HartOMat/docs/workflows/CURRENT_EXECUTION_BATCH.md

# Current Execution Batch

Stand: April 9, 2026

Dieses Batch zerlegt die verbleibende Workflow-Paritätsarbeit in 12 direkt umsetzbare Blöcke. Ziel bleibt unverändert:

- `/workflows` produktionsfähig machen
- den Legacy-Workflow jederzeit funktionsfähig halten
- Tests und Browser-Verifikation gezielt und sequenziell fahren, damit der lokale Stack nicht durch RAM-Last kippt

## Reihenfolge

### Block 1: Shared Authoring Surface

Ziel:
Die Authoring-Logik für Canvas-Menu und Sidebar auf eine gemeinsame Grundlage ziehen, damit neue Node-Organisation, Stage-Führung und spätere Output-Type-Deep-Links nicht doppelt implementiert werden.

Primäre Dateien:

- `frontend/src/components/workflows/NodeCommandMenu.tsx`
- `frontend/src/components/workflows/NodeDefinitionsPanel.tsx`
- `frontend/src/components/workflows/**`

Ergebnis:

- ein gemeinsames Authoring-Modell statt verteilter UI-spezifischer Sonderlogik
- keine Regression bei Right-Click-Insert, Module/Path-Inserts oder Starter-Steps

### Block 2: Node Organization Hardening

Ziel:
Die Node-Library nach Family, Stage und Module weiter verdichten, damit große Produktionsgraphen schneller gebaut werden können.

Ergebnis:

- schnellere Auffindbarkeit
- weniger UI-Rauschen
- sauberere Trennung zwischen Legacy-, Bridge- und Graph-Nodes

### Block 3: CAD Operational Guidance

Ziel:
CAD-Workflows dieselbe operative Führung geben wie der Still-Graph heute schon hat, inklusive Stage-Status und klarer Baseline-Pfade.

Ergebnis:

- CAD-Familie wirkt nicht mehr wie ein Sonderfall
- Intake-Graphen sind ohne Trial-and-Error zusammensetzbar

### Block 4: Run Inspection Completion

Ziel:
Run-, Node- und Comparison-Ansichten so vervollständigen, dass graphische Fehlläufe direkt im Editor debuggt werden können.

Ergebnis:

- Fehlerursachen sind ohne DB-Inspektion sichtbar
- Preflight, Dispatch und Run-Ergebnis greifen sichtbar ineinander

### Block 5: Context Flow Simplification

Ziel:
Dispatch-/Preflight-Kontextauswahl vereinfachen, besonders bei vielen Order-Lines und Workflow-Varianten.

Ergebnis:

- weniger Fehlbedienung
- klarere Zuordnung zwischen Workflow, Kontext und Ausführungsmodus

### Block 6: Output-Type Contract Closure

Ziel:
Output-Type-Erstellung und -Bearbeitung noch stärker auf Workflow-Verträge und Invocation-Profile zwingen.

Ergebnis:

- neue Output-Types lassen sich stabil anlegen
- Family- und Artifact-Mismatch wird früher blockiert

### Block 7: Canonical Blueprints And Seeds

Ziel:
Starter-Blueprints, Seed-Workflows und Frontend-Neuanlage konsistent auf die kanonischen Family-sicheren Graphen bringen.

Ergebnis:

- weniger Drift zwischen Seed, Editor und Runtime
- bestehende Golden-/Smoke-Workflows bleiben reparierbar

### Block 8: Still Smoke Harness Stabilization

Ziel:
Den non-legacy Still-Workflow als wiederholbaren Smoke-Pfad härten, ohne den Legacy-Fallback zu schwächen.

Ergebnis:

- eindeutiges Pass/Fail-Signal für den kanonischen Still-Graph
- belastbarer Startpunkt für echten E2E-Abgleich

### Block 9: CAD/Material Parity

Ziel:
Materialzuweisung, Instances und Geometrie-Identität zwischen Preview, GLTF-Viewer und Workflow-Verbrauch weiter angleichen.

Ergebnis:

- weniger manuelle Materialreparatur
- Vorschau und Renderpfad greifen auf denselben vertrauenswürdigen Zustand zu

### Block 10: Rollout And Fallback Controls

Ziel:
Rollout, Shadow und Graph-Freigabe sauber pro Workflow und pro Output-Type steuerbar halten.

Ergebnis:

- sichere Aktivierung
- klarer Fallback- und Rückrollpfad

### Block 11: Repo Hygiene

Ziel:
Hilfsskripte, Test-Utilities und neue Workflow-Helfer konsolidieren, damit Folgearbeit nicht auf provisorischen Strukturen aufbaut.

Ergebnis:

- weniger Einweglogik
- besser lesbare Diff-Basis für Restarbeiten

### Block 12: Sequential E2E Gates

Ziel:
Die wichtigsten Smoke- und Browser-Gates dokumentiert und gezielt ausführbar machen, ohne den Rechner parallel zu überlasten.

Ergebnis:

- klarer Minimal-Satz an E2E-Prüfungen
- reproduzierbare Freigabegates für `/workflows`

## Aktuelle Ausführung

- Abgeschlossen: Block 1
- Abgeschlossen: Block 2
- Abgeschlossen: Block 3
- Abgeschlossen: Block 4
- Abgeschlossen: Block 5
- Abgeschlossen: Block 6
- Abgeschlossen: Block 7
- Abgeschlossen: Block 8
- 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`
- Ergebnis: 29 Tests grün; Root Cause für den Host-Testfehler war Celery/Redis-Zugriff über Docker-DNS aus dem Host-Kontext, der jetzt zentral im Config-Layer abgefangen wird
- `curl -I -s http://localhost:5173`
- Ergebnis: Frontend antwortet mit `HTTP/1.1 200 OK`
- `curl -s http://localhost:8888/health`
- Ergebnis: Backend antwortet mit `{"status":"ok","service":"hartomat-backend"}`
- `python3 scripts/test_render_pipeline.py --workflow-still-smoke --execution-mode shadow`
- Ergebnis: Live-Smoke erfolgreich; Shadow-Comparison stabilisiert auf `WARN` mit `mean_pixel_delta=0.000257`, Legacy bleibt dadurch weiterhin authoritative
- `./backend/.venv/bin/pytest -q backend/tests/domains/test_workflow_runtime_services.py -k 'resolve_order_line_template_context_uses_exact_template_and_override or resolve_order_line_material_map_prefers_line_override_over_output_override or resolve_order_line_material_map_allows_node_override or prefers_authoritative_scene_manifest_assignments or keeps_legacy_source_name_fallback_without_scene_manifest'`
- 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