Skip to content

meta-framework: execution plan and sequencing #107

Closed
Closed
meta-framework: execution plan and sequencing#107
Labels
meta-frameworkAgent Bundle compiler-coupled meta-framework

Description

@ScriptedAlchemy
ScriptedAlchemy
opened on Aug 31, 2026

This is the execution plan and sequencing for the meta-framework cluster: #93, #94, #95, #96, #97, #98, #99, #100, #101, #102, #103, #104, #105, #108.

It was produced by reading every cluster issue in full, the anchors (#50, #63/#67, #78, #88), and verifying every load-bearing claim against main (cf94ccc4). It takes RFC #50 (one config, framework-owned build) and RFC #63 (structure in config+conventions, JSX only for rendering) as settled ground — nothing here re-litigates them. It applies the #63 learnability gate as a hard constraint: the newcomer path today is exactly three concepts (one directory convention, one small flat config, "JSX = rendering"), and this cluster must end with that budget intact.

Revision 2 (2026-08-31). Re-read after the runtime-topology updates to #93/#96/#97/#98 and the new #108 (now in the cluster). Two changes: the execution architecture is now explicit issue text — MCP tools and host hooks are both internal Flight render requests against one warm runtime, preferably hosted in the generated MCP server process, with typed props in and host-native projection out, and Flight never on a public protocol edge; and the owner answered all ten gates — §4 records decisions, wave 2 is unblocked. No build/defer verdict flipped.

Revision 3 (2026-09-01) — reconciliation refresh, no new plan content. Applies the readback audit against origin/main @ 72c3b38f9. Nothing is re-sequenced and no verdict is re-decided; this revision only makes recorded facts match what landed. Six reconciliations: (1) §3's wave lanes now carry landed status with the PRs that delivered them (Waves 2–3 complete, Wave 4 substantially landed, Wave 5 partially landed), mirrored in a status column on the §Verdict summary table; (2) G4's installer deferral is superseded — agent-bundle install <host> shipped in #195; (3) G10's workspace/open Cursor-only claim is corrected — #221 flipped it to honestly unavailable; (4) G5's agents component is recorded as deferred per #220's dated capability notes; (5) §3's per-wave pnpm check:local-ci bar is reconciled with the owner's Wave-2 landing bar; (6) the §2 dependency graph's unmounted #98 process state remainder now points at its tracker, #233. Two items the audit listed as in flight (#105 stage 2, #103 stage 4) merged after the audit's snapshot commit and are recorded as landed with that caveat.

0. Ground truth the plan is built on (verified at cf94ccc4)

Facts that change or sharpen what the issues assume:

  1. The sync lowerer genuinely cannot run the proposed route contract. lowerMcpResult (packages/rsc-runtime/src/lower-mcp.ts:19-30) calls function components synchronously; an async component returns a Promise and throws Expected an MCP result element. Compile filesystem routes into the Agent Bundle meta-framework #93's route example (async default component doing work in its body) cannot execute on today's runtime. This couples Compile filesystem routes into the Agent Bundle meta-framework #93's public authoring surface to Build a real RSC Agent Document renderer with streaming semantics #96 harder than the issues' stack-position notes state.
  2. render is required and doc-pinned. docs-contract.test.ts behaviorally pins "CLI writes one JSON line, render never invoked" and the docs state "no RSC renderer or Flight transport is involved." Build a real RSC Agent Document renderer with streaming semantics #96 and Generate CLI, MCPorter, and script projections from the compiled route graph #102 deliberately invalidate these pins; they must be flipped consciously, in-wave, never deleted silently.
  3. Flight exists only in examples/rsc-agent-runtime: react-server-dom-rspack@0.1.0 + rsbuild-plugin-rsc@0.1.1 + react@19.2.8 as deliberate exact pins; a spawned worker writes Flight to stdout; decode is buffered after process close, not streaming (src/flight/request-render.ts:163-173). The transport seam is proven; streaming, backpressure, and Suspense semantics are not.
  4. The state prior art is stronger than Provide an optional durable Agent state kernel #98 admits. state-file-core.ts (781 lines) already implements leases, kernel poisoning, phase deadlines, idempotency replay/conflict, monotonic revisions, torn-tail repair, fsync discipline, and byte caps — with a cross-process CI proof (pnpm eval:spot). Missing is only the generic contract: user schemas/reducers, transactions/CAS, migrations, retention, subscriptions, driver boundary.
  5. There are five adapters, not four: portable, codex, claude, cursor, and the composite plugin (intersects Claude ∧ Codex capabilities). The capability surface is Boolean (capabilities: Record<string, boolean>) but the data behind it is pinned, SHA-256-verified versioned tables. The composite adapter is the most likely breakage point of any capability-state migration.
  6. Exactly four canonical hook events (sessionStart, beforeTool, afterTool, stop) with per-event result semantics, deterministic wrapper generation via virtual modules, and a byte-identity invariant between Claude/Codex wrapper bodies. The rsc-runtime Hook.* lane can express only a hard-coded PostToolUse additional-context envelope — the two hook lanes are disjoint today.
  7. The dev-runtime seam is the repo's most fragile surface: ≥14 race/flake fix commits (e.g. 0e0c0954 "HMR e2e failed roughly half of local runs"). Serialized coalescing rebuilds, EpochStore staging/leases/recovery, last-good retention, and the SSE event hub with replay-gap frames exist and must be reused, not reinvented.
  8. The merge bar is scripts/local-ci.mjs (four concurrent worktrees: verify on Node 22.19/24/26 + a gates leg running examples:check, full check:release, eval:spot). Any new gate must land in that script and ci.yml. The packed pool is 8 serialized files sharing one build + two tarballs; the heaviest single test is a 1,136-line packed+browser journey with a 360 s budget; template matrices are release/nightly-only.
  9. node:sqlite is viable on the whole matrix: unflagged since 22.13 (verified locally on 22.x), Node floor is 22.19; it still emits an ExperimentalWarning. The repo currently has zero native dependencies; better-sqlite3 would be the first.
  10. Docs/specs the cluster contradicts: the 2026-08-26 parity spec (line 214) lists "building a filesystem router" as a non-goal (Compile filesystem routes into the Agent Bundle meta-framework #93 supersedes it — needs a supersession note); the 2026-08-25 capability-aware workbench spec is still Status: proposed though implemented; several superpowers plans pin Workbench structure invariants that Add an interactive Agent Workbench with local host discovery and lifecycle replay #105 must consciously amend.
  11. Derive project identity from package version and compiler revisions #94 gotchas: only audiobook-curator has a package.json version; the other four examples have none, while all five declare plugin.version. Package name (@agent-bundle-example/audiobook-curator) ≠ native plugin slug (audiobook-curator). Identity migration must not conflate them and must not treat every dev build as a release build.
  12. The warm-runtime topology is now issue text, not inference (revision 2). Compile filesystem routes into the Agent Bundle meta-framework #93, Build a real RSC Agent Document renderer with streaming semantics #96, Compile semantic Agent event routes into native host hooks #97, and Provide an optional durable Agent state kernel #98 each gained a topology section; jointly they specify: the route graph emits a shared server-runtime plan; the generated MCP entry may host both the public MCP server and the internal Flight render dispatcher; a generated hook wrapper is a thin client of that runtime (host-native mcp_tool hook only where proven equivalent, otherwise compiler-owned local IPC; standalone in-process execution only as an explicit degraded mode); the renderer serves a discriminated invocation model (tool | event | cli | script | workbench) with typed props; the compiler owns runtime discovery, handshake, epoch identity, cancellation, deadlines, and shutdown. Provide an optional durable Agent state kernel #98 adds AgentStateLifetime = 'request' | 'process' | 'workspace-durable' | 'external'; a tool-less MCP registration is not evidence of a persistent service.
  13. Compile target-aware Skills with host frontmatter and interpolation #108 lands on real machinery (revision 2). config/skill.ts (portable frontmatter parsing against the pinned Agent Skills schema), config/rendered-skill.ts (build-time SKILL.tsx → Markdown compilation), and the adapter artifact planner already exist at cf94ccc4. Compile target-aware Skills with host frontmatter and interpolation #108's ask is typed per-host extensions, one placeholder/token model across the plugin surface, capability-lowered per-host outputs, and real-install proof — not a new skills subsystem.

1. Per-issue analysis

Size legend: S = one small PR · M = one substantial PR · L = a 2–4 PR wave · XL = its own multi-wave arc. "As-written" sizes the full issue text; "v1" sizes the recommended first shippable slice.

#93 — Filesystem routes (the keystone)

What it really proposes. A source compiler between the project tree and the existing build layers: scan conventional roots (src/mcp/<server>/{tools,resources,prompts,apps}/, src/events/, src/providers/, src/cli/, src/scripts/), derive route kind/server/identity from paths, statically extract a restricted config export (never executing route modules for metadata), validate one immutable route graph carrying a shared four-state capability contract, and generate: virtual MCP server entries, CLI/script registries, event/provider manifests, TypeScript types, Workbench catalogs, and provenance inputs. Route modules replace defineOperation arrays, defineRscApplication, repeated server strings, and one-line server/CLI adapter files. (Revision 2) The route graph additionally emits the shared server-runtime plan: the generated MCP entry hosts the public MCP server and the internal Flight render dispatcher, and the compiler owns runtime discovery, handshake, epoch identity, cancellation, deadlines, and shutdown.

Builds on / replaces. Builds on: discover.ts (today: skills/assets/payloads only), normalize.ts entry probes, build/entries.ts + build/rslib.ts virtual-module machinery (generated wrappers already ride VirtualModulesPlugin), the adapter capability tables. Replaces: the manual registry layer (audiobook's application.ts, src/mcp/curator.ts, per-operation mcp.server strings).

Newcomer-concept cost. Neutral-to-negative if and only if framed as generalizing concept #1: "files under conventional src/ roots ARE the app" — replacing, not adding to, the skills-directory rule (skills keep working identically). Path = identity, optional config export = metadata, default export = rendering — replacing defineOperation, itself a taught concept. Globs, overrides, custom-server modes, target restrictions stay power-tier. Hard requirement: docs/framework-mode.md stays one screen after the rewrite.

Hidden complexity. (a) Static config extraction is NOT a small extension — build/entry-exports.ts today is a comment-stripping regex scanner that recognizes two booleans; the proposal needs a real TS/TSX-aware parse with a precise accepted-expression grammar and named diagnostics for dynamic config. (b) Discovery/normalization/build ownership and timing of the graph need design (graph must exist before validation and entry composition). (c) Typegen needs an output location, cleanup policy, and dev atomicity. (d) The capability-state contract (supported/degraded/unavailable/prohibited + evidence) is a cross-adapter migration that must not break the composite plugin adapter (co-owned with #100 stage 1). (e) Directory-vs-file convention collisions (below, §2 conflicts) need explicit mode diagnostics.

Size. XL as-written. Substrate (graph + extraction + diagnostics + inspect) is L; public authoring + audiobook migration + templates/docs is the flagship slice of a later wave.

Verdict: BUILD. Stage: (1) substrate — route discovery, IR, collision/mode diagnostics, static extractor, inspect route-graph focus, internal fixtures only, no public docs; (2) generated server registries and the runtime-plan seam (the generated entry hosts the dispatcher, co-designed with #96) behind internal fixtures; (3) public authoring contract bound to #96's final-only renderer, audiobook-curator migration, scaffolder templates, docs rewrite. Do not publicly ship an interim route authoring model on the sync lowerer (G8: decided — one public contract only).

#94 — Project identity from package version + compiler revisions

What it really proposes. package.json name/version become authoritative release identity; plugin.version becomes optional then legacy; ProjectContext (already carrying revision, configDigest, modelDigest, sourceInputs) gains validated packageName/packageVersion; manifests, inspect, dev status, and runtime context expose the axes distinctly; release builds fail closed without package identity; dev builds get a labeled fallback.

Builds on / replaces. core/project-context.ts already has all four non-package axes; snapshotProjectSource() already makes package.json participate in the source revision. Replaces the required plugin.version (core/types.ts) duplication.

Newcomer-concept cost. Negative — deletes a required config field from the newcomer path.

Hidden complexity. Package name ≠ native plugin slug (plugin.name must stay the host-safe identity; scoped npm names can't become slugs — G9: confirmed). Four of five examples have no package version. Release-mode vs dev-mode semantics must be explicit. Manifest codecs, epoch DTOs, Workbench identity displays, and pin tests all propagate.

Size. M.

Verdict: BUILD, first wave. Stages: (1) derive + expose identity alongside plugin.version; (2) precedence flip with mismatch diagnostics; (3) plugin.version optional, release-fail-closed (rides a later wave once consumers migrate).

#95 — Typed request context + providers

What it really proposes. Promote the 22-line AsyncLocalStorage wrapper into a framework-owned, versioned, realm-singleton request store installed at every generated entrypoint: canonical AgentInvocation, Observed identities (host/session/actor/workspace with provenance, never fabricated strings), capabilities, progress, signal, services, and provider values; await agent() as the React-independent accessor; a provider dependency graph with compiler-validated ordering, requirements, and generated typing; request leases that make post-completion access throw.

Builds on / replaces. packages/rsc-runtime/src/request-context.ts (22 lines, proven concurrency isolation in tests); examples/rsc-agent-runtime/src/runtime/request-context.ts hand-builds exactly the shape (withRenderContext, useEdit, useRuntimeSnapshot) this issue generalizes — and installs it only on the hook render path (MCP renders run context-free today, a gap this issue closes).

Newcomer-concept cost. One genuinely new opt-in concept: await agent(). This is the cluster's single addition to the newcomer budget (see §1-ledger below). Observed identities, providers, capabilities are power-tier.

Hidden complexity. Request leases (ALS does not invalidate escaped continuations — needs an explicit closed-in-finally token); realm-singleton via Symbol.for + version-conflict behavior across bundled copies; provider failure/ordering/cleanup semantics; the published context contract must reserve the extension slots #98 (state) and #99 (notices) will fill — the issue's sketch currently omits state while #98's example destructures it. (Revision 2) One context store serves every warm-runtime render; it carries the invocation discriminator without forking per surface.

Size. L (core M; providers + entrypoint bindings + fixtures complete it).

Verdict: BUILD; core lands in wave 1, before #93's public surface. Provider discovery (src/providers/) and generated typing arrive with #93's graph; useAgent() arrives with #96.

#96 — Real RSC Agent Document renderer with streaming (the arc's bet)

What it really proposes. Replace manual component invocation with React-owned RSC/Flight execution: route components render to a live Flight stream; an incremental decoder commits versioned, finite, serializable AgentDocument snapshots and ordered render events (shell/progress/replace/error/complete); projectors translate honestly per target capability (MCP: optional progress notifications + one final CallToolResult, tasks-aware; CLI: text/json/ndjson; Workbench/tests: event streams). One exact pinned React/RSC package set. Ends with retiring the synchronous lowerers and making the package's name honest (#88's unanswered half). (Revision 2) The renderer is the shared internal request protocol for every surface (§0-12): MCP tool calls and hook envelopes are Flight render requests with typed props against the same runtime.

Builds on / replaces. Builds on the example's proven seam (worker installs context → writes Flight → decode) and its exact pins. Replaces lower-mcp.ts/lower-hook.ts and the Mcp.*-only vocabulary with the Agent.* document vocabulary. The Workbench already reads Flight bytes (inspection/download) but never decodes — the decoder is net-new framework code.

Newcomer-concept cost. Zero on the happy path if done right: a simple async component returning <Agent.Result> is still just "JSX = rendering." Suspense, progress reporters, NDJSON, capability fallbacks are power-tier. Flight must never be a taught concept.

Hidden complexity. React-minor re-pinning treadmill (framework-facing RSC APIs are not semver-stable); keeping React OUT of agent-bundle (the renderer lives in the runtime package); moving the example's three-environment Rsbuild topology into framework-owned build composition without breaking the tools hatch or source-deleted artifacts; buffered→streaming decode with real backpressure; boundary-replacement IDs are not free from Flight — the reconciler needs an invocation-local model; MCP progress-token/tasks plumbing; vocabulary governance — #97 uses <Agent.Context>, #99 uses <Agent.Warning>, neither in the initial vocabulary (one owner + addition process). (Revision 2) The dispatcher/transport layer is compiler-owned and shared with #93/#97/#98 — one implementation, not one per surface.

Size. XL — its own multi-wave arc, exactly as the issue's 8 delivery steps imply.

Verdict: BUILD (G1: decided). Stages: (1) document/event contracts + the discriminated invocation contract with typed props; (2) React-owned Flight execution behind the render-dispatcher seam, exact pins, cancellation, final-only decode — the slice #93's public authoring binds to; per G1 the dispatcher seam is the boundary and the warm shared runtime the committed model (worker seam = bootstrap/degraded); (3) streaming decode + Suspense replacement + bounded event reconciler; (4) MCP progress/final projector + the warm-runtime proofs (consecutive requests served without reloading the application; runtime restart and artifact-epoch mismatch fail closed; a missing runtime yields an honest unavailable/fallback result, never fabricated success); (5) stable projector seams handed to #97/#102/#105; (6) audiobook migration + sync-lowerer retirement + doc-pin flips (the rename executes earlier, at the wave-2 boundary, per G2).

#97 — Semantic event routes → native host hooks

What it really proposes. Generalize the four-event hook contract into filesystem event routes (src/events/<family>/<event>.tsx) over a broader capability-aware vocabulary; adapters own native event names, matchers, decode schemas, deadlines, response envelopes, and trust semantics; the compiler refuses routes requiring unavailable capabilities unless target-restricted; immediate output renders through the Agent Document projector; deferred work fails with a typed unsupported outcome until #99 exists. (Revision 2) Execution is the thin-client model (§0-12): the generated hook validates the native envelope into bounded, provenance-bearing typed props (canonical identity + the complete validated native payload), renders through the shared runtime under the same artifact/protocol revision, and projects the final document into the exact native output envelope before the host deadline; transport is adapter-selected, standalone execution is an explicit degraded mode.

Builds on / replaces. Builds on: hook-contract.ts (four events, per-event result semantics, wrapper generation, simulation codecs — all reusable), pinned capability tables (Claude's already carries hooks.events + matchers), the Workbench hooks page (execution + replay of generated wrappers). Replaces: config-declared hooks as the primary authoring model (they remain an escape hatch); bridges the disjoint rsc-runtime Hook.* lane (hard-coded PostToolUse) into the real event contract.

Newcomer-concept cost. None new — event routes are the same "file under a root" rule from #93. The event vocabulary is a lookup table, not a concept. Host codecs/deadlines invisible on the happy path.

Hidden complexity. The honest matrix is canonical events × 4–5 hosts, where each supported cell needs pinned evidence, decode schema, identity quality, matcher, deadline, and response channel — an order of magnitude more adapter contract surface than today (G10 bounds v1 tightly). Immediate-output shapes differ per event family (deny/updated-input/context/no-response); one generic document needs event-family projection rules. Idempotency-key derivation and payload bounding per family are unspecified. (Revision 2) Runtime absence, restart, timeout, cancellation, and artifact-epoch mismatch need fail-closed or explicitly configured fallback behavior at the client; consecutive events must be able to observe the same process-lifetime provider when the shared runtime is active.

Size. XL as-written; L for the staged v1.

Verdict: BUILD STAGED per G10. v1 = event descriptor/support-state schema + route discovery + four-event parity through routes + context binding + thin hook clients against the shared runtime, plus exactly the decided families: agent/start/agent/stop with pinned per-host evidence, workspace/open Cursor-only honestly unavailable everywhere (revision 3: #221 flipped Cursor's row to unavailable — the native workspaceOpen hook is sessionless, so no host currently evidences the family; the unavailable row is the delivered v1 outcome, which is exactly the "one family honestly reported unavailable" acceptance clause below). One tool/after in two genuinely supported native formats and one family honestly reported unavailable satisfy acceptance; every further family is its own evidence-backed increment. Compile-side may stage before #96 but stays internal until immediate output renders through the real projector. (Revision 3 status: v1 landed — #170 descriptors, #173 host family capability states, #180 thin hook clients over the warm runtime, #182 example adoption, #194 Claude/Codex subagent correction.)

#98 — Durable state kernel

What it really proposes. An optional, event-sourced state capability: defineState({ schema, initial, events, reduce }); request-bound handles ((await agent()).state.dispatch(...)) with idempotency keys; the kernel owns transactions/CAS, monotonic revisions, exact-revision snapshots, migrations, corruption fail-closed, budgets, subscriptions/change cursors, deterministic test reset; one production-capable local cross-process driver plus a driver interface with a conformance suite. No daemon; stateless projects ship none of it. (Revision 2) State declarations choose an explicit lifetime (request | process | workspace-durable | external); the warm runtime may host a volatile process driver and the configured durable driver, but an MCP process is not durable (hosts restart, multiply, or omit it), and inspect/Workbench expose effective lifetime and runtime instance identity rather than letting applications infer durability from an MCP server's presence.

Builds on / replaces. The example's 781-line JSONL kernel + its CI-proven cross-process eval (eval:spot) are the semantic prior art; the issue explicitly declines to grow that JSONL into a database. Depends only on #95's context slot.

Newcomer-concept cost. Zero for stateless projects (must stay out of scaffolder defaults and intro docs). For stateful authors, defineState is one power-tier concept (a familiar reducer shape).

Hidden complexity. Subscriptions across short-lived processes reduce to polling/change cursors unless a long-lived surface exists — promise nothing stronger; reducer determinism constraints; retention vs exact-revision reads; ensuring stateless artifacts omit kernel code entirely (conditional generated imports, own subpath export); process-lifetime semantics under host restart/multi-instance need honest surfacing, not silent loss.

Size. XL as-written; L narrowed.

Verdict: BUILD NARROWED. v1 = driver-neutral contract with the explicit lifetime taxonomy + conformance suite (in-memory driver, labeled test-only) + a process-lifetime driver hosted in the warm runtime + the workspace-durable driver on node:sqlite per G3 (ExperimentalWarning documented and surfaced; conformance runs on all three CI Node lines; zero native dependencies; the JSONL kernel is not grown further and is retired by migration once the kernel proves parity via eval:spot) + request-context handle + explicit migrations + polling subscriptions. Acceptance includes a real MCP-hosted runtime serving tool and hook Flight requests, restart behavior for process state, multi-instance behavior, and a durable-driver proof. External drivers (Postgres/Redis/TraceDecay daemon) are post-arc, admitted only via the conformance suite.

#99 — Recipient-aware notices + capability-gated delivery

What it really proposes. A durable, recipient-scoped notice object holding a detached finite AgentDocumentSnapshot; a delivery router that selects only adapter-evidenced channels; a state taxonomy (pending/attempted/available/delivered/read/acknowledged/expired/unavailable) where stronger states require real host evidence; v1 delivery = next admitted recipient event or already-connected surface — no implied timers/workers.

Builds on / replaces. Nothing like it exists: no notice model, recipient model, inbox resource, or directed-message capability in any adapter. Depends on #96 (snapshot detachment), #97 (next-event admission), #98 (durability).

Newcomer-concept cost. Zero unless used; notices.publish(recipient, content) is one power-tier API. The state taxonomy is surfaced in receipts, not learned upfront.

Hidden complexity. Today's adapters can evidence exactly: framework-ledger states (pending/expired/unavailable), attempted, and (with a durable inbox) available/observed-re-read. delivered/read/acknowledged have no current host evidence anywhere — a universal promise would institutionalize false claims. Dual-time authorization (publish AND delivery), withdrawal, dedupe races, redaction.

Size. XL as-written; M for the narrow core.

Verdict: BUILD NARROW CORE after #96–#98; DEFER the full router. Stages: (1) durable ledger (publish/dedupe/expire/withdraw, honest states); (2) next-event delivery with attempted receipts; (3) MCP inbox resource (available + observed re-read); (4) per-host stronger states only with pinned evidence. Reject the universal eight-state promise in v1.

#100 — Capability-aware host component bundles

What it really proposes. Replace the Boolean capability surface with versioned four-state capability records bearing pinned evidence; model host-neutral component kinds (skill, command, agent, rule, event-route, mcp, mcp-app, lsp, native-diagnostics, native-extension) with compiler-derived ownership and lifecycle class; adapters lower supported kinds into native artifacts and explain degradations/omissions; opaque payloads stay the escape hatch.

Builds on / replaces. Builds on: TargetAdapter/TargetRegistry, the pinned capability JSON tables (already richer than their Boolean surface), artifact plans with sourceInputs/schemas/provenance, payloadCopyEntries. Replaces: supports(): boolean and capabilities: Record<string, boolean>.

Newcomer-concept cost. Zero if new kinds are just more conventional roots (src/commands/, src/rules/, src/agents/) under the same file rule; a taught ten-kind taxonomy would break the gate. Feature sets, restrictions, lifecycle classes are power-tier.

Hidden complexity. The kind × host × host-version evidence matrix; "command/agent/rule" are not semantically equivalent across hosts; the composite plugin adapter must intersect states, not booleans; LSP/native-extension kinds drag in compilation, signing, trust, platform matrices — far beyond artifact JSON.

Size. L narrowed; XL if LSP/native-extension are included.

Verdict: BUILD NARROWED per G5. Stage 1 (early, co-designed with #93's shared contract): capability-state migration with evidence, contract tests on the composite adapter first. Stage 2: existing kinds re-expressed semantically (skill/mcp/mcp-app/script; event-route plugs in after #97). Stage 3: commands/rules/agents where official host contracts/fixtures exist — Cursor first, rules first (G5: decided). (Revision 3: stage 2 delivered rules (#207, Cursor) and command prompts (#219, Cursor + Claude); the agents component is deferred, not pending — #220 records one dated evidence line each on the pinned Claude 2.1.250 and Cursor 2026-08-28 tables stating that both hosts document a plugin agents component (audits #187/#189) and that #100 stage 2 defers it under this G5 narrowing, so the absent agents capability row reads as a deliberate deferral. Stage 3 has not landed.) DEFER lsp/native-diagnostics until a real consumer proves need. REJECT (from this issue) native-extension compilation — keep opaque payloads; it needs its own RFC covering platform/signing/trust. Also owns the read-only host observation probe contract (ObservedLocalHost) consumed by #105 — and later, separately, by any lifecycle driver. (Revision 2) #108 is the deep-dive of the skill kind and rides this issue's stages: it consumes stage 1's capability states and stage 3's real-install evidence apparatus.

#101 — Managed lifecycle for generated host bundles

What it really proposes. An optional receipt-backed installer: observe → immutable preview plan → digest-paired confirm → backup → journaled apply → host activation → verify → receipt; install/update/repair/uninstall/rollback/recover + Doctor; structured merges preserving unrelated host config keys.

Builds on / replaces. Nothing exists: adapters emit immutable plans and never touch user host config. The dev stores (staging/digests/leases/last-good) are patterns, not reusable machinery for arbitrary shared host files.

Newcomer-concept cost. Operator-tier, not newcomer-tier — but it creates a major product expectation (support burden, trust prompts, destructive-operation safety, cross-OS paths) on a repo whose CI is Linux-only.

Hidden complexity. Format-preserving JSON/TOML merges under concurrent host/user edits; ownership markers surviving reformatting; crash-safe journaled multi-file writes (no atomic multi-file primitive exists); rollback of shared documents after unrelated later edits; Windows/macOS realities with zero CI coverage.

Size. XL, independent of the rest of the cluster.

Verdict: DEFER the installer (G4: approved); build only the read-only slice. Stage 0 (free): keep emitting validated bundles + exact manual install instructions. Stage 1 (small, rides #100's probe contract): read-only Doctor — observe and report installed/missing/conflicted, no writers; consumes #108's host-tree layout evidence for skill/plugin install selection. Mutation is reassessed only after (a) #100's ownership model is stable and (b) at least two real consumers repeatedly need managed installs. If approved later, it ships as an explicit operator surface (CLI), never implicitly via build or the Workbench.

(Revision 3 — the deferral above is superseded; see G4.) Mutation shipped in #195: pinned install capabilities for Claude/Codex/Cursor/portable/composite, generated INSTALL.md plus a Cursor-compatible install.mjs fallback, local marketplace metadata, and agent-bundle install <host> --from <bundle-dir> --scope <scope> delegating to the public host CLIs. It landed exactly on this verdict's shape constraint — an explicit operator CLI, not implicit in build, not in the Workbench — but not on its timing condition (the two-consumer bar was not the trigger). What this issue still specifies and main does not have: the receipt/journal machinery (immutable preview plan → digest-paired confirm → backup → journaled apply → verify → receipt), update/repair/uninstall/rollback/recover, format-preserving merges of shared host config, and the read-only Doctor of stage 1.

#102 — CLI, MCPorter, and script projections from the route graph

What it really proposes. Compile src/cli/** routes (path→command nesting, schema→argv parsing, generated help/exit codes), optionally project eligible compiled MCP tools into the same command tree (the "MCPorter" idea, driven from the already-validated route manifest rather than a live server), discover src/scripts/** with extension-based plain-vs-rendered semantics, merge into one collision-checked command graph, one Rslib executable, with text/markdown/json/ndjson output modes; mutation-capable projections preserve authorization or fail closed.

Builds on / replaces. Builds on: src/cli.ts bin convention + entry-shell.ts envelopes + explicit scripts config + Rslib packaging (all shipped in #50). Replaces runRscCli's manual operation-array dispatch (which never renders JSX — pinned).

Newcomer-concept cost. src/cli/ and src/scripts/ fold into the same route-root rule. One crisp sentence needed: ".tsx scripts render; .ts scripts are plain Node." Output modes are flags.

Hidden complexity. Schema→argv for arbitrary Zod shapes (positionals, unions, arrays, defaults) needs a bounded, documented policy; direct local invocation vs wire invocation of MCP-backed commands have different progress/task/cancellation semantics; collision resolution across aliases and nesting; help text is not authorization.

Size. L (3–4 PRs after foundations).

Verdict: BUILD STAGED; no hard MCPorter dependency (G7: confirmed). Stage 1 (early, independent): plain src/scripts/ discovery through existing entry machinery. Stage 2 (needs #93): routed CLI + parser + help + collision diagnostics. Stage 3 (needs #95/#96): rendered commands/scripts + output modes — rendered CLI/script invocations are render requests against the same runtime contract (cli/script invocation kinds), typically in-process rather than cross-process. Stage 4 (needs #93 manifest): MCP-tool command projection implemented in-house over the compiled manifest; adopt the MCPorter package only if it offers a stable library boundary that consumes static manifests without imposing a second command model.

#103 — Rstest-based consumer test harness

What it really proposes. agent-bundle/rstest (plugin) + agent-bundle/test (helpers) as subpath exports with Rstest as an optional peer; a compiler-generated test manifest configures transforms/aliases/environments; four visibly-separate proof levels (route-unit on the real renderer; projection contract, in-memory MCP labeled as such; browser on the production Rsbuild profiles; packed artifact incl. deleted-source); document/event matchers; failure diagnostics naming route/projection/target/provenance.

Builds on / replaces. Builds on the repo's own pool discipline (unit/integration/packed configs, run-packed-tests.mjs shared tarballs, time-scale knob) — none of it consumer-consumable today: audiobook runs bare rstest tests; the RSC example hand-maintains serialized pool/timeouts.

Newcomer-concept cost. Net negative for consumers (delete copied configs, internal imports, hand-built clients). Proof levels are test-author education carried by helper names.

Hidden complexity. The plugin must reuse one compiler pass (no second divergent compile); route-unit tests need the manifest without full builds; browser helpers must not couple consumers to Workbench internals; snapshot normalization must not erase capability failures; packed helpers must never pack per-route/per-test; public subpaths + optional peer become release commitments. (Revision 2) Projection helpers exercise the warm runtime path, not a parallel test-only execution route.

Size. XL as-written; L for the core.

Verdict: BUILD CAPPED. Stage 1 (with #93+#96): plugin + manifest + renderRoute + document/event matchers; audiobook adopts. Stage 2 (with #102/#97): in-memory MCP + CLI dispatch + packed stdio proof level. Stage 3: browser harness. Stage 4: packed-artifact helpers. Hard cost rules: one build + one pack per pool; matrices stay release/nightly; at most one PR-gate packed journey per new surface; per-route assertions iterate inside one process.

#104 — Worktree-proximity reference application

What it really proposes. A demanding public example (root task + two child agents in separate git worktrees; app-level proximity detection; warnings to the current actor and directed notices to the other) proving that providers, events, state, renderer, and notices compose into a TraceDecay-class coordination app without collision logic or a daemon in framework core. Deterministic suite = generated adapters + two real child hook processes + real worktrees + durable driver; explicitly not evidence of commercial-host dispatch.

Builds on / replaces. Net-new example; the dependency list (#93, #95, #96, #97, #98, #99, #103) is verified honest — it does NOT need #100 (existing adapters + #97 projection suffice), #105 (optional visualization follow-up), or #101 (fixture subprocesses, no host installs). Must satisfy AGENTS.md example rules: public exports only, workspace:*, desktop 1440×900 acceptance, stale-diagnostic/repair flow if browser coverage is added.

Newcomer-concept cost. None if clearly positioned as the advanced reference (kept out of the scaffolder and intro docs).

Hidden complexity. Deterministic worktree fixtures + git metadata isolation; proximity inference stays explicit path/dependency intent in v1; restart/durability journey. (Revision 2) Also the end-to-end warm-runtime proof: hooks + tools sharing one runtime, process state across consecutive events, durable state across restart.

Size. L.

Verdict: BUILD LAST — it is the arc's composition proof and the natural finale gate for waves 4–5.

#105 — Interactive Agent Workbench with host discovery + lifecycle replay

What it really proposes. Extend (explicitly not replace) the existing nine-page Workbench into the compiler-manifest-driven browser half: route catalog + schema-generated input editors; live Agent Document stage (shell/progress/replace/error/complete, audited Markdown); target-projection switch; semantic lifecycle replay across native decode → route execution → render → native encode with fixture-vs-observed provenance; read-only local host discovery via adapter probes; real MCP sessions reused.

Builds on / replaces. #105's "existing foundation" claims are all CONFIRMED in code: build-scoped capability catalog with a hard drift check, hooks page executing real generated wrappers, MCP page with real client sessions + App rendering + consent, Runtime Playground (replays runs, reads Flight bytes but never decodes), last-good retention, SSE hub with replay-gap frames, dev --open. Net-new: manifest navigation, Agent Document stage (today renders raw JSON), schema-driven input editors, lifecycle timeline, discovery probes, projection switch, TanStack Markdown.

Newcomer-concept cost. Zero authoring concepts (UI is generated). Host discovery needs a visible privacy/scope posture, not config.

Hidden complexity. Discovery scans real user machine state — "read-only" must be structural (no writers, trust changes, or credential capture reachable from the probe type); MCP handshakes execute processes, so live probing is user-initiated only; stale-run cancellation and replay identity binding sit on the repo's most fragile seam; the pinned Workbench structure invariants and the 2026-08-25 spec status move consciously as stages land. (Revision 2) The workbench invocation kind rides #96's dispatcher, not a parallel endpoint; #108 adds a source-vs-generated Skill comparison.

Size. XL, staged.

Verdict: BUILD as EXTENSION (G6: read-only discovery approved). Stage 1 (after #93/#103): compiler-manifest navigation replacing count-derived gating, all current pages preserved. Stage 2 (after #96): Agent Document stage + Markdown projection. Stage 3 (after #97): semantic lifecycle replay generalizing the hooks page. Stage 4 (after #100's probe contract): read-only host inventory. Stage 5: user-initiated live MCP probing with consent + redaction. #101 mutation stays out of the Workbench permanently.

#108 — Target-aware Skills with host frontmatter and interpolation (new in revision 2)

What it really proposes. One canonical Skill source — portable Agent Skills fields and Markdown body, optional typed per-target extensions and sidecars (Claude frontmatter extensions; Codex agents/openai.yaml interface/policy/dependencies; Cursor path filters, invocation policy, plugin-config variables), canonical runtime placeholders (arguments, skill/plugin root, plugin data, project root, session identity), referenced resources, and optionally a rendered (MDX/TSX) form — parsed into a Skill IR and lowered per host through the existing adapter/capability system. Placeholders lower to each host's real syntax in the correct document ($ARGUMENTS, ${CLAUDE_PLUGIN_ROOT}, Codex plugin/hook variables, Cursor plugin-config interpolation) or fail with a precise diagnostic; unknown fields are never smuggled into another host's closed schema. Hand-authored portable SKILL.md stays a supported pass-through.

Builds on / replaces. Builds on config/skill.ts, config/rendered-skill.ts (build-time SKILL.tsx → Markdown already ships), the pinned agent-skills frontmatter schema, and the artifact planner, which keeps owning destinations, atomic staging, manifests, validation, and provenance. Extends rather than replaces; no hand-authored skill breaks.

Newcomer-concept cost. Zero. Portable skills stay byte-stable pass-through; targets extensions and placeholders are power-tier.

Hidden complexity. (a) The placeholder classes are the real design: semantically portable vs target-namespaced vs honestly-no-equivalent, expressed as one typed token model spanning the whole plugin surface (Skill bodies, plugin configuration, MCP arguments/env/cwd, hooks, commands, prompts) — not a per-surface regex. (b) Per-host schemas are closed — several portable/upload/plugin validators reject unknown fields — so lowering must emit exactly-legal documents per host. (c) Skills are static install artifacts: a rendered source is executed at build time, its final document projected to Markdown; it may reuse #96's Agent Document → Markdown projection but must not require a live Flight client. (d) Whether the combined multi-host plugin keeps one shared skills/ tree when outputs differ is an evidence question (real host discovery/precedence), and the answer feeds #101's install-time selection. (e) Acceptance demands real installs on Claude, Codex, and Cursor, each exercising a genuinely different native capability.

Size. XL as-written; L staged.

Verdict: BUILD STAGED (child of #100). v1 = canonical Skill IR + typed target extensions for the three hosts + the placeholder/token model with honest lowering diagnostics + static lowering through the existing rendered-skill path; the SKILL.mdx-vs-SKILL.tsx-vs-Markdown-AST decision is made inside the lane by comparing watch behavior, source maps, output control, and multi-target lowering (the rendered form reuses #96's Markdown projection only if it wins that comparison). Per-host lowering with real-install proof rides #100 stage 3's evidence apparatus, Cursor first per G5. Shared-vs-per-host tree layout is decided by discovery evidence and handed to #101 stage 1.

Newcomer-concept ledger (the #63 gate, end-state)

After the full cluster, the newcomer path must still be one screen:

  1. Files under conventional src/ roots are the app (generalizes today's skills rule; subsumes Compile filesystem routes into the Agent Bundle meta-framework #93/Compile semantic Agent event routes into native host hooks #97/Compile capability-aware host component bundles #100/Generate CLI, MCPorter, and script projections from the compiled route graph #102 roots; Compile target-aware Skills with host frontmatter and interpolation #108 changes nothing here — portable skills stay portable).
  2. One small flat config (plugin identity shrinks further via Derive project identity from package version and compiler revisions #94).
  3. JSX = rendering (now literally true — components render Agent Documents; Build a real RSC Agent Document renderer with streaming semantics #96 makes the sentence honest).
  4. (the one addition, opt-in) await agent() when a route needs context (Add typed Agent request context and pluggable context providers #95).

Everything else — providers, state, notices, events vocabulary, output modes, proof levels, host discovery, target-specific skill extensions — is power-tier reference material. Any wave PR that grows the newcomer path beyond this ledger fails review.

2. Dependency graph and conflicts

The now-explicit shared runtime (revision 2)

One warm Agent runtime per project artifact serves every execution surface. Flight stays internal.

MCP tools/call ────────────────────────┐
thin hook client (mcp_tool hook / IPC) ┤
routed CLI / rendered script ──────────┼─> render dispatcher (invocation kind + typed props)
Workbench invocation ──────────────────┘        ├─ request context + providers (#95)
                                                ├─ optional process / durable state (#98)
                                                └─ RSC/Flight render -> Agent Document -> per-target projector

Public edges remain legal MCP results, native hook envelopes, CLI bytes, and Workbench projections — raw Flight never reaches a host that did not negotiate it. The dispatcher/transport layer (discovery, handshake, epoch identity, cancellation, deadlines, shutdown) is compiler-owned, built once, shared by #93/#96/#97/#98. Sequencing: contracts land in #96 stages 1–2, the MCP-hosted dispatcher ships with #93's generated entries in wave 3, hook thin clients consume it in wave 4; the per-render worker stays bootstrap/degraded (G1).

Corrected dependency graph

independent roots:   #94 (identity)   #95-core (context store)   #93-substrate (route IR)   #102-s1 (plain scripts)
                                                                        |
capability-state contract (co-owned #93 + #100-s1, adapters lane)       |
                                                                        v
#96-s1/s2 (document/event/invocation contracts + final-only Flight behind the dispatcher seam)  <—needs— #95-core
        |
        +——> #93-public authoring + generated entries hosting the warm runtime (MCP tool = internal Flight render)   <— the flagship join point
        |                       |
        |                       +——> #103-s1 (manifest + renderRoute harness)
        |                       +——> #102-s2 (routed CLI) ——> #102-s3 (rendered, needs #96) ——> #102-s4 (MCP projection)
        |                       +——> #97-v1 (thin hook clients over adapter transport; G10 families)
        |                       +——> #105-s1 (manifest navigation) ——> #105-s2 (document stage, needs #96)
        |
#98-v1 (lifetime taxonomy + node:sqlite driver; process state rides the warm runtime — process/mounting remainder tracked in #233) ——> #99 core (needs #96 snapshots + #97 next-event + #98 durability)
                                                        |
#100-s2/s3 (semantic kinds; Cursor rules first) ——> #108 (Skill IR + token model + per-host lowering; uses #93 IR; real installs via #100-s3) ——> #101-s1 (read-only Doctor + install-selection evidence)
#100 probes ——> #105-s4 (host inventory)
                                                        |
#104 (needs #93,#95,#96,#97,#98,#99,#103) — the composition finale;  #105-s3 (replay, needs #97)

Answers to the load-bearing sequencing questions:

Conflicts (pairs that genuinely collide)

  1. Compile filesystem routes into the Agent Bundle meta-framework #93 vs shipped RFC: agent-bundle owns the build — one config, framework entry conventions #50 conventions: src/mcp/<server>/ (directory, inferred server) vs src/mcp/<server>.ts (file, declared server); src/cli/ vs src/cli.ts; convention-inferred servers vs "convention applies only when mcp.servers.<name> exists". Resolution: explicit mode diagnostics (the issue's rule 10 — never silently choose), templates/docs migrate in the same wave.
  2. Build a real RSC Agent Document renderer with streaming semantics #96/Generate CLI, MCPorter, and script projections from the compiled route graph #102 vs the behavioral doc pins: docs-contract.test.ts ("CLI never renders", exact one-line JSON) and the "no Flight transport" statements in framework-mode.md + rsc-runtime README + the removed react-server-components keyword. Resolution: pins are flipped (not deleted) in the PR that changes the behavior; new pins land the same day.
  3. Compile filesystem routes into the Agent Bundle meta-framework #93 vs 2026-08-26 parity spec: "Building a filesystem router…" non-goal at :214. Resolution: supersession note in wave 1.
  4. Build a real RSC Agent Document renderer with streaming semantics #96 vocabulary vs Compile semantic Agent event routes into native host hooks #97/Add recipient-aware notices and capability-gated delivery #99 elements: <Agent.Context> and <Agent.Warning> are used by dependents but absent from Build a real RSC Agent Document renderer with streaming semantics #96's initial vocabulary. Resolution: Build a real RSC Agent Document renderer with streaming semantics #96 owns the vocabulary registry; additions ride the dependent issue but require Build a real RSC Agent Document renderer with streaming semantics #96-lane review.
  5. Add typed Agent request context and pluggable context providers #95's context shape vs Provide an optional durable Agent state kernel #98/Add recipient-aware notices and capability-gated delivery #99 extensions: the sketch omits state/notices slots that dependents destructure. Resolution: Add typed Agent request context and pluggable context providers #95 reserves named extension slots in the v1 contract.
  6. Projector ownership overlap (Build a real RSC Agent Document renderer with streaming semantics #96 vs Generate CLI, MCPorter, and script projections from the compiled route graph #102 vs Add an interactive Agent Workbench with local host discovery and lifecycle replay #105): Build a real RSC Agent Document renderer with streaming semantics #96 owns document/event contracts + low-level projectors; Generate CLI, MCPorter, and script projections from the compiled route graph #102 owns CLI/script UX on top; Add an interactive Agent Workbench with local host discovery and lifecycle replay #105 owns browser presentation. No surface is implemented twice.
  7. Compile capability-aware host component bundles #100/Add safe managed lifecycle for generated host bundles #101/Add an interactive Agent Workbench with local host discovery and lifecycle replay #105 observation vs mutation: one read-only probe contract (in Compile capability-aware host component bundles #100) serves Add an interactive Agent Workbench with local host discovery and lifecycle replay #105; any future lifecycle driver is a separate operator-only interface; the Workbench never receives mutation capabilities.
  8. Derive project identity from package version and compiler revisions #94 identity vs native slugs: npm package name must not become the host plugin slug; plugin.name remains authoritative for hosts (G9: confirmed).
  9. Add an interactive Agent Workbench with local host discovery and lifecycle replay #105 vs superpowers Workbench structure invariants ("no new shell/navigation/router…"): amend those plan docs consciously in Add an interactive Agent Workbench with local host discovery and lifecycle replay #105 stage 1.
  10. Capability-state migration vs the composite plugin adapter: Boolean intersection must become state intersection with evidence merging; contract-test the composite first (Compile capability-aware host component bundles #100 stage 1).
  11. Compile target-aware Skills with host frontmatter and interpolation #108's token model vs per-surface interpolation (revision 2): placeholders span Skill bodies, plugin config, MCP args/env, hooks, commands, prompts. One typed token registry, owned by the Compile target-aware Skills with host frontmatter and interpolation #108 lane and consumed through adapters — neither Compile semantic Agent event routes into native host hooks #97 nor Generate CLI, MCPorter, and script projections from the compiled route graph #102 grows a second interpolation engine.
  12. Compile target-aware Skills with host frontmatter and interpolation #108 output trees vs Add safe managed lifecycle for generated host bundles #101 install selection (revision 2): shared-vs-per-host skills/ layout is an evidence decision (real host discovery/precedence). Add safe managed lifecycle for generated host bundles #101's Doctor consumes that decision; it does not re-derive it.

3. Wave sequencing

Repo pattern honored: parallel lanes with strict file ownership; every wave gated by pnpm check:local-ci green on HEAD (the merge bar); every framework wave lands with a consumer/example migration proving it (the RFC #50 pattern); docs + diagnostics + pins updated in-wave, never later. All ten gates are answered (§4), so no wave is blocked on an owner decision.

(Revision 3 — the per-wave pnpm check:local-ci bar above was superseded and never reconciled until now.) From the Wave-2 launch onward the operative bar is the owner's landing bar, recorded in the Wave-1-complete comment: scoped tests + typecheck + lint, merge on green, no CI waits, with per-test rstest retries covering the #122 flakes. The comprehensive full-matrix pass moved from per-PR to wave-exit verification — Wave 1's exit pass (single comprehensive run at 0d5796b0 plus follow-ups) is the recorded instance of that shape. pnpm check:local-ci remains the full merge bar it always was; it is simply no longer claimed as a per-wave, per-HEAD gate.

Wave 1 — foundations (launchable now; lanes, file ownership, and proofs are detailed in §6) — complete (2026-09-01) (rev 3)

Wave 2 — the renderer bet + independent substrate — complete (rev 3)

Wave 3 — routes go public (the flagship consumer wave) — complete (rev 3; #139–#151 all landed, per the Wave-3.5 comment)

(Wave 3.5 — Effect-native internals — was inserted here by owner decision on 2026-09-01 and is tracked in #152; it landed as #153–#162.)

Wave 4 — projections — substantially landed (rev 3)

Wave 5 — coordination + browser + host power — partially landed (rev 3)

In flight at the audit snapshot (72c3b38f9): #100 stage 3, #101 read-only Doctor, #105 stage 2 (landed since — #231), #103 stage 4 (landed since — #225).

Wave 6 — proof and host power

Post-arc / explicitly deferred: #101 mutation lifecycle (reassessment criteria in §1); #99 per-host delivered/read/acknowledged evidence; #100 LSP/native-diagnostics (own RFC if a consumer materializes); #105 stage 5 live probing polish; external #98 drivers; #108 rendered-authoring expansion beyond the v1 decision.

4. Owner decisions (recorded 2026-08-31)

All ten gates are answered; nothing below blocks any wave. (Revision 3 marks the three gate records that main has since contradicted — G4 superseded, G10 corrected, G5 narrowed further. The decisions themselves are not re-litigated here; only their recorded state is brought in line with what landed.)

5. Risk register

6. Recommended first wave (launchable immediately)

Four parallel lanes, disjoint file ownership, each PR local-ci-gated. Every gate is already answered, so wave 2 starts the moment wave-1 exit criteria hold.

Lane A — #94 identity, stages 1–2 (M).
Derive packageName/packageVersion into ProjectContext with validation; expose in normalized model, artifact manifests, inspect, dev status; add mismatch diagnostics (plugin.version ≠ package version → warning); plugin.name untouched (G9). Consumer proof: audiobook-curator keeps one version (package.json), config comment documents the derivation; remaining examples get the documented dev fallback. Files: core/project-context.ts, core/types.ts (additive), identity slices of config/normalize.ts, build/manifest.ts, inspect/status DTOs + their pin tests.

Lane B — #93 substrate (L, first two PRs).
PR-1: route discovery + immutable route-graph IR + collision/mode diagnostics (new AB code family; directory-vs-file conflicts are errors demanding explicit mode) + inspect route-graph focus, driven purely by internal fixtures. PR-2: the static config-export extractor (real TS/TSX parse; documented accepted-expression grammar; named diagnostics for dynamic config), still consumer-invisible. Explicit non-goals this wave: no public authoring docs, no rsc-runtime changes, no generated server entries. Files: new packages/agent-bundle/src/routes/**, additive slices of config/discover.ts, config/validate.ts, cli.ts (inspect focus), fixtures.

Lane C — #95 core (M–L).
Versioned realm-singleton request store with closed leases; agent(); Observed identities + canonical AgentInvocation carrying the invocation-kind discriminator; reserved state/notices/providers slots in the contract; bind MCP and CLI entrypoints behind the current operations model (context available, nothing else changes). Consumer proof: examples/rsc-agent-runtime deletes withRenderContext/useEdit/useRuntimeSnapshot internals in favor of the framework store (its tests keep passing). Files: packages/rsc-runtime/src/** only.

Lane D — docs hygiene (S, rides Lane B).
Supersession note on the 2026-08-26 filesystem-router non-goal pointing at #93; status note on the 2026-08-25 workbench spec pointing at #105.

Wave-1 exit criteria: local-ci green on every lane; route graph inspectable on fixtures; examples' identity displays agree across build/inspect/status; the RSC example runs on the framework context store. (No gate answers pending — wave 2 is unblocked.)

Verdict summary

Status column added in revision 3 — recorded facts as of origin/main @ 72c3b38f9 plus the two same-day merges that followed it (#231, #225).

Issue Verdict Size (as-written → v1) Wave Status (rev 3)
#93 routes Build (substrate first; public authoring with renderer) XL → L substrate 1 → 3 landed — substrate #119/#135; public authoring #147/#150
#94 identity Build M 1 landed — stages 1–2 #121; stage 3 open on #94
#95 context Build (core before routes) L → M core 1 landed — core #113; later slices open on #95
#96 renderer Build (G1 decided; warm shared runtime, no per-render-worker commitment) XL 2 → 4 landed — s1–2 #139/#140/#144 · s3 #145 · s4 #175
#97 events Build staged (G10 families: four existing + agent/start/agent/stop; workspace/open Cursor-only honestly unavailable per #221) XL → L v1 4 landed — v1 #170/#173/#180/#182/#194; #221 correction
#98 state Build narrowed (node:sqlite per G3; explicit lifetimes) XL → L v1 2 partial — durable slice #142/#149 (+#154); process state / bundle mounting remainder → #233
#99 notices Build narrow core; full router deferred XL → M core 5 partial — ledger + next-event #184 (+#202); MCP inbox stage open
#100 host components Build narrowed (Cursor rules first per G5); agents deferred per #220; LSP/native-diag deferred; native-extension compilation rejected here XL → L 2 (s1) → 5 partial — s1 #141 · s2 #207/#219 (agents deferred #220); s3 open
#101 lifecycle Defer installer (G4 approved) installer shipped #195 (G4 superseded); read-only Doctor still the only planned observation slice XL → S probe slice 6+ partial — install CLI #195; Doctor + receipts/journal/rollback open
#102 CLI/scripts Build staged; no MCPorter hard dep (G7) L 2 (s1) → 4 partial — s1 #143 · s2 #178 · s3 #186; s4 (MCP projection) open
#103 harness Build capped XL → L core 3 → 6 landed — s1 #151 · s2 #190 · s3 #212 · s4 #225
#104 proximity app Build last (composition + warm-runtime finale) L 6 not started
#105 Workbench Build as extension, staged; read-only discovery per G6 XL 5 → 6 partial — s1 #211 · s2 #224/#231; s3–s4 open
#108 target-aware Skills Build staged (child of #100; static build, no live-Flight requirement) XL → L v1 4 (design) → 5 partial — design slice #185; per-host real-install proof rides #100 s3, open

Cross-links: #93 #94 #95 #96 #97 #98 #99 #100 #101 #102 #103 #104 #105 #108 · anchors #50 #63 #67 #78 #88.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    meta-frameworkAgent Bundle compiler-coupled meta-framework

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions