midi2-gpu-fabric.git · PLANS.md

revision 1133a0ddcb2a0278bcf787067fd5488ec9571ef3 · bounded preview

# PLANS.md

## Local bounded fix — native localhost estate interlink projection (2026-09-02)

**Capability.** The writer-facing native localhost estate preview keeps navigation between all six admitted Fountain
Coach domains inside one inspectable mirror, while production HTML retains its canonical HTTPS links.

**Acceptance proof.** Build the Swift `ReframeEstatePreview` product; project the reviewed site into one named local
directory per admitted host; verify the projection rewrites only admitted sibling-domain `href` values to the local
`/__reframe_estate/<host>/` namespace, leaves external source links unchanged, and starts with
`swift-preview-ready=true`. Follow the root projection in the browser and stop.

**Status.** Implementation is bounded to `ReframeSemanticBrowserPreviewHost.startEstate` and the existing host
projection utility. The Store snapshot remains the preview record; the disposable filesystem projection is only the
Swift preview server's serving surface. Production canonical links, DNS, HTTPS, and remote Store publication are
unchanged and deferred to the publication proof.

## Current scenario phase — expose the estate journey to AX (2026-09-02)

**Scenario.** `rspc_7f39c8e2a4b14d8f` — Observe the Fountain Coach estate as one continuous reality.

**Observed gap.** The rendered WebKit projection was published as a generic AX group, so its admitted headings and
links were visually present but unavailable to the declared `press-title` actions.

**Bounded change.** Preserve `WKWebView`'s native accessibility role and descendants in
`ReframeWebKitSourceProjectionView`; do not add a second navigation authority or change the scenario contract.

**Acceptance proof.** Build the current Swift `ReframeApp`, launch the existing scenario through `ReframeLaunch` with
`auto` MIDI2 ports and a fresh managed Store, admit the window on the external display, execute the scenario once with
the Swift work-session runner, and require all six named estate links/headings plus matching MIDI2, AX, window-ID, and
Store terminal evidence.

**Status.** COMPLETE for this bounded projection slice. The fresh rerun passed all six named AX link/headings,
MIDI2 discovery/admission/terminal evidence, Store read-back, window-ID capture, and predicate reconciliation. No
publication or estate mutation is part of this slice.

## Current implementation program — Chapters 120–125 (2026-09-01)

**Capability.** Complete the governed path from a writer's intention, through a triadic Composer dialogue and
reasoning-legible commands, to a deterministic semantic State A → State B, a selected-route publication, and only
then its visible WebKit transition.

**Program-level acceptance proof.** One correlated run will: negotiate the three participants through MIDI-CI; let
Reframe expose and explain an existing command declaration; select and invoke one admitted instrument; persist the
approved State B, semantic diff, and predecessor; route-publish only the selected destination bundle with remote
Store read-back and public digest proof; and, where a transition is requested, expose its MIDI2/AX/FountainStore
settlement separately. Each step retains its own authority; no screenshot, process exit, or HTTP response substitutes
for another step's proof.

**Chapters read — phase A.** 07 (phase-sized plans and replacement proof), 08 (separate evidence authorities), 120
(triadic roles and Composer mediation), 121 (generic discovery plus Factory admission), and 122 (deterministic
semantic State A → B). Phase B separately read 07/08, 123 (complete reasoning declarations), 124 (timed visual
transition contract), and 125 (Store graph and atomic route promotion); the split preserves the five-chapter reading
cap.

**What they forbid here.** A new command language, per-instrument Reframe switches, a model-written State B, an
animation standing in for a semantic mutation, whole-estate transfer for a selected route, filesystem/Caddy/Python/
Node publication, or treating a reachable URL as a Store promotion proof.

**Conflicts.** None in doctrine. The current code is ahead of Chapters 120 and 122 in places, while Chapters 122,
124, and 125 explicitly describe unaccepted or unimplemented boundaries. Code is recorded as current capability;
chapter claims remain acceptance targets until the named proof exists.

**Excluded, and why.** Whole-estate refactoring, domain retirement/redirects, production DNS/TLS mutation, and a
full live-drive matrix are excluded from the first slice. They require the prior typed command, instrument, State B,
and route-mapping proofs; doing them now would conflate authorities.

**History and current status.** Chapter 120 has committed Composer/MIDI-CI identity, speaker-provenance, and
turn-signal work (`693c5afd`, `90d1b64c`, `4205227e`, `9b865246`, `b0aad53b`), with its bounded triadic entrance
proof complete. Chapter 121 has an FCIS-KIT Factory plan validator and an estate-pipeline declaration. Its typed
admission handoff, Store-backed profile discovery, declared generic host binding, and fixture-backed live execution
proof are complete without a Reframe per-instrument switch.
Chapter 122 has a committed named FCIS-KIT transformer plus MIDI2 ingress, Store persistence, and browser projection
(`740b607f`, `ce826065`, `bf965af0`, `11c69542`, `a3911945`, `0f241d5f`), and its live executable scenario now
proves the declared frontispiece reordering as a semantic State A → State B preview. Chapter 123 has a conformance
document
and command-discovery instrument, but the current implementation upgrades `/commands` specifically while other
catalogue entries still carry missing declaration fields. Chapter 124 is a governance/specification asset only;
there is no transition executor, slot registry, timeline, or acceptance matrix. Chapter 125 has a native,
route-scoped Store-to-Store bundle/index/sync seam, including selected-file read-back, but no cross-domain mapping,
host-bound metadata rewriter, or atomic destination promotion.

**Priority and dependency order.**

1. **Chapter 120 — triadic entrance. COMPLETE.** The bounded Composer exchange established negotiated identities,
distinct Codex/Reframe speaker provenance, return-turn signal, and Store terminal evidence.
2. **Chapter 123 — make `estate.publication.sync` self-describing. COMPLETE.** The existing route-scoped operation
now has one typed declaration projected consistently through `/commands`, Composer, and MIDI-CI.
3. **Chapter 121 — complete generic admission and discovery. COMPLETE for the bounded generic instrument seam.** The
Factory admission record, generic host binding, and fresh fixture-backed MIDI2/Store execution proof now pass.
4. **Chapter 122 — semantic State A → State B preview. COMPLETE for the bounded preview capability.** The existing
executable scenario now applies the already-governed frontispiece order, persists the semantic diff, and visibly
reorders the MIDI2 and Instruments pages. The result remains non-publishable until a separate approval step.
5. **Implement Chapter 125 — map and promote one route.** Build `route.mapping.preview` then approved
`route.mapping.commit`: source/destination identities, deterministic host-bound metadata rewrite or conflict,
new State B revision, route-index evidence, selected-route remote patch, and read-back. Source retirement remains
separate.
6. **Implement Chapter 124 — render the already-established change.** Add only the discoverable slots required by
the mapped route, correlated timeline and Teatro plan, WebKit application, reduced-motion path, pointer custody,
and live matrix. This is last because motion must never be used to manufacture semantic or publication truth.

