[lilyshen0722]

TASK-213 A — runtime-token narrowing

Implements §12 A of #2380 against main cd37b32e. Current head: 66801640. This is the kernel prerequisite for the later daemon-seat eligibility work. Vera's exact-head code gate passed at 66801640 (review 5599464010). The #2380 amendment rebuilt at 807595f7 is byte-identical to the dc53ab37 text this code implements; Vera confirmed its own-state condition is satisfied on TASK-213. Keep this PR draft pending the CTO security gate. B/C/D and the outside offer remain separate.

• At both agentRuntimeAuth success paths, census every active installation pod for a live outsider-writable grant on each request. The lookup batches pods, grants, and connections rather than querying per pod; a read failure narrows across all installation pods.
• A single reached pod permits reads and writes resolved to that pod. A post without podId, a thread without a pod, a DM, pod creation or self-install, integration publish, GitHub issue writes, and shared memory writes are refused. Two or more reached pods refuse pod writes, including in the reached pods. Private-only memory updates, event acknowledgements, and spawn credential maintenance remain available. Broker and grant calls retain their own checks. Unknown routes and unresolved pod writes fail closed with outsider_grant_runtime_narrowed.
• The route inventory includes the three mounts missed in the earlier census: ensemble response, hooks, and five spawn-credential routes. The ensemble response resolves the stored ensemble's pod, because its handler ignores the path's :podId. Spawn credential maintenance is classified as the seat's own state; a minted child authenticates as the same agent identity and inherits this gate. An AST test discovers every route file requiring agentRuntimeAuth and compares its runtime-token acceptors to the table.
• The legacy installation-token path keeps the matched installation in its census even if an older instance ID shape makes its identity-wide lookup miss it.
• The human agent roster projects the same identity-wide N≥2 status as a boolean, including grant pods outside the viewer's current pod. The Tools page explains blocked posting and the way to restore it. A failed roster lookup shows an unavailable status instead of claiming posting is allowed; runtime enforcement still fails closed.

Verification

• Backend TypeScript lint: pass.
• Backend tsc:check: pass.
• Focused backend Jest: 5 suites / 47 tests pass, including a real HTTP mint of a spawn child against Mongo while two grant pods reach the seat, its inherited refusal for outward and pod writes, retained event acknowledgement, an ensemble path-spoofing refusal, and narrowed refusals on both user-first token shapes (embedded User token and spawn-scoped AgentCredential). Route-resolution and roster grant-read failures have explicit fail-closed arms; the roster route and Tools page carry the unavailable state through to the visible warning.
• Frontend tests, including the Tools page warning: pass. Frontend and backend TypeScript checks: pass.
• Broad backend Jest run was stopped after the plan advanced at dc53ab37; its partial passes are not claimed as an exact-head gate.

No merge or deploy in this PR. TASK-213 B must follow A; C/D and TASK-214 remain launch gates. Vera's gate binds to head 6680164014004d597bb65acf7620e2a279f3257b; any branch change needs a new exact-head gate. The CTO security gate remains outstanding.

[lilyshen0722]

Gate at cd7ac7c9b9e14ef45127548ed2bd39f6394fcd50, the live head when I read the code and again at filing. origin/main cd37b32e is an ancestor; 7 files, +529 −36. Draft, as the ask says, with CTO card 79693 still open — so this verdict covers the code against #2380 dc53ab37 as proposed, and the own_state item is spent if that class is ruled differently.

Verdict: HOLD. One item, and it is the arm I asked for in advance rather than a new request. Everything else is strong, including two things I expected to argue with and could not.

The item: the narrowing call on the agentUser branch has no arm

agentRuntimeAuth calls the new check at two sites. Disabling the one at :224 leaves 18 of 18 green.

The two branches serve different populations, and the covered one is the smaller:

• :329 is the legacy installation-token path — the installation is matched first, then the bot user is resolved. Every narrowing arm drives this one: setupLegacy() sets mockUserFindOne → null and supplies an installation carrying runtimeTokens.
• :224 is the branch reached when the token resolves to an agentUser first — const agentUser = embeddedAgentUser || (await resolveSpawnChildAgentUser(credential)). That is both the AgentCredential rows and the User.agentRuntimeTokens embedded tokens, and it is also the path a minted spawn child takes.

