Reaktor UI/UX Audit — 8 September 2026

Current status: Reaktor now has working local developer flows, but the full BestBuds development loop is still incomplete. The native app can load the BestBuds workspace, inspect the mounted application graph and its source declarations, render the live Compose preview, discover devices, execute reviewed device commands, query local SQLite, browse Memgraph through registered reads, read live schema and statistics, inspect declared worker/storage/Kubernetes relationships, read the configured Kubernetes cluster, and expose workspace facts through MCP. Auth now has directories for principals, memberships, sessions, refresh tokens, PATs, service accounts, grants and issuance/audit events. Remote reads require a configured connection with suitable authority; a directory UI alone does not establish that the deployed identity plane has been inspected.

Graph, auth, database, DevTools, compute/cloud and MCP are all top priority. This supersedes the earlier instruction in this document to defer cloud and agent tools until the four original pillars were finished. The acceptance criterion is a completed developer workflow against BestBuds, including useful results and a retained operation reference. A mounted pane, a configuration count, a screenshot or a compiled button is insufficient.

This is a living implementation ledger. Earlier captures, measurements and assessments are retained as historical evidence. In particular, the initial finding that twelve modes rendered pictures was repaired in F24–F27; it is not the state of the current window. The new developer workflow pass records the subsequent feature builds and remaining load-bearing gaps. The Living Graph atlas and north star remain design references.

Distance from the full design and vision

Graph architecture proposal — updated 9 September: Data-oriented Substrate and Typed Maps specifies the pure-data kernel, capabilities, maps, traversal/visitors, services/FFI, async channels, distributed ownership, portable Kotlin logic, modification protocol and verification/migration gates. Its complete ecosystem integration contract now maps all 34 framework module/build directories, 13 desktop modes and 74 authored subpanes to owned definitions, hooks, observations, maps, operations and presentation. It includes shared Workbench context, integration release gates, HLD diagrams, a compiled Kotlin contract specimen and a downloadable source inventory. This is design progress; the proposed runtime and operational flows are not recorded as implemented fixes. The seven-journey readiness assessment below remains unchanged by publication of the proposal.

Current readiness: a useful inspection alpha, with substantial operational work remaining. None of the seven broad end-to-end journeys in the current P0 queue has met its complete acceptance bar yet; all seven have working parts and blocking gaps. This is a workflow count, not a feature-completion percentage. Passing tests, mounted tabs and authored boards do not measure how much of the product vision has shipped.

The desktop can already save time finding source, exploring the client graph, inspecting local SQL and bounded Memgraph results, reading Kubernetes state, and giving an agent the same local workspace facts. The available evidence does not establish support for the complete BestBuds change → reproduce → diagnose → fix → test → deploy → verify loop, or measured a developer shipping-speed improvement. It does not yet replace DataGrip, Chrome DevTools or the existing deployment/observability tools.

The remaining distance is several major integrations and complete operational workflows, followed by qualification across real providers, devices and display configurations. It is not just a visual-polish backlog. A calendar estimate would require estimating and validating the open provider/operation contracts; this audit does not invent one.

The delivery gates are:

1. Connect the real system. Qualify the configured BestBuds remote databases and auth inspector, attach physical/simulated devices and observed worker runtimes, and preserve stable identities across panes.
2. Complete everyday operations. Review, execute and reconcile database edits/migrations, identity changes/revocation, app installation and cloud deployment against explicit targets, retaining results and operation references.
3. Close the developer and agent loop. Carry an observed failure through trace, graph, source, reproduction, test, change and verified deployment; expose the same references and governed actions through MCP and agent sessions.
4. Qualify the experience. Prove adaptive behavior, accessible input, failure/recovery states, large-graph performance and physical-device workflows. Close the remaining authored interaction contracts, including testing, telemetry and agent surfaces.

These gates describe completion criteria, not a reason to postpone usability repairs. The viewport-orientation correction below is one concrete graph repair; it does not close the broader graph journey.

Scope and evidence

The audit covers the complete source catalog structurally and representative native workspaces visually and behaviorally. It does not establish that every possible interaction, display configuration or future provider attachment is bug-free.

The native captures use logical pixels, density 1 and font scale 1. A browser displaying a 3360-pixel image at a smaller width makes its text look smaller; that is not evidence that the native app changed its font size.

Evidence is preserved locally under reaktor-context/compose-parity/ui-consistency-2026-09-07/. The source snapshot contains resolved specifications, exact icon exports, PNG references and SHA-256 hashes. The native rendering tests additionally write modules/engine/build/reports/studio-responsive-review/ and studio-host-parity/. Screenshots reproduced below are authored examples, not live provider observations.

Status

• Fixed / verified: implemented in a repair pass and covered by the stated evidence.
• Open / observed: directly visible in a capture or established by the reviewed implementation.
• Integration gap: the surface exists, but its intended operation is not attached.
• Qualification gap: more testing is required; this is not a claim that an untested feature is broken.

Priority

The historical bands below organize issue families. The current P0 workflow queue takes precedence across bands; an unavailable database, device or compute flow must not wait for graph polish.

Band is the product order. It decides what is worked on:

Severity decides the order inside a band:

• S0 — not usable. The surface cannot do its job at all: the operation is absent, or what is shown is a picture of the operation.
• S1 — blocks the task. The surface works but a normal workflow cannot be completed, or a decision is made on information that is wrong or hidden.
• S2 — friction. Repeated cost, weak discoverability, avoidable confusion.
• S3 — polish.

Severity expresses consequence, not an assertion that a dangerous operation currently executes. The complete ranking is in Order of work; the older P0–P3 labels on individual issues are kept so links and history still resolve, but the band-and-severity queue is what sequences the work.

Decision order

1. Keep the current native implementation, repaired source constraints and real graph.
2. Mount the panes. Route every mode to a tool instead of a board, on one application identity and one shell. Until this is done, work in bands 1–4 lands in code the window never shows.
3. Make the graph usable at every scale and window size, then attach its instruments to the live session.
4. Make the database surface a database tool: connections, an editor, results, schema.
5. Make auth an inspector over real principals and policy, with an honest simulation boundary.
6. Build the device-tools surface Reaktor is missing — console, network, elements — rather than renaming the build surface.
7. In the same P0 delivery sequence: compute topology and operations, MCP parity, delivery and observation through shared commands and receipts. AI and reference-library polish follow working developer flows.

Do not optimize this into fewer features. Reaktor needs more power with better organization: progressive detail, docked tools, contextual actions, inspectable state and reversible navigation.

Developer workflow pass · 8 September

This pass inspected the running packaged macOS application with the BestBuds workspace, alongside reaktor.pen (including FsQx4, LODux, yawya, T51iyD and GaN4a), the module code, SQL, Wrangler configurations, Kubernetes manifests and developer documentation. All thirteen primary modes were opened in the native application: Graph, UI preview, DevTools, Database, Auth, Cloud, Deploy, Testing, Telemetry, Analytics, Agent, AI and UI. This is primary-mode coverage, not a claim that every subpane or provider operation was exercised.

Operational and adaptive follow-through — 8 September

These are additional implementation changes, not a declaration that every atlas interaction is complete.

The complete-output repair is part of the operational acceptance bar: a command exiting successfully is insufficient if the UI receives only a truncated suffix of its response. The Kubernetes integration test goes through the actual Desktop control plane, supervised process, retained receipt, parser and rendered inspector, with an explicit live-read opt-in.

Verification ledger for F47–F54: the full :engine:jvmTest suite ran 282 tests, zero failures, one skipped, including the real configured-cluster integration and the rendered graph disclosure/reveal regression. Shared suites passed: reaktor-flow 49, reaktor-tooling 19, and reaktor-ui 7 tests. The full :reaktorDesktop:test run passed all 37 tests, including physical port selection and all three reference-window input/focus checks. The native input harness now binds Robot to the test window’s graphics device and measures its port after foreground layout settles; it still sends actual OS pointer events and asserts the exact port inspector. No native assertion was disabled or replaced with semantic clicking. The additional three adaptive tests passed after adding smallest-element hit testing in the device bounds viewport.

Verification ledger for F55: the subsequent full :engine:jvmTest run passed 284 tests, zero failures, one skipped, with both live Kubernetes and Memgraph reads enabled. The shared reaktor-db suite passed all 32 tests. desktopMcpE2e passed against its actual loopback server and createDistributable rebuilt the packaged app. All six Memgraph catalog reads returned real column/row results through DatabaseStudioSession; the ten-row test limit correctly reported truncation for properties, nodes, relationships and relationship types. The separate broker regression executes each catalog template and rejects injected/unregistered text before invoking the console. The packaged app then read ten labels, 100 nodes on page one, 100 nodes on page two, and 100 relationships after switching record kind, resetting to page one. Every native read had a successful operation receipt. The repaired health probe also succeeded and changed the Memgraph connection to connected. Native 37-test qualification above preceded F55; these additional Memgraph flows were verified manually in the rebuilt app.

Verification ledger through F56 (before the orientation correction): :engine:jvmTest passed 287 tests, zero failures, one skipped; :reaktorDesktop:test passed all 37 tests; shared reaktor-db passed 34 and reaktor-flow 50 tests. Both live-read opt-ins were enabled. The real returned Memgraph node and relationship rows also passed the new typed page parser. MCP loopback E2E and packaging succeeded. New rendered pointer regressions preserve exact endpoint identity through selection, relationship inspection and local neighbor focus at laptop and ultrawide sizes. The projection benchmark and flame frames are written to modules/engine/build/reports/memgraph-results/performance.json; its 100/500-relationship input is an explicitly generated fixture, not production traffic or an FPS claim.

Native Memgraph graph review: the packaged application executed the production-target registered relationship read and drew 105 endpoint identities / 100 returned relationships. Selecting Node #15 and focusing its returned neighbors produced 2 nodes / 1 relationship. The HAS_RESOURCE relationship inspector identified source Node #1 and target Node #15 and exposed its returned properties. Target navigation selected Node #15; restoring the page returned to 105/100; clicking the Node #1 card directly on the native canvas opened its exact inspector. No additional database query was issued by those local navigation actions. The subsequent offscreen-selection regression checks that selecting a different component reveals it. The paging controls now disable Next at the supported bound and validate a destination before changing page state.

desktopMcpE2e passed against the actual loopback server, and createDistributable rebuilt Reaktor.app. Native computer control exercised Compute → Kubernetes → Read cluster (21 objects) → server pod → events → 300 log lines, with successful operation receipts. Database executed a local SQLite query in the new side-by-side layout, returned two schema rows and retained them after window restoration. The native graph changed between 48 cards/66 relations and 29/29 on Chat expansion/collapse, and a consumer port opened its exact inspector. That manual pass caught and fixed scope disclosure replacing the selected subject; the new rendered regression verifies retention and targeted Reveal.

Adaptive rendering and splitter input are exercised at 1512 and 2560 logical pixels; responsive helpers also cover 390 and 768. Native wide-window inspection is additional evidence, not exhaustive qualification of every MacBook/Dell resolution, scale or window arrangement. The pre-F57 graph projection report covered 900/1600/2400/3200-pixel canvas widths: median overview projection was 0.1–0.2 ms and fully expanded projection 0.5–0.8 ms in that run (worst sample 3.3 ms). The viewport-orientation pass below replaces width-only input with width and height. This measures projection work only, not display frame rate. Physical mobile-device qualification and the P0 operations below remain open.

Current P0 workflow queue

Native review defects still open: Agent Chat has no session transport. AI Models shows binding inventory under authored model/prompt headings, and its "retrieved context" can contain unrelated operation runs. The UI mode is a component catalog. Testing has runnable gates but does not yet parse their reports into a useful result tree. These are functional integration gaps; they must not be counted as delivered workflows because the tabs render.

Earlier verification ledger (before F47–F54): :engine:jvmTest ran 274 tests, zero failures, one skipped. Shared suites passed: reaktor-flow 47, reaktor-tooling 11, and reaktor-auth 67 tests. The full desktop suite ran 37 tests: 33 passed and four native-focus tests failed. Their diagnostics show no focused window; the computer-control tool independently reported that the Mac had locked at the verification snapshot. The three reference-window focus/close tests and the physical graph-port click test remain an explicit qualification gate. They were not disabled or changed to bypass native input.

The new DesktopFeatureFlowsTest passed through the real Compose shell: source topology → search messaging-service → select worker → focus dependencies → Agent/MCP → discover this process → execute system_topology. desktopMcpE2e also passed against the actual loopback HTTP server, covering the nine-tool registry, resources, arguments, environment selection and source/device read contracts. createDistributable produced the rebuilt Reaktor.app. All thirteen primary modes had been opened in the packaged app earlier in the pass, including live local SQLite query/schema/statistics and explicit adb/simctl discovery. This earlier native-focus failure is superseded by the follow-through verification record above.

These screenshots come from the desktop integration harness with its explicitly labelled E2E operation catalog, the actual BestBuds repository topology, and the real loopback MCP server. They show the implemented Compose flows, not a live deployment observation or Pencil raster-parity result.

Viewport-orientation correction · 8 September

Latest verification ledger — F57: the full :engine:jvmTest run passed 288 tests, zero failures, one skipped, with both live Kubernetes and Memgraph read opt-ins enabled. Shared reaktor-flow passed 53 tests, and :reaktorDesktop:test passed all 37 tests, including actual OS port input. desktopMcpE2e passed on its loopback server and createDistributable rebuilt the native app. The first full run exposed a preview test reading the previous status before Compose applied its state update; explicitly delivering snapshot notifications and advancing the existing frame clock fixed the harness, with the same runtime-status and viewport-identity assertions retained. The complete rerun passed.

