geneseed 3.11.0 → 3.13.0

package/src/bricks/adr-challenge.md

@@ -0,0 +1,20 @@
+---
+name: adr-challenge
+description: Attack the ADR this iteration drafted; the user reviews the ADR that survives.
+effect: read
+agent: skeptic
+gate: human
+gateOn: pass
+outcomes: pass, fail
+---
+Read the ADR this iteration wrote as a skeptic reading it cold. Is a decision driver missing? Is
+a rejected option strawmanned? Is a consequence — cost, risk, the way back — left unstated? Does
+it contradict an accepted ADR in the same folder, or the code as it stands? A gate amendment in
+LOOP.md's notes for this ADR is a finding: report `fail` until the ADR answers it.
+
+Never edit any file — findings go back to `adr-draft`, which revises the ADR.
+
+Report `fail` only on findings that would change the decision or its consequences, never on
+wording or style: write each one to a file in the OS temp directory and report that file's path
+with the outcome. Report `pass` otherwise — the user then reviews the ADR before the loop
+continues: write its path and the decision in one line to a temp file and report that path.

package/src/bricks/adr-draft.md

@@ -0,0 +1,15 @@
+---
+name: adr-draft
+description: Write or revise one architecture decision record for the card's decision.
+effect: mutate
+agent: architect
+outcomes: pass
+---
+Write or revise the ADR file the card's write set names, in Nygard form: Status: Proposed,
+Context, Decision, Consequences — the costs as well as the gains — and at least two options
+considered, each with why it lost. Touch only that file; never change code.
+
+If LOOP.md's notes carry `adr-challenge` findings or a gate amendment for this ADR, answer each
+one: change the decision, or record it under Consequences.
+
+Report `pass` once the ADR is written.

package/src/bricks/apply.md

@@ -0,0 +1,17 @@
+---
+name: apply
+description: Implement the current card's intent, touching only its declared write set.
+effect: mutate
+agent: developer
+outcomes: pass
+---
+Implement the card's intent exactly, touching only the files in its `writeSet`. If the card
+carries an `amend`, that supersedes the original intent — follow the amendment, not the plan it
+replaced.
+
+Make no unrelated edits: no drive-by rename, no incidental cleanup, no touching a file the card
+did not declare. If the change genuinely needs a file outside the write set, stop and report that
+rather than widening scope unasked — the diff is scored against the declared set, not your
+judgement of what else looked wrong.
+
+Report `pass` once the change is made, with a short account of what changed and where.

package/src/bricks/baseline-green.md

@@ -0,0 +1,17 @@
+---
+name: baseline-green
+description: Confirm the suite and linter are green before the loop changes anything.
+effect: read
+agent: tester
+outcomes: pass, fail
+---
+Run this project's full test suite and its linter, unchanged — no fix, no skip, no retry with
+different flags. This is the loop's starting line, not a chance to tidy up first.
+
+Report `pass` only if every test and the linter both exit clean. Include the raw command output
+in your report either way, so a `fail` carries the actual failure rather than a summary of it.
+
+Report `fail` on the first red suite or linter run, and stop there: a loop that starts on a red
+baseline cannot tell its own changes apart from pre-existing breakage.
+
+Never edit, create or delete any file: this brick only reads.

package/src/bricks/bruno-test.md

@@ -0,0 +1,16 @@
+---
+name: bruno-test
+description: Write or update Bruno requests for the endpoints this iteration touched.
+effect: mutate
+skill: bruno-test-writer
+outcomes: pass, fail
+---
+Follow the bruno-test-writer skill for every endpoint this iteration's diff added or changed.
+Touch only the Bruno collection — new or updated `.bru` requests and their expectations — never
+the application code.
+
+Report `pass` once every touched endpoint has a request that exercises it and asserts on the
+response.
+
+Report `fail` if an endpoint cannot be exercised this way (missing auth fixture, no reachable
+instance, an endpoint the diff removed), naming which one and why.

package/src/bricks/characterize.md

@@ -0,0 +1,17 @@
+---
+name: characterize
+description: Pin what legacy code does today with characterization tests, touching tests only.
+effect: mutate
+agent: tester
+outcomes: pass, fail
+---
+For the card's change point (with no card, the code the requirement names), write tests that pin
+what the code DOES today, not what it should do: assert a value you expect to be wrong, run it,
+and copy the observed value in. Touch only test files — never production code.
+
+Pin odd behaviour as it is and name it in the test's title; do not fix it here. If LOOP.md's notes
+list surviving mutants for this card, add the assertions that kill them.
+
+Report `pass` once the new tests run green against the unchanged code.
+Report `fail` if the code cannot be put under test without breaking a dependency first — that is
+a refactor in its own right — naming the dependency.

