chore: snapshot workflow migration progress
This commit is contained in:
@@ -147,11 +147,101 @@ Ergebnis:
|
||||
- Abgeschlossen: Block 6
|
||||
- Abgeschlossen: Block 7
|
||||
- Abgeschlossen: Block 8
|
||||
- In Arbeit: Block 9
|
||||
- Nächster geplanter Folgeblock: Block 9
|
||||
- Abgeschlossen: Block 9
|
||||
- Parallel in Arbeit: Block 11
|
||||
- Vorbereitet: Block 12
|
||||
- Nächster geplanter Folgeblock: Block 11
|
||||
|
||||
## Nächste Orchestrierte Batch-Wellen
|
||||
|
||||
Diese Wellen priorisieren Root-Cause-Arbeit vor weiterer UI-Politur und halten Legacy jederzeit parallel funktionsfähig.
|
||||
|
||||
### Welle P1: Vertrags- und Produktionsmodell-Schließung
|
||||
|
||||
Muss zuerst laufen:
|
||||
|
||||
- `P1-A` Node-Contract Closure
|
||||
- Backend-Registry und Schema als harte Source of Truth schließen
|
||||
- Fokus: Family-Konsistenz, param-key-Validierung, vollständige node settings contracts
|
||||
- `P1-B` Output-Type / Invocation Model Closure
|
||||
- Output Types als sauberes Workflow-Invocation-Modell abschließen
|
||||
- Fokus: artifact/family compatibility, editor/API contract clarity, sichere Erstellung neuer Output Types
|
||||
- `P1-C` Render-Template- und Asset-Library-Inputs als echte Produktionsinputs modellieren
|
||||
- Fokus: template/material-library/input contracts statt versteckter Defaults
|
||||
|
||||
Warum zuerst:
|
||||
|
||||
- diese drei Blöcke definieren die autoritativen Verträge, an denen Editor, Runtime und Golden-Gates hängen
|
||||
- weitere Runtime- und E2E-Arbeit bleibt sonst drift-anfällig
|
||||
|
||||
### Welle P2: Runtime-Parität und Graph/Legacy-Unifikation
|
||||
|
||||
Parallelisierbar nach P1-A:
|
||||
|
||||
- `P2-A` Legacy/Graph Module Unification
|
||||
- gleiche Produktionsmodule in Legacy- und Graph-Pfad verwenden
|
||||
- Fokus: template resolution, samples/defaults, dispatch parity
|
||||
- `P2-B` Canonical Graphs / Starter Blueprints / Seed Normalization
|
||||
- eine kanonische Graph-Quelle statt Drift zwischen backend blueprints, bundles und frontend starters
|
||||
- `P2-C` Run Inspection Completion
|
||||
- Preflight, dispatch, comparison und node outputs operativ debugbar machen
|
||||
|
||||
### Welle P3: CAD-/Material-Parität und Editor-Führung
|
||||
|
||||
Parallelisierbar nach P2-A:
|
||||
|
||||
- `P3-A` CAD / Material Parity
|
||||
- instance-aware part/material truth zwischen exporter, viewer und render path schließen
|
||||
- `P3-B` Editor Organization Around Modules / Families / Input Paths
|
||||
- gemeinsame Authoring-Surface weiter auf modulare Produktionspfade zuschneiden
|
||||
- `P3-C` Context Flow Simplification Follow-up
|
||||
- Kontextauswahl und Output-Type-Einstieg auf die neuen Contracts ausrichten
|
||||
|
||||
### Welle P4: Operative Freigabe und Hygiene
|
||||
|
||||
Nach P2 und P3:
|
||||
|
||||
- `P4-A` Shadow / Graph Rollout Hardening
|
||||
- pro workflow / output type steuerbar, mit klarem Rückfallpfad
|
||||
- `P4-B` Sequential Golden / Smoke / E2E Gates
|
||||
- echte Produktionsfälle mit Templates, Varianten und Output-Types sequenziell absichern
|
||||
- `P4-C` Test-Infrastruktur / Low-RAM Gates
|
||||
- reproduzierbare sequentielle Verifikation
|
||||
- `P4-D` Repo Hygiene / Generated Artifact Root Cause
|
||||
- Ownership-, Pycache- und generated-file-Ursachen bereinigen
|
||||
|
||||
## Sofort Nächste Disjunkte Arbeitsblöcke
|
||||
|
||||
Für die aktuelle nächste Ausführung werden diese drei Blöcke als kleinste sinnvolle Parallel-Batch vorbereitet:
|
||||
|
||||
- Batch `NB-1`: Node-Contract Closure
|
||||
- Status: verifiziert
|
||||
- Fokus: Registry- und Schema-Contracts als harte Source of Truth
|
||||
- Verifikation: `backend/tests/domains/test_workflow_schema.py`, `backend/tests/domains/test_workflow_node_registry.py`
|
||||
- Batch `NB-2`: Output-Type / Invocation Model Closure
|
||||
- Status: verifiziert
|
||||
- Fokus: Artifact-/Family-/Invocation-Contracts fuer Output Types
|
||||
- Verifikation: `backend/tests/domains/test_output_types_api.py`, `frontend/src/__tests__/api/outputTypes.test.ts`
|
||||
- Batch `NB-3`: CAD / Material parity root-cause closure
|
||||
- Status: verifiziert
|
||||
- Fokus: part-key-/instance-stabile Materialidentitaet zwischen Exporter, Manifest und Viewer
|
||||
- Teilfortschritt April 10, 2026: scene-manifest aliasiert jetzt auch exporter-variant keys wie `_af6` auf ihren kanonischen semantischen part key; der Viewer kann damit dieselbe autoritative Materialidentitaet konsumieren wie der Manifest-Pfad
|
||||
- Verifikation: gezielte low-RAM CAD-/Viewer-Tests nach Root-Cause-Fix
|
||||
- Abschluss April 11, 2026: live HartOMat-Export fuer `7c214057-9982-4d6e-aa87-43bfabfdb709` liefert jetzt `146` Manifest-Parts, `146` Mesh-Nodes, `146` eindeutige `partKey`s, `0` fehlende und `0` duplizierte Zuordnungen; Root Cause war die Kombination aus stale GLB cache plus nicht-atomarem OCC-Overwrite beim Re-Export
|
||||
|
||||
Merge-Reihenfolge:
|
||||
|
||||
1. `NB-1`
|
||||
2. `NB-2`
|
||||
3. `NB-3`
|
||||
4. danach erst weitere Runtime-/Editor-Folgeblöcke
|
||||
|
||||
## Letzte Verifikation
|
||||
|
||||
- `./scripts/repo_hygiene.sh`
|
||||
- Ergebnis: Dry-run listet bereinigbare Cache-/Bytecode-Artefakte plus nicht dem aktuellen Nutzer gehörende Generated Files; die Repo-Hygiene deckt jetzt auch `render-worker/scripts/__pycache__` explizit ab
|
||||
- `find . \! -user "$USER" -not -path './.git/*' -ls | sed -n '1,120p'`
|
||||
- Ergebnis: verbleibende Ownership-Reste liegen im `render-worker`-Pycache; Compose-Härtung wird nun über `PYTHONPYCACHEPREFIX=/tmp/pycache` auf die Ursache angesetzt
|
||||
- `backend/.venv/bin/pytest backend/tests/test_config_runtime_resolution.py -q`
|
||||
- Ergebnis: 3 Tests grün; Host-Runtime normalisiert Docker-Service-Aliase (`postgres`, `redis`) außerhalb von Containern nun automatisch auf `localhost`, Container-Runtime bleibt unverändert
|
||||
- `backend/.venv/bin/pytest backend/tests/domains/test_workflow_runtime_services.py -q -x`
|
||||
@@ -166,5 +256,17 @@ Ergebnis:
|
||||
- Ergebnis: 5 Tests grün; autoritative Scene-Manifest-Zuweisungen werden nun im Workflow-Renderpfad auf `part_key` und `source_name` gespiegelt, Legacy-Fallback bleibt unverändert
|
||||
- `./backend/.venv/bin/pytest backend/tests/test_part_key_service.py -q`
|
||||
- Ergebnis: 1 Test grün; part-key-basierte Manifest-Auflösung bleibt konsistent
|
||||
- `python3 scripts/compare_live_cad_parity.py --cad-id 7c214057-9982-4d6e-aa87-43bfabfdb709`
|
||||
- Ergebnis: Live-CAD-Parität grün; Manifest, ausgeliefertes GLB und Viewer-`partKey`-Grundlage stimmen für alle 146 renderbaren Teile exakt überein
|
||||
- `cd frontend && npx vitest run src/__tests__/components/workflowEditorUi.test.tsx src/__tests__/api/outputTypes.test.ts --pool forks --poolOptions.forks.singleFork=true`
|
||||
- Ergebnis: 20 Tests grün, sequenziell ausgeführt
|
||||
- `cd frontend && npm test -- src/__tests__/components/workflowEditorUi.test.tsx src/__tests__/components/workflowAuthoringGuidance.test.ts`
|
||||
- Ergebnis: 17 Tests grün; die gemeinsame Authoring-Surface bleibt nach dem jüngsten Wiring-Refactor stabil
|
||||
- `cd frontend && npm run build`
|
||||
- Ergebnis: Build grün; `/workflows` bleibt kompilierbar nach dem Authoring-Refactor
|
||||
- `./backend/.venv/bin/pytest backend/tests/test_part_key_service.py -q`
|
||||
- Ergebnis: 6 Tests grün; scene-manifest deckt jetzt neben `_2`/`_3` auch exporter-style `_af*`-Varianten ueber semantische Alias-Keys ab
|
||||
- `./backend/.venv/bin/pytest backend/tests/test_export_step_to_gltf.py -q`
|
||||
- Ergebnis: 3 Tests grün; GLB partKey stamping bleibt mit semantic-sibling-Aufloesung stabil
|
||||
- `cd frontend && npm test -- src/__tests__/components/cadUtils.test.ts`
|
||||
- Ergebnis: 11 Tests grün; Viewer-seitige part-key-Aufloesung bleibt nach dem Manifest-Alias-Fix konsistent
|
||||
|
||||
Reference in New Issue
Block a user