Agent mode, plus two safety fixes and the 1.3.0 bump

.agents/skills/feature-close/SKILL.md

@@ -79,6 +79,11 @@ grep -rn "<old-path>\|<OLD-FILENAME>" --include='*.md' . | grep -v node_modules
 Move every **closed** finding tied to this feature out of `context/findings.md` and into the archived plan's
 own log. `findings.md` must not grow for the life of the project.
 
+Then read [`context/git.md`](../../../context/git.md) before committing anything. `git mv` stages a rename
+and writes no history, so it is safe under either answer — but the commit that carries it is the agent's to
+make only where that file says so. If it does not exist, the answer is *the user commits*: show the whole
+retirement as one reviewable change and hand it over.
+
 ## Mode 2 — `--dropped`
 
 For an entry that will not be built. **There is no ledger check in this mode** — unfinished phases are
@@ -97,6 +102,6 @@ expected.
 - **Never delete a plan document.** Archiving keeps the reasoning; deleting throws away the record of a
   decision someone will otherwise re-litigate.
 - **Never leave `roadmap.md` and `history.md` inconsistent.** An entry is in exactly one of them.
-- **Never commit the sweep unreviewed.**
+- **Never commit the sweep unreviewed** — and never commit it at all unless `git.md` says the agent commits.
 - **Never mark a phase `done` to get past the refusal.** If phases are unfinished, the feature is
   unfinished.

.agents/skills/feature-implement/SKILL.md

@@ -38,7 +38,8 @@ detailed it looks.
 This is the step that used to be structural: `/feature-plan` stopped and you typed a second command. It is
 explicit here now, or it is lost.
 
-1. **Surface the plan's §8 Open questions and require an acknowledgement.** Do not proceed on silence.
+1. **Surface the plan's Open questions section and require an acknowledgement.** Do not proceed on
+   silence. Cite it by name — a plan written against an earlier template numbers its sections differently.
 2. **Re-check that the files the plan cites still exist.** A plan drafted a month ago against a
    since-changed tree is a state that can now exist and could not before. Name anything that has moved.
 3. **Check the one-active-feature rule** in [`context/workflow.md`](../../../context/workflow.md). If
@@ -65,10 +66,31 @@ If the ledger's claim contradicts the repo — a phase marked `done` whose **Fil
 plainly in the tree under a phase marked `not started` — **say so and stop.** Never silently re-do or skip
 a phase on a stale ledger.
 
-## 6. Do the work
+## 6. Open the ledger row
+
+Set the phase's Status to `in progress` and write a Note naming what is underway — **before any code.**
+
+This row is what a *later* session reads. A phase interrupted here — context exhausted, session closed, run
+cancelled — leaves a working tree with half a phase in it. A row still reading `not started` sends the next
+run into step 5's disagreement stop, or into redoing work that is already there.
+
+One token and one Note, in the row that is already there — do not move the entry, restructure the table, or
+write a summary anywhere else. If the row is already `in progress` because you are resuming it, leave it
+alone; step 11 rewrites the Note.
+
+**This write is not a change of its own.** Leave it in the working tree — it lands with the phase's work
+under either answer in [`context/git.md`](../../../context/git.md). Never commit it on its own.
+
+## 7. Do the work
 
 Read the phase's §6.2 sub-section: its scope, its **Files:**, and what `done` means for it.
 
+**The plan's Documentation rows assigned to this phase are part of this phase**, not a follow-up — their
+paths are on the same **Files:** line as the code. Per the standing rule in
+[`context/workflow.md`](../../../context/workflow.md), whatever this phase makes untrue is fixed by this
+phase. If the work turned out differently from the plan and made something *else* untrue — a README the
+plan never listed — fix that too and say so; the sweep happened before the code existed.
+
 Delegate to a coder per [`context/executors.md`](../../../context/executors.md) if one is configured;
 otherwise implement in-host. The coder's system prompt is
 [`context/roles/coder.md`](../../../context/roles/coder.md).