Measured on the live instance this morning: 101 live runtime credential rows across 95 agents, and 456 bot users carrying an unexpired embedded token. Those are the identities whose narrowing is unwitnessed here, including every spawn child.

The ask says the suite "exercises legacy token refusal", and it does — but legacy is the branch that is covered, and the uncovered one is everything else. So the arm I named at 10:20 is still outstanding, in the direction I did not expect: not "the legacy half is missing" but "only the legacy half is present".

Two arms close it, mirroring the existing ones: a narrowed refusal through an embedded User.agentRuntimeTokens token (mockUserFindOne returning a bot user rather than null), and one through an AgentCredential row. If both assert the same 403 and the same code, :224 is pinned.

What holds, measured rather than read

The route key matches real Express, which is the assumption everything rests on. Every narrowing arm hand-sets req.route.path and baseUrl, so the suite cannot tell whether the table's spelling is what Express actually produces. I mounted the same shapes on a real router (express 4.21.2) and read the key from inside route-level middleware. All six match the table exactly, including the nested mount and the optional parameter:

/api/agents/runtime POST /pods/:podId/messages
/api/agents/runtime POST /events/:id/ack
/api/agents/runtime GET  /memory/shared/:agentName/:instanceId?
/api/agents/runtime/spawn-credentials POST /
/api/agents/runtime/spawn-credentials POST /:id/renew
/api/pods POST /:podId/ensemble/response

req.route is populated for route-level middleware, so the classification runs with a real key rather than 'unknown'. Had any key been off, every write would have failed closed — safe, but a silent outage no arm could see.

The anti-drift test is the strongest part of this PR. It walks routes/ for files that require the middleware, asserts that file set equals the declared bases, AST-parses each for router.<verb> mounts carrying that file's auth wrapper, and asserts the derived key set equals the table. So the table cannot quietly fall behind the code. Both halves bite: dropping one route from the table reddens it, and adding a new unclassified acceptor route to agentHooks reddens it too.

The classification reads the pod from the record, not the path. POST /:podId/ensemble/response resolves through AgentEnsembleState by req.body.ensembleId, with a comment saying the handler ignores :podId — and there is an arm for exactly that ("ensemble path in P cannot write into an ensemble stored in Q"). POST /posts and /threads/:threadId/comments with no resolvable pod fall to outward.

Mutations, one variable each, tree verified clean after every arm. Reddened: a route dropped from the table; a new unclassified acceptor route; unknown made allowed (fail-open); a pod write allowed at N ≥ 2 (3 arms); own_state no longer exempt; a failed grant census opening the token instead of narrowing it. Survived: the :224 call site above.

Suites: the four touched suites are 40 passed. Widened to every backend suite matching agent/runtime/grant/task/message — the acceptor surface — 2043 passed, 4 skipped, 187 suites, no collateral from a change this central.

One ruled requirement is not in this PR

The ruling's note 3 says the 403 message and the Tools page must say in plain words why an N ≥ 2 seat has stopped posting. The 403 carries it (code: 'outsider_grant_runtime_narrowed' plus a message naming the pods and "writes cannot be confined to one pod"). No frontend file is touched by this PR, so the Tools-page half is absent. If that is deliberately B's or a later piece, say so on the row and I will not re-raise it; as it stands a ruled item has no implementation.

Smaller, not a finding: the message names pod ids. For an owner reading it, a pod name would be plainer, and the ids are already in podIds for machine readers.

Written by Vera, a Commonly agent — https://commonly.me/pods/6a8f6dc7a1dccf2e02f31015

GATE: HOLD

[lilyshen0722]

Gate on #2386 at exact head 415ba99a71f8c12597c45aec3afb9d1cb3293f73 — the head you named at 12:00, one commit past the 1f66e21c in your row note. All measurements below are at 415ba99a; the cd7ac7c9 verdict (review 5599237285) is the baseline.

The HOLD item from cd7ac7c9 is closed. Disabling the narrowing call on the agentUser branch (agentRuntimeAuth.ts:224) now reddens two arms — the embedded User.agentRuntimeTokens refusal and the spawn-scoped AgentCredential refusal — where it left 18/18 green before. Both populations are covered, and the larger one (the embedded tokens) is explicit rather than incidental. The legacy site at :329 still reddens six arms when disabled, so the two sites are independently witnessed, which is the point.

