🤖 Spire 0.2.2: drop superpowers default, build settings, pinned role agents

- Superpowers is no longer part of the cycle; it survives only in
  implementation/references/superpowers.md (older models, override table).
- implementation: plan altitude, staleness check in the attack, phase
  review records unplanned work (never auto-reverts).
- Igor: orienting is not deciding, light grilling trial in brainstorm,
  research briefs ask for findings, journal times from `date`.
- project/init: `## Build` settings section, gitignored project.local.md
  override.
- New pinned agents planner, attacker, reviewer (Opus 5.5).
- .codex/config.toml mirrors .claude/settings.json (spire + gitea).

plugins/spire/skills/implementation/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: implementation
-description: Drive implementation lean — test the plan against the code before building, build in large blocks with a cheap gate between them, run tests and one review per phase, fix once, stop. Use whenever the user asks to "implement", "build", "ship", "fix this bug", or hands you a plan / spec / ticket to execute, especially for multi-step or multi-file changes and hard bugs. Harness mechanics and model notes live in references/. Composes with `workpad`; superpowers skills are optional tools.
+description: Drive implementation lean — test the plan against the code before building, build in large blocks with a cheap gate between them, run tests and one review per phase, fix once, stop. Use whenever the user asks to "implement", "build", "ship", "fix this bug", or hands you a plan / spec / ticket to execute, especially for multi-step or multi-file changes and hard bugs. Harness mechanics and model notes live in references/. Composes with `workpad`.
 ---
 
 # Implementation
@@ -25,11 +25,13 @@ Separate the roles: the planner, the attacker, the builder and the reviewer are
 
 After the plan is written, a fresh agent that did not write it **tests it adversarially against the code**: blockers, design errors, wrong root causes, and consumers of changed semantics the plan missed (other readers, stats, migrations, callers in other crates). In the same pass it **reshapes** the plan: phases that each end in a testable state, blocks that one owner can finish, scope cut back to the goal, decisions the user must make listed. It writes a new build plan; the original stays as written.
 
+A plan written before earlier phases landed may be stale. The attack checks it against the code as it is now; it reads the previous phase's run log and review only when something is off.
+
 This step is what pays for dropping per-task review. A plan checked against the code catches in minutes what many small reviews would find one by one, or not at all. Without it, lean is just less review.
 
 The build plan sets defaults: block size, owner model per block, the gate per block, what may stay broken between blocks. It may place an extra review at a hotspot if it says why. Its risk list shapes the build. It is not the phase reviewer's scope: a reviewer handed a checklist tends to confirm the checklist.
 
-Plan-writing tools are swappable (superpowers `writing-plans` today; others later). The attack is the same whichever wrote the plan.
+A plan holds decisions, contracts, invariants and the scope fence. Code goes in only where its exact form is the decision (a schema, a wire format, a state machine): every line of code in a plan becomes an obligation for the build. Whatever tool wrote the plan, the attack is the same.
 
 ## Building a phase
 
@@ -50,6 +52,7 @@ One option is **trunk and forks**. At intake the builder reads the build plan an
 
 - A **fresh** reviewer that did not build the phase, dispatched outside the build, stamps its model id in its report header. A review without a stamped id does not count.
 - It is adversarial: it runs the gates, traces concrete scenarios, and **answers every deviation and flag in the handoff notes**, one by one. It looks specifically for **weakened checks** (loosened assertions, downgraded errors) and **tests that cannot fail**.
+- It lists **what was built that the plan did not ask for**. On record only, never an automatic revert: an unplanned addition may be a good one.
 - **One fix pass** over all findings. Minors are fixed in that pass or logged as follow-ups.
 - **Re-check only Critical and Important**, by a fresh reviewer scoped to those findings. Then stop. A Critical or Important that survives the re-check goes to the user or into a new plan, not into the next phase.
 - Extra reviews (for example a mid-phase review of a hotspot block whose note flags a deviation) are a choice with a stated reason, not a default.
@@ -76,10 +79,10 @@ Use the `workpad` skill for placement.
 
 ## Project settings
 