**Historical implementation record.** Chapter 123 was the first bounded implementation slice for the already-existing
`estate.publication.sync` operation.
Its implementation must not alter publication behavior or credentials: it only makes the real operation sufficiently
legible for Composer/Codex to select it safely, with one source declaration and projections validated against it.
Run focused Swift tests and generated-contract verification; live drive is excluded because this slice changes only
the declarative command surface, not Reframe's renderer or execution semantics.

**Fixture-backed generic execution proof (2026-09-02).** The previous live drive reached `swift_ready=true`, external
display admission, and MIDI2 discovery, but stopped before execution because the fresh managed Store contained no
`instrument-factory:admission:` record. The bounded repair added a typed `managed-store-admission-seed` setup entry
to the existing `scenario-runtime-midi2` contract. Preparation now constructs and persists one admitted
`MaintenanceInstrumentFactoryAdmissionRecord` with the declared `reframe.fixture.store-receipt` binding, reads it
back through the native Store client, and includes that proof in the preparation artifact. The scenario's terminal
predicate observes the generic operation's Store-backed `succeeded` lifecycle; independent evidence decodes the
matching `instrument-factory:execution:<executionID>` receipt and compares its instrument, operation, binding,
correlation, source revision, and digest. The fresh proof is recorded in the current Chapter 121 phase below.

**Finite acceptance proof (completed).** Build the three Swift products from the current manifest; prepare a fresh Store with
`scenario-validation: PASS`, `scenario-preparation: COMPLETE`, and typed admission read-back; launch once through
`ReframeLaunch` with `swift_ready=true` and `auto` MIDI2 ports; verify the same PID, executable, managed Store, and
source revision on the external-display AX witness; execute the existing scenario once through `ReframePeer`;
observe MIDI2 discovery/admitted/running/succeeded events; read the generic execution receipt from the same Store;
and stop. If any one authority is missing, report `BLOCKED` at that seam and preserve the run bundle. No domain
publication, whole-estate sync, or scenario-status promotion is part of this proof.

**Completed proof (2026-09-01).** The existing `/maintenance estate sync` command now has one typed declaration
owned by the existing command-discovery MIDI2 instrument. The declaration names the existing
`estate.publication.sync` operation, grammar, inputs, preconditions, strict Store-only mutation boundary,
SecretStore/confirmation boundary, lifecycle, terminal predicates, and evidence addresses. `/commands` and the
Composer consume that same catalogue entry; the existing MIDI-CI Property Exchange now exposes the identical typed
array at `midi-ci/property-exchange/command-declarations`. Focused evidence: 9/9
`CommandDiscoveryCapabilityTests` and 18/18 `ExternalMIDI2ContractTests` passed, including the Property Exchange
decode/equality assertion; `git diff --check` and `verify-dependency-coherence` passed. No schema, IDL, roles, or
generated-contract inputs changed, so regeneration was not applicable. No live drive was claimed: this slice does
not change Reframe rendering or operation execution. Deferred: every other command remains an explicit
status-quo gap until it receives its own authoritative declaration.

**Chapter 120 live-gate reading record (2026-09-01).** Chapters read — 07 (planning/evidence record and Copilot
entry discovery), 08 (same-PID AX, window-ID, and Store authorities), 120 (distinct user-intention, companion, and
Reframe roles; Composer is transport rather than a second router), and 123 (MIDI-CI identity before Composer,
current command surface before operational selection, and turn ownership). What they forbid here — driving Composer
with AX text injection, transcript-role guessing, numeric-port scenario input, a shell launcher, or a terminal claim
without the same correlation in MIDI2 and FountainStore. Conflict — none: the fixed `Codex / companion agent /
codex.peer / reasoning` ingress identity is the current admission binding, while Chapter 120 keeps the companion role
replaceable through a future admitted binding. Excluded — estate publication itself and any semantic mutation; this
gate proves only the triadic dialogue entrance.

**Chapter 120 gate result (2026-09-01).** **COMPLETE for the bounded entrance proof.** Existing scenario contract:
`commands-discover` (used for the fresh managed Store preparation); Composer request: `/commands`. Swift launch
readiness was observed in `/tmp/reframe-swift-launch-15601.json`: launcher PID `15601`, Reframe PID `15610`,
Store `/private/tmp/reframe-ch120-triadic.UBQYRM/store.fountainstore`, source
`769011105f93dc30aca6cd8033d764c9dbac307e`, target port `63798`, peer port `54838`, `state=ready`. External-display
admission was observed as `verified: true`, fullscreen, CoreGraphics window ID `8601`. The Composer peer completed
MIDI-CI discovery, profile exchange, dialogue-participant exchange (`User`, `Codex`, `Reframe`), SecretStore state
exchange, and process inquiry, then sent one Composer request as `fountaincoach.codex@0.2.3`. MIDI2 correlation
`338DE25D-39F7-4A19-B294-B1679ECE6BE8` persisted `admitted → running → succeeded` and returned the turn to
`user.intent`. AX observation for PID `15610` / window `8601` showed `Codex: /commands` and
`Reframe: Commands — current local catalog`; Store documents `chat:managed-fixture:round:1` and
`midi2:operation:managed-fixture:338DE25D-39F7-4A19-B294-B1679ECE6BE8` were read back with the same provenance.
The window-ID capture is `/private/tmp/reframe-ch120-triadic.UBQYRM/evidence/triadic-commands.png` with its JSON
sidecar. No publication or estate mutation was attempted. The prior stale run was closed by its known launcher
and child PIDs; the temporary Store and visual evidence remain preserved.

## Completed bounded phase — Chapter 121 admission and generic discovery handoff

**Capability.** Make a fully evidenced FountainCoachMaintenanceKit factory result consumable by Reframe's existing
generic MIDI2 discovery and local instrument-selection paths, without adding a per-instrument dispatch switch.

**Acceptance proof.** An admission record can be constructed only from a plan member whose result is `.admitted`,
has a non-empty artifact digest, and carries non-empty evidence. The record must round-trip as typed Swift data. The
Reframe MIDI-CI declaration must identify the Instrument Factory, and both external discovery and local selection
must read the admitted profile from the Store admission prefix. Incomplete, built-only, or unevidenced results must
remain undiscoverable.

**Necessary implementation.** `MaintenanceInstrumentFactoryAdmissionRecord` is the typed Kit-owned handoff. The
Reframe adapter advertises `fountaincoach.instrument-factory@1.0.0`, exposes it during MIDI-CI profile inquiry and
discovery, and reads only evidenced `instrument-factory:admission:` records beside existing scenario facades. The
same admission records now participate in Reframe's local registered-profile selection. No new command language,
OpenAPI route, numeric MIDI port, Python/Node runtime, or per-instrument Reframe switch was added.

