Reaktor Graph Navigation, Layers and Live Views

Reaktor's graph workspace must make a complete application composable at every useful scale. A developer can begin with a product feature, inspect its UI and services, open an actor or native computation, choose a cloud binding, compare a trace with source, then return to the whole feature without losing context.

The foundation is one heterogeneous, nested, multilayer Living Graph. Hierarchy provides orientation; semantic layers explain different relationships. Source, Blueprint, deployment, table, trace and preview editors project that same identity fabric. No screen requires loading or drawing the entire system.

1. The problem: retain the whole system without flattening it

Graph.parentGraph, nested ContainerNode graphs, architecture scopes, ports, services and source imports already provide useful structure. A recursively expanded canvas loses that structure as a system grows. The opposite failure is to divide UI, runtime, data, providers and agents into unrelated dashboards that cannot compose a feature together.

The workspace exposes a continuous whole-system map. Its starting camera can frame the whole project or the selected feature while retaining wider context. It supports local editing and cross-scope queries without forcing a new page, a scope switch or a change of product mode. Actors are one semantic family, not the organizing principle of every view. A provider resource may be a selected authority domain without being an executable application process.

The user should be able to answer “what participates in this feature?”, “which interface can I compose here?”, “what does this invocation do?” and “what changes if I choose another implementation?” using related views of the same entities.

2. Architectural levels are useful presets

The C4 model provides architectural abstractions for system context, containers, components and code. Reaktor borrows their explanatory purpose while adding source editing, executable profiles, observations and commands.

A C4-style preset chooses a useful initial scope and detail. It is not a fixed ownership taxonomy for every domain, a semantic layer or a restriction that every resource fit four levels. A feature may cross several runtime islands; a database, bucket and remote SaaS have distinct authority and execution meanings.

Navigation changes the projection. Extracting a component, changing a binding or introducing an actor boundary changes the program and therefore uses a semantic command with an owned source delta. A menu label such as “Collapse” must never do both silently.

3. Scope and detail presets

These presets are entry points over one logical graph. Developers can save their own queries and perspectives.

Zoom from the whole application to a port

The primary graph behaves like one navigable map. Start with the entire authorized application/fleet, zoom toward a runtime island, reveal a feature, then a node, port and concrete invocation. Camera movement is continuous; component detail may change at stable scale bands. The bands below are useful defaults, not separate screens or hard limits on depth.

Zoom uses indexed summaries and progressive detail without making the developer navigate through a sequence of pages. A scope control separately narrows query/work budget; it does not have to change when the camera crosses a region boundary. Pin a detail level if automatic expansion is distracting. Use hysteresis and stable anchors to avoid cards flickering or jumping between representations; reducing motion must preserve orientation and selection.

A selected route remains visible at every scale. Distant sections become exact boundary summaries, not discarded paths. Off-screen, unloaded and filtered route segments have navigable indicators with known membership and coverage. Back/Forward restores the camera, layers, route, time and linked source selection together. “Focus selection” moves the camera deliberately; an incoming trace or agent update must not repeatedly steal the user's view.

The system map: four linked states over one graph

The distributed system map and its three companion states — runtime district, feature and boundary and exact port with a selected execution — are one viewport at four scales, not four diagrams. Every state keeps the same fixture (Fieldwork definition G42, recorded activation local/7, route R-CAP · capture → publish), the same port identifiers (p40 … p141) and the same shell. Only scope, detail and camera change.

A district is a grouping projection over runtime/provider domains; it is not a new node, and a feature can span several districts. A corridor is a bundle of member relations between districts; it renders as one road with a member count and resolves, on selection, to its exact source and destination ports. Portals are the boundary ports where a route enters or leaves a scope; a wire never terminates on a container edge. Offscreen continuations name the members that leave the viewport. Placement defaults to logical topology; physical geography is an optional overlay that needs location evidence, and no coordinates are invented for Workers, Durable Objects or managed services.

Roads keep their class at every scale. The road grammar (in-process value, state observation, ServiceAPI request/result/error, actor mailbox, FFI call/stream, Bus publication/queue, Work handoff, Mesh session, data write/derived projection, build/activation) is specified in Visual Language; the map legend component reproduces it without relying on colour alone. A route is shown in one of four modes — declared, candidate (Δ44), simulated, correlated (local/7) — and a correlated segment ends at the observation cursor: beyond it the road is drawn as unknown, never as traffic.

Map viewport instrument and explain view