The current directional projection benchmark measured overview medians of 0.1–0.2 ms and fully expanded medians of 0.8–0.9 ms across portrait, laptop and ultrawide canvas dimensions; the worst expanded sample was 4.9 ms. These measurements include projection and flame-frame reporting, not native FPS or a large-production-graph performance qualification.

F57 fixes the mounted application graph, not only the Compute or Memgraph result layouts. F34 passed canvas width into the typed strategy but still wrapped expanded scopes underneath their parents. The shell now measures the actual canvas width and height, and the shared flow layer places descendants along its longer axis. Changing panes, navigator/inspector sizes or window orientation triggers a new projection; graph identities and the inspected subject remain stable.

The following focused-run measurements are graph-coordinate bounds from the real BestBuds runtime projection at density 1, not screenshot dimensions or promises that every card fits on screen. Fully expanded includes all 172 cards. Dense layouts deliberately grow on both axes; their dominant direction follows the canvas. The width-only F34 measurements below are retained as history.

The shared tests also relocate an expanded child containing a nested expanded region and a folded descendant, checking the whole subtree remains contained and non-overlapping. The rendered workspace tests obtain dimensions through the real canvas measurement callback and exercise fold → hidden selected port → targeted reveal at laptop, portrait and ultrawide sizes. Their captures are under modules/engine/build/reports/graph-orientation/; the projection benchmark and flame frames are under modules/engine/build/reports/graph-navigation/performance.json. Projection timings are directional CPU measurements, not native display FPS.

Native follow-through: the rebuilt packaged application was resized from the wide desktop to a tall graph canvas and back. Chat collapsed from 48 nodes / 66 edges to 29 / 29, then expanded back to 48 / 66 in both orientations. Frame all showed descendants below in portrait and to the right in landscape; the OnboardingScreen inspector stayed selected through resize and disclosure. This is a concrete native window check, not exhaustive display qualification.

The following capture is the actual rendered graph workspace with BestBuds and Chat expanded. The portrait capture and ultrawide capture show the same selected port and scope state. These are native Compose test renders, not observations of a remote runtime or proof of whole-Pencil parity.

Schema and layout pass · 8 September

Historical F34 measurements (width-only layout, superseded by the viewport-orientation correction): these show the earlier improvement over fixed columns, and also the remaining vertical-expansion defect. They are not current orientation-qualified results:

F34 used width alone and continued wrapping expanded scopes underneath one another, even in landscape. The follow-up uses both dimensions of the actual graph canvas and places expanded descendants along its longer axis. Dense graphs may grow on both axes; landscape expansion must remain horizontally dominant and portrait expansion vertically dominant.

Compute topology pass · 8 September

The reader found C04 on its first run: the deploy order the repository documents contradicts the order its own service bindings require.

Pane anatomy pass · 8 September

Mounting the panes exposed the next problem: the panes were generic resource lists, and the design file specifies something much more particular. This pass reads reaktor.pen and builds what it actually draws.

Honesty about F29 and F30. Neither pane invents data. Where a provider is not attached the pane says UNKNOWN and names what is missing — a backup adapter, a catalog read, an EXPLAIN adapter, a live heimdall connection — which is what the boards themselves do. That pass labelled the plan inferred from the statement. F40 replaces the active Query Plan surface with a real EXPLAIN result; it does not claim measured execution cost.

Pane routing pass · 8 September

Selection now belongs to a mode rather than to a composition: leaving Develop for the graph and coming back returns to the subpane and row you left.

Does this help a BestBuds developer ship?

Historical baseline, before F36–F46. The current answer and remaining gates are in the developer workflow pass above. The initial answer was: on one requirement, yes. On the load-bearing ones, no. This section is the 8 September re-read of the four pillars against the application they exist for, because the passes before it improved how the panes look without asking whether a developer could use them.

What BestBuds actually is

339,000 lines of Kotlin in modules/, 42,000 lines of TypeScript in targets/, 26 targets of which 25 are Cloudflare workers, 275 npm scripts, fastlane for both mobile stores, Maestro and Playwright end-to-end suites, a k3s JVM server, and three declared shared stores — Postgres, Memgraph, ClickHouse — beside per-worker D1, Durable Objects and R2.

What a developer does in a day

Taken from the repo's own guide (AGENTS.md §8–9) and its scripts, not invented:

What the desktop does with them

Three structural reasons, not twelve small ones

1. There are two unrelated models of BestBuds. The graph knows 48 client nodes. The operational catalog knows 481 tasks and 253 resources. The overlay that claims to join them mints its own identifiers — task:, resource:, provider:, target:, run: — and attaches all 814 of them to the root scope, never to a node. So no node knows the command that builds it, the worker that serves it, the store it reads or the run that last touched it. Every question a developer actually asks crosses that gap.

2. There is no source plane. The graph inspector's Source tab prints a fully-qualified class name. Nothing in the workbench opens a file, shows a line, renders a diff, or reveals a symbol. In a 339k-line codebase, a tool that can point at a component but not at its code cannot participate in a change.

3. There is no observation plane. There is no log stream, no wrangler tail, no trace, no attach to a running target. Of the 18 database connections the Data pane discovers, one can be read — the desktop's own SQLite. The other seventeen, including all three declared shared stores, report disconnected or broker required. Auth can read declarations and simulate against them; it has never observed an enforcement.

The honest verdict

A BestBuds developer today would open the desktop to run a gated command and read its receipt, and to look at the client app's graph. Everything else in their day happens in IntelliJ, a terminal, wrangler, Supabase Studio and Grafana. The tool does not yet make them ship faster, because it does not touch the loop where their time goes: change → gate → observe → deploy.

The four pillars are not short of features. They are short of one join, one source plane and one live connection — and every pane gets more valuable the moment those exist, including the ones this document has already spent two passes polishing.

What would change the answer

In the owner's priority order, and each stated as the smallest thing that makes the pillar load-bearing:

1. Graph — join the two models. A graph node resolves to its target, its worker, its store, its commands and its last run. This is not a rendering change; it is a correlation key. It makes the graph the system rather than one target of it, and it is the precondition for the other three.
2. Database — one real connection. Reach Postgres, Memgraph and ClickHouse the way the workers already do, through the reaktorServer /_graph gateway and the Cloudflare VPC bindings that are already proven from an edge worker. One live read against the three declared stores is worth more than seven authored subpanes.
3. Auth — one observed decision. Capture one real AuthDecision from a running worker and show it beside the simulated one. The simulator is already real; what it lacks is something observed to disagree with.
4. Device tools — logs from something running. A log stream from one target and one deployed worker, attributed to a graph node. This is the first thing anyone opens when something breaks, and Reaktor has none.
5. Cloud — deploy what changed, in order. Read the changed workers the way deploy.sh does, apply the documented binding order, and produce one receipt for the set. This is a day-to-day, high-consequence action the tool is already 80 % of the way to owning.

None of these is a pane. Each is a plane the panes then draw.

The capability inventory

Historical inventory from F32–F35. F36–F46 above supersede the state column where a capability has since been implemented. This section remains as the before-state and source context.

The assessment above says the pillars are short of three planes. This section names the capabilities each pillar owes a BestBuds developer, one row at a time, and says which are built. It is the working list for bands 1–4.

Source-derived implementation: the compute topology. Every fact in it is declared in a file already checked in — 21 wrangler configurations and the k3s manifests — so it needs no credential, no network and no adapter, and it is labelled as source truth about the deployed shape rather than an observation of it.

Compute

Data

Auth

The schema is real and checked in: identity, provider_account, principal, tenant, membership, principal_role, auth_provider_client, refresh_token, service_account, signing_key, plus the preserved role, permission, role_permissions, session and personal_access_token.

Device tools

C04 — The documented deploy order contradicts the service bindings · S0 · Observed

AGENTS.md §9 requires text-moderator-service → image-moderator-service → chat-service → messaging-service → media-service → campaign-engagement-service when bindings change. The configurations say text-moderator-service and image-moderator-service each bind chat-service, and a service binding must resolve at deploy time, so chat-service has to exist before either. The computed order is chat-service → image-moderator-service → text-moderator-service → media-service → messaging-service → campaign-engagement-service.

One of the two is wrong, and both are load-bearing for a production deploy. The workbench now shows them side by side and says which constraint it derived; a developer decides which is right. This is the first defect the tool has found in the repository rather than in itself.

The four pillars at the initial audit

This section is the 8 September discovery pass over the four surfaces the owner ranked. It reads the running window, not the boards: WorkbenchShellRenderTest renders ReaktorWorkbenchContent — the same composable the desktop window mounts — for eight modes at the authored 1600 × 1000, and for the four pillars at 1024 × 720 and 3360 × 1418. Sheets are in modules/engine/build/reports/machinesignal-shell/; the per-subpane sheets are in machinesignal-panes/.

The window · Band 0

W01 — Only Graph opened a tool; twelve modes opened a picture · S0 · Fixed / verified (F24)

Was: Workbench.kt branched once. If the destination was the application graph it composed the real editor; otherwise it composed ReaktorDesignWorkspace(boardId = …) at fillMaxSize(), and that authored board painted its own menu bar, toolbar, tabs, left panel, tool strip and status bar. Data, Auth, Develop, Cloud, Agent, Telemetry, Analytics, AI, Testing, Deploy, UI and UI preview all took that second branch, so in eleven of thirteen modes every control the user could see was a drawing.

Now: a mode navigates to ReaktorWorkspaceDestination.ModePane, which composes the shell around the mode's pane. The authored board is reached from the surface chooser and keeps its full-bleed reference view, which is what it is for.

W02 — The domain panes were implemented, tested, and unreachable · S0 · Fixed / verified (F25)

workbench/render/compose/panes/ is 9,075 lines across 34 files. Exactly five of its composables are referenced anywhere outside that package: ReaktorCommandPalette, ReaktorWorkbenchBottomDrawer, ReaktorEditorDrawerStrip, ReaktorInspectionComposerProbe and one table helper. DatabaseStudioPane, ReaktorAuthWorkspace, AuthPane, DatabasePane, DevToolsOperationsPane, CloudPane, TelemetryPane, AnalyticsPane, AgentPane, TestingPane, DeployPane, AiPane, UiPane, DomainNavigator, AuthoredSubpane and the whole subpane layer have zero callers outside the package.

This changes how one existing number should be read. MachineSignalPaneCoverageTest reports 31 of 74 subpanes render real data — database 7/7, devtools 9/9, cloud 4/6, agent 4/9, auth 3/6, telemetry 2/9, analytics 2/8, ui 0/8, ai 0/12. That is true of the implementations and false of the product: the window never mounts them, so no user has ever reached a single one.

Now: eleven of the twelve non-graph modes mount their pane. Data opens a connection inventory that discovers 18 connections across Postgres/Supabase, ClickHouse, Memgraph, Cloudflare D1, Durable Objects and local stores, each with its environment and state, beside a query document with Test and Run read and a result panel that says Run a read to view results instead of showing a fixture. Auth opens an inspector bound to the current graph selection that reports exactly what is missing — no context provider, no secured ports declared, no AuthPolicyNode in scope. Develop opens its nine subpanes over real run history and runnable tasks. UI preview had no pane at F25; F39 subsequently mounts the live graph application.

Still open: the coverage gate still counts implementations rather than reachable subpanes, and the 43 pending subpanes are still pending. Acceptance: the gate fails when a subpane counted as wired is not reachable from the window in at most two interactions.

W03 — The window disagreed about which application is open · S0 · Fixed / verified (F26)

Across eight rendered modes the title bar reads three different applications: bestbuds — BestBuds (Graph), BestBuds — media messaging (Cloud), Fieldwork — site-capture (Data, Auth, Develop, Agent, Telemetry, AI). The project chip, the branch chip (wo…, truncated from the real workbench-foundation, versus a fixture main), the target chip (All · Local / All targets / Web · Local / System targets) and the perspective chip (Develop / Compose) change with it.

Switching mode therefore switched project, branch, target and perspective, and no selection, revision or environment could survive it.

Now: the shell owns the header in every mounted mode, so the application, branch, target and perspective are the live ones everywhere. The authored reference view still carries its own fixture identity, which is correct for a design board and is what N05 and CO21 remain about.

W04 — Two tool strips, and two counts that count something else · S1 · Partly repaired (F24) · Open

Repaired by F24: every mounted mode now shows the live drawer — Runs · Logs · Traces · Network · Tests · Build · Diagnostics, with counts from the operational snapshot. The drawn strip Terminal · Problems · Build · Debug · Tests · Profiler · Conductor now appears only on an authored reference board, where a drawing is what it should be.

Still open: BottomDrawerTab declares Command Queue, Code Agent and CodeDiff, which never render and whose last name is not a label; and the drawer still has no active-tab state.

Two of the live counts do not count what their name says: Network counts cloud-domain resources, and Traces counts resources tagged traces. There is no network panel behind either.

Required fix: one tool strip, defined once, with counts whose source matches the name. Acceptance: the strip is identical in every mode, has an active tab, and every count links to the collection it counted.

W05 — The left panel is named four ways · S1 · Observed

Before F24 the running product showed APPLICATION EXPLORER (Graph, ~280 px), Project (Auth, Develop, Agent, Telemetry, AI, ~224 px), System explorer with a Features ▾ selector (Cloud) and, in Data, no panel at all. Mounting the panes did not fix this and was not expected to: each pane brings its own navigator and its own header grammar — Data bestbuds / local, Auth local · OnboardingScreen, BESTBUDS / DEVTOOLS / PREVIEW. The shell's explorer now exists only in Graph.