**Verification (2026-09-01).** **COMPLETE for admission and discovery.** FountainCoachMaintenanceKit: 29/29 tests
passed. Modernization Studio focused suites: 9/9 `CommandDiscoveryCapabilityTests` and 19/19
`ExternalMIDI2ContractTests` passed (28/28 total). `git diff --check`, `verify-dependency-coherence`, and
`verify-reader-ui-surface.sh` passed. The built Reframe executable was coherent with source revision
`769011105f93dc30aca6cd8033d764c9dbac307e`. No live drive was claimed: this slice changes typed admission and
discovery, but no concrete factory-produced instrument was built, admitted, and invoked in a fresh Reframe run.

**Completion boundary.** The Swift host binding and generic adapter are implemented, and the fresh Reframe run
contains a concrete admitted fixture record with its correlated MIDI2 terminal event and Store receipt, as recorded
in the Chapter 121 live proof below. The Kit deliberately keeps compilation, artifact loading, MIDI2 endpoint
routing, Store effects, and host permissions outside the reusable Kit. No domain mutation or publication is implied.

## Current implementation slice — declared FCIS-KIT execution binding (2026-09-01)

**Capability.** Allow a Store-admitted FCIS-KIT instrument to cross Reframe's generic MIDI2 invocation boundary by
using its declared host binding, without adding a Reframe switch for the instrument's identity.

**Acceptance proof.** A typed admission carries a named execution binding. Supported bindings are a finite Swift
vocabulary. Generic ingress selects only live Store admissions whose operation and optional instrument/scenario name
match the request; zero matches remain unresolved and multiple matches fail closed. A selected admission advances
through the shared MIDI2 lifecycle and persists one typed terminal Store receipt containing the admission digest,
evidence, execution identity, and result-evidence digest. A legacy admission with no binding remains readable for audit
but is not discoverable for execution.

**Necessary implementation.** `MaintenanceInstrumentFactoryAdmissionRecord` now carries `executionBinding`; legacy
decoding falls back to an empty, non-executable value. `ReframeAdmittedInstrumentExecutionBinding` defines the
supported host effects (`reframe.scenario-contract-validation` and `reframe.fixture.store-receipt`).
`ReframeExternalMIDI2Adapter` reads factory admissions, resolves them by declared operation/name, emits admitted →
running → succeeded/failed through the existing coordinator and monitor, and writes the typed receipt through the
active native FountainStore client. Unknown bindings, ambiguous matches, missing Store, and failed receipt writes
stop at their concrete boundary.

**Verification (2026-09-01).** **COMPLETE for the implementation and static contract proof.** FountainCoachMaintenanceKit:
29/29 tests passed, including legacy admission non-executability. Modernization Studio:
20/20 `ExternalMIDI2ContractTests` passed, including binding vocabulary and receipt round-trip. The three required
Swift products (`ReframeApp`, `ReframeLaunch`, `ReframeScenarioRunner`) built successfully from the current
manifest. `git diff --check` passed. No Python/Node runtime, OpenAPI route, numeric MIDI port, or per-instrument
switch was introduced.

**Live proof completion (2026-09-02).** **COMPLETE for generic runtime execution.** A fresh Swift
`ReframeScenarioRunner --prepare` produced `scenario-validation: PASS` and `scenario-preparation: COMPLETE`,
including the typed Store-admitted fixture record. `ReframeLaunch` then emitted `swift_ready=true` for launcher PID
`38531`, Reframe PID `38534`, target MIDI2 port `53208`, peer port `54914`, managed Store
`/tmp/reframe-generic-live.QiCoi6/store.fountainstore`, executable from source revision
`9ef8138236992363f5957f8a906238be821fb8a4`. The external-display helper verified `verified: true` and
`fullscreen: true` for CoreGraphics window ID `8969`. `ReframePeer` completed discovery, invoked the admitted
`fountaincoach.scenario-runtime.fixture.execute` operation, and observed the terminal lifecycle through MIDI2.
Typed Store read-back proved the matching receipt
`instrument-factory:execution:midi2-F083AA1A-01ED-4934-94B4-D0A3A58654E2` with status `succeeded`, the same source
revision, execution binding `reframe.fixture.store-receipt`, and result-evidence digest
`b3588fd3ce65b539be075e8febaff46b5f63773eba60e4a3d93af2b8437d9c4d`. AX read-back observed the same generic
operation and succeeded lifecycle on the bound window. This proves generic FCIS-KIT admission and execution only;
it does not claim a domain mutation or publication.

**Governance read record — live proof (2026-09-01).** Chapters read — 07 (authority order, planning, focused
validation); 08 (live-drive identity tuple, AX/window-ID/Store evidence, claim-artifact rule); 121 (generic MIDI2
discovery, declared execution boundary, no per-instrument switch); 112 (kit-owned contract and host-adapter route).
**What they forbid here** — direct app launch, guessed ports or windows, shell/UI substitution, and treating a
scenario facade or running lifecycle as proof of an admitted factory instrument. **Conflicts** — none. **Excluded,
and why** — publication chapters and payload-specific instruments were out of scope for this generic execution proof.

**Live proof attempt (2026-09-01).** The required Swift products and coherence gates passed. `ReframeLaunch` emitted
`swift_ready=true` for launcher PID `27925`, Reframe PID `27927`, target MIDI2 port `51168`, peer port `54345`,
managed Store `/tmp/reframe-live.V6Netk/store.fountainstore`, executable from source `6d72f16a6ee94adcd35510d40e9d40ec72d8d9b1`.
The external-display helper observed `verified: true`, `fullscreen: true`, window ID `8658`; AX observed the same
PID's MIDI2 peer projection and running correlation `midi2-FDCA2A6D-EECC-47B0-BEA0-71DBEB7B0BDC`. Store read-back
found `0 document(s)` for `instrument-factory:` in corpus `reframe-scenario-runtime-fixture`, so the new generic
admitted-instrument invocation and `instrument-factory:execution:<executionID>` receipt were **not established**.
The runner was stopped without relaunch; the preserved isolated run is incomplete evidence, not a success claim.

## Current governance slice — Chapter 125 Store publication graph (2026-09-01)

**Capability.** Write and locally showcase the governance chapter that defines domain-to-domain route mapping as a
FountainStore publication-graph transformation.

**Acceptance proof.** Publication and integration Chapter 125 sources and SVG are text-identical; both reading indexes
name the chapter; a native `ReframeEstatePreview` run materializes the selected site projection into the declared
local Store; and the chapter route is served by the native localhost preview with its illustration and route metadata.
This slice does not claim cross-domain transformation, remote promotion, DNS, or HTTPS acceptance.

**Governance read record.** Chapters 07/08 (bounded proof and separate evidence), 92 (publication graph), 116
(Store-owned route publication), and 122 (semantic State A → State B boundary). Chapter 124 is not required for this
Store-graph slice. The repository's pre-existing docs-sync mismatch is retained and not broadened.

**Scope boundary.** Chapter source, deterministic SVG, retained local route projection, Store-backed local preview, and
focused validation only. Cross-domain mapping and atomic route-promotion instruments remain deferred until separately
implemented and accepted.