One reusable viewport instrument underlies every map state: a breadcrumb trail (estate › district › feature › port), an explain chip with visible / scoped / known / unknown counts, reveal search, Frame all, Frame route, Keep camera, Follow selection, view history and saved cameras in the top strip; a minimap, zoom cluster and a scale bar with the four bands beside the map. Entering a scope narrows the query and work budget; it never moves the camera unless a frame command is used. Enter zooms into the selection, Esc returns to the parent with the previous camera restored, ⇧F frames everything, F frames the route.

Explain view answers why the map shows what it shows. It lists the ordered query stack (scope → structure and contracts → route filter → expansion → decoration), the input and output counts of each step, folded and omitted members with their witness paths, the budget and truncation, and the state of everything that is not drawn: hidden by a layer, not loaded, stale, inaccessible or unknown. Filtering before expansion can differ from expanding before filtering, so the order is shown rather than implied. Turning a visual layer off changes the view only; the program, its effects and its policy enforcement are unchanged. Restricted names and counts are excluded from the denominators rather than leaked through aggregates.

Select and save routes through the system

A named graph route can represent Capture intent, Upload/send, Completion/return, Notification delivery or Analytics projection. Its definition is a typed relationship query over the Living Graph. It can branch, loop or wait according to its selected profile. UI navigation routes remain their own relation type; “route” in this instrument does not convert every relationship into a router edge.

Select a route from the explorer, a wire, a UI element or a finding. Highlight its member ports/edges, dim unrelated detail, retain significant alternatives and show why each segment is included. The route bar exposes the entry event, selected branch, artifact/activation and mode: declared, fixture/simulated, recorded or live. Branch chips can follow send, return, error/retry, notification or analytics without replacing the graph.

A folded service, actor, native component or resource region has explicit route entry/exit portals. Every portal maps to true internal endpoints and exact member relationships. Multiple entry/exit mappings remain inspectable; geometry cannot invent a cross-boundary call. The same relation system can navigate a local call, FFI exchange, service request, mailbox admission and event projection while displaying their different protocol/cancellation/completion contracts.

“Follow execution” follows one causal instance using its events and correlation evidence. It is different from highlighting a possible static flow. Missing spans, independent clocks, fan-out, retries and incomplete downstream observations remain visible. A return path or notification branch can remain unknown even when the originating handler completed successfully.

L0: Product landscape

Show the participating apps, services, major modules, providers, data authorities and user-facing features. Relationships can include selected service bindings, UI journeys, delivery closure and evidence. A whole-system feature view may deliberately cross ownership trees rather than render the root of one tree.

Useful actions include selecting a feature/capability, composing a module, comparing placement strategies, showing consumers and opening a particular source or runtime scope. Do not fill the default view with every function or observation event.

L1: Runtime island or authority domain

Show an executable/deployable boundary such as a mobile app, Worker, JVM process or native library, or an explicitly labeled resource authority such as Postgres or R2. A resource authority is not automatically a runtime scheduler.

Expose its major child scopes, exported/consumed interfaces, selected bindings, artifact revision, deployment observations and supported tools. Several activations can realize one definition. Selecting an island definition must not imply every instance is running the same revision.

L2: Graph scope or reusable composition

Show the selected module, feature composition, actor group, route group or nested component, with direct members and relevant cross-boundary relationships. Render deeper owned scopes as summaries unless expanded. Keep dependency, feature membership and ownership relations distinguishable.

Useful work includes composition, extraction, selecting an implementation, inspecting capability demands and tracing impact. A query can expand a sibling or remote endpoint without transferring its ownership into this scope.

L3: Component behavior and interfaces

Expose typed ports, function/operation calls, actor messages, state transitions, stream readiness, native boundaries and selected execution data. Multiple semantic layers can remain visible. A pure function's data dependency and an effectful request's completion protocol are different instruments.

This is where drag-from-port creation, field mappings, loop/feedback diagnostics, extraction, watches and source-linked findings become precise. Code remains a peer editor for arbitrary Kotlin or foreign implementations.

L4: Source, operation or execution detail

Open source, schema, input/output, a protocol table, operation configuration, trace, profile or evidence in an editor group or detail tool window. Detail does not require leaving the graph, nor must it be squeezed into a small inspector.

A source editor can follow the working copy while a trace remains pinned to artifact revision, activation and recorded time. Comparing them is useful; silently treating them as the same execution is not.

