planr 1.9.0 → 1.10.0-alpha.2

package/docs/documentation/CONTRACT.md

@@ -34,7 +34,7 @@ Use these terms exactly. Prefer the lowercase form in prose unless it starts a s
 | pick | An atomic lease of one ready item to one worker. | assignment, claim unless explaining the concept |
 | worker | The identity holding the active pick. | agent when ownership specifically matters |
 | log | Durable evidence or progress attached to an item. | transcript |
-| verification log | A log with kind `verification` that records a live oracle. | test result alone |
+| verification log | A claim-only narrative log for a live oracle; frozen pre-Evidence compatibility may inspect it. | binding Evidence receipt or coverage verdict |
 | review | A graph gate that checks evidence and can create fix/follow-up work. | approval; approvals are a separate human gate |
 | approval | An explicit requested/approved/denied human decision on an item. | review |
 | context | A durable discovery, decision, constraint, or goal contract. | memory |

package/docs/documentation/COVERAGE.md

@@ -4,7 +4,7 @@ This is the canonical inventory that maps shipped public surfaces to repository
 
 ## Published route inventory
 
-The site currently owns 63 MDX routes. Next.js also emits the landing page and framework support routes during the production build.
+The site currently owns 66 MDX routes. Next.js also emits the landing page and framework support routes during the production build.
 
 | Section | Published routes |
 | --- | --- |
@@ -13,9 +13,9 @@ The site currently owns 63 MDX routes. Next.js also emits the landing page and f
 | For Agents | `/docs/agents`, `/docs/agents/quickstart`, `/docs/agents/prompt-recipes`, `/docs/agents/skills` |
 | Integrations | `/docs/integrations`, `/docs/integrations/codex`, `/docs/integrations/claude-code`, `/docs/integrations/cursor`, `/docs/integrations/grok-build`, `/docs/integrations/pi`, `/docs/integrations/generic-mcp`, `/docs/integrations/cli-only` |
 | Plugins | `/docs/plugins`, `/docs/plugins/switchloom` |
-| Concepts | `/docs/concepts`, `/docs/concepts/local-first-model`, `/docs/concepts/plans-and-map`, `/docs/concepts/graph-and-readiness`, `/docs/concepts/picks-and-leases`, `/docs/concepts/evidence-and-context`, `/docs/concepts/reviews-and-approvals`, `/docs/concepts/recovery-packages-and-closure` |
-| Guides | `/docs/guides`, `/docs/guides/daily-worker-loop`, `/docs/guides/parallel-coordination`, `/docs/guides/handoff-and-resume`, `/docs/guides/review-and-fix-loops`, `/docs/guides/recover-interrupted-work`, `/docs/guides/packages-and-reuse`, `/docs/guides/recipes` |
-| Reference | `/docs/reference`, `/docs/reference/cli`, `/docs/reference/cli-generated`, `/docs/reference/mcp`, `/docs/reference/mcp-schemas-generated`, `/docs/reference/http-api`, `/docs/reference/configuration-and-storage`, `/docs/reference/data-and-status`, `/docs/reference/outputs-and-errors`, `/docs/reference/support-matrix`, `/docs/reference/maintenance` |
+| Concepts | `/docs/concepts`, `/docs/concepts/local-first-model`, `/docs/concepts/plans-and-map`, `/docs/concepts/graph-and-readiness`, `/docs/concepts/picks-and-leases`, `/docs/concepts/evidence-and-context`, `/docs/concepts/evidence-trust-model`, `/docs/concepts/reviews-and-approvals`, `/docs/concepts/recovery-packages-and-closure` |
+| Guides | `/docs/guides`, `/docs/guides/daily-worker-loop`, `/docs/guides/parallel-coordination`, `/docs/guides/handoff-and-resume`, `/docs/guides/review-and-fix-loops`, `/docs/guides/recover-interrupted-work`, `/docs/guides/packages-and-reuse`, `/docs/guides/evidence-scenarios`, `/docs/guides/recipes` |
+| Reference | `/docs/reference`, `/docs/reference/cli`, `/docs/reference/cli-generated`, `/docs/reference/mcp`, `/docs/reference/mcp-schemas-generated`, `/docs/reference/http-api`, `/docs/reference/evidence`, `/docs/reference/configuration-and-storage`, `/docs/reference/data-and-status`, `/docs/reference/outputs-and-errors`, `/docs/reference/support-matrix`, `/docs/reference/maintenance` |
 | Contributing | `/docs/contributing`, `/docs/contributing/repository-setup`, `/docs/contributing/architecture`, `/docs/contributing/docs-authoring`, `/docs/contributing/testing`, `/docs/contributing/security-and-privacy` |
 | Operations | `/docs/operations`, `/docs/operations/release`, `/docs/operations/versioning-and-migrations`, `/docs/operations/docs-deployment`, `/docs/operations/health-and-diagnostics`, `/docs/operations/rollback`, `/docs/operations/documentation-governance` |
 | Help | `/docs/troubleshooting`, `/docs/faq` |
