refactor(registry): exhaustive platformExecution discriminator (ADR 0019 §6) - #1740

Size Report

Startup median (7 runs, lower is better):

Top changed chunks:

Reviewed exact head 9428496.

P1: react-devtools is incorrectly classified as platformExecution: none. Its production CLI route injects configureDirectPortReverse in src/cli.ts; for Limrun Android react-devtools start, that callback sends internal runtime port-reverse, and session-runtime-command.ts executes configureProviderPortReverse. This is delegated provider/device platform behavior, while ADR 0019 §6 defines none as executing no platform behavior.

Reclassify react-devtools as legacy until that operation migrates. Also add derived coherence coverage, with a planted-red proof, for injected/delegated platform execution. The current entry gate rejects only missing or malformed declarations and none plus a capability bucket, so it cannot catch this real route and can silently undercount the migration denominator.

The other none classifications, runtime readers/public projection behavior, exhaustiveness checks, and itemized +1.9 kB raw / +169 B gzip size tradeoff otherwise look clean. All completed checks are green; iOS Smoke and Layering Guard were still pending at review time.

You're right, and my reach probe had exactly the blind spot you named: it followed imports, and react-devtools's platform reach is injected from src/cli.ts rather than imported, so the module read clean. react-devtools is now legacy (counts: none 17 / legacy 55 / inventory 1 / device-runtime 3), with the delegation recorded at the declaration site. For the coherence coverage I added mode dominance across composition in platform-execution-cli-route.test.ts: it parses the composition root, attributes each command: dispatch literal to its if (command === '<name>') route by following calls into same-module functions, resolves both ends through the command catalog and descriptor registry, and fails when a none route dispatches a non-none command. It is total within that scope — a dispatch no route can claim fails rather than passing quietly, which is the undercount you were pointing at. The planted red runs the real src/cli.ts with react-devtools pinned back to none and fails with react-devtools declares platformExecution none but its CLI route dispatches runtime (legacy); that proof is kept permanently by injecting the mode lookup instead of reverting the registry. Sweeping the same join over the whole composition root, react-devtools -> runtime is the only such delegation, so no other none classification changes.

🤖 Addressed by Claude Code

Reviewed current exact head 8ad1292b. The prior react-devtools classification P1 is fixed: delegated runtime port-reverse makes it correctly legacy, and the current planted-none case detects that edge. One actionable gate issue remains:

[P2] Track dispatch occurrences, not only command names. platform-execution-cli-route.test.ts stores both attributed and all dispatches as Set<string> targets, then subtracts by target name. Once the routed react-devtools edge attributes runtime, any second runtime dispatch outside a recognized route is silently treated as attributed too. I reproduced this with a planted source containing one routed and one stray INTERNAL_COMMANDS.runtime: expected unattributed: ["runtime"], received []. That contradicts the gate’s stated totality and lets future injected/delegated platform behavior evade the migration denominator merely by sharing an existing target. Preserve AST occurrence/source identity through extraction, subtract attributed occurrences rather than names, and keep the one-routed/one-stray duplicate-target witness as a regression.

The current classification/production route otherwise looks coherent. The branch was freshly rebased during review, so the new exact-head CI run is still pending; no ready label yet.

Confirmed and fixed — your reproduction is exact. I ran your planted source against the old scanner first and got expected [] to deeply equal [ 'runtime' ]: attributed and the full dispatch set were both Set<string>, so the routed react-devtools -> runtime edge consumed the name and the stray occurrence fell out of the subtraction. The totality claim was therefore false in exactly the way you describe — shared target names were an escape hatch from the denominator.

Dispatch extraction now carries source identity: every command: site becomes a DispatchSite { command, offset } taken from the AST node's start position, route attribution collects sites rather than names, and the unclaimed set is computed by subtracting attributed offsets. Route edges are still deduplicated by (route, command) so the dominance check is unchanged, and a site with no source position falls back to -1, which can never match an attributed offset and so stays unclaimed (fail-closed). Your one-routed-plus-one-stray case is now a permanent regression test asserting both halves — the routed occurrence is claimed (dispatches is exactly the react-devtools edge) and the stray one is reported (unattributed is ['runtime']) — so a future fix that over-reports everything fails too.

🤖 Addressed by Claude Code

Self-correction on the commit I just pushed: the edge key I introduced in the occurrence-identity fix was written with a raw NUL byte as its separator instead of a space. The logic was correct and every test passed, but git classified the file as binary — so that commit had no reviewable diff, and depgraph:test's no tracked TypeScript source contains a raw NUL byte gate failed the Layering Guard job on 4dbbbb74c (a real failure, not the smoke-lane flake class, so I did not rerun it).

