docs: state production reply authority as it is, not as a dispatch lease

[chughtapan]

Plan step 4a — Lane V-a, the factual half of the reconciliation. The one-path design change is deliberately not here; see below.

What was false

PR #941 removed dispatch leases, LeaseId, conversation_busy, server-side reply grants, and local duplicate-reply suppression from production. Several v2-owned records still described production as lease-bearing. The sharpest was 20260801-model-output-is-start-or-bound-reply:

The production implementation continues to use its dispatch lease privately.

Production reply authority is the originating ConversationId, carried privately in MCP _meta under xyz.moltzap/events-v1, and every invocation sends. The records now say that.

Where a production target was discussed but never admitted on main, the text now says requested and unselected rather than selected — including freeze row G1-DEC-640, whose only defect was that past tense.

management.md retraction

It asserted, as normative v2 spec, that main's registration "must be idempotent and crash-recoverable, using a stable OperationId and a client-owned recoverable credential." Verified against main: there is no OperationId anywhere, AuthService.registerAgent generates the credential server-side, and agents.name is TEXT UNIQUE — so identical retries fail rather than recover. Per 20260729-v2-authority-lives-with-v2, a v2 spec must not bind main's implementation. The request is recorded; the outcome is not admitted.

Without this, a registration implementer reads an outranking normative spec demanding a contract main's schema cannot deliver.

Membership DTO narrowed to the wire

"Harness introduces no … membership DTO" now scopes to the network wire. A daemon may enrich the conversation it passes across its own loopback MCP boundary with membership its endpoint already holds.

I verified the justification rather than asserting it: git diff origin/main..HEAD -- packages/protocol/src/conversation/ is empty. The canonical wire is genuinely unchanged, so the DTO never crosses the network and the record's actual concern is not violated.

Provenance: maintainer, 2026-08-04T07:51:15 — "we can include participants in conversation passed by mcp to harness client but not on the main wire."

Audit

Found by a bare lease grep, not dispatch lease — the narrower pattern misses output.md's "lease and production-owned completion behavior". Every surviving hit is legitimate and was reviewed individually:

Location	Why it stays
20260721-sessionless-network.md:69	historical reference to v1's lease-cleanup, in a partially-superseded record
20260801-model-output:14	Context — hypothetical leak surfaces at decision time. AGENTS.md requires preserving historical reasoning.
20260801-model-output:54	new text listing what the production path does not carry
inbound-notifications:53	now "was requested", describing an unselected main target
gate-1-freeze:326	now "requested but remains unselected"

docs/decision-evidence/ was not touched — trajectories are source-faithful ledgers.

Deliberately not in this candidate

The one-path /register/mcp collapse. It is a separate PR because the risk profile is asymmetric: these are factual corrections against verifiable code, while the one-path change amends AGENTS.md Constitution item 3 and supersedes admitted Gate-1 row G1-DEC-635 — 28 edits across 11 files. Bundled, a FAIL there would drag down four uncontroversial corrections and force both to be re-frozen with a fresh reviewer. AGENTS.md already requires a different reviewer per candidate, so splitting costs one extra gate run and no extra reviewer.

Status and gates

No record changes status, so no superseded-by field, no Supersession section, and no docs/decisions/README.md index rows move. These are corrections within current outcomes, not replacements of them.

• pnpm docs:check — 0
• pnpm docs:check:mermaid — 0
• bare-lease grep annotated above, line by line

Next

This candidate still needs the AGENTS.md blind-teammate review gate: one fresh reviewer, the six verbatim questions, no coaching, artifact recorded under docs/decision-evidence/. Then maintainer acceptance — agents draft and route, never self-admit.

🤖 Generated with Claude Code

https://claude.ai/code/session_01P76aaa1STr3WPZ3nDascta

[chughtapan]

Blind teammate review: FAIL — this PR is blocked from landing

Artifact checked in at docs/decision-evidence/20260805-lane-v-a-595edef1-cold-review.md (commit 8fec8733). A failed review is auditable evidence, so it lands regardless of outcome, and the rerun rule needs a record of which reviewer saw which candidate.

Six blockers. I verified them after delivery rather than contesting them; five of six reproduce from the repository alone.

#	Blocker	Status
1	v2/VISION.md — top of the authority order — still says the production conversation_busy behavior was selected, while this PR flips an ADR, a manifest row, and a spec to unselected	reproduced
2	The _meta / xyz.moltzap/events-v1 carriage claim	qualified — see below
3	"Every production reply invocation sends" is contradicted by channel-base/reply-guard.ts, tracked source on this branch	reproduced
4	Attribution flipped from selects to requested without amending the linked trajectory	reproduced
5	harness-implementation-slate.md still specifies dispatch leases — not landed atomically	reproduced
6	output.md retains LeaseId; management.md § Search retains the unqualified membership prohibition client.md narrowed	reproduced

The one I'd qualify, and why it gets worse rather than better

The reviewer called the _meta/events-v1 claim unverifiable. HARNESS_EVENTS_EXTENSION = "xyz.moltzap/events-v1" and the _meta route do exist — but only on the unmerged production stack, not on v2 and not on main. So the characterization is too strong for the code's existence and exactly right for its status: this PR describes behavior no merged branch carries.

Its underlying point is sharper than its framing, and I missed it entirely: xyz.moltzap/events-v1 is clean-slate-owned by G1-DEC-608, daemon.md, and ingress.md. Assigning it to production is a cross-track identifier collision that also contradicts the accepted outcome that the two raw MCP surfaces may differ. That is a worse error than describing unlanded code.

The most serious one is #4

I changed the record from selects conversation_busy to was requested … remains unselected. The linked trajectory records the decision-maker answering A to a prompt selecting exactly that.

I conflated two questions: was this selected and did main implement it. Absence of an implementation does not unmake a recorded decision — and I made that error inside a PR whose stated purpose was fixing that class of error.

What holds

The direction is right and four factual corrections check against code: production reply authority genuinely is the ConversationId, no leases survive in production source, daemon-side membership enrichment is real, and main's registration has no OperationId.

Next

Rework, freeze a new candidate, and review with a different fresh reviewer per the gate's rerun rule. Reviewer prose is not self-certifying — maintainer disposition is still pending regardless of this outcome.

One thing the reviewer disclosed unprompted: a system-reminder injected an author-side task list naming this candidate. It says it did not use it and grounds each finding in cited artifacts. Recorded in the artifact rather than judged there.