Required fix: one navigator and one header contract in the shell, which the pane fills. This is CO14 as a live product defect and is the next thing standing between the four pillars and looking like one tool.

W06 — The design file and the app disagree about what the modes are · S1 · Observed

reaktor.pen authors ten mode tabs: Graph (no shortcut, no icon), UI ⌘2, DevTools ⌘3, Analytics ⌘4, Telemetry ⌘5, AI ⌘6, Agent ⌘7, Database ⌘8, Auth ⌘9, Cloud ⌘0. The app ships thirteen: Graph 1, UI preview (none), Develop 2, Agent 3, UI 4, Data 5, Auth 6, AI 7, Testing 8, Deploy 9, Cloud ⇧C, Telemetry 0, Analytics ⇧A.

Two labels differ (DevTools/Develop, Database/Data), three modes exist only in the app, and not one shortcut agrees. MachineSignalPaneCoverageTest.everyAuthoredModeTabHasAWorkbenchMode has been failing on exactly this. The design file also carries two contradictory subpane sets for the single Cloud tab, which its own notes record as unresolved.

Required fix: one mode list and one keymap, authored once and read by both. Acceptance: the coverage test passes without an exception list, and a shortcut printed in the design file works in the app.

W07 — The live shell has no compact-layout contract · S1 · Observed

F22 and F23 gave the authored boards a content floor and a visible overflow. The live shell got neither. At 1024 × 720 the graph canvas is about 380 px wide between a fixed 280 px explorer and a fixed 320 px inspector, and renders the map at 17 %; the C4 preset row (Detail · System · Container · Component · Code · Everything · Neighbors · Reset layers) clips after Co…; the drawer strip clips after Build; neither offers an overflow menu. At 3360 × 1418 the two panels stay fixed and the extra 1,700 px becomes empty canvas.

Acceptance: the resize matrix in V05 covers the live shell, not only the boards.

W08 — One gesture, two meanings · S2 · Fixed / verified (F27)

Was: ⌘K opened the command palette in Graph and the surface chooser everywhere else. Now: search is the command palette everywhere; the surface chooser is its own action in the Window menu. The wider scoping work is still N06.

X01 — The subpanes are skeletons, measured · S1 · Measured

Across the 74 rendered subpane sheets, the last painted row sits at or above half the pane height in 64 of 74; the median subpane stops at 30 % of its height. Most of the painted area is empty section frames — a Rows band containing —, a Detail band containing one truncated sentence. Parity with the authored anatomy was the goal of the August passes and it was reached; content was not part of it. This is the honest baseline for bands 1–4.

Graph · Band 1

The one pillar that is a real tool. Its defects are therefore about legibility, scale and identity rather than existence.

GR01 — No semantic zoom, so the map is unreadable at every useful scale · S0 · Observed

Node cards paint their full port list at every zoom. At 1600 × 1000 the graph sits at 38 % and the card bodies are grey texture; at 1024 × 720 it sits at 17 %; at 3360 × 1418 it reaches 61 % and is still small, because the layout is wider than any window. There is no scale at which a user can both see the system and read it.

Required fix: a render contract per zoom band — what folds, what expands, the label budget — as CO13 already demands for the design file, applied to the live canvas. Acceptance: at every band the visible labels are legible at normal viewing distance, and the band is named in the UI.

GR02 — The layout is a fixed grid, and it is not saved · S0 · Observed

Nodes are placed on a uniform grid with scope bands; the panel states Dragging changes layout only. There is no saved position, no layout document and no persistence anywhere in the graph workspace. A user cannot arrange the map they work in, and the arrangement they are given carries no meaning.

Required fix: a real layout — hierarchical or force-directed, with pinning — persisted per graph and per user. Acceptance: move a node, switch mode, come back; the node is where it was left, and the position is part of a document that can be shared and reviewed.

GR03 — One window, five disagreeing counts · S1 · Observed

The explorer lists Graph 172. The topology bar says 48/48 nodes · 66/66 relations · 17 scopes. VISIBLE NODES · 48. SOURCE + CONTEXT says 48 cards · 66 relations. The status bar says local · 481 tasks · 253 resources. The layer Resources / operations is unchecked and reads 814, with no statement of what turning it on would add or why it is off. This is CO12 in the live product.

GR04 — The inspector tab row is clipped at every window size · S1 · Observed

Inspect · Ports · Source · Runtime · Telemetry · A… — the sixth tab is cut at 1024, at 1600 and at 3360, because the inspector is a fixed 320 px carrying six tabs. A tab the user can never see is a feature the user never finds.

GR05 — No selection or authoring gestures · S1 · Observed

The graph workspace has no marquee, no multi-select, no alignment, no drag-from-pin wiring and no undo of a graph edit. L8el1 in the design file is the only Blueprint-grade gesture specification in the project and nothing renders it. Related: G07, CO23.

GR06 — The graph toolbar mixes four kinds of control in one row · S2 · Observed

Filter symbols and ports… (a filter), Frame all – 38 % + (a camera), Detail (a bare label), System · Container · Component · Code (C4 presets), Everything · Neighbors (a scope mode drawn as two buttons), Reset layers (an action on a different panel). Nothing groups or separates them, and Neighbors shows selected state that the presets do not.

GR07 — The graph is not a document like everything else · S2 · Observed

The document strip shows a Graph tab and immediately below it a second Graph title. The tab has no close affordance, cannot be pinned or reordered, and there is only ever one. Related: N03.

GR08 — The design file has no graph pane contract at all · S1 · Observed

reaktor.pen defines a subpane family for ui, devtools, agent, auth, database, telemetry, analytics, ai and cloud. There is no graph family, and the Graph mode tab is the only one authored with no shortcut and no icon. The 14 graph boards are system-map states, not a tool contract. So the highest-priority surface is the one surface the design file never specified as a tool — which is why its instruments (layers, saved views, inspector tabs, camera) differ on every board.

Required fix: author the Graph family — its subpanes, its instrument set, its inspector tabs — the way the other nine are authored. Acceptance: WorkbenchPaneCatalog gains a graph family checked against the design file, and the live instruments are instances of it.

GR10 — Relations are drawn but not readable · S1 · Observed

The layer panel counts 6 route attachments, 6 navigation, 45 dependencies and 9 containment relations, and the canvas draws them, but at every zoom the lines disappear into the card grid: there is no routing, no bundling, no label, no direction marker and no emphasis on the selected path. 16.00 · Reaktor Graph · Living graph instruments specifies six typed relations with their own endpoint roles — CALL → request/result, VALUE → immutable data, FLOW → demand/cancellation, BINDS → consumer/provider, OBSERVES → origin/time, DEPENDS → build/evidence — and says explicitly that "labels and line patterns supplement colour". None of that is rendered. Related: CO18.

GR11 — Expand and collapse do not behave as one gesture · S1 · Observed

Expanding a scope also expands its ancestors and clears the architecture level, and the C4 preset buttons rewrite the whole expansion set. The two controls therefore fight: a preset discards hand-drilled state, and one manual toggle drops out of the preset. There is also no expand affordance on a collapsed scope summary on the canvas — the only way to open a scope is the navigator — and the camera does not follow the scope that was just opened, so on a large graph a successful expand looks like nothing happening.

GR12 — The navigator is a list of sections, not an instrument · S1 · Design gap

16.00 specifies a layer stack of five independently composable layers — Structure, Contracts, Auth / effects, Runtime, Telemetry — each with its own count and settings control, and a view contract that separates hiding a layer from disconnecting a relation. The shipped navigator instead lists the four ReaktorEdgeKind values plus a Resources / operations toggle, has no per-layer settings, no saved views, no search scoping and no way to act on a node from the tree. The node card is also short of 16.00's anatomy: a kind chip and module / symbol on the header line, port rows carrying their own handles, and an activation footer.

GR09 — The minimap is an unlabelled blob · S2 · Observed

Bottom-right, no viewport rectangle, no scale, no click-to-move at 1600; at 1024 it overlaps the little canvas that is left.

Database · Band 2

Two implementations, neither usable: an authored board in the mode slot, and an unreachable skeleton behind it.

DB01 — There is no connection · S0 · Observed

The mode lists seven providers — Supabase Postgres, ClickHouse, Memgraph, Cloudflare D1, Durable Objects, SQLite / ObjectDatabase — as static text with a one-line subtitle each. None can be selected, connected, disconnected, added or removed. There is no status, no credential state, no environment and no error. The list is a drawing of a list.

DB02 — There is no query editor · S0 · Observed

The SQL is BasicText. No caret, no editing, no execute, no cancel, no elapsed time, no error location, no history. Run in the toolbar is the application's Run. The result below it is labelled Result = fixture.

DB03 — The implemented Query subpane is an empty frame · S0 · Observed

The pane that would replace it has an Editor band containing a sentence about editors, a Rows band containing —, a Schema band containing —, and three empty cards labelled memgraph, durable objects, r2. It also carries a different context format (BESTBUDS / DATABASE / LOCAL) from the board in the mode slot (Fieldwork / Postgres / demo / query.sql), so the two implementations do not even agree on which application or which breadcrumb grammar they belong to.

DB04 — Schema, Migrations and History are pictures · S1 · Observed

Named in the board's tab row, drawn, and not attached. Related: N02.

DB05 — The result grid is not a grid · S1 · Observed

No copy, export, sort, filter, pagination, column resize, type display, null-versus-missing distinction, or large-cell inspection. Two rows of fixture data with no way to act on them.

DB06 — The design file draws one screen for seven tabs · S1 · Observed

The database family authors seven subpanes — Query, Schema, Data, Relationships, Query Plan, History, Migrations — and the design file contains one board for them (09.04 · State · Query & Schema) plus two variants that omit Query. Schema, Data, Relationships and Migrations exist only as tab labels. Auth and devtools have the same shape of gap: auth authors six subpanes across three boards, with Providers, Audit and Simulator never the active tab; devtools authors nine across seven, with Logs and Source never active.

Required fix: a board per subpane, or an explicit decision that a subpane is a state of another and its tab is removed. Acceptance: every subpane in the catalog has one authored screen where it is the active tab.

DB07 — The pane defers to a database tool that is elsewhere · S2 · Observed

Open source query in database tool is the primary action. A database mode whose main affordance is to leave for the real database tool is stating the problem rather than solving it.

DB08 — The chrome contradicts the document · S1 · Observed

A .sql document with Kotlin 12:4 in the status bar, the Files icon lit in the tool rail, Problems with no count, and no active tool tab. CO03, live.

Auth · Band 3

The weakest of the four on the coverage gate: 3 of 6 subpanes read real data, and none of them are reachable.

AU01 — The mode promises six surfaces and shows one paragraph · S0 · Observed

ReaktorMode.Auth describes "provider, user, session, role, token, and audit surfaces". What renders is a single fixed explanation of one hard-coded decision — principal technician/meera, resource report/42, policy report-share@v4, result denied — with no principal picker, no resource picker, no policy list, no environment and no way to ask a second question.

AU02 — The implemented Providers subpane is an empty list · S0 · Observed

One empty Providers list, one Detail card holding a truncated sentence (Turns on with: a read-only heimdall adap…), and 78 % of the pane blank — the emptiest of the four pillars' panes.

AU03 — The simulation boundary is a paragraph, not a control · S1 · Observed

Simulated decision · no effect executed is a callout. There is no switch between simulated and observed enforcement, no statement of which binding is missing in a form the user can act on, and no way to see what evidence would change the answer. Related: A02 in the integration backlog below.

AU04 — Auth has no navigation · S1 · Observed

The left panel in Auth mode is the file tree. There is no list of principals, roles, sessions, tokens or audit entries anywhere in the mode.

AU05 — Three of six auth subpanes are never drawn as active · S1 · Observed

See DB06. Providers, Audit and Simulator have tab labels and no authored screen.

Device tools · Band 4

DT01 — Reaktor has no developer tools · S0 · Observed

There is no console, no network panel, no element tree, no computed styles, no breakpoints and no stepping anywhere in the product. Console appears exactly once in the whole engine source: as a text label inside the design-system board LzukO. Network exists only as a drawer tab in the graph shell, counting cloud resources. The Develop mode is a source-plus-preview-plus-property-inspector surface — closer to a design tool than to a browser's dev tools.

Required fix: decide what "device tools" means for a KMP product — an element tree over the rendered surface tree, a console over the running target, a network panel over the real transport, and stepping — and build it. Acceptance: a developer can select a rendered element, read its computed properties, see the requests it caused, read its logs and stop it, on a real running target.

DT02 — The property inspector looks editable and is not · S1 · Observed

Width: Fill container ▾, Height: 175 px, Padding: 18 px, Enabled: state.canCapture, onCapture: interactor.capture — dropdowns and fields drawn at full contrast, none of them attached.

DT03 — Every result says fixture · S1 · Observed

Fixture: completed, Fixture: r18 preview ready, 5 selected · not run. The build panel reports on a build that did not happen.

DT04 — Two different jobs share one mode · S1 · Design gap

The devtools family is Preview · Devices · Testing · Pipeline · Releases · Recorder · Traces · Logs · Source — a build-and-ship family. The mode is labelled Develop in the app and DevTools in the design file, and the owner's fourth pillar is a third thing again: browser-style device tools. One mode currently stands for all three.

Required fix: separate the inner-loop debugging surface from the ship surface, and name each after what it does.

DT05 — Logs and Source are never drawn as active · S2 · Observed

See DB06.

Recorded repairs

F03 affects Pr3Pv, Nm5QX, GaN4a, O0ZFq9, GqUVw, OYUup, Yb00x, Wx6KI and nXDMm. It changes their resize contract, not their original pixels. The source audit's two intentional clipped cards are on Pu9Sf; they illustrate neighboring graph context and should remain cropped.

