HartOMat/docs/workflows/TEMPLATE_INPUT_AUDIT.md

Template Input Audit

Stand: 12. April 2026

Befund

Die Transportkette fuer workflow_input_schema und template_inputs funktioniert inzwischen end-to-end im Graph-Workflow. Der aktuelle Engpass liegt in den live hinterlegten .blend-Templates selbst:

• Alle produktiven Render-Templates haben aktuell workflow_input_schema = [].
• Die live hochgeladenen .blend-Dateien enthalten keine erkennbaren Template-Input-Marker auf Collections, Objekten oder Worlds.
• Damit gibt es derzeit keine realen, template-spezifischen Dropdown-/Options-Felder, die wir ehrlich in resolve_template exponieren koennen.

Gepruefte Live-Templates

• Blender_Studio_Schadowcatcher_Anim_RotOBJ
• Default
• Blender_Studio_Schadowcatcher_Anim
• BlenderStudio_Shadowcatcher
• BlenderStudio

Beobachtete Blend-Struktur

• BlenderStudio: Collection, Export, Lighting, World
• BlenderStudio_Shadowcatcher: Collection, Export, Lighting, Shadowcatcher, World
• Blender_Studio_Schadowcatcher_Anim: gleiche Struktur wie Shadowcatcher-Template
• Blender_Studio_Schadowcatcher_Anim_RotOBJ: gleiche Struktur wie Shadowcatcher-Template
• Default: nur Export, keine World, keine Marker

Konsequenz

Der naechste saubere Schritt ist nicht ein blinder Schema-Backfill, sondern Template-Authoring:

1. Marker oder Scene-Property-gesteuerte Varianten in den .blend-Dateien anlegen.
2. Daraus eine echte workflow_input_schema ableiten.
3. Danach die Felder im Admin pflegen oder per Script backfillen.

Tooling

Fuer diese Authoring-Arbeit gibt es jetzt ein reproduzierbares Audit-Script:

python3 scripts/audit_render_templates.py --json
python3 scripts/audit_render_templates.py --write-markdown docs/workflows/TEMPLATE_INPUT_AUDIT.generated.md

Das Script:

• loggt sich gegen die lokale API ein,
• kopiert die live verwendeten .blend-Dateien aus dem Backend-Container,
• inspiziert sie mit host-Blender,
• erkennt Marker gemaess der HartOMat-Konventionen,
• und erzeugt daraus ggf. Schema-Vorschlaege.