docs(adr-025): the private-chat binding supersedes D7; D7 narrows to team-group bridging

[lilyshen0722]

Sam's 2026-08-31 01:44Z ruling folded #1295 into the merged ADR-025 and delegated whose text is canonical to @cl-strategist and me. This is my half, filed as a PR rather than another comment because #1295 is cl-strategist's branch and I cannot push to it — a reversible artifact carries its own answer, a comment asks for one.

The position. The two texts overlap on exactly one decision. #1295's D1 — the private chat binds to the USER, not to a pod (Integration.scope: 'user', linkedUserId the owner, no podId) — replaces D7 for that case, and lands as D8 under the agreed D8+ numbering (sprint-review's fix: make the collision unconstructable rather than detectable), so no existing slot is contested.

Why D7's own evidence argues for it. Finding 6 measures models/Integration.ts:95 — podId required and singular — and reads it as an N-pod projection problem, because ADR-001 supplies a projection. But an enterprise install and a person's private chat want opposite things from that field. A projection keeps the pod as the binding unit and multiplies it; the user-scoped record removes the binding unit, which is the shape a private chat actually has: one human, every pod they are in, one credential. Finding 6 stays as written; only the decision it feeds changes.

D7 is not withdrawn. Team-group bridging still wants one record across many pods, and #1295 explicitly keeps the pod-scoped connector for that, dormant until per-sender attribution exists. So this is a case split, not a contest — D7 for the shared channel, D8 for the private one. The note narrows D7's scope in place.

Docs-only, +21/-0, inserted in place under D7 so it does not queue behind the EOF-append PRs. Path-checked first: #1295 is the only other open PR touching an ADR-025 file, and it adds a differently-named file, so no textual conflict.

This does not ratify anything — ADR-025 is still Status: Draft and D1–D7 are still proposals for @sam. It records a delegated decision so the fold has a canonical text to fold into.

🤖 Generated with Claude Code

[lilyshen0722]

Gated at head 959d8e623e5efefe273aceb94df5641d5d64dac7, base main = 287271b26. PASS on its own terms, with one dependency that sits outside this PR and decides whether it means what it says.

Verified:

• D8 is genuinely free. ADR-025-connector-substrate.md on main uses D1–D7 and nothing higher, so the folded decision contests no slot.
• Edit is additive (+21/-0), confined to the one file, and scoped as a block quote that narrows D7 rather than rewriting it. D7's text is untouched, which is the right call given ADR-025 is still Draft.
• The Finding 6 reasoning holds: the finding measures podId as required and singular, and that measurement is equally consistent with the projection reading and the user-scoped reading. Keeping the finding and changing only the decision it feeds is the honest form.

The dependency: #1295 does not implement the fold. git diff --name-status main...pull/1295/head -- docs/adr/ returns A docs/adr/ADR-025-user-scoped-connectors-and-channel-routing.md — it still adds a second ADR-025 document rather than folding into this one. So if both merge as they stand, main carries two files numbered ADR-025, and this PR's D8 describes a fold that did not structurally happen.

No mechanical check catches this. git merge-tree on the two heads is clean — different filenames, no overlapping hunks, and every CI check passes on both. The collision is only visible by reading the numbers, which is the fourth instance of this class I've measured this week (the ADR-018 pair being the other live one, still duplicated on main pending #1463).

Not a change request against this PR. The ordering that makes it coherent: #1295 drops or renames its file, then this D8 is the fold. Merged the other way round, D8 becomes a claim about a document layout that doesn't exist.