Compact-layout pass · 8 September

F22 is a floor, not a size. Every board still resolves to its exact authored geometry at its authored viewport, including boards whose every node claims an impossible floor, and the ultrawide captures are byte-identical to the previous pass on all eleven reviewed boards. The change is confined to windows narrow enough to compress a name.

Remaining visual and layout issues

V01 — Exact Pencil raster parity remains unqualified · P0 · Open

Affected: all native boards. Evidence: the existing strict comparison has native text coverage, baseline and edge-sampling differences. Matching dimensions, bounds, fonts and native-host pixels is insufficient.

Reproduce: render the current source manifest through the exact RGBA harness and inspect its per-board masks. Required fix: resolve the remaining renderer differences against unchanged, hash-identified references; treat a source correction as a new reference revision. Acceptance: every required board has matching dimensions, a deterministic repeat and zero differing RGBA pixels. A low mean error is diagnostic information, not a percentage-complete claim.

V02 — Narrow layouts truncate primary identities · P1 · Fixed / verified (F22)

Was: at 1024 × 720, AI stage names became “01 · Inve…” and “02 · Cha…”, cloud module and service names collapsed into fragments, and the Devices board dropped its whole Run / observation column to keep the rest on screen. Ellipsis prevented overlap but hid the very identity a developer needs to select.

Now: identity labels declare a measured content floor and the owning column overflows instead — one of the three routes this issue asked for, and the one that needs no per-board authoring. Stage, module, service, provider and card identities are readable at the supported minimum window size on AI L9r7am, Cloud P29oV8, Auth j8If5 and Devices GaN4a, and the authored source lines the Devices board shows are complete rather than clipped. Full text remains available through the existing tooltips.

Residue: the identity of a selected object in a right-hand inspector can now sit behind the column's horizontal scroll rather than being truncated in place. Which panel should yield first is V05, and the layout exposes that unresolved decision.

V03 — Narrow decision flows lose their outcome offscreen · P1 · Partly repaired (F23) · Open

Affected: Auth j8If5 and Cloud P29oV8. The Auth principal/capability/decision/resolution chain extends beyond the narrow editor viewport; the resolution and parts of its contextual detail need horizontal navigation.

Repaired: the acceptance clause “horizontal scrolling is acceptable for detailed evidence, but its extent must be visible” is now met. The overflow was always real; it was the indicator that was invisible, so a clipped column read as the end of its content. Both the column scroll and the workspace viewport now state their extent in the shell's own colours.

Still required: a responsive decision-flow layout with a readable, always-discoverable result and next action. A compact chain may wrap into a vertical sequence while retaining arrow semantics. Acceptance: the reason, outcome and next step can be understood without guessing that a hidden panel exists.

V04 — Ultrawide layouts stretch relationships too far apart · P2 · Observed

Affected: Data, Auth, AI and Cloud. Panels now fill the window, but many tables and cards expand across nearly the entire display while their useful content stays at an edge. Auth checks and their results become far apart; Data leaves a large empty area below a short result.

Required fix: use intentional docking proportions, bounded reading widths and user-resizable groups. Use extra width for a related inspector, source, plan, result comparison or pinned evidence when the user chooses it. Do not manufacture filler metrics. Acceptance: common comparisons can be scanned without traversing the whole screen; empty space is a deliberate workspace choice.

V05 — There is no product-wide compact-layout contract · P1 · Observed

The new layout kernel preserves intrinsic controls and manages overflow. It does not decide which navigator, inspector, editor group or dock should collapse first. Those choices vary implicitly with authored constraints.

F22 supplies one of these pieces — a per-label content floor with a measured value — and by doing so makes the missing one obvious: every column now answers compression the same way, by overflowing, because nothing says which panel should yield first.

Required fix: define supported window sizes, compact/comfortable density, panel minimums, collapse priorities, independent scroll boundaries and a Reset layout command. Acceptance: a single resize matrix covers every current workspace at 1024 × 720, 1440 × 900, 1920 × 1080 and 3360 × 1418, plus density/font-scale changes. If 1024 is unsupported, the native minimum must enforce that openly.

V06 — Graph wires and annotations still compete with text · P1 · Observed

Affected: district DBc14, feature pxsmW and realtime W9V37c. Return routes and annotation labels run close to region headings and descriptions. The district capture shows dense route labels crossing the same band as folded summaries. This remains visible even where no child is outside its parent's bounds.

Required fix: reserve label lanes, apply edge-to-label collision avoidance, bundle secondary routes, and expose selected-route detail on demand. Acceptance: every primary node/port label has a clear reading area, selected paths stay continuous, and secondary wires cannot obscure selected evidence. Add screenshot cases for dense crossings. A containment-only audit cannot detect these collisions.

V07 — Toolbars can overflow without a clear overflow menu · P2 · Partly repaired (F23) · Open

Affected: map instruments, Devices, source/preview and cloud boards. At narrow widths, right-side actions and context strings continue beyond the editor boundary.

Repaired: the overflow is at least visible now, so the trial-and-error is bounded rather than blind.

Still required: preserve primary actions, collapse secondary actions into a labelled overflow menu and keep current target/selection visible. Acceptance: all supported actions remain discoverable by pointer and keyboard without trial-and-error horizontal scrolling.

V08 — Tiny metadata and map labels need readability qualification · P2 · Measured

The source contains 65 visible text instances below 10 logical pixels, including 9-pixel map scale labels and smaller embedded-preview labels. There are 1,141 instances at 10 pixels; repeated component instances are counted. This is not by itself an accessibility failure, but it identifies a concrete test population.

Required fix: classify product text, embedded-preview text and optional map metadata separately. Provide semantic zoom or an accessible detail view for identifiers and state. Acceptance: the primary task remains usable at normal viewing distance and with increased UI text scale; no essential fact exists only in a tiny canvas label.

V09 — Fit, UI presentation scale and graph camera zoom can be confused · P2 · Observed

The workbench now has Responsive/Fit/100% presentation, while the pictured graph contains its own Fit/100%/zoom instruments and UI Preview has a separate preview scale.

Required fix: label these scopes explicitly: workspace presentation, graph camera, product preview. Avoid changing two scopes with one command. Acceptance: keyboard help and visible controls identify the affected viewport; Back restores the intended camera without resetting presentation.

V10 — “No overlap” currently has incomplete test coverage · P1 · Qualification gap

Containment checks pass except for intentional map context. Native layout tests check geometry and scrolling, and host tests check raster identity. They do not exhaustively test sibling text collisions, edge/label intersections, popup placement, expanded dropdowns or every font scale.

The compact-layout pass adds two of the missing classes: a sibling-overlap invariant over every current board at three viewports, and a rendered-pixel case for an overflow indicator, which no geometry check could have caught.

Required fix: add targeted assertions and rendered cases for the remaining failure classes — edge/label intersections, popup placement, expanded dropdowns and every font scale. Acceptance: every open V-series issue has a repeatable failing example before its fix and a passing check afterward. Do not weaken pixel acceptance to make layout tests pass.

Shell, navigation and everyday editing

N01 — The workbench still switches complete boards instead of sharing one document workspace · P1 · Integration gap

The atlas specifies persistent editor groups, docked tools and shared context. Current non-Graph navigation selects a full authored board. Source tabs, breadcrumbs, project trees and inspectors inside that board are largely authored examples.

Required fix: introduce the persistent document/dock model under the existing visuals. A source file, graph projection, query, auth explanation and run receipt should be documents or tools over one context. Acceptance: open source, graph and a query alongside each other; change one selection; verify the chosen linked tools follow it while pinned tools do not.

N02 — Visible local controls still have no behavior or unavailable state · P1 · Observed

Examples include Data's Schema/Migrations/History tabs and provider rows, authored action buttons such as “Create finding from row”, and numerous inspector dropdowns. The reviewed common shell bindings do not attach those operations. Several still look enabled.

Required fix now: inventory each intended control and render available, unavailable-with-reason, loading or failed state explicitly. Required fix later: attach the operation through the shared command model. Acceptance: every visible affordance either works or explains what is missing; no silent dead end. A global fixture footer alone is insufficient.

N03 — Pictured tabs do not yet behave as documents · P1 · Integration gap

The accidental close navigation is repaired. The close icons themselves remain unavailable, and the authored active/source/preview tabs do not support a complete document lifecycle.

Required fix: real tab identity, dirty state, pinning, close/reopen, reorder and editor-group movement. Acceptance: closing a tab affects only that document; closing a dirty document has a defined, recoverable outcome; navigation history is not used as a substitute for an open-document set.

N04 — Displayed source, queries and identifiers are not full editing/copy surfaces · P1 · Observed

Generated authored text uses native BasicText. The reviewed board host does not turn its pictured editors into editable documents or provide a universal selection/copy surface.

Required fix: retain typography and geometry while introducing appropriate editor/read-only selectable components. Offer Copy identifier, Copy query and Copy evidence even when execution is unavailable. Acceptance: users can copy the complete untruncated value by keyboard and pointer; editable state is explicit and backed by a real document.

N05 — Authored context does not follow active application context · P1 · Observed

Fieldwork and BestBuds examples carry their own project, branch, revision, target and run labels. Switching from the live graph to an authored workspace does not make these examples live context.

Required fix now: maintain an unmistakable example/reference state close to the workspace title and action areas. Required integration: one context tuple containing workspace, revision, environment, principal, selection, time and run. Acceptance: a context switch invalidates or rebinds dependent views visibly; no screenshot fixture becomes an apparent production observation.

N06 — Search has inconsistent scope between live and authored workspaces · P2 · Observed

Search opens the graph command experience in the live workspace and the surface chooser in authored workspaces. Both are useful, but the same gesture changes meaning with location.

Required fix: one command palette with explicit scopes for commands, symbols, nodes, resources, runs and design references. Acceptance: search results state their type and execution scope; unavailable commands include reasons; a command behaves consistently regardless of the current tool.

N07 — The surface chooser mixes product navigation and design review · P2 · Observed

It exposes 122 boards plus the live graph, including retained references and libraries. Classification and search help, but an ordinary developer should not need a source-board catalog to find a database or trace.

Required fix: task-oriented primary navigation, recent/pinned workspaces and a separate reference-review filter. Keep all reference boards accessible. Acceptance: a new user reaches Graph, Data, Auth, UI Preview and the active run without knowing a board ID or atlas numbering.

N08 — Layout control is incomplete · P2 · Integration gap

The current presentation chooser is real; most pictured dock controls are explicitly unavailable. There is no complete user-controlled split, resize, detach, restore or saved-perspective workflow.

Required fix: implement docking over one layout model with keyboard alternatives. Acceptance: source, graph, details and a run log can be arranged and restored without losing selection, scroll or unsaved work.

N09 — Status/context vocabulary is too compressed in some instruments · P2 · Observed

Map counters such as “4 / 4 / 61 · 1 port” and short provenance strings save space but require the user to recall the denominator and scope. “Graph” also names a primary mode, a source reference and an instrument.

Required fix: stable labelled counts, tooltips and an Explain view that states visible/scoped/known/unloaded categories. Preserve compact labels for expert use. Acceptance: users can explain what each count excludes and identify whether they are viewing a definition, activation, observation or authored example.

Living Graph interaction gaps

G01 — The continuous system map is still a set of authored states · P1 · Integration gap

Estate, district, feature and port references now exist in the native catalog, and reviewed navigation connects them. They are not yet a continuously navigable projection of the active application graph.

Required fix: attach the visual instruments to the real graph session, preserving stable node/port IDs, selection, layer query, time and camera history. Acceptance: traverse estate → district → feature → exact port and back on the same graph; no board replacement, synthetic runtime values or lost selection.

G02 — Layer controls need executable, inspectable query semantics · P1 · Integration gap

The source shows ordered layers and visitors, but the new authored layer stack is not a complete runtime query editor.

Required fix: enable/disable, reorder, scope and parameterize layers; show why a node is included or hidden, query budget, truncation and unknown regions. Acceptance: the same saved query gives equivalent results through the human UI and agent interface; toggling a layer changes the projection, not the underlying program.

G03 — Graph-wide selection linkage remains incomplete · P1 · Integration gap

UI element inspection, source following, query results, auth decisions, cloud placement and traces are designed to share graph identity. The new authored tools are not yet all attached to that selection.

Required fix: a selection envelope with entity ID, revision, activation and time, plus explicit Follow/Pinned behavior per tool. Acceptance: select from a UI element, port, database row, scheduled workflow or trace event and reveal the related flow without assuming every flow starts at a UI.

G04 — Route navigation needs a complete interaction contract · P1 · Integration gap

Painted corridors communicate request, result, error, actor, stream and delivery relationships. Runtime interaction still needs member picking, direction-aware traversal, branch selection and a clear distinction between reachability and observed causality.

Acceptance: select a bundled route, inspect exact member ports and their completion/failure contracts, choose a branch and follow it across FFI/service/provider boundaries. Unknown receipt must remain unknown.

G05 — Maps need scalable density and label management · P1 · Observed design gap

The current examples already contain dense crossings. Larger systems require aggregation, stable layouts, route isolation, label budgets and bounded expansion.

Required fix: semantic zoom, summarized regions, named boundary portals, priority labels and layout stability during observation updates. Acceptance: test realistic small, medium and large application graphs with measured interaction latency and readable selected routes. Do not claim scalability from the 172-node application fixture alone.

G06 — Camera, selection and execution history need separate visible controls · P2 · Integration gap

The port source correctly distinguishes a pinned activation from a changed working copy, but that interaction is not yet fully operational.