**Visual correction evidence (2026-09-01).** Reworked the Chapter 125 illustration so domain names break inside their
cards, arrow captions have a separate padded label band, and the card/graph typography has balanced spacing. Native
preview serves the revised SVG at HTTP 200 and `xmllint` accepts it. The bundled CDP VRT/AX runner could not start its
isolated Chrome (`Dedicated Chrome did not expose CDP`); no screenshot claim is made.

## Current implementation slice — Chapter 125 route mapping preview (2026-09-02)

**Capability.** Preview one declared route transformation from a current Store publication graph without mutating the
source snapshot or contacting a remote Store.

**Acceptance proof.** A typed `route.identity-preserving-host-move` request must resolve an admitted source route and
destination domain, select the route bundle and its declared same-site dependencies, create deterministic destination
file identities and a new State B revision, rewrite host-bound route metadata, report destination collisions, and keep
`publishable` false. The source snapshot and source file identities must remain unchanged.

**Implementation.** `FountainCoachMaintenanceKit` now owns the named `route.mapping.preview` and
`route.mapping.commit` operation identities plus the canonical route-mapping request contract. ReframeCore now owns the
preview transformer; it does not yet promote State B or invoke Store-to-Store publication.

**Validation.** The MaintenanceKit route contract test passed. The focused Reframe route-mapping tests passed after a
fresh Swift rebuild, covering destination path/host rewriting, canonical URL rewriting, collision reporting, and
non-mutation. No live GUI drive or remote publication is claimed because this is a host-side preview boundary with no
user-facing surface change.

**Deferred.** Approved `route.mapping.commit`, destination route-index evidence, selected-route remote patch/read-back,
public DNS/HTTPS digest proof, source retirement, and Chapter 124 visual transition remain separate slices.

## Current implementation slice — route-complete native publication proof (2026-09-01)

**Where Chapter 123 lives.** The authoritative chapter is
`/Volumes/NINJA2/Github-Desktop/Reframe-Refactoring/docs/123-commands-must-be-legible-to-reasoning.md`; its
illustration is `docs/illustrations/123-commands-must-be-legible-to-reasoning.svg`, and its published-site source
is `site/chapters/123-commands-must-be-legible-to-reasoning/index.html`. The maintained integration copy is under
`apps/modernization-studio/docs/reframe-grounding-first-refactor/`.

**Goal.** Make the existing Swift `estate.publication.sync` path a robust, route-scoped publisher: a named route
must carry its complete selected projection, prove every selected public file, and leave the remote Store's prior
current snapshot intact until the typed route patch is admitted.

**Acceptance proof.** A pure Swift route-bundle selector includes the requested route subtree plus declared
same-site HTML dependencies; the local Store persists a revision-bound route index; the native Reframe Store
instrument reads only that indexed bundle; the native route-patch write transfers only that selected bundle; the
public projection verifier checks every selected file rather than silently checking only HTML; route-patch tests prove
stale-revision rejection and complete selected-file read-back; the focused Swift builds/tests pass. A remote
production publication is not claimed unless its correlated Store receipt also proves remote readiness, atomic
current, HTTPS, DNS, and matching digests.

**Governance read record.** Chapters 07/08 (bounded proof and separate evidence authorities), 116 (native
FountainStore route publication), and 123 (live command declarations and grounded selection). The existing
`FountainCoachMaintenanceKit` `estate.publication.sync` instrument remains the sole publication authority.

**Deferred.** Host-agent process supervision and public DNS/HTTPS are separate infrastructure gates; they cannot be
proven by local unit tests or replaced with a file copy, generic HTTP wrapper, shell launcher, Python, or Node. A
route without a current, matching index remains blocked rather than falling back to a full-estate read.

## Current planned phase — Chapter 124 MIDI2-timed WebKit transitions

This governance slice defines the complete visual capability contract for semantic State A → State B transitions:
WebKit remains the full web renderer, MIDI2 discovers and schedules independently addressable slots, and Teatro plans
the motion. It claims no slot executor, WebKit adapter, live animation, or site publication.

**Governance read record:** Chapters 07/08 (bounded proof and evidence); 92 (publication shell); 101 (Teatro stage
boundary); 104 (event time and jitter); 106 (Teatro runtime projection); and 122 (semantic transformation).

**Acceptance proof:** source and integration Chapter 124 plus its SVG illustration and reading-index entry are
text-identical; relative links and `git diff --check` pass. Runtime implementation and live acceptance are deferred.

**Publication result (2026-09-01):** The native Swift `ReframeEstatePreview` materialized the reviewed Chapter 124
projection into the intact declared Store at `/Volumes/NINJA2/FountainStore/.fountainstore`, after its Store authority
was initialized through `ReframeStoreDump` (the stale managed-default path remained unusable because its referenced
`.sst` table is missing). `ReframeEstateSync` then transferred only
`/chapters/124-midi2-timed-webkit-transitions/` to `https://store.fountain.coach` and returned `COMPLETE` with
revision `chapter-124-1e0bc98`, source revision `1e0bc98376dd28f391b35e90fe7ceb76cee8466d`, remote/read-back status
200, and content digest `sha256:375b117dab6813a0a4a829620865222f12d7620be79210f7995c06b76437d985`. Public projection proof
resolved `https://governance.fountain.coach/chapters/124-midi2-timed-webkit-transitions/index.html` with DNS/HTTPS
status 200 and matching digest evidence.

## Current governance slice — bounded FountainStore route publication (2026-08-31)

**Goal.** Make the successful Chapter 122 publication path the immediate governed default for every bounded Fountain
Coach page, chapter, or domain-route publication.

**Acceptance proof.** Chapter 116 and its integration copy define host-and-path route patches, explicit whole-estate
intent, preflight admission, and terminal digest proof; root `AGENTS.md` routes bounded requests to the existing Swift
`ReframeEstateSync` adapter; the publication-estate procedure carries the exact native inputs and stopping condition;
the two Chapter 116 copies are byte-identical; documentation and skill validation pass.

**Chapters read.** 07 (bounded planning and source authority), 08 (separate evidence authorities), 116 (Store-owned
publication and native edge), and 122 only to preserve its semantic-transformer/deployment separation.

**What they forbid here.** Whole-estate transfer for one route, generic HTTP or filesystem deployment, Caddy, a site
generator, Python/Node runtime publication, overlapping credential prompts, or an HTTP response presented as Store
publication proof.

**Direction and boundary.** Chapter 116 publication source `Reframe-Refactoring@110d5a7` → exact integration copy.
Chapter 122 and runtime behavior remain unchanged; this slice records the already-proven native route path rather
than inventing another mechanism.

## Current implementation slice — FCIS-KIT remote FountainStore credential handoff (2026-08-31)

**Goal.** Extend the existing `fountainstore.credential.provision` instrument with a host-owned remote handoff
boundary so the local SecretStore credential can be placed in the remote FountainStore host SecretStore without
appearing in MIDI2, Codable requests, receipts, telemetry, logs, or Git.