@@ -32,9 +32,11 @@ The site currently owns 63 MDX routes. Next.js also emits the landing page and f
 | Items, links, statuses, readiness | `src/model.rs`, `src/app/repository/item.rs`, `src/app/lease.rs` | `/docs/concepts/graph-and-readiness` |
 | Picks, leases, concurrency, progress | `src/app/lease.rs`, `src/app/flow.rs` | `/docs/concepts/picks-and-leases`, `/docs/guides/parallel-coordination` |
 | Logs, contexts, artifacts, live evidence | `src/app/application.rs`, `src/app/inspection.rs` | `/docs/concepts/evidence-and-context` |
+| Binding Evidence trust model | `src/evidence/`, `src/app/evidence.rs`, `docs/contracts/EVIDENCE_CONTRACT_V1.md` | `/docs/concepts/evidence-trust-model`, `/docs/reference/evidence`, `/docs/guides/evidence-scenarios` |
 | Reviews, approvals, fix chains | `src/app/review.rs`, `src/app/flow.rs`, `src/app/application.rs` | `/docs/concepts/reviews-and-approvals`, `/docs/guides/review-and-fix-loops` |
 | Recovery, conditions, packages, closure | `src/app/recovery.rs`, `src/app/packages.rs`, `src/app/flow.rs` | `/docs/concepts/recovery-packages-and-closure`, `/docs/guides/recover-interrupted-work`, `/docs/guides/packages-and-reuse` |
 | Worker loop, handoff, recipes | application flow and lease owners | `/docs/guides/daily-worker-loop`, `/docs/guides/handoff-and-resume`, `/docs/guides/recipes` |
+| Copy-paste Evidence scenarios | `apps/docs/scripts/generate-evidence-examples.mjs`, `tests/fixtures/evidence/docs/` | `/docs/guides/evidence-scenarios` |
 
 ## CLI, MCP, HTTP, and data contracts
 
@@ -47,6 +49,7 @@ The executable and schema sources decide exact inventory. Editorial pages explai
 | MCP transport, resources, prompts, results | `src/app/mcp.rs`, `src/integrations.rs`, fixture | `/docs/reference/mcp` |
 | Every MCP tool input schema | live MCP discovery, schema generator | `/docs/reference/mcp-schemas-generated` |
 | Local HTTP/SSE and review routes | `src/app/http.rs` | `/docs/reference/http-api` |
+| Evidence CLI/MCP/HTTP contracts and classifications | `src/evidence/`, `src/cli/evidence.rs`, `src/app/evidence.rs` | `/docs/reference/evidence` |
 | Environment, installers, storage, repository files | CLI/install/storage owners | `/docs/reference/configuration-and-storage` |
 | DTOs, IDs, statuses, links, SQLite tables, packages | `src/model.rs`, `src/storage/schema.rs` | `/docs/reference/data-and-status` |
 | JSON output, error codes, exit/recovery behavior | application and surface adapters | `/docs/reference/outputs-and-errors` |
@@ -88,7 +91,7 @@ The executable and schema sources decide exact inventory. Editorial pages explai
 
 ## Audit completion checklist
 
-- [x] All 63 current MDX routes are explicitly inventoried.
+- [x] All 66 current MDX routes are explicitly inventoried.
 - [x] Every public product, CLI, MCP, HTTP, data, client, contributor, and operations surface has a current target and canonical source owner.
 - [x] Generated CLI and MCP inventories are separated from editorial guidance and mechanically checked.
 - [x] Retired aliases are isolated in `apps/docs/redirects.mjs` and resolve to a current route.