package/src/bricks/ci-fix.md

@@ -0,0 +1,18 @@
+---
+name: ci-fix
+description: Fix the failing CI check named in the card.
+effect: mutate
+skill: ci-fix
+outcomes: pass, fail
+---
+Follow the ci-fix skill against the failing check the card names — read its actual log, not a
+guess from the check's title, before changing anything.
+
+Touch only what that failure requires; this is a repair, not a chance to improve the pipeline
+along the way.
+
+Report `pass` once the named check is fixed and green LOCALLY — CI itself is re-read after the
+push, not here.
+
+Report `fail` if the check cannot be fixed from this repo alone (an infra outage, a flake with no
+reproducible cause, a required secret that is missing), naming why.

package/src/bricks/ci-triage.md

@@ -0,0 +1,20 @@
+---
+name: ci-triage
+description: Read the failing CI checks for this commit and pick one code failure to fix, or stop.
+effect: read
+agent: explorer
+outcomes: more, done
+---
+Key on the commit, not the branch: `gh run list --commit <HEAD sha> --json databaseId,status,conclusion`.
+A commit pushed moments ago may not have a run yet — poll that command for up to ~2 minutes
+before concluding none exists. Wait on a pending run with `gh run watch <id>`, then read
+`gh run view <id> --log-failed` — never guess from a check's title. Classify each failure as
+code, flaky or infra. Never edit any file. `ci-repair` needs CI to run on `loop/*` branches: if
+still no run after that poll, write "CI does not run for <sha>" to a file in the OS temp
+directory and report `done` with that file's path — never as green.
+
+Write the classification, one failure per line, to a file in the OS temp directory and report
+that file's path with the outcome. Report `more` with a card for ONE code failure:
+{"intent": "<fix check X: cause>", "writeSet": ["<files the fix touches>"],
+ "actions": ["<each of: format, imports, rename, logic, new-file, api, delete, architecture>"]}
+Report `done` when CI is green for HEAD, or only flaky or infra failures remain — naming them.

package/src/bricks/compat-check.md

@@ -0,0 +1,16 @@
+---
+name: compat-check
+description: Confirm consumers of the old and the new interface both still work after this iteration.
+effect: read
+agent: tester
+outcomes: pass, fail
+---
+Run the tests of every consumer this change can reach — those still on the old shape as well as
+those already moved — and, where the repo records consumer contracts (Pact, Spring Cloud
+Contract), the provider verification against them. In a contract step, where the old shape is
+removed on purpose, check instead that no consumer still uses it. Never edit any file: send
+reports to the OS temp directory.
+
+Report `pass` if every consumer works. Report `fail` naming the broken consumer, the check and
+its raw failure, written to a file in the OS temp directory — report that file's path with the
+outcome.

package/src/bricks/deps-audit.md

@@ -0,0 +1,14 @@
+---
+name: deps-audit
+description: Audit this iteration's dependency changes for known vulnerabilities.
+effect: read
+skill: deps-audit
+outcomes: pass, fail
+---
+Follow the deps-audit skill against the dependency manifest this iteration's diff touched (or the
+whole manifest, if nothing else scopes it). Never edit any file; this brick only observes.
+
+Report `pass` if the audit finds nothing at high severity or above.
+
+Report `fail` on any finding at high severity or above, naming the package, the version, the
+advisory, and the fix the skill recommends (upgrade, pin, or removal).

package/src/bricks/docs-update.md

@@ -0,0 +1,15 @@
+---
+name: docs-update
+description: Update the documentation this iteration's diff made stale.
+effect: mutate
+agent: docs
+outcomes: pass
+---
+Read this iteration's diff and find every doc it made stale: a changed signature, a renamed
+flag, a moved file, a behaviour the README or docs still describe the old way.
+
+Update only those docs, only to match what the diff actually changed. Do not rewrite unrelated
+prose, reorganize a page, or fix an unrelated staleness you happen to notice while in there.
+
+Report `pass` once every doc the diff touched is back in sync, naming the files you changed — or
+that none needed it, if the diff left nothing stale.