GATE: HOLD — three unwitnessed fail-closed arms, all added in this delta, all one line each. Nothing I found is wrong by reading; what is missing is any test that would notice if the reading changed.

1. The route-resolution catch can flip fail-open silently (agentRuntimeAuth.ts:97). Replacing route = { routeClass: 'unknown', podId: null } with routeClass: 'read' leaves 16/16 green. Its sibling catch one block up is witnessed — emptying narrowedPods = new Set(uniquePodIds) reddens "failed grant census narrows the agent" — so the suite asserts fail-closed for a failed grant read and not for a failed route read. The arm is reachable: classifyRuntimeOutsiderGrantRoute is async and its resolvers (messagePod, ensemblePod, askPod) do their own lookups, so a transient DB error lands there. With that one word changed, a narrowed seat's writes would all be admitted during such an error, and the suite would stay green. This is the item I would not merge without: the same arm exists for the neighbouring catch and reads as deliberate, so a later reader has no signal that one of the pair is load-bearing and untested.

2. The whole server-side "status unavailable" chain is unwitnessed, in all three of its links. Each mutation below is independent and each survives:

• nativeOutsiderGrantPolicy.ts — podsWithOutsiderWritableGrants(podIds).catch(() => new Set(podIds)) → new Set<string>(): 7/7 green. Your own comment says this matches the middleware's fail-closed census; the middleware's version of it is tested and this one is not.
• registry/pod-agents.ts:147 — runtimeNarrowingUnavailable = true → false: 2/2 green.
• V2ConnectorTools.tsx — dropping the .some((seat) => seat.runtimeNarrowingUnavailable) disjunct and keeping only seatLookupFailed: 31/31 green.

The two arms that do bite are the other causes: F2 (dropping seatLookupFailed) reddens "does not imply agent posting is available when the roster read fails", and F3 (emptying the blocked-seat filter) reddens the plain-words warning. So the frontend copy for an unavailable status is reached in the suite only by a rejected roster request — never by the flag the server sets, which means the policy → route → flag → copy path has no end-to-end coverage at any of its three joins. Three arms close it: a rejecting podsWithOutsiderWritableGrants asserting the pod ids come back narrowed; a rejecting agentsWithMultipleOutsiderGrantPods asserting runtimeNarrowingUnavailable: true in the payload; and a seat carrying that flag asserting the copy.

On the ruled item, which is satisfied. §12 note 3 asks that the 403 and the Tools page say why in plain words. The 403 does. The page copy — "{{agents}} cannot post while connectors reach more than one of their pods. End a grant until only one pod has connector access." — names the cause and the remedy, is witnessed by name in V2ConnectorTools.test.tsx, and is in both locales. One copy observation, not a finding: the ruling's parenthetical stresses "can't post anywhere", because the counterintuitive part for an owner is that the seat is write-dead in the grant pods too. "cannot post" unqualified carries that, but a reader comparing the ruling to the string will look for it.

What I checked and could not break.

• The projection is boolean-only: runtimeNarrowedByMultipleGrantPods: multiGrantPodAgents.has(instanceKey), and no pod id from outside the viewer's roster leaves the endpoint, which is what the census needs to be identity-wide for. That the boolean lets a pod member infer some other pod holds a grant is an accepted trade here — it is the price of the warning the ruling asked for, and the alternative is the silent failure.
• agentsWithMultipleOutsiderGrantPods counts a pod only when it is in the narrowed set, keys on agentName:instanceId with instanceId || 'default', and your test drives it with a pod outside the roster plus the single-pod negative in the same arm.
• The two guards I re-checked from the baseline both still bite: dropping the route.podId === [...narrowedPods][0] conjunct reddens two arms, and disabling the legacy-path call reddens six.

Suites at this head, product tree restored (HEAD^{tree} a48885d3) after every mutation: backend 45 passed across the five suites (agentRuntimeAuth, runtimeOutsiderGrantRoutes, nativeOutsiderGrantPolicy, registry.list-agents-config, agentCredential.substrate); frontend V2ConnectorTools 31 passed; both typechecks clean on every touched file (the 50 backend tsc errors are confined to four scripts — cleanup-test-data.ts and three test-discord-*.ts — untouched by this PR and failing at the merge base).

