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

docs/decision-evidence/20260805-lane-v-a-595edef1-cold-review.md

@@ -0,0 +1,183 @@
+# Lane V-a lease reconciliation blind teammate review
+
+## Candidate identity
+
+- Candidate repository root: `/home/tapanc/moltzap-lanev-a`
+- Candidate commit: `595edef1`
+- Candidate branch as observed: `docs/lane-v-a-lease-reconciliation`, one commit ahead of
+  `origin/v2@7329cfb0`
+- Candidate subject: `docs: state production reply authority as it is, not as a dispatch lease`
+- Candidate scope: eight files, documentation only, no code
+
+## Reviewer identity and isolation attestation
+
+Fresh agent session that did not author or reconcile the candidate. It received only the
+candidate repository root, the candidate commit, and the six fixed questions. It was given no
+design summary, no diff tour, no ADR or file pointer, no search term, no expected answer, and no
+out-of-band index.
+
+The reviewer attests it opened **no** quarantined file. It observed `*-cold-review.md` and
+`*-invalid-review*.md` names in one directory listing of `docs/decision-evidence/` and filtered
+them from every subsequent search. No command returned an answer or verdict sourced from one.
+
+**Contamination the reviewer disclosed without being asked.** Two `<system-reminder>` blocks
+auto-injected an author-side task list containing the string
+`Step 4a: Lane V-a — factual ADR/spec corrections`. The reviewer did not request it, states it
+did not use it, and grounds every finding in cited repository artifacts. Recorded here because
+the gate requires a complete isolation record, not because the reviewer concealed it.
+
+Whether that injection materially assisted the review is a maintainer judgement. The reviewer's
+findings are independently checkable against the cited paths, and the author's verification below
+reproduced five of six from the repository alone.
+
+## Author interventions
+
+None during the run. The author neither coached the reviewer nor answered questions while it
+worked. The author's verification of the findings happened only after the report was delivered
+and is recorded separately below.
+
+## Exact prompt
+
+> You are performing a blind teammate review of a candidate repository revision.
+>
+> Candidate repository root: `/home/tapanc/moltzap-lanev-a`
+> Candidate commit: `595edef1`
+>
+> Read the root `AGENTS.md` first; it governs how this repository's decision records work and
+> what this review requires.
+>
+> Normal repository navigation, history, search, and discovery of the checked-in decision index
+> are allowed. Files matching `*-cold-review.md` and `*-invalid-review*.md` under
+> `docs/decision-evidence/` are **quarantined**: do not open, read, or search their contents.
+> Seeing such a path in a directory listing or in history is fine. If any command returns an
+> answer or verdict sourced from one of those files, stop and say the run is invalidated.
+>
+> This is a read-only review. Do not edit, commit, or push anything.
+>
+> Answer these six questions, in order:
+>
+> 1. What decision does this candidate make current, what problem does it resolve, and which
+>    statements are binding versus context or non-normative explanation?
+> 2. What earlier outcomes does it replace, retain, or leave untouched, and where does the
+>    current normative contract live?
+> 3. What must an implementer now do or avoid, which layers or consumers are affected, and under
+>    what fault, trust, safety, liveness, and compatibility assumptions?
+> 4. Which humans are named as decision-makers, which source events does the compacted trajectory
+>    cite for their calls, alternatives, reversals, and deferrals, and what source gaps does it
+>    explicitly record? Report only what the event ledger states; do not infer motives,
+>    confidence, urgency, or rationale.
+> 5. Find the strongest apparent contradiction, stale instruction, or broken lineage elsewhere in
+>    the repository. Resolve it using the authority order or report it as a blocker.
+> 6. Could a teammate implement the decision without chat or guessing? List every missing link or
+>    unresolved choice and classify each as a deliberate deferral or an accidental gap.
+>
+> `Not discoverable` is a valid answer. Report what you can and cannot establish from the
+> repository alone.
+>
+> Return: your unedited answers to all six questions; the paths and headings you independently
+> discovered; your discovery trail (what you looked at, in what order); a per-question verdict of
+> PASS or FAIL; any blockers; and an overall PASS or FAIL. Also state explicitly whether you
+> opened any quarantined file.
+
+## Per-question verdicts
+
+| Question | Verdict |
+|---|---|
+| 1 — current decision, problem, binding vs. context | PASS |
+| 2 — replaced/retained/untouched, normative owner | FAIL |
+| 3 — implementer obligations, layers, assumptions | FAIL |
+| 4 — decision-makers, cited source events, gaps | FAIL |
+| 5 — strongest contradiction under the authority order | FAIL |
+| 6 — implementable without chat or guessing | FAIL |
+
+## Overall result
+
+**FAIL.** Blocks landing.
+
+## Blockers
+
+1. **A lower source contradicts `v2/VISION.md`.** VISION.md sits at the top of the authority
+   order and states the production `conversation_busy` and local-retry behavior was *selected*.
+   The candidate flips an ADR, a manifest trace row, and a spec chapter to *unselected* without
+   landing the same reframing in VISION.md.
+2. **A binding claim the repository does not support.** The candidate states production reply
+   authority is "carried privately in MCP `_meta` under the `xyz.moltzap/events-v1` extension."
+   Neither `_meta` nor `xyz.moltzap` appears in any `.ts` file on the candidate tree, and the
+   production MCP wire there exposes only `status`. Separately and more seriously,
+   `xyz.moltzap/events-v1` is clean-slate-owned by manifest row **G1-DEC-608**,
+   `docs/spec/harness/daemon.md`, and `docs/spec/harness/ingress.md`, so assigning it to
+   production is a cross-track identifier collision that also contradicts the accepted outcome
+   that the two raw MCP surfaces may differ.
+3. **"Every production reply invocation sends" is contradicted by live code.**
+   `packages/client/src/channel-base/reply-guard.ts` is tracked source on the candidate tree and
+   pre-checks a consumed marker before sending. An implementer taking the sentence literally
+   would remove the only protection against double-posting.
+4. **Source-event attribution was flipped without amending the linked ledger.** The trajectory
+   records the named decision-maker answering `A` to a prompt selecting `conversation_busy`
+   without a second lease, and summarizes it as *selects*. The candidate recharacterizes that as
+   *requested*, leaving each ADR and its own evidence ledger telling different stories.
+5. **Non-atomic landing.** `docs/architecture/harness-implementation-slate.md` still specifies
+   dispatch leases and `conversation_busy` as production work, contrary to the requirement that a
+   decision land atomically with its affected architecture pages.
+6. **Partial scrubs inside edited files.** `docs/spec/harness/output.md` retains `LeaseId` in the
+   same enumeration from which the candidate removed `lease` elsewhere, and
+   `docs/spec/management.md § Search` retains an unqualified membership-DTO prohibition that
+   `docs/spec/harness/client.md` narrowed to the network wire, so two Gate-1 chapters now state
+   different membership rules. No manifest trace row was updated for the membership narrowing.
+
+## Independently discovered paths and headings
+
+`AGENTS.md` (Constitution; ADR admission, record shape, provenance, lifecycle; Blind teammate
+review gate; Docs authority order) · `docs/decisions/` (52 records) · `docs/decisions/README.md`
+· `20260801-model-output-is-start-or-bound-reply.md` ·
+`20260801-inbound-notifications-separate-content-from-grants.md` ·
+`20260801-harness-client-owns-runtime-context.md` · `20260728-gate-1-architecture-freeze.md`
+(rows G1-DEC-600, 608, 610, 633, 635, 637, 638, 639, 640, 641) ·
+`20260728-endpoint-daemon-speaks-modern-mcp.md` · `docs/spec/harness/client.md`,
+`ingress.md`, `output.md`, `daemon.md` · `docs/spec/management.md` (§ Registration and status,
+§ Search) · `docs/architecture/harness-implementation-slate.md` · `v2/VISION.md` ·
+`docs/decision-evidence/20260801-harness-mcp-and-dispatch-trajectory.md` (§ Source record and
+compaction method; § Busy behavior answer; § Production registration must recover a lost success;
+§ Model output is start or bound reply; § Source gaps, inherited mechanics, and excluded candidate
+detail) · `packages/client/src/harness-mcp-wire.ts`, `channel-core.ts`,
+`channel-core-enrichment.ts`, `channel-base/reply-guard.ts` ·
+`packages/openclaw-channel/src/openclaw-entry.ts` ·
+`packages/server/src/identity/agents/auth.service.ts`
+
+## Discovery trail
+
+`AGENTS.md` → `git show --stat` and `git diff` of the candidate commit → `docs/decisions/`
+listing and index → the three edited ADRs in full → `docs/decision-evidence/` listing with
+quarantined names filtered → the linked trajectory in full → search for `events-v1` across
+`packages/`, `v2/`, `docs/` → search for `lease`, `LeaseId`, `conversation_busy` across docs and
+source → the three harness spec chapters → `management.md` and the manifest trace rows →
+repository-wide search for `_meta` and `xyz.moltzap` → `harness-mcp-wire.ts` → `v2/VISION.md` →
+the reply guard and `openclaw-entry.ts` → conversation enrichment and `registerAgent`.
+
+## Author verification of the findings
+
+Performed after delivery, recorded for the maintainer rather than to contest the result.
+
+- Blocker 1 reproduced. `v2/VISION.md` states *selected* and was not updated.
+- Blocker 2 partially qualified. `HARNESS_EVENTS_EXTENSION = "xyz.moltzap/events-v1"` and the
+  `_meta` route do exist, but only on the unmerged production stack, not on the candidate tree or
+  on `main`. The reviewer's characterization of the claim as unverifiable is therefore too strong
+  for the code's existence, and exactly right for its status: the candidate describes behavior no
+  merged branch carries. The cross-track ownership collision it raises stands unqualified and was
+  missed entirely by the author.
+- Blocker 3 reproduced. `packages/client/src/channel-base/reply-guard.ts` is tracked source on the
+  candidate tree. The author's premise that PR #941 removed local duplicate-reply suppression was
+  wrong.
+- Blocker 4 reproduced and is the most serious. The author conflated *was this selected* with
+  *did `main` implement it*. Absence of an implementation does not unmake a recorded decision.
+- Blockers 5 and 6 reproduced.
+
+Five of six blockers reproduce from the repository alone. The candidate's direction holds — four
+of its factual corrections check against code — but it asserts more than the evidence supports.
+
+## Maintainer disposition
+
+Pending. Reviewer prose is not self-certifying, and a FAIL blocks landing regardless.
+
+Per the gate's rerun rule, a reworked candidate must be frozen anew and reviewed by a **different**
+fresh reviewer.