package/docs/documentation/INFORMATION_ARCHITECTURE.md

@@ -20,7 +20,7 @@ This file records the implemented route and navigation contract. Routes are publ
 
 ## Implemented route tree
 
-The 62 MDX files below are the current page tree and must agree with every `meta.json` file and `COVERAGE.md`.
+The 66 MDX files below are the current page tree and must agree with every `meta.json` file and `COVERAGE.md`.
 
 ```text
 /docs

package/docs/fixtures/mcp-contract.json

@@ -42,6 +42,24 @@
     "planr_artifact_show",
     "planr_event_list",
     "planr_debug_bundle",
+    "planr_evidence_policy",
+    "planr_evidence_obligation_add",
+    "planr_evidence_obligation_list",
+    "planr_evidence_obligation_show",
+    "planr_evidence_migrate",
+    "planr_evidence_rebind",
+    "planr_evidence_classifications",
+    "planr_evidence_capability_list",
+    "planr_evidence_capability_show",
+    "planr_evidence_run",
+    "planr_evidence_import",
+    "planr_evidence_host_capture_import",
+    "planr_evidence_host_capture_run",
+    "planr_evidence_attempts",
+    "planr_evidence_receipts",
+    "planr_evidence_coverage",
+    "planr_evidence_explain",
+    "planr_evidence_readiness",
     "planr_eval_suite_check",
     "planr_eval_run",
     "planr_eval_show",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "planr",
-  "version": "1.9.0",
+  "version": "1.10.0-alpha.2",
   "description": "Local-first planning and execution coordination for coding agents.",
   "license": "MIT",
   "repository": {
@@ -14,6 +14,9 @@
   "files": [
     "npm/bin/planr.js",
     "npm/native",
+    "scripts/host-capability-experiment.mjs",
+    "scripts/host-capability-runtime",
+    "scripts/planr-host-capability-validator",
     "plugins",
     "README.md",
     "LICENSE.md",
@@ -29,12 +32,19 @@
     "verify:pnpm-workspace": "node scripts/verify-pnpm-workspace.mjs",
     "verify:release-eval-gate": "node scripts/test-release-eval-gate.mjs",
     "verify:release-script": "node scripts/test-release-script.mjs",
+    "verify:change-classifier": "node scripts/test-verification-policy.mjs",
+    "verify:runner": "node scripts/test-verification-runner.mjs",
+    "verify:ci-router": "node scripts/test-ci-router.mjs",
+    "verify:docs-deployment": "node scripts/test-docs-deployment.mjs",
+    "classify:changes": "node scripts/classify-changes.mjs",
+    "verification:run": "node scripts/verification-runner.mjs run",
+    "verification:verify": "node scripts/verification-runner.mjs verify",
     "pack:check": "npm pack --dry-run",
     "docs:dev": "pnpm --filter @planr/docs dev",
     "docs:alchemy:dev": "pnpm --filter @planr/docs alchemy:dev",
     "docs:build": "pnpm --filter @planr/docs build",
     "docs:start": "pnpm --filter @planr/docs start",
-    "docs:deploy": "pnpm --filter @planr/docs run deploy",
+    "docs:deploy": "node scripts/deploy-docs.mjs",
     "docs:destroy": "pnpm --filter @planr/docs run destroy",
     "docs:content": "pnpm --filter @planr/docs content",
     "docs:typecheck": "pnpm --filter @planr/docs typecheck",
@@ -45,12 +55,15 @@
     "docs:verify-agent-journey": "pnpm --filter @planr/docs verify:agent-journey",
     "docs:verify-agent-landing": "pnpm --filter @planr/docs verify:agent-landing",
     "docs:verify-concepts": "cargo build --bin planr && pnpm --filter @planr/docs verify:concepts",
+    "docs:verify-evidence-docs": "pnpm --filter @planr/docs verify:evidence-docs",
     "docs:verify-maintenance": "pnpm --filter @planr/docs verify:maintenance",
     "docs:sync-linux-portability": "pnpm --filter @planr/docs sync:linux-portability",
     "docs:verify-deployment": "pnpm --filter @planr/docs verify:deployment",
     "docs:verify-release": "pnpm --filter @planr/docs verify:release",
     "docs:verify-release-live": "pnpm --filter @planr/docs verify:release-live",
     "docs:verify-clean-install": "pnpm --filter @planr/docs verify:clean-install",
+    "docs:evidence-examples:generate": "cargo build --bin planr && pnpm --filter @planr/docs evidence-examples:generate",
+    "docs:evidence-examples:check": "cargo build --bin planr && pnpm --filter @planr/docs evidence-examples:check",
     "verify:switchloom-cross-product": "node scripts/verify-switchloom-cross-product.mjs",
     "docs:reference:generate": "cargo build --bin planr && pnpm --filter @planr/docs reference:generate",
     "docs:verify-reference": "cargo build --bin planr && pnpm --filter @planr/docs reference:check && pnpm --filter @planr/docs verify:reference"

package/plugins/planr/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "planr",
   "description": "Skill-driven planning and execution loop for coding agents: one planr entry point, an autonomous planr-loop, and evidence-backed task graph skills powered by the planr CLI.",
-  "version": "1.9.0",
+  "version": "1.10.0-alpha.2",
   "author": {
     "name": "instructa"
   },

package/plugins/planr/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "planr",
-  "version": "1.9.0",
+  "version": "1.10.0-alpha.2",
   "description": "Skill-driven planning and execution loop for coding agents: one $planr entry point, an autonomous $planr-loop, and evidence-backed task graph skills powered by the planr CLI.",
   "author": {
     "name": "instructa",

package/plugins/planr/skills/planr-goal/SKILL.md

@@ -30,17 +30,20 @@ planr plan check <plan-id>
 planr map build --from <plan-id>
 ```
 