4. Scope, layers, time and mode are separate

A scope reference uses canonical identity. Source path and display breadcrumb are navigation metadata; renaming or moving an entity should not destroy its identity or saved view. An owner can supply remapping when extraction/splitting changes that correspondence.

The following is an illustrative view-state shape, not a frozen public API:

data class GraphViewState(
    val scope: ScopeRef,
    val detail: DetailPreset,
    val layers: List<LayerQueryStep>, // ordered, composable and individually inspectable
    val context: GraphContextRef,    // revision vector, activation/run and time mode
    val mode: EditorMode,
    val selection: Set<EntityRef>,  // nodes, ports, relations, resources, UI instances, evidence
    val expandedScopes: Set<ScopeRef>,
    val externalEdges: ExternalEdgeMode,
    val layout: WorkspaceLayoutRef
)

The dimensions mean different things:

A layer stack is a reproducible query/view program: select relations, filter, expand, group, derive and style. Some operations commute; others do not. Filtering to one module before impact expansion can omit external consumers that expansion-before-filter would reveal. The inspector explains the actual order, scope, omitted regions, revision/time vector and coverage.

Deep links and saved workspaces serialize these settings by stable reference. A target default applies to editors that follow it; a pinned editor remains pinned. If a requested revision or observer is unavailable, the view reports that state rather than silently substituting current data.

5. Hierarchical view documents are projections

ReaktorFlowGraph and any HierarchicalGraphDocument are derived exchange/read models, not separately authoritative semantic graphs. They may cache scoped entity references, exact relation endpoints, summaries, operation descriptors and render hints from the Living Graph. They identify the query, revision vector, coverage and derivation that produced them.

The existing GraphDocument persistence format also has real consumers and local editing behavior. Integration should preserve compatible documents through explicit adapters and source ownership; it must not silently declare every saved canvas to be an executable system definition.

A view builder takes a snapshot/query result plus GraphViewState and produces a scene. The scene maps every actionable card, pin, wire, summary and finding back to its canonical references or an explicitly view-only identity. Rendering cannot invent semantic edges from proximity, similar labels or matching color.

Every edit has either a supported inverse mapping to its owning source grammar, a typed semantic command or a view-only command. An inferred arbitrary-source graph may offer source navigation and a reviewable source patch rather than a purported lossless direct edit. See source ownership and graph sources.

6. Rendering and incremental update rules

Render authorized direct members and selected related context. Represent deeper regions through summaries and exact boundary mappings. Preserve canonical identity across detail changes. Keep position, ordering, viewport and visual grouping out of executable semantics.

An incremental graph patch updates affected render elements, findings and summaries. Preserve unaffected positions, selected ports, open tools, expanded scopes and the user's focus. New evidence should not trigger a global layout. Auto-layout remains explicit or constrained to the changed region; manual pins survive where valid. Deleted or remapped selections explain what changed and offer the related source delta.

Child scope summaries

A useful summary exposes its title, kind/owner, exported interface and the most relevant findings for the active layers. Counts state their authorized domain and coverage. “3 visible consumers” is different from a verified complete count of all consumers. Hidden or redacted objects must not leak through aggregate labels.

A folded reusable component retains separate definition and call-site identity. Observed state is scoped to an activation/invocation; a summary must not display one global “live value” for every instance of a definition. Warnings, stale observations, missing coverage and proposed changes remain distinguishable.

Boundary portals and bundles

Cross-scope relations terminate visually at explicit portals or folded boundary ports. A portal preserves the true endpoint identity and the exported-to-internal mapping; it does not create a new application port simply for display.

A bundle stores its exact member relation IDs, endpoint roles and derivation. Selecting it opens the members and their contract/protocol details. Navigation can open either endpoint, explain why it appears, inspect callers/providers or expand the related region. Folding and expanding must preserve the logical relationship set and its witnesses.

This distinction is especially important for an edge that crosses several kinds of boundary: a service request may cross source ownership, runtime process, auth and deployment, while a telemetry relation observes it. One thick line must not collapse all those meanings into a guaranteed call.

Layout strategies

Hierarchical layout must distinguish the inclusion tree from cross-node relations. ELK's graph model separates hierarchy and edges, and ELK Layered offers port/hierarchy options useful to evaluate. ELK is a candidate adapter, not an adopted Reaktor dependency or guarantee. Whatever layout engine is chosen, moving nodes cannot change execution order, wiring or ownership.

