tumwater 0.2.0 → 0.4.0

package/dist/src/prompt/gate-prompts.js

@@ -1,21 +1,37 @@
-// vocabulary: plain
 import { shortSha } from "../text/format.js";
 import { KILL_BY_PID_RULE, OLDER_NAMES_SENTENCE, TEST_RUNNER_RULE, dateLine } from "./prompt.js";
-import { NEEDS_REPLAN_NOTE, NEEDS_REVIEW_NOTE } from "../roles/role-guidance.js";
 import { describeCheck } from "../build/build-check-report.js";
-import { formatTimestamp } from "../text/datetime.js";
 import { numberedList } from "../text/markdown.js";
-import { SUMMARY_BLOCK, VERDICT_ENDING, NOTHING_TO_DO } from "../verdict/reply-contract.js";
+import { VERDICT_ENDING } from "../verdict/reply-contract.js";
+import { joinParts } from "../text/text.js";
+import { FINISHED_ARCHIVES } from "../backlog/backlog-md.js";
 /** Prompts for the merge gate's pi runs — the runs the merge/review pipeline starts, not the
- * role loops' authoring ticks (those live in prompt.ts): conflict resolution after a rebase
- * (merge-to-main.ts), the adversarial pre-merge review (review.ts), and the notes that carry the
- * gate's verdicts back to the loop that authored the change (loop-tick.ts, tick-prompt.ts,
- * main-red.ts). The machine-detectable half of the gate's reply contract — verdict constants
- * and detection for parsing a reviewer's VERDICT line — lives in reply-contract.ts. */
+ * roles' authoring runs (those live in prompt.ts): conflict resolution after a rebase
+ * (merge-to-main.ts), the adversarial pre-merge review (review.ts), and the conflict hand-back
+ * note. The other notes that carry the gate's verdicts back to the role that authored the
+ * change live in gate-notes.ts. The machine-detectable half of the gate's reply contract —
+ * verdict constants and detection for parsing a reviewer's VERDICT line — lives in
+ * reply-contract.ts. */
 /** The listed-reasons placeholder the review and revision notes share when a rejection recorded
  * none: one home so a revision round's note and the next rejection's note cannot disagree on
  * how an empty objection list reads. */