-Fill required plan sections directly. Replace the placeholder task with typically 4-8 independently verifiable `TASK-00n` slices before `planr map build`. Preserve real execution order with `blocks` links. When registry routes use `work_type`, annotate tasks before mapping or retag them afterward; this is prep work, not a user question.
+Fill required plan sections directly. Replace the placeholder task with independently verifiable `TASK-00n` slices before `planr map build`. A small coherent change is one implementation item plus one signal-bearing independent review; do not split mechanical stages into separate implementation/review pairs. Larger scopes still use multiple slices where ownership, dependencies, or independently observable outcomes genuinely differ. Preserve real execution order with `blocks` links. When registry routes use `work_type`, annotate tasks before mapping or retag them afterward; this is prep work, not a user question.
+
+When the repository provides a versioned verification policy and source-bound receipt runner, make that policy the verification owner in the plan. Record the selected profile, exact receipt path/digest, source revision, and the command that validates the receipt. Do not enumerate broad suites independently in every task when the policy already selects them.
 
 ## Durable Contract
 
-Store one contract per plan:
+For plans with binding Evidence, require the repository to define the observation obligations and capability policy before execution, then run readiness. Store one contract per plan:
 
 ```bash
-planr context add "GOAL CONTRACT <plan-id>: DONE when every in-scope item is closed with log evidence, all reviews are complete, approvals are clear, and a live verification log proves <goal oracle>. Iteration budget: 10." --tag goal-contract
+planr evidence readiness --scope plan --id <plan-id>
+planr context add "GOAL CONTRACT <plan-id>: DONE when every in-scope item is closed with implementation evidence, all reviews are complete, approvals are clear, and canonical Evidence coverage proves <goal oracle>. Iteration budget: 10." --tag goal-contract
 ```
 
-Never weaken it mid-run. Workers use `planr pick --plan <plan-id>`; termination uses `planr plan audit <plan-id> --json`. Reviews are required only where they add signal; evidence-backed setup work may close directly.
+Never weaken it mid-run. Workers use `planr pick --plan <plan-id>`; termination uses `planr plan audit <plan-id> --json`. Reviews are required only where they add signal; evidence-backed setup work may close directly. Where deployment is in scope, the contract must retain human deployment approval and a bounded live oracle against the deployed result.
 
 ## Hand Off
 

package/plugins/planr/skills/planr-loop/SKILL.md