Scope queries, expansion, layout and render work each have budgets and cancellation. Use indexed/paged retrieval and visible work limits for large graphs. Benchmarks should include dense interfaces, cyclic behavior, cross-scope edges, many activations and live updates, not just a wide static DAG.

Dense application topology with mixed detail

The BestBuds application topology workspace improves the real application's fully expanded graph view. Shared Root composition, Chat, Campaign, Discover, Events, Friends, Profile, Palette, Dev and the independent design prototype remain recognizable. The selected Onboarding dependencies expose exact pins; other regions retain summaries and named continuations. A developer can expand Chat beside Onboarding without expanding every feature to the same depth.

Hierarchy determines which owned regions are folded; node categories determine which families are selected; layers determine which relationships are interpreted; density and detail determine their representation. These controls remain independent. All is an available recursive inspection preset, while Mixed preserves local detail choices. Neither should turn the whole application into uniformly tiny cards. Minimum readable labels, expandable port lists, stable region anchors, exact bundles and a synchronized outline make high density useful. Frame all, Frame selection and Keep camera give the developer deliberate control when the query changes.

7. Service and FFI boundaries connect the system

Moved. How a boundary is established across runtimes — and the full list of what selecting one must reveal — now lives in Reaktor Graph Protocol §2, with the rest of the connection model: switches, trunks, the HELLO handshake and the rule that matching contracts identify candidates while only a selected binding or a qualified observation establishes an actual route.

What remains a view concern, and stays here: the landscape summarizes a boundary as a relation between domains, while the component editor reveals exact ports and operation details. A line through a native boundary must not be drawn as though it promises zero-copy, cancellation propagation or memory safety unless the adapter and evidence establish it. See also Living Graph boundaries.

8. Native, imported and observed facts share the model

Provenance, coverage, source ownership, freshness and command authority are orthogonal. They should be available on selection without turning every card into a wall of badges.

A scanned node can expose a verified, authorized edit adapter; a native node can be read-only under current grants or lack a handler. “Unknown” provider state remains unknown. The current configuration-only Wrangler inventory must not look like a successful live health check.

9. Persistent super-IDE interaction contract

The graph lives in a persistent multi-editor shell with project/symbol explorer, source/graph/preview tabs, breadcrumbs, context details, command search and tool windows. Six tool categories/perspectives organize access; they are not mutually exclusive full-page modes. Conductor docks beside the selected work and attaches exact graph/source/evidence context.

The developer can:

1. Select a feature in Project/System Explorer and see its connected UI, capability, behavior, native, provider, data and evidence relationships.
2. Add or reorder semantic layers while keeping the scope and selected source revision.
3. Open a nested composition, source declaration or concrete invocation in another editor; use Back/Forward to restore the previous selection and viewport.
4. Create from a typed port, insert an adapter, map fields or extract a reusable definition through the same commands available to an agent.
5. Inspect a capability/placement alternative as a graph and source delta, including the UI fallback, FFI boundary, provider resources and affected checks.
6. Run a selection with declared prerequisites and fixtures; inspect input/output, waits, failures, profiles and concrete effect outcomes.
7. Compare a recorded run with the working copy, repair a failure, run affected checks and follow the exact artifact to the delivery tools.

The graph is keyboard navigable through a synchronized outline/table representation, named ports and search. Expand/collapse, create compatible, open source, inspect binding, run checks and attach context need keyboard commands. Labels, icons and patterns complement color. Reduced-motion mode avoids decorative pulses; animation reports real observed activity only.

The real application view: topology, behavior and execution

The whole-application topology and selection across tools are complementary design states grounded in the actual BestBuds implementation. They specify how existing application surfaces should cooperate; they do not report that the integrated workflow already runs.

Three instruments must stay distinguishable even when shown together:

The current desktop's Source only control disables the operations overlay over a constructed local graph instance. Its label must not imply static source extraction. The proposed context ribbon identifies application topology origin, examined source revision and attached observation independently. Likewise, the current Traces surface computes a bounded outgoing dependency traversal; it does not establish a recorded causal sequence. See the implementation baseline for the substrate's wider limits.

Counts describe a view and its evidence. The motivating capture contains 172 nodes, 153 relations and 72 unconnected pins; these are snapshot-specific values. The existing badge adds unconnected provider and consumer pins, so 72 must not become a defect count. Findings distinguish unmatched consumers, DI-backed consumers without explicit graph wiring, unused providers, and optional/external endpoints where metadata supports those classifications. Requiredness and broader coverage may remain unknown. No numerical split is inferred from the capture. Hiding an edge does not disconnect its endpoint.