package/src/bricks/done-check.md

@@ -0,0 +1,16 @@
+---
+name: done-check
+description: Verify the requirement is met — every acceptance criterion proven by a passing test or a stated manual check.
+effect: read
+agent: reviewer
+outcomes: pass, fail
+---
+Read the requirement's acceptance criteria — `specs/<slug>/spec.md` when the branch has one, else
+the requirement in LOOP.md — and the branch's full diff against its base. Run the suite. For
+every criterion, name the test that proves it, or the manual check (what to do, what to see) when
+no test can. Never edit any file. Judge only the stated criteria — never style or extras.
+
+Report `pass` only if every criterion maps to a passing test or a stated manual check.
+Report `fail` otherwise: write each unmet criterion, one per line, with what is missing (no test,
+a failing test, a half-built behaviour) to a file in the OS temp directory and report that file's
+path — the next iteration's `identify` builds from it.

package/src/bricks/fitness-define.md

@@ -0,0 +1,22 @@
+---
+name: fitness-define
+description: Encode the requirement's architecture rule as a test, with an allowlist of today's violations.
+effect: mutate
+agent: architect
+gate: human
+outcomes: pass, fail
+---
+Turn the requirement's architecture rule into an executable test in the suite, with the repo's
+own tools first: ArchUnit for Java (a `FreezingArchRule`, whose violation store is the
+allowlist), then dependency-cruiser, import-linter, eslint-plugin-boundaries or size-limit.
+Record today's violations in an allowlist beside the test so the suite stays green — each later
+iteration removes one entry. Touch only the test, its allowlist and the tool's test-scoped setup,
+and declare the tool's generated store as a glob in the write set (`--write-set '**/archunit_store/**'`
+— single-quote it, the same as any glob in `--write-set`).
+
+The user reviews the rule before the loop continues: write the rule in one sentence, the test's
+path, the allowlist's path and its entry count to a file in the OS temp directory and report that
+file's path with the outcome.
+
+Report `pass` once the test runs green with the allowlist in place. Report `fail` if the rule
+cannot be checked deterministically, with the note file naming what is ambiguous.

package/src/bricks/flake-check.md

@@ -0,0 +1,17 @@
+---
+name: flake-check
+description: Rerun the card's test until it proves stable — a retry or a sleep is not a fix.
+effect: read
+agent: tester
+outcomes: stable, flaky
+---
+Rerun the card's test 20 times alone, then 20 with its suite, as `flake-repro` did (Maven: a
+loop of `mvn test -Dtest=<Class>#<method>`, shuffled). Never edit any file.
+
+Read this iteration's diff first. Polling on the awaited condition (Awaitility
+`await().atMost(…).until(…)`, `waitFor`) in place of a fixed sleep is a fix; adding a sleep or
+raising an existing timeout is not, and neither is a retry (`rerunFailingTestsCount`,
+`@RetryingTest`, `jest.retryTimes`) — report `flaky` naming it, whatever the runs say.
+
+Report `stable` only on 0 failures in all runs. Report `flaky` otherwise, with the failure count
+and one failure's output in a file in the OS temp directory — report that file's path.

package/src/bricks/flake-repro.md

@@ -0,0 +1,18 @@
+---
+name: flake-repro
+description: Confirm which suspected tests are flaky by repeated runs, before anything is fixed.
+effect: read
+agent: tester
+outcomes: flaky, stable, broken
+---
+Run each suspected test the requirement names 20 times (or the N it gives) alone, then 20 with
+its suite in a shuffled order — no code change, no retry option. Maven: loop `mvn test
+-Dtest=<Class>#<method>` (multi-module: add `-pl <module> -Dsurefire.failIfNoSpecifiedTests=false`),
+shuffled with `-Dsurefire.runOrder=random` and, under JUnit 5,
+`-Djunit.jupiter.testmethod.order.default=org.junit.jupiter.api.MethodOrderer$Random`. Never
+`-Dsurefire.rerunFailingTestsCount`: it hides the failures you count. Never edit any file. Write
+each test as `<test>: <failures>/<runs>` with one failure's output to a file in the OS temp
+directory and report that file's path.
+
+Report `broken` if any test fails every run — a bug for `bugfix`, not a flake. Report `flaky` if a
+test failed some runs, listing the confirmed ones. Report `stable` if none failed.

package/src/bricks/identify.md

@@ -0,0 +1,23 @@
+---
+name: identify
+description: Choose the next iteration of the loop, or declare the requirement done.
+effect: read
+agent: explorer
+outcomes: more, done
+---
+Read the requirement and the loop's history (LOOP.md, `git log --format=%(trailers)` on this
+branch). If the requirement is fully met and the suite is green, report `done`.
+
+Otherwise pick the SMALLEST next change that moves the requirement forward and can be tested on
+its own — when the branch has `specs/*/spec.md`, its next unfinished task. If the latest note is
+`done-check`'s unmet criteria, report `more` with a card for one of them, never `done`. Report
+`more` with a card, as JSON:
+{"intent": "<one line>", "writeSet": ["<every file ANY brick this iteration writes, tests/docs too>"],
+ "actions": ["<each of: format, imports, rename, logic, new-file, api, delete, architecture>"]}
+
+Declare every action honestly: the diff is scored again before commit, and anything outside the
+write set or under-declared escalates to a blocking stop. If LOOP.md's notes say the previous
+attempt was re-split, make this card strictly smaller than that one. The card obeys every
+instruction in the template's `rules` (e.g. its intent cites the proof that code is unused).
+
+Never edit, create or delete any file: this brick only reads.

package/src/bricks/lint.md

@@ -0,0 +1,14 @@
+---
+name: lint
+description: Run the project's linter alone, without the test suite.
+effect: read
+agent: tester
+outcomes: pass, fail
+---
+Run this project's linter only — not the test suite, which is `test`'s job. Never edit any file;
+this brick only observes.
+
+Report `pass` if the linter exits clean.
+
+Report `fail` otherwise, with the raw linter output (every violation, not a count or a summary)
+so the next `apply` can act on the actual finding.

package/src/bricks/migration-plan.md

@@ -0,0 +1,21 @@
+---
+name: migration-plan
+description: Plan a breaking interface change as expand, migrate each consumer, contract — for the user to review.
+effect: read
+skill: migrate
+gate: human
+outcomes: pass, fail
+---
+Following the migrate skill, plan the change as ordered steps: expand (add the new shape beside
+the old), migrate (one consumer or call-site group per step), contract (remove the old shape).
+Every step must leave the system deployable and fit one `identify` card. Name the contract files
+the expand and contract steps touch — API specs, schema migrations, event schemas. Never edit any
+file.
+
+The user reviews the plan before the loop continues: write the steps, one per line, then the
+contract files, to a file in the OS temp directory and report that file's path with the outcome.
+Those files belong in LOOP.md's `contracts`, so the expand and contract steps stop for a human:
+the user adds any the template's defaults miss to LOOP.md's `contracts` before answering ok.
+
+Report `pass` with the plan. Report `fail` if no backward-compatible path exists, naming what
+forces the break.

package/src/bricks/mutation-check.md

@@ -0,0 +1,18 @@
+---
+name: mutation-check
+description: Prove the new tests bite, by mutation testing scoped to the code the card names.
+effect: read
+agent: tester
+outcomes: pass, fail, unavailable
+---
+Run the project's mutation tool scoped to the production code the card's intent names. Java: PIT
+first — `mvn test-compile org.pitest:pitest-maven:mutationCoverage -DtargetClasses=<fq.Class*>
+-DreportsDirectory=<OS temp dir> -DtimestampedReports=false`, or Gradle's `pitest` task; else
+Stryker, mutmut or cargo-mutants. Never edit any file — reports and caches (.mutmut-cache,
+mutants.out/, .stryker-tmp/) go to the OS temp dir, or are removed.
+
+Report `pass` if no surviving mutant sits on a line the new tests target. Report `fail` with each
+survivor as `file:line`, the mutation, and the assertion that would kill it, in a file in the OS
+temp directory — report its path. Report `unavailable` when no tool is configured — the pom lacks
+`pitest-junit5-plugin` under JUnit 5, or Gradle does not apply `info.solidsoft.pitest`: never add
+it to the build; write what you checked to a temp file and report its path.

package/src/bricks/plan.md

@@ -0,0 +1,17 @@
+---
+name: plan
+description: Split the requirement into an ordered list of iterations before any code changes.
+effect: read
+agent: architect
+outcomes: pass
+---
+Read the requirement and survey the code it touches. Split the work into an ordered list of
+small iterations, each one sized to a single `identify` card — one testable change apiece.
+
+Do not edit any code; this brick only plans it. `plan` is not an iteration head, so its card is
+never recorded — write the ordered list, one iteration per line, to a file in the OS temp
+directory (never inside the worktree) and report that file's path with the outcome, so it is
+recorded into LOOP.md's notes. Report `pass`.
+
+If the requirement cannot be split — it is already one atomic change — say so in the note file
+and let the loop proceed with a single iteration.

package/src/bricks/red-test.md

@@ -0,0 +1,16 @@
+---
+name: red-test
+description: Write the failing test for the card's intent before any production code changes.
+effect: mutate
+agent: tester
+outcomes: red, green, untestable
+---
+Write the smallest test that expresses the card's intent at its seam, touching only the test
+files in the card's `writeSet` — never production code; making it pass is `apply`'s job. Run it.
+
+Report `red` if it fails FOR THE REASON the intent states — not an import error, a typo, or a
+broken fixture in the test itself.
+Report `green` if it already passes: the behaviour exists, so keep the test as coverage.
+Report `untestable` if no seam lets a test reach the behaviour without changing production code
+first, naming what blocks it. If the card's `writeSet` names no test file, report `untestable`
+and say so.

package/src/bricks/reproduce.md

@@ -0,0 +1,16 @@
+---
+name: reproduce
+description: Write the smallest test that reproduces the bug and watch it fail.
+effect: mutate
+agent: tester
+outcomes: pass, fail
+---
+Write the smallest possible test that demonstrates the bug the requirement describes. Run it and
+confirm it fails, and that it fails FOR THE STATED REASON — not for an unrelated error.
+
+Touch only the new test file; do not change any production code here, and do not try to make the
+test pass. A reproduction that already passes proves nothing.
+
+Report `pass` once a failing reproduction exists, with the test's path and the failure it shows.
+Report `fail` if the bug cannot be reproduced from the requirement as written — say what you
+tried and why each attempt did not fail the way the requirement claims.

package/src/bricks/review.md

@@ -0,0 +1,19 @@
+---
+name: review
+description: Review this iteration's diff against the card it was supposed to implement.
+effect: read
+agent: reviewer
+outcomes: pass, fail
+---
+Read the card's intent and write set, then read the diff this iteration actually produced. Check
+that the diff matches the intent, stays inside the declared write set, does not smuggle in an
+unrelated change, and keeps any rule in `rules` (e.g. a cited proof that code is unused).
+
+Never edit any file — findings go back to `apply`, which makes the fix.
+
+Report `pass` if the diff is a faithful, scoped implementation of the card.
+
+Report `fail` with concrete findings — `file:line`, what is wrong, what to do instead — if the
+diff drifts from the intent, touches an undeclared file, breaks a rule, or leaves an obvious defect behind.
+The outcome alone does not carry the findings to `apply` — write them to a file in the OS temp
+directory (never inside the worktree) and report that file's path with the outcome.

package/src/bricks/security-scan.md

@@ -0,0 +1,17 @@
+---
+name: security-scan
+description: Security review of this iteration's diff.
+effect: read
+agent: security
+outcomes: pass, fail
+---
+Read this iteration's diff and review it for security issues: injected input reaching a
+dangerous sink, a widened trust boundary, a secret written to disk or logs, a weakened auth or
+permission check — anything that would not survive a real security review.
+
+Never edit any file; this brick only observes and reports.
+
+Report `pass` if nothing in the diff raises a security concern.
+
+Report `fail` with each finding as `file:line`, the concrete risk, and the fix — severe enough to
+block the iteration, not a style nit that belongs in `review` instead.

package/src/bricks/spec.md

@@ -0,0 +1,18 @@
+---
+name: spec
+description: Write the feature's spec — scope, EARS acceptance criteria, ordered tasks — for the user to review.
+effect: mutate
+agent: architect
+gate: human
+outcomes: pass, fail
+---
+Write `specs/<slug>/spec.md` (the slug of the loop's title) and touch nothing else — no code: the
+problem, what is out of scope, acceptance criteria in EARS form ("WHEN <trigger> THE SYSTEM SHALL
+<response>"), each one testable, and an ordered task list sized to one `identify` card apiece,
+ending with an end-to-end verification task. A gate amendment in LOOP.md's notes answers your
+open questions or corrects the spec: revise the spec to follow it.
+
+The user reviews the spec before the loop continues. Report `pass` once every criterion is
+testable, with the spec's path and its criteria count in a file in the OS temp directory — report
+that file's path. Report `fail` if a criterion cannot be stated testably: list the open questions
+in such a file and report its path; the user answers them with an amend.

package/src/bricks/test.md

@@ -0,0 +1,14 @@
+---
+name: test
+description: Run the suite and linter over this iteration's change.
+effect: read
+agent: tester
+outcomes: pass, fail
+---
+Run this project's full test suite and its linter over the current change. Never edit any file —
+this brick only observes; a fix belongs in `apply`, not here.
+
+Report `pass` only if both exit clean.
+
+Report `fail` otherwise, with the raw failures (not a paraphrase) so `apply` can act on the actual
+error rather than your summary of it. Name every failing test and lint violation you saw.

package/src/bricks/upgrade-scout.md

@@ -0,0 +1,16 @@
+---
+name: upgrade-scout
+description: Pick the next dependency upgrade and read its breaking changes, or declare all done.
+effect: read
+agent: researcher
+outcomes: more, done
+---
+Read the requirement and the loop's history (LOOP.md, `git log --format=%(trailers)` on this
+branch). Pick the next package or group the requirement names that is not yet upgraded, skipping
+any release younger than 14 days, and read its changelog or migration guide. Never edit any file.
+
+Report `done` when every named package is upgraded. Otherwise report `more` with a card:
+{"intent": "<bump X to N and adapt>", "writeSet": ["<manifest, lockfile, every file to adapt>"],
+ "actions": ["<each of: format, imports, rename, logic, new-file, api, delete, architecture>"]}
+Write the breaking changes that hit this repo to a file in the OS temp directory and report that
+file's path with the outcome — the card alone does not carry them to `apply`.

package/src/doctrines/process.md

@@ -85,7 +85,9 @@ time — a personal feature branch included. A one-time approval is not standing
 consent. Consent may cover a **named batch**: "commit as you go on this branch"
 stands for commits on that branch until the session ends or the scope changes; a
 new session, a new branch, or a widened scope re-asks. Push earns no such default
-and stays per-ask unless granted in the same named form. Before each, present in
+and stays per-ask unless granted in the same named form. A launched loop's batch
+covers commit and push on its own `loop/*` branch; merging that branch into a
+shared one never is. Before each, present in
 order (1) a plain-language summary of what changed and why and (2) the exact
 commit message you intend to use, then wait. Never push on your own initiative.
 On a **shared branch** — `main`, `master`, `develop`, `development`, a
@@ -97,13 +99,14 @@ through the git-rescue {{SKILL}} behind a backup. The host gates commit and push
 the tool boundary too, so this consent cannot be lost to a sticky allowlist.
 <!-- LEAN:else -->
 Recording and sharing code is consented, never unilateral: **every** `git commit` and
-`git push` needs the user's **explicit acceptance**, on every branch, every time; a
-one-time approval is not standing consent. A named batch ("commit as you go") stands until
-the session ends or scope changes; push earns no default. Before each, present the plain
-summary of what changed and why, the exact commit message, then wait. Shared branches —
-`main`, `master`, `develop`, `development`, `release`/`hotfix`, any you are unsure of —
-take the same gate. Never force-push, hard-reset, or rebase one: undo with a revert commit
-(git-rescue {{SKILL}} for a legitimate rewrite). The host gates both at the tool boundary.
+`git push` needs **explicit acceptance**, every branch, every time; one-time approval is
+not standing consent. A named batch ("commit as you go") stands until the session ends or
+scope changes; push earns no default. A launched loop's batch covers commit and push on
+its own `loop/*` branch only; merging it never. Show the plain summary and the exact
+commit message before each, then wait. Shared branches — `main`, `master`, `develop`,
+`development`, `release`/`hotfix`, any unsure — take the same gate. Never force-push,
+hard-reset, or rebase one: undo with a revert commit (git-rescue {{SKILL}} for a
+legitimate rewrite). The host gates both at the tool boundary.
 <!-- LEAN:end -->
 
 ### {{DOCTRINE:bound-the-loop}} Bound the Loop

package/src/loops/api-endpoint.json

@@ -0,0 +1,31 @@
+{
+  "name": "api-endpoint",
+  "description": "Build an HTTP API feature (a Spring MVC controller, say) one endpoint change per iteration: plan, apply, test, write or update the endpoint's Bruno request, run a security review, and review.",
+  "category": "development",
+  "rules": [
+    "The card's write set names the endpoint's .bru requests too, not only the code.",
+    "An OpenAPI or Swagger spec edit stops for a human by design; the aggressive preset or trimming LOOP.md's contracts relaxes it."
+  ],
+  "nodes": ["plan", "identify", "apply", "test", "bruno-test", "security-scan", "review"],
+  "start": "plan",
+  "edges": [
+    { "from": "plan", "on": "pass", "to": "identify" },
+    { "from": "identify", "on": "more", "to": "apply" },
+    { "from": "identify", "on": "done", "to": "$close" },
+    { "from": "apply", "on": "pass", "to": "test" },
+    { "from": "test", "on": "pass", "to": "bruno-test" },
+    { "from": "test", "on": "fail", "to": "apply" },
+    { "from": "bruno-test", "on": "pass", "to": "security-scan" },
+    { "from": "bruno-test", "on": "fail", "to": "$stop" },
+    { "from": "security-scan", "on": "pass", "to": "review" },
+    { "from": "security-scan", "on": "fail", "to": "apply" },
+    { "from": "review", "on": "pass", "to": "identify" },
+    { "from": "review", "on": "fail", "to": "apply" }
+  ],
+  "loops": [
+    { "name": "iterations", "nodes": ["identify", "apply", "test", "bruno-test", "security-scan", "review"], "max": 20, "iteration": true },
+    { "name": "apply-test", "nodes": ["apply", "test"], "max": 5 },
+    { "name": "review-fix", "nodes": ["apply", "test", "bruno-test", "security-scan", "review"], "max": 3 }
+  ],
+  "contracts": ["**/openapi*.yaml", "**/openapi*.yml", "**/openapi*.json", "**/swagger*.yaml", "**/swagger*.yml", "**/swagger*.json"]
+}