-const NO_REASONS = "(no reasons recorded)";
+export const NO_REASONS = "(no reasons recorded)";
+/** Check 4's note on how a finished entry reads in the diff. The author pastes it under the live
+ * file's finished section, and the commit-time sweep (src/backlog/backlog-archive.ts) moves it
+ * to the top of the archive before the gate builds the diff. So a correct change shows the
+ * entry leaving PLANS.md or BUGS.md for PLANS-DONE.md or BUGS-FIXED.md. A reviewer that did
+ * not know this rejected such changes as misfiled. One change spent all four rounds asking for
+ * the entry under PLANS.md's `## Done`, a move the author cannot make stick (2026-10-21).
+ * Built from FINISHED_ARCHIVES so the names cannot drift from the sweep's. */
+const ARCHIVE_SWEEP_SENTENCE = (() => {
+    const sections = FINISHED_ARCHIVES.map((a) => `${a.file}'s \`## ${a.section}\``).join(" or ");
+    const archives = FINISHED_ARCHIVES.map((a) => a.archive).join(" or ");
+    return `A finished entry reaches this diff already archived: the author pastes it under
+   ${sections}, and tumwater's commit-time sweep moves it
+   from there to the top of ${archives}, leaving that heading empty. An
+   entry that leaves the live file for its archive, closing stamp added, is the expected update,
+   not a filing error.`;
+})();
 /** The two labeled blocks that show the resolver what each side meant, framed as data, not
  * instructions, so pi cannot mistake a commit body for a rule. */
 function conflictIntentBlocks(intent) {
@@ -54,8 +70,8 @@ function conflictedFileLine(file) {
 function listsHunks(files) {
     return files.some((f) => typeof f !== "string" && f.hunks.length > 0);
 }
-/** The prompt for resolving merge conflicts left in a loop's worktree. `check` — the project's
- * resolved check, as the tick prompt threads it — is named so the resolver knows which command
+/** The prompt for resolving merge conflicts left in a role's worktree. `check` — the project's
+ * resolved check, as the run prompt threads it — is named so the resolver knows which command
  * the harness will run (told only to keep the tests passing, the 2026-10-04 resolver guessed
  * `npx vitest run` in a node:test repo, BUGS.md 2026-10-05), and the rules tell it not to run
  * that check itself: merge-to-main.ts's verifyMerge runs it on the resolved tree before
@@ -125,24 +141,26 @@ ${TEST_RUNNER_RULE}${noCheckRunRule}
 /** The prompt for the adversarial pre-merge review gate: a fresh-session pi run that sees only the
  * diff and project context — never the author's session — and replies with exactly one VERDICT
  * line plus numbered reasons (see parseVerdict in src/review/review-verdict.ts).
- * `verifiedByHarness` names the project's own check the gate's deterministic pre-check already ran
- * green on this exact tree (e.g. "`npm run test` passed"), so the reviewer spends its run on what a
- * green suite cannot show instead of re-running it. The no-re-run instruction is its own line in
- * the rules list, not a clause in the context paragraph: stated there, reviewers read past it and
- * re-ran the suite in scratch copies under /tmp while holding the merge slot (BUGS.md
- * 2026-09-23). It appears only when a verified result exists: after a timed-out, killed, or skipped
- * pre-check no green run stands behind the tree, and a reviewer running the suite itself is doing
- * its job. `baseRev` is the frozen revision the diff is measured against (changeBaseRev's
+ * The prompt always says tumwater is running the project's own check on this tree (alongside
+ * the review, or already done), so the reviewer spends its run on what a green suite cannot show
+ * instead of running it. The no-re-run instruction is its own line in the rules list, not a clause
+ * in the context paragraph: stated there, reviewers read past it and re-ran the suite in scratch
+ * copies under /tmp while holding the merge slot (BUGS.md 2026-09-23). `baseRev` is the frozen
+ * revision the diff is measured against (changeBaseRev's
  * merge-base, resolved when the gate builds the diff): the prompt names it and tells the reviewer
- * to compare against it, never `main`, because other loops merge to main while the review runs
+ * to compare against it, never `main`, because other roles merge to main while the review runs
  * (BUGS.md 2026-10-06). Omitted, the prompt keeps the generic "ahead of main" wording. `today` pins
  * the date line (prompt.ts's dateLine) for tests; omitted, it is the local day. The text must
  * contain the literal "VERDICT:" exactly twice — the two advertised forms — because a prompt
  * test derives the accepted forms from it. `priorReview` is present only when this merge is a
  * revision of a previously rejected change (plans/revise-rejected.md part 2/2): it names the round
  * and shows the prior objections plus the interdiff so the re-review checks each one first.
- * Omitted, the prompt is unchanged from a fresh change's. */
-export function buildReviewPrompt(diff, summary, commitBody, principles, highFriction, verifiedByHarness, baseRev, today, priorReview) {
+ * Omitted, the prompt is unchanged from a fresh change's. `postMerge` marks the post-merge review
+ * of a commit already on main (review.afterMerge): a finding the reviewer can repair is the work —
+ * it makes the minimal fix in the worktree, leaves the edit, and ends with the verdict line plus a
+ * `FIX:` line — so the instruction and the repair rule render only for that caller, and every other
+ * (pre-merge) caller's prompt is byte-identical. */
+export function buildReviewPrompt(diff, summary, commitBody, principles, highFriction, baseRev, today, priorReview, knownMainFailures, postMerge) {
     const parts = [
         `You are an adversarial code reviewer for tumwater, which runs a team of AI roles on this project. ${OLDER_NAMES_SENTENCE} A
 role's change is about to be merged to main; you decide whether it may merge. You have no context
@@ -172,13 +190,23 @@ from a new finding. The prior objections were:\n${list}\nThe interdiff
 between the rejected version and this revision (what the revision changed, main's own movement
 excluded):\n<interdiff>\n${priorReview.interdiff}\n</interdiff>`);
     }
-    if (verifiedByHarness)
-        parts.push(`Tumwater already ran the project's own check on this exact tree and it passed:
-${verifiedByHarness}. Spend your run on what a green check cannot show: wrong behavior the tests
-never exercise, claims the diff does not back, work left half-done.`);
+    parts.push(`Tumwater is running the project's own check on this tree; do not run the suite. Spend your run
+on what a green check cannot show: wrong behavior the tests never exercise, claims the diff does
+not back, work left half-done.`);
+    if (knownMainFailures && knownMainFailures.length > 0)
+        parts.push(`Tumwater ran the project's own check on this tree and it failed, but only on tests main already
+fails, or that failed at this change's base and pass on main's tip now — not this change's failures:\n${knownMainFailures.map((t) => `- ${t}`).join("\n")}
+Do not count them against the change unless the diff touches what they test.`);
     if (principles) {
         parts.push(`Design principles this project holds — your review standard; a violation of one is a finding:\n<principles>\n${principles}\n</principles>`);
     }
+    if (postMerge) {
+        parts.push(`This review judges a change already on main, so a finding you can repair IS the work: make the
+minimal fix right here in the worktree, leave the edit in place, and end with your verdict line plus
+a \`FIX:\` line naming the files you changed — tumwater commits and merges your repair as one fix.
+Fix only what the diff shows is wrong, nothing more. A finding you cannot repair in this worktree is
+recorded as numbered reasons, exactly as a pre-merge rejection is.`);
+    }
     // The base the diff is measured from, named in the prompt: main moves while a merge is approved,
     // and a reviewer that double-checks scope with `git diff main` reads a newer merge, reversed, as
     // part of the change (BUGS.md 2026-10-06). Sentence only when a base is given; the callers that
@@ -191,14 +219,25 @@ never exercise, claims the diff does not back, work left half-done.`);
     parts.push(`The full diff this merge will land (${diffBase}):\n<diff>\n${diff}\n</diff>`);
     // Right after the scratch-copy allowance it qualifies: a scratch copy stays fine for measuring
     // something, but a copy made to run the suite is the re-run this line forbids.
-    const noRerunRule = verifiedByHarness
-        ? `
-- Do not re-run the check named above or the project's full test suite: tumwater's green run
-  is the verified result. Copying the tree elsewhere to run it — rsync or cp into a temp
+    const noRerunRule = `
+- Do not run the project's check or its full test suite: tumwater is running it on this tree and
+  owns the result. Copying the tree elsewhere to run it — rsync or cp into a temp
   directory, reinstalling dependencies there (for an npm project, \`npm ci\`; otherwise its
-  equivalent) — counts as re-running it. Running one
-  specific test file for a concrete reason you can name is fine.`
-        : "";
+  equivalent) — counts as running it. Running one
+  specific test file for a concrete reason you can name is fine.`;
+    // The worktree rule differs by mode: a pre-merge reviewer must not touch the tree it is judging,
+    // while a post-merge reviewer's whole point is to repair what it finds in this worktree (the
+    // harness commits the edit). The pre-merge text is byte-identical to the line it replaces.
+    const worktreeRule = postMerge
+        ? `- Make your repair directly in this worktree and leave it: the files you edit are what
+  tumwater commits as one fix commit. Never run a git command that changes state (no git add,
+  commit, merge, rebase, reset) — tumwater owns every git operation and commits for you. Reading
+  files and git history is fine; a scratch copy under the system temp directory is fine when you
+  need to run something.`
+        : `- Do not edit any file in the worktree. Never run a command that changes state (no git
+  add/commit/merge/rebase/reset, no writes in the worktree) — your only output channel is the
+  verdict below. Reading files and git history is fine; a scratch copy under the system temp
+  directory is fine when you need to run something.`;
     parts.push(`Review adversarially: hunt for correctness bugs, violations of the project's principles,
 unjustified complexity growth, and incomplete or half-done work. Work in this order:
    1. The diff above is current — read it there; do not fetch it again with \`git diff\`,
@@ -219,8 +258,8 @@ Check, in this order:
 1. Does the diff do exactly what the summary and WHY claim — no more, no less? An unclaimed
    change is a finding.
 2. Are the VERIFIED claims consistent with the diff (commands, files, observations)? A claim you
-   can disprove is a rejection. Suite counts are tumwater's own attestation — they appear in
-   the passed-check line above when the check ran green — so a count missing from VERIFIED is
+   can disprove is a rejection. Suite counts are tumwater's own attestation — it runs the
+   check and records them — so a count missing from VERIFIED is
    not a finding, and neither is an author-stated count that differs from it: judge whether the
    tests exist and exercise the change (check 3), not the author's arithmetic.
 3. Do new or changed tests exercise the new behavior — would they fail without the change?
@@ -231,24 +270,24 @@ Check, in this order:
    direction is not itself a defect. Reject only if the change is incoherent or incomplete for
    its stated purpose, or leaves the existing entry stale and contradictory (updating the entry
    in place is the author's duty).
+   ${ARCHIVE_SWEEP_SENTENCE}
 5. Does anything violate a principle above, or grow complexity the WHY does not justify?
 Reject only for concrete, verifiable defects you can name; when the change is correct, complete
 for its stated purpose, and within the principles, taste alone is not a rejection.
 
 Rules for this run:
-- Do not edit any file in the worktree. Never run a command that changes state (no git
-  add/commit/merge/rebase/reset, no writes in the worktree) — your only output channel is the
-  verdict below. Reading files and git history is fine; a scratch copy under the system temp
-  directory is fine when you need to run something.${noRerunRule}
+${worktreeRule}${noRerunRule}
 ${TEST_RUNNER_RULE}
 - ${KILL_BY_PID_RULE}
 - Weigh the change against its stated purpose; do not approve work you did not actually check.
 - End your reply with exactly one line in this form:
-  ${VERDICT_ENDING.replace(/\n/g, "\n  ")}`);
+  ${VERDICT_ENDING.replace(/\n/g, "\n  ")}${postMerge ? `
+  plus, when you repaired a finding, one \`FIX:\` line naming the comma-separated files you edited:
+  FIX: <files you changed>` : ""}`);
     return parts.join("\n\n");
 }
 /** The prompt for the next attempt at a review whose previous run hit its time budget while
- * still making progress (LoopState.reviewResume): that run continues the timed-out reviewer's
+ * still making progress (RunnerState.reviewResume): that run continues the timed-out reviewer's
  * own session (`--continue`), so the diff and everything the reviewer already read are in
  * context. This prompt carries no diff — re-sending it would defeat the resume — and names the
  * frozen comparison base and the unchanged patch-id so the reviewer knows the change it was
@@ -290,17 +329,32 @@ this worktree, not in a scratch copy. Finish the review now from what you have a
 reply with ONLY the closing block — no tool calls, no other text — one line in this form:
   ${VERDICT_ENDING}`;
 }
