--- name: teatro-scenario-composer description: "Turn a writer's natural-language musical intention into an automatically composed, inspectable, executable Fountain Coach Csound Teatro Scenario and live patch. Infer semantic relationships and runtime routing from the request and discovered capabilities; implement missing owner-native connections, then admit, run, observe, stop, and verify the result. Use for composing or changing Teatro scenarios, live patches, Sing/Ear/Csound connections, MIDI 2.0 and MIDI-CI capability negotiation, and Teatro Stage projections. Preserve the versioned Csound Teatro DSL, canonical TeatroStageEngine, and source ownership. Invoke Linotype only when the request includes a book, folio, edition, Bookshelf, or publication." --- # Teatro Scenario Composer Translate musical intention into a working Teatro composition. The writer should describe the musical result; the model should infer the entities, relationships, mappings, and signal/control routing, author the Scenario, bind it through the existing owner-native runtime, and make the result audible and visible. Do not make the writer specify ports, protocols, endpoints, cables, mappings, or implementation steps when these can be resolved from the request, source contracts, and discovered capabilities. Keep the Scenario inspectable as the semantic score, while keeping plumbing backstage. A skill is a procedure, not an FCIS instrument, engine, transport, source repository, or release receipt. Before implementation or conformance claims, read [source authorities and drift](references/authorities.md), [Scenario and binding contract](references/scenario-contract.md), and the current organization [Goal Fidelity and Non-Invention](https://github.com/Fountain-Coach/.github/blob/main/docs/FCIS-Non-Invention-and-Goal-Fidelity.md). Read [live stage UX](references/stage-ux.md) for interface/prototype tasks and [Linotype collaboration](references/linotype-handoff.md) for books, scores in books, editions, or publication. ## Compose in the existing domain 1. **Understand the intended musical result.** Read the writer's request for sound, behavior, change, and desired live or visual result. Infer a complete first composition from available context. Ask only when unresolved artistic intent or entity identity would materially change the result; do not ask the writer to design the routing. A request for a live patch means compose, connect, and run the patch through the governed path, not merely author or visualize a candidate. 2. **Inspect owners and actual state.** Read the current authoritative FCIS/Governance chapter 151 and relevant 150, 101, 107, 119; the relevant `AGENTS.md`; the existing Scenario source; and the participating instrument, stage, and transport code. Pin branch and commit SHA when modifying source. Verify what is actually running separately from checked-in Git: the public Teatro root and repository's static root can disagree. Record OBSERVED / PROVEN / DOCUMENTED / INFERRED / PROPOSED separately. Do not infer acceptance from names, source files, test fixtures, a generated score, or an attractive screenshot. 3. **Compile intent into the existing Csound Teatro DSL.** Author or revise `CsoundTeatroScenario` with stable identities and `GIVEN`, `TRANSFORM`, `CONSTRAINTS`, `EXPECT`, and `VERIFY`. Infer the best supported relations, mappings, ranges, and policies from the musical request and actual capabilities. Keep this translation automatic; show the writer a concise description of the resulting composition rather than asking them to approve each connection. Validate against the *owning runtime's* current registry, not only a secondary source checker. If a predicate or representation disagrees across implementations, reconcile the owning versioned grammar and consumers, then continue through admission and execution. Never silently weaken the intention or call a secondary check native admission. 4. **Keep entities distinct.** Sing is a source-owning FCIS instrument; Ear is an observing instrument; Csound is a sound engine unless a particular governed Csound-backed instrument has separately declared identity/capability; a wind FIELD, Teatro Stage, and Csound Teatro Scenario do not automatically become FCIS instruments. A Scenario governs their relation. Prevent identity collapse such as renaming a wind-generating AudioWorklet "Sing". 5. **Do the routing work for the writer.** Infer the topology that realizes the musical intention, then resolve it automatically against discovered endpoints, ports, clocks, and owner-supported adapters. Use MIDI-CI, Profiles, and Property Exchange for the capability and configuration facts they actually provide; use the existing audio path for PCM and MIDI 2.0 UMP for typed MIDI operations. MIDI-CI does not choose musical meaning or carry arbitrary PCM. Do not expose a cable-by-cable negotiation to the writer. If a required adapter, binding, or runtime operation is absent, continue by implementing the smallest change in its owning source and preserve the intended outcome. Do not substitute a diagram, alternate transport, hidden port, MIDI 1 fallback, or unadmitted local shortcut. 6. **Admit and execute the composed result.** Produce the canonical Scenario and execution plan, resolve its bindings, and invoke the existing native admission path before effects. A source checker is not admission. When the writer explicitly requests a live patch or performance, that request authorizes its bounded start; do not ask for another confirmation merely to start the requested work. Keep Stop available, prevent uncontrolled feedback, and collect correlated runtime and terminal evidence. If admission refuses, repair the owning contract or adapter and retry; report a blocker only when the exact required path cannot proceed after the smallest authorized repair. 7. **Let the stage show the composed result.** Preserve TeatroStageEngine's canonical room, camera, actors/fields/puppet, time, and snapshots. Project the authored Scenario and actual runtime state into its existing host. Treat the spatial/sonic composition as the work; keep port, protocol, and binding detail in an optional inspector. The writer should experience a composed scene, not a patch board or an implementation tutorial. Do not invoke Linotype unless the requested outcome includes a book or publication. See [stage UX](references/stage-ux.md). 8. **Verify the experienced result.** For a live patch, prove the original source, resolved signal/control paths, actual Csound effect, audible result, Ear observation, and bounded Stop with the appropriate owner evidence. For a visual-only request, verify the canonical stage projection and label simulated state clearly. Use owner-native tools and checks. A passing test, diagram, or source candidate cannot replace a live witness. FountainStore owns durable evidence; publication remains separate. 9. **Handoff publication, never confuse it with performance.** If a Scenario is to appear inside a book or edition, give the Linotype skill the versioned source identity, provenance, Score/Stage projection contract, rights/admission status and verified runtime/preview limits. Linotype composes book leaves and reading/navigation; Teatro owns scenario meaning, stage and execution. See [Linotype collaboration](references/linotype-handoff.md). 10. **Stop at bounded acceptance.** Report the written/revised Scenario and owning commit, grammar status, capability and binding evidence, Stage projection status, runtime/measurement witness, and any remaining actual gap. Do not claim running sound because a diagram animates, nor imply public release from a source preview. ## SatzfunkPlayer execution profile Use this profile when the requested result is a source-bound playable composition and the current SatzfunkPlayer contract/runtime exposes the path. Re-read the owner contract and exports at the pinned commit each time; do not assume an old bundle contains the current API. - Resolve the Scenario through the Player's public instrument API (`createTeatroScenarioRuntime`) and its declared Csound input adapter (`createCsoundMidi2UmpInput`). If the contract declares an adapter that `src/index.mjs` does not export, repair the Player owner API and pin the resulting commit. Do not import an unexported private file from a consumer route. - Keep `CsoundTeatroScenario.status: candidate-unadmitted` when the native Csound Teatro admission path has not run. A Player-owned admission receipt is a separate, valid runtime state; never rewrite the DSL candidate to imply native Csound admission. - Verify the exact public source bytes and digest before binding the Player. Route Player PCM through Ear's actual AudioWorklet input, dispatch the typed UMP operation to the declared software peer, observe Csound output through its separate Ear tap, and project the same run ID into canonical TeatroStageEngine. Do not equate the software UMP peer with hardware interoperability or MIDI-CI envelope support with live discovery/profile negotiation. - Start only under a trusted browser user gesture where Web Audio requires one. Correlate source identity, Scenario ID, run ID, UMP sequence and controller, input/output Ear measurements, Stage state and Stop. For WLAN overlays, inspect the final browser media URL: if the overlay has already rewritten a path, the runtime must consume it once and must not prepend the mount path again. - Stop the Player, send the correlated baseline operation, mute and disconnect the Csound output and its Ear tap, and request context closure. Accept terminal silence only after the output context is closed and UMP/Ear counters remain unchanged after Stop. Do not hold the visible stopped state indefinitely on a host cleanup promise after audio has been cut off; report host cleanup separately if it remains pending. ## Typical requests and their expected outcomes - **"Compose by Ear; let Ear drive Csound wind while Sing performs."** Infer and compose the live path from Sing's PCM through Ear's observation to the Csound FIELD control, including the existing typed MIDI 2.0 operation where the runtime uses it. Inspect the current Scenario and runtime contracts; reconcile any grammar mismatch and implement the owner-native bridge/admission path needed to make the requested live result run. Do not return only the candidate or ask the writer to specify ports. - **"Make Teatro feel like Bidule without cables."** Let the writer state what should happen musically. Resolve and establish the actual topology automatically, then show its spatial and temporal consequences on the Teatro stage. Keep routing facts inspectable on demand; do not make a patch board or cable editor the primary experience. - **"A ball excites a plate; Ear hears it."** Use Chapter 151's accepted `collision(Ball.01, Plate.01)` / `EXCITES` / `MAPS_TO` / `LISTENS_TO` fixture, retaining typed units and separate physics, Csound and Ear evidence. - **"Put this live score in First Hearing."** Hand off to the [Linotype collaboration contract](references/linotype-handoff.md). Its measured book page may embed a sourced Stage projection without publishing an unadmitted live run or inventing a second Stage engine. ## Non-negotiable distinctions - **Scenario is not instrument.** **Csound engine is not Sing.** **MIDI-CI informs routing but does not compose it.** **PCM is not UMP.** The model performs the semantic composition and resolves the supported routing; the writer supplies musical intent. - **Teatro Stage is not Linotype page composition.** A static score may be a downstream Linotype leaf, never the authority for live Scenario behavior. - **Draft vs validated candidate vs admitted Scenario vs real run vs observed output vs published edition** are different states with different receipts. - Do not expand the writer's goal into new authorization, DNS, CI, infrastructure, inference or stage primitives without a demonstrated need under the FCIS four-question test.