package/src/loops/architecture-decision.json

@@ -0,0 +1,22 @@
+{
+  "name": "architecture-decision",
+  "description": "Record one architecture decision record per decision the requirement names: draft it, have a skeptic attack it, and let the user review the ADR that survives, until every decision is recorded as Proposed.",
+  "category": "architecture",
+  "rules": [
+    "Pick the next undocumented decision; the card's write set is its ADR file."
+  ],
+  "nodes": ["identify", "adr-draft", "adr-challenge"],
+  "start": "identify",
+  "edges": [
+    { "from": "identify", "on": "more", "to": "adr-draft" },
+    { "from": "identify", "on": "done", "to": "$close" },
+    { "from": "adr-draft", "on": "pass", "to": "adr-challenge" },
+    { "from": "adr-challenge", "on": "pass", "to": "identify" },
+    { "from": "adr-challenge", "on": "fail", "to": "adr-draft" }
+  ],
+  "loops": [
+    { "name": "iterations", "nodes": ["identify", "adr-draft", "adr-challenge"], "max": 8, "iteration": true },
+    { "name": "challenge-fix", "nodes": ["adr-draft", "adr-challenge"], "max": 3 }
+  ],
+  "weights": { "new-file": 0.2, "architecture": 0.2 }
+}

package/src/loops/bugfix.json