@@ -79,7 +101,7 @@ this repository can open them, and a brief that inlines them is a brief that goe
 
 Describe **what** needs to happen, never **how** to code it. Scope each delegated task to specific files.
 
-## 7. Gate 1 — verification
+## 8. Gate 1 — verification
 
 Per the gate contract in [`context/workflow.md`](../../../context/workflow.md): read
 [`context/verify.md`](../../../context/verify.md) and run its sections in order — Lint → Typecheck → Build →
@@ -89,9 +111,9 @@ Test.
 so, never faked. Exit 0 is the verdict regardless of summary text. If `verify.md` does not exist or has no
 filled-in section, stop and say so. Docs-only changes run Lint plus a read of the diff.
 
-A failure is the verdict — go to step 9 with the failing output verbatim as the feedback.
+A failure is the verdict — go to step 10 with the failing output verbatim as the feedback.
 
-## 8. Gate 2 — review
+## 9. Gate 2 — review
 
 Dispatch per [`context/executors.md`](../../../context/executors.md). With no independent reviewer
 configured, review the diff yourself against the plan's review expectations and the standards — weaker, and
@@ -100,13 +122,13 @@ configured, review the diff yourself against the plan's review expectations and
 Require concrete evidence — file paths, command output — for every verdict, and a `P0`–`P3` severity on
 every blocking finding.
 
-- `PASS` or `PASS WITH NOTES` → the phase's work is done; go to step 10.
-- `FAIL` → **write it to [`context/findings.md`](../../../context/findings.md) first, then** go to step 9.
+- `PASS` or `PASS WITH NOTES` → the phase's work is done; go to step 11.
+- `FAIL` → **write it to [`context/findings.md`](../../../context/findings.md) first, then** go to step 10.
 
 **Write the finding before the loopback, not after it.** A verdict that lives only in this session's
 transcript evaporates when the conversation ends — including a `P0` the cap never got to.
 
-## 9. Loopback
+## 10. Loopback
 
 Cap: **two loops per gate, per phase.**
 
@@ -118,20 +140,34 @@ At the cap: **write a finding** (`P1` for a Gate 1 cap-out — a phase whose ver
 blocked by definition), then escalate to the user with the current state and the last feedback.
 **Escalating is not a substitute for recording.**
 
-## 10. Close out the ledger row
+## 11. Close out the ledger row
 
-In the same commit as the work:
+The row is part of the same change as the work — never a separate step afterwards:
 
-- **All of the phase's scope landed and both gates passed** → `done`.
+- **All of the phase's scope landed and both gates passed** → `done`. Its documentation rows are part of
+  that scope: a phase whose doc update has not landed has not landed.
 - **Some landed** → stays `in progress`, Note rewritten to name exactly what remains.
 - **A gate hit its cap, or something external blocks it** → `blocked`, with the blocker in the Note.
 
 **Never mark `done` on a coder's self-report** — the gate output is the evidence. **Refuse `done` while an
 open `P0` or `P1` is tied to this phase**; leave it `in progress` and name the finding.
 
-## 11. Report
+`done` is a verdict about the gates, not about git. Whether the change is committed at all is the next step.
+
+## 12. Land it — read [`context/git.md`](../../../context/git.md)
+
+**Do not commit until you have read that file, and do not commit at all unless it says the agent does.**
+It is the only place this project's answer lives, the same way `verify.md` is the only place its commands
+live. If it does not exist — an install from before it shipped — the answer is *the user commits*: say so
+once, and name `/onboard`.
+
+- **The user commits** → leave the change in the working tree, ledger row and all. Report it, hand it over,
+  and stop. Do not stage-and-commit "to be helpful", and do not push or branch under either answer.
+- **The agent commits** → the code and the ledger row in one commit, at the granularity that file names.
+
+## 13. Report
 
-- What changed, and which files.
+- What changed, and which files — and whether it is committed or waiting in the tree.
 - Gate 1 output, and Gate 2's verdict.
 - Loopback counts, if any.
 - Findings written or closed, by id.