The instrument shows visible, scoped and total-known counts with the query and coverage that produced them. A filtered or capped result retains omitted-region indicators. Selecting a finding frames its pin, identifies the contract and evidence, and offers candidate providers or an owned source repair where supported.

Decision table for the consistency pass

The 7 September 2026 map iteration resolved the encodings that had drifted between boards. These decisions are enforced through shared components, and a verification pass applied them to every typed-node instance in the design file rather than assuming inheritance.

Fixture and identity ledger

The map states share one authored fixture and never mix it with audited application data. Fieldwork is the fixture: definition G42, working copy r18, recorded activation local/7 (turn 12, events E201–E202, cursor 14:02:11.482), proposals Δ43 (keyed retry and provider repair), Δ44 (outbox) and Δ45 (reusable extraction). BestBuds boards use audited source symbols and explicitly unobserved execution. The example switch between them is explicit in the shell.

Corridors between districts fold these members: C1 client → edge (3), C2 edge internal (3), C3 edge → domain (2), C4 domain → derived and delivery (3), C5 delivery → client (2), C6 client ⇄ edge realtime (1, designed). Observation covers p40 → p44 only; everything beyond is declared, and FCM acceptance is never shown as device delivery.

Carry one selected subject through the tools

EntityRef above denotes the common selection envelope, not a new parallel graph model. It can address a definition, runtime node, port, relation, resource, task, run, finding or UI instance with the appropriate revision/activation/epoch qualifier. Display names and runtime object identity are insufficient as persistent cross-tool references. A view-only summary resolves to its exact members; an unavailable or remapped entity remains explicit.

In the BestBuds linked-editor state, selecting OnboardingScreen keeps its dependency corridor above the actual callback/source excerpt. The UI outline says that no rendered instance is attached. The Ports inspector shows consumed contracts; Source shows declaration and callback correspondence; Runtime shows the missing activation, values and observation cursor. A source location can remain useful while callback-to-runtime correlation is unavailable.

Open alongside and Follow selection carry that subject into Auth's operation policy, Database's repository/store context, Testing's relevant harness, Cloud's service binding and Conductor's bounded task. The shell preserves workspace, revision, environment, principal, target, query/layers, route, time and active run. Back/Forward restores the graph camera, expanded regions and linked editor selections. A pinned tool remains pinned; a deleted or unavailable reference does not silently fall back to a similarly named entity. Tool availability and specialist deep links are resolved against actual supported operations and grants.

The current implementation still has separate graph-node, UI-tree and operational-resource selection state; operational selection resets on a mode change, and an overlay card does not necessarily resolve to the graph inspector. Preview-to-Graph currently changes the mode without establishing a complete handler binding. Graph dragging updates canvas state without completing an integrated document/source command loop. The new boards make these integration gaps reviewable: a common selection path, explicit source ownership and shared evidence must be implemented before those controls can claim full functionality. Human and agent changes use the same governed change path, with context attached to findings and proposals.

Inspect an element, reveal its entire feature

Inspect mode in a browser/Compose preview selects the actual rendered element without activating it. The selection bridge reveals the component instance, source spans, data binding and event handlers, then highlights their operations, state/effects, services and resource dependencies on the whole graph. The preview, graph and source remain open in linked editor groups.

For example, inspect Fieldwork's Submit capture button, choose its submit handler, and follow VisitCommand through actor admission, local state, media processing, remote write, completion and downstream notification/analytics. Zoom out to see the whole distributed route; zoom into a particular boundary to inspect a pin or source call. Select a failed effect or state field in reverse to reveal its originating or affected UI.

The element inspector lists multiple/delegated handlers, binding paths, component definitions and rendered instances when necessary. It distinguishes exact source instrumentation, generated mappings, inferred candidates and unsupported widgets. A DOM path or Compose position alone is insufficient: selection includes render epoch, artifact revision and component-instance identity. Rerender/remapping updates the selection when known; deletion or lost mapping is explicit.

The developer can attach the element, chosen handler, route and selected execution to Conductor; request an offline fallback, stricter auth, lower latency or a different placement; then inspect linked source/graph/preview changes. The agent uses the same selection bridge and commands, not a separate screenshot-only understanding of the product.

Run, simulate and reconcile a route

