create-religion 1.4.0 → 1.6.0

package/template/.claude/hooks/write-handoff.mjs

@@ -8,7 +8,7 @@
  */
 
 import { createHash } from "node:crypto";
-import { existsSync, lstatSync, readFileSync, writeFileSync } from "node:fs";
+import { closeSync, constants, existsSync, fstatSync, lstatSync, openSync, readdirSync, readFileSync, readSync, realpathSync, statSync, writeFileSync } from "node:fs";
 import path from "node:path";
 
 const STATE = "religion";
@@ -49,10 +49,10 @@ const capped = (items) =>
   items.length > LISTED ? [...items.slice(0, LISTED), `and ${items.length - LISTED} more in \`${STATE}/context/findings.md\``] : items;
 
 const blocking = capped(
-  [...findings.matchAll(/^### (F-\d+) \[(P[01])\] (open|fixed) - (.+)$/gim)].map((m) => `${m[1]} [${m[2]}] ${m[3]} - ${plain(m[4])}`)
+  [...findings.matchAll(/^### ((?:[\w-]+\/)?F-\d+) \[(P[01])\] (open|fixed) - (.+)$/gim)].map((m) => `${m[1]} [${m[2]}] ${m[3]} - ${plain(m[4])}`)
 );
 // Unconfirmed findings are the least trusted titles in the ledger, so only their identifiers.
-const unverifiedIds = [...findings.matchAll(/^### (F-\d+) \[(P[0-3])\] unverified - /gim)].map((m) => `${m[1]} [${m[2]}]`);
+const unverifiedIds = [...findings.matchAll(/^### ((?:[\w-]+\/)?F-\d+) \[(P[0-3])\] unverified - /gim)].map((m) => `${m[1]} [${m[2]}]`);
 const unverified = unverifiedIds.length > 10 ? [...unverifiedIds.slice(0, 10), `and ${unverifiedIds.length - 10} more`] : unverifiedIds;
 
 // The same stamp overview writes and status compares: the plans' SHA-256, first 16 characters.
@@ -62,6 +62,90 @@ const stale = stamp !== undefined && stamp !== plansHash;
 
 const notes = (inbox.match(/^- .+$/gm) ?? []).length;
 
+// Items active in the repository's other worktrees, found as status finds them: from git's own
+// worktree records, since this hook runs no subprocess. A spec there is written by whoever
+// works in that worktree, so what is copied from it is cleaned like a ledger title.
+const quiet = (fn) => {
+  try {
+    return fn();
+  } catch {
+    return null;
+  }
+};
+const gitDir = (dotgit) => {
+  const stat = quiet(() => statSync(dotgit));
+  if (!stat) return null;
+  if (stat.isDirectory()) return dotgit;
+  const target = quiet(() => readFileSync(dotgit, "utf8"))?.match(/^gitdir:\s*(.+)$/m)?.[1]?.trim();
+  return target ? path.resolve(path.dirname(dotgit), target) : null;
+};
+const headBranch = (git) => quiet(() => readFileSync(path.join(git, "HEAD"), "utf8"))?.match(/^ref:\s*refs\/heads\/(.+)$/m)?.[1]?.trim() ?? null;
+// Another worktree's branch decides what its spec is: a link could point at a device that never
+// ends, or at a file whose first heading would be copied in as a title. So it is opened without
+// following a link or blocking, checked through the open handle, and read up to a cap.
+const readPlain = (file, within) =>
+  quiet(() => {
+    // The folder is resolved so a linked directory cannot lead outside that worktree; the spec
+    // itself is not, so a spec that is a link is refused below.
+    const folder = realpathSync(path.dirname(file));
+    if (!(folder + path.sep).startsWith(within + path.sep)) return null;
+    const resolved = path.join(folder, path.basename(file));
+    const fd = openSync(resolved, constants.O_RDONLY | (constants.O_NOFOLLOW ?? 0) | (constants.O_NONBLOCK ?? 0));
+    try {
+      const stat = fstatSync(fd);
+      if (!stat.isFile() || stat.size > 256 * 1024) return null;
+      // Windows has no O_NOFOLLOW: the name must still be a plain file, the one that was opened.
+      const named = lstatSync(resolved);
+      if (!named.isFile() || named.ino !== stat.ino || named.dev !== stat.dev) return null;
+      const buffer = Buffer.alloc(stat.size);
+      return buffer.subarray(0, readSync(fd, buffer, 0, stat.size, 0)).toString("utf8");
+    } finally {
+      closeSync(fd);
+    }
+  });
+// The rule `religion status` applies: only an `auto` run holds items, each a plan number, capped.
+const heldItems = (source) =>
+  quiet(() => {
+    const record = JSON.parse(source ?? "");
+    if (record?.command !== "auto" || typeof record.summary !== "string" || !["running", "blocked", "ready", "completed"].includes(record.status)) return [];
+    if (!Array.isArray(record.items)) return [];
+    const held = record.items.filter((i) => typeof i === "string" && /^\d+[a-z]?$/i.test(i)).map((i) => i.toLowerCase());
+    return [...new Set(held)].slice(0, 100);
+  }) ?? [];
+const elsewhere = (() => {
+  const self = quiet(() => realpathSync(root));
+  let home = self;
+  let own = null;
+  while (home && !(own = gitDir(path.join(home, ".git")))) home = path.dirname(home) === home ? null : path.dirname(home);
+  if (!home || !own) return [];
+  const commondir = quiet(() => readFileSync(path.join(own, "commondir"), "utf8"));
+  const common = commondir ? path.resolve(own, commondir.trim()) : own;
+  const records = path.basename(common) === ".git" ? [{ dir: path.dirname(common), git: common }] : [];
+  for (const id of quiet(() => readdirSync(path.join(common, "worktrees"))) ?? []) {
+    const git = path.join(common, "worktrees", id);
+    const target = quiet(() => readFileSync(path.join(git, "gitdir"), "utf8"))?.trim();
+    // Git calls a record prunable once the `.git` file it points at is gone.
+    if (target && existsSync(path.resolve(git, target))) records.push({ dir: path.dirname(path.resolve(git, target)), git });
+  }
+  const offset = path.relative(home, self);
+  return records.flatMap(({ dir, git }) => {
+    const tree = quiet(() => realpathSync(dir));
+    if (!tree || tree === home) return [];
+    // A wave's step worktree holds a copy of its parent item's spec, not an item of its own.
+    if (/^step-\d+$/.test(path.basename(tree)) && existsSync(path.join(path.dirname(tree), "base"))) return [];
+    const spec = readPlain(path.join(tree, offset, STATE, "context", "current-work.md"), tree) ?? "";
+    const items = heldItems(readPlain(path.join(tree, offset, STATE, ".state", "run.json"), tree));
+    const holding = items.length > 0 ? `holding items ${items.join(", ")}` : "";
+    const on = `on \`${plain(headBranch(git) ?? tree)}\``;
+    if (!spec.trim() || /_Nothing in progress\./.test(spec)) return holding ? [`- **An automated run** ${on}, ${holding}.`] : [];
+    const item = spec.match(/^\*\*From build plan:\*\*[ \t]*item[ \t]+([0-9a-z]+)/im)?.[1]?.toLowerCase();
+    const name = plain(spec.match(/^#\s+(.+)$/m)?.[1] ?? "Active work");
+    // Spaces and tabs only: `\s` crosses newlines, which makes blank lines quadratic.
+    const steps = `${(spec.match(/^[ \t]*- \[x\]/gim) ?? []).length} of ${(spec.match(/^[ \t]*- \[[ x]\]/gim) ?? []).length}`;
+    return [`- **${name}**${item ? ` (item ${plain(item)})` : ""} ${on}: ${steps} step(s) done${holding ? `, ${holding}` : ""}.`];
+  });
+})();
+
 // Only names the status rule accepts reach this file, which every session loads: no free text
 // from a record any skill can write.
 let run = null;
@@ -97,6 +181,11 @@ if (active) {
   lines.push("Nothing in progress.", "");
 }
 
+if (elsewhere.length > 0) {
+  const more = elsewhere.length - LISTED;
+  lines.push("In flight in other worktrees:", "", ...elsewhere.slice(0, LISTED), ...(more > 0 ? [`- and ${more} more`] : []), "");
+}
+
 lines.push(
   `Plan: ${done} of ${done + open} item(s) complete.` + (nextItem ? ` Next up: ${nextItem}` : ""),
   ""

package/template/.claude/skills/audit/SKILL.md

@@ -96,7 +96,7 @@ context; this does. Create it with a `# Findings` heading if it is missing.
 One block per finding. The header line is the machine-readable part and keeps this exact
 shape; the prose below it is for people.
 
-    ### F-03 [P0] open - Retained auth volumes carry the run label
+    ### 12/F-3 [P0] open - Retained auth volumes carry the run label
 
     **File:** ops/compose.yaml:86
     **Found:** 2026-09-04 by audit (scope: current; lens: security)
@@ -105,12 +105,18 @@ shape; the prose below it is for people.
     **Resolution:**
 
 When the pass is re-reviewing a repair and finds a new problem in the code that repair
-changed, add `**Surfaced by:** F-NN` after **Found**, naming the finding whose repair exposed
-it. That link is what keeps a defect a repair introduced attached to the repair.
-
-Identifiers are sequential within the ledger, one past the highest present, never reused
-and never renumbered while their entries live there. Completion archives resolved entries
-under a work-item prefix, and that prefixed form is the permanent reference.
+changed, add `**Surfaced by:** <identifier>` after **Found**, naming the finding whose repair
+exposed it, in full: `**Surfaced by:** 12/F-3`. That link is what keeps a defect a repair
+introduced attached to the repair.
+
+**Identifiers carry the item they were raised in.** While the active spec has a
+`**From build plan:** item <n>` line, a new finding is `<n>/F-<k>`: item 12's first is
+`12/F-1`, and `k` is one past the highest present with that prefix. Two items built in
+separate worktrees then never hand out the same identifier. With no active planned item, a
+finding is bare, `F-<k>`, one past the highest bare identifier present, as entries raised
+before prefixes are. Either way an identifier is never reused and never renumbered while its
+entry lives in the ledger. Completion archives resolved entries under the item's prefix, and
+that prefixed form is the permanent reference.
 
 | Status | Meaning | Blocks completion at P0/P1 |
 | --- | --- | --- |

package/template/.claude/skills/auto/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: auto
 summary: run the loop unattended, within explicit bounds
-description: "Run the reviewed loop without stopping between steps, within bounds you set. With no argument it takes one work item and stops before completing it; `all` runs the remaining build plan; a number runs that many items; `fix` works through the findings ledger instead, every class most severe first or one class such as `fix P1`, one fix per file and class, re-reviewing every repair and folding any finding a repair surfaces into the same fix. Specs, implements, verifies, applies the configured gates, repairs confirmed high-severity findings, and completes each item. Its invocation grants committing, dependency installs, and remote reads for the run, and grants nothing else: it still stops to ask before any merge. Under git.mode pull-request it lands every item on one shared integration branch and ends by opening a single aggregate review packet it never merges, after stating that whole remote budget up front and being told yes. Use only when the user runs /auto or explicitly asks for an unattended run."
+description: "Run the reviewed loop without stopping between steps, within bounds you set. With no argument it takes one work item and stops before completing it; `all` runs the remaining build plan; a number runs that many items; a range or list such as `1-5` or `6, 7, 8` runs exactly those items; `refresh` brings the default branch into a run's integration branch after another run landed first; `fix` works through the findings ledger instead, every class most severe first or one class such as `fix P1`, one fix per file and class, re-reviewing every repair and folding any finding a repair surfaces into the same fix. Specs, implements, verifies, applies the configured gates, repairs confirmed high-severity findings, and completes each item. Its invocation grants committing, dependency installs, and remote reads for the run, and grants nothing else: it still stops to ask before any merge. Under git.mode pull-request it lands every item on one shared integration branch and ends by opening a single aggregate review packet it never merges, after stating that whole remote budget up front and being told yes. Use only when the user runs /auto or explicitly asks for an unattended run."
 ---
 
 # auto - the same loop, without the pauses
@@ -18,7 +18,11 @@ between steps.
 - `/auto all` - the remaining build plan, completing each item, until it runs out or hits
   a bound.
 - `/auto 3` - the next three items, completing each.
+- `/auto 1-5` or `/auto 6, 7, 8` - exactly those plan items, completing each. A range or
+  a comma list names items; a bare number is always a count. See Named items.
 - `/auto resume` - continue an interrupted run from the file-backed state.
+- `/auto refresh` - bring the default branch into a run's integration branch after another
+  run's aggregate landed first. See Refresh.
 - `/auto fix` - the findings ledger instead of the plan; see Fix mode.
 
 `auto.maxItems` caps successful completions. `auto.maxRepairAttempts` caps repeated
@@ -67,7 +71,7 @@ Before the first item:
   than one that never began.
 - The working tree is clean, or the only dirt belongs to work being resumed.
 - The plan has unchecked items, or in fix mode the ledger has `open` or `fixed` findings in
-  range.
+  range. A named run needs at least one of its own items unchecked.
 - Under `pull-request`, the repository can host one: a remote exists and the host command
   works. A repository that cannot is a stop, not a reason to fall back to local merges. The
   mode exists to produce review gates, and silently producing a different history instead
@@ -84,6 +88,24 @@ if one exists that does not descend from the recorded commit, stop, because the
 moved and that needs a person. Never rebase, reset, or force-push it: it is append-only for
 the run.
 
+A named run's integration branch adds its items to the date, `<prefix><date>-<first>-<last>`,
+or `-<item>` for one, with labels as the plan writes them: `auto/2026-10-26-6-10`. Two runs on
+one day then never share a name, and a resume finds its own.
+
+**With `workflow.parallelItems` on**, under `pull-request`, the run works in its own worktree so
+another session can run beside it. The main checkout must be on the default branch at the
+recorded commit, since the worktree is made from `HEAD`; anything else stops. Make the
+integration branch with blocks 1 and 2 of the routine /implement keeps in
+`reference/item-worktree.md`, with `move='no'`, push it from the worktree, and work from there
+from then on: move the session into it where the tool can, and otherwise address every file and
+command to its path. Item branches stay plain branches, made and removed inside that worktree,
+so the main checkout stays on the default branch for the next session. Under
+`branch-per-item`, which merges each item into the default branch only one checkout can hold, a
+run stays in the main checkout and runs alone.
+
+**Resuming from the main checkout** while a run's worktree exists names that worktree and its
+branch and stops: the run resumes from there, never as a second copy here.
+
 State the bounds, the gates in force, and how many items are in range. Then start.
 
 ## Step 2 - each item
@@ -115,6 +137,102 @@ nothing left to build and stops there.
 
 An item counts against `auto.maxItems` once it has landed, not once it is built.
 
+## Named items
+
+Given a range or a list, the run builds those items and no others.
+
+- **Plan order**, whatever order they were given in, since the waiting rule assumes it.
+- **A ticked item** is named and passed over. **A number the plan does not have** stops the
+  run before any work starts, naming it: a typo should not quietly shrink the run.
+- **The waiting rule still applies.** An item waiting on one outside the list, or on a
+  spike, is passed over and named in the final report, as in Step 2.
+- **Refuse what another run holds.** Before any work, read `religion status --json`, or the
+  handoff without that command. A named item that an `inFlight` entry with `here` false holds
+  under `items` or is building, counting a parent and its sub-items as one, stops the run,
+  naming each such item and the branch that has it: two runs over one item is what holding
+  exists to prevent.
+- **Name what waits on another run.** A named item that waits on an item held elsewhere will
+  be passed over, since that item lands on the other run's integration branch, not this one.
+  Name each when stating the bounds, with what it waits on and the branch that holds it, so a
+  run that will build fewer items than it was given says so before it starts.
+- **Hold them.** The first write, made before the configuration is read, holds no `items`.
+  Once preflight knows where the run will run, write the listed items, lowercased, as `items`
+  in the record there, and keep them in every rewrite. A run that moves into its own worktree
+  writes them only in the worktree, then rewrites the main checkout's record as `completed`,
+  holding none and with no resume command, its summary naming the worktree: nothing resumes
+  from the main checkout, and a record holding the items there would read, from the run's own
+  worktree, as another run holding them. That is what lets `status`, the handoff and
+  /feature in another worktree pass over the items this run has not reached yet, which no
+  spec shows.
+- **Release them only when none is left to build**, each named item completed, already
+  ticked, or passed over as waiting. That release is the run's last write, made after Step 3
+  has opened the aggregate pull request where the mode has one, and it is `completed` although
+  the run ends waiting for review: `completed` is what says nothing remains to resume. It keeps
+  just the items the run completed, so the ones it passed over are free for another worktree to
+  take; a parent number stays only when every sub-item under it was completed, since a parent
+  still held holds all of them. A run that completed nothing has no aggregate to open, so it
+  releases at once, `completed` and holding none. Any other stop, a merge question, a bound, a
+  failure, an aggregate pull request opened early, or one Step 3 should have opened and did not,
+  keeps every item and writes `blocked` with `/auto resume`.
+- **Resume.** A record holding `items` resumes those still unticked, and when every one is
+  ticked it resumes at Step 3; a `completed` one has nothing left to resume. A record without
+  `items` is a count, `all` or fix run, and resumes as one. A named run whose record is gone
+  stops and asks for the list again rather than guessing which items it had.
+
+Plain numbers and sub-item labels are both items (`39a, 39b`); a range covers whole numbers
+only. A number that has sub-items stands for its unticked sub-items: build those, and record
+their labels in `items` beside the number, so readers that do not walk the plan still see
+them.
+
+## Refresh
+
+`/auto refresh` catches a run up when another run's aggregate pull request merged into the
+default branch first. Both wrote the plan, the ledger and the journal, so this run's aggregate
+now conflicts on them every time. It runs where the run's integration branch is checked out, in
+the run's own worktree when it has one, and only when all of these hold; otherwise it stops and
+says which:
+
+- the checked-out branch starts with `git.integrationBranchPrefix` and is not the default
+  branch, and the run's aggregate pull request is open with it as head and the default branch
+  as base
+- the run's own record, here, is `blocked` or `completed`, never `running`, and the spec is the
+  stub and the tree clean
+- after fetching it, the branch is at its remote-tracking copy or can fast-forward to it, which
+  is how an item merged on the host since reaches it; or it is ahead only by an earlier
+  refresh's own merge, one commit whose second parent is on the default branch, left by a
+  rejected push. Ahead by that merge and behind as well means the merge was made on a stale
+  branch: stop, naming the merge commit and saying why. Dropping it is a reset, first-tier and
+  the person's to take, after which a refresh starts again from the remote copy. Any other
+  difference stops
+
+A refresh writes **no activity record**, the one exception to writing one first: the record is
+the run's, and the `items` it holds are what keep other worktrees off the run's work.
+
+Its remote budget is asked for **before any work starts**, in full, as a run's is:
+
+    This refresh will, without asking again:
+      push <integration branch>, adding one merge commit that brings in <default branch>
+      update the body of its aggregate pull request <number>
+
+    It will not merge or push <default branch>, will not force-push,
+    and will not merge the aggregate pull request.
+
+Then, when the branch is behind, fast-forward it. When an earlier refresh's merge is waiting,
+push it as it is, add the body line, and end. Otherwise fetch the default branch and follow "A
+run catching up" in /complete's `reference/land-on-top.md`: blocks 1 to 3 with the
+default branch's remote-tracking name as the target, redoing the share of every item the run
+completed; `nothing landed since` ends the refresh with nothing to do. Run the full `Verify`.
+Only when it passes, commit the merge, push the integration branch by name, never forced, and
+add a line to the aggregate's body naming the default-branch commit brought in and the files
+redone. A rejected push is a stop that keeps the merge commit locally and says so. Once the
+cause is put right, `/auto refresh` again pushes it; when the push was refused because the
+branch moved on the host, it stops on the stale merge as above.
+
+Stop, keeping the state as it is, on a conflict outside the shared files, which the routine
+reports and abandons; on a failing `Verify`, abandoning the merge with the routine's block; or
+when nothing landed since. A refresh never rebases, resets or force-pushes the integration
+branch, and the run's activity record and the items it holds are left as they were.
+
 ## Fix mode
 
 `/auto fix` works through the findings ledger instead of the build plan, under the same

package/template/.claude/skills/complete/SKILL.md

@@ -93,9 +93,9 @@ Read the spec's type.
 
 The number lives in the path. It never appears in the commit message.
 
-**Record what landed.** After the work commit exists in Step 3, append a `## Landed`
-section to the archive with the exact commits this item produced, oldest first, and the
-commit that preceded them:
+**Record what landed.** After the work commit exists in Step 3, and after Step 4 has landed
+it on top of anything that landed first, append a `## Landed` section to the archive with the
+exact commits this item produced, oldest first, and the commit that preceded them:
 
     ## Landed
 
@@ -110,9 +110,10 @@ commits sit among others on the same branch, so this record is the only reliable
 
 **Prune the ledger.** Append every `closed`, `accepted`, and `invalid` entry to a
 `## Findings` section in the archive just written, at its final status, with the reason
-preserved for accepted entries. Prefix each identifier with the archive name so it is
-globally unique: item 12's `F-03` becomes `12/F-03`, and that prefixed form is the
-permanent reference.
+preserved for accepted entries. Every archived identifier carries a prefix, so it is
+globally unique, and that prefixed form is the permanent reference. One raised under the
+item's prefix already has it and moves across unchanged: item 12's `12/F-3` stays `12/F-3`.
+Prefix only a bare one, with the archive name: item 12's `F-03` becomes `12/F-03`.
 
 Then remove only those entries from the ledger. `open`, `fixed`, and `unverified` entries
 stay, with their identifiers, so nothing is silently dropped. A `fixed` P2 does not block
@@ -195,6 +196,15 @@ is refused outright when any of those commits has already been pushed.
 Under **`git.mode: trunk`** the work is already on the branch you were on. There is nothing
 to merge. Go to Step 5.
 
+**Under either branching mode, land on top of what already landed.** Before the squash merge
+or the push, follow `reference/land-on-top.md`. When the branch the item lands in has moved
+since the item began, because another item built in its own worktree landed first, it brings
+that in, takes the landed copy of each of the plan, ledger, journal, overview and handoff that
+the other item changed, and redoes this item's share of them, so those files are never merged
+as text. Any other conflict stops
+for review. When nothing landed in between, it does nothing. Write the `## Landed` record after
+it, as its last section says, so a later rollback reverses this item's work alone.
+
 Under **`branch-per-item`**:
 
 1. Squash-merge into the default branch, only with an explicit yes, so the item lands as
@@ -245,6 +255,12 @@ confirm the work commit is actually in it, and only then delete the branch local
 the remote. A squash-merge leaves no merge parent, so `git branch -d` will refuse; verify
 the content landed before reaching for `-D`.
 
+An item built in its own worktree holds its branch there, so the cleanup runs from the main
+checkout: remove the worktree first, then the branch. Removing the worktree is deleting files,
+so it asks, every time, and only once the work commit is confirmed in the default branch. When
+the state directory is ignored, the item's record is in the worktree alone until the routine's
+last section has copied it to the main checkout; say so when asking.
+
 ## Step 5 - say how to try it
 
 Always end with the manual walkthrough for what just landed: what to start, where to go,

package/template/.claude/skills/complete/reference/land-on-top.md

@@ -0,0 +1,188 @@
+# Landing on top of what already landed
+
+Used before an item's branch is squash-merged or pushed, when the branch it lands in has moved
+since the item began: another item, built in its own worktree, landed first. Both items wrote
+the same state files, and a text merge of those conflicts every time, because each holds
+bookkeeping derived from its own branch. So the landed copy of each is taken, and this item's
+share of it is done again on top.
+
+The **target** is the branch the item lands in: the default branch, or an automated run's
+integration branch. Under `pull-request`, fetch it first, which is a network read and asks
+outside an automated run, and use the remote-tracking name, such as `origin/main`.
+
+The merge this makes is a commit on the item's own branch, like the work commit, and is covered
+by the same yes; it never writes the target.
+
+Run each block as **one** command, from the item's checkout, after the work commit. Each runs in
+a subshell and sets what it needs. A block that stops ends the landing: report what it printed
+and stop. A stop after block 1 leaves the merge open: either put right what the block named and
+run it again, or abandon the merge with the block in "Abandoning the merge" below.
+
+## 1. Bring in what landed
+
+    (
+      root=$(git rev-parse --show-toplevel) || exit 1
+      target='<the target>'
+      [ -z "$(git -C "$root" status --porcelain -- . ':!religion/context/handoff.md')" ] ||
+        { echo "uncommitted changes; make the work commit first"; exit 1; }
+      git -C "$root" checkout -q -- religion/context/handoff.md 2>/dev/null
+      git -C "$root" rev-parse -q --verify "$target^{commit}" >/dev/null || { echo "no such target: $target"; exit 1; }
+      if git -C "$root" merge-base --is-ancestor "$target" HEAD; then echo "nothing landed since"; exit 0; fi
+      git -C "$root" merge --no-commit --no-ff "$target"
+      git -C "$root" rev-parse -q --verify MERGE_HEAD >/dev/null || { echo "the merge did not start"; exit 1; }
+      base=$(git -C "$root" merge-base HEAD MERGE_HEAD)
+      for f in build-plan.md context/findings.md learning/journal.md context/project-overview.md context/handoff.md; do
+        p="religion/$f"
+        git -C "$root" diff --quiet "$base" MERGE_HEAD -- "$p" && continue
+        if git -C "$root" cat-file -e "MERGE_HEAD:$p" 2>/dev/null; then
+          git -C "$root" checkout MERGE_HEAD -- "$p" || exit 1
+          echo "taken as landed: $p"
+        else
+          git -C "$root" rm -q -f --ignore-unmatch -- "$p" || exit 1
+          echo "no longer tracked by the target: $p"
+        fi
+      done
+      left=$(git -C "$root" diff --name-only --diff-filter=U)
+      if [ -n "$left" ]; then
+        echo "conflicts outside the shared state files:"; echo "$left"
+        git -C "$root" merge --abort; exit 1
+      fi
+      echo "merged; redo this item's share of each file taken as landed"
+    )
+
+`nothing landed since` means the target is already part of the branch: skip the rest. Only a
+shared file the target changed since the item began is taken from it; one it left alone merges
+as usual, carrying this item's changes with nothing to redo. A shared file the target stopped
+tracking is removed, as the target has it; this item's copy is still in `HEAD`. The handoff is generated and rewritten at the end of every turn, so discarding it loses nothing.
+
+Taking the target's copy of a shared file resolves that file, conflicted or not. A conflict in
+any other file, product code included, is not this routine's to settle: the merge is abandoned,
+the branch is exactly as it was, and the paths are reported for review. Never resolve them by
+taking either side.
+
+While the merge is open, `HEAD` is this item's own work and `MERGE_HEAD` is what landed.
+
+## 2. Redo this item's share
+
+For each file block 1 took as landed, edit it as it now stands, taking this item's part from
+`HEAD`'s copy, as `git show HEAD:religion/<file>` prints it:
+
+| File | This item's share |
+| --- | --- |
+| `build-plan.md` | a feature ticks its line, and its parent once every sub-item is ticked; a rollback unticks its target and adds its note; a fix or refactor campaign has none |
+| `context/findings.md` | append each entry `HEAD`'s copy holds that the merge base's did not, still `open`, `fixed` or `unverified`, unchanged; one whose identifier the landed copy already holds, two fixes' bare `F-1` say, takes its permanent prefixed form, the archive's name before it as completion would archive it, and the rename is reported; when the landed copy is the stub, replace its placeholder line |
+| `learning/journal.md` | append its entry, the one whose `**Archive:**` line names this item's archive |
+| `context/project-overview.md` | none: left as landed, and stale until /overview runs, as after any completion |
+| `context/handoff.md` | none |
+
+Then compare `HEAD`'s ledger with the merge base's,
+`git diff $(git merge-base HEAD MERGE_HEAD) HEAD -- religion/context/findings.md`. A change this
+item made to an entry it did not add is not carried, since the landed copy is the one kept; name
+each such entry in the report so it can be made again by hand.
+
+Everything else, this item's archive included, merged as git merges it.
+
+## 3. Check, then commit the merge
+
+Stage the redone files for the merge commit, then check them:
+
+    (
+      root=$(git rev-parse --show-toplevel) || exit 1
+      for f in build-plan.md context/findings.md learning/journal.md context/project-overview.md context/handoff.md; do
+        [ -e "$root/religion/$f" ] && git -C "$root" ls-files --error-unmatch -- "religion/$f" >/dev/null 2>&1 &&
+          { git -C "$root" add -- "religion/$f" || exit 1; }
+      done
+      for f in build-plan.md context/findings.md learning/journal.md; do
+        ! grep -n -e '^<<<<<<< ' -e '^>>>>>>> ' -- "$root/religion/$f" 2>/dev/null || { echo "conflict markers in religion/$f"; exit 1; }
+      done
+      [ -z "$(git -C "$root" diff --name-only --diff-filter=U)" ] || { echo "unresolved paths remain"; exit 1; }
+      echo "ready for Verify"
+    )
+
+Only the files edited by hand are searched: git leaves no markers in a file it merged cleanly,
+and a document elsewhere may show one on purpose.
+
+Run the project's full `Verify` on the result: it is new code, made of both items, and neither
+was checked against the other. A turn that ends before the merge is committed has its handoff
+rewritten by the hook; run block 3 again before committing, which stages it only while the index
+still tracks it.
+
+When `Verify` passes, commit the merge with a message that says what was brought in, such as
+`merge: bring in what landed on main`.
+
+When it fails, abandon the merge with the block below, which returns the branch to its work
+commit, and stop with the failure. The item is complete on its branch but cannot land as it
+stands: the way forward is /fix here, describing the failure, built on this branch.
+Completing that fix lands both through this routine: block 2 then redoes the share of both, the
+item's and the fix's, every row, each taken from `HEAD`, and the `## Landed` record goes into
+both archives with the one range they share, each saying it is shared.
+
+## Abandoning the merge
+
+    (
+      set -o pipefail
+      root=$(git rev-parse --show-toplevel) || exit 1
+      git -C "$root" rev-parse -q --verify MERGE_HEAD >/dev/null || { echo "no merge open"; exit 0; }
+      g="$(git -C "$root" rev-parse --absolute-git-dir)/abandon"
+      list() { git -C "$root" -c core.quotePath=false "$@"; }
+      list ls-files -o | LC_ALL=C sort >| "$g.before" || exit 1
+      { list diff --name-only --no-renames HEAD && list diff --cached --name-only --no-renames HEAD; } >| "$g.tracked" || exit 1
+      git -C "$root" reset -q --hard HEAD; rc=$?
+      list ls-files -o | LC_ALL=C sort >| "$g.after" || exit 1
+      { cat "$g.tracked"; LC_ALL=C comm -23 "$g.before" "$g.after"; } | LC_ALL=C sort -u | sed 's/^/discarded: /'
+      rm -f "$g.before" "$g.after" "$g.tracked"
+      [ "$rc" -eq 0 ] || { echo "the reset failed: the merge is still open, and a path named above may not be set back"; exit 1; }
+      list ls-files -o --exclude-standard --directory | sed 's/^/left untracked: /'
+      echo "back at the work commit"
+    )
+
+Block 1 started from a clean tree, so the work commit is the whole of this item's work, and
+resetting to it ends the merge and returns the branch exactly as it was, whatever the merge left:
+redone shares, a handoff the hook rewrote, output `Verify` regenerated, paths still in conflict.
+Each path the reset set back or removed is named once: every tracked path whose working or staged copy
+differed from the work commit, an edit made by hand while the merge was open among them, and every untracked or
+ignored file in the way of a path the work commit has, such as one inside a directory the target
+put where a file was, found by listing them with git before the reset and after it. Other
+untracked files are left where they are and named, a whole directory as one line. Names are
+printed as git prints them, quoted where they hold unusual characters. So nothing is lost without
+a word. A reset that fails, such as on a directory it cannot write, still names what it removed,
+then says the merge is still open: put right what git named and run the block again. Never
+abandon with `git merge --abort` alone, which refuses while a file the merge touched has unstaged
+changes. With no merge open, the block does nothing.
+
+## 4. Record what landed
+
+When a merge was made, the item's `## Landed` record names the last such merge's second parent,
+the target it brought in, as **Base**, and that merge commit and anything after it as **Commits**:
+`git diff` from that base to the last commit is then this item's work alone, which is what a
+rollback reverses. Without a merge, the record is as `/complete` describes. Commit the
+record: in a worktree, an uncommitted file goes when the worktree is removed.
+
+## A run catching up
+
+`/auto refresh` uses blocks 1 to 3 for a whole run rather than one item, when another run's
+aggregate pull request merged into the default branch first. The checkout is the run's
+integration branch, between items, and the target is the default branch's remote-tracking name,
+such as `origin/main`, fetched first. The merge is a commit on the integration branch, which
+stays append-only: nothing is rebased, reset or force-pushed.
+
+Block 2's share is every item the run completed, each row as the table gives it: every one of
+the run's plan ticks, and a parent's once all its sub-items are ticked; the ledger entries
+`HEAD` holds beyond the merge base, as for one item; and each journal entry whose `**Archive:**`
+names one of the run's archives. Block 4 does not apply: each item's `## Landed` record already
+names its own commits on the integration branch, and the refresh's merge belongs to none of them.
+
+## When the state directory is ignored
+
+Then none of these files are in git, and the merge carries none of them: this item's archive,
+plan tick, journal entry and ledger exist only in its worktree's copy of `religion/`. Before
+the worktree can be removed, redo this item's share, as the table in block 2 lists it, in the
+main checkout's own `religion/` files, and copy this item's archive there. When this landing
+follows a failed `Verify`, that is the share and the archive of both, the item's and the fix's. With no `HEAD` copy
+or merge base in git, the worktree's own files are this item's part, and the ledger saved when
+the worktree was made, `religion/.state/findings-at-start.md` in it, is the base: an entry the
+worktree's ledger holds that the saved one did not is this item's. Comparing the two also shows
+each entry this item changed or removed, a repair it closed and pruned among them: make the
+same change in the main checkout's ledger, or name the entry in the report, so a finding this
+item closed does not stay open there. Removing the worktree deletes ignored files with it, so
+until then they are the only record.

package/template/.claude/skills/distill/SKILL.md

@@ -56,7 +56,8 @@ finding, already repaired, is an incident.
 
 For each group that earns it, propose the coding-standard rule that would have prevented every
 finding in it, in the standards' own voice, as an instruction for work not yet started, with the
-findings cited by identifier. A rule that only restates one finding is not a standard. Skip a
+findings cited by their archived identifier, prefix included, such as `39a/F-2` or `27/F-161`.
+A rule that only restates one finding is not a standard. Skip a
 group already recorded in `religion/learning/journal-archive.md` unless it has grown since.
 
 ## Step 3 - route by kind

package/template/.claude/skills/feature/SKILL.md

@@ -65,7 +65,12 @@ plan top to bottom and take the first unchecked leaf that waits on nothing: an i
 those is unticked, or says `spike first` and no archive under `religion/history/spikes/` records
 `**For:** item N` with `**Settled:** yes`. Wording inside a code span does not count.
 Name each item passed over and what it waits on, and point a spike-first one at
-/spike. State which item you are spec'ing before going further.
+/spike. An item another worktree is already building is passed over too: one that
+`religion status --json` lists under `inFlight` with `here` false, or, without the `religion`
+command, one the handoff lists as in flight in another worktree. So is an item an automated
+run in another worktree holds: one listed under `items` on an `inFlight` entry with `here`
+false, or named as held in the handoff. Name it with its branch.
+State which item you are spec'ing before going further.
 
 Asked by number for an item that waits, say what it waits on and stop: speccing it now
 builds on an answer nobody has yet. A reference to an item the plan does not have, or items

package/template/.claude/skills/fix/SKILL.md

@@ -14,8 +14,9 @@ numbered, it ticks nothing, and it archives on its own.
 - **A description** - `/fix "password reset email never sends"`. A problem stated in the
   conversation already counts; this skill does not scan the project hoping to find
   something wrong.
-- **Finding identifiers** - `/fix F-03` specs the repair of that ledger entry, and
-  `/fix F-03 F-07` repairs several together. Group findings only when they share a file
+- **Finding identifiers** - `/fix 39a/F-2` specs the repair of that ledger entry, and
+  `/fix 39a/F-2 F-07` repairs several together. An identifier is used exactly as the
+  ledger heads it, with an item prefix when it has one, bare when it does not. Group findings only when they share a file
   and a severity, as /auto's fix mode does: one fix then stays one reviewable diff.
 
 - **An issue** - `/fix #42` or its link. Read it through the host's own command-line tool, for example `gh issue view 42 --json title,body,url` on