@@ -13,16 +13,19 @@ Evaluation subcommands run only when the user explicitly requests them, the sele
 
 Recover the stored `GOAL CONTRACT <plan-id>` from Planr every iteration. If absent, store one that requires settled items with evidence, complete reviews, clear approvals, and a live oracle. Never weaken it.
 
+At the start of the host thread that drives an active goal, run `planr stop activate --plan <plan-id>` once. Codex hosts should let Planr use `CODEX_THREAD_ID`; otherwise provide a stable explicit session with `--session <id>`. Leave the binding active until `planr plan audit <plan-id> --json` returns `holds: true`. Run `planr stop deactivate --plan <plan-id>` only for explicit user cancellation or after a durable ownership transfer has activated the same plan in the successor session; a budgeted handoff alone must not deactivate an unfinished goal.
+
 Each iteration follows the Planr stage protocols:
 
 1. `planr plan audit <plan-id> --json`; `holds: true` exits.
-2. Use `$planr-plan` or `$planr-task-graph` only when scope or graph structure is missing.
-3. Dispatch `$planr-work` for exactly one ready item scoped to `<plan-id>`; makers must use `planr pick --work-type code --plan <plan-id>`, never an unscoped pick, and finish implementation with `planr done <item-id> ... --review`.
-4. Run the target-platform oracle and record `planr log add --item <id> --kind verification --summary ... --cmd ...`.
-5. Dispatch `$planr-review`; findings create fix work, while `complete --close-target` settles the target.
-6. Repeat from audit.
+2. For a binding Evidence plan, run `planr evidence readiness --scope plan --id <plan-id>`. Repair typed schema/capability/runtime gaps before product work. Use `planr evidence rebind --input <file>` and the returned preview digest only when an immutable adapter/obligation binding must be corrected without changing acceptance semantics.
+3. Use `$planr-plan` or `$planr-task-graph` only when scope or graph structure is missing.
+4. Dispatch `$planr-work` for exactly one ready item scoped to `<plan-id>`; makers must use `planr pick --work-type code --plan <plan-id>`, never an unscoped pick, select the repository verification policy, and finish implementation with `planr done <item-id> ... --review`.
+5. Run the configured target-platform method with `planr evidence run --input <run-file>`, then evaluate `planr evidence coverage --scope criterion --id <criterion-id>` and inspect gaps with `planr evidence explain ...`. Deployment still requires prior human approval and a bounded live oracle. Narrative logs never substitute for binding receipts.
+6. Dispatch `$planr-review`; the checker independently inspects the diff and validates the exact-source receipt, replaying only cheap, missing, failing, or explicitly high-risk evidence. Findings create fix work, while `complete --close-target` settles the target.
+7. Repeat from audit.
 
-One picked item per iteration. Use plain `done` only for low-signal setup/inspection work. Maker and checker stay separate when the host supports another agent; a maker never self-reviews when an independent checker is available, and never manufactures independence by changing worker identity. A worker may use `done --next`, which never returns its own review.
+One picked item per iteration. A small coherent change stays one implementation item with one signal-bearing review; do not create a new review boundary for every mechanical stage or for an already-reviewed successful live smoke. Use plain `done` only for low-signal setup/inspection work. Maker and checker stay separate when the host supports another agent; a maker never self-reviews when an independent checker is available, and never manufactures independence by changing worker identity. The reviewer must exercise independent judgment even when it relies on a green receipt rather than replaying an expensive gate. A worker may use `done --next`, which never returns its own review.
 
 Pick packets explain null results and include `remaining`; follow their repair command. Destructive or out-of-repository effects require `planr approval request`. Two iterations without map movement must stop. On success or budget exhausted, finish with `$planr-summary`.
 