Flows are first-class regardless of their trigger. The route editor's entry picker exposes UI events, HTTP/services/webhooks, queues/Pub/Sub/state changes, schedules/timers, device/sensor streams, CLI/operator commands, agent MCP/A2A adapters and lifecycle/protocol continuations. Headless flows use the same map, layers, source and execution tools without an artificial UI node.

Select an entry to inspect payload mapping, event/correlation identity, principal/grants, admission acknowledgement, ordering, backpressure and deadline/retry rules. A saved runbook/flow asset versions those mappings with profile, target, budget and recovery configuration. Several triggers can join one existing protocol or stream; several outcomes and ongoing activity remain visible rather than forcing every flow into one start/one finish DAG.

A route toolbar offers the operations supported by its selected profile: inspect, simulate with fixtures, prepare/run a plan, pause/step a supported local target, stop admission, drain, cancel, resume or reconcile. Availability follows actual adapters and current grants. A recorded trace supports cursor navigation; it does not acquire live controls just because the route is visible.

The plan shows exact inputs, prerequisites, fixtures, state/checkpoint origin, targets, capability/effect grants, budgets and completion criteria. The result joins per-target attempts and receipts with the selected route; local completion, remote acceptance, durable commit and downstream publication remain distinct. Resuming a durable profile uses its checkpoint/effect identities, while an ordinary non-resumable call offers an explicit restart plan.

Users can compare the route before/after a change, isolate a local transform without repeating an upload, inject a denied-permission or lost-response case, and derive affected tests and deployment closure. These operations connect creation, debugging, profiling and delivery around one product behavior.

Grouping is not extraction

Group visually, Fold, Extract function, Extract reusable composition and Introduce service/actor boundary are separate actions. Only the first two are view changes. Extraction exposes interface changes, updated callers, preserved identities and source maps. A rejected port deletion identifies the consumer or boundary condition that would be broken.

This follows a useful distinction in Unreal's graph collapsing tools, while Reaktor additionally connects full-stack source and deployment obligations. It does not imply Reaktor inherits Unreal's implementation.

10. Incremental implementation plan

The roadmap owns delivery dates. These slices build on current local editing and architecture projections. December 2026 should demonstrate a bounded working chain; the complete set of runtime/provider/visual profiles matures afterward.

Phase 0: Baseline and fixtures

Capture current source/graph identities and existing document/editor behavior. Choose a real feature spanning client, service and state, plus a brownfield boundary. Keep fixture observations visibly distinct from instrumented runs. Measure the current rendering baseline.

Phase 1: Scope and context index

Add canonical scope references, definition/artifact/activation context and explicit source mappings. Build authorized summaries with coverage. Serialize per-editor state and remapping-aware deep links.

Phase 2: Layered scope-local projections

Implement the ordered layer/query stack and view builder. Preserve existing layout/document APIs through adapters. Demonstrate equivalent semantic projections across supported renderers without claiming complete visual parity prematurely.

Phase 3: Exact boundaries and stable updates

Implement folded ports, relation bundles and endpoint navigation with exact member mappings. Preserve selection and mental map during local source/runtime updates. Handle observer gaps, lost revisions and deletion/remapping explicitly.

Phase 4: Selected bindings and composition

Represent candidate providers separately from selected routes. Support one typed connection/extraction/source-update workflow. Make capability and placement changes expose their combined source, effect, target and test closure.

Phase 5: Connected source and execution evidence

Add one real runtime overlay and one provider/configuration boundary with accurate provenance. Support pinned invocation input/output and a coverage-aware impact query. Extend imported-source adapters without granting permissions from provenance alone.

Phase 6: Shared commands and specialized instruments

Use the same query/change/run contracts from visual tools, command search and agents. Add profile-specific debugging, waits, FFI inspection and delivery operations as their adapters become real. Keep operation preparation, execution and observed reconciliation separate.

11. Workflow acceptance tests

