Clarify verification receipt reuse across roles

CHANGELOG.md

@@ -2,6 +2,35 @@
 
 All notable changes to SkipHow 2.x and later appear in this file. Earlier release notes remain available on [GitHub Releases](https://github.com/mzored/SkipHow/releases).
 
+## 6.3.3 (2026-10-08)
+
+Delegates, leads, and reviewers reuse a verifiable passing result when the command, tree fingerprint,
+and relevant environment are unchanged. Checking a return, reviewing, integrating, or reporting does
+not require executing it again. Changed inputs, missing or unverifiable evidence, or a concrete named
+doubt justify another run. A different fingerprint never establishes a pass for the current tree.
+
+Verification defines the minimal record in existing logs or handoffs: command and arguments, checked
+fingerprint, terminal exit, completion time, checkout, accessible evidence, and relevant environment.
+Ignored configuration, scratch inputs, service state, and uncertain capture still limit applicability.
+Required coverage, independent review, destination inspection, and `agent-verify inherited` remain intact.
+
+The fixed host-log sample found 28 same-label, same-fingerprint repeats in 116 completed runs, 24.1%
+of runs and 9.6% of execution time. Command identity was absent, so this is a proxy, not a measured
+same-command or avoidable-work share. No wording cause, behavioral improvement, or savings is claimed.
+Five new arm-aware decision probes remain `UNVERIFIED`. No paid behavioral experiment or clean-install
+session was run. Package structure and installation are unchanged; no host configuration was edited.
+See [current evidence](docs/evidence.md#633-verification-receipt-reuse).
+
+Independent isolated Codex source review approved the candidate with no qualifying material findings.
+It inspected runtime responsibilities, the five probes and arm expectations, version metadata, canonical
+documentation, and site evidence. No finding required correction or was rejected. Source review proves
+neither model adherence nor the private measurement records; the maintainer reproduced the aggregate.
+
+The local deterministic gate passed on the reviewed source. Its non-blocking headroom lint required
+a bounded editorial tightening of delegation; focused package/document validation covers that correction.
+Revision-bound CI supplies full evidence for the integrated candidate. Clean installs and behavioral
+sessions stay `UNVERIFIED` in the release validation matrix.
+
 ## 6.3.2 (2026-10-08)
 
 Contributor checks now use the optional installed `agent-verify` host queue before their subprocess

VERSION

@@ -1 +1 @@
-6.3.2
+6.3.3

docs/decisions.md

@@ -25,7 +25,7 @@ The live decisions, their premises, and what would reopen each. "Evidence" says
 | Read-only analysis writes nothing; established owner-authorized non-production workflows cover routine delivery and tracking, settling what may travel and not how often, so the lead groups related accepted results into reviewable delivery units without holding independent finished work for unrelated pending work; assignment handoff and final delivery can have different destinations, and local combination grants no publication; a series of owner-reviewed changes stays in iteration until the owner requests delivery or accepts with nothing further to send, and an invoked iteration workflow keeps its own boundary until delivery is requested | Explicit planning-skill invocation requests durable records, but automatic selection grants nothing; fast-fixes acceptance stays inside iteration; preparation and production remain separate grants | Owner-selected workflow contracts preserve ordinary SkipHow behavior, existing grants, audience boundaries, and downstream-effect checks | `Contract`; assignment and delivery wording aligned in 5.1.3 by inspection; workflow behavior `UNVERIFIED` | A receipt shows unauthorized effects, missing records requested by invocation, unnecessary permission questions, per-assignment publication, premature closure after local handoff, or unrelated blocked work delaying delivery |
 | Every branch, worktree, checkout, checkpoint, running service, and uncommitted change in a project is the lead's own engineering state, made by this session, an earlier one, or a delegate, and completion is relative to the authorized destination; on a request that changes the project, integrated leftovers of earlier sessions that nothing holds are retired as routine hygiene, a superseded or abandoned attempt with unique commits is retired on the lead's judgment with its commit named, uncommitted changes the run did not make and a live session's lane stay untouched, and none of it is attributed to the owner or a third party or handed back to them | The owner writes no code and no third party does, so state reported as someone else's is a false report and a decision handed to the one person who cannot make it; a named destination is incomplete until verified there; retiring one's own recoverable state is engineering, not the material deletion the exact-grant rule protects | Liveness is readable from changes still moving, an open review, a live record, or a session the host lists, and not from a name, a timestamp, or a running process alone; Git recovers a deleted branch's commit and nothing recovers an uncommitted file; a read-only request grants nothing | `Contract` (5.0.0; destination-relative completion 4.0; naming duty 4.8); integration and custody cases in `evals/`, not run | Receipts show a run retiring a live session's lane or an uncommitted file, retiring as abandoned an attempt whose defect is still present, retiring anything under a read-only request, a small change growing a sweep material beside it or custody ceremony in every report, a project where a human writes code put under SkipHow, or the owner asking for a retired branch back or for report-and-wait again |
 | No technical choice reaches the owner, and a running result shown to them names the branch or revision and the address it serves | The owner never handling engineering is the boundary this product exists to hold; a recommendation the owner can decline is not a question that stops the work | Reversible technical uncertainty is settled by taking the option the agent would defend; several checkouts of one project answer on the same default address | `Contract` (4.8); the corpus forbids technical approval, tracker interviews, and test-selection questions in five cases, none run | Receipts show the recommendation channel being used to hand product choices back, or an owner asking for the technical options they no longer see |
-| Verification proves each property at the narrowest stable boundary that retains the needed fidelity; distinct high-fidelity evidence survives; recurring disproportionate cost is measured at its responsible layer; equivalent inputs reuse valid evidence | The 4.6.0 release repeated equivalent gates, while the new verification-health cases distinguish coupling, setup cost, unique cross-boundary confidence, and proportional iteration | The relevant code, dependencies, configuration, environment, artifact, and destination determine whether evidence applies; test category, suite size, and speed alone establish neither cause nor adequacy | One installed 4.6.0 release session supports evidence reuse; the 4.7.0 placement and diagnosis rules are `Contract` with deterministic corpus coverage; behavior is `UNVERIFIED` | A run drops unique evidence, normalizes disproportionate churn, optimizes an unmeasured cause, or makes ordinary work heavier without preserving delivery confidence |
+| Verification proves each property at the narrowest stable boundary that retains the needed fidelity; distinct high-fidelity evidence survives; recurring disproportionate cost is measured at its responsible layer; matching command, tree fingerprint, and relevant environment reuse verifiable passing records across roles; changed inputs, unverifiable records, or named concrete doubts justify another execution | The 4.6.0 release repeated equivalent gates, while the new verification-health cases distinguish coupling, setup cost, unique cross-boundary confidence, and proportional iteration | The checked fingerprint identifies the actual state exercised; ignored or external inputs and destination remain relevant; a different fingerprint needs current-candidate evidence, including revision-bound CI; test category, suite size, and speed alone establish neither cause nor adequacy | One installed 4.6.0 release session supports evidence reuse; the 6.3.3 clarification is owner-requested `Contract`, with unrun arm-aware probes; causal and behavioral effects remain `UNVERIFIED` | A run drops unique evidence, normalizes disproportionate churn, optimizes an unmeasured cause, or makes ordinary work heavier without preserving delivery confidence |
 | Broad project-state reconciliation reconstructs before it mutates; status reports each leftover with the disposition a change request would give it, record correction changes records and retires nothing, and any request that changes the project retires integrated unheld leftovers; only a non-reconstructible outcome-to-workspace association becomes durable | Tracker state, branch names, merge status, and CI can each be stale or refer to the wrong outcome, revision, or destination; a parallel lifecycle registry would create another claim to reconcile | Live Git, reviews, destinations, and revision-specific validation establish every transition in the current cases; workspace ownership cannot always be reconstructed after a session ends | `Contract` and deterministic corpus validation (4.6.0; amended 5.0.0); behavior `UNVERIFIED` | A receipt finds live evidence insufficient to recover a material transition, the ownership association insufficient for safe recovery, or the ordering adding ceremony without preventing a failure |
 | Delegates are read-only without verified distinct isolation; the root serializes writes; lead and delegate model and effort are independent choices minimizing expected total cost within owner constraints; a route already shown adequate for comparable work survives; an unset control still resolves to some default, often the parent's route, so leaving it unset is a routing decision held to the same test; a brief states whether and how widely its delegate may dispatch delegates and at what route; a delegate receives the kernel's path and acts as CTO of its brief within the owner's authority the brief relays, fixing what it finds inside its surface and returning the rest, while the lead keeps owner questions, dispositions, and records; settings use actual host controls | One shared checkout has one index and one branch; a delegate's own account of its isolation is not proof; host controls change independently of this package; a review's independence and framing matter more than its level; a delegate may not have this guidance in context and its own delegates often inherit its route, so the brief is where nested fan-out is bounded | The active host supplies the controls a run can use; no portable writer-isolation or absolute-level interface exists across supported hosts, so unverifiable isolation takes the safe fallback | Failures `Observed` on 2.x (five lanes in one checkout; a worktree that reported success into the shared tree); the portable fallback is `Contract`, not run; writer lanes remain host-specific and must be verified; inherited delegate routes and unbriefed nested fan-out are readable in private 5.0.0 Claude sessions, and the 5.0.1 wording is `Contract`; one private 6.0.0 Claude session motivates the 6.1.0 delegate reading, which is `Contract` | A portable capability interface appears, a host makes isolation verifiable and default, or paired runs settle the routing cost question |
 | Prefer host-native execution; admit thin bindings when a demonstrated gap justifies them | Duplicated runtime state increases cost; optional skills reuse one kernel without a service or custom workers | Required outcomes survive implementation changes; new components need host schema, safety, and compatibility checks | Current package shape `Deterministic`; adapter benefits require receipts | A controlled check shows a host binding is needed to preserve an outcome |
@@ -40,6 +40,36 @@ The live decisions, their premises, and what would reopen each. "Evidence" says
 
 The sections below are the history behind those rows: what each release tried, measured, and rejected. They are non-normative. Where a section and the index disagree, the index is current and the section records how it got there.
 
+## Verification receipts across roles
+
+Version 6.3.3 clarifies existing evidence reuse after the owner identified repeated verification as material
+shared-host load. A fixed host-log sample found 28 same-label, same-fingerprint candidates in 116 completed
+runs. Command differences, scratch inputs, environment changes, and lost output explain why those counts
+cannot establish redundant passing checks or a wording cause. The [evidence ledger](evidence.md#633-verification-receipt-reuse)
+records the measurement boundary and uncertainties.
+
+The selected change tightens the existing kernel and verification reference. A delegate, lead, or reviewer
+can reuse an inspectable passing record for the same command, fingerprint, and relevant environment.
+The record carries command and arguments, checked fingerprint, terminal exit, completion time, checkout,
+and an accessible evidence location, plus relevant environment context. Existing logs and handoffs suffice.
+Changed inputs, missing or unverifiable evidence, or a concrete named doubt justify execution. A different
+fingerprint needs evidence for that candidate; relevant-file similarity cannot silently substitute for equality.
+This is deliberately conservative when a HEAD-inclusive fingerprint changes after a content-preserving commit.
+Revision-bound CI can establish the integrated state. Role and stage changes alone invalidate nothing.
+
+Required property coverage, risk-scaled independent review, scrutiny of returns, and destination verification
+survive. Fingerprint equality covers no ignored or external input by itself. A capture that cannot identify
+the stable state exercised establishes no reusable pass. The contributor `agent-verify inherited` protocol,
+host queue ownership, package structure, and installation path are unchanged.
+
+A reference-only clarification would cost fewer kernel characters but leave the invariant absent when that
+reference is not opened. A host result cache would add state, command/environment key design, and host coupling
+without evidence that this package needs an execution service. The selected prose rule uses existing evidence,
+adds no tool, file format, persistent ledger, or model experiment, and retains current host fallback behavior.
+It clarifies the promised runtime contract, so the release is PATCH. Behavioral improvement and savings remain
+`UNVERIFIED`. Reopen if a receipt shows stale evidence accepted, duplicated execution despite a matching record,
+missing required coverage, or evidence capture too costly to repay reuse.
+
 ## Planning boundaries and shared review continuation
 
 Version 6.3.1 clarifies the existing planning and independent-review contracts. One private installed Claude

docs/evidence.md

@@ -2,6 +2,55 @@
 
 This page separates package checks from observed model behavior. The full 2.0 evidence remains in the immutable [`v2.0.1` research snapshot](https://github.com/mzored/SkipHow/tree/1c811262e6acdbdc58a2ee862b54e0b8d3478eaa/docs/research/2026-08-27).
 
+## 6.3.3 verification receipt reuse
+
+On 2026-10-08, read-only inspection used the host admission events from 10:28:44.019 through
+12:18:20.126 UTC. The fixed cutoff excludes later events from the live append-only journal.
+There were 116 completed runs, with 2,191.686 total execution seconds. Count a repeat when an earlier
+completed run in the same checkout has the same label and non-null tree fingerprint, was admitted
+within the preceding 30 minutes, and completed before the later admission. Count each later run once.
+This gives 28 repeats, 24.1% of completed runs, consuming 209.539 seconds, 9.6% of execution time.
+These are same-label, same-fingerprint candidates, not a measured same-command repeat rate.
+
+The host journal has no command arguments or session/role correlation. Private transcript inspection
+confirmed at least two same-command, same-fingerprint repeats: a delegate retrieving truncated failure
+output, and a lead recovering an explicit terminal exit status before reporting. A pre-merge lead also
+repeated checks inside a differently composed batch. Other candidates ran different test selections or
+diagnostics, changed scratch fixtures, or changed environment settings. Those distinctions prevent treating
+the aggregate as redundant passing checks. Reviewer and lead-return duplicate rates, the exact same-command
+share, and avoidable execution time remain `UNVERIFIED`. The owner's earlier 81-hour, label-only estimate
+cannot be retroactively classified by tree. Private transcripts, host identifiers, and raw logs are not published.
+
+Source inspection found an ambiguity rather than a demonstrated cause. The kernel required checking returns
+against current state, fresh review, and final verification after the last edit, while verification and integration
+already permitted input-bound evidence reuse. None defined a minimal reusable check record in the kernel's
+execution path. No controlled before/after model receipt connects those sentences to the measured executions.
+
+The owner requested a clarification. Delegates, leads, and reviewers inspect existing passing records for the
+same command, tree fingerprint, and relevant environment. Changed inputs, missing or unverifiable evidence,
+or a concrete named doubt justify another execution. A different fingerprint requires current-candidate evidence,
+including revision-bound CI where available. Verification owns the record fields; delegation carries references
+and integration applies that rule. Required coverage, independent review, destination checks, and contributor
+admission remain intact. The asynchronous host fingerprint alone cannot establish that source inputs stayed
+stable throughout a check. Relevant ignored and external inputs remain part of applicability.
+
+Five original synthetic decision probes cover role transitions, tracked/untracked/history changes, changed
+commands and environments, scratch inputs outside the fingerprint, incomplete or failed records, uncertain
+capture, and conflicting results. They remain `UNVERIFIED`; deterministic corpus checks validate their shape
+and arm satisfiability only. No behavioral experiment or savings claim is attached to this release.
+The [decision](decisions.md#verification-receipts-across-roles) records alternatives and surviving responsibilities.
+
+Exact future telemetry would need command identity and session/role correlation. Reusable host receipts would
+also need an inspectable fingerprint query and evidence of the state actually exercised. These are external
+host requirements, not package dependencies. No host configuration or admission implementation was changed.
+
+Independent read-only Codex source review approved the runtime, corpus, metadata, canonical documentation,
+and site changes with no qualifying material findings. Isolated operating-system and host homes used a
+temporary minimal authentication reference. Control and review transcripts showed no personal skill or
+installed-plugin paths. The reviewer ran no verification commands or behavioral experiments and did not
+inspect private measurement records. The maintainer reproduced the fixed aggregate separately. Owned
+review resources and the authentication reference were removed after completion.
+
 ## 6.3.2 optional contributor-check admission
 
 [PR #143](https://github.com/mzored/SkipHow/pull/143) integrated optional host admission into both