**Acceptance proof.** The FCIS-KIT contract names a versioned remote operation and two explicit SecretStore
references; a host-owned transport receives the credential only as an in-memory argument; the adapter returns a
terminal redacted receipt; the scenario declares exact-target, expiry, idempotency, fingerprint, and value-redaction
predicates; and the focused FCIS-KIT Swift tests pass. This slice does not claim that the production host agent
implements the transport or that Chapter 122 is published.

**Chapters read** — 07 bounded implementation and STOP discipline; 08 evidence ownership; 91 FCIS-KIT capability
plane; 94 credential custody and host handoff; 97 enrolled host-agent boundary; 122 semantic transformation claim
boundary.

**What they forbid here** — credential values in MIDI2 or serialized state, direct HTTP/shell publication, silent
rotation, provider-token substitution, and claiming a real remote handoff from a fixture transport.

**Implementation boundary.** The reusable Swift URLSession transport now lives in the standalone
`FountainStoreHostEnrollmentKit`; it requires an explicitly admitted HTTPS endpoint and keeps both credentials
outside the typed request. The deployed FountainStore HostAgent still does not expose or advertise the matching
remote credential-provision operation, so live production acceptance remains a separate host-agent/server slice.

## Current implementation slice — bounded remote Store publication transport (2026-08-31)

**Goal.** Ensure `estate.publication.sync` cannot remain indefinitely suspended when the authenticated remote
FountainStore does not produce a response.

**Acceptance proof.** The Swift URLSession transport applies a transport-only timeout to GET and PUT, maps a timed
out request to a typed terminal error, the focused transport test passes, and one Chapter-122 publication retry
returns a terminal Store receipt or a concrete bounded failure. No semantic content is selected by byte/token size.

**Chapters read** — 07 bounded implementation and STOP discipline; 08 terminal evidence and separate Store/HTTP
authorities; Chapter 116 Store-to-Store publication authority; Chapter 122 semantic transformation boundary.

**What they forbid here** — an unbounded remote wait, a generic publication fallback, filesystem/Caddy deployment,
or treating process activity as publication evidence.

**Conflicts** — none.

**Excluded, and why** — remote service restart, DNS changes, credential rotation, and cleanup outside the bounded
Swift transport are unrelated to this proof.

## Current implementation slice — FountainStore credential provisioning instrument (2026-08-31)

**Goal.** Provide the missing typed Swift boundary for creating the FountainStore API credential required by
`estate.publication.sync`, without putting the credential value into MIDI2, Composer, receipts, logs, Git, or public
artifacts.

**Acceptance proof.** The org-owned `FountainStoreHostEnrollmentKit` publishes the stable
`fountainstore.credential.provision` instrument identity, versioned typed contract, checked scenario, and redaction
test; Reframe consumes that released contract and supplies only the SecretStore host adapter; the adapter creates
and stores a random credential only when the named account is absent; it returns only a SHA-256 fingerprint and
redacted evidence; an existing credential is refused for explicit-rotation-only handling; focused Swift tests and
the Reframe product compile pass.

**Chapters read** — 07 planning discipline and evidence ownership; 08 validation and acceptance; Chapter 91
instrument capability-plane boundaries; Chapter 94 credential custody and provider adapters; Chapter 97 host
enrollment; Chapter 122 semantic transformation boundary.

**What they forbid here** — Hetzner Cloud tokens substituted for a FountainStore API key, credential values in
Composer/MIDI2/Store/logs, silent rotation, environment-variable fallback, and claiming remote provisioning from a
local-only adapter.

**Conflicts** — none. The existing HostAgent `rotate` lifecycle remains distinct. The reusable instrument contract
now lives in the org-owned FCIS-KIT package; the Reframe-side types are aliases only and cannot become a second
instrument authority.

**Excluded, and why** — remote server-side provisioning and one-time secure handoff remain unestablished because
the deployed FountainStore HostAgent currently has no credential-provision operation. The FCIS-KIT contract is
released at `0.1.3`; Reframe consumption and remote publication remain separate evidence gates.

## Current implementation slice — Composer triadic identity and terminal turn (2026-08-31)

**Goal.** Ensure an externally submitted Composer `/commands` turn is visibly and semantically triadic: the
Composer peer is `Codex`, the runtime reply is `Reframe`, and the MIDI2 peer receives its terminal turn signal only
after the reply has been rendered and persisted.

**Acceptance proof.** The existing `/commands` shortcut receives the negotiated dialogue participants, stores the
user-role message with the Codex companion identity, stores the reply with the Reframe runtime identity, invokes the
existing external turn-return callback exactly after the reply, and the focused Swift tests/build pass. No remote
publication is claimed by this slice.

**Chapters read** — 07 planning discipline and evidence ownership; 08 live-drive evidence and terminal predicates;
Chapter 120 triadic dialogue; Chapter 121 MIDI2 instrument identity; Chapter 122 governed transformation boundary.

**What they forbid here** — generic `You` labels for a Codex Composer turn, AX or prose used as the transport,
premature MIDI2 completion, and any guessed remote publication endpoint.

**Conflicts** — none. The existing slash grammar remains authoritative; this change only carries its already
negotiated participants and terminal callback through the existing shortcut seam.

**Excluded, and why** — remote publication remains excluded because the canonical authenticated FountainStore
endpoint was not present in the verified launch configuration; no URL or web response is being promoted to Store
authority.

## Current implementation slice — MIDI2 turn signal drives Composer UI (2026-08-31)

Goal: make the writer-facing Composer control reflect the negotiated talk-master signal, so the UI says `Running` while another peer owns the turn and shows only the send arrow when the writer's turn is returned.

Acceptance proof: the external Composer ingress publishes a valid `ReframeDialogueTurnSignal` for the running Codex turn and the returned writer turn; `StudioChatPanel` derives its button label, enabled state, and AX value from that signal; focused Swift tests pass and the deprecated reader-surface check remains green.

Scope: publish the signal through the existing MainActor ReframeViewModel seam and consume it in the existing Composer control. No new command, transport, peer, polling loop, or inferred identity.

Readings: root `AGENTS.md`; Governance Chapters 120–122; `ReframeDialogueParticipants`; `ReframeExternalMIDI2Contract`; the existing Composer adapter and panel tests.

Forbids: pixel-driven interaction, guessed peer state, model/prose-based turn detection, Python/Node runtime paths, and unrelated UI or protocol changes.

Deferred: independent live-drive evidence on the attached display; this bounded code/test slice does not claim that GUI acceptance.

## Current implementation slice — Composer turn-state control (2026-08-31)

**Goal.** Make the writer-facing Composer control express MIDI2-mediated turn ownership: `Running` while Reframe
holds the turn, and a compact upward arrow only when the writer may speak.

**Acceptance proof.** With `model.isSending == true`, the existing Composer control renders the accessible label and
visible text `Running`, is not submit-capable, and exposes AX value `Running`. With `model.isSending == false`, a
sendable writer turn renders `arrow.up` (not a paper-plane icon), submits through the existing Composer/MIDI2 path,
and an empty or blocked turn renders no send arrow. Focused UI tests and the required Swift surface checks pass.

