task-pipeline-skill 1.17.0 → 1.19.0

package/CHANGELOG.md

@@ -1,5 +1,55 @@
 # Changelog
 
+## v1.19.0
+
+### The copy you are about to edit may not be the copy that ships — `learned.md` rule 17
+
+A machine keeps a skill twice: the working copy it publishes from and the installed plugin it runs.
+On 2026-08-07 the working copy was **two commits behind its own origin** — `v1.16.2` against
+`v1.18.0` — and the newer commits carried rule 16 itself. The tree was clean and nothing had
+diverged; the copy had simply never been pulled. An edit there would have landed on 1.16.2 and the
+release would have **deleted rule 16 and two versions of work by fast-forward** — not as a conflict
+git would show, but silently. The project's own instruction names that directory as the source, so
+whoever did it would have been following the documentation.
+
+The check is one command and it runs **before the first edit**:
+
+```bash
+git fetch -q && git rev-list --count HEAD..@{u}     # 0, or stop and pull
+```
+
+- `references/learned.md` — rule 17 and incident 17.
+- `references/knowledge-sources.md` — a harvest section, because this is a property of the sources
+  that reading them cannot reveal.
+- `references/grill.md` + `templates/brief.md` — autonomy-sweep row `0 Source`, in both files: the
+  grill asks it, the brief records it, and a topic in only one is a question with nowhere to land.
+- `test/validate.py` — a guard in the shape of rule 16's, so dropping a citation fails the build
+  rather than quietly ending the coverage. Both halves were watched failing against planted defects.
+
+## v1.18.0 — 2026-08-06
+
+### Added
+- **`references/deploy-targets.md`** — stages 7 and 8 knew what a deploy must
+  satisfy and never said what to run. This carries the runbook template, the
+  per-platform verbs (Heroku, DO App Platform, droplet over SSH, CI-as-deploy,
+  and the quick table for Fly/Vercel/Cloudflare), and the verification trio.
+
+### Changed
+- **Stage 7: a missing runbook is now the stage's first deliverable**, not a
+  reason to improvise. A deploy performed from an agent's inference about the
+  project is one nobody can repeat or roll back, and the operator is already
+  standing at that manual gate — the questions cost two minutes there and cannot
+  be reconstructed during an incident.
+- **Stage 8 names all three verifications, and says to check the deploy job**,
+  not only the build. A green build beside a skipped or failed deploy is the
+  commonest way a run reports success while nothing shipped — previously the
+  stage said "confirm clean boot" and left the shape of the confirmation open.
+
+### Notes
+- Ported from a standalone `deploy` skill that lived only in a Cursor skills
+  directory. The pipeline already owned the gates; what it lacked was the
+  concrete verbs behind them, so the skill folded in rather than shipping beside.
+
 ## v1.17.0 — 2026-08-06
 
 **A carried-in claim is a recollection — `learned.md` rule 16, and the four places
@@ -98,6 +148,7 @@ landed and the floor stayed at 104 while the file carried 108. A floor below the
 cannot notice losing the difference, which is the entire job. Now guarded, and the
 guard was watched rejecting a lowered floor.
 
+
 ## v1.16.1 — 2026-08-06
 
 ### Fixed — frontmatter that a regex called valid and a YAML parser silently dropped

package/README.md

@@ -799,6 +799,7 @@ recommendation, so you arm the whole run in one exchange. Detail:
 | [`references/conventions.md`](plugins/task-pipeline/skills/task-pipeline/references/conventions.md) | how stages 6–10 read the host project's `CLAUDE.md`, and how the documentation regime is detected |
 | [`references/documentation.md`](plugins/task-pipeline/skills/task-pipeline/references/documentation.md) | the doc system: the inventory, registers and ids, SSOT, the Doc Loop, supersede semantics, the propagation matrix, intent vs as-built |
 | [`references/gates.md`](plugins/task-pipeline/skills/task-pipeline/references/gates.md) | the two axes, the promotion ladder, gate anatomy, the probe recipe, ratchet floors, where a gate runs |