Amended and force-pushed as 4c1c42979 with a plain space separator. The commit now diffs as text (57 insertions / 22 deletions), pnpm depgraph:test is 22/22 locally including that NUL gate, and the six route-gate tests still pass. Worth noting the gate that caught it already existed — nothing new was needed.

🤖 Addressed by Claude Code

Re-reviewed exact head 4c1c429. The prior occurrence-vs-name issue is fixed: attribution now tracks AST dispatch sites by source offset, and the one-routed/one-stray same-target planted regression proves the stray occurrence stays visible. Production react-devtools → runtime classification is coherent.

[P2] The scan still fails open for unknown command targets. dispatchTargetOf() passes literal strings through knownCommand() and returns undefined for an unregistered/typo literal; unsupported dynamic/computed targets are likewise returned as undefined. Those properties are then absent from both allSites and unattributed, contradicting the gate’s totality claim. Please represent unresolved command properties explicitly (or fail the scan immediately) and add planted-red coverage for at least command: 'unknown-target' plus a computed/dynamic target, so every daemon dispatch syntax outside the supported catalog forms is rejected rather than silently omitted. All authoritative CI is green; no readiness label while this remains.

Coordinator check: this PR is currently marked ready while the exact-head unknown/computed-target scanner P2 remains unresolved and no corrected head has been pushed since 4c1c429. Please convert it back to draft immediately, address the finding with planted coverage, rerun pnpm check:affected --run, and only restore readiness after exact-head re-review. Five downstream ADR 0019 units are blocked on this correction.

Confirmed — and I reproduced the drop before fixing it. Running your shape (one routed-known dispatch plus one stray SOME_OTHER_CATALOG.hidden) through the pre-fix resolver, the extraction yields exactly ['runtime']: the stray never enters the scan, so no downstream attribution arithmetic could ever surface it. Unknown was silently equivalent to absent.

Design. command: on its own cannot mark a dispatch in the composition root — withDiagnosticsScope({ command: argv[0] }), resolveRunContextOrExit({ command, positionals }) and the client-config builders all carry that key — so treating every unresolved command: as a failure would fire on six honest sites. Instead the request envelope is identified by the call it is passed to: the first object argument of a sendToDaemon(...) call (identifier or member callee). For each envelope the gate resolves the command property, and anything it cannot resolve — computed target, variable, unknown literal, unknown catalog key, or no command at all — is reported in a new unresolvedTargets list keyed by source line, rather than skipped. Known-target detection stays broad, so a resolvable dispatch anywhere in the file still attributes as before; only the failure case is scoped to send calls. Restricting to the first argument matters: sendToDaemon(request, { authToken }) would otherwise report the options object as a command-less envelope.

Your planted red is permanent, asserting both halves (the routed edge still resolves, the stray surfaces as 7: daemon send target is not a registered command), plus a four-case table covering computed target, unknown literal, variable target, and missing target. The composition root asserts unresolvedTargets is empty alongside the existing dominance and attribution assertions.

Head for re-review: 5b4f1e599, rebased onto 52402aec4. check:affected --run clean; depgraph:test 22/22 including the NUL-byte gate. Left in draft per your coordinator-check note — not requesting readiness.

🤖 Addressed by Claude Code

Re-reviewed exact head 5b4f1e5. The prior unknown/computed inline-envelope finding is fixed, but one actionable totality gap remains.

[P2] daemonSendEnvelopes records a send only when the first argument is directly an ObjectExpression. A request passed by identifier is silently ignored. Concrete planted witness:

const request = { command: "not-a-command", positionals: [] };
await deps.sendToDaemon(request);

The standalone object property does not become an allSites dispatch because dispatchTargetOf rejects the unknown literal, and daemonSendEnvelopes drops the identifier argument, so unresolvedTargets and unattributed are both empty. This is the same denominator escape through one level of request construction. Resolve local request identifiers (or fail closed on every non-object first argument), and keep planted coverage for unknown/computed targets behind sendToDaemon(request). The inline target tests and production react-devtools edge otherwise look coherent. Keep draft pending the corrected head and affected gate.

Re-reviewed exact head 5b4f1e5. The prior unknown literal/computed command target inside an inline object envelope is fixed, and the new planted regressions are meaningful.