Required fix: independent camera history, selection history and execution cursor, with explicit follow/pin behavior. Acceptance: a source edit cannot silently retarget a pinned run; a new run does not move a camera unless Follow is enabled; Back restores the appropriate context.

G07 — Graph authoring needs complete pointer and keyboard workflows · P1 · Integration gap

The live graph is real, but the full new design implies more: port wiring, module insertion, Kotlin correspondence, validation, patch review and commit.

Acceptance: create a node, discover compatible ports, inspect incompatibility, connect or cancel, undo/redo and review the typed patch using both pointer and keyboard. A drawn wire is not evidence that a supported runtime connection was committed.

G08 — Compare and graph commits need legible change semantics · P1 · Integration gap

Required fix: separate structural, contract, placement, authority and observation changes; display affected routes, validation evidence and revision ownership. Acceptance: an agent or human proposal can be reviewed without interpreting an undifferentiated red/green graph; operations remain scoped to the reviewed revision and produce receipts.

G09 — Discovery and partial topology need actionable empty states · P2 · Design gap

The map depicts Manna as unloaded and several cloud members as unknown/designed. The next action should explain whether the user needs a workspace path, provider adapter, credentials, a target, or runtime observation.

Acceptance: “not found”, “not loaded”, “not authorized”, “unsupported”, “stale” and “failed to observe” remain distinct and each offers an appropriate, non-destructive recovery path.

Data, auth and the software value chain

The following are integration backlogs with concrete UX acceptance. They must retain the authored layouts rather than mount the retired panes.

For the detailed system contracts, follow the graph foundation, graph interaction specification, agentic tooling, cloud pane and desktop master plan.

Accessibility, discoverability and failure qualification

These checks are required before release. Where no direct failure is recorded, retain the qualification gap label.

Design coherence: why the atlas still reads as separate tools

This section records the cross-board review completed on 8 September 2026 (Claude Fable 5.1). It looks at a different axis from the V, N and G issues: not whether one board renders or resizes correctly, but whether the 122 boards describe one tool. They do not yet. Each design wave — the Machine Signal fabric shell, the IDE chrome, the STATE storyboards, the system-map states and the retained references — brought its own shell, vocabulary, fixture, provenance style and scale model, and the documents describe yet another model. Nothing enforces a shared contract, so the same concept is drawn differently on almost every board. Evidence: a structural scan of every board in the source file and five reviewer passes over the exported images (15 + 15 + 25 + 29 + 22 boards read at full size). Several findings are defects introduced by the 7 September map iteration; they are marked as such.

The CO issues use the same status and priority scheme as the rest of this document. Most are design gaps: they are fixed in reaktor.pen, the shared component library and the canonical documents before any implementation, and they explain many of the N, G and Q items above.

CO01 — Five information architectures compete · P1 · Design gap

Evidence: the 29 retained boards carry a 14-tab bar (six lenses × eight homes, two lit at once, lens chosen arbitrarily); the design system and older graph boards use Map/Trace/Validate/Act movements; A0a5je and the toolbar use Develop/Compose/Debug/Operate perspectives (the perspective label reads "Develop" on IDE boards and "Graph" on map boards, which is not a perspective); 36 of 61 registry entries are categorized as "Homes · …", 18 as "Graph · Living Graph" and 7 as bare System/Runs/Evidence; the entrance yPKZB organizes by 13 chapters plus a 7-phase AUTHOR…IMPROVE band, cannot reach Hr7rV, LXase, ObFUi and oKbaW, and lists w4EWt twice; the tool rail has 9 unlabeled icons, the bottom strip 7 tools, the atlas text 13 tool windows, and the desktop code 12 modes. The same tab mission.reaktor hosts five unrelated screens (Gbwnj, Hzi6v, L9r7am, DOTHj, gddyF).

Required fix: one IA — perspectives × tool windows — written once, mirrored by the entrance, the registry categories, the rail (labelled, highlighted per perspective), the strip and the documents. Acceptance: every current board is reachable exactly once from the entrance; rail, strip and documented tool list are identical; no board is filed under a home, lens or movement.

CO02 — Three shell generations, and the proofs belong to the wrong one · P1 · Design gap

Evidence: shell A (Machine Signal fabric: movement and instrument strips, context bar, SAVED SCOPES explorer, Evidence & execution footer, nine-tab drawer) on 33 boards, including every responsive and theme proof (gt7MZ, v0bjJ, xqQrc, VLrsK, V2GduQ), the design system LzukO, the atomic catalog GiULy, the palette kvPHW and the drawer states wXLgg; shell B (CU5sk: Open project / Create app, vertical Missions…System rail, PINNED); shell C (IDE chrome: menu bar, run toolbar, tool rail, Project tree, Terminal…Conductor strip) on 61 boards, with a graph variant at 2200×1320 and a 280 px navigator. Inside shell C two templates coexist: instrumented screens and slide-like boards (Hr7rV, LXase, ObFUi, oKbaW, p4vwb) with no action row, floating cards and 40–55 % empty canvas. No Light, High-Contrast, 390 or 768 proof touches shell C; the responsive proofs open a different project (bestbuds/AuthService) and their main pane is a placeholder essay. LI1ng is a static copy of the chrome, not a component sheet; GiULy catalogs the consumer app's atoms, not the tool's.

Required fix: declare shell C the only shell; regenerate design system, catalog, palette, drawer, theme and responsive proofs from it (or declare desktop-only and delete 390/768); move shell A and B boards to an archive section with a line saying what replaced them. Acceptance: every proof board's chrome bands equal shell C's; the design system's composed screens are shell C screens.

CO03 — Shell C never reflects the document it shows · P1 · Observed

Evidence: the rail highlights Files on data, agent, auth and graph boards; the Structure panel is frozen at "Capture visit · inputs 2 / outputs 2" on 13 boards; the status bar says "UTF-8 LF Kotlin 12:4" on SQL, YAML, JSON, Markdown and graph documents; the bottom strip never has an active tab, even with the debugger open (w4EWt); Problems never carries a count although GaN4a logs FAIL, O0ZFq9 and Yb00x show failed gates and Nm5QX shows HOLD; the blue Run primary sits on Costs, Releases, Layouts, the state catalog and the system map; breadcrumbs end in a marketing question on eight boards and are a real path on one (yawya); tab names follow three grammars (real files, pseudo-files such as system.reaktor, and "Category · noun"). Related: N01, N02, N09.

Required fix: derive rail item, explorer view, tab grammar, breadcrumb path, active tool, status fields and the perspective label from the focused document, and check it per board like a lint. Acceptance: an automated check over the source file finds no board whose chrome contradicts its document.

CO04 — Slides wearing the shell instead of states of an instrument · P1 · Design gap

Evidence: the five slide boards above, the nine STATE boards with an unchanged preview image under nine different captions (oxhTK … ag6vT), "Workspace activity · Working copy r18 · selection retained" filler on nine boards, doctrine sentences on 13 of 15 workspace boards, roadmap copy inside product UI (p4vwb), design notes inside fixture code (O0ZFq9), "DESIGN TARGET … need implementation" inside a product table (DOTHj). LXase is oKbaW's "Unknown outcome" state promoted to a board; ObFUi is GqUVw's "no comparable measurement" state; Hr7rV and p4vwb are the Releases object at two steps.

Required fix: fold each slide into a state of its parent instrument; every board keeps an action row and one visible primary action; empty canvas must be a deliberate workspace choice. Acceptance: no current board lacks an action row; state variants change the instrument, not the narrative.

CO05 — Failure and progress are invisible; states exist only as breadcrumb text · P1 · Observed

Evidence: FAILED STAGE, BLOCKED and UNKNOWN OUTCOME (VsGDs, r7L5v, HfRjK) share the amber chip, blue Run, empty Problems and unchanged activity feed with DRAFT and RECONCILED; RUNNING (Ipum2) has no progress, no Stop and Run still highlighted; DRAFT (oxhTK) already has five source files open; ZqZ5F says "Continue building" two states before aFYsq says the build has not started; X45qZ shows attempt A-2 with no A-1; recovery (ag6vT → KWocx → HfRjK) has no trigger and rolls back to an r18 whose compatibility KWocx calls unknown; oKbaW defines eight states that the other boards paraphrase eleven other ways; no Loading, Running, Denied, Offline or No-project state exists for shell C (a 403 exists only in shell A). Related: Q07, G09.

Required fix: a written state table (state, trigger, outcome, next state, which panes change) that every STATE board is drawn from; failure changes the chrome (red chip, Problems count, Stop control, activity entry). Acceptance: each non-happy state changes at least three chrome elements relative to the happy path, and the transitions are visible.

CO06 — Two revision universes; r19 means three things · P1 · Observed

Evidence: graph boards use G42/G41; IDE boards use r17/r18/r19; shell A uses r1842, 8f41c2, v19; releases use rc-812, v812 and sdk v812 for one deploy (OhclB, cvqmo, DeFQh); r19 is a failed compile (VsGDs), a not-started release blocked by S-04 (r7L5v) and the currently deployed web build (KWocx, Xd3s4, of8K7) while every header says "Working copy · r18"; A0a5je and Nm5QX say r19 in the breadcrumb and r18 in the status bar; Hr7rV plans r19 under r18; Yb00x conflates semver, build number and revision ("0.1.18 (18) · fw-r18"); the map's Pu9Sf relates r18 and G42 in one caption without a definition. Version notation itself varies: @3, v3, / v3, /v2, "schema rev 3", "Contract v3", @1.

Required fix: one revision grammar (source rN, graph definition GN, release rc-N, artifact identity) with the relation between source and definition revisions written once, and one fixture timeline. Acceptance: every revision string on every board is in the fixture ledger; the same label never denotes two states.

CO07 — Identifier collisions across boards · P1 · Observed

Evidence: "42" names a visit, an upload, a capture, a change, an experiment, a notification, N-42, Upload-42, report-42 and visit-42; operation 42 has six spellings (capture/42, upload/42, upload-42, U42, upload27, accept(visit/42)); p95 is a latency percentile on ObFUi, Nm5QX, GqUVw, ZlHaI, L8el1, l4tkKY and LzukO and a port on Pu9Sf; S0x names route segments (nXDMm), fixture seeds (Wx6KI), a cohort (Nm5QX) and a scenario S-04 (r7L5v); P18 is a profile (GqUVw) and P-18 a patch (Hr7rV, LXase); B18 is a budget run and a baseline; T381 and trace-17 name the trace; events are E201, E101–E105, evt-M204, E03–E22 (edges on Pr3Pv) and bare 1–5 (A0KF5); C1 is a bundle, C07 a checkpoint, C-12 a context item; W17 a witness and w17 a watermark; run ids are #318, #322, B18, A-1, r204; local/7 and "activation epoch 7" are never related.

