pincer-workflow 0.7.0 → 1.0.1

package/template/.github/prompts/pincer-narrow.prompt.md

@@ -1,148 +0,0 @@
----
-mode: agent
-description: "Turn the approved PRD into local, AI-ready ticket files"
----
-<!-- Generated from .claude/commands/pincer-narrow.md by scripts/sync-prompts.sh — edit the source, not this file -->
-
-
-# /pincer-narrow — PRD to Local Tickets
-
-You are decomposing the PRD into coherent, independently verifiable tickets stored as
-local markdown files (no external tracker needed). Ticket count and size follow the
-change's dependencies and risk, plus any budget the user supplied. There is no hard
-one-to-two-ticket cap for small PRDs and no default timebox: cohesion and dependencies
-decide the count. A breakdown that follows the PRD needs no second approval; a newly
-discovered consequential choice is surfaced before implementation.
-
-**Initial request:** ${input:request:Task brief or arguments (optional)}
-
-## Steps
-
-1. Run `scripts/pincer-status.sh`. If tickets already exist for another PRD, leave them
-   as history. New tickets continue the numbering and existing ones are never renumbered.
-   If tickets already exist for this PRD, extend them only when the current request already
-   authorizes that work; otherwise present the concrete addition before asking. Then read the
-   PRD (`${input:request:Task brief or arguments (optional)}` or the latest `.prd/prd-v*.md`). If its status isn't `draft`, ask
-   which PRD to use.
-2. Decompose into tickets. Rules:
-   - Each ticket is one coherent unit. Use S, M, or L as relative scope indicators and
-     split work when that improves dependency order, verification, or ownership.
-   - For greenfield work, use a walking skeleton when it reduces integration risk. For
-     brownfield work, begin with the smallest protected vertical change; add a
-     characterization ticket before changing load-bearing code that lacks coverage.
-   - Order by dependency; note blockers explicitly ("depends on T-01").
-   - Build the requirement map: for every `R-NN` in the PRD and each of its
-     scenarios, name the ticket that owns the implementation and the executable
-     check that exercises it, or an explicit review method when no executable check
-     exists. Record the IDs in each ticket's Context as `Implements: R-NN, R-MM`
-     (a navigation aid). Enabling work that implements no requirement states its purpose
-     in the ticket Objective. Resolve missing coverage and conflicting criteria with
-     the user before implementation; do not start with an unmapped required scenario. On a change with change records, author the map once as
-     `.prd/coverage/<change id>.json` (coverage map schema 1, "Coverage map" in
-     `docs/runtime-contracts.md`). Start from
-     `node scripts/pincer-runtime.cjs coverage scaffold --change <change id>`: it prints
-     a read-only draft listing every live scenario exactly once with its requirement,
-     every ticket with its objective, its own `Implements:` claim and its Verification
-     text, and an `Unresolved` list of what is still unauthored. It writes nothing,
-     adopts nothing and decides nothing — it removes the transcription, not the
-     judgment, so a ticket's claim is material to check rather than a link, and no check
-     command, ticket role or scope disposition is ever invented. The draft is not a map:
-     it carries no `schema` key and `coverage adopt` refuses it. You author the real map
-     yourself, working through the draft's unresolved entries:
-     one `scenarios` row per `S-NN` naming its
-     implementing tickets and declared checks, every ticket of the change in
-     `tickets` as `implements` or `enables` (with a rationale), each check declared
-     once in `checks` with its kind, `required` flag and, for a command, the exact
-     command line and timeout, and a `scope` entry (`deferred` or `removed`) for a
-     scenario this change will not deliver, naming the decision that records the
-     user's choice. The map is authored work you edit by hand; the runtime never
-     rewrites it, and it validates it against the PRD's definitions.
-   - Every ticket gets a runnable command in its Verification block — a fenced `bash`
-     block that exits 0 only when the ticket is done. `scripts/pincer-ticket.sh verify`
-     runs it verbatim and stamps the receipt that `done` requires, so it must be
-     non-interactive and self-contained (no "check by hand"). An optional
-     `timeout: <seconds>` frontmatter field (default 600) bounds the run; it is part of
-     the check identity, so changing it invalidates earlier passes.
-   - Each Verification section opens with `Proves:` — what the check establishes and
-     which regression it detects. A check for an executable change must exercise
-     observable behavior (including relevant rejection paths and, in brownfield work,
-     preservation of existing behavior) and fail when the behavior is wrong, not only
-     when an identifier is renamed. Reuse adequate focused tests. A build, a syntax
-     check, or an identifier grep alone is not proof; static assertions are primary
-     evidence only for static contracts such as generated files, and `Proves:` says so.
-   - Adequacy is a judgment about what the command observes, never a word match: do
-     not call a command sufficient because it contains `grep`, `test`, or a runner
-     name, nor insufficient for lacking them. Manual visual judgment is recorded
-     separately in evaluation; a tool the check needs but cannot run yields an
-     explicit `unverified` result, never fabricated evidence or a silent waiver.
-   - If the brief or stack implies automated tests, at least one ticket's verification
-     command must be the test runner (e.g. `npm test`) — manual checks alone don't count.
-   - Any ticket whose surface accepts external input (HTTP endpoint, form, file,
-     LLM output) gets an acceptance criterion for the reject path — what invalid
-     input produces (e.g. "empty goal → 400 with a clear message"), not only the
-     happy path.
-   - A greenfield setup ticket includes `.gitignore` covering `.env*` (except
-     `.env.example`) and an `.env.example` naming any required secrets before any
-     secret can exist in the repo. In brownfield repositories, preserve and verify
-     the existing ignore and environment conventions.
-3. Write each ticket to `tickets/T-{NN}-{slug}.md` using
-   `.claude/references/ticket-template.md`, with `status: open` and an explicit
-   `prd: .prd/prd-vN.md` naming the selected PRD. Never infer this association from
-   numbering or old notes. The other state fields
-   (`started`, `last_check`, `verified`, `finished`) are added later by `scripts/pincer-ticket.sh` —
-   never write them yourself.
-4. Present the ticket list (number, title, size, dependencies) as a table, followed
-   by the requirement map as a second table (requirement · scenario · ticket · check
-   or review method). Whether the map is complete and each check is adequate is your
-   judgment as the author; say so rather than presenting the table as mechanical proof.
-
-Present the concrete breakdown and build order as a report, not a question. Reuse
-existing authorization for the same scope and order.
-
-5. Finalize. A breakdown that follows the PRD is already authorized by the PRD: do not
-   ask whether to proceed. Update the selected PRD frontmatter to `status: ticketed`,
-   inspect existing staged changes, stage that PRD and the explicit new ticket paths,
-   review `git diff --cached`, and commit only those paths. Ask first — and finalize
-   once it is resolved — only when step 4 surfaced a newly discovered consequential
-   choice or a scope change the PRD does not cover. Then register the change when the
-   `Runtime` status line says `legacy` and no ticket of this PRD carries legacy
-   receipts, or `changes` (the project already keeps change records):
-   `node scripts/pincer-runtime.cjs register --prd .prd/prd-vN.md` writes the change
-   record `.prd/changes/prd-vN.json` (retaining every earlier change); stage
-   `.prd/changes/` and `.gitignore` (registration adds `.pincer/` to it) and commit them
-   as `Register PRD vN`. Then record the user's actual approval against the agreement
-   the record binds — `node scripts/pincer-runtime.cjs change show prd-vN --json`
-   prints the agreement digest — with
-   `node scripts/pincer-runtime.cjs change authorize prd-vN --agreement <digest> --reference "<where the user said it>" --excerpt "<the user's approval, quoted>"`,
-   select it for this worktree (`node scripts/pincer-runtime.cjs change select prd-vN`)
-   and commit `.prd/changes/` as `Authorize PRD vN`. When the map was authored, adopt
-   strict coverage explicitly: `node scripts/pincer-runtime.cjs coverage adopt --preview --change prd-vN`
-   shows the inventory, the map digest and the agreement it records (it refuses an
-   incomplete map, naming the scenario or ticket); `--apply` writes the schema 3
-   record with a backup and grants nothing — record the user's approval of that
-   agreement with `change authorize` (the same instruction, if it named this
-   breakdown; a delegated disposition needs its basis) and commit `.prd/coverage/`
-   and `.prd/changes/` as `Adopt strict coverage for PRD vN`. A scenario the user
-   deferred or removed is a decision: `change decide --summary "<the choice>"`,
-   `--resolve D-NN` with the user's words naming the scenario, the `scope` entry in
-   the map, then `change authorize … --decision D-NN`. Never record a disposition
-   the user did not state; `coverage` reports `SCOPE_UNAUTHORIZED` until it is. The excerpt records the user's own
-   words; running the command proves nothing by itself, and a registration, a PRD
-   status or a passing check never becomes an authorization. A project whose tickets
-   carry legacy receipts, or that still holds a v0.5.0 binding (`Runtime  change <id> ·
-   revision …`), is migrated from `/pincer-code` after a preview, never here. Finish with:
-   "Tickets ready in `tickets/`. Run `/pincer-code` to start implementing."
-
-## Authorization rule (shared by plan, narrow, code and evaluate)
-
-Reuse explicit authorization for the same scope and decisions; ask only about a
-material choice not already authorized, and prepare the concrete proposal before
-asking. A decision the user delegated (for example "pick the architecture") does not
-need another approval when you exercise it, but a newly discovered consequential
-choice is surfaced before implementation. Record the authorization basis and the
-scope it covers in the PRD or the handover, and on a project with change records as
-a `change authorize` record (the user's words as the excerpt, or a `--delegated`
-disposition with its basis). An agent-written record or a status
-field is not authenticated human approval. When resuming without the context that
-granted authorization, do not invent it — read the `resume` report; an authorization
-it reports as `current` needs no repeat approval, and any other verdict is asked.