**Scope.** Studio Composer control only; reuse the existing governed `isSending` lifecycle and AX identifier. No new
transport, peer registry, or command language. Additional participant admission is deferred to a separate MIDI2
moderation slice.

**Readings.** Root Agent Guide; Modernization Studio Agent Guide; Chapter 120 triadic dialogue; Chapter 121 dynamic
MIDI2 instrument factory; Chapter 122 governed semantic transformation instrument.

**Forbids.** The control must not infer turn ownership from text, timing, screenshots, or a second local boolean;
the UI must not label the writer as `You` for an in-flight Composer turn.

## Current implementation slice — MIDI-CI triad identity before Composer traffic (2026-08-31)

**Goal.** Make the beginning of every Codex/Reframe exchange a standard MIDI-CI identity negotiation, so the
user-intention peer, Codex companion peer, and Reframe runtime authority are declared and validated before any
Composer request is sent or rendered.

**Acceptance proof.** Reframe answers standard MIDI-CI discovery, profile inquiry, and Property Exchange for the
typed dialogue-participants resource. `ReframePeer` requests and validates that resource before its custom Composer
discovery or invocation; missing, malformed, collapsed, or non-Codex companion identity fails closed. The visible
Composer user turn is labeled `Codex` and the runtime response `Reframe`, with focused Swift tests and exact product
builds passing.

**Scope.** Existing MIDI-CI adapter, dialogue participant contract, ReframePeer handshake, and the focused chat
speaker rendering test. No new command language, transport, polling, or Store authority.

**Chapters/readings.** Root Agent Guide; Modernization Studio scoped Agent Guide; Chapter 120 internal triadic
dialogue; Chapter 121 dynamic MIDI2 instrument factory; Chapter 122 governed semantic transformation instrument.

**Forbids.** CLI identity fields, UI labels, prose, or custom Composer payloads cannot substitute for the standard
MIDI-CI declaration. Composer traffic cannot begin before the negotiated declaration is validated.

**Deferred observations.** User-intention rebinding remains a later governed session operation; this slice uses the
explicit initial `User` identity and does not invent a second negotiation protocol.

## Current implementation slice — triadic MIDI2 turn ownership (2026-08-31)

**Goal.** Make a Reframe Composer lifecycle terminal only when the visible Reframe reply has been produced and
persisted, so the MIDI2 signal that releases the next participant's turn matches the writer-facing dialogue state.

**Acceptance proof.** A Composer request emits `admitted → running`, then waits for Reframe's mediated turn to return;
only after the response path completes does it emit one correlated terminal `succeeded` event with a
`turn-returned` capability phase. A rejected/failed response emits a correlated terminal failure. `ReframePeer`
must remain blocked until that terminal event, and focused tests must guard the callback ordering.

**Scope.** Reframe Composer ingress, the existing `sendMessage` async turn boundary, the MIDI2 lifecycle projection,
and focused tests. No new command, transport, Store authority, polling loop, or UI-side turn coordinator.

**Chapters read** — 07 planning discipline and evidence ownership; 08 live-drive evidence and artifact-bound claims;
73 rules 5–10 (ordered prerequisites, authority, and independent evidence); 75 rules 1–4 and 8–11 (one run owner,
event-driven waits, terminal predicates, and no ad-hoc polling); Chapter 120 triadic dialogue boundary.

**What they forbid here** — treating Composer submission acknowledgement as a completed Reframe reply, polling the
Store to guess that a turn returned, or allowing Codex to advance the dialogue without a correlated MIDI2 terminal
signal.

**Conflicts** — none. The existing Composer transport remains the ingress; this slice changes only the meaning of
its terminal lifecycle event to agree with the already-existing visible response boundary.

**Excluded, and why** — publication execution is not part of this protocol fix; its existing Reframe command and
Store proof remain unchanged. Full live acceptance follows after focused validation.

**Validation result.** Swift build and `ExternalMIDI2ContractTests` passed. Fresh triadic live drive used
`ReframeLaunch` with `swift_ready=true`, external-display AX admission `verified: true`, and distinct auto-allocated
MIDI2 ports. Composer lifecycle remained `admitted → running` for the duration of the mediated turn, then emitted
`succeeded` only after the response was persisted in `chat:managed-fixture:round:1`; the terminal summary was
“Reframe returned the mediated response; the next triadic participant may speak.” The same run was closed through
`reframe.session.terminate`. The prior premature-submission behavior is no longer the live terminal boundary.

**Command-surface consequence.** The response-owned terminal event now carries the completed Composer response as
`dialogueResponse`, so a MIDI2 peer can reason over the live `/commands` result without reading source code or
polling Store state. The command-selection gate remains procedural: an operational drive must first send `/commands`,
read that response, and only then send an existing command or the declared `/confirm` grammar.

## Proof-Bounded Development adoption (2026-08-31)

**Goal.** Make finite acceptance proof, minimal implementation, verification, and STOP the default workflow for this
repository's implementation agents.

**Acceptance proof.** The repository defines PBD; root and Modernization Studio instructions require proof before
substantial work; scope expansion is limited to proof-required work or proof-invalidating defects; agents must stop
when proof passes; reports distinguish `COMPLETE` from a concrete `BLOCKED` condition; documentation validation passes;
and no unrelated runtime architecture is changed.

**Implementation.** The definition lives in `docs/proof-bounded-development.md` and is binding through the root and
scoped `AGENTS.md` files. This plan entry is the evidence record for the change. It does not alter Reframe runtime,
MIDI2 contracts, Store schemas, or publication behavior.

**Stop condition.** Once the documentation checks pass and the worktree is clean, this bounded task is complete.

## Current implementation slice — Store-owned public estate publication (2026-08-31)

**Goal.** Make `estate.publication.sync` transfer the actual reviewed estate projection from the explicit local
FountainStore to the authenticated remote FountainStore, then establish separately that the native public edge serves
the exact canonical Chapter 122 route. A sync receipt must no longer be able to succeed when the remote Store has only
a manifest pointing at the local machine.

**Scope.** Define the typed remote publication projection, its asset/content identity, idempotent Store-to-Store
transfer, remote typed read-back, and a Swift-hosted public DNS/HTTPS verification result for
`governance.fountain.coach`. The affected identities are the local estate snapshot, its `governance.fountain.coach`
record, the remote `estate.publication-snapshots` projection, and the native FountainStore edge.

**Non-goals.** This does not mutate DNS, certificates, a web-server configuration, or a filesystem deployment root;
it does not use a shell script, Python, Node, Caddy copy, static-directory deployment, or an untyped HTTP wrapper.
It also does not claim visual/AX acceptance from a transport receipt.

**Migration and risk.** Preserve legacy manifest-only snapshots as readable historical state, but reject their use as
published proof until their content projection is present remotely. The main risk is partial publication, addressed by
content-addressed transfer, remote read-back before promotion, retained predecessor identity, and explicit public-edge
verification.