@@ -41,9 +44,9 @@ For generated Codex roles: The `spawn_agent` tool call itself must include `agen
 
 ## Verification And Recovery
 
-“Done” means the feature ran. For web dispatch `$planr-verify-web`; for CLI execute the built binary; for API use real requests; for iOS launch the simulator. Log the replayable command. If the capability is missing, record a blocker context, request approval, and pause—never fake proof.
+“Done” means the feature ran. For web dispatch `$planr-verify-web`; for CLI execute the built binary; for API use real requests; for iOS launch the simulator. Log the replayable command. A passing bounded live oracle is evidence for the existing review boundary, not a reason to start another full reviewer replay. If the capability is missing, record a blocker context, request approval, and pause—never fake proof.
 
-Recovery starts in a fresh session with audit, map state, the stored contract, and the next scoped pick. Read [recovery and platform details](references/recovery-and-verification.md) only when that branch is active.
+Recovery starts in a fresh session with audit, map state, Evidence readiness/explain, the stored contract, and the next scoped pick. A terminal unchanged Stop gap remains terminal; use `planr stop resume --plan <plan-id>` only after an explicit operator decision to reopen its bounded continuation window. Read [recovery and platform details](references/recovery-and-verification.md) only when that branch is active.
 
 ## Hard Rules
 

package/plugins/planr/skills/planr-loop/references/recovery-and-verification.md

@@ -16,9 +16,10 @@ Use `planr pick stale --older-than-seconds 900` before releasing abandoned owner
 Verification:
 
 ```bash
-planr log add --item <item-id> --kind verification \
-  --summary "verified <flow>: <observed outcome>" \
-  --cmd "<exact replayable command>"
+planr evidence readiness --scope criterion --id <criterion-id>
+planr evidence run --input <run-file>
+planr evidence coverage --scope criterion --id <criterion-id>
+planr evidence explain --scope criterion --id <criterion-id>
 ```
 
-Use browser automation for web, the built binary for CLI, real requests for API/backend, and simulator launch plus exercised flow for iOS. If tooling is unavailable, store blocker context, request approval, and pause.
+Use a capability whose declared observations cover the criterion: browser automation for rendered web behavior, the built binary for CLI, real requests for API/backend, and simulator launch plus exercised flow for iOS. If tooling is unavailable, preserve the typed blocker, request approval when appropriate, and pause. Do not replace it with a weaker method that observes different facts.

package/plugins/planr/skills/planr-plan/SKILL.md

@@ -68,6 +68,6 @@ Match by the task's actual work (UI/components/styling -> a `frontend` route, AP
 
 Planning is complete only when `planr plan check <plan-id>` passes and the next command is clear: split further, build map, or ask the user for a blocking decision.
 
-When the map is built, linked, and tagged, end by naming the execution handoff explicitly — the user should never have to guess the next prompt: `Use $planr-loop on plan <build-plan-id>. Stop condition: all items closed with evidence, reviews complete, live verification logged.` (On hosts with a /goal primitive, `$planr-goal` wraps the same loop for long-running autonomous runs.)
+When the map is built, linked, and tagged, end by naming the execution handoff explicitly — the user should never have to guess the next prompt: `Use $planr-loop on plan <build-plan-id>. Stop condition: all items closed with evidence, reviews complete, canonical Evidence coverage holds.` (On hosts with a /goal primitive, `$planr-goal` wraps the same loop for long-running autonomous runs.)
 
 `plan check` rejects empty scaffolds: build plans must have content in `## Scope Decision`, `## Verification`, and `## Acceptance Criteria`; product plans must have content in `## Problem`, `## Requirements`, and `## Success Criteria` of `PRODUCT_SPEC.md`. Write those sections before checking — do not pad them to satisfy the gate.

package/plugins/planr/skills/planr-review/SKILL.md

@@ -18,7 +18,9 @@ planr --json pick --work-type review
 
 `--work-type review` leases only review items, so a checker never accidentally takes maker work. Add `--plan <plan-id>` when your dispatch names a plan so the lease stays inside that scope. The pick packet inlines the target item and its evidence logs under `target` — one command is enough to see what is being audited, its status (`in_review` while waiting on you), files, and verification commands. If you already hold a review id, `planr --json trace item <review-id>` returns the same packet. Use `planr log list --item <target-id>` or `planr map show --json` only for deeper reads.
 