package/template/.github/prompts/pincer-plan.prompt.md

@@ -1,134 +0,0 @@
----
-mode: agent
-description: "Create a PRD through brief discovery, codebase scan, and an architecture gate"
----
-<!-- Generated from .claude/commands/pincer-plan.md by scripts/sync-prompts.sh — edit the source, not this file -->
-
-
-# /pincer-plan — PRD Creation
-
-You are turning a task brief into a reviewable PRD. Scale discovery and detail to
-the change's uncertainty, risk, and any time budget the user supplied. The PRD feeds
-`/pincer-narrow` next.
-
-Choose the planning profile and record why it fits: `profile: small` for bounded
-scope, low risk, known behavior and straightforward verification; otherwise
-`standard` (the default). Few changed lines alone do not qualify — migrations,
-authorization boundaries, uncertain requirements and broad effects need proper
-investigation even for a tiny patch. Honor an explicit budget the user supplied;
-there is no default timebox, and a budget never silently cuts requirements —
-record any cut in Out of Scope.
-
-**Initial request:** ${input:request:Task brief or arguments (optional)}
-
-First run `scripts/pincer-status.sh`. If a PRD already exists, preserve it and select
-the next unused numeric version for this change. Use the brief and repository state to
-distinguish a revision from a new change; ask only if that distinction changes scope or
-architecture. If tickets for the current PRD are in progress, resume `/pincer-code`
-unless the user explicitly authorized a separate change.
-
-## Phase 1: Discovery
-
-1. If `${input:request:Task brief or arguments (optional)}` contains the brief, extract what you can before asking anything.
-   Never ask a question the brief already answers. Preserve or link the original
-   brief in the PRD, and record the desired outcome, assumptions and exclusions.
-   If the user supplied a PRD, review it: keep its meaning and existing requirement
-   IDs; do not silently replace either. Where its structure needs adapting to the
-   template, record a mapping table (`their section or ID → R-NN`) inside the PRD.
-2. Ask only the questions whose answers would change the architecture or scope.
-   Batch them (max 3–4 at once). A question the brief partly answers is
-   asked only for its open part, naming the settled part; when the brief settles
-   every material decision, including acceptance behavior, ask no discovery
-   question and record the brief's answers. Do not add a question to fill the budget.
-   Typical ones:
-   - What does "done" look like — what will be run, demoed, or reviewed at the end?
-     A named test runner settles the verification choice, not every acceptance
-     behavior; ask about the demo or manual check only if that is still open.
-   - Any required stack, or is it my choice?
-   - What is explicitly out of scope?
-3. If the project has a frontend, ask one design question: "What should this feel like,
-   and what should it NOT look like?" Capture the answer for the Visual Direction section.
-   The same rule applies: when the brief already supplies design direction, record it
-   and ask only about what it leaves open.
-
-Summarize your understanding in 3–5 sentences. Existing authorization in the request or
-session carries forward; ask only about an unresolved choice that materially changes the result.
-
-## Phase 2: Codebase scan (conditional)
-
-If the repo already contains source code, launch 1–2 `codebase-explorer` agents in parallel
-(one for architecture/structure, one for patterns relevant to the feature). Read the 2–3 most
-load-bearing files they identify yourself — don't rely solely on agent summaries. If the
-repo is empty, skip and say so. (No subagents on this platform? Do the exploration
-yourself, inline, following the rules in `.claude/agents/codebase-explorer.md`.)
-
-**Brownfield scaling:** if the existing code is substantial or load-bearing (production
-traffic, other consumers, no green test suite), this phase grows and Phase 4 shrinks —
-a wrong map costs more than a thin PRD. Additionally establish: which paths the change
-touches are load-bearing, what test coverage protects them (run the suite, don't assume),
-and the blast radius + rollback story for the change. Record these in the PRD's
-Architecture section. Greenfield speed assumptions do not transfer to brownfield work.
-
-## Phase 3: Architecture
-
-Propose the architecture: components, data flow, integration points, and key decisions.
-- Recommend one approach; mention an alternative only when the trade-off is real.
-- Name the trust boundaries in one or two sentences: which inputs are untrusted
-  (user input, LLM output, third-party responses), where each is validated, and
-  which secrets exist and where they live (server-side only). This becomes the
-  PRD's Security section when the project handles secrets or external input.
-- Verify versions of key dependencies with `npm view <pkg> version` (or the ecosystem's
-  equivalent) before naming them — don't trust training data.
-- Verify the contract of any external API the plan builds on (one live request or the
-  current official docs) before designing around it — endpoint shapes remembered from
-  training data are guesses.
-- Respect any explicit delivery budget. Record deliberate cuts in Out of Scope.
-
-Prepare the full draft before seeking any approval still required. The user should review a
-concrete scope and architecture; do not repeat an approval already given for the same decision.
-
-## Phase 4: Write the PRD
-
-1. Load `.claude/references/prd-template.md` and write all core sections.
-   In Requirements, assign stable `R-NN` IDs within the selected PRD: a revision
-   keeps existing IDs and adds new ones, never renumbers. Every requirement has
-   observable acceptance scenarios, the relevant failure paths, and the existing
-   behavior it must preserve, each written as a bold `- **S-NN:** …` item under its
-   requirement heading (the template's grammar; the runtime parses exactly these
-   definitions into the inventory that strict coverage tracks, and a requirement
-   without a scenario is invalid there) — `/pincer-narrow` maps each scenario to a
-   ticket and a check in the coverage map, and `/pincer-evaluate` dispositions every
-   ID. A supplied PRD keeps its own uppercase IDs (`REQ-1`, `AC-3`); only its
-   definition syntax is adapted, and the mapping table records what changed.
-2. Include optional sections when risk or the product context warrants them.
-3. Save to the next unused `.prd/prd-v{N}.md` (create `.prd/` if needed), with `N`
-   matching the filename and frontmatter:
-   ```yaml
-   ---
-   version: {N}
-   status: draft
-   date: {today}
-   profile: small   # only when small; omit for standard
-   ---
-   ```
-4. If `.git/` doesn't exist, run `git init`. Commit the PRD and only the intended setup
-   paths after inspecting existing staged work; planning should be visible in history
-   without absorbing unrelated brownfield changes.
-
-Present the saved draft and obtain approval only when the same scope/architecture was not
-already authorized. Finish with: "PRD saved to `.prd/prd-v{N}.md`. Run `/pincer-narrow`
-to break it into work items."
-
-## Authorization rule (shared by plan, narrow, code and evaluate)
-
-Reuse explicit authorization for the same scope and decisions; ask only about a
-material choice not already authorized, and prepare the concrete proposal before
-asking. A decision the user delegated (for example "pick the architecture") does not
-need another approval when you exercise it, but a newly discovered consequential
-choice is surfaced before implementation. Record the authorization basis and the
-scope it covers in the PRD or the handover, and on a project with change records as
-a `change authorize` record (the user's words as the excerpt, or a `--delegated`
-disposition with its basis). An agent-written record or a status
-field is not authenticated human approval. When resuming without the context that
-granted authorization, do not invent it — read the `resume` report; an authorization
-it reports as `current` needs no repeat approval, and any other verdict is asked.

package/template/.github/prompts/pincer-release.prompt.md

@@ -1,82 +0,0 @@
----
-mode: agent
-description: "Audit the repo against the workflow checklist — pass/fail per item, no fixes"
----
-<!-- Generated from .claude/commands/pincer-release.md by scripts/sync-prompts.sh — edit the source, not this file -->
-
-
-# /pincer-release — Workflow Audit
-
-You are auditing the current repo state against `docs/release-checklist.md`. Read-only:
-report pass/fail, never fix anything — fixes belong to the stage commands. Release does
-not repair tickets, rewrite evidence, change PRD state, or publish. A check that mutates
-the candidate invalidates the audit: if `git status --short` is not empty afterwards,
-the verdict is FAIL and names the mutation. The verdict is reported to the user; a
-durable runtime-owned release record is later work.
-
-**Requested stage:** ${input:request:Task brief or arguments (optional)}
-
-## Steps
-
-1. Read `docs/release-checklist.md` — it is the source of truth for product-candidate
-   readiness. `docs/dry-run-checklist.md` is a separate manual platform trial and must
-   not impose toy-project or Pincer-kit assumptions on this audit.
-2. Run `scripts/pincer-status.sh` to determine the selected PRD and which stages have run
-   (it reads `.prd/`, associated `tickets/`, `NOTES.md`; add `git log`). If `${input:request:Task brief or arguments (optional)}`
-   names a stage, check only up
-   to that stage.
-3. Check every applicable item mechanically where possible:
-   - File existence and frontmatter: read the files.
-   - Commit format and story: `git log --oneline`.
-   - Receipts: every done ticket is ready — on a legacy project current `last_check`
-     and `verified` receipts, on a migrated project a current passing attempt
-     (`node scripts/pincer-runtime.cjs ready` exits 0); any status warning fails the
-     audit. Do not call `pincer-ticket.sh` from Release:
-     it writes receipts and would invalidate the evaluated candidate. Release never
-     runs `verify`, `check` or `done`; `status`, `ready` and the project gate are its
-     only commands.
-   - Evidence: `scripts/pincer-status.sh` runs the shared validator
-     (`scripts/pincer-evidence.cjs`) against the manifest `NOTES.md` names. The `Notes`
-     line must read `current` and the `Evidence` line `ok`; any other text fails the
-     audit with that diagnostic. Do not re-implement evidence checks and do not accept
-     screenshots described in chat: read the manifest's `checks`, requirement
-     dispositions and `visual_review`. Validation establishes that the record is
-     consistent, not that the commands ran — say so if asked.
-   - Provenance: status prints a `Provenance` line for the evaluated candidate:
-     `runtime (schema 2)` with local attempts consistent, or `legacy (schema 1, authored
-     command results)`. A newer local attempt that failed, timed out, was interrupted or
-     is still running for the same check and source inputs fails the audit (`ready`
-     exits 1 and names the check). A fresh clone reports `local verification history
-     unavailable; saved candidate evidence validated only`: state that limit in the
-     verdict rather than claiming local verification.
-   - Change records (the `Runtime` line reads `changes`): the selected change is
-     `completed`, its authorization is `current` for the current agreement, and its
-     evaluation locator `.prd/evidence/changes/<id>.json` names the evaluated
-     candidate; `node scripts/pincer-runtime.cjs ready` reports `SELECTION_REQUIRED`,
-     `LIFECYCLE_BLOCKED`, `DECISION_REQUIRED`, `AUTHORIZATION_REQUIRED` or
-     `AGREEMENT_CHANGED` as failures. Release selects, activates and completes nothing;
-     historical evidence of a cancelled or superseded change is inspectable but never
-     release-ready.
-   - Strict coverage (the status line reads `Coverage strict …`): read
-     `node scripts/pincer-runtime.cjs coverage` — structure complete, every in-scope
-     scenario `delivered` on the evaluated candidate, deferrals and removals backed by
-     their decision and user authorization, `delivery` reported as original versus
-     agreed scope (never conflate them), adequacy `adequate`; the manifest is schema 3
-     and the `Provenance` line reads `runtime (schema 3)`. `ready` names
-     `COVERAGE_INCOMPLETE`, `SCOPE_UNAUTHORIZED`, `OBLIGATION_MISSING`,
-     `REVIEW_MISSING` and `ADEQUACY_REQUIRED` as failures. A change labeled
-     `Coverage unverified` did not adopt strict coverage: audit it under the rules
-     above and say so; never imply strict coverage was established.
-   - Every file the manifest lists is tracked, and `git status --short` is empty before
-     and after the audit.
-   - Run the repository's candidate-wide release gate directly (`npm test`, or the
-     equivalent declared by the project) and report its actual output. Any failure
-     blocks PASS. Confirm `git status --short` remains clean afterward.
-4. For judgment items (tickets genuinely S/M, history reads as a story), give your
-   verdict AND one sentence of evidence — never a bare pass.
-5. Present a table: checklist item | pass/fail/skipped | evidence. Order by stage.
-6. End with a one-line verdict naming the candidate: "PASS — candidate {sha}: workflow
-   artifacts complete" or "FAIL — candidate {sha}: {n} items failed; fix via {command}".
-   Fixes go through a new ticket, a new candidate and a new evaluation. For each failure, name the command
-   file (`.claude/commands/*.md`) whose instructions should be tightened if the
-   failure is a workflow bug rather than a run mistake.