+| [`references/deploy-targets.md`](plugins/task-pipeline/skills/task-pipeline/references/deploy-targets.md) | stages 7–8: writing the runbook when there is none, the template, per-platform deploy and log verbs, the verification trio |
 | [`references/hooks.md`](plugins/task-pipeline/skills/task-pipeline/references/hooks.md) | the `PreToolUse` contract, the fail-open hazard, placement, and the Claude-Code-only limit |
 | [`references/knowledge-graph.md`](plugins/task-pipeline/skills/task-pipeline/references/knowledge-graph.md) | the code graph: install line, stage-0 reach queries, the stage-9 refresh, the graph↔docs divergence check |
 | [`references/retrospective.md`](plugins/task-pipeline/skills/task-pipeline/references/retrospective.md) | the project retro: the three grades of fix, the mandatory prune, the cap of ten |

package/SKILL-CARD.md

@@ -12,7 +12,7 @@ harmless.
 |---|---|
 | **Purpose** | Runs a substantial task through ten gated delivery stages — intake grill, docs study, brainstorm, spec, plan, subagent build, tests, lint/deploy, post-deploy, docs+registers, acceptance — refusing to advance until each gate passes |
 | **Owner** | ssheleg ([github.com/ssheleg/task-pipeline](https://github.com/ssheleg/task-pipeline)) |
-| **Version** | 1.17.0 |
+| **Version** | 1.19.0 |
 | **Surface** | Claude Code (filesystem skill + plugin) and the vercel `skills` CLI. **Not** uploaded to the Skills API; custom Skills do not sync across surfaces |
 | **Dependencies** | None required. Optional: `context7` (MCP), `figma` (MCP), super-ux, agent-sync, graphify, obsidian-wiki. Every stage's doctrine ships in-repo; the one conditional requirement is super-ux for the stage-3 UX track on a user-facing task |
 | **Evaluation status** | Suite authored (15 evals, 5 categories). **Never executed** — see [`evals/RESULTS.md`](evals/RESULTS.md) |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "task-pipeline-skill",
-  "version": "1.17.0",
+  "version": "1.19.0",
   "description": "Full-cycle delivery pipeline for coding agents: a mandatory built-in intake grill, then 10 gated stages (docs, brainstorm+decompose, spec, plan, build, tests, lint/deploy, post-deploy, docs/wiki, acceptance). Every stage's doctrine ships inside the skill — no companion plugin required. This package is the installer CLI.",
   "bin": {
     "task-pipeline": "bin/task-pipeline.js"

package/plugins/task-pipeline/.claude-plugin/plugin.json

@@ -1,8 +1,8 @@
 {
   "name": "task-pipeline",
   "displayName": "Task Pipeline",
-  "description": "Runs a substantial task through a mandatory built-in intake grill, then 10 gated stages (docs, brainstorm+decompose, spec, plan, subagent build, tests, lint/deploy, post-deploy, docs/wiki, acceptance). Every stage's doctrine is built into the skill \u2014 no companion plugin required \u2014 with typed auto/manual gates, a frozen requirement spine that must close with evidence, a loop guard that breaks churn, one provider-agnostic model confirmed up front, and an optional super-ux UX track for user-facing work.",
-  "version": "1.17.0",
+  "description": "Runs a substantial task through a mandatory built-in intake grill, then 10 gated stages (docs, brainstorm+decompose, spec, plan, subagent build, tests, lint/deploy, post-deploy, docs/wiki, acceptance). Every stage's doctrine is built into the skill — no companion plugin required — with typed auto/manual gates, a frozen requirement spine that must close with evidence, a loop guard that breaks churn, one provider-agnostic model confirmed up front, and an optional super-ux UX track for user-facing work.",
+  "version": "1.19.0",
   "author": {
     "name": "ssheleg",
     "url": "https://x.com/sshlg93"

package/plugins/task-pipeline/skills/task-pipeline/SKILL.md

@@ -49,6 +49,7 @@ gate stops until it is installed.
 | 0 + 9 + any settled decision · The documentation system | [`references/documentation.md`](references/documentation.md) |
 | any claim that will be read as true · The canons, and where each is enforced | [`evidence-docs`](../evidence-docs/SKILL.md) — the sibling skill in this plugin |
 | 6–10 + any check you write · Gates | [`references/gates.md`](references/gates.md) |
+| 7–8 · Deploy targets | [`references/deploy-targets.md`](references/deploy-targets.md) |
 | any agent-time enforcement · Hooks | [`references/hooks.md`](references/hooks.md) |
 | 0 Knowledge harvest (pre-grill) | [`references/knowledge-sources.md`](references/knowledge-sources.md) |
 | 0 + 9 The code graph (graphify — recommended, never required) | [`references/knowledge-graph.md`](references/knowledge-graph.md) |
@@ -330,6 +331,7 @@ automation is on — `pipeline.schema.json` is the only contract.
 - `references/retrospective.md` — stage 10's last act: the project retro (`docs/superpowers/retro.md`), the three grades of fix, the mandatory prune and its cap of ten
 - `references/documentation.md` — cross-cutting: the doc inventory, registers and ids, SSOT, the Doc Loop, supersede semantics, the propagation matrix, intent vs as-built
 - `references/gates.md` — cross-cutting: the two axes, the promotion ladder, gate anatomy, the probe recipe, ratchet floors, where a gate runs
+- `references/deploy-targets.md` — stages 7–8: writing the runbook when there is none, the template, per-platform deploy and log verbs, and the verification trio
 - `references/hooks.md` — agent-time enforcement: the PreToolUse contract, the fail-open hazard, placement, and the Claude-Code-only limit
 - `references/audit.md` — cross-cutting: the L0→L7 ladder and its seams (what was never written), axis rotation, ratchets, proven checks
 - `references/learned.md` — cross-cutting: fifteen rules earned by failure on a real multi-repository build, each with the incident behind it, its check and its exit criterion; plus the two that no check can decide

package/plugins/task-pipeline/skills/task-pipeline/references/deploy-targets.md

@@ -0,0 +1,184 @@
+# Deploy targets — the runbook, and the verbs when the runbook is thin
+
+**Load this when:** stage 7 is about to deploy or stage 8 is about to verify, and
+the project's own runbook either does not exist yet or does not say enough to
+act on.
+
+The project's `docs/DEPLOYMENT.md` outranks everything here. This file exists for
+the two moments it cannot help: when there is no runbook to read, and when the
+runbook names a platform whose verbs you have to recall. `conventions.md` says
+where to look; this says what to run once you know.
+
+## Contents
+
+- If there is no runbook, write one first
+- Runbook template
+- Heroku
+- DigitalOcean App Platform
+- Droplet / bare server over SSH
+- Deploy that happens in CI
+- Other platforms, quick verbs
+- The verification trio
+
+---
+
+## If there is no runbook, write one first
+
+A deploy performed from an agent's inference about the project is a deploy
+nobody can repeat or roll back. Stage 7's authorization floor assumes a
+documented procedure; absent one, **the runbook is the first deliverable of the
+stage**, gathered from the operator and committed before anything ships.
+
+Ask for what the template below leaves blank — the target, the trigger, the
+gate commands, where secrets live, the migration step, the health check, the
+rollback — and write the answers down. The questions take two minutes at the
+gate where the operator is already present. Reconstructing them during an
+incident does not.
+
+## Runbook template
+
+Scaffold `docs/DEPLOYMENT.md` with this. Fill every placeholder, delete what does
+not apply, keep it short — it is the source of truth stage 7 follows, and a long
+one goes stale.
+
+```markdown
+# Deployment
+
+## Overview
+- Project: <name>
+- Environments: <production | staging | ...>
+- Deploy branch: <main>
+- Deploy trigger: <CLI push | container registry | CI on push>
+
+## Platforms / targets
+| Env | Platform | App / service | Region | Notes |
+|-----|----------|---------------|--------|-------|
+| production | <Heroku / DO App Platform / Droplet / Fly / Vercel / AWS / SSH> | <app-name or id> | <region> | <notes> |
+
+## Pre-deploy gate
+Commands that must pass before deploying:
+- Lint: `<command>`
+- Type check: `<command>`
+- Tests: `<command>`
+- Build: `<command>`
+
+## Deploy steps
+1. <exact commands, in order>
+2. <release / migration commands>
+
+## Environment variables / secrets
+- Stored in: <Heroku config vars | DO app-level secrets | .env on server | GitHub secrets>
+- Required keys (NAMES ONLY, never values): <KEY_A, KEY_B, ...>
+
+## Migrations / release-phase commands
+- <e.g. release phase in Procfile, or `heroku run <migrate> -a <app>`>
+
+## Post-deploy verification
+- Health check URL: <https://.../health> → expected `<200 / payload>`
+- Logs: <exact command per platform>
+- CI build (if any): <workflow name / link>
+
+## Rollback
+- <exact procedure — the one thing nobody writes down and everybody needs>
+
+## Contacts / ownership
+- Owner: <who>
+- Escalation: <who / where>
+```
+
+**Never write secret values into the runbook.** Names only. A runbook is
+committed; a secret in it is a secret in git history.
+
+---
+
+## Heroku
+
+Check you are authenticated before relying on any of it: `heroku auth:whoami`.
+
+```bash
+# git-based deploy (build runs on Heroku)
+git push heroku <local-branch>:main
+
+# container-based deploy
+heroku container:push web -a <app>
+heroku container:release web -a <app>
+
+# migrations / release-phase, when not automated in the Procfile
+heroku run "<migrate command>" -a <app>
+```
+
+Verify:
+
+```bash
+heroku ps -a <app>            # dyno state — this is where a crash loop shows
+heroku logs --tail -a <app>   # boot and runtime errors
+heroku releases -a <app>      # confirm the new release landed; `heroku rollback` reverts
+```
+
+## DigitalOcean App Platform
+
+`doctl account get` first.
+
+```bash
+# an app connected to a branch deploys on the push from stage 7; to force one:
+doctl apps create-deployment <app-id> --wait
+```
+
+Verify:
+
+```bash
+doctl apps get <app-id>                 # active deployment and its phase
+doctl apps logs <app-id> --follow       # runtime
+doctl apps logs <app-id> --type build   # build — a different stream, and usually the answer
+```
+
+## Droplet / bare server over SSH
+
+Shape only — the runbook's exact steps win, because this is the target where
+"typical" is least likely to be true.
+
+```bash
+ssh <user>@<host> '
+  cd <app-dir> &&
+  git pull &&
+  <build command> &&
+  <restart command>          # systemctl restart <service> | docker compose up -d
+'
+ssh <user>@<host> 'systemctl status <service> --no-pager'
+ssh <user>@<host> 'journalctl -u <service> -n 100 --no-pager'
+```
+
+## Deploy that happens in CI
+
+When the push itself is the deploy, stage 8 verifies the run, not the host:
+
+```bash
+gh run list --branch <branch> --limit 5
+gh run watch <run-id>
+gh run view <run-id>
+gh run view <run-id> --log-failed     # only the failed step's log
+```
+
+**Confirm the deploy job, not just the build job.** A green build with a skipped
+or failed deploy is the most common way a run reports success while nothing
+shipped — and it is exactly what the stage-8 gate is for.
+
+## Other platforms, quick verbs
+
+| Platform | Deploy | Verify |
+|---|---|---|
+| Fly.io | `fly deploy` | `fly status`, `fly logs` |
+| Vercel | `vercel --prod`, or CI on push | `vercel ls`, the deployment URL |
+| Cloudflare Workers/Pages | `wrangler deploy` | `wrangler tail` |
+
+## The verification trio
+
+Whatever the platform, stage 8's gate needs the same three, and all three:
+
+1. **Process/deployment state** — is the new version the running version
+2. **Runtime logs** — clean boot, no error spike
+3. **A health-check request** — from outside, against the live URL
+
+One or two of the three is where "deployed successfully" gets said about a
+service that is crash-looping. If any of the three cannot be obtained, that is
+the honest degradation report the gate asks for — not a reason to call it green.

package/plugins/task-pipeline/skills/task-pipeline/references/grill.md

@@ -142,6 +142,7 @@ explicit "stop and ask me here":
 | run-wide | the model decision ([`model-tiering.md`](model-tiering.md)); what to decide autonomously vs escalate |
 | run-wide Pacing | the **run mode** ([`continuity.md`](continuity.md)): does the run advance item-by-item with no check-in between items, and on what interval? Read `pipeline.json` → `run.loop` first — a recorded mode is the answer and is not re-asked. **Absent, it is off**: recommend it, take the answer, record it. It never collapses a `manual` gate or an outward act, so this row buys pacing, not authorization |
 | 0 Harvest | doc sources beyond this repo — other repos, hosted doc systems, the knowledge wiki, **the code graph** ([`knowledge-graph.md`](knowledge-graph.md): built / installed-not-built / absent) — and whether stage 9 may write to them (another repo is outward: propose + PR, never a direct push) |
+| 0 Source | for a repository with an upstream — **is this checkout the one that ships**. `git rev-list --count HEAD..@{u}`, printed, before the first edit. Behind means stop and pull: an edit on a stale copy deletes newer work by fast-forward, and nothing complains (`learned.md` rule 17) | the count, stated |
 | 0 Work-list | which register holds task **state** — a roadmap, a board, a backlog, a tracker — and the **command that reads it**. Recorded once; the harvest and every loop iteration re-run it, and a closing report that names what is left cites it. No register → record the row empty, and the rule costs nothing ([`knowledge-sources.md`](knowledge-sources.md) → *Carried-in claims*) |
 | 0 Setup audit | doc map absent or stale: run the entry audit over the existing documentation before building on it ([`setup.md`](setup.md))? Asked once; a refusal is recorded and never re-asked |
 | run-wide Escalation | cost of being wrong: decide alone while it stays inside the repository and reversible; escalate price, legal posture, promise, money, reputation, irreversible outward acts. Project exceptions? |

package/plugins/task-pipeline/skills/task-pipeline/references/knowledge-sources.md

@@ -17,6 +17,7 @@ that goes stale when the answer changes.
 - The knowledge wiki — recommended
 - How to harvest — retrieval, not reading
 - Record it — the source ledger
+- The source is not the copy you have
 - Carried-in claims — measured or recalled
 - Phase 2 — validate the answers against the harvest
 - Close the loop — stage 9 updates what stage 0 read
@@ -171,6 +172,27 @@ source nobody will update.
 **"No sources found" is a valid, recorded outcome.** Write the row. An empty ledger
 tells the next run that the search happened and came back empty — silence doesn't.
 
+## The source is not the copy you have
+
+`learned.md` rule 17. The harvest reads the project's own files, and one property of them is
+invisible to reading: **whether this checkout is the one that ships.** A working copy two commits
+behind its upstream looks exactly like a current one — clean tree, no conflict, `git status` says
+nothing is wrong — and an edit on top of it deletes the newer work by fast-forward rather than by
+collision.
+
+Before the first edit, in any repository that has an upstream:
+
+```bash
+git fetch -q && git rev-list --count HEAD..@{u}     # 0, or stop and pull
+```
+
+Print the number. `0` is the measurement; the absence of a complaint is not.
+
+This matters most where it is least suspected — a skill, a plugin, a fork, a vendored library —
+because those are the repositories a machine keeps **twice**, once to publish from and once to run,
+and the one a person opens is chosen by a path in some documentation rather than by which is
+current.
+
 ## Carried-in claims — measured or recalled
 
 The harvest exists because *the operator misremembers*. This section exists because

package/plugins/task-pipeline/skills/task-pipeline/references/learned.md

@@ -41,6 +41,7 @@ to be enforced and is not is the same failure as a gate that prints `FAIL` and e
 | 14 | **A document may not send a reader to something absent** | any instruction naming a command, file or install | resolve it | the gate fails when the target does not exist |
 | 15 | **Identity before coordination** | any lease, lock, claim or run id | ask what two instances with the same identity would do, and make the tool answer it | two instances demonstrably get two identities |
 | 16 | **A carried-in claim is a recollection** | any run resuming from a summary, a handoff or a compacted context | re-derive the claim from its source before acting on it or reporting it | every state claim the run makes is marked `measured` with the command behind it, or it is not made |
+| 17 | **The copy you are about to edit may not be the copy that ships** | any run editing a repository that has an upstream — a skill, a plugin, a vendored library, a fork | `git rev-list --count HEAD..@{u}` **before the first edit**; non-zero means stop and pull | the run states the count it measured, or it has not started |
 
 ---
 
@@ -124,6 +125,8 @@ provenance on the way. Eleven iterations later a single command over the registe
 rows out of 99**, not the handful being worked from. Nothing had failed, because nothing compares a
 run's belief about the work-list against the register; the claim only ever appeared in prose.
 
+**17 · The stale source.** A machine keeps its skills in two places: the working copy it publishes from and the installed plugin it runs. On 2026-08-07 the working copy was **two commits behind its own origin** — `v1.16.2` against `v1.18.0` — and the newer commits carried rule 16 itself. The repository was clean, nothing had diverged, and `git status` said so; the copy was simply never pulled. An edit made there would have landed on top of 1.16.2, and the release would have **silently deleted rule 16 and everything else in two versions** — not as a conflict, which git would have shown, but as a fast-forward over work that was already published. The project's own instruction names that directory as the source, so the person doing it would have been following the documentation. Nothing in the pipeline asked the one question that separates a source from a copy of one, and the check is a single command.
+
 The same class had already bitten that project twice from the other side, and its roadmap names the
 property exactly: seven rows read `blocked` on producers the dependency board recorded as delivered,
 and *"no gate can catch it because it breaks nothing — it only removes work from consideration"*;

package/plugins/task-pipeline/skills/task-pipeline/references/portability.md

@@ -46,6 +46,7 @@ a row pointing outside the bundle is the defect this file exists to catch.
 | The knowledge harvest and its source ledger | `references/knowledge-sources.md` |
 | The documentation system, the Doc Loop, supersede semantics | `references/documentation.md` |
 | Gate types, the enforcement ladder, degrees of freedom, probing | `references/gates.md` |
+| Deploy runbook template, per-platform verbs, the verification trio | `references/deploy-targets.md` |
 | The Claude Code hook contract | `references/hooks.md` |
 | First run in a project: greenfield and brownfield | `references/adoption.md` |
 | The entry audit and what it inspects | `references/setup.md` |

package/plugins/task-pipeline/skills/task-pipeline/references/stages.md

@@ -339,7 +339,11 @@ never that the work was skipped quietly.
   the **super-ux linter** (`python3 docs/ux/lint.py` / `/ux-lint`) is part of lint —
   it must pass too (no UX drift merges). Then deploy per the project's convention;
   if the project defines release automation (`pipeline.json` → `release`, toggle
-  on), that is what "deploy" runs here.
+  on), that is what "deploy" runs here. **No runbook, or one too thin to act on?
+  Write it first** ([`deploy-targets.md`](deploy-targets.md)) — a deploy performed
+  from inference about the project is one nobody can repeat or roll back, and the
+  operator is standing at this gate anyway. That reference also carries the CLI
+  verbs per target for when the runbook names a platform you have to recall.
 - **GATE (manual):** lint clean (host linter **and**, for UI projects, the super-ux
   linter) **and** suite green **before** deploy, **and no REQ is still `open`** — a
   `partial` ships only with the operator's explicit acceptance. A gap is cheapest to
@@ -353,7 +357,12 @@ never that the work was skipped quietly.
 ## 8 — Post-deploy
 - **Freedom: medium** — where the logs live varies; 'clean boot or an honest degradation report' does not ([`gates.md`](gates.md) → *Axis C*).
 - Tail deploy logs / health-check per conventions. Confirm clean boot, no error
-  spike, live subsystems healthy.
+  spike, live subsystems healthy. **All three of the verification trio, not one of
+  them** ([`deploy-targets.md`](deploy-targets.md) → *The verification trio*):
+  deployment/process state, runtime logs, and a health-check request from outside.
+  Where deploy happens in CI, verify the **deploy** job and not only the build —
+  a green build beside a skipped deploy is the commonest way a run reports success
+  while nothing shipped.
 - **Read the CI verdict for the deploy's own commit** ([`conventions.md`](conventions.md)
   → *The CI verdict*): the run's conclusion quoted, the **failing step's log quoted**
   on anything but `success`, and one of the three states stated — including **`no run

package/plugins/task-pipeline/skills/task-pipeline/templates/brief.md

@@ -120,6 +120,7 @@ is not neutral — it is a scheduled interruption.
 | run-wide | Decide autonomously vs escalate to me | … |
 | run-wide Pacing | Run mode: item-by-item with no check-in between items, and on what interval? (the skill's `references/continuity.md`; read `pipeline.json` → `run.loop` first) | … (**absent ⇒ off**; it never collapses a manual gate or an outward act) |
 | 0 Harvest | Doc sources beyond this repo — other repos, hosted docs, the knowledge wiki, the code graph; and may stage 9 write to them? | … (another repo is outward: propose + PR, never a direct push; graph built / not built) |
+| 0 Source | `git rev-list --count HEAD..@{u}` before the first edit, printed. Behind means stop and pull — an edit on a stale checkout deletes newer work by fast-forward and nothing complains (`learned.md` rule 17) | |
 | 0 Work-list | Which register holds task **state**, and the command that reads it — re-run at every harvest, at every loop iteration and at the close | … (e.g. `bash scripts/board.sh`; none → record empty) |
 | 0 Setup audit | … (yes / no — recorded either way) | doc map absent or stale: run the entry audit over the existing documentation before building on it (the skill's `references/setup.md`)? Asked once; a refusal is recorded and never re-asked |
 | 0 Docs regime | Where settled things live (register or ADR set — one home, never both); who may write it; lease mechanism present, or is this run `ungated`? Gate command + ratchet floors; may this run raise a floor? | … |