One PR per issue: update the open one instead of opening a second

.claude/skills/fix-issue/SKILL.md

@@ -46,6 +46,7 @@ node scripts/ds-bot-patches.mjs generate && node scripts/ds-bot-patches.mjs chec
 - Subject: imperative; the reason in the body; `Fixes #N` on its own line.
 - A Verification section per Verifier honesty: tip SHA, each gate with **real numbers**, Not run with reasons.
 - A reviewer note for environment traps (e.g. the worktree harness symlink above).
+- **One PR per issue:** if the issue already has a pull request, push to that branch (re-base, `update-branch`, or a commit on its head) instead of opening another, and put the new tests there. Only a branch that cannot be pushed (maintainer edits off, author gone and the branch unusable) justifies a new PR — and the issue then says why.
 
 ## 5. Independent review loop
 

AGENTS.md

@@ -45,6 +45,8 @@ On 2026-10-21 the owner replaced the earlier "only a merge click in the UI is th
 
 Such a PR needs `tests-ok` green at the tip **and** a test that fails when the source change is reverted. A new commit at the tip voids the PASS and the review is repeated.
 
+**One PR per issue.** When an issue already has a pull request, keep working in that one: re-base its branch, use `update-branch`, or push a new commit to its head, and add the tests there too. Never open a second PR and close the first — that is what produced a trail of superseded PRs. A contributor's fork is treated the same way while it allows maintainer edits. The only exception is a branch that cannot be pushed (maintainer edits off, or the author is gone and the branch is unusable): then a new PR is allowed **and the reason goes on the issue** — never a silent swap.
+
 Anything else is not opened, not queued and not reviewed: pure UX polish, new configuration keys, design proposals. Leave them in `needs-human`, or close them with the reason written down, and report them in one batch instead of one at a time.
 
 **Still report to the Chief first** (who asks the owner): a vague scope, a change on the security surface (secrets, permissions, sharing), or a policy change the owner can feel. The routines keep their own bottom lines: no production deploy without consent, no touching the owner's own machine, never print a secret, never open an issue on someone else's upstream, never remove a PR the owner put in the merge queue.

docs/autonomous-dev.md

@@ -18,7 +18,9 @@ Decisions by the maintainer, and what follows from them:
    maintenance routine after triage (the routine runs as the maintainer account `Birfy`, so the controller sees a
    maintainer's label). No LLM develops other issues, and nothing outside text sets the label.
 4. **Merge by tier** (owner decisions 2026-10-19, revised 2026-10-21): **T0 and T1** merge through the merge queue once CI is green, the PR is
-   mergeable and it conforms to the design rules, with no PASS. **T2 and T3** need a PASS at the tip (a **self-PASS counts**, below) with green CI, and then the agent that gated the PR enqueues it itself: the owner's authorisation is the self-gate, not a click in the UI (owner decision 2026-10-21, AGENTS.md). The gate is the review: green `tests-ok` at the tip, a PASS at that same tip, and a test that fails when the change is reverted. Work that meets neither the defect nor the routine-need bar gets no PR at all (AGENTS.md).
+   mergeable and it conforms to the design rules, with no PASS. **T2 and T3** need a PASS at the tip (a **self-PASS counts**, below) with green CI, and then the agent that gated the PR enqueues it itself: the owner's authorisation is the self-gate, not a click in the UI (owner decision 2026-10-21, AGENTS.md). The gate is the review: green `tests-ok` at the tip, a PASS at that same tip, and a test that fails when the change is reverted. Work that meets neither the defect nor the routine-need bar gets no PR at all (AGENTS.md). An issue that already has a
+   pull request keeps it: update that branch (re-base, `update-branch`, or a commit on its head) rather than opening a
+   second PR; a branch that cannot be pushed is the only exception, and the reason goes on the issue.
 5. Budget is not set. Every cost cap will live in one config file (open PRs, attempts per PR,
    PRs per day, minutes per attempt) so it can be changed without code.
 

docs/code-standards.md

@@ -43,6 +43,7 @@ When you report status on a change:
   - **T2/T3:** a **PASS** at the **same tip SHA** (a self-PASS by the owner's reviewer Bot/agent counts; no independent reviewer required). With green required checks and a mergeable branch, the agent that gated the PR enqueues it itself: the owner's authorisation is the self-gate (AGENTS.md, owner decision 2026-10-21, "the Bot gates and merges its own PRs"), not a click in the UI.
   - Required checks in CONTRIBUTING (`npm test`, client `--check`, `npm run lint`; smoke when host changes) are green or honestly listed as not run with a maintainer waiver.
 - Any new commit voids a PASS: re-run the Verifier on the new tip. Never admin-merge or bypass a gate.
+- **One pull request per issue.** An issue that already has a PR keeps it: re-base the branch, use `update-branch`, or push to its head, and put new tests there. Never open a second PR and close the first — including on a contributor's fork while maintainer edits are allowed. A branch that cannot be pushed is the only exception, and the issue must say why.
 
 ## Architecture docs and owned paths