# #242 — Medienabteilung (Konzept, Phase 1 / morphisch)

> Status: **Design-Track — Konzept vollständig entschieden (i/ii/iii, Sascha 2026-08-09).**
> Kein Produktivcode, keine BE-Anbindung. Nächster Schritt = Bau-Planung (Slice-1 =
> A-Studio-MVP, Bau-Plan #244). **A („Studio") = Leitrichtung + Einstieg + Leit-Build.** B („Agent-als-User") war ein **Fehl-Framing und ist gestrichen** —
> der Agent hat KEINE eigene sichtbare Lane-UI; seine Erzeugung wird der **unsichtbare
> on-behalf-of-Capability-Unterbau** von A (und später C). C („Fließband") bleibt als
> **spätere Skalierungs-/Batch-Sicht**. Design-Anker = bestehendes App-Shell-CI
> (#237-Linie, `MachineroomAgentDossier` als visueller Ton).

## 1. Problem

Menschen (User) im Pandora-Ökosystem brauchen laufend Medien-Assets — Bilder
(Passbilder, Illustrationen, Diagramme), Ton (Voice, Jingles) und Video (H3-Clips)
— für ihre **Kontexte**, **OpenCloud-Spaces** und **Repos**. Das erzeugende System
ist ComfyUI auf dem neuen Blackwell-GPU-Stack (Sisyphus: H3-Video läuft, Bild-Gen
kommt dazu). ComfyUI ist mächtig, aber seine **rohe Node-Graph-UI ist für Endnutzer
ungeeignet** — zu viel Komplexität, kein Bezug zur App-Shell, keine Integration in
die bestehenden Kontext-/Space-/Repo-Workflows.

**Kern der Aufgabe:** Eine „Medienabteilung" als **integrierte Pandora-App im
Drei-Lanes-Layout** — NICHT die rohe ComfyUI-Node-UI. Die Komplexität soll
verschwinden. Kuratierte Workflow-Templates werden zu einfachen Formularen. Der
**User** erstellt und verwaltet **seine** Medien im Studio; er kann eine Generierung
zusätzlich **an einen Agenten delegieren** („in meinem Auftrag durch Agent X"), der
sie **on behalf of** über eine Capability erzeugt — die Ergebnisse landen dabei
**nahtlos im Zugriffsbereich des beauftragenden Users** (sein Kontext/Space/Repo).

## 2. Nutzer

| Nutzer | Rolle | Braucht |
|--------|-------|---------|
| **User (Mensch, PRIMÄR)** | Sitzt an der Werkbank; besitzt seine Medien | Template wählen, Parameter füllen, generieren, Varianten vergleichen, Assets kuratieren + in **seinen** Kontext/Space ablegen. Volle Kontrolle, visuelles Feedback. **Optional** eine Generierung **an einen Agenten delegieren** und seine (auch delegierten) Jobs verfolgen. |
| **Agent (DELEGAT, unsichtbar)** | Führt im User-Auftrag aus | Erzeugt Medien **on behalf of** den User über die Capability; die Ergebnisse entstehen im **Zugriffsbereich des beauftragenden Users**. **Keine eigene sichtbare Lane-UI, kein eigener Akteur** — erscheint höchstens als Attribut „erzeugt von Agent X in deinem Auftrag". |
| **Kurator (RBAC)** | Pflegt die Template-Bibliothek | Workflow-JSON hochladen, Parameter-Schema definieren, Template freigeben/zurückziehen. |

**Kern-Korrektur (Sascha):** Der Agent ist **kein sichtbarer User** und agiert
**nicht in eigenen Lanes**. Die einzige sichtbare Oberfläche ist die **User-Surface**
(A/C). Delegation = der User beauftragt; der Agent produziert unsichtbar im
Hintergrund; die Medien gehören dem User und landen in seinem Space.

## 3. Die drei Lanes (App-Shell-Muster)

Die App hängt als `routes/work/medien` in das bestehende `useShell`-Muster (Header
mit Suche + Lane-Toggles, dyn. Footer), Lane-Mechanik 1:1 wie `RoomsView` /
`MachineroomView`: **linke Lane** (320px, `border-right`), **mittlere Lane** (flex),
**rechte Lane** (bedingt sichtbar, resizable, closable).

- **Richtung A — „Studio" (LEIT-BUILD, User-Werkbank):** (siehe `mocks/242/direction-a-studio.html`)
  - Links: **Template-Galerie** (kuratierte Workflows, gruppiert nach Modalität Bild/Ton/Video) + Workflow-Upload/-Export.
  - Mitte: **Canvas/Bühne** — großes Inline-Vorschaufeld + Prompt/Parameter-Formular des gewählten Templates, Generieren-Aktion (selbst **oder** „an Agent X delegieren"), Varianten-Streifen, sowie **die eigene Job-Timeline des Users** (queued/läuft/fertig, 600 s-Polling) über seine eigenen UND seine delegierten Jobs.
  - Rechts: **Asset-Bibliothek / Ablage** — erzeugte Assets, Inline-Media-Viewer (Bild/Video/Audio), Metadaten inkl. „erzeugt von Agent X in deinem Auftrag", „In meinen Kontext/Space ablegen".

- ~~**Richtung B — „Agentur / Agent-als-User"**~~ — **GESTRICHEN.** Fehl-Framing: der
  Agent hat keine eigene sichtbare User-UI und agiert nicht in eigenen Lanes. Der Wert
  von B (Delegation + Job-Timeline) ist als **on-behalf-of-Feature in A eingefaltet**;
  die Agent-Erzeugung selbst ist der **unsichtbare Capability-Unterbau** (§5).

- **Richtung C — „Redaktions-Fließband" (SPÄTERE Skalierungs-Sicht):** (siehe `mocks/242/direction-c-fliessband.html`)
  - Batch/Massen-Fortführung dessen, was im Studio vorentwickelt wurde (standardisierte Use-Cases), evtl. **eigener Pandora-Bereich**.
  - Links: **Aufträge des Users** · Mitte: **Pipeline-Board** (Brief → In Arbeit → Review → Freigegeben → Publiziert) · Rechts: **Karten-Detail / Freigabe / Ablage-Ziel**.
  - Der Agent bedient A+C **im Hintergrund** (unsichtbar via Capability, on-behalf-of) — er erscheint auf Karten nur als Ausführungs-Attribut, nicht als Auftraggeber/Akteur.

## 4. Workflow-Template-Modell

Der Kern der „Komplexität verschwindet"-Anforderung. Ein **Template** kapselt einen
kuratierten ComfyUI-Workflow und exponiert nur eine Handvoll Formularfelder:

```
Template
├─ id, name, beschreibung, kategorie
├─ modalität            : bild | ton | video
├─ vorschaubild          (Thumbnail für die Galerie)
├─ workflow_ref          (der kuratierte ComfyUI-Graph — versioniert, versteckt)
├─ param_schema[]        (NUR die exponierten Eingaben:)
│   ├─ { key, label, typ: text|zahl|auswahl|seed|bild-input, default, constraints }
│   └─ …  (z.B. prompt, negativ-prompt, seed, steps, seitenverhältnis, dauer)
├─ kosten_schätzung      (GPU-Zeit / Credits — analog Token-Metering)
└─ sichtbarkeit / RBAC   (wer darf nutzen; wer darf kuratieren)
```

- **Curation-Layer** ist das Herz: der Node-Graph bleibt unsichtbar, der Nutzer sieht
  nur `param_schema` als Formular. Das ist die Übersetzung „Node-UI → App-Shell-Form".
- **Template-Quellen (Sascha, ii ENTSCHIEDEN):** ein **kuratiertes Start-Set** PLUS
  **Upload + Import eigener ComfyUI-Workflows** — durch **User UND Agenten** (Agenten
  bauen + importieren Workflows auch **im Hintergrund**). **Workflow-Import ist
  KERN-SCOPE, nicht nachgelagert:** eigene Import-Routes/Endpoints, **async-fähig**.
  Der User kann Templates im Studio zusätzlich anpassen (Parameter-Presets/-Varianten).
  Die Grenze user-editierbar ↔ kuratiert-gesperrt bleibt RBAC-Detail (§7).
- **Upload/Import (Kern):** User **oder** Agent lädt/importiert Workflow-JSON via
  Import-Route → System registriert es als nutzbares Template und **leitet das
  `param_schema` aus der rohen ComfyUI-Workflow-JSON ab** (war Hermes' Nebenpunkt, ist
  jetzt zentral; Machbarkeit G8). Download exportiert das Template wieder als JSON
  (Austausch zwischen Umgebungen). Versioniert. Die on-behalf-of-Delegations-Auth (§5,
  G6) gilt **auch für agent-importierte** Workflows.
- **Delegierbar:** dasselbe Template ist per `param_schema` maschinell aufrufbar →
  bei Delegation füllt der **Agent im User-Auftrag** die Felder (on-behalf-of, §5).

## 5. Capability-Seam (unsichtbarer on-behalf-of-Unterbau)

Die Agent-Erzeugung ist **kein sichtbarer Akteur in der UI**, sondern der
**unsichtbare Unterbau** hinter der User-Surface (A/C): der User beauftragt, der Agent
erzeugt **on behalf of** über eine **Capability**, die Medien landen im
**Zugriffsbereich des beauftragenden Users**. Der folgende Ist-Stand ist von
**Hermes am realen Pandora-BE code-verifiziert** (nicht spekuliert):

- **Registrierung — YAML-first + DB-gespiegelt, 4 Layer:** `capabilities/registry.yaml`
  (Index) + `capabilities/examples/*.yaml` (eine Datei pro Capability), validiert
  gegen `capabilities/schema.yaml`. Das Schema hat **ComfyUI bereits mitgedacht**
  (Beispielwerte: service `pandora-comfyui`, env_var `COMFYUI_API_KEY`, metadata.name
  `video-creator`) — **eine ComfyUI-YAML existiert aber noch nicht**. DB-Layer:
  `AgentCapability` (M2M Agent↔Capability, Felder `enabled`/`priority`/
  `config_overrides`); die `CapabilityBridge` rendert die YAML in eine
  Claude-Subagent-`.md`.
- **Auth/Scoping, zwei Ebenen:** `AgentCapability` = *wer hat sie zugewiesen*;
  `CapabilityPermission` = platform/org/role/user-Sichtbarkeit, **deny-by-default**.
  Zusätzlich pro Capability `access.permissions` + `access.quotas`
  (jobs/hour/day, concurrent, max_duration) in der YAML. Getrennt von der
  MCP-Tool-ACL (die gated einzelne Tool-Calls, nicht die Zuweisung).
- **Invocation — harness-aware:** `claude_code`-Agenten bekommen `local_execution:true`
  und rufen die Capability als **nativen Subagent** über ihr Agent/Task-Tool auf
  (liest die gesyncte `.md`). Andere Harnesses → externer Container-Spawn +
  Redis-Result-Bus (Kanal `capability:result:{invocation_id}`).
- **Kritisch fürs UX (600s-Cap):** der Wait-Call ist auf **600 s gedeckelt**. Ein
  mehrminütiger ComfyUI-Render passt **nicht** in ein einzelnes blockierendes Warten
  → **Polling-Muster ist Pflicht**: Job-Status queued → running → done als expliziter
  FE-Zustand. Das zeigt die **User-Job-Timeline in A** (und das Board in C).

**on-behalf-of-Fluss:** der User wählt in A ein Template, füllt `param_schema` und
wählt „selbst generieren" **oder** „an Agent X delegieren". Bei Delegation füllt der
Agent die Felder im User-Auftrag und reiht den **Job** ein; der User verfolgt ihn per
Poll in **seiner** Timeline; das Asset landet in **seinem** Space (§6). Der Agent
bleibt UI-unsichtbar — er erscheint nur als Attribut „erzeugt von Agent X in deinem
Auftrag".

**Autorisierung = Delegation, keine Impersonation** (Daedalus, BE-verifiziert): das
on-behalf-of ist eine **Autorisierungs-Delegation**. Der Agent handelt innerhalb des
**bestehenden user-autorisierten Write-Pfads** — er schreibt nur dorthin, wo der
**Auftraggeber ohnehin darf** (self-scoped, #240-Klasse). **Kein** breiter Service-
Account, **kein** eigener Agent-Space, **keine** Token-Impersonation (Details §6/§7 G6).

**Nächstes Vorbild:** `workflow-automation.yaml` (n8n) — die einzige bestehende
Capability mit echtem `infrastructure.service` / `queue:redis` / `access.url`.
**Wichtige Einschränkung:** der Invoker **validiert nur Params + schreibt eine
`CapabilityInvocation`-Zeile — er startet NIE Docker/den Service**. `infrastructure.*`
ist heute **deskriptive Doku, kein ausgeführter Provisioning-Vertrag**.

## 6. File-Exchange-Seam (Kontexte / OpenCloud / Repos)

**Der Landing-Pfad existiert bereits und ist hoch machbar** (von Daedalus am realen
BE code-verifiziert — das präzisiert und entschärft Hermes' „OCIS nicht verdrahtet"):

- **OpenCloud-Space (PRIMÄR):** wiederverwendbares Primitive
  `opencloud_spaces.upload_bytes(kontext.opencloud_space_id, path, bytes, content_type)`
  — dasselbe, das `context_space_upload` (`POST /api/context/<id>/space/upload/`) nutzt.
  Ein dort abgelegtes Media-Ergebnis **erscheint automatisch im FE-Datei-Browser**
  (`context_space_tree` / `content` backen ihn). Der Space-Root ist
  `kontext.opencloud_space_id`, **server-gesetzt (D-005-leak-safe, nicht
  client-supplied)**. → Die Mocks dürfen selbstbewusst zeigen: „Ergebnis landet im
  Kontext-Datei-Browser" — der Pfad ist real.
- **Auth (Delegation, keine Impersonation):** `context_space_upload` / `upload_bytes`
  sind **user-membership-gated** mit **server-resolved `space_id`** (physisch via
  Service-Graph-Client). Bei Delegation reused der Agent **genau diesen bestehenden
  user-autorisierten Pfad** — **self-scoped auf den Auftraggeber** (#240-Klasse):
  geschrieben wird nur, wo der User ohnehin darf. **Kein** breiter SA, **kein** eigener
  Agent-Space, **keine** Token-Impersonation. Offene Design-Fragen → G6.
- **Repo (SEKUNDÄR / optional):** Binary-in-git ist Anti-Pattern → OpenCloud-Space ist
  das Haupt-Ziel; Repos nur für kleine/Text-Assets oder git-LFS (**ob LFS auf dem
  Kontext-Forgejo aktiv ist, ist verifizierte Unbekannte**). In den Mocks entsprechend:
  Kontext/OpenCloud als Haupt-Ziel, Repo als Nebenpfad.

Der FE-Seam ist damit **Ziel-Auswahl** (Kontext-Space vorausgewählt), **Inline-Media-
Vorschau** des Ergebnisses und der **„im Kontext-Space gespeichert"-Zustand** — alles
gegen einen realen Schreibpfad.

> **FLAG-3 (FE-Lane, direkt relevant):** Inline-Media-Preview (image / audio / video)
> ist **unsere** Aufgabe — `office_open` deckt nur Office-Dokumente, **kein Media**.
> Die Mocks zeigen daher einen echten Inline-Viewer (Bild-Grid, Video-Player,
> Audio-Waveform) für die Ergebnisse. Das ist ein starker, machbarer Aufhänger.

## 7. Machbarkeit — Ist-Stand + ehrlicher Bau-Umfang

**Der Dienst steht bereits.** Sisyphus fährt **ComfyUI-h3 healthy auf Olympus**
(Bild via `flux-kontext` migriert, Video H3 getestet) — die Machbarkeits-Sektion
formuliert also **nicht** „ComfyUI muss erst ans Laufen gebracht werden". Auch das
**Capability-Modell trägt** (YAML + `AgentCapability`-Zuweisung + Quotas,
ComfyUI-antizipiert; §5).

**Net-new ist ausschließlich die FRAMEWORK-INTEGRATION.** Das ist der ehrliche
Bau-Umfang — gehört in die Planung *nach* der Richtungswahl, **nicht** in die Mocks
(die zeigen den Ziel-Zustand, nicht den heutigen Integrations-Gap):

| # | Integrations-Baustein (Gap) | Ist-Stand / Owner |
|---|------------------------------|-------------------|
| **G1** | **Capability-Wiring:** ComfyUI als YAML-Capability + DB-Zuweisung. | Struktur trägt (`pandora-comfyui` ist Schema-Beispielwert); Vorbild `workflow-automation.yaml`/n8n (**nicht** Coolify-Adapter). Framework managed den Dienst heute **nicht** — `infrastructure.*` ist doc-only/nicht provisioniert. → Daedalus/Hermes |
| **G2** | **GPU-Scheduling:** Quota/Affinität/Queueing. | Im Schema vorhanden (`infrastructure.gpu`, `resources.gpu_memory`), **code-seitig nicht enforced**. → Sisyphus/Daedalus |
| **G3** | **Long-Render-Polling:** async Job-Fortschritt. | Result-Bus-Wait auf **600 s gedeckelt** → echte Renders brauchen Polling-Muster (queued/running/done). FE-seitig in den Mocks abgebildet. → Hermes |
| **G4** | **Streaming-Upload (FLAG-1, kritisch):** `context_space_upload` / `upload_bytes` puffern die **ganze Datei im RAM** → große Media (Video) = OOM-Risiko. Media braucht chunked/streaming-Upload (TUS o. chunked-WebDAV-PUT). | **Haupt-BE-Extension.** → Daedalus |
| **G5** | **Capability-Result → Upload verdrahten:** den Capability-Output an `upload_bytes(kontext.opencloud_space_id, …)` hängen. | Das ist Hermes' „Framework-Integration"-Teil; Landing-Pfad + FE-Browser stehen bereits (§6). → Hermes/Daedalus |
| **G6** | **on-behalf-of-Schreib-Auth = Autorisierungs-Delegation.** Zwei Schichten: der physische Write *reused* den user-membership-gated Pfad (`context_space_upload`/`upload_bytes`, self-scoped wie #240); die Delegations-Grant-Schicht ist *net-new*. Konsolidiertes Modell (DelegationGrant + Doppel-Check + Provenance als Hard-Req) siehe **G6-Detail** unter der Tabelle. | Modell konsolidiert (Daedalus+Hermes, code-verifiziert); 1 offene **Sascha**-Entscheidung (Grant-Scope, iii) → Hermes+Daedalus |
| **G7** | **ComfyUI-API-Anbindung:** Aufruf-Shape ans laufende ComfyUI (Workflow-Submit, Progress). | Dienst läuft; BE-seitige Anbindung an die Capability zu spezifizieren. → Sisyphus |
| **G8** | **Workflow-Import-API (KERN-SCOPE, Sascha ii):** User- UND Agent-Upload/Import von ComfyUI-Workflow-JSON via eigene Import-Routes (**async-fähig**) → Registrierung als nutzbares Template inkl. **`param_schema`-Ableitung aus der rohen Workflow-JSON**. on-behalf-of-Delegation (G6) gilt auch für **agent-importierte** Workflows. Konvertierungs+Validierungs-Schicht + **Security-Block** siehe **G8-Detail** unter der Tabelle. | **Machbar** (Sisyphus + Daedalus verifiziert, G8-Detail): ComfyUI-UI→API-Konverter (Prototyp) + `WorkflowTemplate`-Registry am Capability-Muster. Security = Minos/D-005 @ Import-Slice. Ergänzt G1/G7. |

### G6-Detail — Delegations-Auth (konsolidiert, Daedalus + Hermes, code-verifiziert)

Das on-behalf-of trennt sich sauber in **zwei Schichten** — das ist die präzise
Machbarkeits-Aussage (nicht „alles neu", nicht „alles da"):

- **(a) Physischer Write = REUSED.** `context_space_upload` / `upload_bytes` sind
  user-membership-gated, mit **server-resolved `space_id`** (aus dem Grant, **nicht**
  client-supplied = leak-safe), physisch via Service-Graph-Client. Der Agent schreibt
  nur, wo der Auftraggeber ohnehin darf (#240-self-scope). **Keine** Token-Impersonation.
- **(b) Delegations-Grant = NET-NEW.** Kein bestehender Träger: `CapabilityPermission`
  ist reine Sichtbarkeit (kein Resource/Space-Scope, nicht per-Ziel-revocable),
  `AgentCapability` kennt keine User-Delegation, `CapabilityInvocation` hat kein
  on-behalf-of-Feld. → **`DelegationGrant`** (neues Modell, getrennt von
  `CapabilityPermission`): `(user, agent, capability_name, space_id, granted_at,
  revoked_at, granted_via)` — **per-Agent-Trust (Sascha iii = b, least-privilege): der
  Grant scopet auf das `(user, agent, capability)`-Tripel, NICHT capability-name-weit**
  — OAuth-Consent-artig, keine Rolle; Revocation = `revoked_at` setzen
  (kein Hard-Delete, Audit-Trail). **BE-self-scope auf die Grant-Erstellung:** `space_id`
  muss ein Space sein, den der **delegierende** User selbst schreiben darf (nur in
  **eigene** Spaces delegierbar).
- **Claim-Transport + Doppel-Check:** invoke trägt `on_behalf_of_user_id`; BE validiert
  gegen den **Grant** (nicht die Live-Session) und persistiert den durablen Claim
  (`space_id` + `on_behalf_of_user_id` + invocation-id) in `CapabilityInvocation`
  (neue Felder). `revoked_at` wird **zweimal** geprüft — bei **invoke-time** (Job
  annehmen) UND bei **write-time** (Recheck am `upload_bytes`-Boundary, bevor der
  Service-Client schreibt) — sonst greift Revocation nicht auf schon-gequeuete
  Async-Jobs. Spiegelt die #240-write-time-authz.
- **Provenance = HARTE Anforderung** (DSGVO, nicht-verhandelbar — Amphiaraus/Sascha):
  da die OCIS-Write-Identity der Service-Client ist, **muss** Pandora das Triple
  `(agent_id, on_behalf_of_user_id, space/medium-path via invocation-id)` zur
  **invoke-time** im Claim festhalten (Feld auf `CapabilityInvocation` o. Audit-Zeile)
  — sonst nach dem Write nicht rekonstruierbar. **Keine** offene Frage, sondern Pflicht.
- **Entscheidung (Sascha, iii = b): Grant-Scope = Agent+Capability-Paar** (per-Agent-Trust,
  least-privilege). Der User vertraut **Agent X spezifisch** mit dieser Capability, NICHT
  der Capability generell — der `DelegationGrant` scopet entsprechend auf
  `(user, agent, capability, space_id)`. (Enger + mehr Grants, aber least-privilege — jeder
  Agent braucht seinen eigenen Grant vom User.)

### G8-Detail — Workflow-Import (Sisyphus + Daedalus, prototyp-/code-verifiziert)

**Machbar** — aber Import = **net-new Konvertierungs+Validierungs-Schicht** auf
existierenden Primitiven **plus** ein **net-new Registry-Modell** auf dem bestehenden
Capability-Muster. Der harte Block ist **Security** (beide unabhängig geflaggt).

**ComfyUI-Seite (Sisyphus, prototypisch am H3/flux-Stack verifiziert, 0.31.1):**
- **Kern-Gap = zwei JSON-Formate:** Export/Save liefert das **UI-Format** (Editor-Graph:
  `nodes[]` + `widgets_values` + `links[]` + evtl. `definitions.subgraphs`); der Submit
  `POST /prompt` frisst das **API-Format** (`{node_id:{class_type,inputs}}`). ComfyUI
  konvertiert UI→API **nur clientseitig** (litegraph-JS) — **kein server-side Endpoint**.
  Die Konversion ist net-new.
- **Existiert nativ:** `POST /prompt`, `GET /history/<id>` + WS `/ws` (Poll/Live-Status →
  passt zum 600 s-Polling G3), `GET /object_info` (Node+Modell-Katalog = Dependency-Quelle),
  `POST /upload/image`, `GET /view`, `GET /queue`.
- **Net-new Import-Schicht:** (1) **UI→API-Konverter** — Sisyphus hat einen funktionierenden
  **Prototyp** (Subgraph-Expansion, `widgets_values`-Alignment gg. `object_info`, seed-Shift,
  Output-Bridge) = **harden statt from-scratch**; (2) **Dependency-Manifest** (custom-nodes +
  Modelle gg. `object_info`/`models/` validieren, fehlende Deps vor Submit rejecten statt
  opaker 400s); (3) **Asset-Handling** (LoadImage via `/upload/image`, tenant-scoped);
  (4) tenant-scoped Storage + ComfyUI-Version-Bindung.

**Pandora-Seite (Daedalus, code-verifiziert):**
- **Template-Registry = NET-NEW** (`WorkflowTemplate`; kein bestehendes Modell,
  `ViewTemplate` ist unrelated) — aber **kein neuer Access-Layer:** **anknüpfen ans
  Capability-Muster** (owner + param-Validierung + Visibility via `CapabilityPermission`).
- **`param_schema` = JSON-Schema**, verankert auf dem bestehenden params-Muster
  (`bookstack_action_registry.params_schema` + Capability-Validierung) → **Validierungs-
  Maschinerie reused**.
- **Schema-Derivation = net-new + Haupt-BE-Arbeit.** **FLAG (Konzept-Entscheid nötig):**
  ComfyUI-JSON hat **keine native Param-Deklaration** — die Derivation braucht eine
  **Konvention, welche Inputs user-exponiert sind** (Title-Prefix / Primitive-Input-Nodes /
  Companion-Manifest). Muss festgelegt werden.
- **Import-Route = net-new, Shape precedented** (bestehendes `blueprint/import`-Muster,
  z.B. `machineroom/agents/blueprint/import/`).

**Agent-Import-Ownership (Daedalus):** Import erzeugt eine **Registry-Entity**
(`WorkflowTemplate`-Row) — **andere Resource-Klasse als G6** (Space-Write). Der
G6-`DelegationGrant` passt **nicht** direkt; Import braucht einen **eigenen, leichteren
Ownership-Typ** (`WorkflowTemplate.owner` + Visibility + Provenance), **nicht** die
per-Space-Grant-Maschinerie. Das **on-behalf-of-Prinzip trägt** aber: agent-importiert →
**owner = der beauftragende User** (nicht der Agent) + **Provenance** (`imported_by_agent`
+ `on_behalf_of_user`, reuse des G6-Triples).

**SECURITY = der harte #242-Design-Block** (Sisyphus + Daedalus **unabhängig**;
Minos/D-005 @ Bau): hochgeladene Workflows sind **untrusted** — ComfyUI-Nodes können Files
lesen/schreiben o. Code ausführen, Filename-Felder erlauben **Path-Traversal**; als runnable
Template registriert = **Injection/Execution-Surface**. Braucht **Node-Allowlist + Sandbox +
Pfad-Constraints**, **kein** arbitrary custom-node-exec. Dazu **ComfyUI-Version-Drift**
(`object_info`-Signatur-Mismatch validieren), **custom-nodes** (rejecten vs. kuratierter
Satz), **Multi-tenant-Queue/GPU-Fairness** (überschneidet G2).

**Offene Trust-Entscheidung (Sascha, analog iii) = (iv):** braucht Agent-Import einen
**expliziten User-Delegations-Grant**, ODER darf ein Agent mit zugewiesener
Import-Capability **per-default als-User** importieren (owned-by-served-user)? Termin-Frage.

**Reconciliation (wichtig):** der **File-Landing-Seam ins OpenCloud/Kontexte
existiert bereits** (Space-Root server-gesetzt + FE-Datei-Browser bäckt ihn, §6) —
also **nicht** „nicht existent". Der neue BE-Bau ist **schmaler** als zunächst
angenommen: die **Haupt-BE-Arbeit ist FLAG-1 / Streaming-Upload (G4)** — **unabhängig
von der Auth-Richtung** — plus **Result→Upload-Wiring (G5)**. Die Schreib-Auth-Richtung
ist **gesetzt** (on-behalf-of = Autorisierungs-Delegation über den bestehenden
user-gated Pfad, self-scoped; **keine** Impersonation/SA/Agent-Space), nur die
Delegations-Mechanik-Details sind offen (G6). **FE-seitig (unsere Lane):** Inline-
Media-Viewer (image/audio/video) — `office_open` deckt Media nicht (§6 FLAG-3).

**Verifizierte Unbekannte / offene Punkte:** git-LFS auf dem Kontext-Forgejo aktiv?,
`OPENCLOUD_SYNC_ENABLED` per-Box gesetzt? — beides per-Box zu verifizieren.
**Konzept-Entscheide (i/ii/iii) sind ALLE durch** — Grant-Scope (iii) = **Agent+Capability-Paar**
(Sascha = b; G6-Detail). Die **G6-Delegations-Mechanik ist konsolidiert** (Daedalus+Hermes;
Provenance = harte Anforderung; `DelegationGrant` scopet auf `(user, agent, capability, space_id)`).
**RBAC-Detail für die Bau-Planung:** Grenze user-editierbar ↔ kuratiert-gesperrt bei Templates
(§4), Kosten-Metering analog `tokenUsage` (Daedalus). Die **Workflow-Import-API (G8)** ist
feasibility-geklärt
(Sisyphus + Daedalus, G8-Detail): machbar auf existierenden Primitiven + Capability-Muster;
Haupt-Arbeit = UI→API-Konverter (Prototyp da) + Schema-Derivation. **Offene G8-Punkte =
Bau-Items der späteren IMPORT-SLICE** (Slice-1 = A-Studio-MVP, Import danach; nicht Review-Runde):
(a) **Security-Design-Block** (untrusted-Workflow-Validierung, Node-Allowlist/Sandbox/Pfad-
Constraints — **Minos/D-005**, prominent im Bau-Plan #244), (b) **Schema-Derivations-Konvention**
(welche Inputs user-exponiert), (c) Trust-Entscheidung **(iv)** (Agent-Import expliziter-Grant vs.
default-owned-by-served-user) — entschieden beim Planen der Import-Slice, nicht jetzt an Sascha.

Bis diese Bausteine gebaut sind, sind die Mocks bewusst **frontend-only** und
markieren jede noch nicht verdrahtete Fläche als Entwurf.

## 8. Design-Disziplin

- **Anker = App-Shell-CI:** Section-Header UPPERCASE + `letter-spacing ~0.16em` +
  Primär-Tick `::before`, Section-Icons, dünne Trennlinien, Card-/Chip-Styling wie
  im `MachineroomAgentDossier`. Feld-/Input-Styling wie `RealModelEditor`.
- **Nur Theme-Tokens** (`var(--…)`), hell + dunkel; keine hartkodierten Farben.
- **Drei-Lanes-Muster** wie `RoomsView` (nicht Standalone-Route).
- **Minimal-invasiv:** in Phase 1 nur neue Dateien unter `docs/` + `mocks/242/`.

## 9. Entscheidung (Sascha, 2026-08-09)

- **A („Studio") = Leitrichtung + Einstieg + Leit-Build.** Human-in-the-Loop:
  A ist die Erstellungs- und Verwaltungs-Oberfläche des **Users** für **seine** Medien.
- **on-behalf-of-Delegation ist ein FEATURE in A**, keine eigene Richtung: der User
  kann eine Generierung „in meinem Auftrag durch Agent X" anstoßen; die Erzeugung läuft
  über den **unsichtbaren Capability-Unterbau** (§5); das Ergebnis landet in **seinem**
  Kontext/Space. Der Agent erscheint höchstens als Attribut „erzeugt von Agent X in
  deinem Auftrag" — **nie** als eigener Akteur/UI.
- **B („Agent-als-User") ist gestrichen** (Fehl-Framing). Sein Delegations-/Timeline-
  Wert ist in A eingefaltet.
- **C („Fließband") = spätere Skalierungs-/Batch-Sicht** für standardisierte Use-Cases
  (Pipeline/Masse dessen, was im Studio vorentwickelt wurde), evtl. eigener
  Pandora-Bereich. Agent bedient A+C **im Hintergrund** via Capability.

**Beantwortete Entscheidungen:** (i) Ausführungs-Modell = Capability-**on-behalf-of**
(keine Agent-Persona) — durch Saschas Korrektur entschieden. (ii) Template-Quellen =
kuratiertes Start-Set **PLUS User- UND Agent-Workflow-Upload/Import als Kern-Scope**
(§4, G8). (iii) **Grant-Scope ENTSCHIEDEN (Sascha = b):** **Agent+Capability-Paar**
(per-Agent-Trust, least-privilege; `DelegationGrant` scopet auf `(user, agent, capability,
space_id)`, G6-Detail). → **Konzept i/ii/iii vollständig entschieden.** Für die spätere
**Import-Slice**-Bau-Planung offen (nicht Review-Runde): (iv) Agent-Import-Trust,
Schema-Derivations-Konvention, Import-Security-Block (Minos/D-005). **Slice-1 = A-Studio-MVP.**

Gemeinsam über A und C: Template-Modell (§4), Capability-on-behalf-of-Unterbau (§5),
File-Exchange-Seam (§6). Nächster Schritt bleibt morphisch: A als Leit-Mock verfeinern,
dann Build-Planung — **nicht** in dieser Phase.