Required fix: one identifier grammar reserved per kind (ports pNN, runs run #N, operations kind/N, traces T-N, changes C-N, findings KIND-N, percentiles written "p95 latency"), enforced with a text lint over the source file. Acceptance: the lint reports zero cross-kind collisions.

CO08 — Port identifiers are not stable inside the new map family · P1 · Observed (introduced 7 September)

Evidence: p44 is MediaRepository.put on ZCxzu, DBc14 and pxsmW, VisitActor.put on W9V37c, and is replaced by a new p96 on Pu9Sf; p90/p91 name ImageProcessor on pxsmW and Domain records on W9V37c and ZCxzu; p140/p141 swap meaning between DBc14 and W9V37c; Pr3Pv numbers the same nodes p09–p33; every board footer still says "same stable IDs".

Required fix: make the fixture ledger authoritative and correct the boards against it. Acceptance: each pNN maps to exactly one node and port across all boards, and the ledger is the only place a new port is minted.

CO09 — Turn 12 of local/7 is recorded twice, incompatibly · P1 · Observed

Evidence: Pu9Sf, ufhps and pxsmW record E201–E202, 14 ms, media.put over HTTPS, uploadId 27; izozd records E101–E105, 8.1 ms, persistCapture to the local store and VisitState v18→v19 for the same turn; VisitActor.kt differs in text and line numbers (104–120 on Pu9Sf, 84–88 on izozd, CaptureGraph.kt:84 on IRQ5A); the G42 contract is VisitCommand v1 on izozd and "requires v2" on hqJ9u; timestamps 14:02:11.482 (map) and 14:03:02 (W9V37c) sit beside a gate failure logged at 14:02:14 (GaN4a) and at 14:06 (Yb00x).

Required fix: one recorded-activation file (events, timings, values, source lines) that every board quotes. Acceptance: any two boards showing local/7 agree on every event they share.

CO10 — Δ43, Δ44 and Δ45 each mean several changes; the compare row is boilerplate · P1 · Observed

Evidence: Δ43 is keyed retry and provider repair on five boards, an idempotent-upload proposal on IRQ5A and a typed-hole composition draft on aPU6J; Δ44 is a Postgres outbox (W9V37c, ZCxzu), a client ObjectStore outbox (pxsmW), UploadOutbox n30 (nXDMm, Wx6KI) and CaptureOutbox plus UploadWorker (hqJ9u); ZCxzu offers Compare Δ43 and Compare Δ44 side by side; the "Compare ΔNN · Attach runtime" row appears on all 17 graph boards in six label variants whether or not the Δ applies (copied with the shell during the 7 September iteration).

Required fix: one story per Δ in the ledger; remove the boilerplate row and show Compare only for the change a board is about. Acceptance: each Δ has one definition, one owner and one affected-node list.

CO11 — One role, many names · P1 · Observed

Evidence: Media Gateway / MediaService / UploadAdapter / Media Worker / UploadWorker; Domain service / VisitService / Media authorities / Domain records; ImageProcessor / ImagePipeline / ImageTransform / Native encoder / PrepareUpload; CaptureView / CaptureController / CaptureInput / PhotoCapture; PhotoRepository / PhotoService / Upload service / UploadRepository / upload_intents; A0KF5 names Media Gateway in its map chip and MediaService on the card; n17 is MediaService on nXDMm and UploadAdapter on Wx6KI; n01 is CaptureView on nXDMm and CaptureController on Pr3Pv; the offline-capture work item has five titles across Mmo0o, Gbwnj and the STATE boards; the human is "Operator" on Hzi6v and "Operator" is an agent identity on L9r7am and DOTHj; the user is ovd in every top bar and @shibasis in histories.

Required fix: a node and role registry with one canonical name each; boards abbreviate only through the registry. Acceptance: no fixture node has two names; no name denotes two nodes.

CO12 — Counts disagree for one scope · P1 · Observed

Evidence: the capture scope is 5 nodes / 12 scoped (pxsmW), 18 nodes / 24 relations (16.x boards, Wx6KI) and 8 + 14 + 6 (ufhps); the Cloudflare edge district is 5 in the navigator, 6 in the inspector and 14 scoped in the header of DBc14; BestBuds is 172 nodes on FsQx4 and L8el1 and 166 on l4tkKY; ZCxzu's inspector ends the route at p121 while its dock ends it at p45; okDnx says 60 nodes and draws 27; T51iyD's top-seven regions sum to more than its active total; jmEA1 says 12 policies and lists 11; wXLgg shows Build "0 errors" beside compile and wrangler errors. Related: N09.

Required fix: counts come from the ledger with visible / scoped / known denominators, and every count names its scope. Acceptance: any two counts of the same scope on any two boards agree.

CO13 — Seven scale ladders and a self-contradicting keymap · P1 · Design gap

Evidence: estate / district / feature / port at 18 / 65 / 140 / 260 % (map boards); L0 Landscape ≤25 %, L1 Island 25–50 %, L2 Standard 50–100 %, L3 Detail ≥100 % (L8el1); "L2 · FEATURE" with 36 % and 118 % (l4tkKY); World / System / Street at 64 % (ufhps); Scope · Root / Detail · Mixed / Auto zoom with no percentage (FsQx4); Scope / Layers / Detail: ports / Time at 100 % (Pr3Pv); L0–L4 landscape / island / subgraph / component / detail in Graph Navigation; System / Container / Component / Code plus Hierarchy / L1 / L2 / All in the desktop. The ladders contradict each other in practice: DBc14 at "65 %" shows full port lists, which L8el1's own 50–100 % rule forbids; W9V37c calls a two-boundary view "district"; Pu9Sf's 260 % lies beyond its scale bar. Keys: F means frame route, focus selection, fit route, frame selection or frame path depending on the board, and nXDMm binds two of them at once; fit is ⇧F, home or ⇧home; search is / reveal, / search graph, / filter graph, ⌘F, ⌘K or ⇧⇧; actions are ⌘K and ⌘P on the same board (Wx6KI); tier navigation is 1–4/0, 1–9/0 or Enter/Esc; the palette says "open in IDE" as if it lived elsewhere (kvPHW). Related: V09.

Required fix: one ladder with a render contract per band (what folds, what expands, label budget) and one keymap, both in Graph Navigation and in the viewport instrument component; retire L8el1's tiers or make the map obey them. Acceptance: every zoom percentage on a board falls inside its band's range and shows only what the band's contract allows; one key has one meaning.

CO14 — Panel names are invented per board · P2 · Observed

Evidence: the left tree is Project, System explorer, Explorer · sheet, SYSTEM OUTLINE, GRAPH NAVIGATOR (7 boards), ESTATE NAVIGATOR (5), APPLICATION EXPLORER, BESTBUDS · SYSTEM NAVIGATOR or LIVING GRAPH, at widths of 200, 224, 250, 280 and 295 px, and three boards add a second navigator inside the editor (Ruuut, fFimd, yawya); the layer control has eight variants (LAYER STACK · ordered query with Scope as a layer, LAYER STACK with another set, RELATION LAYERS, SELECTION LAYERS, FLOW LAYERS, Layer stack, VIEW COMPOSITION, BASE·STRUCTURE chips); saved state is Saved cameras + History, Saved views, a lone Save view button or Selection path; the inspector has more than ten titles and four tab sets (Ports/Source/Runtime/Telemetry/Auth; Inspect/Ports/Source/Runtime; closable Ports/Source/Runtime; Ports/State/Effects) and docks right, left (Ri7Es), floats or becomes a chat (Mmo0o); findings live in four places (aPU6J Problems, FsQx4 dock, IRQ5A tab, Wx6KI witness); "Evidence" is a tab, a card, a panel, a drawer, a button and a percentage.

Required fix: one name each (Project, Layers, Saved views, Details with Ports · Source · Runtime · Evidence · Agent), one width per altitude, Problems as the only findings surface. Acceptance: the shared shell component exposes these names and no board overrides them.

CO15 — Verbs and progress models drift · P2 · Observed

Evidence: the agent affordance has more than ten phrasings (Ask Conductor, Ask agent, Ask · Propose, Ask Codex about this route, Ask Claude to fix all, Fix with AI, Create scoped/repair/benchmark task, Create optimization mission, Attach selection to Conductor, Drive with Codex, Delegate) and four dock positions while A0a5je declares "Conductor · Right · auto-hide"; "open source" has ten variants, Compare seven, Preview seven names, Attach six; j8If5 says "Ask a dispatcher" and offers "Compare as dispatcher"; delivery has four progress models (O0ZFq9 four stages, Yb00x five readiness items, Hr7rV six steps, p4vwb four epochs), three run-id schemes and a lone HOLD (Nm5QX) with no promote anywhere; grey buttons carry nouns ("Required", "Changes", "Runs") on Hzi6v; blue-filled buttons serve both navigation and commitment.

Required fix: the command registry described below, with canonical labels, and design-file chips instanced from it; one delivery object with one stage model shared by Pipeline, Releases, Publish and Evolve. Acceptance: each command has one label, one icon and one shortcut across boards; each object has one progress vocabulary.

CO16 — Provenance is written in many registers and leaks into data · P1 · Observed

Evidence: shell A uses at least 14 spellings (SOURCE, OBSERVED, DESIRED + OBSERVED, Truth, EVIDENCE %, FIXTURE, DESIGN FIXTURE, authored fixture, Recorded, estimate · not observed, UNKNOWN, UNASSESSED, not wired, adapter not connected); shell C uses six registers (orange status stamp, caps banners, subtitles, callouts, code comments, roadmap copy) and puts fixture words in data cells ("Fixture: passed", "stage · fixture", "Fixture observation", "Result = fixture", "fixture receipt publish-web-19"); STATE boards carry three disclaimers each; the map boards use icon marks (pin, radio, pencil-ruler), chips and three status-bar phrasings ("Authored design fixture", "Design study", "Design specification"); the TruthMark family the design system defines (Live, Source, Fixture, Stale, Partial, Unknown, Failed) is not used by graph or IDE boards.

Required fix: one provenance register — the TruthMark family — with a fixed location (status stamp plus per-value marks), and no fixture words inside data cells. Acceptance: every "not real" statement on a board is a TruthMark instance; the status bar carries one stamp.

CO17 — Colours carry three to five meanings each · P1 · Design gap

Evidence: amber = stale (Pu9Sf), designed (W9V37c), simulated (route mode), the Work road, the Service and Repository families, a declared-only boundary (izozd) and "+ CHANGE" chips; blue = definition provenance, the state road, the attachment edge, selection, the Route/Actor/Container families and the selected path (ufhps); green = recorded, correlated route, the build road, the Screen/Agent families and a receipt; red = the error road, authority (IRQ5A), WRITE (A0KF5), stale base (hqJ9u) and the Auth family; purple = the Bus road, BINDS, the Interactor/Topic families, navigation (FsQx4) and FEATURE badges (DBc14); the map colours districts by node family; the new library palette collides with itself (Service and Repository both amber, Route/Actor/Container all blue, Interactor/Topic purple equal to the Bus road); on shell A the card-border colour leaks into provenance labels so "SOURCE · main" is red on one card and "OBSERVED · 3s" green beside "not wired". Related: Q04.

Required fix: reserve hue families — provenance (four), relation classes (pattern first, few hues), node families (distinct from both), status — and lint the tokens; districts and scopes use one neutral scope colour. Acceptance: no hue appears in more than one family; the legend and the token file agree.

CO18 — Two relation taxonomies and eight layer stacks for one graph · P2 · Design gap

Evidence: Wgw9w defines ten road classes; p0Fgf defines six relations (CALL/VALUE/FLOW/BINDS/OBSERVES/DEPENDS); FsQx4 uses four (dependency/attachment/navigation/containment); the desktop uses four relationship chips; layer stacks come in the eight variants listed under CO14, with different names, counts and orderings for the same graph.

Required fix: one relation taxonomy in Living Graph → one legend component → all boards; one layer stack component with one ordering rule. Acceptance: the legend on any graph board is the same component; layer names and counts derive from the taxonomy.

CO19 — Type-ramp regression and density · P1 · Measured (partly introduced 7 September)

Evidence: the 18 August pass cleared the file of text at or below 10 px; the map iteration reintroduced it (ZCxzu 61 of 192 texts, Pu9Sf 61 of 242, DBc14 36 of 140, pxsmW 32 of 143, W9V37c 31 of 152, Wgw9w 35 of 66), and nXDMm (38 of 160), L8el1 (45 of 127) and IRQ5A carry 9–10 px floaters and caps labels; shell A boards spend about 30 % of height on chrome and leave 75 % of their panels empty while truncating headers ("Constraint Optimiz", "Polyglot Boundary St"); Ri7Es, P29oV8 and GqUVw are the densest IDE boards; Light and High-Contrast variants fail contrast on mono captions and amber LOCAL on cream, and High Contrast is a hue swap with white outlines on every container. Related: V08.

Required fix: a ramp floor of 11 px for product text and 12 px for body text; map metadata behind semantic zoom or a detail view; a contrast pass on shell C rather than shell A. Acceptance: the census reports zero product text below the floor; contrast checks pass on shell C's own panels.

CO20 — Fake precision and constant evidence blocks · P1 · Observed

Evidence: seven template clones (Mw1gH, D0yQo, blRVd, ysUFy, qoZHY, AgsbM, ED2r5) share "12 findings · 3 blocking", "EVIDENCE · 94 %", "Confidence 1.0 / exact", "OBSERVED · 3s" and "LIVE · 2s" beside their own note that runtime observation is not wired, and "14 tests · 3 deploy targets" on auth, design tokens, a C++ ABI and AI traces alike; numbers contradict across boards (1,200 uploads in 30 minutes on GqUVw against 6,000 visits a week on OYUup; spans 8.4 M/24 h on ZlHaI against 42 k/s on DeFQh; AuthService p95 142 ms on okDnx and 400 ms on ZlHaI at the same commit; daily AI cost $118 on D3PIAz/Wjmfj and $124 on zJrBc whose rows sum to $122; moderation on three different models across ZV3fR, Wjmfj, zJrBc; budbot v7 "live" on ZV3fR and "not released" on qtbd3; D7 retention 41 % on i1enWz and 44 % on D3PIAz; kvPHW 92 ms and 210 ms on one screen); one number generator recurs (142, 412, 62 %, 5,236, 8,412, 8f41c2); read-only reference boards still expose Commit, Revoke all, Promote to 100 % and Restore.

Required fix: all numbers drawn from the fixture ledger; delete constant evidence blocks; reference boards lose live destructive controls. Acceptance: no numeric value on a board lacks a ledger entry; no two boards disagree on a shared value.

CO21 — Fixture universes and the example switch · P2 · Observed

Evidence: Fieldwork / Meera / r18 (shell C and B), bestbuds / AuthService / ovd / r1842 (shell A, GiULy), bestbuds / checkout (kvPHW), bestbuds / onboarding and chat (wXLgg), and the audited BestBuds application (FsQx4, LODux, P29oV8) with its own explorer header ("System explorer / Features"), target ("System targets") and stamp ("Architecture fixture"); the responsive proofs open a different project than the tool's states; P29oV8 reads as a different application. Related: N05.

Required fix: two fixtures only — Fieldwork (authored) and BestBuds (audited) — with an explicit switch in the shell and one user identity. Acceptance: every board names its fixture through the switch; no third project appears.

CO22 — Redundant boards and template clones · P2 · Observed

Evidence: gVWV6 ≈ Ruuut; n7tbP, pj1eK, a1cWFd are one board with states; i1enWz, ITreE, QMram, D3PIAz tell one product-analytics story with conflicting numbers; zJrBc, Wjmfj, ZV3fR overlap and contradict each other; the seven shell A clones swap card titles over identical fake findings; okDnx is superseded by ZCxzu; Wx6KI overlaps the map's explain view; w4EWt and A0a5je restate one paused turn with different labels; PERF-12, COST-7 and ObFUi are three proposals on one encode path with no cross-link; Pr3Pv and QPAyL carry on-board titles unrelated to their atlas names; boards come in 17 sizes. The retained-reference review recommends: keep T51iyD, jmEA1, z6gUa2, lN1J9, cvqmo, ZlHaI, YdwCE, W3npMV, ZV3fR; merge n7tbP+pj1eK+a1cWFd into the compose board, OhclB into the district map, DeFQh into ZlHaI, Wjmfj+qtbd3 into Conductor, i1enWz+ITreE+QMram into one analytics reference, qoZHY and AgsbM into document text; retire Mw1gH, D0yQo, blRVd, ysUFy, AgsbM, qoZHY, ED2r5, okDnx, zJrBc, D3PIAz.

Required fix: apply the keep / merge / retire list and turn merged boards into states; one board size per altitude. Acceptance: no two current boards answer the same question; every retained reference states what replaced it.

CO23 — Standard IDE and editor affordances are absent everywhere · P1 · Design gap

Evidence: no run-configuration picker (only target chips: Web · Local, All targets, Local JVM, System targets); no Problems counts or gutter markers; no undo/redo or dirty-tab markers on a "working copy"; no context menus or opened menus; docking claimed on LI1ng but never shown; no settings, help or keymap beyond one table on A0a5je; "changes.diff" without a diff; "Search everywhere" drawn as a bottom table rather than the toolbar search's popup; no Stop, cancel, background progress or notifications; on the graph, no marquee or multi-select, alignment, drag-from-pin pending-wire state (aPU6J shows a palette but no drag), breakpoints or watches outside izozd, and izozd's breakpoint "does not step or pause"; L8el1's gesture grammar (drag pin, ⌥ click, ⌃ drag, reroute, ⌘G extract) is the only Blueprint-grade specification and nothing renders it. Related: N02, N03, N08, G07.

Required fix: render the editor floor once — menus, context menu, run configurations, Problems with counts, docking, settings, keymap, undo, diff, graph selection and wiring states — as shell C proofs. Acceptance: each affordance has one authored proof board or state and one native test.

CO24 — Atlas, registry and document noise · P2 · Observed

Evidence: board names use 14 prefix conventions (Reaktor IDE 41, Reaktor Graph 20, AI 6, Graph 5, System Studio Shell 5, Interface 4, Observe 3, Learn 3 and eight others); 04.03A–04.03D are filed under the graph substrate but placed among the 16.x boards; registry categories mix three schemes; two registries were produced by two sessions on one day; the documents describe L0–L4 levels, 13 tool windows and four perspectives that the boards do not show; "Blueprint" appears only on A0a5je and yPKZB; the docs' "Source only" and the desktop's C4 presets appear on no board.

Required fix: one naming convention, one registry category scheme equal to the IA, and a documents-versus-boards check in the registry sync. Acceptance: the registry sync fails on a board whose prefix, category or size is outside the convention.

CO25 — The rendered subpane set is not the authored subpane set, and no gate compares them · P1 · Observed

Evidence: the Cloud pane renders eight subtabs in the running window — Topology, Kubernetes, Resources, Operations, Deploy, Pipeline, Runs, Cost — while WorkbenchPaneCatalog authors six; Topology and Kubernetes exist in neither the catalog nor pen-truth.json, and MachineSignalSubpaneRenderTest accordingly emits no cloud-topology.png or cloud-kubernetes.png. In the other direction, Deploy and Testing are two of the thirteen modes in the rail and have no pane family at all — the catalog lists only ui, devtools, agent, auth, database, telemetry, analytics, ai, cloud. MachineSignalPaneCoverageTest passes throughout, because every one of its assertions compares the catalog to pen-truth.json; nothing compares the rendered tab strip to either. So "13 modes" and "74 subpanes" are two taxonomies that overlap only partly, and the coverage gate is blind to the difference.

Required fix: assert the rendered subtab strip against WorkbenchPaneCatalog for every mode, the way devToolsStripLeadsWithTheAuthoredSubpanes already does for DevTools alone; then either author Topology and Kubernetes into the cloud family or fold them into Resources, and give Deploy and Testing a family or state in the catalog that they are mode-level tools outside the subpane taxonomy. Acceptance: a subtab that no family authors fails the build, and the count of rendered subtabs across all modes equals the count the catalog declares.

CO26 — One shell renders under six headings, twice under a heading that promises something else · P1 · Observed

Evidence: a single five-row run table — Discover Android devices, Android Maestro dev-login smoke, Workspace doctor twice, Discover Apple devices — is the body of devtools/pipeline, devtools/releases, devtools/recorder, devtools/traces and devtools/logs, and the same rows fill the bottom dock's run ledger in every mode. Two of those headings promise something the table is not: devtools/traces titles it "Port invocations · waterfall", and devtools/logs titles it "Live stream · every runtime, one timeline". Cloud repeats the pattern at a different scale: cloud/deploy and cloud/pipeline render byte-identical bodies (the "ORDERS DISAGREE" block plus Deploy order · 21). auth/simulator is a strict subset of auth/security — the same permission-simulator panel with the posture list removed. agent/audit and agent/runbooks both render a panel headed "Audit log · every actor, every command".

Required fix: a subpane that has no projection of its own must render its SubpaneSpec card, not a neighbour's table under a borrowed heading. Where two subpanes genuinely share a body, merge them. Acceptance: no two subpanes in a family render the same component with the same data, and no panel heading names a visualisation the pane does not draw.

CO27 — Panes are authored to fill a quarter of their height · P1 · Measured

Evidence: measured over all 74 sheets from MachineSignalSubpaneRenderTest (1180 × 840 each), the median pane paints content down to 25.4% of its height and covers 1.5% of its area in non-background pixels. Thirty-five of 74 fill under a quarter; 57 of 74 fill under 40%. There is a hard floor at 19.6% — breadcrumb, subtab row, one panel header — and only six panes clear 60%: cloud-operations 84.5%, agent-chat 76.8%, cloud-deploy 76.7%, database-query 74.4%, ai-models 70.0%, analytics-performance 66.4%. The full table is in the pane sweep below. This is a layout property, not only a data property: the panes place two or three cards in a top band and leave the remaining three quarters of a 1568-point window empty, so even a fully wired pane inherits the shape.

Required fix: give each pane a layout that grows with its content — the anatomy kit in panes/PaneAnatomy.kt already has the parts — and treat a pane whose authored layout cannot reach the fold as a design defect rather than a data gap. Acceptance: median vertical fill across the 74 sheets rises above 60% with the same snapshot, and no pane's authored layout stops before half the viewport.

CO28 — The coverage metric measures wiring, not what the pane shows · P2 · Observed

Evidence: reportPaneCoverage prints ui 0/8 and ai 0/12, but in the running window the AI mode shows 32 resources, 11 operations and 5 runs — real per-worker Cloudflare AI bindings — and the UI mode shows a live component canvas with the entity-hue palette and a metrics strip reading 253 resources / 483 tasks / 30 runs. Both render through the generic evidence-and-operations path rather than through a SubpaneReads entry, so the gate cannot see them. The converse also holds: devtools/source counts as wired solely because SubpaneReads maps it to the workspace domain, while the pane renders "Files | Source" with Source empty and Files reading "Turns on with: a source index keyed by graph node id". The number is therefore neither an upper nor a lower bound on what a user sees.

Required fix: report two numbers — subpanes with a declared SubpaneReads slice, and subpanes that paint a non-empty body against the live snapshot — and never quote the first alone. Acceptance: the coverage report distinguishes "wired to a named slice" from "renders content", and devtools/source appears in the second column only once it renders source.

Competing vocabularies at a glance

What resolves the CO family

Most CO issues share five causes, which the architecture changes below address from the implementation side; the design side needs the same discipline in the source file. One shell contract checked per board (CO01–CO04, CO14, CO24); one object model with one identifier grammar and one written fixture ledger that every number, name and revision is drawn from (CO06–CO12, CO20, CO21); one IA that the entrance mirrors and one command registry that chips are instanced from (CO01, CO15, CO23); one provenance register and one colour and type ramp enforced by the component library (CO16–CO19); and states instead of slides, with failure that changes the chrome (CO04, CO05). Retiring shell A, shell B and the template clones removes most of the noise without losing any requirement, provided the unique requirements listed under CO22 are carried into documents or merged boards first.

Order of work

Historical issue-family ordering follows. The current P0 workflow queue above supersedes sequencing: graph, auth, database, DevTools, compute/cloud and MCP are worked toward completed BestBuds developer flows before supporting polish.

Band 0 · The window — do these first

W01, W02 and W03 were one change seen from three sides and they have landed: the four pillars now share one shell over one application, and bands 1–4 ship into code the window actually mounts. W05 remains open. With the panes mounted, one remaining reason the four pillars do not read as one tool is that each pane still brings its own navigator and its own header grammar.

Band 0.5 · The three planes

Does this help a BestBuds developer ship? establishes that the four pillars are short of three things, and that every pane below gets more valuable once they exist. These outrank the per-pillar items that follow them.

Band 1 · Graph

Band 2 · Database

Band 3 · Auth

Band 4 · Device tools

Band 5 · One vocabulary the four pillars inherit

Ordered by how much of bands 1–4 each unblocks, not by how visible it is.

Band 6 · Supporting surfaces

Cloud C01–C03, delivery R01–R02, observability O01–O02, agent and AI AI01–AI03, module composition L01. All real, all after the four pillars.

Band 7 · Qualification, accessibility and polish

Accessibility and failure qualification Q01–Q11 (Q01, Q02, Q03, Q07 first — keyboard, focus, canvas semantics and empty/error states are the ones the four pillars will need as they are built). Remaining visual items V03, V04, V07, V08, V10. Then V01, exact Pencil raster parity.

V01 is deliberately last, and that reverses an earlier "visual fidelity first" instruction. The reason is in this document: CO01–CO24 establish that the boards contradict each other on identifiers, counts, revisions, provenance, colour and scale. Reaching zero differing pixels against that set would lock the contradictions into the product and would have to be redone after band 5. The recommendation is to keep the exact-comparison harness running as a regression signal and to restore V01 as an acceptance gate once the boards are one design. If the owner wants pixel parity kept at the top regardless, that is a one-line change here — it is a sequencing decision, not a finding.

Architecture changes that resolve several issues together

One persistent workbench context

Promote workspace, source revision, environment, principal, selection, time and active mission/run into one typed context with explicit linked and pinned fields. Every document and tool declares what it follows. This resolves context drift across Graph, Data, Auth, UI Preview, Cloud and Evidence without coupling all panes to one arbitrary active tab.

One command registry with visible availability

Each action declares a stable ID, label, shortcut, arguments, target scope, availability/reason, effect category and completion/evidence contract. Human menus, command search, toolbars and agents use that registry. Unavailable commands remain discoverable with their prerequisites. Do not implement generic “success” for unconnected commands.

One document and docking model

Represent source, graph views, queries, traces and plans as typed documents with identity, dirty/pinned state and supported actions. Tools remain dockable projections over context. The source design then defines composition and presentation rather than standing in for the document lifecycle.

Responsive policies above the layout kernel

Keep the shared flexible-layout machinery small. Product-level policies decide minimum readable widths, docking priorities and optional secondary panels. The kernel should not infer whether a card's text is a critical auth result or decorative metadata. Give code, identifiers, evidence and decision chains appropriate overflow behavior.

Graph interaction as the common foundation

Connect real graph selection, scopes, layers, traversal, source identity, runtime activation and typed changes before multiplying new operational panes. The same mechanism should power UI inspection, headless workflows, data lineage, provider placement, auth explanations and agent proposals.

The source plane is a projection, not an embedded editor

Decision, 8 September. P02 is answered by an annotated read-only source projection with a language server behind it, not by embedding a web editor. Editing is allowed, bounded to a region, and leaves as a patch rather than as a write.

Why not Monaco. The desktop surface is Compose/Skia and the editor chrome is already native: render/compose/shell/ReaktorEditorChrome.kt implements the design's MG56E, and ReaktorEditorChromeGeometryTest locks its geometry. Monaco requires a browser embed (JCEF/KCEF) — a second process carrying its own input, IME, font and theme stack, 150–250 MB of runtime, and a pane that no longer renders under GoldenImage.render / ImageComposeScene, which is the mechanism every visual claim in this document rests on. Monaco also ships the VS Code keymap, so it does not return a JetBrains user's shortcuts; only the handoff below does that. Neither repository contains Monaco, CodeMirror or a CEF binding today.

What the design actually authors. Source appears as five- to ten-line excerpts, one text node per line at 12 px / 1.3, read-only, on Mmo0o, w4EWt, izozd and aPU6J. The value is in the marks around the line — the port it implements, its effect class, its truth and freshness, the graph node it binds to. That is a projection over a document, not a document.

The language server is not blocked on an editor. Semantic tokens, hover, go-to-definition, find references, diagnostics, inlay hints, document symbols and code lens all operate on a read-only buffer, and semantic tokens remove any need for a hand-written highlighter. Only completion, signature help, rename, quick-fixes and formatting need an editable buffer, and those stay scoped to the open region.

Where it lands. Two subpanes already author it: devtools/source ("The source behind the selected node or frame", needing a source index keyed by graph node id) and ui/source-diff ("The source behind the selected component", needing a source index keyed by composable name). devtools/source counts as wired only because SubpaneReads maps it to the workspace domain; it does not render source.

The escape hatch is missing, and it is the cheapest item here. The panes already offer "Open in source" three times and "Open rule and call site" once. Neither repository contains an idea://, vscode:// or equivalent handler, so none of those affordances can do anything. Wiring idea://open?file=…&line=…, vscode://file/…:line and an $EDITOR fallback is what returns a developer's own keymap, plugins and refactoring for everything past a minor edit — and it fixes the boundary the edit affordance must not cross.

Bounds on the edit affordance. A contiguous region, opened in place at the projection's own metrics; refused when the working copy has moved since the projection was taken; carrying the Local Write effect class the design already defines (k4qdzd); committed as a scoped patch through the review path 04.08 · Commit and semantic patch review already authors, never as a silent write. New files, rename and multi-file edits escalate to the handoff.

Order. The read-only projection with semantic tokens, hover and diagnostics first — that is most of P02's value. The deep links second; they are small and they set the boundary. The editable region and commit-as-patch third. Monaco only if a browser-only editing story is ever needed, and then in the React surface (render/react/panels) where it is native and costs nothing — never inside Compose.

Acceptance: devtools/source opens a file at a line from a graph selection and renders it with gutter marks and language-server diagnostics; "Open in source" launches the configured editor at that file and line; an in-region edit produces a reviewable patch and changes no file on disk until it is applied; the pane renders under the existing golden-image harness.

Acceptance journeys

Implementation ownership and order

The band order in Order of work governs sequencing; this table only says who owns each package. Prioritize shared causes over one-off board patches. A command registry fixes dozens of silent controls; a persistent context fixes repeated identity drift; a docking contract fixes repeated resize problems. Preserve the two-developer team's ability to qualify bounded slices without implying that the entire atlas is already operational.

Verification record

Full pane sweep · 8 September

Every one of the 74 authored subpanes was inspected, by two methods that check each other. All thirteen modes were driven in the running desktop window over an accessibility bridge — mode rail, subtab strips, breadcrumbs read back per capture — covering roughly fifty subpanes live. The remaining coverage, and the measurement below, comes from the project's own oracle: MachineSignalSubpaneRenderTest writes one 1180 × 840 sheet per authored subpane to modules/engine/build/reports/machinesignal-panes/, and that directory holds exactly 74 files whose names are precisely the catalog's family/id pairs. Where the two disagree the live window is the authority, because the harness renders with an empty operational snapshot: Cloud, Database, Deploy, Testing, AI and UI all carry real data in the window and none in the sheet. For the unwired subpanes the two agree exactly, because both render the same SubpaneSpec card.

What the live walk found that the sheets cannot show: Database runs a real Cypher statement against production Memgraph and returns real label counts (Chapter 3433, ChapterEdge 3853, Resource 321, Tenant 1) with 1 of 18 connections live; database/history holds 18 real queries with per-query durations from 53 ms to 754 ms; database/relationships lists 89 foreign keys — but reads them from the Postgres/heimdall schema while the selected connection is Memgraph, a graph store with no foreign keys; database/migrations reads 22 checked-in SQL files and states that applied state is not observed. Cloud reads 21 workers, 51 elements and 80 bindings from the repository's own wrangler and k3s configuration, and cloud/pipeline renders C04 live — "ORDERS DISAGREE", the documented deploy order against the order the service bindings require. Deploy exposes 78 operations behind 68 gates with real effect classes; Testing exposes 189 harness operations with their exact gradle and npm command lines. devtools/preview renders the actual BestBuds onboarding screen as a live Compose composition with a semantics tree. Auth is honest and nearly empty: two provider adapters read from source, "No AuthContextProvider is bound, so there are no effective grants to read", and a Roles & Permissions pane that is a credential-gated Postgres reader naming the six environment variables it needs.

Fill measurement, all 74 sheets. Vertical fill is the fraction of the sheet's height above the last row containing content; ink is the fraction of sampled pixels differing from the background. This is the evidence behind CO27.

Median vertical fill 25.4%, mean 33.1%, range 19.6%–84.5%. Median ink coverage 1.57%. Panes filling under a quarter of their height: 35 of 74. Under 40%: 57 of 74.

Perspectives pass · 8 September

The same sweep, read as six different users. These are readings of what the window affords, not new defects; each one points at issues already numbered above.

• Reaktor contributor. Best served. The graph carries 172 nodes and 153 edges with typed ports, an inspector spanning identity/ports/source/runtime/telemetry, and an explicit provenance line ("Origin: local Graph instance · Remote execution: not observed"). Testing and Deploy together are a real command plane. The irritant is CO26: six panes show him the same five runs, and the bottom dock's Traces, Tests and Build counters sit at zero in every mode.
• BestBuds developer. Three tools work — Cloud topology, the Memgraph query, the live Compose preview — and then the surface stops. Seventeen of eighteen database connections are disconnected, the device lab reports "Adb: not refreshed / Simctl: not refreshed / Idb: not refreshed", and the two artifacts he would actually ship, the Android release bundle and the web distribution, both read FAILED with "Expected build output is absent". He uses it to find a command, then leaves. This is P03 and P01.
• Vibe coder. Worst fit, and CO27 is why: the median pane is three-quarters empty, and every empty state is addressed to the implementer — "Turns on with: a ClickHouse analytics read; the events table is already partitioned for it" tells him nothing he can act on. With no source plane (P02) there is no way to do the one thing he came for.
• Product manager. Nothing usable. Analytics KPIs render "—"; funnels, cohorts, retention, experiments and reports are stub cards; Telemetry offers Grafana "configuration discovered; live signal freshness is not queried". The app never claims otherwise, which is to its credit, but a PM learns only that the plumbing exists.
• CTO. The strongest case in the building, and it is measurable: cloud-operations and cloud-deploy are the two fullest panes in the file. Every operation carries an effect class — LocateArtifactWrite, ProductionReversibleWrite, DeviceWrite, Destructive — with a gate and a receipt, and dangerous ones are refused with a reason ("Production distribution is disabled until its app artifact/source closure is sealed"). Cloud→Pipeline catches a real contradiction in the repository. The gap he names immediately is reconciliation: "deployed state is not observed", "authenticated Cloudflare version reconciliation is not queried yet". It governs intent, not reality.
• Big-tech developer. Two things read as unfinished on first launch. The application draws its own menu bar inside the window — File through Help are in-window buttons and the macOS menu bar carries only Apple and Reaktor — which on macOS reads as a port rather than a native app. And CO27's density collapse is the first visual impression, regardless of how honest the empty states are. He also finds Diagnostics 220 in the status bar with no route to those 220 items.

Pane inventory pass · 8 September

MachineSignalPaneCoverageTest now passes all eight of its tests, so W06 is closed on both sides: the app's mode labels and the design's mode tabs agree. reportPaneCoverage prints 31 of 74 subpanes rendering real data across the nine authored families — unchanged in total since the discovery pass — but the per-family split is where the gap actually sits.

Two families are complete and two report zero — but see CO28: ui and ai render live data through the generic evidence path, so the zero measures the absence of a SubpaneReads entry, not an empty pane. The 43 pending subpanes each name their own blocker in WorkbenchSubpanes, and three name nothing — they are one projection away from data the workspace already holds: agent/audit and cloud/runs render from the run ledger as soon as runs exist, and auth/security renders source-derived findings the pane already computes. Those are the cheapest coverage in the file.

The number is derived rather than asserted: backedByRealData is SubpaneReads.keys plus the two DevTools subpanes the shell routes to dedicated panes, so a subpane cannot be claimed as wired while showing nothing on screen.

One piece of dead code surfaced while reading: shell/WorkbenchModePanes.kt defines ReaktorModePaneUnavailable — the "states what is missing instead of drawing the tool that is missing" fallback — and nothing calls it. Every mode now maps to a pane, so the branch it was written for no longer exists. Delete it or give it a caller; a fallback that cannot be reached is not a safety net.

Pane anatomy pass · 8 September

:engine:jvmTest runs 249 tests and :reaktorDesktop:test runs 35. The pre-existing pair still fails, and the database tab-contract test was rewritten rather than patched: it now asserts the strip is the authored subpane list, so a rename in reaktor.pen fails the build instead of drifting quietly.

Renders are in machinesignal-shell/. Auth's security posture reads seven checks off the real BestBuds graph and the reaktor-auth checkout, finds one high-risk item — no AuthContextProvider is bound — and the simulator correctly reports that it has nothing to decide with rather than showing an invented verdict. Data now carries the seven authored subpanes over the same 18 discovered connections.

Pane routing pass · 8 September

:engine:jvmTest runs 249 tests and :reaktorDesktop:test runs 35. Everything passes except the same two pre-existing engine failures, one of which is W06 itself. The desktop suite is the meaningful gate here, because it drives the real window: ReaktorWorkbenchSmokeTest opens all twelve non-graph modes as panes inside the shell and then all twelve again as references from the surface chooser, asserting on each pass that the operational control plane is untouched and the mounted graph is not rebuilt; NewWorkbenchIntegrationTest checks that graph selection, search text, layer state and camera zoom survive every mode switch, and that Back and Forward still work across panes, references and the live graph.

Two desktop tests that had been failing on window focus before the recorded repairs — AstraStudioNavigationTest and TypedGraphPointerTest — now pass; they were flaky rather than broken.

One implementation detail worth keeping: two testTags on one modifier chain overwrite each other, so the mode slot is tagged on the slot and the pane keeps its own tag. The first version of this change silently lost database-studio.

Discovery pass · 8 September

This pass added no product code. It added one test — WorkbenchShellRenderTest.thePriorityModesRenderAtTheSupportedWindowSizes, which renders the four pillar modes at 1024 × 720 and 3360 × 1418 — and read the running window, the pane package and the design file's pane contract. Its claims are checkable in this order:

• W01 — Workbench.kt composes the graph editor when the destination is the application graph and ReaktorDesignWorkspace(boardId) otherwise. ReaktorWorkbench, the window entry, delegates to the same ReaktorWorkbenchContent, so the sheets are the product.
• W02 — grep every composable in render/compose/panes/ for callers outside that package: ReaktorCommandPalette, ReaktorWorkbenchBottomDrawer, ReaktorEditorDrawerStrip, ReaktorInspectionComposerProbe and one table helper are referenced; nothing else is.
• W03, W04, W05, GR03, GR04 — read the eight shell sheets side by side.
• W06, GR08, DB06, AU05, DT05 — src/jvmTest/resources/machinesignal/pen-truth.json → panes, against ReaktorMode.entries and WorkbenchPaneCatalog.families.
• X01 — measure the last painted row of each sheet in machinesignal-panes/.
• 31/74 — MachineSignalPaneCoverageTest.reportPaneCoverage prints it.

Two engine tests were already failing before this session and still are; both are now findings rather than noise. MachineSignalPaneCoverageTest.everyAuthoredModeTabHasAWorkbenchMode is W06 — it fails because reaktor.pen authors DevTools and Database while the app ships Develop and Data. EngineArchitectureTest.composeRendererUsesLayeredPackagesAndSmallFiles names three oversized renderer files (graph/ReaktorGraphWorkspace.kt 737 lines, panes/BottomDrawer.kt 644, panes/DevToolsPreview.kt 545), none of which this session edited.

Compact-layout pass · 8 September

:engine:jvmTest runs 248 tests. Every studio, workbench, layout, navigation, host-parity and pinned-shell test passes, including the five new compact-layout tests. Two failures remained at that historical checkpoint and were subsequently repaired in F37/F44: EngineArchitectureTest.composeRendererUsesLayeredPackagesAndSmallFiles reports three oversized renderer files (graph/ReaktorGraphWorkspace.kt, panes/DevToolsPreview.kt, panes/BottomDrawer.kt, none touched here), and MachineSignalPaneCoverageTest.everyAuthoredModeTabHasAWorkbenchMode reports two authored mode tabs — DevTools and Database — that the workbench has no mode for. :reaktor-ui:jvmTest passes, with two new kernel tests for the content floor.

The compression-only change is supported by comparison with the previous rendering: all eleven ultrawide captures at 3360 × 1418 differ by zero pixels, while the narrow captures change by 10–20 % on the four boards the audit named (Devices 19.6 %, Cloud 17.3 %, AI 14.0 %, Auth 10.5 %) and by 0.7–2 % elsewhere, which is the newly visible scrollbar. Exact host parity at the authored viewport is unchanged. Before and after captures are preserved under reaktor-context/compose-parity/ui-fixes-2026-09-08/.

Both behavioural compact-layout tests were confirmed to fail with the policy disabled, so they measure the fix rather than describing it.

Previous pass

The final focused run passed 28 native engine tests, five desktop tests and ten shared framework tests: 43 tests, zero failures. It includes actual desktop navigation, keyboard/picker behavior, native pointer input, graph state, exact icon coverage, native host parity and pinned-shell scrolling. Intermediate failures exposed a fixed-height source constraint in nine boards and a test that dispatched a pointer press before the preceding hover/layout frame had settled; the final pointer test exercises the visible settled target and retains the negative close-click assertions.

The seven-board host comparison passes exact decoded RGBA equality against the native board and an independent repeated host render. All 122 native board trees retain exact authored bounds, including intended overflow. These results validate the integration contract, not Pencil-reference raster acceptance.

The current 122-board Pencil run renders every board deterministically at matching dimensions, with zero capture errors. 0/122 pass exact RGBA comparison: 26,023,445 of 235,914,033 compared pixels differ; weighted mean absolute channel delta is 1.074828/255. The suite has changed from the previous 118-board oracle, so these totals are not a like-for-like trend claim. Per-board masks, heatmaps and hashes are in the pencil-comparison evidence directory. The application remains visually unqualified against the requested 100% requirement.

What this audit does not claim

• That all 122 authored boards are operational applications.
• That a containment pass proves absence of sibling or wire/text collisions.
• That a screenshot proves cloud discovery, execution, database access or authority.
• That keyboard, screen-reader, scale, performance or recovery qualification is complete.
• That every possible UI/UX issue has been discovered.

The inventory is complete with respect to the source catalog listed below; the coverage labels make the depth of inspection explicit. New failures belong in this document with evidence and stable issue IDs.

Full board coverage ledger

Every board below was included in the structural source census. Native resized review means a narrow and ultrawide capture was generated and reviewed for the issue classes described above. Other boards have source-level coverage and inherit applicable shared findings; they have not received a claim of exhaustive native interaction testing. Retained references and libraries remain accessible through the atlas and design navigator.