[P2] The claimed total scan still fails open one level earlier. daemonSendEnvelopes() records only a directly recognized sendToDaemon call whose first argument is an ObjectExpression. A normal refactor such as const request = { command: 'not-a-command' }; await deps.sendToDaemon(request) is silently omitted from envelopes, dispatches, unattributed, and unresolvedTargets; a computed send callee is likewise skipped. Please make every recognized daemon-send call produce either a resolved envelope or an explicit unresolved failure, and plant the variable-envelope case red. Given this is another syntax-form omission, prefer a typed construction/source of truth over continuing to extend a syntax mini-compiler. Production react-devtools → runtime remains coherent, and all authoritative CI is green/CLEAN, but no readiness label while this remains.

I took the inversion. The scanner is deleted, not extended.

Your holes are real and I confirmed both against the old code before removing it: daemonSendEnvelopes accepted only a direct/member sendToDaemon call whose first argument was an inline ObjectExpression, so const request = {...}; deps.sendToDaemon(request) and deps['sendToDaemon'](...) each produced zero envelopes — invisible to dispatches, unattributed and unresolvedTargets alike.

Why I stopped extending it. This was the third omission patch in three reviews: occurrence-vs-name, unknown targets, now variable envelopes and computed callees. AGENTS.md is explicit that a guard needing a second omission patch should be redesigned around the source of truth rather than given another exception, and each patch made the scanner enumerate what counts as a dispatch — an open-ended set where anything unrecognized passes silently. That failure direction is the actual defect; no amount of syntax coverage fixes it.

The seam. src/cli/injected-daemon-dispatch.ts holds one typed table of route/command pairs and sendInjectedDaemonRequest, the single construction point. command is a typed parameter constrained to the declared pairs, so an undeclared dispatch is a compile error, and the dispatched command is known by type at the call site rather than recovered from an object literal. runReactDevtoolsCli now goes through it.

The gate follows: mode dominance reads the table directly, with no AST at all. The only remaining syntax check is seam singularity, and it is positional rather than value-resolving — the transport identifier may appear in imports, type queries, property signatures, property values, member access and call arguments, and nowhere else. Calls, aliases, and any form I have not imagined fail by default, so the enumeration is now of where the transport may appear (closed) instead of what a dispatch looks like (open). That inversion is what closes the surface; I would not claim the old scanner's surface was closed.

Both of your cases are planted reds, alongside direct call, member call, and alias, plus a positive test that the legitimate client-transport wiring (transport: deps.sendToDaemon, createClientDaemonTransport(deps.sendToDaemon)) still passes. Net −141 lines: a 448-line test becomes ~124 plus a 46-line seam.

One judgement to flag: I kept the structural half in the vitest gate rather than adding a layering rule number, because #1745 and #1750 are both moving the layering rule namespace right now and a fourth concurrent number would collide. If you'd rather it live in scripts/layering/ as an R-rule in the #1744 shape, that is a clean follow-up once those land.

