Reaktor Desktop Master Plan

How this document came to be. On 2026-08-17/18 two agents independently produced the plan for Reaktor Desktop from the same ground truth — both repositories, the full documentation corpus, the modules/reaktor.pen product atlas, and hands-on use of the running workbench. Codex wrote the constitution: category, laws, architecture, surface contracts, trust model, and delivery gates. Claude wrote the build score: the verified current state of every surface, a decision log resolving what the corpus left open, per-surface wiring order, and six shippable phases. This edition merges them with nothing deleted from either voice.

How to read it. The constitution is the spine; its section numbering is unchanged. Build-score material appears in place as sections titled "Build score §N — …" — those §-numbers and cross-references (D-decisions, G-gaps, phases) are the build score's own and point at other Build score sections. Where both plans specify the same mechanism independently, a Convergent note says so; treat those as the highest-confidence commitments in the document. Passages that would map live-security specifics onto running systems are summarized here and enumerated only in the private security reviews; each such passage says so in place.

The build score's thesis. Reaktor Desktop is already the only tool in the world that renders the real, typed, running graph of an application, gates every operation behind an effect ladder with fingerprinted plans, and refuses to lie about what it knows. What it is not yet is connected: selection dies at pane boundaries, twelve modes feel like twelve apps, the design is authored at a density only its author can read, and the deepest capabilities (editor session, lens, wiring report, live port events, the approval spine) sit unwired behind honest gray cards. The revolution is not more surface. It is making one context flow through every surface — Unreal's depth, Apple's continuity — until an intent started anywhere can be understood, proven, executed, and evidenced everywhere.

Status: product constitution and implementation program
Date: 2026-08-18
Scope: Reaktor framework, Reaktor Desktop, BestBuds integration, authored Pencil system, extension ecosystem, release factory
Companion evidence: the private investor-diligence review, Codex investor diligence in the originating task, docs/REAKTOR_DESKTOP_GOLDEN_DEVELOPMENT_LOOP.md, the private graph-editor-unification note

This is not a list of screens to beautify. It is the plan for turning Reaktor into the place where a team and its agents understand, shape, prove, run, and govern a software system as one continuous act.

The ambition is intentionally high:

Reaktor must let a small group build and safely operate systems an order of magnitude more complex than they could otherwise hold in their heads, while making every important relationship, decision, action, and piece of evidence legible to humans and agents.

Unreal is the reference for depth, extensibility, and the co-evolution of engine and editor. Apple is the reference for continuity, restraint, and the feeling that many powerful surfaces are one product. JetBrains is the reference for semantic understanding and trustworthy refactoring. Expo is the reference for collapsing an entire delivery journey into a coherent developer experience. Dapr is a reminder to integrate through explicit contracts instead of forcing a runtime everywhere. Stately is the warning that a beautiful graph which is not the program becomes a demo rather than an indispensable tool.

Reaktor should not replace JetBrains IDEs, Codex or Claude, Grafana, DataGrip, Figma/Pencil, Dagger, Pulumi, Cloudflare, Supabase, Kubernetes, Expo, or the platform consoles. It should make them cooperate. Reaktor owns the system context, semantic graph, governed action path, evidence, and continuity between tools. Specialists remain the best place to perform specialist work.

1. Decision

1.1 The product category

Reaktor is a system studio: an evidence-backed semantic model and governed control plane for software systems.

It is simultaneously:

• a brownfield architecture x-ray that can make an unfamiliar repository understandable in minutes;
• a live flight recorder that connects source, runtime, telemetry, tests, deploys, and incidents;
• a typed system composer where graph edits become reviewable code, configuration, or operational plans;
• a governed execution plane for humans and AI agents;
• an orchestration layer that deep-links into, invokes, and receives evidence from domain-specific tools;
• a persistent memory of why the system is the way it is and what changed it.

The initial adoption wedge and the long-term destination are deliberately compatible:

1. Wedge: open a brownfield workspace; obtain an honest semantic map, causal trace, blast radius, and governed operations without changing its architecture.
2. Expansion: wrap important boundaries in typed Reaktor contracts; connect runtime and telemetry; let agents propose verified changes.
3. Destination: author behavior, workflows, deployment cuts, and whole-system changes through one bidirectional graph/compiler/control-plane loop.

The graph is not the product by itself. The product is the closed loop:

intent -> context -> graph/query -> proposal -> diff -> validation -> plan
       -> approval -> execution -> observation -> evidence -> learning

1.2 What Reaktor owns

Reaktor owns six durable assets:

1. System identity: stable identities for workspaces, runtime islands, scopes, entities, ports, contracts, operations, releases, runs, and evidence.
2. System model: one queryable model spanning desired and observed source, runtime, infrastructure, data, identity, telemetry, analytics, tests, agents, and delivery.
3. System context: the user's current workspace, revision, environment, target, scope, lens, selection, time range, run, and change set.
4. Mutation spine: one safe path from intent to patch, validation, plan, authorization, execution, events, and audit receipt.
5. Evidence fabric: provenance, freshness, confidence, authority, contradiction, artifacts, and history for every displayed claim.
6. Tool cooperation contract: discover, inspect, deep-link, propose, execute, observe, and import/export across specialist tools.

It does not own every editor, dashboard, database console, cloud control, model provider, test runner, or deployment engine.

1.3 One decisive product promise

For any selected entity or change, Reaktor must answer:

• What is it?
• Why does it exist?
• Where is its source and owner?
• What does it consume, provide, contain, call, store, deploy, and observe?
• What is desired, what is observed, and where do they disagree?
• Which users and system paths depend on it?
• Which tests, traces, metrics, incidents, releases, and costs are attached?
• What can I safely do now?
• What will change, what could break, who must approve it, and how do I undo it?
• What happened after the action, and what evidence proves the result?

If a question cannot be answered, the UI says Unknown, explains the missing adapter or evidence, and offers the shortest honest path to acquire it.

2. Evidence and current-state baseline

This plan was produced from the two investor diligence reports; all first-party Reaktor and BestBuds product/architecture/security/release documents; both repositories and their governing AGENTS.md files; the operational catalog and Desktop implementation; the canonical modules/reaktor.pen design; and hands-on use of the packaged Desktop across its shell, graph, every current mode and subpane, the command palette, safe task execution, run evidence, and local MCP surface.

2.1 What is already worth protecting

• The graph/runtime substrate, typed ports, service projection, local actor model, auth kernel, FlexBuffers work, Cloudflare adapters, and deep BestBuds dogfooding are real.
• The operational planner/executor is unusually mature: ten effect classes, fail-closed tasks, definition seals, fingerprint re-checking, confirmation phrases, process-tree cancellation, bounded output, redaction, retained run evidence, and blocked second-approval classes.
• Source-derived task/resource discovery is materially more honest than a hand-maintained demo catalog.
• The truth doctrine is exceptional: unwired panes state what is missing; configuration does not silently become health; Pencil parity is tested; fixtures are separated from operational facts.
• The Pencil file contains a serious visual language, atomic components, interaction boards, semantic zoom, mission/control-plane concepts, and 74 named subpanes rather than a collection of unrelated mockups.
• The workbench already proves the core idea by inspecting the graph of the application built on Reaktor.

2.2 The gaps that change the plan

2.3 Truth labels used in this document

• Current: verified in the current source or packaged application.
• Designed: present in Pencil or design documents but not a production capability.
• Proposed: a decision introduced by this plan.
• Gate: a binary condition which must pass before the next dependent capability ships.

No roadmap screenshot, sample number, deterministic fixture, config resource, or design-board state is production evidence.

Build score evidence. The baseline above is the constitution's (2026-08-17). The build score re-verified it hands-on a day later on the running workbench-foundation build — every mode, subtab, palette, drawer, and inspector — and distilled the same facts into ten structural gaps and an improvement ledger. Where the two overlap (subpane wiring, packaged-versus-source drift, the editor being a viewer), they were measured independently and agree.

Build score §1 — Where the Desktop truly is — the walk verdict

I drove the running app end to end. This is the honest summary the rest of the plan builds on.

1.1 What is already excellent and must not be broken

1. The shell is real and coherent. One top bar (app · env · branch workbench-foundation fe9cbb2 · workspace · targets · Doctor · Deploy · avatar), a 12-mode strip, per-mode left rail, collapsible inspector, evidence drawer, status bar. Machine Signal tokens everywhere; zero hex literals in panes; parity-tested against the design file.
2. The graph is alive. BestBuds renders 29n/29e at Container level with typed ports, collapsed scope summaries ("Chat · 20 nodes", "design-prototype · 44 nodes · 5 subgraphs"), boundary-folded edges, kind legend, minimap, C4 level switcher, hierarchy L1/L2/All, edge-kind chips, a lens search, and an honest amber "32 disconnected ports" finding. The Workbench renders itself the same way. This self-hosting loop is the moat; nothing below may regress it.
3. The control plane is the crown. 477 tasks / 253 resources / 31 targets discovered from real files, 10-class effect ladder rendered as chips on every operation, plans with fingerprints and typed confirmation phrases, second-approver hard-blocks, runbook view-only gating with exact red reasons, redacted sensitive output ("Sensitive output was not retained"), a persistent run ledger that survives restart as Unknown rather than a guess.
4. The truth doctrine is enforced, not aspirational. Every empty region says what it is and what turns it on ("Turns on with: a ClickHouse analytics read; the events table is already partitioned for it"). Inspector facts read "not sampled / not observed / not attached" instead of inventing. The Auth Security subpane surfaces the repo's real findings (itemized in the private security review) as source-backed rows.
5. The palette is a real command surface. ⌘K mixes graph entities and tasks, shows effect/provenance chips, inlines unavailability reasons, and routes execution through the same requestRun path as everything else — no bypass.
6. The parity harness is a category invention. Four independently-gated altitudes (component / pane / action / layout) generated from the design file itself, plus truth invariants that make the alpha-0.001 class of fraud structurally impossible. 50/50 components, 74/74 subpane anatomies, budgets-not-zero goldens.

1.2 The ten structural gaps the walk exposed

These are the specific reasons the app feels like twelve tools instead of one instrument, each verified on screen or in source:

1.3 The improvement ledger — every improvement area in one view

Ten headline areas; each is expanded in its owning section, and every one traces to walk evidence:

1. Connection — one WorkbenchContext, selection everywhere, one search, verb fabric, history/deep links, full persistence (§3, §5). The single biggest win.
2. Identity — real names for ServiceNodes/bindings, grouped diagnostics, Type trap fix, stable element ids (D7).
3. Correctness & performance foundations — CHM races, port-registry thread safety, owned graph handles, memoized projections, culling/LOD (D12, D13, §18.2).
4. Depth behind the honest gray — V1 data planes for the 43 waiting subpanes; most are cheap because the data exists (§7–§17, Appendix A).
5. Graph: viewer → studio — wire the already-built editing callbacks to draft commands, evidence overlays, studio deck, then compiler/debug per Graph G0–G7 (§6).
6. One evidence plane — shared records behind drawer + panes, earned counts, unified findings (§3.3, D10).
7. Design system for daily use — type/hit-target floors, one themed token family, density tiers, full state matrices, focus/semantics, labeled empties (§4), plus the measured design audit and its correction program (§4A, §4B) and the six anti-regression laws (§4.8).
8. Trust containment — the Appendix-H and BestBuds P0 findings fixed and rendered in-product with verification runs (§19 Phase 1, §9).
9. Missions + ambient agent — durable intent, Ask/Explain first, Propose/Delegate behind the spine (§3.4, §3.5, §17).
10. Shell polish — dead chords, ghost mode, duplicate inspector tab, rail counts, avatar, chrome swaps, keyboard map (§5).

1.3b The one-line diagnosis

The framework has already built the instruments (WiringReport, ScopeView, Lens, EditorSession, PortEvents, ActorStatus, tooling spine, AuthRequirement, accessibility inventory — fifteen ready levers catalogued in §18.1). The Desktop plays each instrument alone. The plan below is, in order: fix the identity and truth of what is shown (Phase 1), make one context flow through everything (Phase 2), wire every authored surface to its real data plane (Phases 3–5), then let the graph write as well as read (Phase 6) — with Machine Signal 2.0 and the pencil atlas repair running as a parallel track.

3. Product laws

These laws are derived from both repositories' AGENTS.md files and are release invariants.

3.1 The graph is semantic, not decorative

Every node, port, wire, scope, badge, operation, and overlay refers to a stable semantic entity or explicitly marked view metadata. Moving a card changes layout. Connecting two typed ports changes the program through a patch. A graph cannot be a hand-drawn parallel truth.

3.2 Atomic design applies to the whole system

Atomic design is not restricted to buttons:

Components are composed from the smallest reusable primitive that preserves semantics. Surface-specific one-off APIs are rejected when a small primitive plus composition expresses the same behavior.

3.3 Expressivity and composability beat breadth

Build the smallest 20% of primitives that make the common 80% effortless and the unusual 20% possible. Reaktor should feel deep because its primitives compose, not because the sidebar contains a button for every vendor API.

3.4 One intent, one context, one action path

Humans, keyboard commands, UI buttons, agents, MCP clients, and extensions must issue the same typed intents. They may have different permissions and presentation, but no privileged alternate mutation path exists.

3.5 Desired and observed never overwrite each other

Source says what should exist. Runtime and providers say what was observed. Reaktor retains both, shows evidence and freshness, and emits drift/conflict findings. A merge cannot silently choose one.

3.6 Every module has three optional layers

1. A graph-neutral kernel usable as an ordinary library.
2. An optional install(graph) projection returning an owned, closeable handle.
3. An optional Desktop extension contribution.

The graph and Desktop are leverage, never an adoption tax.

3.7 Specialist tools remain first-class

Every Reaktor detail view must decide whether the best next action is native, embedded, or a deep link. “Open in IDE,” “Open in Grafana,” “Open in DataGrip,” “Open in Cloudflare,” and “Export verified context to Codex/Claude” are product features, not escape hatches.

3.8 Truth, trust, performance, and accessibility are features

They are not horizontal clean-up phases. Every surface contract contains data truth, authorization, failure/offline behavior, latency/scale budgets, semantics, keyboard access, screen-reader alternatives, and test evidence.

3.9 No marketing before a conformance harness

Polyglot, distributed actor, mega-scale, visual programming, live collaboration, autonomous agent, and multi-region claims only ship after an externally reproducible conformance or scale gate proves the exact claim.

Where this fits. The constitution deliberately left questions open (§27) and the corpus carried contradictions. The build score's decision log resolves them; its D-numbers are referenced throughout this document. D2 and D3 carry amendments made after the constitution's 2026-08-18 revision.

Build score §2 — Decisions — resolving what the corpus left open

The docs sweep found fourteen contradictions and the diligence demanded calls the branch has not made. A plan that covers every surface must first make these decisions. Each is numbered and referenced by the sections that implement it.

D1 — Twelve visible modes stay; the diligence's "cut UI/AI" is rejected in favor of "wire honestly, gate loudly." The branch already chose visibility with NotWiredYet truth cards, and the walk shows this reads as integrity, not vaporware. But visibility now carries an obligation: every UI/AI subpane gets a real V1 data plane in Phases 3–5 (§16, §15), and until a family reaches ≥50% wired its mode tab carries a subtle preview underline treatment (Proposed) so the silhouette matches the truth doctrine. The golden-loop doc's stale IA table is rewritten to match (owner: docs task in Phase 1).

D2 — The four-movement IA (Map/Trace/Validate/Act) arrives as a projection, not a reorganization (amended). Keep the 12 instruments as the primary strip through Phase 5, exactly as the constitution's migration section prescribes. Phase 2 introduces WorkbenchContext + Missions; Phase 6 adds the movement selector as saved templates over the same context. No existing deep link or shortcut is removed, ever, without an alias. Amendment: the revised §8.4 makes the two-row Studio Control Deck (movements + Explore/Edit/Debug/Compare + query + revision/draft) the Graph Studio's own toolbar, and the atlas has now authored and componentized it (Graph / Studio Control Deck, plus the Shell / V2 / Movement Strip family). So the movements appear inside Graph Studio when its deck ships (Phase 3–4) as canvas chrome, while the app-wide IA switch stays Phase 6 behind the flag.

D3 — One safety ladder (amended for the 2026-08-18 revision). The 10-class TaskEffect ladder (golden loop, shipped) remains canonical for operations. The revised constitution §8.13 adds an 8-class authoring-effect scale for canvas drafts (View Ephemeral → Local Document Write → Source Write → Non-Production Runtime Write → Production Reversible Write → Credential/Policy Write → Data Migration → Destructive/Irreversible); adopt it for graph/data change plans, with the visible effect always the maximum transitive effect and a documented mapping into TaskEffect where a draft materializes as an operation. The old 5-class SafetyClass in reaktor-unified-system-graph.md §12 / reaktor-cloud-pane.md dies everywhere: correction notes in both docs, and no UI shows its names on a chip.

D4 — "Inspector," not "Editor," until Proof B passes. Adopt the diligence's M5 and the constitution's migration rule verbatim: shipping UI says Map/Inspect; the composer vocabulary appears only behind the mutation capability gate (§17). The graph-editor-unification.md doc gets a status header pointing here.

D5 — The shortcut canon is the shipped one, and the design file follows the app — not the reverse. Authored pen shortcuts (UI=2, DevTools=3…) are stale fiction; the app's ⌘1 Graph / ⌘2 DevTools / ⌘5 Database / ⌘6 Auth / ⌘⇧C Cloud / ⌘9 Deploy / ⌘8 Testing / ⌘0 Telemetry / ⌘3 Agent is live muscle memory. Phase 1 completes the missing three bindings (UI=⌘4, AI=⌘7, Analytics=⌘⇧A), adds a ModeShortcutParityTest gating enum↔binding↔cap-label↔pen-truth, and the pencil pass (§4.6) updates the authored chips. Digit semantic-zoom keys stay unmodified-only (they never conflict with ⌘ chords); the keyboard reference board (§4.6) documents both.

D6 — One token source, one component kit, one workbench. reaktor-ui/machinesignal is the sole definition (already law). Phase 1 deletes: the legacy COMMON/prototype/ui/MachineSignal.kt copy (after migrating ReaktorPrototypeHost imports), the dead shell files (§5.9), and folds ReaktorWorkbenchTokens/WorkbenchColors into delegating views of MachineSignal (structure kept, values single-sourced — the direction the handoff plan set). The React-web and Compose-common workbench implementations are declared renderer targets of the same catalog: they may not define their own mode enums; Phase 2 gives them a generated WorkbenchSurfaceManifest (D8) and a sync test, or they are marked deprecated behind a build flag. No third mode enum survives Phase 2.

D7 — Identity before features. Nothing else in this plan is legible while sixteen nodes render as "ServiceNode" and six resources render as "AI". Phase 1 ships: (a) ServiceNode takes its service's declared label (fallback: operation-set hash) — framework change in reaktor-graph/ServiceNode.kt; (b) Cloudflare binding resources render binding · worker compound names from the discovery layer; (c) the Diagnostics ledger groups by finding kind with counts instead of 225 sibling rows; (d) Type equality trap fixed: Type compares on type string only, with kClass as advisory metadata and a wiring-time diagnostic when two different classes share a simpleName (framework, reaktor-graph-port/Port.kt); (e) stable ElementId derivation (namespace + logical key) lands in the flow projection so selection survives rebuilds — the pre-work for the constitution's §7.1 model without waiting for the full reaktor-graph-model module.

D8 — The SurfaceContract/CapabilityManifest from the constitution §18 starts life as a small generated artifact, not a rewrite. Phase 2 generates WorkbenchSurfaceManifest from what already exists — ReaktorMode + WorkbenchPaneCatalog + SubpaneReads + WorkbenchSubpaneLayouts + WorkbenchActionCatalog + shortcut bindings — and the palette, help overlay, coverage report, React renderer, and MCP list_surfaces tool all read it. The full typed contract (states, budgets, a11y) grows on that spine in Phase 5 rather than being designed in the abstract.

D9 — Deploy and Testing join the catalog as authored families. Today they are app-only modes with derived tabs, invisible to the pane gates (Deploy's board 07.04 is claimed by cloud/deploy). Proposed: pen gains deploy (7 subpanes: All, Workers, Mobile, Web, Server, Desktop, Artifacts, History — collapsing to the constitution's §15.1 list) and testing (harness filters All/Maestro/Playwright/Desktop/Karate/k6/Keploy + Results) as first-class families in the atlas (§4.6), raising the authored total from 74 to ~89 and bringing both modes under MachineSignalPaneCoverageTest. Until the boards exist, both modes keep derived tabs but gain SubpaneSpecs so no tab is ever blank.

D10 — The drawer is the one evidence plane, and counts must be earned. BottomDrawerTab's hard-coded fallback counts ("412", "86"…) are deleted in Phase 1 (live counts already exist); CommandQueue/CodeAgent/CodeDiff remain excluded until their fixtures die (they return in Phase 5 as Agent-plane projections). Tests/Build/Traces tabs get real feeds in Phase 3 (§13, §7): a testing-harness result adapter, a Gradle/Dagger build-event adapter, and trace records from the causal-trace surface. Rule: a drawer tab whose live count source does not exist renders an em-dash, never a number.

D11 — MCP grows a second, authenticated plane before any mutation tool. The read server stays as-is (loopback, read-only). Phase 4 adds the capability credential + instance identity from constitution §7.10 and three read tools the walk showed agents need (list_surfaces, wiring_report, run_events(runId, afterSeq)); the mutation broker arrives only at the constitution's Gate 4 with the same requestRun/plan/approval spine the UI uses. reaktor-mcp (the module) gains the transport + auth so the bestbuds server shrinks to tool definitions (dual-surface rule).

D12 — Fix the two concurrency landmines before any live-refresh feature. The ConcurrentHashMap migration races (claim-before-migrate finalization, remove/resurrect window, silent probe-exhaustion drop, non-linearizable clear) and the plain-hashMapOf port registry are Phase 1 blockers with model-checking tests, per the constitution's G0. Until then, no background thread may mutate a rendered graph. The JVM fast path may simply delegate to java.util.concurrent.ConcurrentHashMap behind the same API (the file's own header suggests it) while the lock-free implementation is repaired for native/JS.

D13 — Panes stop re-deriving; the snapshot diffs. Replace whole-graph rebuild-on-scope-toggle with: memoized buildReaktorFlowGraph keyed by (graph identity, scope-view state, style), wiringReport recomputed only on PortEvent, and GraphManifest-style cached read models for MCP so app.graph() is constructed once per app and closed on switch (a DisposableEffect and an openGraph(): OwnedGraphHandle seam — the first slice of constitution §7.6). Budget: scope toggle ≤50ms on the BestBuds graph, measured in ReaktorDesktopPerformanceTest.

D14 — Light theme and density become token axes, not new designs. Machine Signal 2.0 (§4) adds dark (default), light, high-contrast palettes and compact/standard/comfortable density to the token object with the same names; the pen file gains theme variable axes for the same 83 tokens. No component may branch on theme — only tokens. The dark instrument look remains the identity default.

D15 — The three-search problem resolves into one search service with three scopes. One WorkbenchSearchService indexes graph entities, catalog tasks/resources, runs, findings, docs anchors, and (Phase 5) symbols; the toolbar box, rail filter, canvas lens, and ⌘K are four views with preset scope filters over the same index and the same result model. Enter in the toolbar box focuses the best hit in the current mode; ⌘K stays the cross-everything overlay (§5.5).

D16 — Every improvement lands with its gate. Each per-surface section below names its acceptance; globally, Phase 1 adds the missing meta-gates: ModeShortcutParityTest (D5), DeadCodeAbsenceTest (files in §5.9 stay deleted), SurfaceManifestSyncTest (D8), SelectionPropagationTest (G1), a DrawerCountTruthTest (D10), and screenshot goldens per mode via the existing WorkbenchShellRenderTest expanded from 8 to all 12 modes + paint-coverage floors twice as strict for wired panes.

4. The seamless interaction model

4.1 A shared WorkbenchContext

Every surface reads and updates one serializable context:

data class WorkbenchContext(
    val workspaceId: WorkspaceId,
    val sourceRevision: SourceRevision,
    val environmentId: EnvironmentId,
    val targetIds: Set<TargetId>,
    val scopeId: GraphScopeId,
    val viewLevel: GraphViewLevel,
    val lensId: LensId,
    val selectedEntityIds: Set<ElementId>,
    val timeRange: TimeRange,
    val selectedRunId: RunId?,
    val changeSetId: ChangeSetId?,
    val principal: PrincipalSummary,
)

This is the connective tissue. Selection is not local widget state unless it is truly ephemeral.

Examples:

• Select ChatActor in Graph; Source opens its declaration, Traces scopes to its spans, Tests shows covering/affected tests, Deploy highlights its runtime island, Database shows its state contracts, and Agent receives the same verified context pack.
• Select release v812; Graph shows its topology, Observe compares it with v811, Errors and Costs use the same time window, Deploy exposes rollback evidence, and Source shows the exact commit.
• Select an auth finding; Graph shows reachable operations, Tests offers a generated negative matrix, Agent can draft a patch, and the plan shows affected resources and required reviewers.

Context navigation behaves like a browser:

• back/forward history;
• stable deep links;
• named/pinned views;
• shareable, redacted context packs;
• “open alongside” and compare without losing the originating selection;
• restoration across restart.

4.2 Missions, not pane hopping

A Mission is a persistent outcome with scope, success criteria, owner, plan, change set, evidence, and history. Examples: “ship chat reactions safely,” “reduce startup P95 below 1.5 s,” “migrate D1 schema,” “resolve auth finding,” “upgrade Kotlin.”

Mission Control is the default home after workspace validation. It shows:

• active missions and blockers;
• system health and freshness, without invented aggregate scores;
• changes since last session;
• failing gates and risks;
• agent activity awaiting review;
• recent runs/releases/incidents;
• the next highest-leverage action with evidence.

A mission can span Graph, Build, Prove, Operate, and Learn without becoming five disconnected tasks. Each surface retains a visible mission chip and contributes evidence back to it.

4.3 Target information architecture

The twelve current source modes remain deep-linkable during migration, but the final primary selector has four movements. The user chooses an intent, then an instrument. This is the “symphony” model: the music remains one system context while the instrument and projection change.

The instrument strip scopes the movement without creating another product:

Mission Control is the orientation/resume home above these movements. Graph, Build, Prove, Operate, Observe, and Learn remain named saved templates and keyboard/palette aliases; for example, Graph opens Map + All instruments, while Observe opens Trace + Runtime. A user can still deep-link directly to Database > Query or AI > Evals.

Agent is the conductor, not a destination. The full Agent workspace remains available for sessions, tasks, memory, tools, and audit, but every surface exposes Ask, Explain, Propose, and Delegate in local context. Agent work materializes as inspectable missions, patches, plans, runs, findings, or evidence—not private chat history.

During transition the full legacy/source mode switcher remains available in the command palette and a customizable workspace switcher. Teams may pin instruments and saved templates. No existing function is deleted merely to simplify navigation.

4.4 Progressive disclosure

Reaktor has three density levels, controlled by window width and user preference:

1. Focus: canvas/content plus compact context; rails become overlays.
2. Standard: navigator + content + contextual inspector; drawer collapsed until evidence arrives.
3. Command: navigator + content + inspector + evidence drawer, optimized for large displays.

The same semantic content survives each density. Compact mode never removes the only route to a function.

Convergent. Both plans independently specify the same connective tissue: one serializable WorkbenchContext, browser-like history and deep links, missions, and ambient agent verbs. The constitution's §4 is the destination contract; the build score below is the Phase 2 implementable slice over today's code. Every overlapping field agrees.

Build score §3 — The connective tissue — how everything becomes one instrument

This section is the heart of the "symphony" requirement. It is deliberately small: five mechanisms, all buildable on current code, that every per-surface section then plugs into.

3.1 WorkbenchContext — one selection, one time, one scope (Phase 2)

One serializable state object replaces today's scattered remembers, owned by the shell and passed (via a CompositionLocal + explicit params for testability) to every pane, the inspector, the drawer, the palette, and the MCP surface:

data class WorkbenchContext(
    val appId: String,                    // BestBuds | Workbench | future GraphManifests
    val workspaceRoot: String,
    val environment: String,              // local | dev | production
    val targetIds: Set<String>,
    val mode: ReaktorMode,                // instrument
    val subpane: String?,                 // family/subpane key
    val graphScope: ReaktorFlowScopeView, // hierarchy position
    val selection: WorkbenchSelection?,   // sealed: GraphNode | Resource | Task | Run | Finding | Artifact | Release
    val timeRange: WorkbenchTimeRange,    // shared by drawer, telemetry, analytics
    val selectedRunId: String?,
)

Rules, enforced by SelectionPropagationTest:

• Selecting anything anywhere sets selection; the right-rail inspector renders it in every mode (killing the "Selection: none" stub, G1). WorkbenchSelection.Resource("cloudflare/chat-service") selected in Cloud is still selected when the user presses ⌘1 — Graph highlights the node, ⌘5 — Database scopes to its bindings, and the drawer filters its runs.
• Mode switches never clear context; app switches snapshot-and-restore per app; everything (context + rail/drawer collapse + mode + scope view) persists to the existing ControlPlaneStore sidecar and restores on launch (fixes G7).
• Context history is a browser: ⌘[ / ⌘] walk back/forward across (mode, subpane, selection, scope) states; every state has a copyable deep link reaktor://bestbuds/graph?scope=…&level=…&sel=… — the URL grammar reaktor-graph-hierarchical-ui.md §5 already specifies. The MCP read plane serves the same links so agents and humans share addresses.

3.2 The verb fabric — "Open in…" everywhere (Phase 2, grows forever)

A small registry of typed cross-surface verbs, derived from the selection kind, rendered identically in the inspector footer, context menus, and the palette:

Open in Graph · Open in <mode> · Open Source (IDE) · Open Trace · Show Runs · Show Findings · Copy deep link · Open in <external console>

The walk found these already exist as one-offs (IDE button, "Open in Graph", Grafana/Cloudflare/Kubernetes jump-outs, drawer run links). Phase 2 unifies them on the context object so every new selection kind gets the whole verb set for free. External deep links (Grafana, Cloudflare dashboard, DataGrip, ClickHouse console, Pencil) are first-class citizens of this registry — the "cooperate, don't replace" law made into chrome.

3.3 The evidence spine — drawer, inspector, and panes share records (Phase 3)

One record model (time, runId, taskId, entityId?, scope, environment, truth, artifactRefs) behind Runs/Logs/Traces/Network/Tests/Build/Diagnostics. Selecting a drawer record navigates context (3.1); selecting an entity filters the drawer. The drawer is the fast view; Telemetry/Testing/DevTools panes are the deep views over the same records — never separate stores. Diagnostics merges: wiring report (already), workspace doctor findings, auth security findings, pen-parity failures in dev builds, and OPEN_QUESTIONS.md parsed as a source-truth rule set (each row: finding, where, severity, evidence link) — the walk showed these live in four different places today.

3.4 Missions — intent that outlives a pane hop (Phase 5)

Adopt the constitution's Mission model with the minimal viable shape: a Mission is a named context bookmark plus a change-set of runs/findings/artifacts it accumulates. Lives in the control-plane store; rendered as a chip row under the top bar when active; every governed run and finding created while a mission is active is tagged to it; Mission Control is a new first tab of the Agent mode (not a new mode) until it earns the constitution's home-surface role. Goals→Missions migration per constitution §26.

3.5 Ambient agent — four verbs on every selection (Phase 5, read-only first)

Ask · Explain · Propose · Delegate on the selection context menu, backed by the MCP read plane + context packs (redacted snapshot slice + evidence links). Ask/Explain ship first (read-only, cite evidence ids); Propose/Delegate wait for the mutation spine (Gate 4) and always materialize as reviewable plans in the existing approval UI. The Critic never applies (constitution §10.3). The Agent mode's Chat subpane is the full conversation surface; the ambient verbs are its entry points — agent work is never trapped in a chat log.

5. Machine Signal 2.0 — atomic design system

The existing Machine Signal language is the foundation, not a constraint. Preserve its technical clarity, semantic color, graph grammar, and compactness. Rebuild it for sustained daily use.

5.1 Token architecture

Tokens are typed and platform-adaptive:

• semantic color roles for surface, text, border, selection, focus, truth, effect, node kind, edge kind, and status;
• UI and code typography roles; mono is reserved for data/code/identity, not every label;
• 4 px spacing base with deliberate density modes;
• control heights of 28/32/36 px by density, never below accessible hit geometry;
• corner, stroke, elevation, opacity, icon, motion, and graph geometry tokens;
• light, dark, high-contrast dark, high-contrast light, reduced-transparency, and platform theme mappings;
• text scale through 200% without clipped primary actions.

Default sustained-reading text is 12–14 px at 100% scaling. Microcopy below 11 px is restricted to nonessential dense data and must still respect OS scaling. Primary interactive controls provide at least a 32 px visual target and a 40–44 px effective hit target where platform conventions require it.

5.2 Component hierarchy

Atoms: SignalText, icon, divider, focus ring, badge, truth mark, effect mark, keycap, avatar, progress, port, handle, timestamp, provenance glyph.

Molecules: buttons, search field, context chip, status pill, metric chip, filter token, tree row, key/value row, command row, plan step, evidence link, source link, graph pin row, inline finding, breadcrumb item.

Organisms: top bar, workspace switcher, mode switcher, scope navigator, command palette, result table, inspector section, evidence timeline, plan approval, run console, diff viewer, minimap, query editor, trace waterfall, device frame, agent proposal card.

Templates: mission control, system canvas, catalog/detail, editor/preview/inspector, compare, query/results, timeline/detail, plan/approval/evidence, empty/unwired/onboarding.

Every reusable component owns:

• default, hover, pressed, focus, selected, disabled, loading, error, and permission-denied states;
• accessible name/role/value/action;
• keyboard behavior;
• truth/evidence treatment;
• light/dark/high-contrast rendering;
• 100/125/200% goldens;
• motion and reduced-motion behavior;
• deterministic test tag and telemetry event where appropriate.

5.3 Visual hierarchy

• Use whitespace, alignment, typography, and grouping before boxes.
• Reserve cards for semantic boundaries; do not put every row inside a rounded rectangle.
• One primary action per region. Secondary and dangerous actions are visually distinct.
• Color never carries the only meaning. Status combines shape/icon, text, and color.
• Persistent chrome is quiet. Selection and active work own the strongest contrast.
• Motion explains continuity—scope transitions, plan evolution, evidence arrival—not decoration.
• Tables, graphs, and timelines share a selection model and can be viewed side by side.

5.4 Accessibility contract

• WCAG 2.2 AA minimum; measured, not assumed.
• Complete keyboard navigation and visible focus.
• VoiceOver, NVDA, and AT-SPI support on the release matrix.
• Every graph, chart, timeline, and minimap has a synchronized navigable tree/table and text summary.
• Reduced motion disables nonessential animation.
• Truth remains legible in monochrome.
• The UI/A11y surface displays results measured from the current build; absent results are Unknown.

Convergent, then extended. Both plans demand the same design-system program — themed token axes, type and hit-target floors, complete component state matrices, and repair of the authored atlas. The build score adds the quantified debt, two direct-inspection addenda recording what the live atlas migration landed, and then goes further: a measured design audit of the atlas against this constitution's own specifications (§4A), the correction program that closes it (§4B), and six anti-regression laws. Where Appendix F/G/H record what each design wave delivered, §4A records what it still gets wrong — and both are true at once.

Build score §4 — Machine Signal 2.0 — the design-system program

The visual language is right: dark, dense, instrument-panel, provenance-as-color, "like VS Code, DataGrip, or Grafana, not like Figma or Notion." The execution has quantified debt: in the atlas, ~6.5k text nodes at ≤10px (~2.3k at ≤8px), 683 contrast failures below 4.5:1, every interactive control under 32px, one hardcoded theme, zero loading/empty/error/light/compact boards, and three coexisting region-naming schemes. The app already diverges upward (12.5–13sp prose, authored data ramp kept for data only) — the right instinct, half-finished, with one open decision the gate surfaced: at 13sp, "Continue mission" no longer fits the authored 137px button.

4.1 Token architecture (Phase 1–2)

• Axes, not forks (D14). MachineSignal gains theme: dark | light | highContrast and density: compact | standard | comfortable resolved at the root; all 83 token names stay identical. The pen file gains matching variable axes. Provenance triads are re-derived per theme with the same semantic roles and re-validated for contrast (the truth colors must survive light mode — this is the hard part and gets its own golden).
• Type ramp becomes law. Prose: 11/13/17/24 (label/body/title/display), floor 11sp; Data (mono): 9.5/10.5/11 permitted only inside data rows, tables, and graph chrome. MachineSignalTypeAuditTest (new) fails any SignalText below floor outside a data context. Sustained-reading surfaces (docs panels, explanations, empty states) use 13sp minimum.
• Hit targets. Control heights move to 28 (compact) / 32 (standard) / 36 (comfortable) with ≥40px effective hit area via padding; the authored 30px button becomes the compact value. The button-width decision (open in the harness): widen authored button boxes to fit 13sp — the design file follows the app (D5 logic), and budgets re-baseline. Sub-tab row 27→30, mode tab 26→28 at standard density.
• Divergence ledger stays. Every deliberate app-over-pen divergence lives in MachineSignalGeometryParityTest's ledger with a reason — the mechanism that already exists and works.

4.2 Component contract (Phase 2–4)

Every kit component (the 62 shipped across MachineSignalKit/GraphKit/ShellKit) gains the full state set as it is touched: default/hover/pressed/focus-visible/selected/disabled/loading/error/permission-denied, keyboard operation, accessible name/role, reduced-motion behavior, and both themes — recorded as goldens at 100%/125%/200%. Rule of acquisition stays: a widget needed twice becomes a kit component; a data need appearing twice becomes a Fact provider. Priority additions the walk exposed (all have authored anatomy already): FindingRow (severity+where+evidence — Auth Security has the best current form), RunStatusChip (unify the five ad-hoc renderings), EmptyRegion (the "—" placeholder, today unlabeled — every em-dash gets a one-line reason), OverflowChip ("N mores" → "+N more", fixing the pluralization bug everywhere it appears), TimeRangeChip (shared, deep-linkable), ContextCrumb (the selection chips, made interactive).

4.3 Accessibility (Phase 2 baseline, Phase 4 gate)

Baseline now: complete the keyboard map (§5.8), visible focus rings everywhere (the kit has the ring; several panes swallow it), semantics on every interactive element (diligence: near-zero today), and the graph's accessibility inventory (reaktorGraphAccessibilityItems — already implemented and tested in reaktor-flow) rendered as an actual navigable tree alternative behind a toolbar toggle. Gate at Phase 4: WCAG 2.2 AA measured by the UI/A11y subpane itself (§16) — the tool audits its own chrome with the same machinery it offers for the product app, and unwired audits say Unknown.

4.4 Density and layout behavior

The three authored responsive shells (390/768/1600) become live: compactShell today only swaps rails for strips at <900dp. Phase 3 adds the middle tier (rail overlays, inspector as sheet) and honors density in band heights via the existing TitleStep mechanism. "Chrome does not scale" stays law (fixed px bands); content bands share leftover; the NarrowRegion compact-list degradation already works and becomes a documented behavior with a golden.

4.5 Motion

One motion token set (150/220ms, standard easing, reduced-motion kill-switch): scope expand/collapse animates containment (the semantic-zoom story), selection ring fades in, drawer/rail slide, palette fades, run-status chips pulse only while Running, and wire animation remains reserved for observed activity per the visual-language law. No decorative motion anywhere else.

4.6 The pencil atlas repair (parallel track, §19 milestones)

The atlas is a product asset worth repairing, not regenerating. Work order:

1. Mechanical hygiene pass (script-driven via Pencil MCP execute): fix the 84 clipped nodes in 09.01 and 11.01's clipped funnel rows; renormalize the three region-naming schemes to the short-code scheme; reparent the stray hfE45 node and the two 04.06 state boards parked in section 09; delete the 0.1px hidden-text hack in Tab/Mode masters.
2. Token axes for theme/density (4.1) — variables only, no board redraw.
3. Type & control raise: batch-update the 51 masters to the new metrics (buttons/subtabs/type floor); instance counts mean masters-first fixes ~500 control instances for free; then a targeted pass on the ~2.3k ≤8px labels in the most-used boards (04.x, 05.00, 09.01, 13.x first), converting micro-labels to the data ramp or the 11sp floor.
4. Missing-state boards — the gap list verbatim: loading/skeleton (graph, query, trace), known-empty (first-run workbench per mode), error (query error, trace not found, adapter failed), permission-denied, offline/stale, light theme (one board per shell + one per family exemplar), compact density exemplar, Composer step 3-of-5, and a keyboard-shortcut reference board. House rule: state boards are variants over the family's base board, not ×N deep clones — the Composer/Deploy clone debt is not repeated (STATE clones get rebuilt as overrides when next touched).
5. New authored families for Deploy and Testing (D9), plus dedicated selected-state boards for the ~35 subpanes that are named on strips but never drawn — prioritized by wiring order (§19), so the board always exists one phase before the pane wires.
6. Refresh loop discipline: after every atlas change, extract-pen-truth.js passes 1–3+5 → pen-truth.json → :engine:jvmTest --tests "*MachineSignal*" — the unbroken chain reaktor.pen → pen-truth → MachineSignal → shell stays the enforcement path. (Standing gotchas: Pencil MCP acts on the active editor only; Pen's render handlers die after the integrated browser is used — restart Pen, don't misread it as an export bug.)

4.7 Atlas inspection addendum — direct inspection, 2026-08-18