.agents/skills/feature-plan/SKILL.md

@@ -89,11 +89,22 @@ inline. Either way the brief is the same, and the output contract is the templat
 planner's own default shape:
 
 - The roadmap entry verbatim, and the full content of its draft if there was one.
+- **If `prototypes/<NAME>/` exists at the repository root**, its `NOTES.md` and the mockups beside it. A
+  sketch someone has already looked at settles a design question that a paragraph would only argue. Carry
+  what it settled into §4 Design and cite the folder; treat anything it marked invented as a proposal, not
+  a fact. **No folder, no step** — this is a conditional read, not a prerequisite.
 - **The full section list from `context/plan-template.md`, stated as required output**, in order, with the
   ledger's exact column set. A general-purpose planner will otherwise emit implementation-steps-and-
   acceptance-criteria — a per-phase artifact, not a plan — and you will throw it away.
 - Pointers to `context/stack.md`, `context/standards/README.md` (load per its conditional table) and
   `context/verify.md`. Cite the paths; do not paste the files in. Anything reading this repo can open them.
+- **Where this project documents itself, and what this feature makes untrue there.** Start from the
+  Documentation section of `context/stack.md`. **If that section is empty, missing, or names less than the
+  tree plainly holds, sweep for it** — the root `README`, a `README` in each package, `docs/`, a docs site
+  or landing page in the repository, an API reference or OpenAPI document, a changelog, help text and
+  format comments that live in the code. Ask the user about anything hosted elsewhere: a wiki, a docs site
+  built from another repo, a published reference. **An index nobody filled in is not evidence that there
+  are no docs**, and a plan that assumes it is ships the drift.
 - **Cite file paths and command output for every claim about the current codebase.** Anything unverified is
   an open question, not an assertion.
 - Phases are **commit-sized units with checkable outcomes**, each with a real `Depends on` value and a
@@ -107,7 +118,11 @@ Fill in the template's shape. Then:
 - Date it and point its header at the roadmap entry.
 - **No `**Status:**` header.** Feature status lives in `roadmap.md`, phase status in the ledger. A document
   that claims its own status is a copy that goes stale.
-- Fill in **§8 Open questions** honestly. An honest gap is worth more than an invented decision.
+- Fill in **§7 Documentation** from what the sweep found: one row per surface the feature changes, each
+  assigned to the phase that carries it, **and that phase's `Files:` line names the same path.** A
+  documentation row with no phase is a follow-up nobody does. If nothing changes, say which surfaces you
+  checked and why none of them describe this — that is an answer, and leaving the section blank is not.
+- Fill in **§9 Open questions** honestly. An honest gap is worth more than an invented decision.
 - Every phase is `not started`.
 
 ### 6. Update the roadmap entry
@@ -125,7 +140,8 @@ own; discarding it over a marker would undo the point of the split.
 
 ### 7. Report and stop
 
-State the document path, the phase count, and the open questions. Then say plainly that **what you produced
+State the document path, the phase count, the documentation surfaces §7 commits to updating, and the open
+questions. Then say plainly that **what you produced
 is a reviewable skeleton plus open questions, not a finished plan of record** — the value is the structure
 and the research. Name the next step: the user reviews and edits the plan, and `/feature-implement` runs it
 once they are satisfied.

.agents/skills/feature-status/SKILL.md

@@ -40,8 +40,10 @@ stale. That is the exact failure this workflow exists to prevent.
 
 - Every phase `done` while the entry still reads `active` — that is the normal state before
   `/feature-close`. Next action 5 handles it.
-- A `done` row with its changes still in the working tree — a phase finished but not committed. Name it in
-  the report; do not stop on it.
+- A `done` row with its changes still in the working tree. Under the default policy in
+  [`context/git.md`](../../../context/git.md) that is the normal end state of a phase, not a discrepancy —
+  the user commits. Name it in the report; do not stop on it, and do not commit it: this command writes
+  nothing.
 
 ## 3. Report