The contract in plain language
WebKit stays the complete web platform. Teatro does not become a second browser. The semantic transformer produces the meaning of State B; MIDI2 identifies the participating slots and schedules the transition; Teatro turns that schedule into motion; WebKit renders the result.
Visual capabilities
The contract supports movement, reordering, insertion and removal, emphasis, crossfades, SVG morphing, expansion and collapse, route transitions, evidence progression, synchronized slots, pause, resume, cancellation, reduced motion, and deterministic replay.
Claim boundary
Animation is not semantic proof. AX establishes the accessible surface, and FountainStore establishes durable behavioral evidence. A smooth transition never turns a proposal into an acceptance or release claim.
State transition record
A transition binds State A, State B, the semantic diff, source revision, transformer identity, scenario composition, participating slots, timeline identity, and claim boundary. States are semantic publication records—not screenshots, server directories, or uncommitted DOM.
State B carries an explicit publishable Boolean. true means the declared semantic transformation has met its publication-eligibility rule; it does not authorize publication, replace the remote FountainStore receipt, or claim that the route is already published. Legacy State A records without the field decode as false.
One shared visual pointer
The pointer belongs to the writer. It is one visual instrument, not a Codex cursor or a second dialogue channel. When the writer points at a DOM region and comments, WebKit emits a typed anchor with the route, stable DOM/AX address, semantic role, text digest, State identity, source revision, and the writer's comment. Composer then hands custody to the active character through MIDI2.
The writer remains the origin peer; the character may inspect and speak about the pointer; Codex reasons over the received anchor; Reframe mediates. The MIDI trail records origin, recipient, custody handoff, anchor, comment, correlation, sequence, time, response, and terminal outcome. A stale route, State, revision, or DOM/AX digest is rejected and must be reselected—not guessed.
Slots and MIDI2 instruments
A slot such as estate.navigation, domain.lens, or publication.meta receives a MIDI2 instrument identity only when it is independently discoverable, addressable, and able to declare operations and terminal predicates. Internal visual fragments keep their Teatro identity.
Event and timeline contract
The lifecycle is admitted → armed → prepare → start → progress → settled. Cancellation, interruption, and failure remain distinct outcomes. Correlation and sequence are preserved even when packets arrive late. Transport jitter, schedule deviation, Teatro time, WebKit frame time, and persistence completion are measured separately.
Teatro transition plan
Teatro receives the admitted semantic diff and MIDI2 timeline, then returns declared correspondence and tracks: preserve, move, enter, exit, emphasize, deemphasize, SVG morph, expand, collapse, or replace-crossfade. It never guesses correspondence from visual proximity or text similarity.
WebKit application
WebKit remains responsible for the full web platform: DOM, CSS cascade, layout, typography, SVG, links, forms, focus, responsive behavior, and accessibility. Teatro may use CSS transitions, Web Animations, SVG animation, and feature-detected view transitions, but an unavailable animation feature must still settle on an equivalent State B.
Accessibility, interruption, and replay
The surface exposes lifecycle, active slot, controls, settled State B, keyboard actions, and reduced-motion state. Reduced motion changes interpolation only. Cancellation records incomplete state. For fixed identified inputs, plan version, browser capability profile, and timeline, replay must settle on the same semantic State B.
Acceptance target
Acceptance requires correlated MIDI-CI discovery, State binding, MIDI2 sequencing, Teatro correspondence, accessible WebKit State B, reduced-motion equivalence, distinct failure/cancellation handling, replay, AX evidence, matching FountainStore receipt, and window-ID visual evidence. A screenshot alone never proves behavior.