create-religion 1.1.0 → 1.2.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-religion",
-  "version": "1.1.0",
+  "version": "1.2.0",
   "description": "A file-backed, spec-driven AI development workflow. Spec before code, small reviewed diffs, and project state in markdown so a cleared context costs nothing.",
   "license": "MIT",
   "author": "Nate",

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

@@ -104,6 +104,10 @@ shape; the prose below it is for people.
     **Suggested fix:** ...
     **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.
@@ -122,9 +126,9 @@ After reviewing:
 - Append each new confirmed finding as `open`.
 - Record a lead worth tracking as `unverified`. It never gates anything.
 - Update entries this pass re-examined, noting the evidence in **Resolution**.
-- Move `fixed` to `closed` only when all three hold: this pass covered the finding's file,
+- Move `fixed` to `closed` only when all four hold: this pass covered the finding's file,
   re-examining the repaired code confirmed the defect is gone and nothing worse replaced
-  it, and the report names it as closed. An unrelated new problem in the same file gets its
+  it, no finding it surfaced is still `open` or `fixed`, and the report names it as closed. An unrelated new problem in the same file gets its
   own entry. Never close implicitly.
 - Set `accepted` only on the user's explicit decision, with their reason. Never on their
   behalf.

package/template/.agents/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. 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; `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
@@ -19,6 +19,7 @@ between steps.
   a bound.
 - `$auto 3` - the next three items, completing each.
 - `$auto resume` - continue an interrupted run from the file-backed state.
+- `$auto fix` - the findings ledger instead of the plan; see Fix mode.
 
 `auto.maxItems` caps successful completions. `auto.maxRepairAttempts` caps repeated
 attempts at the same finding. `auto.finalAudit` adds one review across everything the run
@@ -65,7 +66,8 @@ Before the first item:
   starts, naming the question, since a run that stops halfway through item four is worse
   than one that never began.
 - The working tree is clean, or the only dirt belongs to work being resumed.
-- The plan has unchecked items.
+- The plan has unchecked items, or in fix mode the ledger has `open` or `fixed` findings in
+  range.
 - 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
@@ -110,6 +112,45 @@ For every item, in plan order:
 
 An item counts against `auto.maxItems` once it has landed, not once it is built.
 
+## Fix mode
+
+`$auto fix` works through the findings ledger instead of the build plan, under the same
+grant, gates, landing and stop rules.
+
+- `$auto fix` or `$auto fix all` - every class, P0 first, until no `open` finding is
+  left or a bound is reached.
+- `$auto fix P0` through `$auto fix P3` - only that class.
+
+**The queue.** Read `religion/context/findings.md` afresh before each fix, because every fix
+and every review changes it. Take the classes in turn, most severe first. Within a class, the
+`open` findings that name the same file form one group, oldest first, and each group is one
+work item: specced by $fix with all of its identifiers, then implemented, gated,
+completed and landed exactly as Step 2 does for a plan item. A fix confined to one file and
+one class stays a diff someone can review; a fix that sweeps several is not.
+
+`unverified` findings are not repaired. Nothing has confirmed them, and repairing a guess
+produces a change nobody can check; report them instead. `fixed` findings in range are
+re-reviewed rather than repaired again, because the repair exists and only a review can
+close it.
+
+**Every repair is re-reviewed.** Repair is the whole point of this mode, so after
+implementation the repaired findings always go to $audit in a subagent with fresh
+context, whatever `qualityGates.audit` says. Only that review closes a finding.
+
+**Folding.** When that review raises a new finding in code the fix changed, the audit records
+it under its own identifier with a `**Surfaced by:**` line naming the finding whose repair
+exposed it, and it joins the current fix as another repair step, whatever its class. The
+finding that surfaced it cannot close while it is `open` or `fixed`. A defect a repair
+introduced belongs with that repair: left for a later fix, it loses the context that
+explains it.
+
+**Bounds.** `auto.maxRepairAttempts` caps the attempts at any one finding. A fix folds in at
+most three findings; a fourth is still recorded, but left out of this fix, and the fix
+completes with what it has, its unclosed findings staying in the ledger. When completion is
+blocked because a P0 or P1 is still `open` or `fixed`, the run stops. A finding the run has
+already given up on is not queued again, and `auto.maxItems` caps completed fixes. Without
+these bounds the loop need not end: a review of a repair can always find something new.
+
 ## Step 3 - close the run
 
 Under `trunk` and `branch-per-item` there is nothing to close: the items are done and the

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

@@ -1,7 +1,7 @@
 ---
 name: fix
 summary: spec an unplanned bug or small change, or repair a recorded finding
-description: "Write a short spec for an unplanned bug or small change into religion/context/current-work.md so it runs through the same reviewed loop as planned work, then stop. Given a finding identifier instead, specs the repair of that recorded finding. Fixes are archived under religion/history/fixes/ and never touch the build plan. Use when the user runs $fix, reports a bug, asks to fix or change something that is not a planned item, or asks to pick up a finding from the ledger."
+description: "Write a short spec for an unplanned bug or small change into religion/context/current-work.md so it runs through the same reviewed loop as planned work, then stop. Given one or more finding identifiers instead, specs the repair of those recorded findings together. Fixes are archived under religion/history/fixes/ and never touch the build plan. Use when the user runs $fix, reports a bug, asks to fix or change something that is not a planned item, or asks to pick up a finding from the ledger."
 ---
 
 # fix - spec an unplanned change
@@ -14,7 +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.
-- **A finding identifier** - `$fix F-03` specs the repair of that ledger entry.
+- **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
+  and a severity, as $auto's fix mode does: one fix then stays one reviewable diff.
 
 - **Nothing** - read `religion/context/inbox.md` and offer what is there. Those notes were
   taken mid-build precisely because they were not worth stopping for at the time, and this is
@@ -31,8 +33,8 @@ would mean exploring, stop and point at $debug, which isolates a failure without
 changing anything. Writing a fix spec against a guessed cause produces a fix for the wrong
 problem.
 
-**For a finding**, read its entry in `religion/context/findings.md`: the file and line, why
-it matters, the suggested fix. The finding is the problem statement.
+**For findings**, read each entry in `religion/context/findings.md`: the file and line, why
+it matters, the suggested fix. The findings are the problem statement, one repair step each.
 
 If something is already in progress in `religion/context/current-work.md`, say so and ask
 whether to set it aside. One thing at a time is the point.
@@ -57,8 +59,8 @@ Fill in:
   test that fails without it. A bug that could recur silently is exactly what the test gate
   is for.
 
-For a finding repair, name the finding identifier in the Goal so the archive and the ledger
-agree about what happened.
+For a finding repair, name every finding identifier in the Goal so the archive and the
+ledger agree about what happened.
 
 ## Step 3 - stop
 

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

@@ -104,6 +104,10 @@ shape; the prose below it is for people.
     **Suggested fix:** ...
     **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.
@@ -122,9 +126,9 @@ After reviewing:
 - Append each new confirmed finding as `open`.
 - Record a lead worth tracking as `unverified`. It never gates anything.
 - Update entries this pass re-examined, noting the evidence in **Resolution**.
-- Move `fixed` to `closed` only when all three hold: this pass covered the finding's file,
+- Move `fixed` to `closed` only when all four hold: this pass covered the finding's file,
   re-examining the repaired code confirmed the defect is gone and nothing worse replaced
-  it, and the report names it as closed. An unrelated new problem in the same file gets its
+  it, no finding it surfaced is still `open` or `fixed`, and the report names it as closed. An unrelated new problem in the same file gets its
   own entry. Never close implicitly.
 - Set `accepted` only on the user's explicit decision, with their reason. Never on their
   behalf.

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. 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; `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
@@ -19,6 +19,7 @@ between steps.
   a bound.
 - `/auto 3` - the next three items, completing each.
 - `/auto resume` - continue an interrupted run from the file-backed state.