1. Continuous whole feature: select a UI-origin route crossing client, Worker, state authority and evidence. Zoom from whole application to actor, node and pin, then back; route membership, selected identity, time and source correspondence persist without mandatory page changes.
2. Orthogonal state: enable Structure + Contracts + Runtime, pin an r18 trace, then edit r19. Changing the global target does not relabel the trace or replace the layer stack.
3. Faithful folding: fold and expand a region with multiple cross-boundary ports. Exact relation/port identities, witnesses and semantic hash remain unchanged.
4. Real extraction: extract a reusable composition, preview the exported interface and all changed callers. Reject deleting an output with an unhandled consumer.
5. Binding truth: show two compatible providers in different environments. Neither becomes the selected route until the binding source or qualified observation identifies it.
6. Arbitrary code: an opaque Kotlin/native body remains source-editable and callable through its known interface. Its missing internal coverage does not become a false “no effects” result.
7. Concrete execution: a watched port before execution shows no observed value; an unavailable observer differs from an empty stream. A local breakpoint does not pretend other islands paused.
8. Safe selection run: show prerequisites and fixture substitutions before running a transform; an unrelated upload or external write is not silently repeated.
9. Incremental stability: patch one component and stream new evidence while the user edits another. Unchanged positions, selection and source context stay stable; stale findings expire.
10. Query limits: interrupt extraction or lose an event cursor. Impact reports become partial/stale and include unknown boundaries rather than claiming complete safety.
11. Authority parity: the same human/agent command under equivalent grants yields equivalent applicability, change and evidence. A source tier alone neither authorizes nor forbids the command.
12. Accessible power: complete scope navigation, compatible creation, wire inspection, extraction preview and run-result navigation through keyboard and named outline controls.
13. Value chain: change a capability/provider strategy and navigate its graph/source/UI/FFI/test changes, resulting artifact, deployment plan and observed execution as one feature history.
14. Element-to-system: inspect a real DOM/Compose instance, choose among its actual handlers/bindings, highlight its full route and reverse-navigate from an effect to the affected UI; missing mappings remain visible.
15. Route orchestration: plan a send/return/notification/analytics flow, simulate one branch, run supported targets and resume/reconcile under the selected profile without replaying an already-completed effect.
16. Headless parity: choose a webhook, message, timer or agent entry with the same trigger picker; inspect its admission contract, join a running protocol/stream and invoke the versioned runbook with no UI wrapper.
17. Actual application continuity: open BestBuds with mixed detail, select an Onboarding port, follow it through Source, Auth, Database, Testing and Cloud, then return. Entity identity, layer/query state, camera and pinned evidence survive; missing mappings stay visible.
18. Findings and count truth: filter the topology and toggle operations. Visible/scoped counts follow the projection; unconnected-provider and unmatched-consumer findings remain distinct, and hidden relationships do not become missing dependencies.
19. Whole system to exact port: the four map states preserve route R-CAP's member IDs and source context from estate to port; no state jumps to an unrelated diagram.
20. Focus with context: expand one district and inspect a port while adjacent districts remain legible summaries; a filter change keeps the camera unless a frame command is used.
21. Boundary crossing: select bundle C1, reveal p44→p52, p56→p43 and p58→p43 with their transport contracts, and follow both the completion and the failure branch through folded or offscreen regions.
22. Useful layers: combine placement, authority and observation layers over the selected route; explain view reports source/observation coverage and exclusions; removing a layer removes nothing from the program.
23. Runtime history: pin local/7 while source advances to r18; old activation, current definition, stale provider and unknown segment stay distinct and the trace is never retargeted silently.
24. Realtime plus durability: a Mesh session's live data/media topology is distinguishable from the Bus write that preserves a business fact; session loss is not shown as durable-message loss or replay, and neither adapter is presented as implemented.
25. Stress and accessibility (still to demonstrate): a declared synthetic large-graph scenario with aggregate populations, bounded loading and truncated/unknown states, plus keyboard/outline navigation, high contrast, 200 % text and 1440×900 / 1280×800 layouts with resizable docks. The current boards do not yet show these; they are required evidence, not a claim.

12. Decisions still requiring implementation evidence

• The exact persistent identity/remapping scheme and migration adapters for existing graph documents.
• Which source grammars support direct visual edits versus source patch proposals.
• Query indexes, coverage representation and layer-stack normalization at measured scale.
• Layout adapter selection, incremental placement limits and manual-pin persistence policy.
• First execution profile and debugging target, including watch validity and paused-scope behavior.
• Provider-specific binding discovery and desired/observed reconciliation rules.
• Targeted accessibility and performance budgets measured on real workspaces.

These are implementation choices within the common model. They do not reopen whether layers are separate graphs or whether every source must be reducible to a visual AST.

13. Intended outcome

The graph workspace should let a developer move between whole-system composition and exact source or execution detail with continuity. Nesting makes the system navigable, layers make its relationships intelligible, and shared commands make that understanding actionable for both the developer and agents.