package/template/docs/dry-run-checklist.md

@@ -1,264 +0,0 @@
-# PINCER Dry-Run Checklist
-
-This is the manual platform trial for the Pincer kit, not the product release audit.
-For release readiness, use `docs/release-checklist.md`.
-
-To test that the `.claude/` workflow works, run the full chain on a small toy
-feature (e.g. "a CLI todo app in TypeScript — add, list, complete, delete, stored in a
-local JSON file"), then tick every box below. All boxes ticked = the workflow passes.
-A failed box points at the command file to fix.
-
-Use a throwaway copy of this repo and a cheap model (`claude --model sonnet`).
-Wording tests in the kit protect adapter contracts; only a trial like this one
-observes agent behavior, and one trial on one surface says nothing about the others.
-
-## Ground rules for the trial
-
-- Write every cheat instruction as a single line: multi-line text pasted into
-  Claude Code is sent at the first line break.
-- Test hooks with direct JSON payloads through the hook scripts
-  (`echo '{"tool_name":"Bash","tool_input":{"command":"..."}}' | bash .claude/hooks/block-dangerous.sh`),
-  separately from asking the model — a refusal tests the model, not the hook.
-- Reset the disposable fixture between injected faults (fresh copy, or restore the
-  source you broke before breaking the next thing) so one validation failure cannot
-  mask the check you are trying to observe. Restore the ticket before breaking the
-  code, or the `done` refusal comes from validation rather than from verification.
-- Record the trial with the template at the end of this file. Label surfaces you did
-  not run as untested; do not infer cross-platform behavior from one trial.
-
-## After `/pincer-plan`
-
-- [ ] The selected `.prd/prd-vN.md` exists
-- [ ] Its frontmatter has `version`, `status: draft`, `date`, and `profile` only when small
-- [ ] All 7 core sections are present (Problem, Solution, Scope, Requirements,
-      Architecture, Success Criteria, Out of Scope)
-- [ ] Requirements carry stable `R-NN` IDs, each with a scenario, failure path and
-      preserved behavior; a supplied PRD keeps its own IDs (mapping table if adapted)
-- [ ] The original brief is preserved or linked; outcome, assumptions and exclusions recorded
-- [ ] The profile is justified in a sentence; a small CSS fix is `small`, a tiny
-      change touching a migration or an authorization boundary stays `standard`
-- [ ] The Scope table has both columns filled (in AND out)
-- [ ] No implementation code inside the PRD (interface examples are fine)
-- [ ] Discovery asked ≤4 questions and none were already answered by the brief
-- [ ] No default timebox was assumed; an explicit budget, if given, is recorded
-- [ ] `.git/` exists and the selected PRD is committed without unrelated brownfield work
-
-## After `/pincer-narrow`
-
-- [ ] Ticket files are named `T-{NN}-{slug}.md`; count follows dependencies and risk,
-      with no one-to-two-ticket cap applied to a small PRD
-- [ ] A requirement map (requirement · scenario · ticket · check or review method)
-      was presented, and each ticket's Context says `Implements: R-NN`
-- [ ] Every ticket has a coherent S, M, or L scope; larger work is split when that
-      improves ownership, dependency order, or verification
-- [ ] Greenfield uses a walking skeleton when helpful; brownfield protects the
-      smallest useful vertical change
-- [ ] Every Verification section opens with `Proves:` and its fenced command
-      exercises behavior (it fails when the feature is wrong, not only when a name
-      is renamed); static checks are justified as static contracts
-- [ ] Every ticket has a runnable, non-interactive command in its fenced
-      Verification block (it is what `scripts/pincer-ticket.sh verify` runs)
-- [ ] Dependencies are declared where they exist (`depends_on`)
-- [ ] If the brief or stack implies automated tests, at least one ticket's
-      verification command is the test runner
-- [ ] Every ticket whose surface accepts external input has a reject-path
-      acceptance criterion (what invalid input produces), not only the happy path
-- [ ] Greenfield setup covers `.env*` (except `.env.example`) and names required
-      secrets in `.env.example`; brownfield preserves and verifies existing conventions
-- [ ] A breakdown that follows the PRD was not re-approved; a newly discovered
-      consequential choice (if any) was surfaced before implementation
-- [ ] PRD frontmatter now says `status: ticketed`
-- [ ] Tickets are committed
-- [ ] The change was registered (`Register PRD vN` commit with `.prd/changes/prd-vN.json`,
-      retaining any earlier change), the user's approval was recorded with
-      `change authorize` (quoted in the excerpt, committed as `Authorize PRD vN`) and
-      the change was selected; status now shows `Runtime  changes · selected prd-vN`
-
-## After `/pincer-code`
-
-- [ ] One commit per ticket, messages formatted `T-{NN}: {title}`
-- [ ] Every ticket file now says `status: done`
-- [ ] Existing project only: the migration preview was shown and `migrate --apply` ran
-      only after your yes, as a `Migrate PRD vN to the runtime` commit; nothing was
-      migrated silently
-- [ ] Every done ticket carries `started` and `finished` stamps and
-      `scripts/pincer-status.sh` prints no readiness warning; legacy project only
-      (no change binding): `verified` receipts too; migrated project: no receipt in the
-      ticket, the latest attempt under `.pincer/runtime/attempts/` passed
-- [ ] Every done ticket has all acceptance-criteria checkboxes ticked
-- [ ] `scripts/pincer-ticket.sh verify T-{NN}` passes on done tickets (spot-check
-      at least two)
-- [ ] Cheat: break the feature but keep every identifier, then run `verify` — it
-      fails; legacy project only: prints "failure recorded in last_check" and
-      "receipt was revoked"; migrated project: prints "recorded as attempt … any
-      prior passing attempt is superseded" and status shows `WARN … CHECK_FAILED`
-- [ ] Cheat: ask the assistant to `git checkout` the ticket file — the guard blocks
-      it, the failed attempt stays recorded, and the assistant hands repair to you
-      (migrated project: there is nothing to restore, the tree is clean; the
-      assistant repairs and re-runs `verify`)
-- [ ] Legacy project only, cheat: revert the source so the tree matches the candidate,
-      then ask again — the assistant names the restore command for you, runs no
-      `verify`, and commits nothing; status is `current` after you run it
-- [ ] Legacy project only, cheat: with the tree at the candidate, stop a local service the check needs
-      (the kit repo's `test/fixtures/local-service.cjs`, or any dependency the block
-      cannot bypass), run `verify` so it fails, then ask for the restore — the
-      assistant keeps the failed `last_check`, names no restore command, does not
-      switch binaries or repair the environment itself (the block must pass in the
-      same execution context as `verify`), and asks for the service back before
-      `verify` runs again
-- [ ] Migrated project only (`node scripts/pincer-runtime.cjs migrate --apply --prd …`
-      was run): cheat: change a source file after a green `verify` — status reports
-      `SOURCE_CHANGED` naming the path and `done` refuses; cheat: make the check fail
-      and `verify` again — the failed attempt blocks `done`, the earlier pass stays in
-      `.pincer/runtime/attempts/`; cheat: kill the session mid-`verify` — status shows
-      the `running` attempt as not ready and `recover` finalizes it as `interrupted`;
-      cheat: run `verify` twice on an unchanged tree — `git status` shows no change;
-      cheat: edit a ticket body, then `migrate --apply` again — the edit is preserved and
-      the second apply reports `already migrated`
-- [ ] Change records only: `change activate prd-vN` ran once before the first ticket and
-      no ticket command asked for a repeat approval; cheat: start a ticket of another
-      change — `WRONG_CHANGE`, nothing launched
-- [ ] Change records only, cheat: pause the change with a reason and a handoff note, clear
-      the context, run `resume` — the report names the change, the blocker and the next
-      command from files alone, the note is labeled authored, and `change resume`
-      continues under the same authorization without a repeat approval
-- [ ] Change records only, cheat: edit the PRD under its filename — `verify` refuses with
-      `AGREEMENT_CHANGED` until `change authorize` records the disposition; cheat: raise a
-      decision with `change decide --summary` — execution is blocked until the user's
-      answer is recorded and authorized
-- [ ] v0.5.0 project only: the binding was converted by `migrate --apply` after a
-      preview, the old attempts read `HISTORICAL_EVIDENCE`, and the old authorization
-      text did not authorize anything
-- [ ] Any scope cut made during build is recorded in the PRD's Out of Scope section
-- [ ] Change records only: `change complete prd-vN` ran (`Complete PRD vN` commit) before
-      the built commit and refused while a ticket was stale or unfinished
-- [ ] PRD frontmatter now says `status: built`, committed on its own (`PRD vN: built`)
-      before evaluation, not folded into the evidence commit
-- [ ] Status shows the wall-clock elapsed line only while a ticket is in progress or
-      a budget is set
-
-## After `/pincer-evaluate`
-
-- [ ] Evaluation refused to start on a dirty tree or an un-built PRD
-- [ ] Findings (if any) were presented with `file:line` references
-- [ ] Every `R-NN` has a disposition (delivered / blocked / deferred); a failed
-      required behavior was not relabelled a limitation; any deferral names the
-      user's authorization
-- [ ] The mechanical security audit used redacted, location-only secret findings;
-      `git ls-files` shows no `.env` beyond `.env.example`, dependency audit,
-      and (if there's an API) one invalid-input request returned a clean 4xx
-- [ ] If the project has a UI, it was actually opened and checked visually, and
-      the capture is saved under `.prd/evidence/prd-vN/<candidate>/visual/` with
-      scenario, viewport and observed result in the manifest
-- [ ] Cheat: make the browser tool unavailable — the visual check is recorded as
-      `unverified`, not fabricated and not silently waived
-- [ ] `.prd/evidence/prd-vN/<candidate>/manifest.json` exists and
-      `node scripts/pincer-evidence.cjs validate <manifest> --candidate <sha> --prd .prd/prd-vN.md`
-      prints `ok`
-- [ ] Each executable check in the manifest holds one command line as run, the
-      security pass is separate entries, and only the tool that could not run is
-      `unverified`
-- [ ] Cheat: edit a saved log after the evidence commit — status reports
-      `evidence invalid: ... digest mismatch`
-- [ ] Strict coverage (when adopted): `coverage adopt --preview` writes nothing and
-      `--apply` records the schema 3 record with a backup; `coverage` names the
-      scenario a map row was dropped for (`COVERAGE_INCOMPLETE`) and `change complete`
-      refuses it; `check C-NN --candidate <sha> -- <other command>` is
-      `CHECK_UNDECLARED`; the exported manifest is schema 3 and `ready` reads
-      `delivery original … agreed …` from `coverage`
-- [ ] Evaluation fixes were completed through new tickets, produced a new candidate,
-      and were re-evaluated with fresh evidence
-- [ ] `NOTES.md` exists at the repo root with `prd`, `base`, `candidate` and
-      `evidence:`; the evidence commit contains only NOTES.md and the listed files
-- [ ] `scripts/pincer-status.sh` shows `Notes … current` and `Evidence … ok`
-- [ ] Migrated project only: executable checks ran through
-      `node scripts/pincer-runtime.cjs check C-NN --candidate <sha> -- <command>` and the
-      manifest came from `evidence export` (schema 2, `provenance: runtime` on command
-      checks); cheat: clone the repository elsewhere — status validates the saved
-      evidence and reports `local verification history unavailable`
-
-## After `/pincer-release`
-
-- [ ] The audit ran `scripts/pincer-status.sh` and the project gate directly, never
-      `pincer-ticket.sh`
-- [ ] The verdict names the candidate and every failed or skipped item
-- [ ] `git status --short` is empty after the audit; nothing was repaired, no evidence
-      rewritten, no PRD state changed, nothing published
-- [ ] Migrated project only, cheat: after the export commit run
-      `node scripts/pincer-runtime.cjs check C-NN --candidate <sha> -- false` for an
-      exported check — the `Provenance` line names the newer failure, `ready` exits 1,
-      and the release verdict is FAIL until the check passes again and is re-exported
-
-## Overall
-
-- [ ] `git log --oneline` reads as a coherent story: setup → tickets → T-01…T-NN →
-      PRD built → evaluation evidence
-- [ ] No `.env` file contents ever appeared in the conversation
-- [ ] Relevant history was checked for committed-then-deleted secrets without printing
-      candidate values into the conversation or audit report
-- [ ] Every dependency in the lockfile is named in the PRD's architecture or was
-      explicitly approved during build
-- [ ] `NOTES.md` has a Handover section (orientation, dependency justification,
-      what breaks first) and summarizes the requirement dispositions
-- [ ] Brownfield only: untested load-bearing code got a characterization test
-      before being modified
-- [ ] Platform adapters in sync: `scripts/sync-prompts.sh` then `git status`
-      shows no changes in `.agents/skills/` or `.github/prompts/`
-- [ ] `scripts/pincer-status.sh` says `Next /pincer-release`; if the user supplied a
-      budget, its elapsed figure and any deliberate cuts are reported against that budget
-
-## Recorded workflow scenarios
-
-Run each scenario in its own throwaway copy and note the observation next to it.
-Expected across all five: repeated approval is avoided, unresolved decisions are
-surfaced, and no arbitrary ticket cap or default budget appears.
-
-1. **Small CSS fix.** Brief: "make the primary button 4px rounder". Expect
-   `profile: small` with a one-sentence justification, a compact PRD with
-   Requirements and verification, a ticket count decided by cohesion (one is fine,
-   two is fine), and a `Proves:` line that checks the rendered style, not the
-   presence of a class name.
-2. **Tiny high-risk change.** Brief: "change the session cookie's `SameSite` from
-   `Lax` to `None`" (or any one-line change on an authorization boundary or a
-   migration). Expect `profile: standard` despite the diff size, with the
-   investigation and rollback story recorded in Architecture.
-3. **Supplied PRD.** Paste a PRD that already numbers its requirements (`REQ-3`,
-   `AC-2`, or similar). Expect the meaning and IDs preserved and, if the template
-   structure was applied, a `Requirement mapping` table rather than a rewrite.
-4. **Authorized resume.** Start `/pincer-code`, stop mid-ticket, clear context, run
-   `/pincer-status` then `/pincer-code T-NN`. Expect resumption without a request
-   to re-approve the unchanged scope; the assistant reads `git status` and the
-   receipt state rather than asking.
-5. **New consequential decision during narrow.** Give a brief whose decomposition
-   reveals a choice the PRD did not settle (for example, a second storage backend).
-   Expect the concrete proposal presented and the choice surfaced before any
-   implementation, and no second approval requested for the parts the PRD covers.
-
-## Trial record template
-
-Copy this into `docs/trial-<date>-<greenfield|brownfield>.md` and fill every line.
-
-```markdown
-# Trial <date>: <greenfield|brownfield>, <agent surface> <model>
-
-- Brief: <the brief, verbatim or linked>
-- Base: <full commit ID of the throwaway repo before the trial>
-- Versions: pincer-workflow <version> · <agent surface and model> · Node <version> · <OS>
-- Artifacts: PRD <path> · tickets <T-NN..T-MM> · evidence <manifest path> · NOTES.md
-- Results: <checklist section → pass/fail per box, with the observation for each fail>
-- Interventions: <every human action beyond the brief: answers, repairs, cheats>
-- Untested: <surfaces and platforms not exercised in this trial>
-
-| Requirement | Observed evidence or `outstanding` |
-| --- | --- |
-| R-01 | |
-| R-02 | |
-| R-03 | |
-| R-04 | |
-| R-05 | |
-| R-06 | |
-| R-07 | |
-| R-08 | |
-| R-09 | |
-| R-10 | |
-```