**Validation.** Focused Swift Kit and ReframeCore tests; FountainStore HTTP tests for typed projection transfer and
edge resolution; verified Swift build; remote Store read-back; Swift DNS plus HTTPS probe of the canonical route. A
public response, Store receipt, and browser/AX evidence remain distinct claims.

- **Chapters read** — 07 planning discipline and replacement-before-deletion; 08 evidence authorities and artifact-bound claims; 92 rules 1–7 (estate contract and exact deployment tuple); 112 typed Kit ownership and no Python runtime; 116 rules 1–8 (Store-owned manifest, typed idempotent sync, separate edge/TLS/DNS witnesses).
- **What they forbid here** — treating a static directory, Caddy copy, shell/Python helper, or a manifest-only remote record as public publication; inferring public content from a successful local sync.
- **Conflicts** — the older `governance-book-publish` / `secure-publishing` procedures describe generator/script/Caddy deployment, while root `AGENTS.md` and the writer require Store-to-Store `estate.publication.sync`; the latter controls this implementation. `fountain-coach-publication-estate` names a Python validator as an optional non-runtime gate, but the writer has prohibited Python for this work, so it is excluded rather than substituted for Swift-native proof.
- **Live command routing** — the generated registry exposes `/maintenance estate preview` and `/maintenance estate sync`, but the live `/commands` index omitted both entries. The local index is being aligned with those declared commands; this is a declaration-to-route defect, not a new command or a new publication path.
- **Preview performance finding** — the first live preview remained non-terminal while encoding the complete six-host estate into one generic JSON payload; the second reached all file records but did not close its single oversized Store transaction. The native Store bridge now passes the same `EstatePublicationFile` records as typed Swift values and commits them in bounded 64-record Store batches before the manifest. The JSON encoding path remains only for transport-compatible callers; no publication authority or manifest-last rule changes.
- **Excluded, and why** — DNS-provider and certificate mutation are separate explicitly authorized operations; this slice makes the Store projection and its public read-back truthful first.

## Maintained estate refactoring plan — scenario sequence (2026-08-29)

This is the canonical human-facing sequence for refactoring the Fountain Coach publication estate. The 18 existing
estate contracts in `apps/modernization-studio/LiveScenarios/Contracts/` are the work items; they are not replaced by
the unrelated runtime, MIDI2, measurement, or Teatro capability scenarios. Each estate scenario is handled one at a
time: resolve the existing contract through Copilot, confirm its meaning, materialize its YAML executable projection,
implement the bounded source slice, validate it, live-drive it through Swift Reframe and AX, read the matching
FountainStore evidence, and record observed, inferred, and not-established results. Candidate status is never silently
elevated by technical execution.

### Phase A — establish the intended experience

- **Desired cross-estate visitor journey** — establish what a first-time visitor should understand across Fountain
Coach, Book, Governance, Instruments, MIDI2, and Status.
- **Estate redesign scope boundary** — state what the redesign is for and what it explicitly does not change.
- **Estate redesign implementation sequence** — agree the human reasoning order for inventory, vocabulary, shared
system, frontispiece, reference domain, navigation, evidence, and generated state.

### Phase B — establish the shared publication frame

- **Publication-estate Semantic Browser preview** — make the current estate visible as the baseline.
- **Common publication shell** — establish the recognizable institutional frame shared by every domain.
- **Distinct editorial lenses** — preserve the different purposes of Book, Governance, MIDI2, Instruments, and Status.
- **Three-layer publication architecture** — separate Publication Core, Domain Projections, and authoritative Evidence
and Publication Data.
- **Shared publication layer** — apply shared identity, metadata, state, provenance, AX semantics, and print behavior.

### Phase C — make evidence and certainty readable

- **Shared evidence grammar** — make PROPOSED, IMPLEMENTED, OBSERVED, ACCEPTED, and RELEASED distinct and traceable.
- **Scenario mediation and certainty metadata** — expose authority, source, evidence, release, and provenance without
making Governance the default landing page.
- **Estate evidence navigation** — let a visitor distinguish scenarios, evidence, releases, and product promises.
- **Semantic Browser evidence-cohort navigation** — follow one evidence cohort across its related projections without
strengthening claims through navigation.

### Phase D — shape the public entry and domain expression

- **Estate frontispiece projection** — make `fountain.coach` the truthful map of the estate.
- **Mirrored human/AI readability** — keep human-visible publication and Semantic Browser relationships equivalent.
- **Claim-boundary-preserving redesign** — ensure visual improvements never make proposals look accepted or released.
- **Teatro publication diagram language** — use spatial arrangement only where it clarifies the system.
- **Unified visual character** — develop the institutional editorial character without generic SaaS styling.

### Phase E — evaluate the complete result

- **Estate redesign acceptance criteria** — evaluate the complete result from both visitor and machine-reader
perspectives, including authority, provenance, structural parity, readability, and claim boundaries.

### Current position and next action

The estate is currently observable through the existing executable scenario **Observe the Fountain Coach estate as one
continuous reality**, and the local/page Semantic Browser projections have independent accepted evidence. The 18 estate
contracts are stages in one serial refactoring pipeline, analogous to the governed Storify Source Auto pipeline. The
next work item is the pipeline entry for **Publication-estate Semantic Browser preview**: admit the existing proposal
once, bind its source identity, expose the ordered estate stages, and advance only when each stage consumes the prior
stage's persisted result. Individual stages still receive their own AX, window-ID, MIDI2, Store, and provenance
evidence, but materialization and sequencing are not repeated 18 times. The plan advances only when the pipeline's
human-facing result and evidence agree.

**Serial pipeline coordinator foundation implemented** — `FountainCoachMaintenanceKit` now defines the single
`estate.refactoring-pipeline` operation, human-readable estate stages, shared proposal identity, FountainStore-bound
pipeline requests, and a monotonic resumable stage ledger. `ReframeSkillKit` exposes the matching governed skill.
Focused kit tests and the Modernization Studio build pass. Copilot command wiring and the 18-stage runtime executor
remain the next bounded source slice; this foundation deliberately does not claim that the full pipeline has run.

### Current implementation slice — named pipeline creation

- **Chapters read** — 07 planning discipline and one-run accountability; 08 terminal evidence and independent proof;
73 rule 9 (resolve → validate → execute → witness → reconcile); 75 rules 1, 5, 8, and 11 (owned binding,
observation-only witness, terminal predicates, runner ownership); 77 rules 1–6 (Swift executor, typed MIDI2,
Store evidence, and no shell runtime).
- **What they forbid here** — creating a second scenario, silently promoting a semantic contract to executable, or
making the writer supervise each pipeline stage.
- **Conflicts** — none. The writer-facing `pipeline create` request composes existing named scenarios; governance
still requires explicit confirmation before any separately governed mutation or publication.
- **Excluded, and why** — live acceptance and publication are excluded because this slice defines and persists a
reusable pipeline; execution remains a separate governed `pipeline run` operation.

