planr 1.10.0-alpha.9 → 2.0.0

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

@@ -1,26 +0,0 @@
-# Recovery And Verification
-
-Load this only for an interrupted item or the live-verification stage.
-
-Recovery:
-
-```bash
-planr plan audit <plan-id> --json
-planr trace item <item-id> --json
-planr log list --item <item-id> --json
-planr context list --item <item-id> --json
-```
-
-Use `planr pick stale --older-than-seconds 900` before releasing abandoned ownership. Pause a legitimate wait with `planr pick pause`; resume it with `planr pick resume`.
-
-Verification:
-
-```bash
-planr evidence verify --scope plan --id <plan-id> --json
-```
-
-The verify result owns plan coverage and settlement. Use criterion-scoped coverage or explain only to diagnose an explicit gap, with a real criterion id rather than a requirement id. A verifier or environment failure stops without an automatic retry.
-
-The Evidence broker executes only the sealed run index from its own readiness stage. A repository-authored obligation, declarative index, guessed digest path, or remembered run filename is not executable Evidence input.
-
-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

@@ -1,86 +0,0 @@
----
-name: planr-plan
-description: Create or refine Planr product plans and build plans before implementation. Use for app ideas, PRDs, architecture slices, scoped implementation contracts, and converting broad work into map-ready items.
----
-
-# Planr Plan
-
-Read and apply the canonical [Evidence ownership guard](../planr/SKILL.md#evidence-ownership-guard) before product planning.
-
-Use this when scope, ownership, acceptance criteria, or verification must be defined before implementation.
-
-## Workflow
-
-```bash
-planr project show --json
-planr plan new "App idea" [--platform web] [--ai] [--backend]
-planr plan refine <plan-id> --note "decision, constraint, or assumption"
-planr plan check <plan-id>
-planr plan split <plan-id> --slice "narrow implementation slice"
-planr map build --from <build-plan-id>
-```
-
-## Product Plan Standard
-
-A product plan package must include:
-
-- manifest;
-- product spec;
-- UX flows;
-- design system;
-- architecture;
-- ADRs;
-- AI spec when relevant;
-- safety/privacy/security;
-- API/data model;
-- client and backend implementation specs;
-- observability;
-- QA;
-- release readiness;
-- executable tasks;
-- references.
-
-## Build Plan Standard
-
-A build plan must include:
-
-- source plan;
-- a non-empty `criteria` frontmatter list whose entries contain only a stable `id` and `title`;
-- scope decision;
-- ownership target;
-- existing leverage;
-- phases;
-- out of scope;
-- verification;
-- acceptance criteria.
-
-Author criterion identity only in frontmatter, for example:
-
-```yaml
-criteria:
-  - id: criterion-api-health
-    title: API health is observable from the target service
-```
-
-Keep the `## Acceptance Criteria` section as readable narrative, never an identity source. Do not infer criterion IDs from prose or decide obligation completeness in this skill; `plan check`, explicit Evidence migration, and the canonical `app/proof` authority own those decisions.
-
-## Route-Aware Tagging
-
-Before writing the task list, check whether the project declares model routing: `planr agents list --json`. If routes exist, their `work_type` selectors are the project's use-case vocabulary (e.g. `frontend`, `backend`, `design`) — and tagging is your job, not the user's; never ask a human to name work types.
-
-Declare the use case in the task list itself — `map build` seeds annotated tasks with that work type directly:
-
-```markdown
-### TASK-001 (backend): REST API for todos
-- [ ] (frontend) Build the form and list view
-```
-
-Match by the task's actual work (UI/components/styling -> a `frontend` route, API/server/storage -> `backend`, and so on); unannotated tasks stay `code`, which the default route covers. For maps that were already built without annotations, retag instead: `planr item update <item-id> --work-type frontend`. The payoff: every pick packet then carries the right profile, model, and paired skill for its use case, so dispatch needs no human routing knowledge.
-
-## Done
-
-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, canonical Evidence coverage holds, and any explicitly required material reviews are complete.` (On hosts with a /goal primitive, `$planr-goal` wraps the same loop for long-running autonomous runs.)
-
-`plan check` rejects empty scaffolds: build plans need a valid unique `criteria` frontmatter list plus 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

@@ -1,55 +0,0 @@
----
-name: planr-review
-description: Review a Planr item or scoped implementation against map state, plan acceptance criteria, logs, changed files, and verification evidence. Use for findings-first audits and review gates.
----
-
-# Planr Review
-
-Use this when a task needs a correctness and completion audit.
-
-## Workflow
-
-Export your checker identity once per session so the lease attributes to you:
-
-```bash
-export PLANR_WORKER_ID=checker-1
-planr --json pick --work-type review
-```
-
-`--work-type review` leases only durable ReviewGates, so a checker never accidentally takes maker work. Continue only when `work_packet.kind` is `review_gate`; read the gate, FeatureRun, responsible maker, attempts, findings, phase, budget, and source revision from its canonical `execution_state`. Add `--plan <plan-id>` when your dispatch names a plan so the lease stays inside that scope. Use `planr review show <review-gate-id> --json`, `planr review evidence <scope-item-id> --json`, or `planr trace item <scope-item-id> --json` only for deeper reads.
-
-Require `planr.execution_state.v2` and treat its budget projection as opaque. Skills must not recompute budget policy or reinterpret provenance, reserves, digest, or deadline.
-
-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 check 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 ReviewGate exactly once:
-
-```bash
-planr review close <review-gate-id> --verdict complete --reviewer <your-id>
-```
-
-`--reviewer` records the independent checker identity on the immutable attempt and event. An accepted risk checkpoint resumes the responsible maker's FeatureRun; an accepted final product gate completes the FeatureRun. A second close without a fresh leased gate fails — never retry a close that succeeded.
-
-or:
-
-```bash
-planr review close <review-gate-id> --verdict not-complete --reviewer <your-id> --findings "specific actionable finding"
-```
-
-## Findings Rules
-
-- 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.
-
-## Independent Identity
-
-ReviewGate closure requires a reviewer identity distinct from the responsible maker and matching the active reviewer lease. Keep one `PLANR_WORKER_ID` per agent instance and always pass `--reviewer <id>` when shell exports do not survive between tool calls. Never manufacture independence by changing identities inside one agent instance.
-
-## Completion Rule
-
-The FeatureRun may complete only after its required ReviewGates are accepted. Use the FeatureRun and ReviewGate projections as the source of truth.
-Pending or denied approval is also a close blocker; treat an attempted close through that gate as a finding, not as completion.

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

@@ -1,52 +0,0 @@
----
-name: planr-status
-description: Report honest Planr project, map, item, or review state without implementing changes. Use when the user asks what is done, what remains, what is blocked, what is ready, or what should be picked next.
----
-
-# Planr Status
-
-Use read-only Planr commands first:
-
-```bash
-planr project show --json
-planr map show --json
-planr map lane --critical
-planr map pressure
-```
-
-For one item:
-
-```bash
-planr trace item <item-id>
-planr log list --item <item-id>
-```
-
-For active work, include runtime and approval state from `trace item`, `map status`, or:
-
-```bash
-planr approval list --open
-planr pick stale --older-than-seconds 900
-```
-
-## Goal Contract Check
-
-When a loop or `/goal` run asks whether its stop condition holds, use the one-call verdict:
-
-```bash
-planr plan audit <plan-id> --json
-planr evidence readiness --scope plan --id <plan-id>
-planr evidence explain --scope plan --id <plan-id>
-```
-
-Audit answers `holds: true/false` from settled outcomes, explicitly required independent material ReviewGates, approvals, and canonical Evidence coverage. Binding Evidence success does not require a final product ReviewGate. 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
-
-Use one:
-
-- `complete`: closed with evidence and no open required child/review/approval work.
-- `in progress`: concrete work remains and the next step is available.
-- `blocked`: progress needs an external decision or prerequisite.
-- `unclear / partially verified`: evidence is incomplete or inconsistent.
-
-Never treat checked Markdown boxes or optimistic summaries as proof. Map state and log evidence decide.

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

@@ -1,30 +0,0 @@
----
-name: planr-summary
-description: Summarize a Planr scope after work, review, or status inspection. Use when the user wants what changed, why, what works now, verification evidence, and what remains.
----
-
-# Planr Summary
-
-Build the summary from current Planr evidence:
-
-```bash
-planr map show --json
-planr plan audit <plan-id> --json
-planr trace item <item-id>
-planr log list --item <item-id>
-```
-
-## Output
-
-Include:
-
-- scope;
-- what changed;
-- why;
-- what works now;
-- verification commands and results;
-- open blockers or unverified items;
-- any explicitly required material ReviewGate state when the summary is plan-scoped;
-- next recommended Planr command.
-
-If completion is not proven, say so directly and recommend `planr-status` or `planr-work`; recommend `planr-review` only when an explicit material ReviewGate is open.

package/plugins/planr/skills/planr-task-graph/SKILL.md

@@ -1,67 +0,0 @@
----
-name: planr-task-graph
-description: Coordinate Planr plans, map dependencies, leases, evidence, approvals, reviews, handoffs, and interruption recovery.
----
-
-# Planr Task Graph
-
-Read and apply the canonical [Evidence ownership guard](../planr/SKILL.md#evidence-ownership-guard) before product graph preparation or making.
-
-Use Planr as the canonical local coordinator. Markdown plans own scope and narrative; the map is the source of truth for live items, links, picks, approvals, logs, reviews, and closure.
-
-Evaluation subcommands run only when the user explicitly requests them, the selected item's acceptance criteria require them, or the maintainer release workflow invokes them. Never invoke them as routine or opportunistic goal, loop, or task-graph work.
-
-## Inspect And Work
-
-Before changes:
-
-```bash
-planr project show --json
-planr map show --json
-planr map lane --critical
-planr map pressure
-```
-
-If missing, initialize the project and run `planr doctor --client all`.
-
-Work one item at a time:
-
-```bash
-planr pick --json
-planr done <item-id> --summary "<outcome and decisive result>" \
-  --files <path> --cmd "<build or live command>" \
-  --tests "<test command>"
-```
-
-Continue only from the typed packet you were authorized to perform. Makers consume `work_packet.kind: "outcome"`; `mode: "finding_repair"` repairs named findings on the same ReviewGate without a fix item, and `kind: "hold"` stops. Read lifecycle state only from `work_packet.execution_state`.
-
-Require `planr.execution_state.v2`. Its budget projection is opaque; skills must not recompute budget policy or replace supplied consumed, reserved, protected, available, provenance, digest, or deadline values.
-
-Every closure must be evidence-backed: changed files through `--files`, commands through `--cmd`, tests through `--tests`, remaining risk through context or findings, and a `planr review` outcome only when an explicit material ReviewGate exists. Plain `planr done` is the standard outcome settlement. Branch on the returned `work_packet.transition` and `work_packet.kind`: continue only for another compatible outcome; stop for a ReviewGate, verification packet, hold, incompatible ownership or scope, or an empty pick. Use `--escalate <reason>` only for an allowed intentional override, always with `--escalation-ref <stable-reference>` and `--escalation-explanation <why-the-override-is-required>`; never use escalation to replace computed materiality. Keep longer work current with `planr pick progress`, `pause`, and `resume`.
-
-## Plans And Dependencies
-
-Create/refine/check the plan, expand it into independently verifiable tasks, then `planr map build --from <plan-id>`. Annotate routed work types before mapping or retag afterward.
-
-Create ordering explicitly with `planr link add <earlier> <later> --type blocks`; readiness comes from graph state, not Markdown checkboxes. Validate generated order and remove only incorrect links. Use `planr item breakdown <parent> --into <child>...` for a parent gate; later top-level work depends on the parent, which rolls up after children settle.
-
-## Reviews And Approvals
-
-Plain `planr done` settles outcome evidence and lets FeatureRun materiality open or reuse a durable ReviewGate. Close a leased gate with `planr review close <review-gate-id> --verdict complete --reviewer <reviewer-id>`. Findings use `--verdict not-complete`; Planr appends an attempt and durable findings to that same gate. The responsible maker repairs the named findings and resolves them with `planr review findings <review-gate-id> --resolve <finding-id>` before re-review.
-
-Human gates use `planr approval request <item-id> --reason <reason>`. Never close with an open or denied approval.
-
-## Handoff And Recovery
-
-Use item notes for nearby handoff and contexts for reusable decisions. Logs are evidence, not chat summaries.
-
-After interruption inspect Git status, map state, then:
-
-```bash
-planr trace item <item-id>
-planr log list --item <item-id>
-planr context list --item <item-id>
-planr pick stale --older-than-seconds 900
-```
-
-Release stale ownership only after inspection. Do not claim completion until children and explicitly required material reviews are closed, approvals are clear, verification commands ran, findings became settled follow-up work, and the user-facing summary matches Planr state.

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

@@ -1,62 +0,0 @@
----
-name: planr-verify-web
-description: Frozen-source live verification for a web FeatureRun. Consumes a canonical verification work packet, uses the configured Evidence capability, and records trusted proof without editing product source.
----
-
-# Planr Verify Web
-
-Prove the frozen feature runs. Planr owns the evidence contract and capability selection; the host executes the configured method. Never install or configure browser infrastructure on behalf of this skill.
-
-## Run The Typed Verification Packet
-
-Keep verification in the coordinator. Use one stable worker identity that differs from the responsible maker. Do not spawn another model.
-
-```bash
-PLANR_WORKER_ID="coordinator-verifier-1" planr evidence verify --scope plan --id <plan-id> --json
-```
-
-This command leases verification, probes readiness, seals the run index, executes the configured adapter, evaluates coverage, and settles the FeatureRun. Product source is read-only. Only Planr runtime state, receipts, logs, and artifacts may change.
-
-Require `planr.execution_state.v2`; its budget and absolute deadline are opaque supplied authority. Skills must not recompute budget policy. If the selected adapter cannot honor required capability or the packet is held, stop with that exact classification.
-
-If readiness is blocked, do not choose another unregistered tool or downgrade the observation. The FeatureRun enters a capability hold. Report the returned gap and `next_action`, then stop. Repair the policy, schema, adapter digest, runtime registration, or permissions before you run the same verify command again.
-
-## Target Lifecycle
-
-The configured Evidence adapter owns target startup, connection, and cleanup. Do not manually start a duplicate browser or application process unless the sealed work packet explicitly declares an externally managed target.
-
-## Run The Verification
-
-Exercise the flow the item changed — not the homepage. Interact and assert on the required rendered output. Capture a screenshot only for a visual criterion or failure diagnostics.
-
-Use only the repository capability selected by the active obligation. Read `object.coverage`, `object.feature_run_verification_settlement`, and `object.verification_broker` from the verify result. Do not issue per-criterion coverage or explain commands on the normal path. They are diagnostic commands for a known gap, and `--scope criterion` accepts a criterion id, never a requirement id.
-
-The observation contract decides what must be proved. Native Browser, CDP, Playwright, Computer Use, and HTTP probes are configurable methods, not interchangeable fallbacks. HTTP can prove an HTTP criterion but cannot satisfy rendered interaction, persistence, accessibility, console, or visual observations it never captured. `planr evidence verify` checks the canonical `SOURCE_PATHS` digest inside the transaction. A mismatch records a failed non-covering attempt and commits zero trusted receipts.
-
-Attach screenshots or traces as artifacts on the item:
-
-```bash
-planr artifact add "verify-web screenshot" --item <item-id> --path <screenshot-path> --kind screenshot
-planr artifact add "verify-web recording" --item <item-id> --path <recording.mp4> --kind video
-```
-
-The replay contract and trusted method identity are mandatory. A successful bounded live verification closes a Binding Evidence FeatureRun directly when all ordinary outcomes and coverage are settled. It does not trigger another model, reviewer, build, or bookkeeping gate. An explicitly required material ReviewGate remains independent of this normal closure path.
-
-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
-
-If no configured capability is available or the runtime is unreachable, do not fake Evidence or downgrade it. The broker records the capability hold. Preserve that exact classification.
-
-```bash
-planr evidence verify --scope plan --id <plan-id> --json
-planr context add "verification hold: <readiness gap code and capability>" --tag blocker
-```
-
-Then stop until the reported capability contract is repaired. A manual approval cannot convert a missing capability into trusted Evidence.
-
-## Outcome
-
-- Pass: the same `evidence verify --json` result reports satisfied plan coverage and a complete FeatureRun settlement. Do not call `planr done`; the implementation outcome was already settled before source freeze.
-- Product failure: Planr routes a product finding back to the responsible maker. The maker receives an outcome repair packet and fixes only the finding. The coordinator then re-freezes the source and calls `evidence verify` for only invalidated Evidence.
-- Verifier or environment failure: record the non-covering attempt and stop immediately. Do not retry, create a new verifier lease, or open an ad hoc ReviewGate. A later run is allowed only after the reported capability or environment state has materially changed.

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

@@ -1,93 +0,0 @@
----
-name: planr-work
-description: Execute one Planr outcome item to evidence-backed settlement in its FeatureRun. Use after code work has been picked or when the next step is implementation, docs, tests, scripts, integration work, or finding repair.
----
-
-# Planr Work
-
-Before product implementation that requires binding Evidence, inspect the
-repository's existing Evidence policy and configured capability. If either is
-absent, record the exact gap code, capability, and next action, then stop. Do not
-create or weaken verification infrastructure to bypass the hold unless repairing
-that infrastructure is the explicit task.
-
-Use this for one picked item at a time.
-
-## Workflow
-
-Export your worker identity once per session so picks, logs, and heartbeats attribute to you instead of `client:host:user`:
-
-```bash
-export PLANR_WORKER_ID=maker-1
-planr pick --json
-```
-
-The pick output is one flat typed packet. Branch only on `work_packet.kind` and, for outcome work, optional `work_packet.mode`; read lifecycle facts only from `work_packet.execution_state`. `kind: "outcome"` with an item id is ordinary maker work. `kind: "outcome", mode: "finding_repair"` has no synthetic fix item: repair the named findings on the same ReviewGate, log evidence against the gate's scoped outcome, resolve those finding ids, and stop for re-review. `kind: "hold"` is a stop, not permission to replace the maker or bypass policy. Each fact appears once; a missing key means "empty". No separate `trace item` call is needed. Add `--work-type code` to lease only outcome work while checker agents lease ReviewGates, and `--plan <plan-id>` when your dispatch names a plan. A null pick explains itself with a reason, remaining snapshot, exclusions, and a repair command when applicable. Read the linked plan/context, implement the smallest correct slice, then finish ordinary outcome work in one command:
-
-Require `work_packet.execution_state.schema_version` to be `planr.execution_state.v2`. Treat its `budget` object—including consumed, reserved, protected, available, provenance, contract digest, and absolute task deadline—as opaque runtime authority. Skills must not recompute budget policy; a hold or unavailable required value is a stop.
-
-```bash
-planr done <item-id> --summary "what changed" --files path-a --files path-b --cmd "exact verification command" --tests "exact test command" --next
-```
-
-Use `--next` when the dispatch authorizes a compatible same-plan maker run. Settlement, the internal three-outcome batch rollover, and the next plan-scoped code lease then happen atomically. Omit `--next` for a standalone outcome.
-
-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.
-
-Before relying on materiality outcomes, confirm the project has selected a committed `.planr/policy.toml`. Missing policy is fail-closed and may require review, but it is not an efficiency baseline; dogfood maker runs should use the repository policy profile and `planr done --next` so materiality, not unconditional escalation, decides.
-
-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 --next` is the standard settlement path inside an authorized compatible maker run: Planr records the completion once, lets FeatureRun materiality decide whether to interrupt, atomically rolls an internal capped batch for the same maker when required, and leases only compatible code work from the same plan. Plain `done` settles a standalone outcome without leasing more work. Intentional escalation beyond computed materiality uses `--escalate <reason>` with `--escalation-ref` and `--escalation-explanation`. If settlement returns a review gate or reports `materiality.effective_review.required: true`, stop; the FeatureRun is waiting on that gate. If settlement returns `next.reason: "verification_handoff_source_frozen"`, stop: source is frozen and the response carries the exact `commands.verify` command for the coordinator. Running `done` on a ready outcome you never picked adopts it under your worker id. The response reports the FeatureRun transition and what the settlement unlocked. Do not add a second ordinary `log add` after `done`; the settlement already persisted the completion log.
-
-Binding verification (browser flow, executed binary, real requests) must produce a trusted Evidence receipt and coverage verdict. During a compatible multi-outcome maker run, implementation settlement uses the repository's ordinary changed-file checks and `planr done --next`; it must not run Evidence or an opportunistic browser smoke while later compatible outcomes can still change the source. Planr caps each internal ExecutionBatch at three outcomes and rolls it for the same maker inside `done --next`; that boundary is not a reason to wake the root or reload skills. Keep the same maker through stable source freeze. Write a compact durable handoff only when the run stops for a material review, incompatible ownership, a blocker, an empty pick, a budget boundary, or stable source freeze. After source freeze, the invoking loop session becomes the coordinator and runs the handoff packet's exact `commands.verify` command under an identity that differs from the maker. Do not spawn a verifier model. The Evidence broker executes the configured adapter and checks the canonical `SOURCE_PATHS` digest before any trusted receipt commit. Product findings route back to the responsible maker. After repair, the coordinator re-freezes and calls `evidence verify` again. The only exception is a material review that requires an affected exact-source criterion before more implementation. Record that boundary and stop for its review.
-
-```bash
-planr evidence verify --scope plan --id <plan-id> --json
-```
-
-Only the coordinator runs this command after source freeze. The configured method must be replayable: use a real shell command, host capture, or committed verifier, never prose such as "start server; curl /; check stats". The result includes plan coverage and FeatureRun settlement. Criterion-scoped coverage and explain are diagnostic only and require a criterion id, not a requirement id. `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.
-
-Evidence logging refreshes the heartbeat automatically — a separate `planr pick heartbeat` is only needed for long silent stretches without logs.
-
-Finding-repair packets use the granular evidence command because they have no outcome item to settle:
-
-```bash
-planr log add --item <item-id> --summary "..." --files a --files b --cmd "..."
-```
-
-For longer work, keep runtime state current:
-
-```bash
-planr pick progress <item-id> --percent 50 --note "tests running"
-planr pick pause <item-id> --note "waiting for human input"
-planr pick resume <item-id>
-```
-
-If a human approval gate is required, request it before close and wait for an approved decision:
-
-```bash
-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 FeatureRun/ReviewGate boundary; a successful smoke does not automatically require another full build or gate replay.
-
-## Rules
-
-- Do not work on multiple picked items unless the user explicitly asks.
-- Do not close without evidence.
-- Do not confuse item completion evidence with frozen-source binding Evidence. Defer binding Evidence until source freeze unless a material review requires it.
-- Do not create workflow-only repair items for a failed review. Repair the named findings under the responsible maker, resolve their ids on the same ReviewGate, and return that gate to re-review.
-- Do not call `planr done` for a finding-repair packet that has no item. Log the repair on the ReviewGate's scoped outcome, then use `planr review findings <gate-id> --resolve <finding-id>`.
-- Do not close items with pending or denied approval.
-- Use `planr context add ... --item <item-id>` for discoveries another client needs.
-- Use `planr pick stale --older-than-seconds 900` before resetting abandoned ownership.
-- Use `planr pick release <item-id> --force` only when ownership must be reset.