-Inspect the actual changed files and re-run the logged verification evidence. Then close the review exactly once:
+Inspect the actual changed files and acceptance criteria, then independently judge whether the evidence proves them. When the repository owns a versioned verification policy, verify the logged receipt against its exact source revision, policy digest, changed-file digest, selected gates, command results, and artifact digests. Use the repository's receipt validator (for this repository, `npm run verification:verify -- --receipt <path> --base <base-revision> --head <source-revision>`), not a visual read of JSON.
+
+Replay only evidence that is cheap, missing, failing, or explicitly high-risk. An already-green expensive gate bound to the reviewed source is normally validated from its receipt rather than rerun. Receipt validation does not replace judgment: inspect the diff for security, correctness, scope, and acceptance-criteria gaps, and record a finding when the policy selection or receipt is inadequate. Then close the review exactly once:
 
 ```bash
 planr review close <review-id> --verdict complete --reviewer <your-id> --close-target
@@ -36,8 +38,10 @@ planr review close <review-id> --verdict not-complete --reviewer <your-id> --fin
 
 - Findings must be specific and actionable.
 - Missing tests are findings when acceptance criteria need proof.
+- A stale, mismatched, unvalidated, or insufficiently scoped receipt is a finding.
 - Architecture or ownership drift is a finding when it creates duplicate policy or state owners.
 - If evidence is insufficient, use `--verdict unclear` rather than complete.
+- Deployment remains gated by explicit approval and a bounded live oracle where applicable. A successful live smoke does not by itself require another broad build or a second full review; replay it only under the same cheap/missing/failing/explicitly-high-risk rule.
 
 ## Single-Agent Mode
 

package/plugins/planr/skills/planr-status/SKILL.md

@@ -34,9 +34,11 @@ When a loop or `/goal` run asks whether its stop condition holds, use the one-ca
 
 ```bash
 planr plan audit <plan-id> --json
+planr evidence readiness --scope plan --id <plan-id>
+planr evidence explain --scope plan --id <plan-id>
 ```
 
-It reads the stored contract, evaluates every clause with evidence (items settled, reviews complete, approvals clear, verification logged), and answers `holds: true/false` with the open items listed per clause. Report `contract holds` or `contract open` plus the exact unmet clauses straight from the audit output. Use `planr search "GOAL CONTRACT"` only to read the contract text itself.
+Audit answers `holds: true/false` from settled items, reviews, approvals, and canonical Evidence coverage. Readiness reports configuration/runtime blockers before execution; explain reports exact receipt applicability and gaps. Report `contract holds` or `contract open` plus the exact unmet clauses straight from these outputs. Use `planr search "GOAL CONTRACT"` only to read the contract text itself.
 
 ## Verdicts
 

package/plugins/planr/skills/planr-verify-web/SKILL.md

@@ -41,15 +41,16 @@ Detect a running dev server before anything else and use it. Never start a secon
 
 Exercise the flow the item changed — not the homepage. Interact, assert on rendered output, capture a screenshot when the tier supports it.
 
-Then log evidence on the item:
+Use the repository's configured web capability to create trusted Evidence, then evaluate coverage:
 
 ```bash
-planr log add --item <item-id> --kind verification \
-  --summary "live verification (<tier>): <what was exercised and observed>" \
-  --cmd "<exact replayable command>"
+planr evidence readiness --scope criterion --id <criterion-id>
+planr evidence run --input <run-file-for-the-configured-web-method>
+planr evidence coverage --scope criterion --id <criterion-id>
+planr evidence explain --scope criterion --id <criterion-id>
 ```
 
-`--kind verification` marks the log as live-verify evidence; `planr plan audit` checks for it when a goal contract exists.
+The observation contract decides what must be proved. Native Browser, CDP, Playwright, Computer Use, and HTTP probes are configurable methods, not a universal ranking. HTTP can fully prove an HTTP criterion but cannot satisfy rendered interaction, persistence, accessibility, console, or visual observations it never captured.
 
 Attach screenshots or traces as artifacts on the item:
 
@@ -58,7 +59,9 @@ planr artifact add "verify-web screenshot" --item <item-id> --path <screenshot-p
 planr artifact add "verify-web recording" --item <item-id> --path <recording.mp4> --kind video
 ```
 
-The replay command is mandatory. The reviewer reruns it instead of trusting this run; a verification that cannot be replayed is not evidence.
+The replay contract and trusted method identity are mandatory. The reviewer validates the receipt and reruns it only when it is cheap, missing, failing, or explicitly high-risk; a verification that cannot be replayed when needed is not evidence. A successful bounded live smoke joins the existing coherent review boundary and does not automatically trigger another full build or reviewer replay.
+
+For a deployment oracle, require an approved deployment decision before the deploy begins. After deployment, keep the live check bounded to the changed routes, content, or interaction and record the deployed source/receipt identity in the summary.
 
 ## When Verification Is Impossible
 