After this plan was written, a direct inspection of the live reaktor.pen editor found the atlas substantially evolved beyond the state §4.6 was written against (the working tree's modified reaktor.pen plus unsaved editor state; Pen has no autosave — save and commit this work). What changed, verified board by board:

• The four-movement IA is now authored. Every board is renamed NN · Movement (+ Instrument) · Name ("04.02 · Map · Semantic Graph Editor & Compiler", "07.04 · Act + Delivery · Deployment Plan & Gates", "09.01 · Validate + Identity · Policy, RBAC & Explanation"), and the redesigned boards render a movement row (Map | Trace | Validate | Act) + instrument strip in the shell chrome. Mission Control is a complete movement-first home (mission hero with typed pipeline cards, truth ledger, real BestBuds findings as release gates, verified context pack with "Drive with Codex"). The compact-390 shell is a real mobile studio (Mission/Map/Trace/Validate/Act tabs, "needs you" approval queue, semantic-zoom graph) with visibly raised type. Consequence for D2: the instruments-first migration stance stands for the app, but the atlas now authors the movement shell as the far state — Phase 6's projection has its design ready, and new boards should follow the movement taxonomy.
• Components: 51 → 78 masters, including the governance atoms §4.2 asked for and more: TruthMark ×7, EffectMark ×4, FreshnessStamp, SourceRef, PermissionGate ×2, RunRef, EmptyReason, PlanSummary/Sealed and ApprovalReceipt/Independent (fingerprint + independent-approver + one-use semantics rendered), full-surface-hit-target node cards, and five major graph-chrome organisms: Studio Control Deck (movements + EXPLORE/EDIT/DEBUG/COMPARE + query + draft chip), Lens Stack (base + overlays + evidence freshness — §8.2 exactly), Time Controller (live/pause scrubber with span count), Boundary Portal, Fabric Context Ribbon (desired | observed split), Data Query Safety Bar (read-only · row/byte/time bounds · explain-first — §8 Query's governance made visible). The kit backlog in §4.2 should be re-baselined against these authored forms.
• Theme axes exist (D14 partially landed in design): a new ms2-* variable family (~34 tokens) is themed mode: light | dark | high-contrast. Verified values: canvas #F7F8FC / #070A0F / #000000, live #087A4A / #42D392 / #00FF88. Gaps: the original 83 tokens remain untheed single values — two token generations now coexist (the exact dual-source drift D6 exists to kill); masters carry no theme stamp, so isolated instances resolve to the axis default (light) — an integration hazard for any board that forgets to stamp mode: dark. New work item: merge ms2-* and the base tokens into one themed family before MachineSignal 2.0 transcription, and define the default mode explicitly.
• Redesigned boards verified at full resolution: Mission Control, 04.03 (studio deck + lens rows + desired/observed node footers + change-set drawer with semantic GraphPatch diffs + contracts-first inspector), 09.01 (policy studio: propose → simulate → blast radius → negative tests → approve → audit receipt; explainable role hierarchy; permission matrix), 07.04 (sealed plan diff chips, five target cards with real infra, required-evidence chips, gate progress, approval receipts, rollback lineage). Design quality is dramatically higher and content is drawn from the real repo (workers, k3s services, findings, bundle ids).
• What did not change (debt confirmed still open): the type census is essentially unchanged (2,277 text nodes ≤8px, 4,124 at 8–10px, whole file) — the §4.1 ramp raise remains the top design task; band names inside boards still carry the old chapter numbering (e.g. board 09.02 · Trust · Auth Sessions contains bands named 06.2 · Auth — Sessions), worsening the naming drift §4.6.1 targets; the ×9 Composer and ×5 Deploy state clones remain deep copies; Composer step 3-of-5 is still missing; the stray hfE45 node persists; loading/empty/error boards still do not exist.
• Pipeline consequence (urgent, Phase 1): pen-truth.json (extracted 2026-08-15) no longer matches the file — board renames alone will shift the layout oracle, and SubpaneLayoutsAuthored.kt transcribes old board titles in its board: strings. Before any further engine work on authored anatomies: re-run the extraction passes, re-baseline the parity suites deliberately (budgets-not-zero rules apply — tighten or re-author, never delete), and update the transcription strings. Until that sync, treat parity-test failures as expected staleness, not regressions.

Second scan, later on 2026-08-18 (file saved to disk 12:41 and still actively mutating between reads — a codex migration session is live): the picture improved dramatically and several §4.7 debts are now closed: the whole-file type census went from 2,277 nodes ≤8px + 4,124 at 8–10px to zero at or below 10px (3,326 at 10–12 for data, 656 at ≥12 for prose — the §4.1 ramp is effectively applied in the atlas), total text nodes halved via componentization, clipping problems are 0 file-wide (Appendix F's "84 → 0" Identity fix verified), the stray hfE45 node is deleted, Composer step 3-of-5 now exists, and components grew to 93 with a new … / V2 / shell family (Movement Strip, Instrument Strip, Context Spine, Navigator, Inspector, Evidence & Execution Drawer, Command Bar, Status Bar, Evidence Handle, Surface Header, Projection Slot, Surface Status, Operation Lifecycle, Governed System Workspace composer/projection) — the band grammar of every screen is being migrated to Command Bar / Workspace Bar / Context Spine / … / Evidence Handle / Status (verified mid-flight on 09.02: five bands renamed, two still old). Variables are at 135 with the mode axis. Standing items that remain: merge the still-untheed base tokens with ms2-* into one themed family; finish the band-grammar migration and then re-extract pen-truth.json once the wave lands (not before — extract against a moving file and the baseline is garbage); the state-matrix boards (loading/empty/error/offline/denied) and the light/high-contrast full proofs are still listed as open in Appendix F's own "explicitly not complete" list, which is now the authoritative pencil worklist and supersedes the §4.6 ordering for items it covers.

4.8 Six laws that prevent the atlas from regressing

Derived directly from the audit in §4A; each is mechanically checkable and each has a named test owner in §4B.6.

1. Chrome is never optional. A surface is not designed until its explorer, inspector and drawer are drawn populated for a real selection. A centre-canvas-only board is a sketch, not a specification.
2. One state is no state. Every family ships its state matrix before any of its subpanes is called complete. The happy path alone is a screenshot, not a product.
3. A component must prove it generalises. Any anatomy used by more than one semantic kind must differentiate by kind, or it is wrong for all of them.
4. Nothing decorative may occupy an instrument's slot. A minimap, chart, map or sparkline renders the data of the surface it sits on, or it is deleted.
5. Effect and truth travel with the control. No control whose effect exceeds read-only renders without its effect mark; no measured-looking figure renders on a designed board without its fixture mark.
6. Never restructure a master that instances override. Change properties, widths or content; export every affected board first. (Written in blood — see the incident note in §4A.5.)

Build score §4A — Design gap audit — the atlas measured against its own specification

Date of audit: 2026-08-18, against the 13:30 atlas save (102 boards / 93 components / 135 variables). Method: every board of the six critical surfaces exported at 2× and read at full resolution — graph (04.01–04.06), state (09.04–09.06), identity (09.01–09.03), telemetry and product (10.01–10.05, 11.01–11.02), fabric (13.01–13.02), intelligence (12.01–12.07) — then re-measured programmatically for text overlap, clipping, and empty area. This section is the honest counterweight to Appendix F/G/H: those record what the design wave delivered; this records what it still gets wrong, and §4B is the program that closes it.

4A.1 The root cause — one hero still-life per surface

Every board is a single frozen moment of one surface, in its calmest state, showing the centre canvas only. Three consequences follow, and they explain nearly every specific defect below:

1. Chrome is designed once. The left explorer, right inspector, and evidence drawer are collapsed to dot-strips on every board except 09.01. The interaction model that §8.4, §12.5, and §6.7 are built around — selection flowing into an inspector, evidence arriving in a drawer, a navigator scoping a query — is drawn a single time in the entire atlas. The reviewer sees the middle third of each tool and correctly concludes it is unfinished.
2. Only the happy path exists. Every board is SOURCE · designed · 11s. There is no loading, empty, partial, stale, offline, permission-denied, failed, executing, or recovery state for any surface, even though §18.1 makes twelve data states mandatory and §8.16 makes the non-happy path a first-class product contract.
3. One instance per idea. Because each concept appears exactly once, nothing forces the anatomy to prove it generalises — which is how kind-agnostic cloned cards and a decorative minimap survived review.

4A.2 The six systemic failures

4A.3 Per-surface findings

Graph (04.01–04.06) — the heart, and the most strained. 04.01 was not a graph: fourteen island grids joined by a single generic labelled edge each (renders, INSERT session, MATCH friends), no typed ports crossing islands, unattached edge pills, and one wire terminating in empty space — beneath a caption claiming "typed, live, editable as ONE graph." Its counts (166 nodes, zoom 36%) have no defined denominator, violating the §8.4 rule that canvas stats name their own denominator. 04.02 is a poster (S4) with only four nodes and, critically, no compiler finding — although Journey B makes an intentional contract error and its precise finding the acceptance test. 04.05 states depth×density orthogonality in a prose panel instead of showing the matrix, and leaves ~60% of the canvas empty with three disagreeing level indicators (L0 Product selected, L2 scope chip, MIXED · PRODUCT L2). 04.06 is the strongest board in the file — the drag-compatibility grammar with real code citations (connect.kt:15, Edge.kt:22, Graph.kt:224) is exactly the standard — but its context menu floats unanchored over empty canvas.

State (09.04–09.06). The query safety bar and FIXTURE DRAFT · UNPREPARED state are right. But the results grid is three rows with no virtualisation, paging, truncation or column types, and nothing is masked despite the bar claiming masked; a second subtab strip is nested inside the page duplicating the family strip above it; the §12.5 systems→namespaces→entities navigator is absent everywhere; parameters (:since, :circle_id) have no inputs; and Export CSV/JSON render as bare links on fixture data with no governance mark. 09.05 leaves ~60% of canvas empty, prints "estimated · not observed" five times instead of an estimated/actual structure, and shows a progress bar on a migration chipped FIXTURE · NOT OBSERVED. 09.06 renders a Restore control as enabled inside a panel whose own text says every backup fact is UNKNOWN.

Identity (09.01–09.03). 09.01 is the one board with full chrome and the densest, most complete policy story — propose → simulate → blast radius → negative tests → approve → audit receipt — and should be the template for every other surface. 09.02 was the weakest board in the atlas (S2, S3, S6 together). 09.03's simulator verdict with a policy-file citation is excellent; its KPI tile labelled "Healthy 8" uses configuration-as-health vocabulary the truth bar forbids, and its tiles carry no truth chips.

Telemetry and product (10.x, 11.x). The strongest section: the causal trace map, the flame graph with correlation to a specific commit, and error triage with "Open in Graph → ChatActor" deliver the graph-linked-evidence promise better than anything else in the file. The weakness is dataviz literacy — metric charts are unlabelled lines with no axes, units, legend or thresholds, and the eBPF panel is two decorative sparklines. Alerts and pipelines are strong and honest.

Fabric (13.01–13.02). Dense and honest — UNKNOWN observed-state throughout, effect-classed operations that render as blocked with reasons, and jump-outs to specialist consoles. But "Topology" is the selected tab on a board that shows a flat inventory list and no topology; the two boards overlap ~70% in content while presenting different subtab sets; and 13.01 had a text collision in its OBSERVED header and cost panel.

Intelligence (12.x). Chain Builder is clean and the studio genuinely expresses "typed, budgeted, guarded, attributable." The sample-run panel labels itself DESIGN FIXTURE while presenting exact token, cost and latency figures in the register of measurement — the same category error as S2, one level subtler.

4A.4 What the audit does not dispute

The visual language itself is right and must not be restarted: dark, dense, instrument-grade, provenance-in-colour, mono reserved for data. The governance vocabulary (sealed plan, independent approval receipt, effect marks, empty-reason) is a genuine invention. The type ramp is now clean (zero nodes at or below 10px, from 6,520 before). Pencil reports 7 clipping problems file-wide, down from 84 on one board alone. The direction is correct; the failures above are of completeness and consistency, not of taste.

4A.5 Verified rendering repairs

1. Node-card and scope-summary masters hardened — head, body, port rows and footer now clip, so no instance can render text outside its card.
2. Contract-demonstration cards widened (04.06/A/B to 300px, 04.02 to 285px) and verbose port labels reduced to the contract they name (ProviderPort<AuthService> → AuthService; the provider pin glyph already carries the role, per §8.5's "a pin is never just a decorative handle").
3. Eight over-long island titles shortened on 04.01 (gcp.ce/otel-collector → otel-collector — the island header already says GCP Compute Engine), clearing every head collision on that board.
4. 09.02 rebuilt for truth and privacy: subtitle now reads session adapter not connected; the scatter is relabelled SESSION DENSITY BY REGION · FIXTURE · no geo adapter — counts only; 21 identifiers masked (IPs to 103.21.•.•, handles to sa•••); the table header carries real pagination (page 1 of 6,017 · masked by policy); and Revoke all became Revoke all… preceded by an EffectMark (production destructive) and a PermissionGate (approval required).
5. Sample number removed from the security CTA (Run security scan · 142 checks → Run security scan).
6. Context-spine truth chip shortened so it no longer collides with the freshness chip, which also collapses the four different spellings of the revision into one.
7. Kind legend moved out from on top of the AuthService card on 04.04.
8. Measured result on the repaired boards: 04.04 and 09.02 now register zero text overlaps; 04.02 6→1, 04.06 7→1, 04.01 6→0 (the two residual items are floating pills over cards, listed in §4B.1).

Incident, recorded for honesty. An attempted structural fix (wrapping the card title in a clipping frame) silently dropped the per-instance name overrides on all 47 node cards and 5 scope summaries, because Pencil keys overrides by descendant path. All 52 labels were reconstructed from pre-change exports plus the surviving layer names and re-verified by render. Two lessons now bind this program: never restructure a component master that instances override — change properties, widths or content instead; and export every affected board before touching a master, because the export is the only recovery source for override data.

Build score §4B — The correction program — from atlas to cohesive product

Six workstreams, ordered by leverage. Each names its unit of work, its acceptance, and the phase of §19 it belongs to. The governing rule is Appendix F's own: propagation, not proliferation — improve the shared contract, prove it on one vertical, then migrate a family. Never add another impressive disconnected board.

4B.1 Finish the rendering-integrity sweep (Phase 1)

Residual items: the fanout · push deliver pill and Cypher pill on 04.01 (repositioned but still crossing card edges at some zooms), the Session{uid} pill over the AuthService footer on 04.02, the drop-receipt panel over the card title on 04.06, and the WATCH panel clipped at its scope edge on 04.02. Root fix rather than nudging: wire labels and floating panels get an authored anchor slot — a label belongs at the wire's midpoint offset perpendicular to the path, and a receipt panel belongs in the canvas overlay layer with collision avoidance against node bounds. Acceptance: zero text overlaps on all 04.x boards at 100% and at Fit zoom, verified by the overlap scan committed as a design test.

4B.2 Kind-differentiated node anatomy (Phase 2, blocks S5)

One master is not enough. Author one card variant per semantic kind — Route, Screen, Service, Repository, Actor, Edge/Worker, Store, Topic, Agent — each with its own legal port vocabulary (a Route has routeBinding/navBinding; a Repository has get/update/sqlAdapter; an Actor has mailbox/schedule/state, never a screen port). Add the three density forms §8.5 requires (Focus, Standard, Expanded) so semantic zoom has real targets. Acceptance: no port label appears on a kind whose contract cannot own it; the parity test asserts kind→port-vocabulary conformance.

4B.3 Chrome in context — the largest single credibility win (Phase 2–3, blocks the root cause)

Promote 09.01 from exception to template. For each of the six critical surfaces author the board with explorer, inspector and drawer expanded and populated for the current selection — the inspector showing the §8.11 tab set for the selected entity, the drawer showing the §8.12 lane that surface actually contributes to, the explorer showing the scoped navigator that surface needs (systems→entities for State, scopes→findings for Graph, providers→resources for Fabric). Simultaneously, evict the poster panels (S4): the taxonomy legend becomes the canvas legend organism, the interaction-grammar table becomes the keyboard-map overlay, the advantage strip is deleted outright — competitive claims belong in the plan, never in the product. Acceptance: every critical surface has one board where all three chrome regions are live, and no board contains a reference table that is not itself a product surface.

4B.4 Instruments that encode data (Phase 3)

The minimap becomes a real semantic minimap per board: node density of that canvas, a viewport rectangle, finding and change marks (§8.4). 09.02's session density becomes a genuine geographic or treemap encoding with a legend and units. Metric charts gain axes, units, thresholds and deploy markers (§13/§16). Query plans gain estimated-versus-actual columns with cost encoding rather than repeated "not observed" strings. Fabric's Topology tab gains an actual topology projection. Acceptance: no chart, map or minimap renders content unrelated to the board it sits on; every axis has a unit.

4B.5 The state matrix — from one moment to a product (Phase 3–4)

Author the twelve §18.1 data states once as a state-matrix reference board per family (not per subpane): loading, live, source-only, fixture, known-empty with the query that produced zero, partial with per-region provenance, stale with age, unknown/not-wired naming the missing adapter, failed with retained prior data, permission-denied without leaking counts, high-volume virtualised, and no-selection with a next action. Then apply the family's matrix to its subpanes by variant, never by clone — the ×9 Composer and ×5 Deploy deep clones are the anti-pattern to retire as those boards are next touched. Add the missing interaction chrome catalogue: context menus, tooltips, toasts, confirmations, and the keyboard reference. Acceptance: every family has a state matrix; MachineSignalSubpaneRenderTest gains a state dimension; no state is represented by a spinner or a bare em-dash.

4B.6 Truth and governance conformance, globally (Phase 1–2, continuous)

Sweep every board for the S2/S3 classes: any figure in the register of measurement on a designed board carries a fixture mark or is removed; any control whose effect exceeds read-only carries an EffectMark and, above non-production write, a PermissionGate; any sample identifier (rc-812, 142 checks, tr_8f21c, v811) is replaced by a generic contract per Appendix B; status bars never contradict their cards. Then make it mechanical: a design-conformance test that fails when a board contains a destructive-verb control without an adjacent effect mark, or a metric-shaped string on a fixture board without a truth mark. Acceptance: the conformance test passes file-wide and runs in the same suite as the parity harness.

4B.7 Sequencing and the pipeline consequence

4B.1, 4B.6 and the remainder of 4B.2 land in Phase 1–2 alongside the engine's identity and context work, because they are cheap and they are what makes the atlas presentable. 4B.3 is the flagship of Phase 2–3 and should be scheduled as one focused cohort — six boards, one week — because it is the single change that converts "half-baked" into "product." 4B.4 and 4B.5 follow the wiring order in §19 so that a board never claims an instrument the engine cannot yet feed. Throughout: pen-truth.json is re-extracted only at cohort boundaries, never mid-wave, and the parity budgets are re-baselined deliberately with reasons recorded — tightening where the kit converged, never deleting a failing gate.

6. Global shell, element by element

6.1 Native window and lifecycle

6.2 Global top bar

6.3 Workspace bar

The second row carries:

• customizable workspace switcher and shortcuts;
• mission chip and progress;
• semantic breadcrumb from product -> runtime island -> graph scope -> entity;
• lens switcher appropriate to the workspace;
• omnibox with typed search scopes;
• command-palette button and shortcut;
• back/forward, open-alongside, pin view, copy deep link, and context export.

The bar never repeats the same hierarchy in three places. Breadcrumb is canonical; rail and canvas selections project it.

6.4 Command palette and omnibox

The current mixed node/task palette becomes the universal command surface:

• prefix-free ranked search across entities, scopes, symbols, files, operations, runs, missions, findings, docs, evidence, and extensions;
• optional filters such as > action, @ agent, # finding, :kind, env:, owner:, truth:, since:;
• natural-language questions compile into visible graph queries, never hidden actions;
• every result states type, scope, provenance/freshness, shortcut, and action effect;
• destructive or remote work can only open a plan; the palette cannot bypass governance;
• command history, favorites, and recent context are workspace-scoped;
• Enter opens, Cmd/Ctrl+Enter opens in specialist tool where applicable, Shift+Enter opens alongside, and actions expose consistent key hints.

6.5 Left navigator

The navigator is a projection of current context, not a different navigation model per pane. It supports:

• scope tree, outline, or domain catalog depending on workspace;
• search, filters, saved views, sort/group, density, and collapse;
• counts with truthful definitions and virtualized large lists;
• drag/drop only where it emits a valid typed command;
• multi-select, range select, context menu, keyboard tree navigation;
• inline freshness, owner, status, finding, and change markers;
• reveal in graph/source/tool;
• resizable width, overlay compact mode, and remembered per-workspace state.

6.6 Center workspace

The center is a pluggable template host: graph canvas, preview, editor, table, timeline, comparison, mission, or plan. It owns primary work, not permanent explanatory hero cards. Every view supports loading, partial, empty, stale, offline, error, permission-denied, and high-volume states.

6.7 Inspector

The right inspector follows selection and uses a shared anatomy:

1. identity and truth;
2. summary and owner;
3. context-specific tabs;
4. relationships and blast radius;
5. source/config/contracts;
6. runtime/evidence;
7. available operations with effect labels;
8. agent explanations/proposals;
9. history.

Graph inspector tabs remain Inspect, Ports, Runtime, Source, Telemetry, and A11y, but each becomes data-backed. The current repeated not sampled strings are a temporary honest state, not a finished inspector.

6.8 Evidence drawer

The drawer is one event/evidence plane with views:

• Runs;
• Logs;
• Traces;
• Network;
• Tests;
• Build;
• Diagnostics;
• Changes;
• Agent activity.

Each record shares time, run, entity, scope, environment, revision, principal, truth, and evidence identity. Selecting a log can reveal its span, graph node, source, release, mission, and run without manual re-search. New evidence expands the drawer only when it is relevant and user preferences allow it. Counts are live, defined, and never sample constants.

6.9 Status bar

The status bar shows only durable context: workspace/revision, environment/targets, selected scope, index/connection state, active run/plan, evidence freshness, CPU/memory if diagnostic mode is enabled, and keyboard/help entry. Each segment is interactive and accessible. No duplicated decorative counts.

6.10 Cross-cut interaction states

Every interactive element must specify:

• pointer, keyboard, and screen-reader operation;
• hover/focus/selected/disabled/loading/error/permission states;
• optimistic behavior, if any, and rollback;
• undo/redo semantics;
• telemetry and audit semantics;
• offline behavior;
• context effect and deep-link behavior;
• high-volume/virtualization behavior.

Complementary. The constitution's tables above state target behavior per shell element. The build score below adds each element's verified current state on the running build, the phase in which it changes, and the dead chrome to delete.

Build score §5 — The shell, element by element

Every element seen on screen, with its target. (Constitution §6 sets the laws; this is the per-control work list.)

5.1 Window & lifecycle

5.2 Mode strip

Current: 12 visible modes, icons + selected chord cap, horizontally scrolling, three dead chords (D5), design-file order divergence. Target (Phase 1): all 12 chords bound and gated by ModeShortcutParityTest; strip order becomes the canonical order everywhere (pen, React renderer, docs); each tab gains a wiring-truth underline while its family is <50% wired (D1); tab context menu: "Open in new window (read-only)" (Phase 6), "Copy deep link". The App ghost mode is deleted as an enum entry and folded into DevTools/Preview permanently (its alias already exists; delete the dead branches).

5.3 Context row (breadcrumb bar)

Current: BESTBUDS / DEVTOOLS / DEVICES + right-side truth chips ("rendered live · LIVE", "153 resources", "66 gated SRC") — per-pane, inconsistent, non-interactive. Target (Phase 2): the row renders WorkbenchContext — app / mode / subpane / graph scope / selection — every segment clickable (3.1), followed by the pane truth summary (already computed as paneTruth()), the mission chip when active (3.4), and ⌘[ ⌘] history buttons. This is the constitution's workspace bar, grown from the existing ContextBar component rather than new chrome.

5.4 Left rail

Current: Graph mode has the good rail (search + grouped entities + counts + legend); operational modes have provider-grouped DomainNavigator; UI/AI have a dead search box; DevTools header shows "0 · 162 ops" against an empty list; collapse state is forced open on mode switch. Target: one navigator component with per-mode projections (Phase 2) — (a) count semantics fixed: header shows <resources> res · <ops> ops with a tooltip defining each (the "0 · 162" confusion dies); (b) UI mode rail lists the component inventory (it exists — the Canvas gallery's registry) and AI mode lists models/prompts/chains once wired (§15); (c) rows carry truth dot + provenance + finding badge uniformly; (d) collapse state is user-owned and persisted (G7); (e) rail rows and canvas/list selection are the same WorkbenchSelection (G1); (f) Insights/Analytics rails stop duplicating by scoping to their subpane families (D5 note: they share a domain — the projection filters by family). Virtualize at >200 rows (the Cloud rail's 138 workers already justify it).

5.5 Search (D15)

Phase 2 ships WorkbenchSearchService + scope presets. Toolbar box = current-mode scope; / focuses it (already-standard key on every pane); ⌘K = everything overlay (kept exactly as-is visually, gains findings/runs/docs result kinds and the verb fabric on each result); rail boxes become thin filters over the same index. One ranking implementation, one highlight style, Enter/⌘Enter/Shift+Enter = open / open-in-IDE / open-alongside (constitution §6.4).

5.6 Inspector (right rail)

Current: excellent for Graph (identity/ports/runtime/source/telemetry + IDE jump), stub card for 10 of 13 modes ("Selection: none"), Ports tab duplicates Inspect, aux tabs are literal "not sampled". Target (Phase 2 for the shared anatomy; per-mode depth lands with each pane's phase):

1. One SelectionInspector renders WorkbenchSelection in every mode with the constitution's §6.7 anatomy: identity+truth · summary/owner · kind-specific tabs · relationships/blast radius · source · runtime/evidence · operations (with effect chips, via the verb fabric) · history (runs touching this entity).
2. Graph inspector tabs get their real feeds as the framework levers wire: Ports becomes the port-centric view (contract, provider/consumer, connection state, last PortEvent, live value when evidenced — distinct from Inspect at last); Runtime reads ActorStatus/lifecycle for actor nodes and stays "not sampled" only where sampling truly doesn't exist; Telemetry waits for §13's evidence pipeline and says so; A11y renders the accessibility inventory slice for UI nodes and "Not applicable" otherwise.
3. The resize grip from the dead SideInspector.kt is the one thing worth salvaging into ShellInspector before that file is deleted.

5.7 Evidence drawer

Current: 7 tabs, live counts (plus dead fallbacks), run ledger with cancel/retry/redaction, Diagnostics merging wiring+resources+runs; auto-opens on new runs politely. Target: D10 (truthful counts, new feeds) + 3.3 (shared records, cross-navigation) + per-record verb fabric; drawer height draggable and persisted; F6 cycles header→rail→content→inspector→drawer (constitution §18.3); drawer strip summary stays. Diagnostics grouping (D7c) with severity ordering; each Diagnostics row deep-links to its owning surface (a wiring row opens Graph with the lens on that port; an OPEN_QUESTIONS row opens its doc anchor).

5.8 Status bar & keyboard

Status bar stays lean: workspace·app / mode / graph counts (+ warnings only when a real diagnostic source supplies them — the current warnings: null honesty keeps) / env·tasks·resources / last run. Every segment becomes clickable (env → selector, counts → drawer tab, last run → run detail). Add: context deep-link copy button, and a ⌘/ keyboard-map overlay generated from the manifest (D8) — the overlay is also the pen keyboard-reference board's twin (§4.6.4).

5.9 Deletions (Phase 1, gated by DeadCodeAbsenceTest)

panes/SideInspector.kt (salvage grip), shell/WorkbenchCollapseChrome.kt, graph/TreePanel.kt, ScreenPreviewPanel, RailModeRow/RailGraphRow/RailNodeRow, modeToolbarIcon, dead MetricTile(WorkbenchMetricFixture) + its fixture import in atoms, BottomDrawerTab fallback counts, ReaktorMode.App enum entry + branches, legacy COMMON/prototype/ui/MachineSignal.kt after import migration (D6). ~900 LOC net deletion before any new chrome is written.

7. Canonical technical architecture

7.1 Separate program, observation, history, and presentation

Do not declare the mutable runtime Graph, current GraphDocument, or current architecture projection individually canonical. Introduce a pure KMP :reaktor-graph-model module:

GraphSpec       desired, editable semantic program
GraphSnapshot   immutable revisioned materialization of claims and evidence
GraphDelta      ordered change set and event stream between revisions
GraphViewState  layout, viewport, selection, expansion, lens
GraphDocument   versioned authoring envelope {spec, viewState, baseRevision}
live Graph      one owned runtime activation of a validated GraphSpec

reaktor-graph-model depends only on reaktor-core, serialization, and immutable collections. It must not depend on Compose, the live graph runtime, DBs, Tooling, provider SDKs, Desktop, or BestBuds.

Core stable identities include GraphId, ElementId, PortId, EdgeId, ContractId, SchemaId, EvidenceId, and Revision. Identity derives from namespace plus logical key—not a random runtime UUID, label, list index, or canvas coordinate.

7.2 Evidence model

Every claim links to one or more evidence records:

data class EvidenceRecord(
    val id: EvidenceId,
    val sourceKind: SourceKind,
    val sourceId: String,
    val locator: String?,
    val observedAt: Instant,
    val validUntil: Instant?,
    val contentHash: String,
    val authority: Authority,
    val confidence: Double?,
    val rawArtifactRef: String?,
)

data class Claim(
    val subject: ElementId,
    val predicate: String,
    val value: JsonElement,
    val evidence: Set<EvidenceId>,
    val plane: Plane, // desired or observed
)

TruthClass is a UI/policy projection over evidence. It is not stored lineage. Imported configuration may prove existence/configuration; it cannot prove live health. Contradictory claims remain queryable and create a conflict finding.

7.3 Registry and source tiers

GraphSource implementations emit evidence-backed fragments. A registry merges and indexes them without erasing disagreement:

• Native Reaktor runtime/source;
• Wrapped typed service;
• Source-scanned/imported code;
• Runtime-observed dependency;
• Desired infrastructure/configuration;
• Observed provider state;
• Tooling/operation catalog;
• Tests, telemetry, analytics, release, ownership, and policy sources.

Trust tier determines legal operations. A scanned Python handler can be inspected and patched through source review; it cannot pretend to have native live mutation capabilities. A brownfield entity can mature from Observed -> Scanned -> Wrapped -> Native without changing logical identity.

7.4 One complete loop

1. Inspect: sources emit fragments; registry materializes and indexes a snapshot.
2. Edit: GraphEditorSession issues pure commands against a base revision and produces a GraphPatch plus inverse.
3. Compile: deterministic passes validate contracts/capabilities and produce findings plus a sealed compile/materialization plan.
4. Plan: source/config/runtime changes become a canonical plan containing exact diff, effect, blast radius, tests, capabilities, rollback, and fingerprints.
5. Authorize: call-time policy verifies principal, resource, environment, plan, and required approvals.
6. Run: local activation returns an owned handle; external work enters the generic Tooling executor.
7. Observe: runtime, provider, run, test, and telemetry events produce evidence and ordered deltas.
8. Persist: append-only deltas and periodic content-addressed snapshots restore the identical spec hash, indexes, findings, runs, and evidence.

The decisive non-BestBuds acceptance journey is: create a five-node workflow; connect typed ports; introduce a contract error; receive a precise finding; fix it; compile; approve; run; observe values/events; close Desktop; reopen with the identical spec hash/history; query the journey through MCP.

7.5 Dependency direction

reaktor-core
  -> reaktor-graph-model
    -> graph-port / service / tooling kernels
      -> graph runtime / registry providers / compiler
        -> reaktor-flow
          -> extension SDK / MCP adapters
            -> Reaktor Desktop
              -> BestBuds providers and shell composition

Generic operational types now duplicated in BestBuds Engine converge on reaktor-tooling. BestBuds retains catalog/provider/product adapters, never a fork of the platform control plane.

7.6 Runtime ownership and lifecycle

• Replace raw app.graph() with inspectable GraphManifest and explicit openGraph(): OwnedGraphHandle.
• Read paths consume manifests/snapshots and start no actor, coroutine, DI graph, or provider session.
• OwnedGraphHandle and BorrowedGraphHandle make close responsibility explicit.
• Attach rejects an already-owned node.
• Detach disconnects edges, unregisters DI/ports, persists actor state where configured, cancels scopes, and closes exactly once.
• Connections are transactional: listener failure cannot leave half-connected endpoints.
• Runtime actor storage keys include tenant/workspace/graph/actor identity.
• Fix or replace the bespoke concurrent map before trusting it with model state; add model checking and forced-resize stress tests.

7.7 Contracts and polyglot boundaries

Ports connect by stable ContractId plus schema compatibility, direction, cardinality, and capability requirements—not display strings or JVM KClass identity. KSP generates canonical ContractDescriptors from serializers/service handlers with operation ID, request/response/event schemas, error algebra, version rules, and capabilities.

Canonical JSON defines hashes and golden fixtures. FlexBuffer is an optional high-performance encoding. Envelopes carry contract/schema version, correlation/causation, deadline, cancellation, and structured errors. TypeScript and C++ generation ships only after Kotlin<->TS and Kotlin<->C++ conformance proves round trips, unknown-field handling, version negotiation, cancellation, streaming/backpressure, and error parity.

7.8 Extension SDK

interface ReaktorExtension {
    val descriptor: ExtensionDescriptor
    fun contribute(to: ExtensionRegistry)
}

Independent contributions include GraphSource, GraphValidator, GraphMaterializer, RuntimeActivator, InspectorProvider, OperationProvider, ToolProvider, RendererProvider, and schema codecs. Each declares stable ID, version, compatible model version, capabilities, trust tier, permissions, and unload behavior.

JVM Desktop uses signed/local manifests plus ServiceLoader; JS/native use generated static registries. The extension SDK depends on graph model/tooling SPI, never Compose/Desktop or BestBuds. The first proof is an independently built sample JAR which adds a source, inspector, and safe operation and can be removed cleanly.

7.9 Tool Cooperation Protocol

Every integration implements the smallest applicable capabilities:

Discover   enumerate entities/capabilities
Inspect    return evidence-backed detail
DeepLink   open exact context in the specialist
Propose    return a diff/patch/plan without applying
Execute    run an approved typed operation
Observe    stream status/evidence
Import     contribute facts/artifacts
Export     accept a redacted verified context pack

Initial first-class partners:

7.10 MCP and agent boundary

• reaktor-mcp is a protocol adapter, not business logic.
• The local read server remains separately deployable and contains no executor dependency.
• Every launch has an owner-readable rotating capability credential and instance identity; loopback alone is not authentication.
• Read tools expose snapshots, queries, detail, findings, evidence, and deltas with pagination and bounds.
• A separate mutation broker accepts only typed patches/task invocations, returns a dry-run/sealed plan, verifies call-time agent identity/scope/approval, and invokes the same executor as the UI.
• Sessions support cancellation, streamed progress, deadlines, and immutable audit correlation.
• An agent cannot satisfy a human approval or separation-of-duty requirement.
• No unrestricted Graph.execute() remote primitive exists.

Build score companion. The framework workstream below sorts the architecture above into levers that exist today (wire now) and gaps that must not be pretended away (blockers), each phase-tagged. It pairs with Appendix C's leverage map.

Build score §18 — Framework workstream — the levers and the blockers

The Desktop plan pulls these framework tasks in dependency order. (a)-items are ready levers being wired; (b)-items are gaps that must not be pretended away.

18.1 Wire now (Phases 1–3): wiringReport() overlay+Diagnostics · ReaktorFlowScopeView/levels deep-linking · ReaktorGraphLens full UI · PortEvent live stream · ActorStatus supervision panel · MachineSignal NotWired/Provenance primitives everywhere · ShellKit consolidation · tooling spine (plans/fingerprints/phrases — already live) · Graph.toJsonElement()/ArchitectureSnapshot.encode() as MCP resources · accessibility inventory · frameGraphReadable/mergeGraphNodes (already shipped — keep) · AuthRequirement/LocalAuthorizer simulator · service cross-runtime ports for remote panes later.

18.2 Fix before scale claims (blockers, phase-tagged):

18.3 Dual-surface discipline. Every framework change above ships kernel-first (plain API), graph projection second, Desktop consumption third — reaktor-auth remains the reference. New modules this plan implies (reaktor-graph-model at Phase 6 per constitution §7.1) follow the same rule.

8. System Canvas / Graph Studio — the heart of Reaktor

The graph must become the common semantic surface on which a human, an agent, and every specialist tool can understand, author, prove, run, and govern a system. It is not a larger node diagram and it is not an attempt to force source code, databases, cloud consoles, or telemetry into one visual metaphor.

The honest current baseline is a promising topology inspector with real rendering, selection, hierarchy, operational overlays, and low-level connection primitives. The shipping Desktop does not yet provide a complete semantic edit → compile → plan → authorize → run → observe → persist loop. The document editor is still view-only, the current command session is in-memory and single-owner, and compiler/debug/replay capabilities remain designs. Until the graph gates below pass, the product language is Graph Studio preview, not “more powerful than Blueprints.”

The target is deliberately higher than a Blueprint clone:

Reaktor must first earn a Blueprint-grade typed behavior-authoring and debugging loop. It then surpasses that baseline by preserving one stable semantic identity across desired architecture, source, runtime, state, data, infrastructure, tests, telemetry, releases, governed operations, evidence, humans, and agents—even for brownfield and polyglot systems which do not run on Reaktor.

8.1 Benchmark, boundary, and durable advantage

The product bar combines several proven interaction traditions without importing their limits:

Reaktor does not win by drawing more boxes. It wins when one ElementId survives every transition: repository scan → semantic query → source symbol → runtime activation → trace span → deployment resource → incident → proposed change → approved plan → result evidence.

8.2 One canvas, six independent dimensions

Every visible graph is a deterministic projection, never a new source of truth:

SystemCanvas = Snapshot × Query × TruthPlane × Time × Lens × Level × Density × GraphViewState

The four primary movements are fixed across every width and input mode:

• Map — understand topology, contracts, ownership, boundaries, dependencies, and change impact.
• Trace — follow causal execution, values, messages, state transitions, latency, failures, and evidence through time.
• Validate — inspect findings, contracts, tests, policies, drift, accessibility, performance, and release gates.
• Act — propose a typed change or operation, review its exact plan, authorize it, execute it, and verify its result.

These are movements through the same model, not four graph products. Interface, Source, State, Identity, Intelligence, Runtime, Delivery, and Product are instruments/lenses, not competing top-level taxonomies.

8.3 Semantic depth and progressive disclosure

Scope—not canvas nesting, process, or actor—is the primary semantic hierarchy. Breadcrumb, outline, minimap, double-click/Enter, Escape, back/forward, deep link, and programmatic GraphLink all update one GraphViewState.

Below the readable threshold, detailed cards do not shrink into illegibility. They become region summaries, contract bundles, heat maps, path ribbons, finding/change marks, and counts. Entering a region restores the last local viewport, selection, lens, truth plane, and time window. Fit may contain the complete topology in overview LOD, but it never claims that 6 px labels are readable.

8.4 Full Graph Studio anatomy

The full canvas is powerful because every region has one job and shares the same context.

Studio control deck

The two-row deck replaces the current overlapping Graph/Container/System/Component/Code vocabulary.

Row 1 — intent and revision

1. Map / Trace / Validate / Act movement switch.
2. Explore / Edit / Debug / Compare interaction mode. Modes never rename movements.
3. Structured omnibox for graph query, command, symbol, contract, run, revision, or evidence lookup.
4. Current revision and snapshot hash summary.
5. Draft-change indicator (ΔN) opening the Changes drawer; absent when no semantic patch exists.

Row 2 — projection contract

1. Named semantic level (L2 Scope), with inline depth controls.
2. Base lens and up to two overlays, each removable and provenance-aware.
3. Desired / Observed / Compare plane.
4. Now / Snapshot / Replay time state and freshness.
5. Evidence coverage and unresolved finding count.

The deck is a reusable atom/molecule composition. It does not know BestBuds kinds, Compose, cloud providers, or Desktop pane state.

Left explorer

The explorer is the synchronized textual navigation and filter surface:

• Context: workspace, product/island/scope, environment, revision, branch/change set.
• Saved views: whole system, feature path, change impact, production now, incident, and user/team views.
• Scopes: virtualized hierarchy with counts, truth mix, findings, collapsed/expanded state, and keyboard navigation.
• Selection sets: named sets for comparison, review, blast radius, or agent context.
• Findings: contract conflicts, stale/unknown evidence, uncovered ports, cycles, policy failures, test gaps, drift, and performance risks.
• Filters: kind, contract, owner, source, truth, capability, effect, change, finding, release, environment, and time.

The explorer never becomes a second unsynchronized tree. Selecting, focusing, isolating, or expanding an item uses the same semantic IDs as the canvas and inspector.

Canvas

The canvas renders only the current query and LOD. Its persistent chrome is intentionally small:

• semantic minimap with viewport, finding/change/run marks, and clickable regions;
• zoom/fit cluster for selection, scope, all, actual size, and reset;
• bounded lens stack showing one base plus at most two overlays;
• time controller for now, snapshot, replay, play/pause/step, range, checkpoints, and replay barriers;
• interactive legend for relationship, truth, state, and proposal grammar;
• canvas stats whose denominator is precisely defined (75 visible / 12,480 indexed, not a context-free node count).

Search or live refresh preserves camera, logical focus, selection, and expanded state when their IDs survive. It never automatically reframes after the first useful landing unless the user asks.

Inspector

The inspector is selection-specific proof and capability, not another dashboard. Its header always shows stable ID, kind, scope, desired/observed status, truth origin/freshness, current revision, and whether the object is applied or proposed. Tabs are defined in §8.11.

Evidence and execution drawer

The drawer contains Changes, Agent, Run Timeline, Trace, Findings, Tests, Evidence, History, and Console. It can be collapsed to a truthful status strip without losing the active run/change context. It never hides a pending approval, failed verification, dropped event, replay barrier, or stale plan.

Context continuity

Changing level, lens, width, theme, or specialist tool preserves, where meaningful: workspace, system, selected IDs, environment, revision, change set, truth plane, time range, run/plan, and next legal action. Copying a GraphLink serializes that bounded context, not merely canvas coordinates.

8.5 Atomic graph grammar

The visual language is generated from a small semantic kernel. Every visual primitive has a model counterpart and an accessible textual representation.

Port roles

Data, Control, Stream, Request, Mailbox, State, and Value ports are different semantic roles. Provider/output connects to consumer/input. Compatibility is based on canonical contract and schema rules, not display strings or JVM KClass. Control scheduling never reuses mutable runtime DI ports as source IR.

Cardinality, ownership, cancellation, backpressure, error algebra, deadlines, replay class, capability requirements, and boundary transport are explicit where applicable. An unknown contract may be inspected but cannot silently become an executable connection.

Relationship grammar

Structural containment, typed data, control flow, service request/reply, event/pub-sub, state access, navigation, deployment, source declaration, test coverage, telemetry attribution, ownership, and causal execution are separate relationship kinds. A user can filter and query them uniformly; their renderer may vary by level.

Direction and state never depend on hue alone. Solid/ring pin shapes, arrows, dash/pulse patterns, labels, and textual legends preserve meaning in monochrome and high contrast.

8.6 Query, selection, lens, and deep-link model

The current presentation-object filter becomes a semantic query engine over immutable snapshots.

GraphQuery supports:

• kind, scope, contract, owner, source, plane, truth, freshness, capability, effect, permission, finding, release, change, and text predicates;
• bounded traversal by relationship kinds, direction, min/max depth, cycle policy, and maximum visited nodes;
• paths, neighborhoods, blast radius, affected tests, callers/callees, providers/consumers, ownership cuts, aggregates, and diffs;
• revision/environment/time comparisons and explicit truncation/page tokens;
• deterministic snapshotHash and queryHash on every result.

Indexes cover adjacency in both directions, kind, scope, contract, source, evidence, capability, finding, revision/change, and full text. Lenses are saved query/projection/layout specifications. A lens may add one base and two overlays only; components from mismatched revisions, environments, or time windows produce a visible misleading-lens finding.

Selection is a first-class ordered set with one focus item. It can represent nodes, ports, relationships, scopes, findings, evidence, or paths. Every surface supports Focus, Select, Add/Remove, Isolate, Compare, Trace from, Blast radius, Open source, Add to mission, and Copy GraphLink where legal.

8.7 Authoring and connection interaction grammar

Editing begins as a draft. No canvas gesture directly mutates source, an active runtime, infrastructure, data, credentials, or production.

The keyboard and pointer paths produce byte-identical canonical commands. A connection drop first creates a proposed relationship. It is visually and semantically distinct from applied topology until committed and observed.

Change lifecycle

Draft → Validating → Invalid | Planned → AwaitingApproval → Approved
      → Applying → Applied → Verifying → Verified → Receipt

Side states are Rejected, Cancelled, Expired, Drifted, Failed, RollingBack, and RolledBack. Truth, effect, permission, and lifecycle are independent fields.

• View history reverses GraphViewState locally.
• Draft undo/redo applies pure inverse semantic operations before commit.
• Committed revert is a new patch against the current revision.
• External rollback is a separately planned, authorized, executed, and verified operation. It is never represented as ordinary Undo.

Semantic commit uses compare-and-set against baseRevision and the exact source/snapshot hash. A stale writer receives a structured conflict and three-way semantic merge options; no update is silently lost. Collaborative cursors and comments come only after the single-writer revision/persistence model passes crash and conflict tests.

8.8 Compiler, findings, and materialization

A graph becomes powerful when it is a typed program with deterministic passes, not when its renderer accepts more node shapes.

The graph compiler pipeline is:

canonicalize
→ resolve identity/references
→ resolve contracts/schemas/types
→ validate direction/cardinality/cycles/boundaries
→ validate ownership/lifecycle/effects/replay
→ validate capabilities/security/policy
→ schedule control flow
→ lower typed IR
→ produce source maps, affected tests, materialization plan, and artifact hashes

Every pass has a stable ID/version, declared dependencies/read set, deterministic cache key, structured findings, and element/port source mappings. Errors leave the partial graph inspectable but block materialization/activation. Warnings never become silent coercions.

CompileBundle contains the input spec/snapshot hashes, model/compiler/pass fingerprints, findings, typed IR, source maps, capability/effect manifest, test-impact set, sealed materialization plan, and artifact hashes. Compiling the same input 100 times produces byte-identical normalized output.

Materialization targets are explicit:

1. a local preview/reference-interpreter activation;
2. generated or refactored source/configuration with exact diff and source map;
3. an external TaskPlan executed by the governed Tooling control plane.

The graph editor never calls a generic unrestricted Graph.execute(). External effects always use the same fingerprinted plan, authorization, approval, isolation, event, and receipt path as every other Reaktor operation.

8.9 Behavior vocabulary and Blueprint-grade baseline

The first executable vocabulary remains deliberately small and composable:

• Event, Pure function, Action, Branch, Sequence, Call, Return;
• typed local values and immutable activation inputs/outputs;
• structured success/error/cancellation;
• explicit deadlines, budgets, determinism and replay class;
• later: loops with bounded/cancellable semantics, fork/join, latent actions, reusable functions/macros, and actor/state adapters.

Durable or cross-activation state belongs behind actor/state/service contracts; it does not hide in node-local UI state. The reference interpreter is the semantic oracle. A generated/compiled backend must match its normalized output and event trace corpus before it is trusted.

Reaktor reaches Blueprint-grade baseline only when palette, typed connections, scopes/functions, refactors, compiler feedback, deterministic run, breakpoints, watches, step controls, value inspection, source maps, save/reopen, and reliable undo/revert all pass on a non-BestBuds example. “Beyond Blueprints” is earned only by the cross-system/evidence/governance proof in §8.18.

8.10 Runtime debugger, causal trace, and time travel

Debug time is separate from edit history.

Every DebugSession pins specHash, compileBundleHash, backend, seed, scheduler policy, environment, and capture policy. Breakpoints target semantic element/port/relationship IDs and support pure typed conditions and hit counts. Commands are Pause, Resume, Step Into, Step Over, Step Out, and Run To.

The runtime event envelope contains run/activation/event IDs, monotonic sequence, causal parent, wall and monotonic time, element/port IDs, phase, input/output value references, state hashes, evidence references, and redaction/truncation/gap flags. Compiler source maps link graph element/pin ↔ IR instruction ↔ generated/source span ↔ runtime activation.

Replay classes are explicit:

• Pure — safely recompute.
• Deterministic local — re-run inside the pinned sandbox.
• Recorded — replay the captured result/value.
• External or nondeterministic — requires a declared stub/recording or creates a visible replay barrier.

Rewind never replays a production side effect. It restores an authorized checkpoint and forks a sandbox replay. Actor/state adapters expose explicit checkpoint/restore at causal boundaries. Dropped, redacted, expired, or unavailable evidence remains a visible gap; Reaktor never invents a value to preserve animation continuity.

The time controller aligns runtime values, traces, logs, metrics, tests, releases, source revisions, graph deltas, and plans on one selected window. Scrubbing updates the same semantic IDs in the canvas, inspector, outline, and specialist tool links.

8.11 Inspector tabs and selection contract

Every tab implements no-selection, valid selection, removed/stale selection, loading, empty, live, mixed, stale, failed, fixture, offline, permission-denied, and high-volume states where applicable.

Selecting a port or relationship preserves its owning node/scope context. Selecting multiple entities switches to aggregate comparison/operation mode rather than showing an arbitrary “first” selection. If an item disappears during refresh, the inspector keeps a tombstone explaining which revision/source removed it and offers History/Compare.

8.12 Drawer, changes, agents, and execution

The primary action is never generic Apply. Examples are Review plan, Request independent approval, Apply approved plan #05 — 3 source edits, Start sandbox replay, or Run 14 affected tests. Its label, enabled state, effect mark, permission gate, and confirmation are derived from the same typed operation contract.

8.13 Truth, effect, permission, and proposal state

Four independent semantics are visible wherever they govern interpretation or action:

1. Truth: Live, Source, Inferred, Imported, Stale, Partial, Fixture, Failed, Unknown—plus origin, revision, asOf, and TTL. Topology truth and runtime-signal truth are separate. Mixed views show counts such as 128 Source · 16 Live · 3 Stale · 2 Unknown; they never display a global LIVE badge.
2. Effect: View Ephemeral, Local Document Write, Source Write, Non-Production Runtime Write, Production Reversible Write, Credential/Policy Write, Data Migration, Destructive/Irreversible. The visible and approval effect is the maximum transitive effect, not the apparent simplicity of the gesture.
3. Permission: Allowed, Approval Required, Independent Approval Required, Denied, Policy Unavailable, Expired/Drifted—carrying subject/session, scopes, policy/version, reason, decision time and expiry.
4. Lifecycle: Draft, Invalid, Planned, Awaiting Approval, Approved, Applying, Applied, Verifying, Verified, Failed, Rolling Back, Rolled Back, and the side states in §8.7.

Fixtures and unknown-policy views are mutation-disabled by default. Stale/partial/source/config evidence may inform a proposal but cannot satisfy a live production precondition. An agent or Critic can propose or review; neither can approve/apply its own work or count as an independent human.

8.14 Keyboard, accessibility, and textual parity

The canvas is one composite widget with a synchronized virtualized Outline/Table alternative. Every inspect and draft action is available in both representations.

Nodes, ports, relationships and scopes expose role, name, selected/expanded/disabled state, truth/effect/permission/proposal description, custom actions, and live-region announcements for validation, approval, execution, verification and rollback. Focus survives delta refresh, LOD transition, filtering, and time scrubbing when the logical ID remains.

Release minima:

• no essential rendered graph text below 12 sp at any LOD;
• 44 × 44 screen-pixel effective target for ports and controls, even if the visual pin is 8–10 px;
• 2 px visible focus ring with at least 3:1 non-text contrast;
• normal text at least 4.5:1;
• labels, shape, arrow and pattern preserve meaning without color;
• keyboard-only and VoiceOver/NVDA/Orca completion of query → connect → validate → approval → apply → verify → rollback;
• usable Outline/Table, inspector, and commands at 200% scale, high contrast and reduced motion.

8.15 Rendering and scale architecture

The canvas may show a 100,000-node system without composing 100,000 rich cards.

• Registry tier: persistent indexed maps and adjacency for up to 100k nodes / 300k relationships with no Compose/UI objects.
• Query/projection tier: a bounded 1k–10k semantic slice with delta-maintained indexes, aggregation and compiler dependencies.
• Visible scene tier: normally at most 250 rich cards, using viewport culling, spatial index, semantic LOD, edge bundling, scope portals and cached minimap atlas.
• Runtime/evidence tier: content-addressed values and chunked/windowed trace/log streams with explicit backpressure, truncation and dropped counters.
• Layout, query, merge and compiler passes execute off the UI thread and publish ordered deltas; the scene does not rebuild/reframe the entire graph on every lens change.
• Accessibility uses an indexed virtual semantic window. It never creates one hidden semantics node per off-screen edge or performs O(V×E) label lookup.

Graph release fixtures are fixed and seeded:

For S–L, pan/zoom/drag/connection preview target p95 ≤16.7 ms, max frame ≤50 ms, input-to-visual p95 ≤50 ms, and zero UI freezes over 700 ms. L attributable memory is ≤250 MB and 20 open/close cycles retain ≤5%. Every budget is measured on pinned macOS, Windows and Linux reference hardware in release builds, with profiles and frame/memory artifacts. Section 20.2 remains the funding gate; these interaction budgets make it operational.

8.16 Non-happy-path product contract

The graph is incomplete until its difficult states are first-class designs and tests:

• workspace untrusted, unreadable, moved, remote identity changed, index partial or adapter unavailable;
• snapshot loading, empty, source-only, observed-only, mixed, stale, partial, failed, fixture, offline, permission-denied or conflicting;
• no selection, port/relationship/scope/path selection, multi-selection, selection removed during refresh;
• query invalid, truncated, too expensive, timed out, cancelled or evidence-incomplete;
• unknown node kind/contract/schema/security version; extension missing, incompatible or revoked;
• draft invalid, typed hole, cardinality/cycle/boundary/capability/policy conflict;
• base revision changed, source dirty, plan drifted, approval expired/revoked, independent approver unavailable;
• execution queued, paused, slow, cancelled, child/provider lost, Desktop restarted, verification failed;
• replay gap/barrier/redaction, checkpoint unavailable, trace dropped, live source disconnected;
• persistence denied/full/corrupt, crash between journal and commit, recovery to exactly old or new revision;
• graph too large for current LOD/query, renderer degraded, accessibility table windowed;
• no tests cover the change, test evidence stale, rollback absent or rollback verification failed.

Every state explains what is true, why, what evidence exists, what remains safe, and the shortest legal recovery path. None collapse to a spinner, empty canvas, generic red toast, or invented green metric.

8.17 Technical ownership and dependency direction

The graph must use atomic Reaktor primitives and preserve the dual-surface rule.

Every reusable feature exposes a graph-agnostic kernel, optional install(graph) projection returning a closeable handle, and optional Desktop/extension contribution. Read paths use immutable manifests/snapshots and start zero actors, coroutines, scopes, ports or provider sessions. Runtime activation returns an exclusively owned handle with ordered, observable, idempotent close.

The V1 GraphDocument, current runtime Graph, current architecture projection and presentation flow survive through explicit adapters while the canonical model lands. They are not extended forever into a universal meta-bag. Unknown security/capability schema makes an old client read-only rather than allowing it to drop critical fields during write.

8.18 Graph delivery gates and claim ladder

These graph gates nest inside the program gates in §23. A date never waives a dependency.

Graph G0 — honest, leak-free viewer

• ADR chooses GraphSpec authority, stable ID algorithm, canonical edge direction and view/semantic separation.
• Inspection/export/MCP starts zero runtime jobs and produces the same hash 100/100 times.
• Runtime connection and ownership primitives are transactional; forced listener/lifecycle failure leaves no partial topology or leaked registrations/jobs.
• Every visible claim carries truth, origin, and time where applicable; Fixture/Unknown cannot enable mutation.
• Current read MCP contains zero mutators. Effective text/target/accessibility floors pass.

Graph G1 — canonical read/query wedge

• reaktor-graph-model, evidence, registry, indexes and V1/runtime/architecture/tooling adapters land.
• Desktop, JSON export and MCP return the identical snapshot hash.
• Contradictory desired/observed/source claims remain queryable and emit findings.
• Bounded query, pagination, cancellation, index and M-size performance gates pass.

Graph G2 — correct draft editor

• Palette, typed connect/reconnect, multi-select, copy/paste, comments/reroutes/scopes, view history, patch inverse, diff, CAS conflict, journal, save/reopen and keyboard parity work.
• 100,000 seeded command sequences preserve identity, port, dangling-edge, contract, cardinality, cycle, deterministic serialization and inverse invariants.
• Delete has zero silent cascades; crash/replay/concurrent-editor tests prove atomicity and no lost update.
• Gestures create drafts only; persistent and external state is byte-identical on every denied/failed preparation.

Graph G3 — compile/run/observe vertical slice

• Event → Pure → Branch → Action sample graph yields a stable contract error, fixes, compiles byte-identically, previews exact source/plan, runs in the reference interpreter and compiled backend, cancels within budget, and emits values/events mapped to semantic IDs.
• UI and MCP proposal surfaces use identical patch/plan/event schemas.
• Restart restores the same spec, snapshot, delta history, plan and receipt hashes.

Graph G4 — debugger and sandbox time travel

• Conditional breakpoints, step modes, watches, live values, profiles, source maps, checkpoints and deterministic replay pass the golden corpus.
• Interpreter and compiled backend yield equivalent normalized outputs/traces.
• External effects are recorded/stubbed or visibly unreplayable; no rewind re-executes production.

Graph G5 — beyond-Blueprints proof

On an external polyglot repository, one revisioned graph traces UI/API → service → actor/state/data → tests → deploy → telemetry. It shows desired/observed conflict with evidence, aligns runtime replay to source/release, and preserves identity through every level. A human and agent propose the same typed change through the same compiler/plan path; an authorized non-production operation produces a complete diff, approval, result, verification and rollback receipt. No BestBuds fixture participates.

Only after this gate may Reaktor claim an envelope beyond Blueprint-style editors.

Graph G6 — scale, extension, and polyglot conformance

• S/M/L/XL budgets pass on the OS matrix and seven-day soak.
• An independently built extension adds/removes a source, inspector, validator and safe operation without BestBuds/Compose dependency or leaked state.
• Kotlin ↔ TypeScript, then C++, pass schema/version/unknown-field/error/cancellation/streaming/backpressure conformance.

Graph G7 — field proof

At least three external teams use different stacks for sixty measured production days. They repeatedly use map, trace, validate, proposed change, governed operation and rollback flows with no authorization/approval bypass and demonstrate measurable improvement in mapping, diagnosis, change lead time and recovery. This—not the number of panes or nodes—is investment-grade proof.

8.19 Decisive acceptance journeys

Journey A — ten-minute brownfield map

A new user opens an untrusted external repository. Without executing repository code, Reaktor identifies workspace/islands/scopes, makes source-only truth explicit, finds a feature path from UI/API to state/tests/deploy, reveals gaps and contradictions, opens exact symbols in the IDE, and exports a bounded evidence pack in under ten minutes.

Journey B — Blueprint-grade behavior loop

The user creates a five-node Event → Pure → Branch → Action workflow, connects typed ports with keyboard or pointer, intentionally introduces an incompatible contract, navigates the precise finding, fixes it, extracts a reusable scope, compiles, runs in sandbox, sets a conditional breakpoint, steps through values, replays from a checkpoint, closes Desktop, reopens, and sees identical semantic/history hashes.

Journey C — full-system governed change

From a production incident, the user selects a causal path, scrubs the failing run, compares Desired with Observed, reveals stale/missing evidence, asks an agent for a typed proposal, inspects source/config diffs and blast radius, runs affected tests, receives policy and independent approval, applies the exact fingerprinted plan through the specialist tool, watches the same semantic IDs update, verifies the postcondition, and retains an auditable/rollback-capable receipt.

The entire journey occurs without reconstructing context in another pane or tool. Specialist tools receive precise deep links and return artifacts/evidence to the same selection, revision, run and plan.

8.20 Pencil implementation disposition

The canonical design file expresses one Graph Studio at different semantic depths and workflow states:

Reusable Graph / Studio Control Deck, Graph / Time Controller, Graph / Lens Stack, and Graph / Boundary Portal components belong to the Machine Signal atomic library. The visual migration sequence is component → three-width/theme harness → default/full graph cohort → inspector/drawer states → remaining boards. Designs remain specifications, never runtime assets.

8.21 System Fabric projection — data, messaging, compute, and cloud are graph-native

The full graph cannot stop at application services. Postgres tables, ClickHouse materialized views, Memgraph labels and relationships, D1 databases, Durable Object classes and instances, ObjectDatabase stores, topics, subscriptions, queues, Workers, JVM servers, containers, Kubernetes workloads, routes, bindings, volumes, policies, releases, and provider resources are first-class semantic entities. A database or cluster shown only in a separate inventory pane breaks the central promise of Reaktor: the user must follow one stable identity across source, desired configuration, deployed resource, runtime signal, data contract, operation, and history.

System Fabric is a projection of the same GraphSnapshot, not a fourth graph model. It adds registered facets and relationship kinds to the canonical graph kernel:

The generic graph remains provider-neutral, while facets retain provider semantics. A Cloudflare Durable Object is not flattened into a generic “server,” a Pub/Sub subscription is not treated like a synchronous port, and a ClickHouse mutation is not presented as a Postgres transaction. Generic kinds enable cross-system queries; typed provider facets preserve the details required to operate safely.

System Fabric lenses

The Graph Studio gains saved base lenses rather than more disconnected canvases:

• Application: routes, UI, services, actors, contracts, state, tests, and releases.
• Data: authorities, projections, schemas, lineage, readers/writers, classifications, residency, retention, query activity, and migration state.
• Messaging: publishers, topics/queues, subscriptions/consumers, schema versions, delivery semantics, lag/backlog, retry and dead-letter paths.
• Compute: Workers, DOs, servers, containers, jobs, processes, endpoints, ownership, capacity, health, and versions.
• Kubernetes: cluster through pod and storage topology, desired/observed rollout state, events, policy, placement, and capacity.
• Network and bindings: routes, gateways, service bindings, ports, tunnels, egress, certificates, trust boundaries, and public exposure.
• Delivery: source/IaC → artifact → deployment → resource revision → verification → rollback.
• Cost and capacity: provider/resource/mission/release attribution, forecast, saturation, and unit cost with evidence freshness.

At most two overlays remain active over one base lens. Selecting any entity keeps the same context spine and opens a type-specific inspector contribution without changing its semantic identity. Cross-scope relationships use boundary portals and bundled summaries at low detail; expanding a portal reveals the exact members and contracts. Graph queries can traverse from UI → Worker → Queue → subscription → consumer → table → materialized view → dashboard, or invert that path for blast radius.

Desired, observed, and historical planes

Every resource may have independent planes:

1. Desired: source, manifest, IaC, migration, policy, or explicit GraphSpec claim.
2. Observed: provider API, cluster API, database catalog, runtime endpoint, or telemetry claim.
3. Historical: content-addressed prior snapshots, deltas, plans, releases, incidents, and query/run receipts.

Reconciliation never overwrites disagreement. It produces a typed drift finding with field-level desired/observed values, authority, freshness, severity, ownership, downstream blast radius, and a proposed reconciliation direction. An unavailable provider leaves the last observation stale; it does not erase the resource or turn source configuration into live health.

Inspector contract for infrastructure entities

Every System Fabric inspector uses a common spine—Identity, Truth, Configuration, Relationships, Runtime, Security, Cost, History, Actions—plus type-specific tabs. Database entities add Schema/Query/Lineage/Migrations; messages add Delivery/Backlog/Replay; compute adds Versions/Instances/Endpoints/Capacity; Kubernetes adds Desired/Observed/Events/Placement/Volumes. Secret values never render: only secret identity, owner, version metadata, last rotation evidence, consumers, and policy appear.

The inspector is also the rendezvous with specialist tools. “Open in DataGrip,” “Open in ClickHouse UI,” “Open in Memgraph Lab,” “Open in Cloudflare,” “Open in Kubernetes dashboard,” “Open in Grafana,” or “Open source/IaC” carries the same workspace, environment, resource, revision, time range, and correlation context where the destination supports it. Reaktor orchestrates the system and preserves context; it does not attempt to out-specialize every console.

System Fabric performance and honesty contract

Infrastructure scale uses the registry/scene split already defined for Graph Studio. The registry may hold 100k+ resources and relationships, but the visible scene composes bounded summaries. Provider refreshes and telemetry update deltas, not the entire scene. Queries are indexed by provider/account/region/kind/owner/environment/namespace/contract/source/truth/change/security/cost. A resource refresh must not reframe the canvas, discard selection, or activate application runtime graphs.

System Fabric is claim-gated. Until live adapters, identity, query isolation, evidence, and conformance tests exist, a resource may be shown as Source or Unknown and deep-link to a specialist console; it may not be labelled Live or expose a mutating action.

Complementary. §8 above is the full Graph Studio specification with its own nested gates (Graph G0–G7). The build score below is the wiring order against current code: what is on screen today, which levers already exist in reaktor-flow/compose-flow, and what lands in which phase. Its Phase 6 corresponds to Graph G2–G3.

Build score §6 — Graph — the heart, from impressive viewer to the common surface

Today (verified): the strongest pane. Levels (Graph/System/Container/Component/Code), hierarchy L1/L2/All with digit keys, scope collapse cards, edge-kind chips + "Source only" operational overlay toggle, lens search, kind legend, minimap, zoom cluster, disconnected-ports finding, selection chips, six inspector tabs, IDE jump. Verified gaps: lens exposes only query+edge kinds (node kinds and neighbor toggle unbuilt in UI), minimap is display-only, level buttons on the Workbench app didn't respond (level state is per-app and the click regression must be reproduced and fixed), positions don't persist, no editing, three searches (G2), selection chips non-interactive, "1-2 · 0 = all" hint is cryptic.

Target experience: the constitution §8 — five deterministic levels over one snapshot, lenses as overlays, node grammar with truth badges, boundary portals, scope-first navigation — arriving in this order:

Phase 2 — navigation completeness.

• Breadcrumb, rail tree, canvas focus, level buttons, digit keys, and deep links all drive the same graphScope in context (3.1). Double-click/Enter opens a scope; Esc goes up; Option-click inline-expands with depth limit (the hierarchical-UI doc's §10 interactions, most of which have code paths already).
• Minimap becomes interactive (click-to-jump, viewport drag) and scope-local (it already scopes; add input). Zoom cluster gains Fit-selection.
• Lens UI completes: node-kind filter chips (data exists in ReaktorGraphLens.nodeKinds), neighbor toggle, saved lens presets per workspace, and "dim vs hide" honoring matchingNodeIds/visibleNodeIds separation. Legend entries become lens toggles (they already filter kinds — unify with lens state so there is one filter model).
• Selection chips (top-right) become the selection breadcrumb: click = re-focus, ⌘click = open alongside (Phase 6 split view).
• Fix: level-switch regression on the Workbench app; "1-2 · 0 = all" hint replaced by the keyboard overlay reference.

Phase 3 — evidence on the canvas.

• Wiring overlay: Graph.wiringReport() painted as port-level badges (unmatched = error ring, DI-satisfiable = warn) with the Diagnostics rows linking back; the "32 disconnected ports" chip opens the lens pre-filtered to them.
• Live activity: addPortEventListener drives edge shimmer on real Connected/Disconnected/traffic events (reduced-motion aware); a "wiring log" drawer record stream. Actor nodes render ActorStatus (Running/Failed…) from the StateFlow that already exists.
• Operational overlay grows from the current all-or-nothing toggle to per-lens composition (Structure + at most two overlays, warned when misleading — constitution §8.2).
• Node cards adopt the full grammar where data exists: truth badge (Fact of the node's provenance — runtime nodes are Live, scanned are Source), finding count, runtime dot. Collapsed scope cards gain provided/consumed contract summaries (from ports at the boundary — computable today) so they are never blank rectangles.

Phase 4 — scale and a11y. Viewport culling + spatial index + LOD in compose-flow (§18.2 blocker), budgets from constitution §20.2 wired into ReaktorDesktopPerformanceTest; the accessible tree/table alternative surfaces behind a toolbar toggle; keyboard-only node traversal (arrows walk the accessibility inventory order, Enter selects, ⌘Enter opens source).

Phase 6 — authoring (D4 gate). The composer arrives exactly as the visual-language doc specifies and only behind Proof B: compose-flow's already-complete onConnect/isValidConnection/onDelete/onSelectionChange/ConnectionController wired to GraphCommands via GraphEditorSession; drags become MoveNode (positions finally persist in GraphViewState); connect gestures validate by contract with green/amber/red pin feedback; every mutation is Preview → dry-run findings → Commit through the one spine; undo/redo binds the session's existing labeled stacks; "Save" persists a GraphDocument (Memgraph graphdoc.* gateway is live server-side already); "Apply" materializes only through the governed plan path. Rename to "Composer" happens here and not before.

Acceptance (per phase): P2 — a deep link restores scope+selection+lens exactly; P3 — disconnected-ports chip → lens → fix → chip count drops without restart; P4 — 10k-node synthetic graph pans at 60fps with culling on; P6 — Proof B's five-node journey passes end-to-end on an external sample.

9. Build workspace — Develop, Preview, UI, and inner loop

Build makes source, preview, device, pipeline, test, trace, and design work feel like one loop. The current DevToolsTab set is retained and completed.

The source-only Run App mode becomes the direct Build + Runtime + Preview template; its capability and shortcut remain deep-linkable while its duplicated shell/state is removed.

9.1 Develop/DevTools surface contract

9.2 Preview control anatomy

The device-mode chips (P, P+T, P+D, All, D) become named presets with tooltips and accessible names. Viewport, scale, orientation, theme, locale, text scale, reduced motion, network profile, auth persona, feature flags, and data scenario are a composable Scenario Bar. Scenarios are versioned artifacts that can be handed to Tests and Agent.

The preview inspector contains component tree, props/state, semantics, layout, render/recomposition cost, graph node, source, events, network, and screenshot diff. State values are redacted by schema. Selecting a component never causes an accidental product interaction while inspect mode is active.

9.3 UI family — all eight authored subpanes

Current binding coverage is 0/8; these remain Designed until their adapters produce current-build evidence.

UI acceptance: change one token and see affected components/screens, source diff, visual tests, accessibility results, app previews, and deployment change set through the same identity. Approving a baseline cannot bypass code review or evidence lineage.

Build score. Two per-surface scores below: the DevTools inner loop (verified subtab by subtab on the running app) and the UI family, whose first wiring wave is nearly free because the Machine Signal parity harness already produces the data its subpanes need.

Build score §7 — DevTools — the inner loop becomes one loop

Today (verified): 13 subtabs. Preview is genuinely special (live BestBuds app in a device frame, brand animation running, click-to-inspect semantics tree with modifiers/bounds, Open Graph/Trace buttons, honest "theme override unavailable / network emulation unavailable" banners, P/P+T/P+D/All/D presets, Online/3G/Off chips). Devices is a real device lab (gated/ready cards, effect-labeled ops). Pipeline lists real stages with commands + a run ledger. Testing/Recorder/Releases/Traces have strong anatomy with honest gating; Logs/Source/Mobile/Workers/Servers/Workspace are catalog+runs projections. Chrome inconsistency: Preview and Traces swap the whole strip away (mode-inside-a-mode), subtab row order sorts authored-first (fine), the "N mores" overflow chip, and the rail count bug.

Targets, per subtab:

Chrome decision: Preview and Traces stop replacing the strip; they render inside the DevTools scaffold with their toolbars as pane toolbars (the mode-inside-mode confusion the walk hit twice). Run App alias remains a palette entry that deep-links to DevTools/Preview.

Acceptance: select a node in Preview's semantics tree → Open Graph lands on the same entity with inspector populated → Open Trace shows its path → a recorded flow replays on the same scenario. That round trip, with zero re-selection, is the inner-loop symphony moment (constitution §9.1 Preview "Done when").

Build score §16 — UI — the design system audits itself

Today (verified): 0/8 snapshot-wired, but Canvas/Workbench/Design System are real hand-rendered surfaces (control gallery, truth-class reference, 12 token rows), and the five dark cards name exact turn-ons — several of which are nearly free because the parity harness already produces the data.

Acceptance: change one token value → Design System shows the parity break, Visual Tests shows the diff, A11y flags any contrast casualty, and the drawer Diagnostics carries the failing gate — the design system audited by the product it styles, live.

10. Ambient Agent and Agent workspace

Agent capability is a governed collaboration model, not a chat box attached to an IDE.

10.1 The four local actions

Every entity/finding/run exposes:

• Ask: answer from the current evidence pack with citations and uncertainty.
• Explain: describe architecture, behavior, history, failure, or plan at the user's level.
• Propose: create a reviewable patch/change set/mission; never apply silently.
• Delegate: run a bounded workflow with explicit budget, capabilities, stop conditions, and checkpoints.

All outputs link to snapshot revision, evidence IDs, tool calls, model/prompt version, and cost. The UI distinguishes model text, retrieved fact, inference, proposed change, executed action, and verified result.

10.2 Agent family — all nine authored subpanes

Current binding coverage is roughly 4/9 and mostly reflects local Manna source status. The target is provider-neutral.

Legacy Manna, Tasks, Goals, Knowledge, and Runs remain addressable as migration views: Manna becomes an agent/provider filter; Goals become Missions; Knowledge becomes evidence/memory/search; Runs uses the common ledger.

10.3 Critic and review

Every material agent change is reviewed by independent passes and, where required, a human:

• contract/type/compiler findings;
• tests/security/accessibility/performance impact;
• change scope and blast radius;
• evidence completeness and hallucination checks;
• effect and authorization policy;
• diff clarity, rollback, and verification.

The Critic withholds approval; it never applies the change itself. Agent confidence does not replace evidence.

Convergent. Both plans make agent capability a governed collaboration model — proposals, plans, findings, and evidence rather than chat history — with the Critic gating by withholding approval. The build score sequences it: session transport and MCP inventory first, Propose/Delegate only after the mutation spine.

Build score §17 — Agent — governed collaboration, not a chat box

Today (verified): 4/9 wired through the Manna provider (chat/agents/runbooks/memory read local Manna state); Session/Critic honestly waiting on "a session transport; the command queue underneath it is already wired"; MCP subpane exists as anatomy; Audit maps to the run ledger.

Plan:

1. Phase 4 — the session transport its cards name. A local agent session = a supervised process lane (claude/codex CLI) with streamed events into the existing run/event model; Chat renders sessions with pinned context packs (3.5); every agent tool call is a ledger record. MCP subpane goes live with the Desktop's own server inventory + per-call audit (data exists in the server).
2. Phase 4 — provider-neutral registry. Agents: local CLI agents + Manna + (config) cloud endpoints with capabilities/scopes/trust tier — the scope table from reaktor-agentic-tooling.md (deploy:* human-only, auth:admin never) enforced at tool registration, not at call time.
3. Phase 5 — work surfaces. Kanban/Tasks-DAG derive from Missions + runs (never a parallel project tracker); Runbooks: the three authored runbooks become executable typed step lists through the plan path with per-step evidence; Memory: read/annotate the agent memory dirs with source/reason/TTL columns; Audit: immutable chain view (principal→context→tool→plan→run→outcome) over existing records.
4. Phase 6 — propose/delegate through the mutation broker with Critic gating (3.5, constitution §10.3). Acceptance: an agent session that touched the workspace shows every read and every proposed action in Audit with zero gaps, and rejecting its plan (the authored wired action) leaves a receipt.

11. AI workspace — models as an operable subsystem

Current binding coverage is 0/12. The mode remains behind an experimental capability flag until at least one real provider, one eval loop, one trace path, and one release gate work end to end.

AI acceptance: a chain change moves from prompt/operator diff -> eval slices -> guardrail/security -> cost/latency -> approved release -> live trace -> regression/rollback with identical artifact identities. Sample model rows and fictional scores never appear in production.

Convergent. Both plans keep AI visible but capability-gated with no fictional registry rows. The build score retires the current keyword-matched projection in favor of typed registries extracted from source, then one governed playground/eval loop.

Build score §15 — AI — an operable subsystem, honestly gated

Today (verified): 0/12 wired; the pane keyword-matches Cloudflare bindings into "System prompt"/"Models" groups (clever but mislabeled — a binding is not a model row) and shows runs as "Retrieved context". Honest headline: "waiting on a model registry read."

Plan. Respect the constitution's capability flag: AI mode stays visible (D1) but its families wire only against real subsystems, and the keyword projection is retired in Phase 3 in favor of typed sources:

1. Phase 3 — registry truth. Models: a real registry — Workers AI models via binding metadata + the bot-service's configured providers/models parsed from source (Source facts), with price/context columns marked Imported from provider docs; Tools: the MCP tool inventory the Desktop itself serves + agent-side tools (real, exists); Prompts: prompt strings extracted from bot-service source with versions from git — the first honest prompt registry.
2. Phase 4 — first loop. Playground: versioned scenario runner against Workers AI/dev bot-service through a plan-gated LiveRead/NonProductionWrite lane with token/cost/latency capture; AI Traces: the bot pipeline's existing logs shaped into prompt→tool→response timelines; Evals v1: golden-set runs as Testing-harness results (one model, one metric, honest sample sizes).
3. Phase 5–6 — the studio. Chain Builder renders the bot flow as a typed graph (graph kit; read-only until the mutation spine); Guardrails = moderation-worker policies as Source facts + eval evidence; Routing & Cost joins Analytics' cost attribution; RAG waits for a real index (Vectorize binding exists; the board's pipeline is the spec); Releases = immutable prompt/model/tool bundles through the same plan/approve path (constitution §11 acceptance). Acceptance: change a budbot prompt → eval run → cost/latency delta → gated ship to dev — one AI change with the same evidence discipline as a worker deploy. Nothing in this mode ever shows a sample score.

12. State / Data Studio — one multi-engine data fabric

Current database binding is the strongest authored family (7/7), but most JVM Desktop facts are discovery/configuration and bounded probes rather than a general live data console. The existing JavaScript rich screen contains useful interaction ideas but relies on fixture catalogs and canned query results. reaktor-db provides a real local ObjectDatabase and tenant-aware graph database adapters; reaktor-cloudflare provides real runtime bindings for D1, Postgres/Hyperdrive and ClickHouse; reaktor-google provides real Pub/Sub adapters. None of those currently form a provider-neutral Desktop inventory, schema, query, lineage, or governed mutation plane. Preserve that honesty while building the complete product.

Provider/storage tabs (Local, Postgres, D1, Memgraph, ClickHouse) become engine filters and saved contexts inside one Data Studio. They do not become parallel applications. Selection, environment, tenant, revision, truth, time range, query budget, and permission survive between tab, graph, table, source, trace, and specialist-tool views.

12.1 The authority rule

Reaktor never implies that every database is an equal source of truth. Every logical dataset declares exactly one current authority and any number of projections, caches, indexes, replicas, archives, local working sets, and event streams. The role is attached per dataset—not hard-coded forever by engine—and carries evidence and effective dates.

DataAuthorityRole values are Authority, TransactionalReplica, ReadProjection, SearchIndex, AnalyticsProjection, EdgeCache, LocalWorkingSet, EventLog, BlobAuthority, and Archive. A graph path such as Postgres → Pub/Sub → ClickHouse is rendered as authority → event transport → analytics projection, with last successful checkpoint, lag, transformation identity, and replay/rebuild path. Contradictory authority declarations are blocking findings.

The initial BestBuds defaults are explicit rather than universal: Postgres is transactional authority for product records; R2 is authority for blobs; Memgraph and ClickHouse are derived projections unless a dataset descriptor says otherwise; D1 owns bounded edge-operational datasets; Durable Objects own single-writer instance state; ObjectDatabase is a local working set/cache unless a feature declares it authoritative. The UI always renders the declared role.

12.2 Canonical data model

Add provider-neutral data facets to reaktor-graph-model, with provider codecs contributed independently:

data class DataSystemFacet(
    val engine: DataEngine,
    val authorityDomain: String?,
    val capabilities: Set<DataCapability>,
)

data class DataNamespaceFacet(val name: String, val kind: NamespaceKind)
data class DataEntityFacet(val logicalName: String, val entityKind: DataEntityKind)
data class DataFieldFacet(val name: String, val type: SchemaRef, val nullable: Boolean)
data class DataIndexFacet(val kind: String, val fields: List<ElementId>, val unique: Boolean)
data class DataRelationshipFacet(val contract: ContractId?, val cardinality: Cardinality)

data class DataEndpoint(
    val id: ElementId,
    val systemId: ElementId,
    val environment: EnvironmentId,
    val tenantPolicy: TenantPolicyRef,
    val credentialRef: SecretHandleRef?,
    val capabilities: Set<DataCapability>,
)

DataSystem, DataEndpoint, DataNamespace, DataEntity, DataField, DataIndex, DataConstraint, DataRelationship, DataContract, DataClassification, DataRetention, DataLineageStep, DataMigration, DataQueryReceipt, and DataObservation all receive stable semantic IDs and evidence. Connection endpoints and credential references are stored; passwords, tokens, certificates, raw connection strings, and result secrets are not.

Schema has independent desired, observed, and historical planes. Source migrations or descriptors can describe desired state; provider catalog queries describe observed state; query telemetry describes usage. A schema merge retains disagreements and creates drift findings. Unsupported introspection fields remain Unknown rather than being inferred across engines.

12.3 Engine adapters and exact scope

One small SPI supports every engine without pretending their semantics are identical:

interface DataProvider {
    val descriptor: DataProviderDescriptor
    suspend fun discover(context: DataContext): DataFragment
    suspend fun catalog(target: DataTarget, budget: QueryBudget): DataCatalog
    suspend fun prepareRead(request: ReadQueryRequest): PreparedReadQuery
    suspend fun executeRead(plan: PreparedReadQuery): Flow<QueryEvent>
    suspend fun prepareChange(request: DataChangeRequest): DataChangePlan
}

The first supported adapters and their type-specific inspectors are:

Database adapters do not automatically receive broad provider credentials. Discovery, catalog, query, explain, export, migration, backup, and administration are separate capabilities. A connection may be present in the graph while query permission is Denied or Unknown.

12.4 Unified query contract

The editor is multi-dialect, not lowest-common-denominator SQL. A QueryDocument pins dialect, target identity, environment, tenant/scope, snapshot/catalog revision, parameters, classification intent, and author. Preparing it yields a sealed QueryPlan containing:

• normalized statement or provider request hash, never a secret-bearing raw log entry;
• parser/engine version and statement class;
• selected endpoint, database/namespace, tenant binding and credential handle version;
• permission decision and policy identity;
• read-only enforcement mechanism;
• timeout, maximum rows, bytes, value size, paths/nodes, concurrency and cost budget;
• consistency/snapshot mode;
• field classification, masks, redaction and export policy;
• explain policy and estimated blast/cost where supported;
• result schema and pagination/cursor strategy;
• expiry, nonce and cancellation handle.

String heuristics are never the security boundary. The adapter uses provider-native read-only credentials/transactions or scoped APIs, a parsed statement allowlist, bound parameters, target/tenant enforcement, and a final provider-specific check. The tenant and authority scope come from the authenticated principal and selected resource policy; query text, parameters and an agent request cannot override them. SQL/Cypher comments, multi-statements, procedures, functions, CTEs and extension calls are adversarial inputs. “Explain” and “read” routes cannot forward arbitrary text to an account capable of mutation.

The production and agent-facing contract is a versioned named query or typed query AST compiled server-side. Raw SQL, Cypher and provider command text are a separately classified local/non-production diagnostic capability, disabled by default, never exposed through the read MCP, and never accepted by a production adapter merely because a parser labels it read-only. Saved query text does not become authority; every execution is re-prepared against the current catalog, policy, target and credential capability.

Execution streams QueryStarted, schema, bounded pages, progress/profile, truncation, warning, failure/cancel and QueryCompleted. A DataQueryReceipt links principal, policy, plan hash, endpoint/catalog revision, start/end, rows/bytes, truncation, classification, result artifact reference, engine query ID, trace ID and redacted error. Results expire by classification policy and are not silently persisted in workspace history.

Production starts with conservative defaults: read-only, parameterized, short timeout, small page/byte caps, no raw PII, no result export and no cross-tenant query. The user can request a larger bounded plan; policy decides. Cancellation must propagate to the provider, and Desktop must stay responsive while pages stream with backpressure.

12.5 Data Studio anatomy

The State workspace uses atomic components shared with Graph Studio:

1. Target ribbon: engine, endpoint, environment, tenant/scope, authority role, truth/freshness, catalog revision, permission, query budget.
2. Data navigator: systems → namespaces → entities → fields/indexes/constraints; searchable, virtualized, desired/observed diff and saved scopes.
3. Query/editor: dialect-aware completion, parameters, schema/contract hover, source query, read/explain controls, selection cost, saved/notebook query and specialist handoff.
4. Results: virtualized typed grid/tree/graph, masks, classification, evidence, paging/truncation, compare, trace/source/entity links and separately governed export.
5. Inspector: identity/role, schema, relationships, readers/writers, lineage, policies, runtime health/usage, migrations, history and actions.
6. Mini graph: the selected entity’s producers, consumers, projections, event path, tests and deploy dependencies; expanding opens the identical selection in full Graph Studio.
7. Activity drawer: query plan/events/profile, migration/change plan, findings, agent proposals, approvals and receipts.

The supported subpanes remain stable and gain complete semantics:

12.6 Schema, contracts, lineage, and change impact

Physical schema is joined to logical ContractDescriptors. A table column, D1 field, DO storage property, ObjectDatabase value, queue payload and API field can share or map between schema identities. Lineage steps name transformer/query/job/release identities, input/output contracts, code/source evidence, last successful checkpoint and failure behavior. Inferred lineage is visibly Inferred and cannot satisfy a release gate without policy allowing it.

Schema diff is semantic: rename versus drop/add, compatible versus breaking type evolution, nullability/default, index/partition/order/TTL, RLS/policy, storage/retention and message compatibility. Blast radius traverses source symbols, services, queries, projections, topics/subscriptions, tests, deploy targets, dashboards and data consumers. Generated migration suggestions remain proposals.

12.7 Governed data mutation grammar

The UI has no generic production “Run” for writes. A mutation is:

intent → typed DataChangeRequest → catalog/source refresh → semantic diff
       → impact and data-classification analysis → rehearsal/backup/preconditions
       → sealed DataChangePlan → authorization/approval → execute
       → provider events → postcondition/query verification → receipt/rollback or forward-fix

DDL, DML, ClickHouse mutation, Cypher write, D1 remote command, DO instance command, object delete, queue replay/purge, backup/restore and cache invalidation have different effect descriptors and rollback requirements. A statement that changes data cannot be smuggled through a query adapter. “Undo” never promises rollback of an external effect; rollback is another governed plan.

One existing graph-gateway read route is a Gate 0 blocker (detailed in the private security review): read and write privileges must be separated onto distinct credentials with a real statement/operation policy, and negative tests must prove every mutation attempt leaves state byte-identical, before Data Studio connects to it.

12.8 Data scale, privacy, and correctness gates

Reference fixtures cover 100, 10k and 1M catalog entities without loading row data. Catalog refresh is delta-based; navigator and result semantics are virtualized. Target budgets on pinned hardware are: first useful catalog ≤2 s at 10k entities, indexed search/filter p95 ≤100 ms, query first page ≤1 s excluding provider latency, result scrolling within frame budget, cancellation acknowledgement ≤500 ms when supported, and no retained-result growth after twenty query/close cycles. Large lineage queries return bounded/truncated paths with continuation.

Initial execution budgets are deliberately finite and policy-ratcheted:

Cancellation is acknowledged in the UI within 1 s and reaches a provider cancellation or forced connection teardown within 5 s; otherwise the run remains truthfully Cancelling or Unknown, never Cancelled. A proposed write touching more than 10,000 records or 1% of an authority partition is blocked pending a provider-specific bulk-change policy, rehearsal and independent approval; these thresholds are tripwires, not permission to mutate smaller sets.

Release tests include:

• a dialect × engine × statement-class matrix with comments, CTEs, multi-statements, procedures/functions and encoding tricks;
• cross-tenant/cross-environment/cross-endpoint authorization negatives;
• row/byte/time/path/concurrency/cost cap and cancellation tests;
• redaction/classification/export/log/clipboard/support-bundle canaries;
• stale catalog, dropped connection, failover, partial page, provider timeout and policy outage;
• schema drift and lineage contradiction retention;
• migration crash injection before/after every durable boundary;
• fixture/source/stale/unknown truth never displayed as live or used to approve a write;
• property tests proving deterministic plans/receipts and zero partial external effect on denial/drift.

Acceptance: a developer can select any supported data entity, identify its authority and every known reader/writer/projection, inspect desired/observed schema with evidence, run a bounded authorized read in the correct dialect, follow one result or query into source/trace/graph, propose a schema/data change, rehearse it on synthetic data, apply to non-production, verify and reopen the receipt. Production remains blocked without authenticated approval and a proven recovery path.

Convergent. The build score's Database V1 — a gated read-only connection, bounded probes promoted to a real editor, applied-migration drift — is the seed of the sealed QueryPlan contract above; budgets and read-only-by-default agree. §12's authority roles and typed-AST production contract are the destination.

Build score §8 — Database — the reference family, deepened

Today (verified): the model family — 7/7 wired. Store inventory in the rail (11 REAKTOR-DB source adapters, ClickHouse, 5 Durable-Object stores honestly FAILED), bounded read probes as the editor's tasks, read-only banners ("writes become migration commands", "QUERY needs a gated read-only connection"), schema truth from heimdall.sql, Cloudflare dashboard deep links, migration resources with "applied state is not inferred from source", a query-history ledger with an ACTOR column, and device-dependent tasks disabling themselves with amber reasons. What it is not yet: an actual query console — Query/Data/Plan render task lists, not result grids.

Per subtab:

Connections: repository nodes in Graph ↔ their stores here (verb fabric); analytics events table ↔ Analytics mode; migration runs ↔ Deploy gates. Acceptance: the BestBuds question "which of the 14 checked-in migrations are applied to dev?" is answerable on screen with provenance, and answering it produces zero writes.

13. Trust workspace — identity, authorization, and security

The legacy Users, Providers, Sessions, Roles, Tokens, and Audit views map into the six authored panes. Users/tokens remain entity types and saved filters, not lost functionality.

Before this workspace administers production, BestBuds must close the verified authorization, privacy, and credential findings enumerated in the private security review — object-level authorization at every external handler, credential rotation with history purge, delegation and refresh correctness, per-service workload identity, and synthetic development data.

Acceptance: every external handler participates in a generated action x principal x tenant x resource negative matrix; uncovered routes fail CI. The simulator's answer, enforcement decision, audit event, trace, and test use the same policy identity.

Build score. The Auth family below is graded per subtab with its wiring source; the permission Simulator is called out as days of work because the pure LocalAuthorizer engine already exists in reaktor-auth.

Build score §9 — Auth — findings today, simulator next

Today (verified): 3/6 wired with the best truth composition in the app: provider truth from source files per platform, the 19-table heimdall schema grouped and counted, RBAC summary rows, and — the standout — Security rendering the repo's real high/medium findings as source-backed rows. Sessions/Audit/Simulator are honest turn-on cards.

Connections: Security findings ↔ Diagnostics drawer (3.3); simulator verdicts ↔ SecuredPort gates in Graph (render port-level auth requirements as lens); session principal ↔ avatar identity. Acceptance: the simulator answers "can role X reach send-message?" with the same engine the runtime uses, and the BestBuds P0 containment list (constitution §19.3) is trackable as findings with verification runs on this very pane.

14. Prove workspace — testing and gates

The packaged All, Maestro, Playwright, Desktop, Karate, k6, and Keploy tabs remain first-class harness filters over one test model.

Cross-cut gates appear as subviews: Unit/Property, Contract, Integration, E2E, Security, Accessibility, Visual, Performance, Compatibility, Packaging, Upgrade/Restore, Chaos/DR, and Eval.

Each result has commit/lock/platform/scenario, start/end, truth, artifacts, related graph entities, release/mission, owner, and retry/quarantine policy. Cached, aborted, stale, or fixture evidence cannot satisfy a release gate unless the gate explicitly permits it.

Acceptance: the test registry generates a coverage report for every mode, subpane, state, interaction, operation lifecycle, external handler, supported platform, and release artifact. Missing/duplicate/skipped/ignored coverage fails CI.

Convergent. Both plans converge on one test model over the seven harnesses, with harness tabs as filters and results as release-gate evidence. The build score starts from the report directories that already exist on disk.

Build score §12 — Testing — one test model over seven harnesses (D9)

Today (verified): 189 harness ops discovered, per-harness tabs (Maestro/Playwright/Desktop/Karate/k6/Keploy), runbook-gated runs, honest empty Devices/Results.

Plan: V1 (Phase 3): a common TestResult record (harness, suite, case, status, duration, artifacts, revision) parsed from each harness's report directory (Maestro results in tmp/maestro-results, Playwright reports, Gradle test XML — all exist on disk today) feeding: Results subtab, the drawer Tests tab (D10), and per-entity "covering tests" in the inspector. Harness tabs become filters over one model (constitution §14). V2 (Phase 4–5): impacted-test selection by graph blast radius; quarantine/flake truth (aborted ≠ passed — closing the harness README's own caveat); coverage-by-entity lens in Graph; results as release-gate evidence for Deploy. Acceptance: run the desktop smoke suite from the pane and watch its 34 flows stream into Results and the drawer with artifacts — the tool testing itself through its own plane.

15. Operate: Deploy and Cloud

15.1 Deploy surfaces

The packaged Workers, Mobile, Web, Server, Desktop, Artifacts, and History tabs remain target filters over one release model.

The Deploy experience is a progressive plan:

change set -> affected targets -> build artifacts -> gates -> desired/observed diff
           -> blast radius -> approval -> rollout -> verification -> observe -> close/rollback

15.2 System Fabric — the entire operable cloud layer

The Cloud family becomes System Fabric: one operable model spanning providers, accounts/projects, regions/cells, networks, compute, data, messaging, Kubernetes, routes/bindings, delivery, telemetry, security, cost and history. Legacy Providers, Resources, Bindings, and k3s remain saved filters and graph entity kinds; legacy Runs maps to the common operation ledger. State/Data Studio provides the deep query experience, while System Fabric provides placement, connectivity, health, capacity, drift and operations. Both select the same resource identities.

The current implementation is a seed, not the target. reaktor-cloud exposes a flat stringly CloudResource and provider/tool SPIs. Its Wrangler inventory reads source configuration without credentials and currently discovers only a subset of R2, Hyperdrive and Workers; it does not prove live status, D1, Durable Objects, Queues, service bindings or Kubernetes state. Provider refresh failure currently collapses to an empty list instead of preserving stale evidence. reaktor-cloudflare, reaktor-google and reaktor-db contain real runtime adapters, but they are not inventory/query/control-plane providers. The Desktop panes largely project discovered catalog data; impressive “live” values in older prototypes are fixtures. The roadmap evolves those pieces through adapters rather than inventing a second product-specific cloud model.

15.3 Resource identity and hierarchy

Replace the universal flat resource record with canonical graph entities and typed provider facets. Resource identity is stable across manifest rename/reorder and separate from ephemeral provider instance IDs:

Provider
  └─ Organization / Account / Project
      └─ Region / Zone / Cell / Cluster
          └─ Namespace / Environment / Stack
              └─ Resource specification
                  └─ Deployment / revision
                      └─ Runtime instance / observation

ResourceSpec stores desired semantic identity, kind, provider locator, owner, environment, region/cell, capabilities, dependencies and source evidence. ResourceObservation stores provider resource/version IDs, status facts, capacity, endpoints, timestamps/TTL and evidence. ResourceDelta records changes; ResourceFinding represents drift, exposure, policy, capacity, failure or unknown coverage. Provider facets are schema/version registered and retain native fields. Secrets are typed handles and metadata only.

Canonical relationship kinds include contains, hosts, deploys, runs, serves, routes-to, binds, invokes, publishes, subscribes, reads, writes, mounts, selects, replicates, projects-to, backs-up, aliases, observed-by, secured-by, costs, owned-by, and drifts-from. A resource can be Source-only, Observed-only, Desired+Observed, Stale, Partial, Conflicting, Unknown or Failed. Health is independent from provenance and derives only from non-expired provider/runtime observations. An environment endpoint which aliases production is rendered as AliasOfProduction, inherits production effect policy, and cannot hide behind a “dev” label.

15.4 Provider and target coverage

The first complete provider pack must cover the systems already present in BestBuds and Reaktor:

Cloudflare

• Workers, versions/deployments, routes/custom domains, cron triggers and tail/log/trace bindings;
• service bindings and dependency graph;
• Durable Object classes, namespaces, migrations, storage type, alarms and known instance context;
• D1 databases, migrations and catalog;
• R2 buckets/prefixes/lifecycle, KV namespaces, Queues/producers/consumers/DLQs;
• Hyperdrive configurations as connection/pooling/cache boundaries, linked to the underlying Postgres authority;
• Workers AI, Vectorize, Browser, Workflows and Containers when configured;
• environment bindings, secret names/versions/consumers, compatibility flags and source config;
• desired/source inventory and live provider observations as separate fragments.

Google Cloud

• organization/project/region/zone identity, workload/service identities and IAM-policy findings;
• Pub/Sub topics, subscriptions, schemas, producers/consumers, delivery policy, backlog/age, retry and dead-letter links;
• artifact/image registries, compute/server targets actually used by the workspace, monitoring/logging endpoints and budgets;
• Secret Manager metadata, not values; workload identity and credential-age evidence;
• Pulumi/IaC desired state and provider observations without making Pulumi state the semantic authority.

Kubernetes / k3s

• contexts, clusters, control-plane reachability and version evidence;
• nodes, labels/taints, readiness, capacity/requests/limits, pressure and placement;
• namespaces and policy boundaries;
• Deployments, StatefulSets, DaemonSets, Jobs, CronJobs and custom resources;
• ReplicaSets/pods/containers/init containers, image digests, restarts, probes, events and rollout revisions;
• Services, EndpointSlices, Ingress/Gateway, ports, tunnels and exposure;
• ConfigMaps and secret descriptors/consumers without values;
• StorageClasses, PVs, PVCs, mounts, capacity, locality and backup/restore evidence;
• NetworkPolicies, PodDisruptionBudgets, service accounts/RBAC and security contexts;
• desired manifest/GitOps state versus observed objects, field ownership and drift.

Servers and processes

• JVM servers, Spring/Ktor/Vert.x services, native processes, containers and external endpoints;
• build artifact/image digest, runtime/framework/version, host/cluster/pod, port/protocol/routes/contracts;
• config/secret names, dependency/service/database/message bindings and public/private exposure;
• process lifecycle, instances, health/readiness, capacity, CPU/memory/thread/GC/profile evidence, logs/traces and release;
• owned local processes through the supervised executor and remote processes through provider adapters—never arbitrary PID kill buttons.

Data systems

Postgres/Supabase, ClickHouse, Memgraph, D1, Durable Object storage, ObjectDatabase, R2/KV and their endpoints appear as System Fabric resources and link into §12 for schema/query/lineage. Provider placement, connectivity, version, capacity, backup, replication, incident and desired/observed status remain visible here.

15.5 Messaging and event fabric

Pub/Sub and queues are not decorative arrows. The semantic model includes MessageBroker, Topic, Queue, Subscription, ConsumerGroup, MessageContract, DeliveryPolicy, RetryPolicy, DeadLetterTarget, Producer, Consumer, BacklogObservation, and ReplayReceipt.

Each message path shows:

• provider/account/region/environment and stable identity;
• producers and consumers resolved to graph entities/source contracts;
• schema/version/compatibility and classification;
• ordering, delivery guarantee, deduplication/idempotency contract and retention;
• ack deadline/lease, retry/backoff, delivery attempts and dead-letter route;
• live backlog/oldest age/throughput/error observations with origin and TTL;
• trace/correlation coverage and gaps;
• replay/re-drive/purge capability, effect, scope and recovery posture.

Cloudflare Queues and Google Pub/Sub retain their native semantics. At-least-once delivery is explicit; a green queue does not prove consumer idempotency. Pull/ack, replay, seek, purge and dead-letter redrive are different operations. A message payload preview requires resource authorization, classification/redaction and a bounded sample; metadata-only visibility does not grant body access.

The current Pub/Sub diagnostic endpoints are not a production control-plane foundation (specifics in the private security review): they must be removed, authenticated, or isolated before System Fabric connects to them. Provider push handlers verify platform identity, audience, and subscription binding before parsing payloads or producing a downstream effect.

15.6 Desired/observed reconciliation and incident context

Every provider adapter emits evidence-backed GraphFragments from source/IaC and live APIs independently. Refresh failure preserves the last observation as Stale with the error; it never returns an apparently empty healthy account. Reconciliation is field-aware and exposes:

• missing desired, missing observed, version/config mismatch and unmanaged resource;
• rollout/revision mismatch, image/tag/digest drift and binding/route drift;
• capacity/replica/storage/policy/security mismatch;
• database schema/migration/backup/replication drift;
• message schema/subscription/retry/DLQ drift;
• owner, first/last seen, related release/incident, blast radius and proposed direction.

Timeline mode aligns manifest commit, plan/approval, provider events, rollout, Kubernetes events, telemetry, database/message observations, alert/incident and rollback. A user can freeze the fabric at an incident timestamp, compare it with current or desired state, and export the evidence chain without mutating anything.

15.7 System Fabric workspace anatomy

The default screen is a calm split view, not a wall of provider cards:

1. Fabric navigator: saved scopes plus provider/account/region/environment/kind/owner filters; searchable and virtualized.
2. Projection switch: Topology, Inventory, Desired ↔ Observed, Rollout, Capacity, Security, Cost and History; all reuse the same selection.
3. Graph/table canvas: semantic zoom, region/cell/namespace scopes, bundled portals and data/message/compute/Kubernetes relationships.
4. Evidence inspector: common resource spine plus type-specific contribution; source and observed claims never merge into one unlabeled value.
5. Action well: legal typed operations for the current selection, permission and effect only; unavailable actions explain why.
6. Timeline/drawer: refresh/provider events, plan/diff, rollout, query/operation logs, findings, approval and receipt.

The six authored subpanes become saved entry points:

Saved secondary views provide Data, Messaging, Compute, Kubernetes, Network/Bindings, Security and Incidents without adding another top-level mode.

15.8 Governed infrastructure operations

Cloud actions never wrap arbitrary console APIs as buttons. OperationDescriptors define exact targets, provider/adapter version, transitive command/API closure, effect, capabilities, filesystem/network/secret handles, preconditions, expected diff, timeout, rollback and verification. All use the same plan/fingerprint/authorization/ledger kernel as local Tooling.

Examples include provider refresh, log/tail/profile read, rollout restart, scale, traffic shift, deployment, secret rotation request, database maintenance, queue replay, pod debug session, backup/restore and resource deletion. A read action may need sensitive-data permission but no mutation approval; a remote write revalidates provider revision and policy at call time; production destructive actions require an independent human and proven recovery. Plugin/provider adapters cannot invent a parallel executor.

The action grammar is:

select resource(s) → refresh source + observed evidence → choose typed operation
                   → prepare immutable diff/blast radius → preflight/verification plan
                   → authorization/approval → execute with bounded streamed events
                   → reconcile observed state → verify → receipt or rollback/escalate

15.9 Adapter ownership and evolution of reaktor-cloud

Keep the kernel generic:

• reaktor-graph-model: resource/data/message facets, stable IDs, evidence, snapshot/query/delta;
• reaktor-cloud: provider-neutral ResourceSource, ResourceObserver, ResourceOperationProvider, reconciliation and common codecs;
• reaktor-tooling: plans, isolation, effects, authorization/approval integration, execution and ledger;
• provider modules (reaktor-cloudflare, reaktor-google, Kubernetes/server/database adapters): provider SDK/config mapping only;
• reaktor-flow: System Fabric projection, semantic zoom and renderer contributions;
• BestBuds engine: BestBuds resource descriptors, saved views and product shell, not generic resource models.

Deprecate CloudResource.metrics: Map<String,String> in favor of typed claims/evidence and metric references. Adapt the current CloudProvider/CloudToolProvider during migration; do not break working Dagger/Pulumi operation fingerprints. Replace “failure → empty inventory” with stale fragment/error evidence. Expand Wrangler source parsing to every binding/config kind, then add a separate authenticated live Cloudflare observer; never upgrade source inventory to Live.

15.10 Safety, scale, and conformance gates

The provider test kit supplies the same fixtures to every adapter: source-only, live, stale, partial, conflicting, permission denied, rate limited, paginated, deleted during refresh, duplicate IDs, renamed resources, regional outage and malformed provider payload. It verifies stable identity, bounded pagination, cancellation, redaction, backoff, rate-budget accounting, stale preservation, deterministic merge and zero secret values.

Reference budgets on pinned hardware:

• first useful cached fabric ≤2 s; first partial uncached scope ≤5 s;
• 10k-resource delta refresh/projection ≤1 s after provider response; indexed filter/query p95 ≤150 ms;
• 100k-resource registry query p95 ≤250 ms; visible rich nodes bounded to the current viewport/LOD;
• no canvas reframe or focus loss on refresh; no main-thread provider work;
• provider event/log/message streams are bounded with explicit dropped/backpressure counters;
• eight-hour refresh/stream soak has ≤10% retained-heap growth and zero leaked process/client/session handles.

Binary acceptance for the first System Fabric release:

1. Source and live observations for Cloudflare, Kubernetes/k3s, GCP Pub/Sub, Postgres, ClickHouse and Memgraph coexist in one snapshot with stable identity and evidence.
2. D1, Durable Objects and ObjectDatabase have type-specific inspectors and safe bounded query/browse contracts; unsupported instance discovery renders Unknown.
3. Desktop, JSON/MCP and Graph Studio return the same resource identities and snapshot hash.
4. A provider outage preserves stale inventory; no source record or fixture appears live.
5. One traced journey crosses Worker → queue/topic → consumer/server → authoritative store → analytics/graph projection → dashboard with gaps rendered as findings.
6. One Kubernetes release shows source manifest → artifact digest → workload/replica/pod/service/storage → telemetry → rollback evidence.
7. Every mutation is a sealed, authorized, drift-checked operation with a complete receipt; attempted cross-environment, stale-plan, replay and self-approval mutations produce zero effect.
8. Secret/PII canaries do not appear in graph, results, logs, snapshots, support bundles or MCP.
9. Provider adapter conformance, accessibility/state matrix and 1k/10k/100k performance gates pass on macOS, Windows and Linux.
10. A non-BestBuds external environment supplies at least one provider/data/message adapter and completes an inspect → query → trace → governed non-production operation loop.

Build score. Two scores below: Cloud (observed-state reads to fill "live health not queried yet", drift chips, naming repair) and Deploy promoted to an authored family — both are the near-term slice of the System Fabric above.

Build score §10 — Cloud — from inventory to fleet truth

Today (verified): 4/6 wired. 138 Cloudflare workers + bindings with per-resource dashboard links, k3s desired-manifest resources with Kubernetes docs links, safety-classed ops (Apply k3s = ProductionReversibleWrite Plan-gated; status/radar = LiveRead), provider chips (cloudflare/firebase/gcp/google-play/grafana/app-store-connect), honest empty Deploy/Pipeline/Runs/Cost regions with turn-on lines. The rail's naming collapse (six "AI"s) is D7's poster child.

Acceptance: the September k3s disk incident (OPEN_QUESTIONS) replayed as a demo: Resources shows the node pressure fact → Operations offers the runbook → the run's evidence lands in the ledger → Diagnostics closes the finding. The pane must beat "ssh + kubectl + dashboard tabs" for that real workflow.

Build score §11 — Deploy — release truth as a first-class family (D9)

Today (verified): the artifact inventory is honest and good (present/absent/FAILED per artifact with the exact "run the corresponding r…" remedy), consoles jump-out, gated Fastlane/desktop-package ops, "66 gated SRC" chip, deployment run history LIVE. History/targets tabs are thin derived views.

Plan: D9 promotes Deploy to an authored family (All · Workers · Mobile · Web · Server · Desktop · Artifacts · History). V1 (Phase 4): per-target release state = artifact truth (exists) + deployment status reads (shared with Cloud/Deploy); History becomes the release timeline over the run ledger filtered to deploy-domain effects; the Deploy top-bar button routes here with context. V2 (Phase 5–6): the constitution's progressive plan — change set → affected targets (graph blast radius via reaktor-devops partition edges) → artifacts → gates (Testing results as gate evidence) → approval → rollout → verify → close/rollback; the walk's honest "No Desktop signing, notarization…" note becomes a tracked release-factory dependency (constitution Gate 3), not a footnote. Acceptance: one worker deploy runs end-to-end from this pane with plan, phrase, evidence, and a rollback that has been rehearsed — the first Proof C rehearsal in miniature.

16. Observe workspace — telemetry as graph evidence

Current authored binding is roughly 2/9. Configuration-derived sources/pipelines stay visibly distinct from observed signals.

The bottom drawer is the fast evidence view; Observe is the full investigative workspace. They use the same records and queries.

Acceptance: an observed user action can be followed across UI event -> actor/port -> service -> queue/store -> response; a gap is a finding, not an invented edge. Deploy markers, logs, metrics, trace, profile, and error share revision/release identity.

Build score. Telemetry is the one family with a true prerequisite: an actual evidence pipeline. The order below builds it (exporter, bounded local store, parenting fix) before any subpane claims live signals.

Build score §13 — Telemetry — evidence pipeline first, dashboards never

Today (verified): 2/9 wired (Sources: Grafana config discovered + deep link; Freshness: ten Perf* runners). Seven subpanes honestly dark.

Plan. The blocker is real: there is no evidence pipeline (§18.4 — Graph.instrument() emits spans with no exporter, and its child-graph parenting bug). Order:

1. Phase 3: fix GraphTelemetry parenting; add the OTLP exporter wiring to the local collector config the repo already has (performance-observability.md stack); persist a bounded local span/metric store (reaktor-db SQLite) so the Desktop is useful offline.
2. Phase 4 subtab V1s: Spans = trace search/waterfall over the local store + Grafana deep link per span (graph-attributed via the node ids in span attrs); Metrics = the performance collector's ReaktorPerformanceReport series + budget violations rendered natively (models exist, §18.5); Logs = shared multiplexer (§7); Profiles = flamegraph render of ReaktorFlamegraphFrame (models + JVM capture exist; the FlexBuffer flamecharts are the first real content); Crashes = Crashlytics deep link + local desktop crash log parse; Alerts = rule definitions from the observability stack as Source facts; Pipelines = collector config desired-state (Source) with health Unknown until probed; eBPF stays a labeled future with its card.
3. Phase 5: deploy markers on every time series (release identity from Deploy), exemplar links span↔metric, and the drawer Traces tab feeding from the same store (D10). Acceptance: one BestBuds request traced UI→actor→service→worker with the graph path highlighted and the gap segments explicitly "unobserved" — constitution §16's acceptance, scoped to the dogfood app first.

17. Learn workspace — analytics and economics

Current authored binding is roughly 2/8. All personal data, experiments, and exports are privacy/authorization scoped.

Analytics event definitions are graph-visible contracts. Reaktor validates naming, schema, consent, classification, cardinality, sampling, and route/feature attribution before a release. A chart without data quality and freshness is not “live.”

Acceptance: an experiment moves from hypothesis -> graph/event changes -> assignment tests -> release -> exposure -> performance/error/cost guardrails -> readout -> decision -> rollout, with reproducible queries and evidence.

Build score. Analytics wires through bounded aggregate reads over the already-proven edge path, with freshness and query provenance on every chart and privacy rails from the start.

Build score §14 — Analytics — product truth with privacy rails

Today (verified): 2/8 wired (Performance: task timeline + funnel resource + honest ClickHouse gating; Reports). The events table is partitioned and reachable via the proven VPC probe.

Plan. V1 (Phase 4): a bounded ClickHouse read (aggregates only, no raw event browsing by default) fills Performance KPIs, Errors (client error groups), Funnels (the onboarding funnel the board authors, definitions versioned in repo), Retention/Cohorts (privacy-safe definitions from BestBudsEvents taxonomy); every chart carries freshness + query provenance chips; Costs joins Cloud's billing read; Reports = saved query+view artifacts with snapshot time. V2 (Phase 5–6): Experiments wired to the config-actor variant system (board 11.03's model); event-contract validation pre-release (naming/schema/consent lint from the analytics doc §13) surfacing as Diagnostics findings; release-correlation annotations shared with Telemetry. Guardrail: aggregates by default, raw reads privileged + audited (analytics doc's MCP rule applies to the UI too). Acceptance: D7 kept-buds retention renders from live ClickHouse with its definition visible, and a release marker shows on the curve.

18. Universal surface contract

The app, mode, shortcut, pane, action, adapter, permission, help, test, and Pencil registries currently disagree. Replace those parallel declarations with a generated CapabilityManifest and typed SurfaceContract registry.

data class SurfaceContract(
    val id: SurfaceId,
    val label: String,
    val movements: Set<Movement>,
    val instrument: Instrument,
    val requiredCapabilities: Set<CapabilityId>,
    val factSchema: SchemaId,
    val actionIds: Set<ActionId>,
    val applicableStates: Set<SurfaceState>,
    val keyboardContract: KeyboardContract,
    val performanceBudget: PerformanceBudget,
    val accessibilityContract: AccessibilityContract,
)

The manifest drives:

• system/application discovery;
• navigation, labels, order, icons, shortcuts, and deep links;
• pane/subpane visibility and NotWiredYet reasons;
• adapters, fact schemas, truth requirements, actions, effects, and permissions;
• command-palette entries and contextual agent tools;
• help/documentation and onboarding;
• semantic IDs, goldens, state tests, E2E journeys, and coverage reports;
• release feature/capability reporting.

18.1 Required data states

Every applicable surface implements:

1. initial/loading using the real anatomy, without invented metric skeleton values;
2. live;
3. source/configuration only;
4. fixture/demo, permanently and visibly marked;
5. known empty, including the query/scope which produced zero;
6. partial, with provenance per region;
7. stale/offline, preserving last evidence and its age;
8. unknown/not wired, naming the missing adapter/capability;
9. failed, retaining stale prior data when safe and offering retry/detail;
10. permission denied without leaking resource counts or names;
11. high volume with virtualization/aggregation;
12. no selection with a useful next action.

Zero, Unknown, Not applicable, Permission denied, and Adapter failed are different states.

18.2 Required action states

Every action has a typed envelope:

verb + subject + target
workspace + revision + environment + target
principal + required capabilities
effect + reason
preconditions + current evidence
diff/plan + blast radius
approvals + expiry
expected artifacts/evidence
rollback/recovery + verification
correlation ID

Actions implement available, unavailable with reason, permission denied, preparing, planned, awaiting approval, queued, running/progress, succeeded, failed, cancelling, cancelled, rolled back, reconciliation unknown, and recovered states. No disabled control is a dead end; it explains the blocker and safe remediation.

18.3 Required interaction states

Every control covers default, hover, pressed, focus-visible, selected, disabled, loading, validation error, operation error, and permission-denied. Modal/drawer/palette transitions restore focus. F6 cycles global header -> navigator -> primary projection -> inspector -> evidence drawer. / focuses local search; Esc unwinds the nearest transient layer; arrows/Enter/Space follow platform patterns.

18.4 Truth cannot be bypassed

• Visible facts and operation preconditions accept typed evidence/fact objects, not raw health/status/metric strings.
• Live facts require source, asOf, TTL, and source revision and become stale automatically.
• Health accepts a health-specific claim policy; renderers cannot infer it from text or color.
• Fixture, Source, Inferred, Partial, Stale, and Unknown may inform a plan but never satisfy a live production precondition.
• Static analysis/KSP gates raw-state escapes; source-string tests are supplemental only.
• Every fixture is test/demo-only or permanently marked.

18.5 Surface coverage gate

A generated report lists:

• every primary movement, legacy/source mode, instrument, family, pane, subpane, inspector tab, drawer tab, toolbar control, authored action, and shortcut;
• every applicable data/interaction/action state;
• semantic, unit, golden, keyboard, accessibility, high-volume, failure, and E2E evidence;
• current implementation owner, status, blocking capability, and release gate.

Missing, duplicate, unowned, skipped, ignored, or undocumented surfaces fail CI. A Pencil change cannot reach production until the manifest and tests classify it. A source-only mode cannot appear in release notes until the packaged artifact test sees it.

18.6 Selection, inspector, drawer, and responsive invariants

Selection belongs to WorkbenchContext, not to a mode-local remember(mode) state. The same ElementId/resource/query/run remains selected while moving Canvas ↔ Fabric ↔ State ↔ Trace ↔ Validate ↔ Act, switching Map/Outline/Table, opening a specialist tool, changing a compatible lens, and restarting Desktop. If a new scope excludes the selection, the UI retains a breadcrumb ghost with a precise reason and offers “return to scope”; it does not silently clear context.

The global inspector receives the actual selection and renders registered contributions. Operational detail is not reimplemented inside every pane. The drawer is context-scoped: selecting a resource filters Activity, Evidence, Query Results, Diff/Plan, Logs/Events, Metrics/Traces and Diagnostics; selecting a run highlights its affected entities. The current drawer tab named Network must become actual network/request/connection evidence rather than a disguised cloud inventory.

Responsive behavior is a state machine, not forced collapsed strips. At medium width, navigator and inspector become keyboard-accessible overlays/sheets with focus trap and restoration. At compact width, Reaktor prioritizes incident triage, evidence review and approval through Outline/Table; it does not shrink a graph or SQL workbench into unreadability. An expand action must always reveal the region it names. Tests exercise open/close, focus, selection preservation and 200% scaling at every breakpoint.

Build score. The gates below are the near-term test additions that enforce this contract on today's registries, ahead of the full generated manifest.

Build score §20 — Gates and tests added by this plan

Beyond the existing four-altitude harness (which stays sovereign): ModeShortcutParityTest · SelectionPropagationTest · SurfaceManifestSyncTest (Compose/React/palette/MCP read one manifest) · DeadCodeAbsenceTest · DrawerCountTruthTest · MachineSignalTypeAuditTest (ramp floor) · theme-contrast goldens for provenance colors in light mode · WorkbenchShellRenderTest extended to 12/12 modes with per-mode paint floors and a persistence round-trip · scope-toggle latency budget in ReaktorDesktopPerformanceTest (≤50ms) · framework-side: CHM model-checking/forced-resize suite, port-registry concurrency test, autoWire diagnostic tests, PortEvent ordering test. Every phase's exit list above is a required-green set, and per D16 no surface ships without its gate.

19. Trust before autonomy

The revolutionary feature is not that Reaktor can run more things. It is that a human and an agent can be trusted to operate the same real system through visible, constrained, reversible machinery.

19.1 Workspace trust and isolation

Every repository is untrusted until explicitly granted capabilities.

Trust levels:

• Untrusted: bounded parser-only discovery; zero child processes/network/workspace writes;
• TrustedRead: reviewed read operations inside sandbox;
• TrustedLocalWrite: declared local output roots and effects;
• TrustedRemoteWrite: explicit target/provider capabilities and governed plans.

Trust binds canonical path, VCS remote, and repository identity key and does not transfer silently after identity change.

Replace script-name heuristics with reviewed OperationDescriptors containing stable ID, expanded transitive command, executable/interpreter/definition/lock digests, effect, environments, filesystem roots, egress domains, required secret names, artifacts, timeout, rollback, and verification. An unknown/inferred command stays blocked. The UI shows the expanded closure, not only npm run name.

ExecutionIsolationProvider enforces:

• workspace read-only by default and a fresh declared output directory;
• no parent home, keychain, SSH agent, Docker socket, cloud config, or ambient secrets;
• minimal allowlisted environment and isolated temp/home;
• network denied unless allowlisted;
• owned/reaped descendant processes;
• symlink/path/decompression/recursion/resource limits;
• fail-closed behavior if the platform cannot enforce the declared sandbox.

Gate: the malicious-workspace corpus produces zero unauthorized processes, network calls, reads, writes, secret access, escapes, or orphans on macOS, Windows, and Linux.

19.2 Plans and approvals

A canonical execution receipt contains actor; workspace/revision/dirty digest; exact argv and executable/definition/lock/sandbox/secret-version hashes; effect and reason; target/environment; capabilities; resource diff/blast radius; preflight/test evidence; artifacts; rollback/verification; expiry; and nonce.

Approvals are signed capabilities, not names or booleans:

• requester, executor, and approvers are authenticated principals;
• independent approval means a different human, session/device, and policy role;
• agents/service accounts cannot satisfy a human gate;
• production fails closed when approval or ledger services are unavailable;
• approval binds the exact plan fingerprint, target, revision, expiry, and one-use nonce;
• drift, replay, expiry, revocation, or identity change invalidates it;
• “reversible” requires a tested rollback/backup/precondition/verification and maximum window; otherwise classify the operation as destructive.

Plans, decisions, transitions, provider receipts, artifacts, verification, and rollback enter an append-only hash-chained ledger. Sensitive output is encrypted, separately retained, and unnecessary to verify the receipt.

19.3 Authorization and privacy

Add a pure ResourceAuthorizer beside LocalAuthorizer, with optional graph projection. Every external handler binds principal, tenant/app, resource, and action before data access. Generated negative matrices are mandatory.

Immediate BestBuds containment covers the same enumerated findings: object-level authorization on realtime and social surfaces, profile-data minimization, token subset/delegation and refresh correctness, per-service workload identity, credential rotation with history purge, synthetic development data, and stable bounded public error behavior. The itemized list lives in the private security review.

No production mutation or design-partner rollout proceeds with open Critical/High object-authorization, token-mint, secret-containment, or privacy findings.

19.4 MCP split

Keep the local MCP read plane small, authenticated, bounded, schema-redacted, and free of executor dependencies. A separate mutation broker performs call-time identity/scope/plan/approval checks. Port conflict, duplicate writer, or bind failure exits loudly; headless mode never waits forever without a server.

Gate: unauthenticated/stale credentials return no data; malformed/oversized fuzzing cannot crash/hang/leak; symbol/dependency scans prove the read server has no mutation path; every broker call has a verifiable audit chain.

19.5 Plugin and extension security

The in-process extension SPI in section 7 is restricted to trusted built-in/local development extensions until isolation exists. Third-party plugins run out of process with signed manifests declaring publisher, digest, API version, effect ceiling, filesystem/network/process/secret capabilities, provenance, and SBOM. Default capability is none; updates which expand capability require consent; revocation and safe mode work offline.

No marketplace or unsigned sideloading ships before an independent sandbox/supply-chain assessment reports zero Critical/High findings.

20. Performance and scale budgets

Performance budgets are release gates measured on pinned reference hardware and published with profiles. Synthetic fixtures establish repeatability; at least one production-shaped external repository validates relevance.

20.1 Product budgets

20.2 Graph/model budgets

Implement persistent indexed maps; adjacency/kind/contract/source/evidence indexes; delta merge/validation; delta-driven flow projection; spatial index; viewport culling; LOD/scope aggregation; bounded streams; and no repeated linear edge/node scans in minimap/render hot paths.

Twenty-run median/P95, variance, CPU, RSS, allocation, heap, and profiles are CI artifacts. Absolute breach or >10% regression fails the release lane unless a documented budget revision is reviewed; deleting or weakening a failing gate is not a fix.

Correctness/property gates cover deterministic hashes, patch inverse, conflict behavior, idempotent refresh, merge policy, no-lost-delta concurrency, connection transactionality, lifecycle leak absence, and the concurrent-map forced-resize race.

21. Release factory and operability

21.1 Mandatory reproducible CI

• Required PR/push/tag checks with branch protection; Dagger is the same canonical pipeline locally and in CI.
• Immutable action, Dagger, JDK, Node, Gradle, image, and toolchain versions/digests.
• Remove machine-local Java paths; wrapper checksum, Gradle verification metadata, committed locks; no mavenLocal/snapshot release resolution.
• Matrix: Linux JVM/JS/Workers/contracts; macOS arm64+x64 Desktop/iOS/signing; Windows MSI; Android emulator; MCP/property/fuzz/concurrency/security; packaging/update/restore; scheduled performance/soak/DR.
• Clean runner and network-offline build after dependency acquisition.
• SBOM, license, secret/history/SAST/dependency scans, signed provenance, artifact hashes.
• Test once and promote the exact tested digest; release never rebuilds.

Gate: twenty consecutive cache-disabled clean builds; deliberate test/security/lock failures block merge; two isolated runners reproduce the unsigned payload; aborted/timed-out/quarantined evidence never reports green.

21.2 Native product shipping

• Split Desktop core from Spring/Kubernetes/Pulumi/GCP/Firebase/server/provider implementation graphs.
• SemVer from signed tag; exact version/commit/digest in About, packages, feed, provenance, symbols.
• macOS arm64+x64/universal decision; Developer ID, hardened runtime, notarize/staple.
• Authenticode Windows; signed Linux packages/repos.
• Signed TUF-style update metadata, offline root, expiry, channels, staged rollout, pause/rollback, atomic install, anti-downgrade, no arbitrary post-install script.
• Explicit consent for major version or permission/capability changes.

Gate: clean-VM install, first launch, N-1 upgrade, rollback, uninstall; tamper/MITM/expiry/interrupted-download/disk-full retain last good version; beta update success >=99%; crash-free sessions >=99.5% before stable.

21.3 Telemetry and SLOs

Instrument dynamically added graph nodes and the whole intent -> plan -> approval -> run -> provider/process -> outcome chain. Low-cardinality catalogs, privacy classification, source redaction, consent/opt-out, retention/deletion, and a previewable encrypted support bundle are mandatory.

SLOs cover launch, catalog freshness, MCP availability, governed-operation success/latency, update health, and evidence completeness. Alerts name owner and runbook. Export loss becomes Unknown; it cannot fabricate healthy status.

21.4 Recovery

• Ledger durability is fail-closed before production effects.
• Remote work reconciles on restart.
• Immutable image digests and GitOps reconciliation.
• Least-privilege runtime policy: non-root, read-only FS, dropped capabilities, constrained egress, documented exceptions.
• Off-node backups and quarterly timestamped restore drills.
• Recommended objectives: critical relational/auth RPO <=5 min/RTO <=60 min; approval/run ledger RPO 0 before effect/RTO <=30 min; Memgraph RPO <=24 h/RTO <=4 h; ClickHouse RPO <=15 min/RTO <=4 h.

Gate: node/namespace loss, full disk, corrupt ledger, expired credential, provider outage, and exporter loss drills meet objectives and leave truthful product state.

22. First three end-to-end product proofs

Breadth does not prove the system. Three complete journeys do.

Proof A — ten-minute brownfield x-ray

On a repository not owned by the Reaktor founder:

1. open as Untrusted;
2. parser-only scan detects languages/builds/apps/services/data/cloud/tests/telemetry;
3. show progressive source-backed product landscape with evidence/confidence/gaps;
4. search one feature and trace UI/API -> service -> store -> tests -> deploy;
5. calculate known/unknown blast radius;
6. open exact symbols in JetBrains/VS Code;
7. export a redacted verified context pack to Codex/Claude;
8. run one trusted read-only diagnostic in isolation and retain evidence.

Success: first map <=3 min; useful feature path <=10 min; no process starts before trust; topology precision >=95% and recall >=90% on the reviewed fixture; every unknown is explicit.

Proof B — programmable graph loop

On a small external sample:

1. create five typed nodes and ports;
2. introduce a contract mismatch and receive a precise finding;
3. fix it and compile deterministically;
4. preview generated source/config and impacted tests;
5. approve/run locally through the trust kernel;
6. observe values/events/traces;
7. close and reopen with identical spec hash/history/evidence;
8. query and propose the same journey through authenticated MCP.

Success: UI, API, agent, runtime, persistence, and MCP all use the same spec/snapshot/delta/plan identities; stale-base edits conflict instead of losing updates.

Proof C — feature-to-production symphony

Use a bounded BestBuds journey, then repeat with a design partner:

1. select a user journey in Graph/UI Flow;
2. inspect preview, source, state, identity, AI, and runtime path without reselection;
3. record a semantic test and run impacted functional/a11y/visual/security/performance gates;
4. propose a source/graph change with blast radius;
5. build signed artifacts and review desired/observed deploy diff;
6. obtain real approvals and roll out to non-production/canary;
7. correlate release with traces/errors/funnel/cost;
8. verify success or execute proven rollback;
9. close the Mission with the complete receipt.

Success: no manual reconstruction of workspace/environment/target/revision/entity/time/run; every surface contributes to one evidence chain; external specialists open and return to the same context.

Proof D — System Fabric inspect, query, trace, and reconcile

On a non-production environment containing at least one Cloudflare Worker/Durable Object/D1 resource, one Kubernetes server workload, Postgres, ClickHouse or Memgraph, and a Pub/Sub or Queue path:

1. import source/IaC without executing the workspace and render Source/Unknown resources;
2. connect authenticated read observers and retain source, recorded, and observed planes independently;
3. traverse Worker → message topic/queue → consumer/server → authoritative dataset → projection → dashboard/trace;
4. inspect schemas, authority/projection roles, bindings, delivery semantics, tenant/security boundaries, releases and current evidence;
5. run one bounded parameterized read on two different data engines and correlate the receipts with source/trace/graph entities;
6. induce safe non-production drift and show the exact desired/recorded/observed disagreement without losing selection;
7. prepare and approve one reversible infrastructure or data change, execute it through the shared control plane, observe reconciliation, verify, and retain its receipt;
8. close and reopen Desktop with the same resource identities, queries, evidence, plan and history.

Success: Desktop/JSON/MCP share the same snapshot hash; unavailable adapters become Stale/Unknown; no secret or unmasked sensitive value appears; attempted cross-environment, write-through-read, stale-plan, replay and self-approval actions have zero effect; a specialist console deep link returns to the same context.

23. Delivery program and gates

Dates are forecasts, never substitutes for exit evidence. Mutation, public installers, production beta, and plugins are independently gated.

Gate 0 — containment and unsafe primitive correction (weeks 0–2)

Deliver:

• fix BestBuds P0 authorization and privacy paths and rotate/reissue credentials with a history scan/purge plan, stopping raw production seeding;
• close the containment set summarized in Appendix H — credential revocation and artifact purge, read-path privilege separation, health-endpoint truthfulness with fail-closed environment selection, push-route authentication, service-credential scoping away from destructive operations, transactional backup/restore, and least-privilege cluster identities. (The specific routes, credentials, and endpoints are enumerated only in the private security review; each becomes a rendered in-product finding with a verification run.)
• fix/replace concurrent map race; deterministic IDs; owned graph handles; read-path leaks; transactional connections;
• fail loudly on MCP bind/duplicate writer;
• freeze current codecs/API/golden fixtures and establish performance hardware/fixtures.

Exit:

• focused security retest has zero Critical/High;
• no active secret in reachable history/artifacts; dev data has zero production direct identifiers;
• every shipping jar/image/resource scan contains zero private credential material; the exposed service-account key is revoked;
• the read-query adversarial corpus produces zero writes and every unauthenticated/forged provider push produces zero downstream effect;
• dependency failure makes readiness false; a dev target can never contact production without an explicit production-class alias plan;
• generic service credentials cannot call destructive GraphQL, restore or purge; interrupted restore/purge tests prove resumable, reconciled cross-store outcomes;
• a compromised Desktop/read identity cannot read cluster secrets, mint credentials, alter RBAC or open an exec/attach/proxy/port-forward channel; the denial matrix is exercised against a real isolated cluster;
• graph inspection creates zero actor jobs/scopes; attach/detach/close leak tests green;
• forced-resize concurrency/model test cannot lose/resurrect an update;
• repeated exports hash identically 100/100.

Gate 1 — one product contract and trust kernel (weeks 2–8)

Deliver:

• CapabilityManifest, SurfaceContract, shared WorkbenchContext, deep-link/history restoration;
• four movements + instrument model behind feature flag; legacy destinations preserved;
• workspace identity/trust, declarative operation descriptors, cross-platform isolation, minimal environment;
• canonical signed plan/approval receipt, authenticated independent approver, durable ledger;
• authenticated read MCP and separate mutation broker, but mutation remains disabled until exit.

Exit:

• source, Pencil, packaged modes/actions/shortcuts derive from the same manifest;
• malicious-workspace suite passes; plan drift fails 100/100;
• same-human/agent second approval is impossible; crash injection cannot execute uncommitted/unapproved effect;
• context propagation/deep links restore deterministically;
• this gate authorizes the first bounded mutation.

Gate 2 — canonical model, registry, and read wedge (weeks 4–12, parallel)

Deliver:

• reaktor-graph-model with spec/snapshot/delta/view/evidence/claims/contracts;
• resource/data/message facets plus stable System Fabric identity and desired/recorded/observed claims;
• V1 adapters for current GraphDocument, live Graph, architecture, tooling/cloud inventories and operational resources;
• source registry, merge/conflict, indexes/query, desired/observed views;
• source-only adapters for full Wrangler bindings, Kubernetes manifests, database migrations/descriptors and message topology without promoting configuration to health;
• manifest/snapshot inspection with no runtime activation;
• brownfield onboarding and Proof A.

Exit:

• Desktop, JSON export, and MCP share snapshot hash;
• all snapshot data has evidence or explicit Unknown;
• native/wrapped/scanned/observed entities coexist without identity drift;
• source outage produces stale evidence, never fake health;
• Canvas, Data Studio and System Fabric retain one resource identity and selection across views;
• external brownfield Proof A meets accuracy/time/trust targets.

Gate 3 — release factory and product integrity (weeks 4–14, parallel)

Deliver:

• required reproducible CI/security/supply-chain matrix;
• signed/notarized slim installers and safe updater;
• complete state/interaction/action test generation for the surface registry;
• Machine Signal 2.0 themes/density/accessibility;
• hard performance/soak budgets.

Exit:

• twenty clean reproducible greens and exact-digest promotion;
• clean-VM install/update/rollback on support matrix;
• 12/12 source modes and 74/74 authored subpanes accounted for, even when intentionally hidden/unwired;
• zero skipped release tests, zero Critical/Serious accessibility issues, all hard performance budgets green;
• this gate authorizes a public beta installer, not production effects.

Gate 4 — edit, compile, persist, and vertical symphony (weeks 10–22)

Deliver:

• patch-based graph editor, typed ports/contracts, compiler passes/findings, local store/migrations;
• runtime/source/config materializers through the generic governed control plane;
• correlated evidence timeline and dynamic graph telemetry;
• complete Graph/Build/Prove/Operate vertical slice and Proofs B/C in non-production;
• bounded provider-native Data Studio reads for Postgres plus at least two of ClickHouse/Memgraph/D1/ObjectDatabase, with schema, query receipt and lineage;
• authenticated live observers for one Cloudflare account, one Kubernetes cluster and one message provider; provider failure preserves stale evidence;
• System Fabric graph/table/inspector plus desired/recorded/observed drift and Proof D in non-production;
• one provider-neutral agent workflow using the same mutation spine.

Exit:

• Proof B passes end to end and after restart;
• Proof C passes on BestBuds non-production with a verified rollback;
• Proof D passes end to end, including write-through-read, cross-tenant/environment, stale-plan and secret-redaction negatives;
• human and MCP invocations yield identical plan/event schemas;
• stale edits conflict, compilation is byte-identical, cancellation/recovery is truthful;
• every action remains inside trust/authorization boundaries.

Gate 5 — operational design-partner beta (weeks 18–30)

Deliver:

• SLOs, privacy-safe telemetry, support bundles/runbooks, GitOps/DR hardening, seven-day soak;
• extension SDK with one independently built trusted extension;
• at least three external design partners on different stacks;
• specialist integrations for IDE, agent, build, cloud/IaC, telemetry, and data deep links.

Exit:

• all failure drills meet RPO/RTO; every governed run is correlated; soak has no unbounded resource trend;
• external extension installs/unloads without BestBuds/Compose dependency or leaked state;
• partners complete Proof A and at least one completes Proof C safely;
• this gate authorizes bounded design-partner production use.

Gate 6 — field proof (60 measured days after Gate 5)

Exit:

• =3 external teams actively use Reaktor in production for 60 days;

• collectively >=500 governed runs/month and >=20 real production deployments;
• no approval/sandbox bypass;
• update success >=99%, crash-free sessions >=99.5%;
• measured time-to-map, time-to-diagnose, change lead time, rollback/recovery, and escaped-error improvements;
• at least one production use does not depend on Kotlin-native adoption.

This is platform proof. Pane count, code volume, and BestBuds dogfood are not substitutes.

Gate 7 — extension ecosystem and scale claims

Deliver only after Gate 6:

• out-of-process signed plugin runtime, registry/transparency/revocation/safe mode;
• independent sandbox/supply-chain audit;
• polyglot bindings after conformance;
• 1k/10k/100k scale gates;
• remote collaboration/registry or distributed actors only behind their own harnesses.

No public plugin marketplace, autonomous production agent, distributed-actor, or mega-scale claim before its binary gate.

Build score. The six phases below are the workstream view of the gates above — each independently shippable, each with exit evidence, mapped to Gates 0–4 and the Graph G-ladder.

Build score §19 — Sequencing — six phases, each independently shippable

Aligned to the constitution's gates (G0–G4); dates are forecasts, exits are evidence. Every phase ends with: all suites green, the surface-coverage report regenerated, a pencil sync (§4.6.6), and a packaged smoke on macOS.

Phase 1 — Truth of what exists (≈ G0, weeks 0–2). Identity fixes (D7) · concurrency blockers (D12) · shortcut canon + parity test (D5) · dead-code deletion (§5.9, D16 gates) · drawer count truth (D10) · token single-sourcing + legacy MachineSignal deletion (D6) · rail count semantics (§5.4a) · overflow/pluralization kit fix · golden-loop doc IA rewrite (D1) · instance lock (§5.1) · pen-truth re-extraction + parity re-baseline + board: transcription update once the atlas wave lands (§4.7). Plus the constitution Appendix H stop-ship containment set (server/infra side, same gate): the seven findings summarized in Appendix H — credential revocation and artifact purge, read-path privilege separation, health-endpoint truthfulness, push-route authentication, service-credential scoping, transactional backup/restore, and datastore recovery posture. Each lands as a rendered finding in Build score §9 Security with its verification run. Exit: zero "ServiceNode"-titled nodes in the self-graph; 12/12 chords work; deleted files stay deleted; forced-resize CHM test green 100/100; no active secret reachable in history/artifacts; the Appendix-H findings are visible in-product with owners.

Phase 2 — One context (≈ G1 core, weeks 2–6). WorkbenchContext + selection propagation + inspector-everywhere (§5.6.1) · context row + history + deep links (§5.3) · persistence of chrome/context (G7) · one search service (D15) · verb fabric v1 (3.2) · graph navigation completeness (§6-P2) · app-switch ownership (D13) · WorkbenchSurfaceManifest + sync tests (D8) · DevTools chrome unification (§7). Exit: the constitution's context examples work verbatim for existing data (select ChatActor in Graph → DevTools Source/Trace/Testing views scope to it); deep links restore deterministically; SelectionPropagationTest green.

Phase 3 — Evidence everywhere (weeks 6–12). Graph wiring/live overlays (§6-P3) · test-result model + Results/drawer Tests (§12) · log multiplexer (§7 Logs) · telemetry pipeline base + local store (§13.1) · Database Query/Schema/Migrations V1 (§8) · Auth matrix/sessions/simulator (§9) · Cloud observed-state reads (§10) · UI family V1 — the harness-backed five (§16) · AI registry truth (§15.1) · Diagnostics unification (3.3). Exit: wired-subpane count ≥55/74 with every new binding carrying Live/Source facts and freshness; the coverage report is the changelog.

Phase 4 — Deep instruments (weeks 12–20). Telemetry subpane V1s (§13.2) · Analytics V1 (§14) · Agent session transport + MCP live (§17.1–2) · AI first loop (§15.2) · Deploy family V1 (§11) · device lab verbs (§7) · graph scale/a11y (§6-P4) · authenticated MCP read plane + new tools (D11) · principal/avatar (§5.1) · Machine Signal 2.0 axes shipped (D14) · accessibility gate live (§4.3). Exit: wired ≥68/74; one end-to-end trace on BestBuds; AA measured on the shell; MCP requires the capability credential.

Phase 5 — The symphony (weeks 20–28). Missions (3.4) · ambient Ask/Explain (3.5) · impacted-test selection · release gates binding Testing↔Deploy · cost attribution · Kanban/DAG/Runbooks/Memory (§17.3) · remaining subpanes to 74/74 · density mid-tier (§4.4) · movement-projection preview behind a flag (D2) · pencil missing-state boards complete (§4.6.4–5). Exit: Proof C rehearsal on BestBuds non-production passes with a verified rollback; 74/74 + Deploy/Testing families accounted; actions catalog ≥45/54 wired-or-retired (Samples all resolved to generic contracts per constitution Appendix B).

Phase 6 — The composer (Gate 4, weeks 22–30, parallel tail). reaktor-graph-model + patches/conflicts (constitution §7) · canvas editing → GraphCommand (§6-P6) · materialization through governed plans · mutation broker + Propose/Delegate (§17.4) · rename to Composer (D4) · Proof B end-to-end on an external sample. Exit: Proof B passes including restart-identity and MCP parity; stale-base edits conflict instead of losing work; the revised constitution's graph gates G2–G3 are the checklist of record for this phase, and Proof D (external non-production System Fabric journey, §15.10/Appendix H) joins Proof C as the Gate 4 exit pair.

Definition of "dramatically improved" (per pane, checked at its phase): (1) its authored anatomy renders live data with truth chips — no invented numbers, no orphan em-dashes; (2) selection in it travels to ≥3 other surfaces via the verb fabric; (3) it contributes records to the drawer and consumes context from the shell; (4) its actions are Wired or honestly gated with a named dependency — never Sample; (5) it has a golden, a state test, and a keyboard path; (6) using it beats the specialist tool for the cross-cutting version of its job, and deep-links to the specialist for the deep version.

24. Workstreams and ownership

At least these accountable workstreams are required; one person may temporarily cover more than one, but every gate requires an independent reviewer.

Minimum credible early team: founder/architecture lead; senior security/runtime owner; Desktop/product-design engineer; release/quality/platform engineer; graph/compiler engineer; integrations/observability engineer; design-partner/product lead. Independent approver/pentest authority must sit outside the implementation chain, and a second maintainer must be able to review and ship materially.

25. Success metrics

Product outcomes

• time to first truthful map;
• time to trace an unfamiliar feature end to end;
• time from alert to owning source/last release;
• time from intent to reviewable plan;
• percentage of graph entities mapped to source, owner, tests, runtime, and evidence;
• percentage of actions with complete plan/evidence/rollback;
• context continuity: number of manual re-selections/searches per golden journey;
• successful governed runs, production deploys, rollback success, and blocked unsafe attempts;
• change lead time, failed-change rate, recovery time, and escaped defects;
• weekly active external teams and 30/60/90-day retention;
• agent proposal acceptance, correction, rollback, and evidence-citation rates;
• update success, crash-free sessions, startup/input/graph budgets.

Guardrail metrics

• zero live/fixture ambiguity;
• zero open Critical/High authorization/sandbox/secret findings;
• zero unowned executable operations or uncovered external handlers;
• zero release surfaces absent from generated coverage;
• zero production action based on stale/source/inferred/unknown preconditions;
• no sustained idle CPU/resource leak regression;
• no partner-specific hard-coded product contract in framework/Desktop core.

Dashboards are not success. User and operator outcomes must be measured through source-defined, privacy-safe events with explicit query/data-quality contracts.

26. Migration and deprecation

1. Generate a current compatibility manifest from ReaktorMode, DevToolsTab, WorkbenchPaneCatalog, operational subpane discovery, action catalog, shortcuts, and Pencil truth.
2. Treat the packaged nine-mode shell and source twelve-mode shell as versioned legacy profiles until they converge.
3. Add four movements and instruments as a new projection; keep old shortcuts/routes/palette aliases.
4. Migrate one family at a time to SurfaceContract and typed evidence; mixed mode visibly labels legacy projections.
5. Convert legacy provider tabs (Postgres/D1/etc.) into filters/saved views without removing deep links.
6. Convert Agent Goals to Missions; Knowledge to Evidence/Memory; Runs to common ledger.
7. Replace OperationalModels duplication with generic Tooling contracts and adapters.
8. Adapt V1 GraphDocument/architecture exports to the canonical model; retain migration codecs and hash fixtures.
9. Rename “Editor” to “Map/Inspector” in shipping UI until Proof B passes; enable Composer claims only behind capability gate.
10. Remove legacy routes only after telemetry shows near-zero use, migration tooling exists, and documentation/shortcuts offer a replacement.

27. Open decisions which must be resolved deliberately

1. Stable cross-repository identity and rename/move semantics.
2. Canonical contract/schema versioning and compatibility policy.
3. Workspace-local append store format, encryption, retention, and team synchronization.
4. Materialization policy: when graph edits generate code, edit an AST/model, or only propose source patches.
5. Authority policy for desired/observed conflict by predicate.
6. Supported languages/stacks for the first brownfield design partners.
7. Supported OS/architectures and whether macOS ships universal or separate binaries.
8. Which provider/telemetry/data integrations live in base vs signed extensions.
9. Commercial/open-source boundary without paywalling the ability to run safely and self-host.
10. Privacy/data residency model for team registries, telemetry, AI context, and support bundles.
11. Collaboration model and conflict semantics after single-user persistence is proven.
12. Product name. “Reaktor” has material trademark/SEO/category collision risk with Reaktor Group and Native Instruments REAKTOR. Commission professional clearance and make a rename decision before public launch; do not build brand equity on an uncleared name.

Resolved since writing. Several of these are now decided in the build score's decision log: IA migration path (D2), safety-ladder unification (D3), shortcut canon (D5), token single-sourcing (D6), Deploy/Testing authored families (D9), theme axes (D14). The remainder stay open deliberately.

Appendix A — exhaustive surface disposition

This is the count gate for the authored catalog. Detailed target behavior appears in sections 8–17.

Additional packaged operational surfaces retained in the migration:

• Develop: Mobile, Workers, Servers, Workspace, Preview, Trace;
• Agent: Manna, Tasks, Goals, Knowledge, Runs;
• Database filters: Local, Postgres, D1, Memgraph, ClickHouse, plus Schema, Queries, Migrations;
• Auth: Users, Providers, Sessions, Roles, Tokens, Audit;
• Testing: All, Maestro, Playwright, Desktop, Karate, k6, Keploy;
• Deploy: Workers, Mobile, Web, Server, Desktop, Artifacts, History;
• Cloud: Providers, Resources, Bindings, k3s, Operations, Runs;
• Insights: Telemetry, Analytics, Logs, Traces, Alerts, SLO;
• Graph inspector: Inspect, Ports, Runtime, Source, Telemetry, A11y;
• Evidence drawer: Runs, Logs, Traces, Network, Tests, Build, Diagnostics.

None may disappear without a compatibility alias, replacement deep link, usage evidence, migration note, and test update.

Build score disposition. The companion table below assigns every subpane a concrete V1 data plane and an owning build-score section, so nothing in the count above is unowned.

Build score appendix A — full surface disposition (74 authored + app-only)

Binding status is the generated report's job (C5); this table fixes each subpane's V1 data plane and owning section so nothing is unowned. Format: family/subpane — V1 source → section.

devtools (9): preview — live Compose host (wired) →§7 · devices — adb/simctl probes (wired) →§7 · testing — testing-task scoping (wired) →§7 · pipeline — package.json/Dagger stages (wired) →§7 · releases — deploy artifact index →§7 · recorder — Maestro bridge →§7 · traces — graph relationships + run events (wired) →§7 · logs — RunEvent multiplexer (wired→deepen) →§7 · source — source locator index (wired→deepen) →§7. ui (8): canvas — kit registry →§16 · workbench — truth/shell reference →§16 · design-system — MachineSignal introspection →§16 · flow — app route graph →§16 · responsive — pen-truth shell geometries →§16 · a11y — semantics sweep →§16 · visual-tests — golden report dir →§16 · source-diff — composable source index →§16. agent (9): chat — session transport →§17 · kanban — missions+runs →§17 · tasks-dag — missions+runs →§17 · agents — provider registry →§17 · pipeline — session tool stream →§17 · mcp — desktop server inventory →§17 · memory — memory dirs (wired) →§17 · runbooks — typed step lists (wired) →§17 · audit — run ledger chain (wired) →§17. auth (6): providers — source+JWKS probe (wired) →§9 · roles-permissions — heimdall gated read (wired) →§9 · sessions — session-table read (wired) →§9 · audit — audit-table read →§9 · security — findings generator →§9 · simulator — LocalAuthorizer →§9. database (7): all wired — deepen per §8 (query console, schema browse, applied-migration reads, EXPLAIN, FK graph, ledger join, drift). telemetry (9): spans/metrics/logs/profiles/crashes/alerts/pipelines — local evidence store + collectors →§13 · ebpf — labeled future →§13 · sources — config inventory (wired) →§13. analytics (8): performance/errors/funnels/cohorts/retention — bounded ClickHouse aggregates →§14 · experiments — config variants →§14 · costs — billing reads →§14 · reports — saved artifacts (wired) →§14. ai (12): playground — scenario runner →§15 · notebooks — repo notebooks →§15 · models — typed registry →§15 · chain-builder — bot flow projection →§15 · prompts — source-extracted registry →§15 · rag — Vectorize index →§15 · tools — MCP inventory →§15 · evals — golden-set harness →§15 · guardrails — moderation policies →§15 · routing-cost — cost attribution →§15 · ai-traces — bot pipeline logs →§15 · releases — bundle plans →§15. cloud (6): resources/operations/deploy/pipeline (wired) + runs — ledger slice · cost — billing →§10. deploy (app-only→authored, D9): artifacts/history (wired) + per-target status reads →§11. testing (app-only→authored, D9): harness filters + results model →§12.

Appendix B — every authored Pencil action

WorkbenchActionCatalog already does the right thing by forcing every authored control to be Wired, Pending, or Sample. The target disposition below upgrades that classification into a capability/action contract. “Sample” never appears in production as live evidence.

Every action row becomes an ActionContract with identity, capability, effect, permission, plan, evidence, keyboard/semantics, and test coverage. Pencil adds anatomy and interaction intent; it does not add operational truth.

Build score disposition. The resolution schedule below maps every Pending action to the phase of its named dependency and re-authors every Sample as a generic contract.

Build score appendix B — authored-action disposition

The 16 Wired stay. The 38 Pending resolve at the phase of their named dependency (source index → P2/P5; gated read connection → P3; Maestro bridge → P3; device inventory verbs → P4; rollback/promote verbs → P5/P6; agent handoffs → P4/P6; store-dependent saves → with their store). The 12 Samples are re-authored as generic contracts in the pencil pass (§4.6) per the constitution's Appendix B rules — no sample identity ("rc-812", "142 checks", "tr_8f21c") survives in a control. MachineSignalActionCoverageTest remains the ledger; target ≥45/54 by end of Phase 5, 54/54 by Proof C.

Appendix C — Reaktor framework leverage map

The dual-surface rule applies to each row: plain kernel first, optional graph projection second, optional Desktop extension third.

Appendix D — release acceptance matrix

Every release candidate proves:

Appendix E — principal evidence map

This plan synthesizes the full first-party documentation corpus and code; these are the most load-bearing documents to keep synchronized with it:

• AGENTS.md in BestBuds and Reaktor — atomic design, expressivity/composability, dual surfaces, truth, performance, graph/tooling boundaries;
• docs/REAKTOR_DESKTOP_GOLDEN_DEVELOPMENT_LOOP.md — implemented operational control plane and current domain status;
• reaktor-framework-overview.md — full-stack module/graph/Unreal thesis;
• graph-kernel-analysis.md, reaktor_graph_visitors_design.md, graph migration/refinement/source docs — semantic primitives, passes, patches, sources;
• reaktor-unified-system-graph.md, reaktor-graph-hierarchical-ui.md, graph-editor-unification.md — system model, scopes/levels, document/editor;
• reaktor-visual-language.md — formal visual grammar, behavior language, compiler/editor gap;
• reaktor-agentic-tooling.md, Koog/Manna/MCP docs — observe/call/change and governed agents;
• reaktor-ui.md, react-compose.md, react-compose-interop-roadmap.md — atomic UI, renderer ownership, future authoring/runtime;
• reaktor-service.md, actor, auth, DB, server, work, bus/mesh, multitenancy, capability, secrets/security docs — runtime and trust subsystems;
• reaktor-cloud-pane.md, build/devops/CLI/implementation docs — provider/tool/release control surfaces;
• reaktor-analytics-telemetry.md, performance-observability.md — signal/evidence/performance contracts;
• reaktor-competitive-analysis.md, reaktor-megascale-strategy.md, workbench roadmap — cooperation, adoption, and scale discipline;
• modules/reaktor.pen, WorkbenchPaneCatalog, WorkbenchSubpanes, WorkbenchSubpaneLayouts, WorkbenchActionCatalog, shell/graph/inspector/drawer/palette source — authored and implemented UI contracts;
• GraphDocument, GraphEditorSession, ReaktorDocumentEditor, runtime Graph/Node/Port/Edge/Actor/Service source — current model/editor/runtime split;
• OperationalModels, OperationalControlPlane, BestBudsOperationalCatalog, SupervisedProcessExecutor, Desktop MCP/Main — current governed-operation spine and trust gaps;
• both investor diligence reports — verified strengths, blockers, valuation/field-proof requirements.

When documentation and code disagree, code and executable evidence win; this document is then updated rather than used to overrule reality.

Appendix F — Pencil reference-contract checkpoint

The first Pencil implementation wave is deliberately a reference contract, not a claim that all authored boards have been migrated. It proves the interaction language on the highest-leverage surfaces before a broad visual rewrite.

Implemented reference contract

• The primary product movements are Map, Trace, Validate, and Act. Mission Control remains the orientation/resume surface rather than becoming a fifth movement.
• The cross-cutting instruments are Interface, Source, State, Identity, Intelligence, Runtime, Delivery, and Product. Width changes may progressively disclose instruments but may not rename the movements.
• The persistent context carries workspace, runtime island/system, selected entity, environment, target, revision, truth/freshness, trace/run/plan, and the next legal action.
• Contextual actions use Review plan, Run validation plan, Propose, Resume mission, and Open in Map/Trace language. A read-only surface cannot display an Apply or Deploy affordance.
• Operational-looking scenario data is explicitly marked DESIGN FIXTURE, synthetic, masked, source-derived, partial, or stale. Correlation is not rendered as causation.

Machine Signal 2.0 primitives landed in the reference library

The library now contains reusable, themed primitives for:

• TruthMark: Live, Source, Fixture, Stale, Partial, Unknown, and Failed;
• FreshnessStamp and SourceRef;
• EffectMark: Read Only, Local Write, Remote Reversible, and Production Destructive;
• PermissionGate: Approval Required and Denied;
• RunRef, EmptyReason, PlanSummary, and ApprovalReceipt.

The canonical approval receipt exposes the sealed plan identity/hash, actor, independent approver, expiry, target/diff, and rollback evidence. Truth origin, freshness, completeness, and operation outcome remain separate semantics.

The first theme proof covers dark, light, and high-contrast truth-state matrices. Light-theme semantic colors were raised to accessible values before propagation; the shared primary action was also darkened to restore normal-text contrast.

Reference surfaces updated

Acceptance evidence

The following fifteen reference roots were structurally checked after the edits: Machine Signal library, Mission Control, Graph, Live Preview, Validate, Act, Observe, Agent, State, Identity, Product, Intelligence, and the compact/medium/expanded shells.

• 15/15 report zero non-zero Pencil clipping/overflow problems.
• The Identity/RBAC reference went from 84 reported layout problems to 0 by collapsing the competing inspector, reflowing the role matrix, and restoring readable metadata hierarchy.
• Product funnel/regression and Intelligence chain specimens were repaired rather than exempted from the acceptance set.
• No frame remains in Pencil placeholder state.
• Machine Signal 2.0 variables are referenced by real reusable nodes rather than existing as unused token scaffolding.

Explicitly not complete

This checkpoint does not waive Gate 3. The remaining Pencil program is to:

1. componentize the three responsive shell implementations instead of leaving them as parallel ad-hoc structures;
2. migrate the remaining board families cohort by cohort to the shared context, movement, instrument, truth, effect, and permission contracts;
3. replace legacy 7–10 px information density with progressive disclosure and the documented type/hit-target floors;
4. add the full loading/empty/partial/stale/offline/denied/error/executing/recovery state matrix for every applicable surface;
5. finish light, dark, high-contrast, reduced-motion, and 100/125/200% proofs;
6. connect every Pencil action to the typed SurfaceContract and ActionContract registries; and
7. make source, Pencil, package, semantics, accessibility, and golden tests fail together when they drift.

The rule for subsequent visual work is propagation, not proliferation: improve the shared contract, prove it on the vertical symphony, then migrate a coherent surface family. Do not add another impressive but disconnected board.

Appendix G — Graph Studio second-wave checkpoint

The graph-specific Pencil wave implements the interaction architecture in §8 on the most important power-user boards. It is a design contract, not an assertion that the current Desktop can execute the depicted edit/compiler/debug lifecycle.

Reusable graph primitives added

• Graph / Studio Control Deck — Map/Trace/Validate/Act, Explore/Edit/Debug/Compare, structured query, revision/draft state, semantic level, bounded lenses, truth plane, freshness, and evidence coverage.
• Graph / Time Controller — live/snapshot/replay state, range/progress, playhead, timestamp, and span/event summary.
• Graph / Lens Stack — one base lens plus bounded overlays with current evidence/time context.
• Graph / Boundary Portal — typed cross-scope boundary with contract/destination/count semantics instead of an unreadable cross-canvas wire bundle.

These are reusable Machine Signal components rather than decorations embedded in one board.

Full-system graph reference

ZCxzu is now Map · Full System Studio — Command Density. It demonstrates:

• the two-row Studio control deck;
• stable L2 scope/focus context;
• Structure base with Runtime and Change overlays;
• Desired + Observed comparison, freshness, evidence coverage, findings and a draft-change count;
• saved system/feature/change/production views;
• explicit scope and finding summaries;
• stable contract-aware node and boundary semantics;
• bounded lens and time/replay controllers;
• selection inspector with semantic identity, desired/observed truth, contracts, change impact and runtime evidence;
• the drawer lifecycle from base revision through draft, compile, findings, tests, evidence and approval;
• Discard draft and Review plan rather than a generic immediate Apply action.

Pr3Pv is now Map · Semantic Depth × Density and makes L0 Product, L1 Island, L2 Scope, L3 Component and L4 Evidence explicit. It documents that depth and density are orthogonal and that identity, selection and context survive the transition.

aPU6J is now Map · Semantic Graph Editor & Compiler. Its copy separates view commands from semantic patches, defines contracts through label/shape/glyph/color rather than color alone, and shows the truthful lifecycle Patch → Compile → Plan → Authorize → Run → Verify → Receipt. It explicitly states that agents use an authenticated read plane and a separate proposal/mutation broker; it no longer advertises push_command on the current unauthenticated local read MCP.

Measured result

The following seven roots were re-read from the canonical Pencil document after the changes:

This checkpoint does not waive Graph G0–G7. In particular, the shipping document editor remains view-only; semantic mutation, compiler, breakpoint/replay, persistence, agent write, and production operation claims remain gated by executable tests and external field proof.

Appendix H — System Fabric and Data Studio checkpoint

This wave extends §8, §12 and §15 so the full graph includes the actual operating substrate: databases, actor state, object storage, Workers, servers, Kubernetes, Pub/Sub/Queues, provider bindings, delivery, telemetry and cost. It is a design and implementation plan, not a claim that the current Desktop has live provider access.

Verified starting point

The existing substrate is valuable but split:

• reaktor-cloud has provider/tool interfaces, fingerprint-bound Dagger/Pulumi runners and a flat CloudResource; its Wrangler provider is source-only and covers only a subset of configured resources.
• BestBuds has a richer Wrangler/k3s/database operational catalog and safe bounded Postgres/D1/Memgraph/ClickHouse probe operations, but results remain run logs and resources remain flat product DTOs.
• reaktor-cloudflare has real Worker-side D1, Durable Object, Postgres/Hyperdrive, ClickHouse, R2 and binding adapters. They are data-plane wrappers, not account inventory or management-plane inspectors.
• reaktor-google has real Pub/Sub ensure/publish/pull/ack adapters; it lacks a provider resource/backlog/schema/DLQ inspector.
• reaktor-db has a useful local ObjectDatabase and Memgraph/Neo4j adapter. ObjectDatabase is a local state primitive—not a universal database abstraction—and its underlying concurrent map must be fixed before control-plane scale.
• the Desktop Cloud/Database panes are honest source/operation projections in JVM code, while some older rich screens and Pencil values are fixtures. There is no unified live resource registry, query plane or desired/recorded/observed reconciliation.

The plan therefore introduces one System Fabric projection over the canonical GraphSnapshot, provider-neutral resource/data/message facets, provider-native inspectors, a bounded multi-engine query contract and one governed operation kernel. It explicitly avoids building a second graph or forcing every store to pretend to be SQL.

Immediate stop-ship findings captured by Gate 0

The audit found concrete issues which must be fixed before any agent or Desktop query/control-plane write ships:

Seven concrete findings are enumerated in the private security review — credential rotation and artifact purge, read-path privilege separation, health-endpoint truthfulness, push-route authentication, service-credential scoping, backup/restore transactionality, and single-replica datastore recovery. They are summarized here because they describe live systems; each becomes a rendered in-product finding with a verification run before any query or control-plane write ships.

These are not reasons to hide System Fabric. They are exactly the risks it must render and govern. Until remediated, the Pencil and product show Source, Fixture, Unknown or Blocked—not Live, Healthy or Rollback Proven.

Reusable Pencil primitives added

Four reusable Machine Signal components now express the System Fabric grammar:

• Fabric / Context Ribbon (y8Bfv) — workspace/scope plus independent Desired, Recorded and Observed planes, coverage and findings.
• Data / Query Safety Bar (SPhvM) — engine/entity, environment/tenant/authority, truth, enforced query budget and an explicit read action.
• Fabric / Entity Row (LeFNf) — provider-native identity, kind, desired/observed/drift, relationships and available capabilities.
• Fabric / Event Path (B6eZm) — publisher → topic/queue → subscription → consumer → store with contract, delivery and observation truth.

They use Machine Signal 2.0 theme tokens and the new ms2-on-accent role, preserve text labels in addition to color, and expose at least a 40 px effective action/row target. Components are reused in reference screens rather than copied decorations.

Reference frames updated

The current screens still carry legacy dense typography outside the new primitives; they are reference contracts, not a waiver of the broader Machine Signal migration. The next visual cohort must use the same components at Expanded/Medium/Compact widths and dark/light/high-contrast themes, with Map/Outline/Table parity and complete loading/empty/stale/partial/offline/denied/failed states.

Explicitly not implemented yet

• no canonical System Fabric model or provider-neutral observed-resource registry exists in source;
• no live Cloudflare/Kubernetes/GCP/database management-plane adapters feed Desktop;
• no safe general multi-engine query service exists;
• Durable Object instance storage remains inspectable only through an explicit app-specific read contract;
• successful operational probes do not yet publish typed evidence deltas into the resource graph;
• Desktop selection is still mode-local, the global inspector is not resource-selection driven, compact rail/inspector strips are not real overlays, and the drawer's Network tab is not a network view;
• cloud/data/agent mutation remains blocked until Gate 0–4 evidence passes.

The decisive product proof is Proof D: one external non-production fabric must traverse source → provider observation → Worker/message/server → authority/projections, execute bounded reads across different engines, detect drift, apply one reversible approved change, reconcile it and reopen the complete receipt with identical semantic identities.

28. Final product bar

Reaktor is ready to call revolutionary only when all of the following are simultaneously true:

1. A stranger opens a real, non-Reaktor system and obtains an honest useful map and trace in minutes.
2. The same semantic identity connects source, graph, runtime, data, identity, AI, cloud, tests, telemetry, analytics, releases, operations, and history.
3. A human and an agent can propose the same typed change and receive the same compiler findings, plan, permissions, and evidence.
4. The graph can author and materialize at least one real system workflow; it is not merely a viewer.
5. Every mutation is scoped, explainable, authorized, fingerprint-bound, isolated, observable, auditable, and recoverable.
6. Specialist tools feel connected rather than displaced; context crosses boundaries without copy/paste archaeology.
7. The interface is fast, accessible, calm, and legible from a laptop to a command display despite its depth.
8. Desired, observed, inferred, stale, fixture, unknown, and conflicting facts can never masquerade as each other.
9. The packaged artifact is the product described by source and Pencil, reproducibly signed and safely updateable.
10. External teams use it repeatedly on systems the founder did not build and can prove that it lets them understand, change, and operate those systems faster and more safely.

Until then, preserve the ambition but describe the product honestly. The spirit of Reaktor is not maximal surface area. It is the conviction that complexity becomes tractable when the system is explicit, every tool plays from the same score, every action is governed, and every result returns as evidence.

The build score's closing, kept alongside the constitution's:

Build score appendix C — what this plan deliberately does not do

No new modes. No movement-first reorganization before the context spine exists (D2). No collaboration/multi-user features before single-user persistence is proven. No polyglot/marketplace/mega-scale claims — those remain behind the constitution's Gates 6–7. This file and the Revolution Plan remain the private working sources; the combined public edition ships at /docs/reaktor-desktop-master-plan with live-security specifics summarized rather than enumerated (full detail stays in the private reviews). And no line of it overrides the running code: where this document and reality disagree once building starts, reality wins and this document gets updated — the same rule the constitution set for itself.

The spirit check, last: every decision above was tested against the bar in AGENTS.md §2 — expressivity and composability over simplicity, simplicity over surface. The symphony is not a feature list; it is one context, one truth model, one action path, and one evidence plane, played through twelve instruments that were already built with love. Wire them together and the tool everyone opens is the one that already refuses to lie.