docs/decisions/20260728-gate-1-architecture-freeze.md

@@ -323,7 +323,7 @@ pin each decision:
 | G1-DEC-637 | The local MCP management surface uses paginated `search_agents` and `search_conversations`. Harness introduces no agent or conversation summary wrapper, replacement identifier, or new domain value, and the naming does not rename Registry or Ledger operations. Empty-query behavior and the exact backing-owned agent and conversation result projections remain unresolved rather than being assigned here. | `docs/spec/management.md` — Search and Explicitly deferred | `MCP`, `DEFER` |
 | G1-DEC-638 | `HarnessClient` owns current- and cross-conversation runtime context and stable per-target/source presentation checkpoints. It advances the relevant checkpoints immediately before emitting a turn and reconstructs missing context from conversation search and history after restart. A crash after advancement but before runtime receipt can lose that context; no runtime acknowledgment or replay is added. The storage format and algorithm remain unspecified. | `docs/spec/harness/client.md` — Context ownership and Local presentation checkpoints | `MCP` |
 | G1-DEC-639 | Inbound content and reply authority are independent. Every observation identifies its source ConversationId; content-only observation updates client context without invoking the model, and only a live backing-owned grant can produce a replyable turn. No common replacement raw notification wire is defined, and a backing without an admitted content-only method and Schema cannot implement that path yet. | `docs/spec/harness/ingress.md` — Content and reply authority and Explicitly deferred | `MCP`, `PROTO`, `DEFER` |