-Read these from `spire:project`; a brief overrides both the config and this skill: worktrees or one checkout, branch ownership, staging (explicit paths), gate and test commands, owner-model defaults per block kind, standing brief constraints for sensitive areas, host rules (temp dirs, memory caps).
+Read these from `spire:project` (its `## Build` section; `project.local.md` wins over `project.md`). Unset means the default in this skill; `none` means deliberately absent. A brief overrides both the config and this skill: worktrees or one checkout, branch ownership, staging (explicit paths), gate and test commands, owner-model defaults per block kind, standing brief constraints for sensitive areas, host rules (temp dirs, memory caps).
 
 ## Composition
 
 - **`workpad`** decides where documents go. **`research-tree`** comes first when how to build is itself an open question.
-- **Superpowers** is a toolbox: `writing-plans`, `test-driven-development`, `systematic-debugging`, `verification-before-completion`, `dispatching-parallel-agents` and others are fine to use. Where one prescribes a per-task review loop or other ceremony, the lean rules here take precedence. `subagent-driven-development` is not the default loop; use it only when a plan asks for per-task review.
+- **Superpowers** is not part of this cycle. When to use it anyway (e.g. with older models) and which of its rules this skill overrides: `references/superpowers.md`.
 - This skill does not govern code style, test frameworks, CI or plan formats.

plugins/spire/skills/implementation/references/superpowers.md

@@ -0,0 +1,36 @@
+# Superpowers with Spire
+
+Superpowers (obra/superpowers) is not part of Spire's cycle. This page is for when you use it anyway: an older model that needs more rails (Opus 4.6 and earlier), or a brief or user that asks for one of its skills.
+
+Dated observations, 2026-10-15, upstream v7.0.0. Sources: the workpad research of that date on superpowers alternatives, Spire coupling and plan anatomy.
+
+## Why it is not the default
+
+On Opus 5.5 its ceremony costs more than it catches: review and fix grew to about two thirds of the work, and scope grew past the plan. The causes are structural, not tuning:
+
+- One fresh implementer plus a review per task (`subagent-driven-development`): 2 to 12 dispatches per task, plus a fix loop of up to 5 rounds.
+- Plans written for an implementer with "zero context and questionable taste": small steps, code in the plan. Every planned line becomes an obligation a reviewer enforces.
+- Reviewer rules that widen scope: "a spec's silence is not permission", a YAGNI argument never downgrades a finding, and the plan's Review Focus adds tests by design.
+- The SessionStart hook ("if there is even a 1% chance a skill applies, you must invoke it") turns optional skills into automatic ones in every main session.
+
+## What the lean cycle overrides
+
+| Superpowers | Spire |
+|---|---|
+| Review after every task, re-review after every fix | One fresh review per phase, one fix pass, re-check only Critical/Important |
+| Plan with bite-sized steps and full code | Plan at the altitude of decisions, contracts, invariants, scope fence |
+| Execution handoff: the user picks subagent-driven or inline | The attack reshapes the plan into a build plan; the user sees it once |
+| Brainstorming HARD-GATE: user approves spec, plan and execution method | Brainstorm is optional; decisions belong before the run |
+| Reviewer treats anything the spec did not mention as a finding | Unplanned work is recorded, never reverted automatically |
+| TDD iron law for every change | Fail-first test for bugs you do not yet understand; tests once per phase |
+| Files under `docs/superpowers/` | The workpad decides placement |
+
+## Still useful as tools
+
+- `systematic-debugging` for a stubborn failure.
+- `test-driven-development` for a fail-first test inside a block.
+- `verification-before-completion`: evidence before claiming a gate or test passed.
+- On older models, `writing-plans` for the planner, then the attack as usual. Upstream v6.4.2 already dropped full code and 2–5-minute steps from plans; prefer a current version.
+- If you do run superpowers' own execution, upstream's Native mode (v6.4.1: one final review) is the cheaper path, not `subagent-driven-development`.
+
+Forks that keep the per-task loop as the default (e.g. pcvelz `superpowers-extended-cc`) add ceremony rather than remove it.