@@ -0,0 +1,23 @@
+{
+  "name": "bugfix",
+  "description": "Reproduce the bug with a failing test, then iterate: apply the fix, test, and review, until the requirement is met and the reproduction passes.",
+  "category": "development",
+  "nodes": ["reproduce", "identify", "apply", "test", "review"],
+  "start": "reproduce",
+  "edges": [
+    { "from": "reproduce", "on": "pass", "to": "identify" },
+    { "from": "reproduce", "on": "fail", "to": "$stop" },
+    { "from": "identify", "on": "more", "to": "apply" },
+    { "from": "identify", "on": "done", "to": "$close" },
+    { "from": "apply", "on": "pass", "to": "test" },
+    { "from": "test", "on": "fail", "to": "apply" },
+    { "from": "test", "on": "pass", "to": "review" },
+    { "from": "review", "on": "pass", "to": "identify" },
+    { "from": "review", "on": "fail", "to": "apply" }
+  ],
+  "loops": [
+    { "name": "iterations", "nodes": ["identify", "apply", "test", "review"], "max": 20, "iteration": true },
+    { "name": "apply-test", "nodes": ["apply", "test"], "max": 5 },
+    { "name": "review-fix", "nodes": ["apply", "test", "review"], "max": 3 }
+  ]
+}