-| G1-DEC-640 | The clean-slate Harness retains at most one live reply authority per ConversationId through its existing per-conversation grant serialization. The selected production target—`conversation_busy`, no competing lease, local retry, and independent progress for other conversations—remains `main`-owned work and is not admitted by this v2 row. | `docs/spec/harness/ingress.md` — Same-conversation exclusion | `MCP`, `PROTO`, `DEFER` |
+| G1-DEC-640 | The clean-slate Harness retains at most one live reply authority per ConversationId through its existing per-conversation grant serialization. A production target—`conversation_busy`, no competing lease, local retry, and independent progress for other conversations—was requested but remains unselected on `main`, and is not admitted by this v2 row. | `docs/spec/harness/ingress.md` — Same-conversation exclusion | `MCP`, `PROTO`, `DEFER` |
 | G1-DEC-641 | The portable model-output surface is conversation start with initial content plus a turn-bound `reply(payload)` closure and has no generic established-conversation send. Each backing retains its already owned START mechanics; the clean-slate backing retains atomic OperationId-based START, raw `reply(TxnId, actionId, payload)`, ReplyFingerprint over that same closed input, receipts, reconciliation, results, and errors. The payload-to-action mapping for a grant with several legal actions remains unselected and blocks that portable clean-slate case. | `docs/spec/harness/output.md` — Purpose and boundary, Conversation start, Established-conversation reply, Generic send removal, and Explicitly deferred | `MCP`, `L3`, `PROTO`, `DEFER` |
 | G1-DEC-642 | The former Endpoint subsystem and `v2/endpoint` package are named Harness and `v2/harness`; the per-profile daemon binary is `moltzapd`, and runtime adapters consume `HarnessClient` rather than constructing Harness internals. | `docs/spec/layer-interfaces.md` — Package graph and Public exports and binaries; `docs/spec/harness/client.md` — Purpose and compatibility boundary | `ARCH`, `INT` |
 

docs/decisions/20260801-harness-client-owns-runtime-context.md