### Governance alignment — semantic instrument selection and missing-instrument handoff

- **Chapters read** — 07 planning and authority precedence; 08 independent terminal evidence; 91 MIDI2/FCIS-KIT
capability-plane ownership; 93 instrument creation as a separately governed promotion path; 119 pipeline
composition, MIDI2 Function Block discovery, forward references, and human-facing results.
- **What they forbid here** — treating a filename or identifier as the reason for instrument selection, silently
compiling or substituting a missing executor, or presenting pipeline composition as proof that a new instrument is
admitted or released.
- **Conflicts** — the prior Chapter 119 wording rejected unknown references and called a missing executor a bounded
failure, while the implemented contract intentionally persists a readable forward reference plus a typed
missing-instrument request. Chapter 119 is amended to make that distinction normative; Chapter 93 is amended to
remove the stale candidate-status lifecycle.
- **Excluded, and why** — automatic instrument implementation, compilation, admission, release, and live drive remain
separate governed transitions; this change documents the request and handoff boundary created by the pipeline
selector.

### Maintenance rule

After every bounded scenario slice, update this section with the scenario's coverage state, source change, validation,
live evidence binding, Store result, and the next human-facing action. Do not advance by scenario number alone, and do
not substitute a technical capability scenario for an estate scenario.

### Current implementation slice — named pipeline lifecycle (Chapter 119)

- **Chapters read** — 07, 08, 73 rule 9, 75 rules 1, 5, 8, and 11, 77 rules 1–6, and 119 rules 1–8.
- **Implemented boundary** — `FountainCoachMaintenanceKit` now owns a generic typed pipeline ledger and serial,
resumable coordinator. Copilot now exposes `/maintenance pipeline inspect <name>`, `run <name>`, and
`resume <name>` alongside `create`.
- **What this forbids** — implicit scenario authoring, stage-by-stage babysitting, IDs replacing names, and
treating validation or process startup as execution evidence.
- **Proof boundary** — each completed stage records its existing named scenario report and Store-backed transition;
the scenario's own AX/window/MIDI2 claim boundary remains authoritative. Pipeline completion does not claim
publication, release, or estate redesign.
- **Excluded, and why** — a live drive is excluded until a concrete named pipeline definition is present in the
managed Store and the governed ReframeLaunch tuple can bind its stage evidence. The next action is to inspect
and run an existing named pipeline through the live-drive procedure, not to create another scenario.

### Current implementation slice — persisted scenario Function Block discovery (Chapter 119)

- **Chapters read** — 07 planning discipline and one-run accountability; 08 terminal evidence and independent proof;
81 rule 6 (MIDI2 is an ingress/egress projection, not a second semantic authority); 112 rules 1–4 (Swift Kit
ownership and no Python runtime); 119 rules 1–8 (scenario materialization, endpoint topology, and Function Block
composition).
- **What they forbid here** — answering MIDI2 discovery from a static capability census after a scenario has been
materialized, treating a persisted profile as execution proof, or using Flex Data as an untyped scenario transport.
- **Conflicts** — none. The chapter's Function Block topology is implemented as a projection of executable profiles
already admitted by FountainStore; Store remains the authority and the adapter does not compile or execute them.
- **Excluded, and why** — hardware interoperability, full MIDI-CI Property Exchange negotiation, and UMP cohort
replay remain separate acceptance slices; this change only makes the live Reframe endpoint discover its persisted
software Function Blocks.
- **Source slice** — `ReframeExternalMIDI2Adapter` discovery and its focused MIDI2 contract tests. The materialization
command and `FountainCoachMaintenanceKit` profile contract remain unchanged.

### Current implementation slice — automatic scenario Function Block admission (Chapter 119)

- **Chapters read** — 07 planning discipline; 08 terminal evidence; 81 rule 6 (MIDI2 projects the governed
operation); 112 rules 1–4 (Swift Kit ownership); 119 rules 1–8 (one scenario, one named Function Block atom).
- **Implemented boundary** — explicit scenario confirmation now persists the typed MIDI2 Function Block profile in
the same scenario contract projection; live discovery reads that atom alongside legacy facade records.
- **What this forbids** — requiring a second materialization command for a newly admitted scenario, generating a
facade from a pipeline, or treating discovery as scenario execution.
- **Identity** — the scenario's stable contract ID remains authoritative; the human-readable scenario purpose is the
Function Block name, and the declared capability/version is its MIDI2 instrument identity.
- **Excluded, and why** — legacy backfill, hardware interoperability, and full MIDI-CI negotiation remain separate
operational slices; this change closes automatic admission for newly confirmed scenarios.

## Current implementation slice — existing-scenario run command (2026-08-28)

- **Scenario** — invoke an existing checked Reframe scenario through the scenario runtime; no scenario authoring or
compilation.
- **Command boundary** — add `/scenario run <existing-scenario-id>` and bind it to the existing
`reframe/scenario.run` MIDI2 operation, whose typed request requires operation, scenario ID, source commit, Store
intent, corpus, scene, and idempotency key.
- **What this forbids** — routing `run` through `/scenario author`, inventing a scenario contract from prose, or
treating the Semantic Browser preview as a substitute for the scenario runtime.
- **Source slice** — typed command parser, Copilot command dispatch, existing scenario resolution, and the Swift/MIDI2
scenario runtime ingress; preserve the current author/confirm commands unchanged.
- **Proof** — focused parser/dispatch tests, checked scenario resolution, MIDI2 lifecycle and FountainStore scenario
receipt, plus governed AX/window-ID evidence when live-driven.
- **Excluded** — scenario creation, contract compilation, publication, promotion, and changes to existing scenario
contracts.
- **Implementation state** — complete for the command slice: parser, Copilot dispatch, exact checked-scenario
resolution, Swift runner invocation, focused test, build gates, and a live AX drive of the estate scenario are
proven. The estate refactoring itself remains the subsequent bounded scenario sequence below.
- **Chapters read** — 07 operating guide and 08 validation/acceptance (mandatory operating and evidence authorities);
73 rule 9 (resolve → validate → execute → witness → reconcile); 75 rules 1, 5, 8, and 11 (one owned binding,
observation-only witnesses, terminal predicates, runner ownership); 77 rules 1–6 (Swift executor, typed MIDI2
ingress, Store/AX/CoreGraphics authority, uninterrupted provenance).
- **What they forbid here** — driving the candidate-only desired-result record, inventing a scenario, using direct
ReframeApp/shell/Python launch, replacing the runner with polling, or treating a screenshot/log as acceptance.
- **Conflicts** — none; the human estate plan selects the baseline by purpose, and the governance requires the
executable Semantic Browser projection as the first live target.
- **Excluded, and why** — candidate scenario authoring/confirmation, estate source redesign, publication, and Book
promotion remain later slices; this drive establishes baseline evidence only.
- **Latest baseline drive** —