Head for re-review: 09808532b, rebased onto 057ab1c82 (#1746). check:affected --run clean, check:layering green, check:production-exports unchanged at 22/22 pre-existing. Still draft.

🤖 Addressed by Claude Code

Re-reviewed exact head 0980853. Moving to a declared pair table plus a construction seam is the right direction, but two actionable enforcement gaps remain.

[P1] The table types only route keys, not dispatched command values. CLI_INJECTED_DAEMON_DISPATCHES satisfies Partial<Record<DescriptorCliCommandName, readonly string[]>>, so a new legacy route can declare ["not-a-command"] and compile. dominanceFailures also ignores it when the route is legacy, because the filter only evaluates none routes. Type values as registered descriptor/catalog command names and add a planted unknown-value compile/runtime witness.

[P2] Seam singularity still allows arbitrary transport forwarding. isAllowedTransportPosition accepts every CallExpression argument, so forward(deps.sendToDaemon) is clean even when forward later invokes the transport outside sendInjectedDaemonRequest. The existing planted alias catches const send = deps.sendToDaemon, but not transport-as-argument or assignment/destructuring aliases. Restrict wiring to exact approved construction calls/positions, or change the API so raw sendToDaemon is never available to arbitrary CLI modules. Plant forward(deps.sendToDaemon) and a renamed destructuring/assignment alias.

The production react-devtools -> runtime pair and the new request construction itself are coherent. Keep draft until these are closed and check:affected is rerun.

Re-reviewed exact head 0980853. Moving the live react-devtools → runtime injection behind a typed construction seam is a strong improvement; the prior inline/variable-envelope and computed-callee cases are meaningfully covered, and the current production pair is coherent.

[P2] Two holes remain in the claimed singular source of truth. First, CLI_INJECTED_DAEMON_DISPATCHES constrains route keys to descriptor CLI commands but leaves target values as readonly string[]; an unknown target such as not-a-command typechecks and passes dominance while the route is legacy. Constrain values to the descriptor-derived daemon-command union and plant an unknown-table-target red. Second, isAllowedTransportPosition() blanket-allows a sendToDaemon reference whenever its parent is any CallExpression. runInjected(deps.sendToDaemon) therefore passes; that helper can rename the parameter to transport and dispatch directly, invisible to both the scan and table. Restrict raw-transport escape to the exact reviewed client-factory callsites/capabilities, or make bypass impossible with a narrower construction boundary, and plant this arbitrary-helper case red. All checks except the still-running iOS smoke are green; no readiness label yet.

Both holes closed. Head for re-review: a63a99f5c, rebased onto 74eab2a55 (#1744).

1. Table values. The values are now DescriptorDaemonRouteCommandName, a new derived union in the registry alongside DescriptorSessionRouteCommandName — the names of descriptors that carry a daemon facet. A command with no daemon route cannot be the target of a request, so that is the honest constraint, and it comes from the same declaration site rather than a second list.

Planted both ways, because the type alone is not the whole gate:

• Compile: adding 'not-a-command' to the table gives TS2322: Type '"not-a-command"' is not assignable to type '"alert" | "app-switcher" | ... | "wait"'.
• Runtime cast-around: unresolvedPairs now checks that both ends of every declared pair resolve to a registered command. The test asserts the hole explicitly first — dominanceFailures returns [] for {'react-devtools': ['not-a-command']}, because an unknown command has no mode to compare — and then that unresolvedPairs reports it. An unresolvable end is a gate error, not an absence.

2. Transport position. You're right that the blanket CallExpression allowance re-opened the bypass; I verified it against the old predicate first, where both runInjected(deps.sendToDaemon, request) and runInjected({ send: deps.sendToDaemon }) returned zero misuse. The allowlist is now over named positions, expressed as data:

Every other position fails, so the enumeration stays over reviewed positions rather than over call syntax. Three new plants: handoff to an arbitrary helper, handoff under an unreviewed key, and a bare re-export; the existing five (direct/member/computed call, variable envelope, alias) and the positive wiring test still hold.

While tightening this, fallow's complexity gate flagged the switch and the visitor, so the allowlist became a lookup table and the visitor split into a single transportDefect — which reads better anyway: the reviewed positions are now literally a table you can review.

Validation: check:affected --run clean (fallow included), check:layering green, tsc clean. Still draft.

🤖 Addressed by Claude Code

Reviewed exact head a63a99f5. The typed dispatch table and sendInjectedDaemonRequest are a strong improvement, and the prior unknown/variable-envelope recovery problems are gone. One P2 seam escape remains: REVIEWED_TRANSPORT_POSITIONS.Property globally allows any property named transport or sendToDaemon, without checking the enclosing callee or reviewed factory callsite. Consequently runInjected({ transport: deps.sendToDaemon }) passes transportMisuse; the helper can extract/rename the transport and dispatch arbitrary targets. The planted test covers the unreviewed key send, while the positive test globally blesses transport. Constrain property occurrences to exact reviewed client-factory construction/callsites (or expose a narrower capability) and keep this object-handoff witness as a planted red. All authoritative checks are green and the branch is CLEAN/MERGEABLE, but no readiness label while this remains.

Addressed the inherited transport-handoff blocker at exact head fac5294b7.

• Raw transport / sendToDaemon properties are no longer globally trusted by name.
• The structural gate now permits only the reviewed constructions in src/cli.ts.
• Planted regressions prove runInjected({ transport: deps.sendToDaemon }) and member-spoofed factory calls are rejected, while the legitimate seams remain accepted.
• pnpm check:affected --run && git push passed: 481 files / 3,970 tests.

Keeping the PR draft while exact-head GitHub checks run and the stack-level R18 catalog dependency is resolved.

The confirmed transport-handoff gap is fixed at exact head fac5294b7.

The coherence gate no longer trusts a property merely because it is named transport or sendToDaemon. Transport references are accepted only at the exact reviewed src/cli.ts construction sites: the two injected-dispatch factories, the client transport factory, and DEFAULT_CLI_DEPS. Member-call spoofing and generic object handoffs are rejected.

Regression evidence:

• planted old behavior: 2/17 failed (generic { transport: deps.sendToDaemon } handoff and member-callee spoof were falsely accepted)
• corrected focused suite: 18/18 passed
• pnpm check:affected --run: 481 files / 3,970 tests passed, plus format, lint, typecheck, layering, Fallow, and build

No production behavior or documentation changed; this tightens the structural ownership proof only. GitHub exact-head checks are now running.