[lilyshen0722]

What

Brings the hosted-MCP connection-scope plan and the integration readiness matrix in line with the TASK-224 ruling, the pod rule #2211 shipped, and #2224.

docs/plans/hosted-mcp-connection-scope.md

• A dated header amendment states the ruling: a grant from a source outsiders can write is attached, and its tools called, only in an eligible pod.
• §12's amendment states the four conditions as built (pod grant only; no write mode; a private, invite-only, unbridged pod; only agents that run inside the backend in it, native or, since feat(hosted): hosted agents can run on the native runtime, behind a per-install engine (TASK-261) #2224, hosted on the native engine), where they are enforced (mint and attenuation, then the broker on every list, direct call and approved call, with no cache), and the narrowing TASK-224 applies while a live grant reaches the pod.
• The narrowing is stated as covering the built-in Commonly tools only. A grant's own tools are offered beside them and go to the broker before the native dispatcher, under the grant's own checks.
• The bound rests on a premise the narrowing cannot see: no in-process agent holds a runtime token, the credential that acts as the agent from outside the backend. feat(hosted): hosted agents can run on the native runtime, behind a per-install engine (TASK-261) #2224 makes the shared issuer refuse one, and it is deployed with d37a8600.
• A short list names the four pieces the outside offer also waits on (TASK-226, TASK-227, TASK-228 and feat(hosted): hosted agents can run on the native runtime, behind a per-install engine (TASK-261) #2224), each with its state at this amendment.
• The default's finding that every grant needs an override, the parking paragraph, (c) and (d) are marked superseded where they stand rather than deleted, so the decision's history stays readable. Parking remains the ruling's fallback (TASK-214, held).
• Step 7 records the fresh-account Linear walk of 2026-10-15, whose call was ok again after Narrow native tools in pods with connector grants #2211 deployed, and the entry's page bullet records the revoke page the walk reached, which fix(connectors): Linear's revoke link opens the person's authorized apps, not workspace security #2230 pins.

docs/plans/integration-readiness-matrix.md

• C3: for a grant source, the walk's pod must pass §12's pod rule.
• C4: refused by design for every grant source until TASK-213, because §12 refuses a seat grant, and a pod grant in a pod with a daemon seat in it.
• Linear row: the fresh-account walk (C1 green, C2 green at 1440, C3 green in an eligible pod and again after Narrow native tools in pods with connector grants #2211 deployed), C4 refused by the deployed rule, and C9 narrowed to whether a revoke takes effect at Linear. The earlier operator-led walks are kept and dated.
• The two broker reds (TASK-111 and withholding) are marked moot and closed until TASK-213.

Test

Docs only. Every code cite in the amendment was re-read at main d37a8600.

Gate: Rhea

🤖 Generated with Claude Code

[lilyshen0722]

DOCS-GATE: HOLD @ 62af878 — Rhea

Two scope qualifications are needed in docs/plans/hosted-mcp-connection-scope.md before this accurately records the ruling and implemented boundary:

1. Preserve the runtime-token prerequisite (header amendment and §12:526). The amendment says condition 4 leaves native agents that can only read/post in-pod and treats items 1–3 as bounded. The latest TASK-224 completion note explicitly qualifies that conclusion: #2211's confinement holds only once native agents cannot hold runtime tokens; the outside offer also depends on TASK-226, TASK-227, TASK-228 and #2224's in-process token refusal. At the cited 17adb067 and current ff909fb3, routes/registry/tokens.ts:191–265 still mints a runtime token for a plain-native identity, storing it on User and installation. #2224 fixes this, but is still OPEN at 593769d6 at this review. Its exact-head security clearance is not deployment evidence. Please record the prerequisite now, explicitly distinguishing #2211's native tool-dispatch boundary from the runtime API credential channel. This does not require documenting #2224's future hosted-native eligibility change or waiting to merge this docs correction. The PR body's blanket deferral of text depending on #2224 should not defer this existing condition.

2. Qualify the two-tool statement as the built-in Commonly toolset (§12:524, :526 and the header). The current text says the turn is offered only read_context/post_message, dispatch refuses any other name, and the agent can do “nothing else.” At the cited ref, nativeRuntimeService.ts:1105 offers [...toolsForConfig(cfg, inPodOnly), ...broker.tools]; broker calls are dispatched separately before dispatchTool's narrowed native-tool guard. Granted connector tools remain available under the broker's grant/eligibility checks—indeed the amended Linear C3 walk demonstrates one. State this explicitly so the plan does not teach that #2211 removes or refuses connector tools.

The remainder checked out: the four eligibility conditions and bridge exclusions match the cited helper; mint/attenuation and broker list/direct/approved calls re-read eligibility; the native policy rechecks before model calls and native dispatch and fails closed on read errors; post_message targets the run's pod. The cited files are unchanged between 17adb067 and ff909fb3. The marker's hosted-MCP-only qualification and administrator-only GitHub App creation match the code. TASK-224's ruling and TASK-214's updated fallback note support superseding override/parking as written.

The Linear changes faithfully carry connector-ops' 77850/77962 operator evidence, including read openid, the read-only grant panel, post-#2211 successful call, C4 refusal and the account/security page. C9 correctly retains vendor revocation effectiveness as unmeasured; 390/failure Activity and the remaining consumer proof are not promoted to green. #2230 is correctly named as the page-pin change, not evidence that a revoke took effect.

Read full two-file merge-base diff (+30/-21), surrounding source and latest TASK-224/214/228 notes and pod messages. Diff check clean; final fetched/live head matches; base/current main ff909fb; rubric/checklist unchanged. No application tests or browser/auth/revocation walk run for this prose review. The live observations above belong to the operator, not this reviewer.

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

GATE: HOLD

[lilyshen0722]

Fidelity read against my TASK-224 ruling (eng lead), at 62af878. This is a comment, not a gate; Rhea holds the docs gate.

Faithful:

• the four conditions as Narrow native tools in pods with connector grants #2211 built them, including that a missing field refuses and the bridge rule is inverted (anything other than a hosted-MCP or GitHub App connection counts);
• the five enforcement points (mint, attenuation, list, direct call, approved call), with no cache;
• the narrowing;
• (c) and (d) marked superseded in place, with parking kept as the fallback.

One gap worth closing before this is the reference doc for the outside offer. §12's rule is necessary but not sufficient for offering GitHub and Linear to outside teams. The ruling made the offer wait on four more pieces, and condition 4's rationale depends on the last of them:

• TASK-226 (Refuse non-native agent joins in protected grant pods #2220): no non-native agent joins an eligible pod while a grant is live (install, member-add, invite, approved connect, auto-join, reprovision, the admin session-token route).
• TASK-227 (Limit v2 chat images to instance uploads #2222, merged): v2 chat renders images only from our own uploads, plus an img-src CSP. Otherwise an injected post exfiltrates through an image URL with no agent involved at all.
• TASK-228 (TASK-228: Let owners make invite-only pods for connector grants #2225): an owner can make a pod invite-only, so a team can actually build an eligible pod.
• In-process agents hold no runtime token (feat(hosted): hosted agents can run on the native runtime, behind a per-install engine (TASK-261) #2224). "Native agents hold no seat tools" is only true if nothing outside the backend can act as a native agent. Before feat(hosted): hosted agents can run on the native runtime, behind a per-install engine (TASK-261) #2224, an installer could mint a token for Scout and take grant results without the narrowing. Rhea confirmed it; production had 0 such tokens, so it was latent. feat(hosted): hosted agents can run on the native runtime, behind a per-install engine (TASK-261) #2224 also counts a hosted agent on the native engine as in-process under condition 4.

A short "Also required for the outside offer" list naming those four, each with its state, keeps the doc honest as they land.

[lilyshen0722]

DOCS-GATE: PASS @ b7f6a92 — Rhea

#2234 CLEARED at b7f6a92. This closes both findings in review 5536542476.

The header and §12 now restrict the two-tool claim to built-in Commonly tools. Granted connector tools remain offered alongside them and dispatch through the broker first, matching nativeRuntimeService.ts at the cited d37a860. The runtime-token channel is explicitly a separate premise: the in-process bound requires no such token, and the text names #2224's shared and legacy issuance refusals rather than treating turn narrowing as sufficient.

The outside-offer list retains TASK-226, TASK-227, TASK-228 and #2224 separately. The native-only join predicate versus hosted-native eligibility difference is accurately described and assigned to TASK-231; its correction remains pending. #2225 remains open at this review. The cited merge commits are ancestral to d37a860. Deployment and zero-live-token census evidence are connector-ops' report in 77998, not my own deployment or census check.

Read the complete two-document merge-base scope (+37/-21), the correction against the held head, and the amended source predicates/dispatch/issuer paths. The matrix is unchanged from the prior reviewed cut: fresh-account Linear observations remain attributed to the operator, C2 is limited to 1440, C4 is refused by design, and vendor-side revocation effect remains unmeasured. Prior source checks and historical-supersession review carry forward. REVIEW.md and the reviewer checklist are unchanged; diff check is clean and the final fetched/live head matches.

Docs-only review: no application tests, rendered-doc check, authenticated vendor walk or independent production verification. This clears the documentation, not the outside offer or deployment prerequisites.

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

GATE: PASS