@@ -41,8 +41,8 @@ compile time.
 
 The two raw MCP surfaces may differ. Each client decodes its backing's existing
 messages and exposes the same consumer behavior to OpenClaw and NanoClaw. No
-backing-specific reply authority or correlation—such as a production lease or
-clean-slate TxnId/action identifier—reaches those adapters. There is no reply
+backing-specific reply authority or correlation—such as a natively captured
+route or a clean-slate TxnId/action identifier—reaches those adapters. There is no reply
 token or implementation-generation discriminator, and MCP client plumbing
 stays private.
 
@@ -55,7 +55,11 @@ and history internally to rebuild its presentation context.
 The MCP tools are named `search_agents` and `search_conversations`, not
 `list_*`, and their results are paginated. Harness introduces no agent or
 conversation summary wrapper, membership DTO, replacement identifier, or new
-domain value.
+domain value **on the network wire**. A backing may enrich the value it passes
+across its own loopback MCP boundary with membership its endpoint already
+holds, because that projection is endpoint-owned presentation data that never
+reaches another principal. The canonical network `Conversation` is unchanged,
+and a client does not write such an enrichment back onto that wire.
 
 The source exchange leaves empty-query behavior and the exact agent- and
 conversation-search result projections unresolved. A backing may reuse an

docs/decisions/20260801-inbound-notifications-separate-content-from-grants.md

@@ -16,9 +16,9 @@ grant cannot contribute to later cross-conversation context. If the client
 deduplicates only by message identity, already-seen content can also suppress a
 later valid grant.
 
-Production dispatch leases and clean-slate transactions carry different reply
-authority. Their wires do not need to become identical for their clients to
-present the same model-facing behavior.
+Each backing carries reply authority in its own native form. Their wires do
+not need to become identical for their clients to present the same
+model-facing behavior.
 
 ## Considered Options
 
@@ -43,15 +43,16 @@ A content-only notification is retained as possible current or
 cross-conversation context and does not invoke the model. A notification with
 live authority allows `HarnessClient` to construct one turn for that
 conversation and bind the backing-specific authority into `reply(payload)`.
-ConversationId identifies and groups context; it is not a substitute for a
-dispatch lease, TxnId, or action selection.
+ConversationId identifies and groups context. Identifying context is a
+separate act from carrying authority, and it does not stand in for whatever
+native route or action selection a backing captures.
 
 The clean-slate Harness permits at most one live reply authority for a
 ConversationId and retains its already accepted per-conversation grant and
-Ledger mechanics. The matching production-line target—including
-`conversation_busy`, no competing lease, and local retry—was selected in the
-source discussion but remains `main`-owned implementation work recorded in the
-non-normative slate. This v2 record does not amend the production contract.
+Ledger mechanics. A matching production-line target—including
+`conversation_busy`, no competing lease, and local retry—was requested in the
+source discussion. It is `main`-owned and remains unselected there; this v2
+record neither admits nor amends a production contract.
 
 Receive delivery retains the accepted single-listener, acknowledgment-first,
 transient, at-most-once MCP subscription contract. Subscription acknowledgment

docs/decisions/20260801-model-output-is-start-or-bound-reply.md

@@ -39,16 +39,23 @@ backing therefore retains its OperationId-based atomic START; this record does
 not create a new production START transaction or failure contract.
 
 For an established conversation, a runtime adapter receives only the
-`reply(payload)` function bound to its current turn. The portable call has no
-reply token, action identifier, TxnId, dispatch lease, ConversationId, or
-generation selector. The corresponding `HarnessClient` implementation captures
+`reply(payload)` function bound to its current turn. The portable call carries
+no backing correlation: no reply token, action identifier, TxnId,
+ConversationId, or generation selector. The corresponding `HarnessClient` implementation captures
 the exact native authority from that turn's raw notification.
 
 The clean-slate direct MCP contract remains
 `reply(TxnId, actionId, payload)`. Its ReplyFingerprint remains canonical
 `(TxnId, actionId, payload)`, and its accepted grant validation, durable Ledger
 result, receipt reconciliation, retry, and error behavior remain unchanged.
-The production implementation continues to use its dispatch lease privately.
+The production implementation's reply authority is the originating
+ConversationId, carried privately in MCP `_meta` under the
+`xyz.moltzap/events-v1` extension. Every production reply invocation sends,
+and that path carries no lease, reply token, action identifier, turn
+identifier, or expiry. The private `_meta` carriage stops at `HarnessClient`
+and does not reach `reply(payload)`. Production reply carriage remains
+`main`-owned; this record states it to fix what the portable projection
+captures and does not amend that branch.
 
 The source exchange did not choose how a payload-only closure selects among
 multiple legal clean-slate actions. The clean-slate portable projection must