+- `/auto fix` - the findings ledger instead of the plan; see Fix mode.
 
 `auto.maxItems` caps successful completions. `auto.maxRepairAttempts` caps repeated
 attempts at the same finding. `auto.finalAudit` adds one review across everything the run
@@ -65,7 +66,8 @@ Before the first item:
   starts, naming the question, since a run that stops halfway through item four is worse
   than one that never began.
 - The working tree is clean, or the only dirt belongs to work being resumed.
-- The plan has unchecked items.
+- The plan has unchecked items, or in fix mode the ledger has `open` or `fixed` findings in
+  range.
 - 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
@@ -110,6 +112,45 @@ For every item, in plan order:
 
 An item counts against `auto.maxItems` once it has landed, not once it is built.
 
+## Fix mode
+
+`/auto fix` works through the findings ledger instead of the build plan, under the same
+grant, gates, landing and stop rules.
+
+- `/auto fix` or `/auto fix all` - every class, P0 first, until no `open` finding is
+  left or a bound is reached.
+- `/auto fix P0` through `/auto fix P3` - only that class.
+
+**The queue.** Read `religion/context/findings.md` afresh before each fix, because every fix
+and every review changes it. Take the classes in turn, most severe first. Within a class, the
+`open` findings that name the same file form one group, oldest first, and each group is one
+work item: specced by /fix with all of its identifiers, then implemented, gated,
+completed and landed exactly as Step 2 does for a plan item. A fix confined to one file and
+one class stays a diff someone can review; a fix that sweeps several is not.
+
+`unverified` findings are not repaired. Nothing has confirmed them, and repairing a guess
+produces a change nobody can check; report them instead. `fixed` findings in range are
+re-reviewed rather than repaired again, because the repair exists and only a review can
+close it.
+
+**Every repair is re-reviewed.** Repair is the whole point of this mode, so after
+implementation the repaired findings always go to /audit in a subagent with fresh
+context, whatever `qualityGates.audit` says. Only that review closes a finding.
+
+**Folding.** When that review raises a new finding in code the fix changed, the audit records
+it under its own identifier with a `**Surfaced by:**` line naming the finding whose repair
+exposed it, and it joins the current fix as another repair step, whatever its class. The
+finding that surfaced it cannot close while it is `open` or `fixed`. A defect a repair
+introduced belongs with that repair: left for a later fix, it loses the context that
+explains it.
+
+**Bounds.** `auto.maxRepairAttempts` caps the attempts at any one finding. A fix folds in at
+most three findings; a fourth is still recorded, but left out of this fix, and the fix
+completes with what it has, its unclosed findings staying in the ledger. When completion is
+blocked because a P0 or P1 is still `open` or `fixed`, the run stops. A finding the run has
+already given up on is not queued again, and `auto.maxItems` caps completed fixes. Without
+these bounds the loop need not end: a review of a repair can always find something new.
+
 ## Step 3 - close the run
 
 Under `trunk` and `branch-per-item` there is nothing to close: the items are done and the

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