The own_state class remains conditional on decision card 79693; this verdict gates the code as built against dc53ab37, and if the ruling keeps b99e23fb instead, the class and its arms change and the gate is spent.

Written by Vera, a Commonly agent — https://commonly.me/pods/6a8f6dc7a1dccf2e02f31015

GATE: HOLD

[lilyshen0722]

Re-gate on #2386 at exact head 6680164014004d597bb65acf7620e2a279f3257b. No ask named this head — it landed about twenty seconds after my HOLD at 415ba99a (review 5599409447), so I took it rather than wait. That verdict is the baseline and everything in it carries except the three items below.

GATE: PASS. All three unwitnessed fail-closed arms now have an arm, each one reddens for its own reason, and one of them is better built than what I asked for.

1. The route-resolution catch (agentRuntimeAuth.ts:97). routeClass: 'unknown' → 'read' now reddens "failed route pod lookup refuses a write even when one grant pod is known", where it left 16/16 green.

The arm's construction is the part worth naming. It sets narrowedPods to the single pod pod-a and aims the request at pod-a, so a successfully-classified pod_write there would be allowed — the request is contained in the one grant pod. The refusal can therefore only come from the throw, and nothing else in the request is suspicious. I gated the instrument in the other direction to be sure: replacing the thrown ensemble DB unavailable with a lookup that resolves to pod-a makes the arm fail, so it is not passing on an incidental 403. An arm built at N = 1 with a matching pod is strictly stronger than the N ≥ 2 version I would have written, because at N ≥ 2 every write refuses anyway and the arm could not tell the catch from the conjunction.

2. The policy's fail-closed census. .catch(() => new Set(podIds)) → empty now reddens "roster marker treats a failed grant census as narrowing in every installation pod" (7/7 → 1 failed). It drives a real rejection from the grant query rather than stubbing the resolved value, so it exercises the catch rather than its result.

3. The roster flag and its consumer. runtimeNarrowingUnavailable = true → false reddens the registry arm, which now asserts the pair { runtimeNarrowedByMultipleGrantPods: false, runtimeNarrowingUnavailable: true } under a rejecting census — the right pair, since the hazard was a bad read reading as "unblocked". And dropping the frontend's .some(seat => seat.runtimeNarrowingUnavailable) disjunct now reddens "shows unavailable status sent by the roster when its grant census fails". The chain is witnessed at all three joins; the other cause (a rejected roster request) keeps its own arm, so neither can mask the other.

The copy observation was taken, and witnessed. Both locales now say "cannot post in any pod while connectors reach more than one of their pods" / "暂时无法在任何 Pod 发帖", matching the ruling's "can't post anywhere". Reverting the en.json string to the previous wording reddens the blocked-seat test, so the phrase is pinned rather than incidental.

Product code is one line. Diffing 415ba99a..66801640 with __tests__ and locales excluded leaves only the defaultValue in V2ConnectorTools.tsx moving in step with en.json. So the guards I verified at the previous head hold by identity of the code, not by re-reading: the middleware's grant-census catch, the route.podId === [...narrowedPods][0] conjunct, the legacy-path call site, both user-first auth shapes, the anti-drift route-table equality, and the boolean-only roster projection.

At this head: backend 47 passed across the five suites (agentRuntimeAuth, runtimeOutsiderGrantRoutes, nativeOutsiderGrantPolicy, registry.list-agents-config, agentCredential.substrate); frontend V2ConnectorTools 32 passed; frontend tsc 0 errors; backend tsc 50 errors confined to cleanup-test-data.ts and three test-discord-*.ts scripts, none touched by this PR and all failing at the merge base. Tree restored to 21ad1168 after every mutation.

Unchanged from the baseline: this gates the code as built against #2380 dc53ab37, so the own_state class is conditional on decision card 79693. A ruling that keeps b99e23fb instead changes that class and its arms, and spends this gate.

Written by Vera, a Commonly agent — https://commonly.me/pods/6a8f6dc7a1dccf2e02f31015

GATE: PASS