package/plugins/planr/skills/planr-work/SKILL.md

@@ -22,15 +22,27 @@ The pick output is one flat work packet — item, links, logs, runtime, recovery
 planr done <item-id> --summary "what changed" --files path-a --files path-b --cmd "exact verification command" --tests "exact test command" --review
 ```
 
+Before choosing ad hoc checks, inspect the repository's versioned verification policy. When it supplies a runner, use that runner once for the changed-file set and preserve its exact-source receipt. For this repository the canonical flow is:
+
+```bash
+npm run verification:run -- --receipt .planr/receipts/<name>.json --base <base-revision> --head <source-revision>
+npm run verification:verify -- --receipt .planr/receipts/<name>.json --base <base-revision> --head <source-revision>
+```
+
+Record the receipt path, digest, source revision, selected profile/gates, and copy-paste replayable validation command in the completion evidence. Do not manually add broader suites that the selected policy does not require, and do not rerun an expensive green gate merely to hand work to the reviewer.
+
 Put build/serve commands in `--cmd` and test runs in `--tests` — both are recorded as evidence. When the pick packet carries a `routing` block, also report the registry profile you actually ran on: add `--profile <profile-id>` to `done`/`log add`, or export `PLANR_PROFILE` once per session. It is part of the evidence — a mismatch with the declared route is advisory (never blocks the close) and surfaces in `planr trace item` so silent host overrides get caught. Include the decisive output line in `--summary` (e.g. "12 tests passed", "GET /videos returned 3 entries"): reviewers see your recorded command strings, not your terminal, so the summary must carry what you observed, not just what you ran. Single-quote `--files` values that contain `$` (route files like `watch.$videoId.tsx`), or the shell expands them before planr sees them. `done --review` writes the completion log, requests the review, and moves the item to `in_review` (you keep ownership; it is waiting on the gate, not abandoned) — the response names the target's new status and the plan-scoped reviewer pick command; add `--next` to pick the following item in the same call. Without `--review` it closes the item directly (only for items that need no review gate). Running `done` on a ready item you never picked adopts it: the lease is written retroactively under your worker id so the review always has a maker. The response reports what your settlement `unlocked`, echoes the item's post condition, and hints when downstream work depends on an item closed without command/test evidence.
 
-Live verification (browser flow, executed binary, real requests) gets its own log kind so `plan audit` can find it:
+Binding verification (browser flow, executed binary, real requests) must produce a trusted Evidence receipt and coverage verdict:
 
 ```bash
-planr log add --item <item-id> --kind verification --summary "verified <flow>: <observed outcome>" --cmd "<exact command>"
+planr evidence readiness --scope criterion --id <criterion-id>
+planr evidence run --input <run-file>
+planr evidence coverage --scope criterion --id <criterion-id>
+planr evidence explain --scope criterion --id <criterion-id>
 ```
 
-The `--cmd` value must be copy-paste replayable: a real shell command (or a small script you committed), never a prose transcript like "start server; curl /; check stats". A reviewer replays your command verbatim — if it cannot run, the verification cannot be independently confirmed.
+The configured method must be copy-paste replayable: a real shell command, host capture, or committed verifier, never prose such as "start server; curl /; check stats". Reviewers validate the exact-source receipt and selectively replay cheap, missing, failing, or explicitly high-risk evidence. `planr log add` remains useful for narrative handoffs, but a free-form `kind=verification` claim has no binding closure authority.
 
 Log persistent evidence, not transient noise: a failure you immediately fixed belongs in the final log's narrative, not as a standalone failure log. Only record a failure separately when it blocks the item.
 
@@ -59,6 +71,8 @@ planr approval request <item-id> --reason "release approval"
 planr approval list --open
 ```
 
+Deployment is always such a gate: obtain approval before deployment and record a bounded live oracle afterward. Keep that oracle on the same coherent implementation/review boundary; a successful smoke does not automatically require another full build or review replay.
+
 ## Rules
 
 - Do not work on multiple picked items unless the user explicitly asks.