-/** The one-turn follow-up sent into a tick's OWN session (--continue) when the harness's
+/** The one-turn follow-up sent into a run's OWN session (--continue) when the harness's
  * pre-queue self-check found problems likely to get the change rejected. Only some findings are
  * the merge gate's own deterministic checks; the rest (path drift, plan dependencies) are
  * heuristics, so the prompt never claims the gate rejects every one — claiming it did made an
  * author sweep a rename through the backlog's history (2026-10-18). The session still holds
  * everything the run did, so the author fixes the faults before the change commits and queues —
  * the gate keeps its final say, and the fix costs one bounded turn instead of a rejection cycle.
- * A finding the author believes is wrong is answered in RISK rather than forced away; the reply
- * re-states the closing block because the harness re-derives the commit message from it.
- * Carries the tick prompt's no-git rule (the harness commits). */
-export function buildStageFixPrompt(findings) {
+ * A finding the author believes is wrong is answered in RISK rather than forced away.
+ * The prompt shows the change's description as the harness holds it and asks only for this
+ * turn's RISK and VERIFIED, which the harness appends to that description. Asked for "the
+ * closing block again", authors described the turn itself ("No change — the finding is wrong"),
+ * and that became the subject of a whole feature (BUGS.md 2026-10-21). A change whose subject
+ * was derived from its paths (`change.summary` null) is also asked for a SUMMARY of the whole
+ * change. Carries the run prompt's no-git rule (the harness commits). */
+export function buildStageFixPrompt(findings, change) {
+    const current = joinParts([change.summary !== null && `SUMMARY: ${change.summary}`, change.body], "\n");
+    const description = current === ""
+        ? ""
+        : `Your change's description stays as your closing block gave it, and review checks it against
+the whole diff:
+${current.replace(/^/gm, "  ")}
+Do not rewrite it to describe this turn.
+`;
+    const summaryLine = change.summary === null
+        ? "  SUMMARY: <imperative one-line description of the whole change, not of this turn, at most 72 characters>\n"
+        : "";
     return `Your change is about to commit, but tumwater's pre-queue self-check found problems the
 merge gate or its review is likely to reject:
 ${numberedList(findings)}
@@ -308,137 +362,59 @@ Fix each one in the worktree now with the smallest edit that resolves it, and ke
 as it is. When a finding is wrong, say why in your RISK line instead of forcing a change that
 does not help. Do not run any git command that changes state (no add, commit, reset, checkout) —
 tumwater commits for you.
-When done, reply with ONLY the closing block again — no tool calls, no other text, one line each:
-${SUMMARY_BLOCK}`;
+${description}When done, reply with ONLY these lines about this turn — no tool calls, no other text, one line
+each. tumwater adds them to the change's RISK and VERIFIED lines, marked as the self-check's:
+${summaryLine}  RISK: <for each finding, what you fixed, or why it is wrong and you left it>
+  VERIFIED: <what you ran or read to check this turn's fixes — write none when nothing was run>`;
 }
-/** The note injected into a role's next tick prompt after its previous change was rejected in
- * review. Every tick starts a fresh pi session, so this is the only cross-tick memory of what
- * was built and why it failed — it carries the full reasons, not a summary of them. The whole
- * `lastReview` rides in, not just the reasons: the timestamp and reviewed head let the author
- * weigh a stale objection against main's current state (main may have satisfied it since). */
-export function buildRejectedReviewNote(review, role) {
-    const list = numberedList(review.reasons, NO_REASONS);
-    let context = "";
-    if (review.at !== undefined) {
-        context = ` (${formatTimestamp(review.at)}`;
-        if (review.head)
-            context += `, head ${shortSha(review.head)}`;
-        context += ")";
+/** How much of the hunks a salvage restore could not place one note quotes, per file and in all:
+ * enough to apply a typical leftover by hand without letting one huge rejected file crowd out
+ * the run's own prompt. The full patch is always named for the rest. */
+const UNPLACED_FILE_CHARS = 4_000;
+const UNPLACED_TOTAL_CHARS = 16_000;
+/** The note a run gets when the salvaged work restored into its worktree (src/git/slot-salvage.ts)
+ * did not all go back cleanly because its branch moved since the work was saved: the files left
+ * with conflict markers, with their hunks' line ranges, and the hunks git could not place at all,
+ * quoted for the run to apply by hand (a binary file only named), with the saved patch's path for
+ * anything cut. Undefined when everything went back cleanly. */
+export function buildSalvageRestoreNote(conflicted, unplaced, patchPath) {
+    if (conflicted.length === 0 && unplaced.length === 0)
+        return undefined;
+    const parts = ["The saved edits did not all go back cleanly: your branch moved since they were saved."];
+    if (conflicted.length > 0) {
+        const readHint = listsHunks(conflicted)
+            ? "\nRead each listed hunk's line range plus a few lines of context, not a conflicted file from the top."
+            : "";
+        parts.push(`These files carry conflict markers: \`<<<<<<< ours\` holds the branch's current text and
+\`>>>>>>> theirs\` the saved edits. Resolve every marker (<<<<<<<, =======, >>>>>>>), keeping the
+intent of both sides:
+${conflicted.map(conflictedFileLine).join("\n")}${readHint}`);
     }
-    // On exhaustion the rejected diff is gone. Feature's rejected change often implemented a
-    // PLANS.md entry, and re-authoring the same plan from scratch is what produced the long
-    // rejection runs this note exists to end, so feature is sent to replan the entry instead.
-    // A plan-less role has no downstream loop to replan for it, so it is sent to its own
-    // notebook instead: it records the abandoned purpose and any instances that remain
-    // unhandled, then takes a different theme on the next tick. Re-authoring the same purpose
-    // from the same objections is what restarted the round and produced the long rejection
-    // runs this note exists to end. The markdown-only replan note merges review-exempt, but a
-    // merged change clears the standing rejection (clearSupersededRejection, tick-apply.ts), so
-    // the instruction does not re-inject once the note has merged.
-    let finality = "";
-    if (review.exhausted) {
-        finality =
-            role === "feature"
-                ? ` This was the change's final revision round — the same objection survived two revisions (or the chain hit its cap), so the rejected diff and ref are gone. If it implemented a PLANS.md entry, do not re-author it: append ${NEEDS_REPLAN_NOTE} under that entry's heading, with the numbered objections above quoted beneath it, and merge that markdown-only change and nothing else so the plan role can rewrite the plan. Otherwise, redo the change against current main.`
-                : " This was the change's final revision round — the same objection survived two revisions (or the chain hit its cap), so the rejected diff and ref are gone. Do not re-author it. Record the abandoned purpose and any instances of it that remain unhandled in your notes, then take a different theme on this run: re-deriving the same purpose from the same objections is what produced the long rejection runs this note exists to end.";
+    if (unplaced.length > 0) {
+        let budget = UNPLACED_TOTAL_CHARS;
+        let cut = 0;
+        const quoted = [];
+        for (const { path, diff } of unplaced) {
+            const body = diff.includes("GIT binary patch")
+                ? "(a binary file: its saved version is in the patch below)"
+                : diff.length > UNPLACED_FILE_CHARS
+                    ? `${diff.slice(0, UNPLACED_FILE_CHARS)}\n… (cut; the rest is in the patch below)`
+                    : diff.trimEnd();
+            if (body.length > budget) {
+                cut += 1;
+                continue;
+            }
+            budget -= body.length;
+            quoted.push(`<diff path="${path}">\n${body}\n</diff>`);
+        }
+        parts.push(`These saved hunks could not be placed at all. Apply what still makes sense by hand, and leave
+out what the branch already does:
+${quoted.join("\n")}${cut > 0 ? `\n(${cut} more file(s) not shown: they are in the patch below.)` : ""}`);
     }
-    return `Your previous change was rejected in review${context}:\n${list}\nAddress the objections or take a different approach.${finality}`;
-}
-/** The note injected into a role's tick prompt when its rejected change has been re-applied to
- * current main as uncommitted edits (plans/revise-rejected.md, loop/revision.ts's
- * applyRevision): this tick's one task is to revise the change already in the worktree, not
- * author a new one. The prior objections are numbered so the author can work through them; a
- * revision round past the first also reaches here. The chain keeps revising while each round
- * fixes the prior objection; it ends only on a repeated objection or the backstop (BUGS.md
- * 2026-10-14). A pure function so its shape is pinned in tests. */
-export function buildRevisionNote(review, round) {
-    const list = numberedList(review.reasons, NO_REASONS);
-    return `Your previously rejected change is already in the worktree as uncommitted edits — this
-is revision ${round}. This run's ONE task is to revise it; do not author anything else.
-The review objections were:\n${list}
-Fix each numbered objection with the smallest edit that resolves it, and keep everything else as it
-is. When an objection is about a build-check failure in a test the change does not touch that you
-cannot reproduce, say so in RISK and keep the change as it is. Rewrite the closing block so it
-describes the WHOLE change as it now stands:
-${SUMMARY_BLOCK}
-When an objection shows the change should not exist (its premise is disproven, it duplicates main,
-or it has no reachable benefit), end your reply with the line ${NOTHING_TO_DO} instead, and
-tumwater drops the change.`;
+    parts.push(`The whole saved patch is at ${patchPath}; read it only if you need more than the above.`);
+    return `<salvage-restore>\n${parts.join("\n\n")}\n</salvage-restore>`;
 }
-/** The note appended to a work instance's tick prompt when it holds a claim (plans/parallel-
- * work-instances.md "Claims", part 4/7): the harness has already picked its entry, so the
- * charter's choosing step is replaced. A pure function so its shape is pinned in tests; the
- * range is optional because a claim whose entry was already released still gets the note. */
-export function buildAssignmentNote(claim, range, missingPaths = []) {
-    const where = range ? ` (${claim.file} lines ${range.start}-${range.end})` : ` (${claim.file})`;
-    const intro = claim.source === "staged"
-        ? `Your change moved ONE backlog entry, so it is now your task, replacing your charter's "pick one" step:`
-        : `Tumwater has assigned you ONE backlog entry, replacing your charter's "pick one" step:`;
-    const shown = missingPaths.slice(0, 10).map((p) => `\`${p}\``).join(", ");
-    const rest = missingPaths.length - 10;
-    const missingLine = missingPaths.length === 0
-        ? ""
-        : `\nThe entry names paths that do not exist in your checkout: ${shown}${rest > 0 ? `, and ${rest} more` : ""}. Each was renamed or removed after the entry was written (find its successor with \`git log --follow --name-status -- <path>\` or by grepping for the symbols the entry names), or is a file the entry asks you to create.`;
-    return `<assigned-entry>
-${intro}
-"${claim.title}"${where}.
-Implement or fix only that entry. If it is too large for one run, append ${NEEDS_REVIEW_NOTE} under its heading and end your reply with that note alone. If it should not be done, append a Refused note under its heading with your objection and change nothing else. Do not edit any other backlog entry.${missingLine}
-</assigned-entry>`;
-}
-/** The note appended to an unassigned work instance's prompt when siblings hold backlog entries
- * (plans/parallel-work-instances.md "an exclusion list of held titles"): those entries are
- * someone else's task, so choosing among the rest — or ending with nothing to do — is the
- * instance's whole job. A pure function so its shape is pinned in tests. */
-export function buildHeldEntriesNote(titles) {
-    return `<held-entries>
-Sibling instances hold these backlog entries; do not pick, edit, or implement them, and do not edit their headings. If every remaining entry is held, treat the backlog as having nothing to do for you:
-${titles.map((t) => `- "${t}"`).join("\n")}
-</held-entries>`;
-}
-/** The capped series-part range list shared by the merged-prerequisites and waiting-parts
- * notes: at most five `- "title"` lines, each naming the entry's heading line range, then one
- * `- …and N more` line for the rest, so the two notes list a part's neighbors identically. A
- * pure function so its shape is pinned in tests (test/gate-prompts.test.ts). */
-/** The longest title a compact prompt quotes in an entry list: a PLANS.md heading's tail names
- * the plan's dates and every file it touches, which its range already leads to. */
-const COMPACT_TITLE_CHARS = 100;
-function entryRangeLines(entries, compact = false) {
-    // Cut by code point, so an astral character is never split in half.
-    const title = (t) => {
-        const cps = Array.from(t);
-        return compact && cps.length > COMPACT_TITLE_CHARS ? `${cps.slice(0, COMPACT_TITLE_CHARS).join("").trimEnd()}…` : t;
-    };
-    const lines = entries.slice(0, 5).map((e) => `- "${title(e.title)}" (${e.file ?? "PLANS.md"} lines ${e.start}-${e.end})`);
-    if (entries.length > 5)
-        lines.push(`- …and ${entries.length - 5} more`);
-    return lines;
-}
-/** The note appended to a series part's assignment when parts it requires already merged: each
- * one's Done heading, file (PLANS-DONE.md once archived) and line range, so the implementer reads
- * exactly what that part changed instead of searching a history that runs to thousands of lines.
- * Lists at most five, then a count of the rest. A pure function so its shape is pinned in tests. */
-export function buildMergedPrerequisitesNote(entries, 
-/** The compact prompt every run gets: each title cut to COMPACT_TITLE_CHARS. */
-compact = false) {
-    const lines = entryRangeLines(entries, compact);
-    return `<merged-prerequisites>
-Your assigned entry builds on parts that are already merged. Each one's Done entry records what it actually changed; read one by its range when your entry depends on its details, rather than searching the backlog files:
-${lines.join("\n")}
-</merged-prerequisites>`;
-}
-/** The note injected into a role's prompt after leftover recovery discarded its pinned change
- * at MERGE_CONFLICT_LIMIT (src/loop/leftover.ts): at the cap recovery ordinarily hands the
- * change back to its author with markers instead, so a discard means that lineage already used
- * its hand-back. The merge failures were harness-level, so without the note the author would
- * never learn its work is gone — or that redoing it from memory of the old diff would conflict
- * again. A pure function so its shape is pinned in tests. */
-export function buildConflictDiscardNote(summary, attempts) {
-    return (`Your previous change ("${summary}") was discarded without merging: it conflicted with main ` +
-        `${attempts} times and conflict resolution could not reconcile it. Main has moved on since you ` +
-        `wrote it. If the change is still needed, redo it against current main, starting from main's ` +
-        `current version of the files it touched rather than your earlier diff.`);
-}
-/** The note appended to a role's tick prompt when a change was handed back to it with the
+/** The note appended to a role's run prompt when a change was handed back to it with the
  * conflict markers left in place (PLANS.md "Robust conflict landing, part 2/2"): the merge
  * resolver could not settle it, so the author — who knows what the change was for — resolves it
  * over current main. `reason` says whether it was an approved change whose merge kept
@@ -467,46 +443,3 @@ ${files}${readHint}
 ${conflictIntentBlocks(intent)}
 </conflict-handback>`;
 }
-/** The note injected into the `bugfix` healer's prompt when main's own suite is red (PLANS.md
- * "Red-main handoff"): the gate's warning event is harness-level and no role prompt reads it, so
- * the one role allowed to author on a red main is told what failed and that fixing it is this
- * tick's job. The healer's normal charter is a starting point, not a fit — a red main blocks
- * every other code role, and the gate's deterministic pre-check rejects any change that leaves
- * the suite red, so authoring anything else first is waste. A pure function so its shape is
- * pinned in tests; script/headline are optional because a red carries a failing script, but the
- * note must still read sensibly if it is ever absent. */
-export function buildMainRedNote(sha, script, headline, tail) {
-    const what = script
-        ? `${script}${headline ? `: ${headline}` : ""}`
-        : (headline ?? "the project's declared check");
-    // A red baseline already carries the check's bounded clipped tail (clipBuildTail, ≤12 lines:
-    // the failing test's name, the error-message line, then the stack). Hoist it into the note so
-    // the healer starts from the actual assertion and stack instead of the one-line headline —
-    // often just the test name — and must burn its run reproducing the failure first. The tail is
-    // fenced and labeled, and never touches the directive lines above, so the failure's own text
-    // cannot read as instructions to the role. An absent, empty, or all-blank tail renders today's
-    // exact note. */
-    const output = (tail ?? []).map((l) => l.trim()).filter((l) => l !== "");
-    const tailBlock = output.length > 0
-        ? `\nFailing check output (${output.length} lines):\n\`\`\`\n${output.join("\n")}\n\`\`\`\n`
-        : "";
-    return `<main-red>
-main's own suite is red at ${shortSha(sha)} (${what}). Every code-producing role is skipping authoring and no change merges until main is green.
-This run your job is to make main green: reproduce that failure, fix it (add a regression test where one is feasible), and merge the fix.
-The review gate's deterministic pre-check runs main + your change, so a change that leaves the suite red is rejected — do not author anything else first.
-If the failure is environmental — flaky, load-sensitive, or a broken local toolchain — say so plainly in your reply rather than editing unrelated code.
-${tailBlock}</main-red>`;
-}
-/** The note appended to an assigned series part's prompt naming the later planned parts that
- * wait on it, so the implementer sees where its part ends and leaves their share alone. At most
- * five are listed, then a literal `- …and N more` line (the `moreSuffix` phrase renders inline,
- * not as a list line). A pure function so its shape is pinned in tests. */
-export function buildWaitingPartsNote(entries, 
-/** The compact prompt every run gets: each title cut to COMPACT_TITLE_CHARS. */
-compact = false) {
-    const shown = entryRangeLines(entries, compact);
-    return `<waiting-parts>
-Later parts of your series wait for yours to land, and each one plans its own share of the work: do none of it here, and keep in place the names and files they say your part leaves behind. Read one by its range when you need to know what it expects:
-${shown.join("\n")}
-</waiting-parts>`;
-}