@@ -1,7 +1,7 @@
 ---
 name: fix
 summary: spec an unplanned bug or small change, or repair a recorded finding
-description: "Write a short spec for an unplanned bug or small change into religion/context/current-work.md so it runs through the same reviewed loop as planned work, then stop. Given a finding identifier instead, specs the repair of that recorded finding. Fixes are archived under religion/history/fixes/ and never touch the build plan. Use when the user runs /fix, reports a bug, asks to fix or change something that is not a planned item, or asks to pick up a finding from the ledger."
+description: "Write a short spec for an unplanned bug or small change into religion/context/current-work.md so it runs through the same reviewed loop as planned work, then stop. Given one or more finding identifiers instead, specs the repair of those recorded findings together. Fixes are archived under religion/history/fixes/ and never touch the build plan. Use when the user runs /fix, reports a bug, asks to fix or change something that is not a planned item, or asks to pick up a finding from the ledger."
 ---
 
 # fix - spec an unplanned change
@@ -14,7 +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.
-- **A finding identifier** - `/fix F-03` specs the repair of that ledger entry.
+- **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
+  and a severity, as /auto's fix mode does: one fix then stays one reviewable diff.
 
 - **Nothing** - read `religion/context/inbox.md` and offer what is there. Those notes were
   taken mid-build precisely because they were not worth stopping for at the time, and this is
@@ -31,8 +33,8 @@ would mean exploring, stop and point at /debug, which isolates a failure without
 changing anything. Writing a fix spec against a guessed cause produces a fix for the wrong
 problem.
 
-**For a finding**, read its entry in `religion/context/findings.md`: the file and line, why
-it matters, the suggested fix. The finding is the problem statement.
+**For findings**, read each entry in `religion/context/findings.md`: the file and line, why
+it matters, the suggested fix. The findings are the problem statement, one repair step each.
 
 If something is already in progress in `religion/context/current-work.md`, say so and ask
 whether to set it aside. One thing at a time is the point.
@@ -57,8 +59,8 @@ Fill in:
   test that fails without it. A bug that could recur silently is exactly what the test gate
   is for.
 
-For a finding repair, name the finding identifier in the Goal so the archive and the ledger
-agree about what happened.
+For a finding repair, name every finding identifier in the Goal so the archive and the
+ledger agree about what happened.
 
 ## Step 3 - stop