@nklisch/pi-agile-workflow 0.15.3 → 0.16.3

package/skills/principles/references/advisory-review.md

@@ -0,0 +1,76 @@
+# Advisory Review Mechanics
+
+The detailed companion to the risk-driven invariants in
+`principles/SKILL.md` Part IV. Model classes, host-to-peer pairing, and concrete
+peer mechanism flags remain in [models.md](models.md).
+
+## Review weight and scope defaults
+
+Start from the effective `review_weight` in Part IV (`standard` when unset), then
+adapt to risk. `light` narrows independent breadth, `thorough` raises
+fresh-context scrutiny, and `maximum` permits multi-class multi-pass depth;
+`none` skips this independent-review table without skipping implementation
+verification or acceptance evidence. These are ceilings and intent, never fixed
+reviewer or pass counts.
+
+Apply the scope defaults below in both direct and autopilot design modes.
+Explicit caller and project review rules override them.
+
+| Scope and risk | Default |
+|---|---|
+| Small, low-risk | Skip advisory review. |
+| Small or medium with material uncertainty | Optionally run one focused different-class pass. |
+| Large, risky, or architectural, without prior `--only-questions` / `## Design decisions` alignment | Run one focused different-class pass when available. |
+| Deep or complex | Use two different model classes across the two phases when available. |
+| Completed feature or epic in a deep review lane | Use a fresh-context lens review; prefer different-class, otherwise strongest same-harness fresh context. |
+| Final autopilot completion | Run the required fresh-context completion path described in Part IV. |
+
+Stories normally fast-advance on recorded green verification, but risk can
+escalate them. Use a full iterative review loop for a completed substantial
+artifact or explicit review request only when that depth is warranted.
+
+## Two-phase mechanics
+
+Always run completeness before attack:
+
+1. **Completeness / complementary / advisory.** Ask what is missing, which
+   alternatives strengthen the artifact, and which questions or risks deserve
+   weight. An open design gets one pass before decisions lock. A complete
+   artifact can iterate until substantive findings stabilize; when a dedicated
+   iterative mechanism exists, converge to nits and cap the loop at roughly five
+   passes rather than chasing perfection.
+2. **Adversarial.** After Phase 1, ask what is broken, contradictory, based on a
+   false assumption, or likely to fail in operation. Open designs get a focused
+   attack pass; completed artifacts may use the same bounded convergence shape.
+   Verify concrete claims before accepting them.
+
+The receiving/orchestrating agent owns the verdict on every returned finding.
+Apply Part IV's material-risk threshold in repository context; do not inherit a
+reviewer's severity label. Fix or activate only current-cycle blockers, park
+valid lower-priority concerns in the unbound backlog, and reject unsupported
+claims with a reason.
+
+For deep or complex work, use a different model class for Phase 2 than Phase 1
+when two classes are available. Their disagreement is evidence to investigate,
+not a vote. For routine design, do not turn a focused advisory pass into a
+multi-pass review loop.
+
+## Recording the result
+
+Summarize evidence and decisions in the item body; never paste transcripts:
+
+```markdown
+## Other agent review
+- Invoked because: <risk or uncertainty>
+- Phase 1 — advisory/completeness: <reviewer class and useful gaps>
+- Phase 2 — adversarial: <reviewer class and failure modes>
+- Fixed/active blockers: <material current-cycle risks and disposition>
+- Parked: <valid lower-priority concerns and risk rationale>
+- Rejected: <points and reasons with phase>
+- Skipped/degraded: <phase and reason, if any>
+```
+
+If only one phase or class was warranted or reachable, record that fact. Limit
+normal design to one advisory pass per item per design stage. The final
+autopilot completion review is separate and follows the stricter completion
+invariant in Part IV.

package/skills/principles/references/code-design.md

@@ -0,0 +1,164 @@
+# Code-Design Mechanics
+
+The detailed companion to the load-bearing code-design capsule in
+`principles/SKILL.md` Part I. Load this when a design or implementation needs
+concrete boundary guidance, checklists, or examples.
+
+## Contents
+
+1. [Ports & Adapters](#1-ports--adapters)
+2. [Single Source of Truth](#2-single-source-of-truth)
+3. [Generated Contracts](#3-generated-contracts)
+4. [Fail Fast—Where It Matters](#4-fail-fastwhere-it-matters)
+5. [Code Economy](#5-code-economy)
+6. [Tests Earn Their Keep](#6-tests-earn-their-keep)
+7. [Leave It Simpler](#7-leave-it-simpler)
+
+## 1. Ports & Adapters
+
+At design time, identify every database, filesystem, HTTP, queue, clock, and
+randomness dependency. Define the interface the domain needs in the domain
+layer; implement it in infrastructure; wire the adapter only at a composition
+root. Domain functions receive ports as typed parameters and never import
+adapters directly.
+
+```text
+src/
+  domain/ports.ts         # UserRepository, EmailSender
+  domain/user-service.ts  # imports ports, not infrastructure
+  infrastructure/db.ts    # implements UserRepository
+  app/wire.ts             # assembles domain + adapters
+```
+
+```typescript
+// Domain
+export function createUser(repo: UserRepository, email: string) {
+  return repo.insert({ email })
+}
+
+// Composition root
+const repo = new DrizzleUserRepo(db)
+app.post('/users', (c) => createUser(repo, c.req.body.email))
+```
+
+Checklist:
+- Every external dependency has a domain-owned interface.
+- Domain modules do not import databases, filesystems, or transport adapters.
+- Infrastructure is referenced only from composition roots.
+
+## 2. Single Source of Truth
+
+When a variant set can grow, define one typed registry and derive types,
+validation, routing, and display from it. Do not repeat unions or literals in
+consumers.
+
+```typescript
+const ROLE_CONFIG = {
+  admin: { level: 2, canDelete: true },
+  editor: { level: 1, canDelete: false },
+  viewer: { level: 0, canDelete: false },
+} as const satisfies Record<string, RoleConfig>
+
+type Role = keyof typeof ROLE_CONFIG
+const ROLES = Object.keys(ROLE_CONFIG) as Role[]
+```
+
+Checklist:
+- One authoritative constant or schema owns the variants.
+- Downstream types and behavior derive from that registry.
+- Adding a variant changes the registry, not a collection of switches and
+  validators.
+
+## 3. Generated Contracts
+
+Choose one source for each system boundary and derive consumers from it:
+
+- HTTP API: OpenAPI schema to generated client.
+- Typed router: share or infer the router contract.
+- Database: infer application types from the schema.
+- GraphQL: generate types from SDL.
+
+Build generation into the normal pipeline. Consumers import generated or
+inferred types rather than maintaining mirrors. Extend a generated type with
+intersection/composition when needed; do not replace it with a hand copy.
+
+Checklist:
+- Every cross-boundary interface names its source of truth.
+- Generation or inference is part of the build path.
+- No hand-written type mirrors a schema, router, or database definition.
+
+## 4. Fail Fast—Where It Matters
+
+Validate untrusted input and required external contracts at system boundaries
+before domain logic runs. Add internal guards when a violated precondition is
+plausible and consequential; do not turn every helper into a defensive boundary.
+The project decides how much invariant enforcement, edge handling, and
+determinism it actually needs.
+
+```typescript
+function processOrder(input: unknown) {
+  const order = OrderSchema.parse(input)
+  return computeTotal(order)
+}
+
+function applyDiscount(order: Order, pct: number) {
+  if (pct < 0 || pct > 1) throw new Error(`Invalid discount: ${pct}`)
+  // ...
+}
+```
+
+Boundary examples include HTTP handlers, CLI arguments, external API responses,
+and configuration files. Internal checks should report the violated
+precondition and received value whenever that is safe.
+
+Checklist:
+- Validate real trust boundaries and explicit contracts.
+- Match defensive rigor to failure consequences and project scope.
+- Do not add checks, retries, invariants, or determinism only because a more
+  general system might need them.
+
+## 5. Code Economy
+
+Prefer the shortest clear expression of the project's actual requirements.
+Every abstraction, option, layer, fallback, and branch creates maintenance cost;
+it must earn that cost in current scope rather than a hypothetical future.
+Terse does not mean cryptic: optimize for fewer concepts, then fewer lines.
+
+Checklist:
+- Choose the direct solution before a configurable framework.
+- Avoid extension points without a current second use or committed need.
+- Delete incidental machinery made obsolete by the change.
+
+## 6. Tests Earn Their Keep
+
+Automated tests are maintained code. Prioritize stable public interfaces,
+important cross-component seams, high-consequence behavior, and regression tests
+for real bugs. Unit tests belong around genuinely complex logic where isolated
+examples add confidence; simple wrappers and implementation details usually do
+not need their own tests.
+
+Checklist:
+- Name the interface, risk, or regression each test protects.
+- Prefer a useful interface test over several implementation-bound unit tests.
+- Do not chase line coverage or enumerate every possible surface by default.
+- Remove duplicate, tautological, brittle, or low-value tests when they no
+  longer justify upkeep.
+
+## 7. Leave It Simpler
+
+Treat elimination as part of feature work, not a separate activity reserved for
+refactors. During exploration and design, identify code, tests, checks,
+abstractions, compatibility paths, and configuration that the proposed feature
+can make unnecessary. During implementation, perform safe cohesive cleanup in
+the touched area and create explicit cleanup/refactor stories for larger work.
+
+Question whole systems as well as local fragments. Removing behavior,
+guarantees, validation, determinism, compatibility, or safety is a product
+choice: explain the trade-off and ask the user rather than silently weakening
+it.
+
+Checklist:
+- Record what the feature can delete or consolidate.
+- Prefer deletion and inlining before extraction or another abstraction.
+- Leave touched code simpler unless doing so would blur scope or alter behavior.
+- Park broader opportunities; ask before reducing meaningful guarantees.

package/skills/principles/references/models.md

@@ -1,7 +1,7 @@
 # Model Selection & Decision Matrix
 
 > The concrete model-layer companion to the **model-agnostic** dispatch and
-> cross-model policy in `principles/SKILL.md` (Parts IV & VIII) and the
+> cross-model policy in `principles/SKILL.md` Part IV and the
 > "different model class" decision points across the plugin. In-skill prose is
 > deliberately written in capability/role terms; **this file is where those
 > capabilities map to actual models and `peeragent` flags.** Load it whenever a
@@ -9,8 +9,9 @@
 > "use a different model class".
 
 Model generations move fast — the *families and classes* below are the durable
-abstraction; specific version numbers (e.g. Opus 4.x, GPT-5.x-Codex, Gemini 3.5,
-GLM-5.2) are the current resolution of each class as of writing. Always resolve
+abstraction; specific versions and names (for example Claude Fable, GPT-5.6
+Luna/Terra/Sol, GPT-5.x-Codex, Gemini 3.5, and GLM-5.2) are current resolutions
+of each class as of writing. Always resolve
 the concrete model against current sources when the choice is load-bearing.
 
 ## Contents
@@ -51,11 +52,26 @@ the in-skill prose names; this is what they mean.
 ## 2. Model-family cards
 
 **Claude (Anthropic)** — `--agent claude`
-- Tiers: `opus` (deepest reasoning + agentic, 1M context; slowest), `sonnet`
-  (strong coding + speed; 1M beta), `haiku` (fast, near-frontier, cheap).
+- Tiers include `opus`, `sonnet`, `haiku`, and Claude Fable where available.
 - Effort: `high | xhigh` (default `xhigh`).
-- Best roles: `opus` → deep reviewer / adversarial peer / highest-tier worker;
-  `sonnet` → primary worker / scout; `haiku` → leaf tasks, cheap fan-out.
+- Recommendations: Opus for deep review/adversarial work, Sonnet for primary
+  work and scouting, Haiku for cheap leaf fan-out. Fable is a strong but
+  expensive design, orchestration, and review choice; it can implement, but its
+  cost usually makes another capable worker preferable.
+
+**GPT-5.6 (OpenAI; host-native where available)**
+- **Luna** is the recommended implementation workhorse: medium thinking for
+  simple/routine work, scaling through xhigh for fairly complicated work short
+  of the hardest tier.
+- **Terra** remains a situational middle pick. Current practitioner preference
+  often favors Sol at low thinking as the bridge above Luna rather than treating
+  Terra as a mandatory rung.
+- **Sol** is preferred for design, review, and complex/large implementation. Low
+  thinking bridges above Luna; raise thinking for the hardest architecture,
+  review, and coding work.
+- These are recommendations, not fixed capability facts. Discover current host
+  availability before selection. Luna, Terra, Sol, and Codex share OpenAI
+  lineage, so switching among them is not cross-model evidence.
 
 **Codex (OpenAI)** — `--agent codex`
 - Current class: GPT-5.x-Codex (model auto-selected; no `--model` flag).
@@ -83,9 +99,9 @@ the in-skill prose names; this is what they mean.
 
 | Role | Needs (capability) | Primary models |
 |---|---|---|
-| Primary worker | write fidelity, agentic stamina | Sonnet-class / Codex high / GLM-5.2 high |
-| Scanner/scout (deep read-only fan-out) | domain inspection, evidence, scoped artifacts | Haiku / Sonnet medium / Sonnet for volume; Opus/Codex xhigh/GLM xhigh for subtle gates |
-| Deep reviewer | reasoning depth, fresh context | Opus-class xhigh / Codex xhigh / GLM-5.2 xhigh |
+| Primary worker | write fidelity, agentic stamina | GPT-5.6 Luna medium→xhigh / Sonnet-class / Codex high / GLM-5.2 high; Sol for complex/large implementation |
+| Scanner/scout (deep read-only fan-out) | domain inspection, evidence, scoped artifacts | Haiku / Luna or Sonnet for volume; Sol/Opus/Codex xhigh/GLM xhigh for subtle gates |
+| Deep reviewer | reasoning depth, fresh context | GPT-5.6 Sol / Claude Fable or Opus / Codex xhigh / GLM-5.2 xhigh |
 | Advisory peer (Phase 1) | blind-spot diversity, augmentation | a **different class** than the host |
 | Adversarial peer (Phase 2) | blind-spot diversity, attack posture | a **different class** than host + than Phase 1 |
 
@@ -98,67 +114,30 @@ diversity**, and for deep work use **two distinct peer classes** (§5).
 
 | Host class | Valid peer classes (any different class) |
 |---|---|
-| Claude | codex · gemini · zai |
-| Codex | claude (opus) · gemini · zai |
-| Gemini | claude (opus) · codex · zai |
-| Z.AI GLM | claude (opus) · codex · gemini |
+| Claude (including Fable) | openai · gemini · zai |
+| OpenAI (GPT-5.6 or Codex) | claude · gemini · zai |
+| Gemini | claude · openai · zai |
+| Z.AI GLM | claude · openai · gemini |
 
 When the natural pair is unavailable, fall through to the next class; never
-peer with the same class as the host.
+peer within the host lineage and call it cross-model. A same-lineage reviewer
+may still provide fresh context when labeled accurately.
 
 ## 5. Multi-class review for deep/complex work
 
-For **deep or complex work** — architectural design points, large/risky
-features or epics, the final autopilot completion review, whole-repo scans — a
-single peer is the floor, not the ceiling. **If two different model classes are
-available, use both.** Different training lineages have different blind spots;
-two independent peers catch more than one, and their disagreements are
-themselves signal (re-read both before deciding).
-
-Concretely: pair the two peers across the two review phases in §6 — one class
-runs the **advisory** pass, a *different* class runs the **adversarial** pass.
-That realizes the 2-class rule through the phase ordering and maximizes both
-augmentation diversity and adversarial independence. For routine/small work a
-single peer (or none) remains correct — this escalation is for deep/complex
-scope only.
+The risk and `review_weight` policy lives in
+[advisory-review.md](advisory-review.md). At model-selection time, when that
+policy calls for two classes, choose two distinct training lineages that also
+differ from the host where availability permits. Pair one with each phase;
+disagreement is evidence to investigate, not a vote.
 
 ## 6. Two-phase design review: advisory then adversarial
 
-Designs and reviews are both evaluated in a fixed **two-phase order** —
-**completeness/complementary/advisory first, adversarial second.** Never reverse
-the phases and never skip Phase 1 to jump straight to attack: a design or review
-reviewed only adversarially gets torn apart before anyone checks whether it is
-complete. The two phases have **different loop shapes depending on whether the
-artifact is a design (open) or a review (complete)**:
-
-**Phase 1 — Completeness / Complementary / Advisory.** Augmentation, not
-judgment. Ask what is missing, what alternatives strengthen it, and what
-questions/risks should be weighed.
-- *Design (open artifact, before decisions lock)*: **a single pass.** You don't
-  iterate an open design to convergence. The host chooses and records rationale.
-  This is the default autopilot design-time peer ask.
-- *Review (complete artifact — feature/epic/out-of-band review)*: **a multi-step
-  convergence loop**, not a single ask — the artifact is complete, so iterate
-  until findings stabilize. The ideal is the full `peer-review` convergence loop
-  (≥3 review→refine passes, continue while substantive issues surface, stop on
-  nits, cap ~5); run that loop in the advisory/complementary posture when
-  `peer-review` is available. When only a single peer pass is available, run as
-  many rounds as the mechanism allows and say it did not reach full convergence.
-
-**Phase 2 — Adversarial (after Phase 1 converges or, for designs, completes).**
-Attack posture. Ask a **different** reviewer (ideally a different class than
-Phase 1, per the 2-class rule in §5) what is broken, contradictory, built on a
-false assumption, or will fail in operation. For reviews this is the same
-`peer-review`-style convergence loop applied in the attack posture; for designs
-it is a focused adversarial pass. Verify concrete claims against code/foundation
-docs before accepting or rejecting.
-
-Record both phases in the item body under `## Other agent review`, labeling each
-finding's phase, the reviewer class, and (for reviews) how far the convergence
-loop ran (converged on nits / hit cap / single pass only). Peer failures in
-either phase are non-blocking (fall back to a fresh same-class sub-agent); the
-final autopilot completion review must still clear through at least one
-cross-class pass.
+The phase order, artifact-specific loop shapes, ceilings, and recording format
+live in [advisory-review.md](advisory-review.md). This model-layer reference adds
+one constraint: when two classes are selected, Phase 2 should differ from both
+the host and Phase 1 where the available class set permits it. Never label an
+unknown or same-class reviewer cross-model.
 
 ## 7. peeragent invocation cheatsheet
 

package/skills/prose-author/SKILL.md

@@ -160,10 +160,15 @@ fan-out. Do not route prose features to `/agile-workflow:implement-orchestrator`
 (agent-spawning + worktrees) just because they exceed a line count; the
 orchestrator's value is parallel coordination, which prose work does not need.
 
-For a large deliverable, the inline `implement` is the **write** stride and
-`review` is a genuine **revise/coherence** pass — not a rubber stamp. For the
-common small case, implement is the one stride that finishes the work and review
-is light.
+For a large deliverable, inline `implement` is the **write** stride and the
+review lane is a genuine **revise/coherence** pass — never a rubber stamp. For a
+small deliverable, the same review may be light, but it still evaluates the work.
+In both cases, `/agile-workflow:implement` continues through that review lane to
+`done` by default in one invocation, forwarding the effective review weight, or
+returns with a documented bounce or blocker. Even when policy skips independent
+review, closure still requires green verification and acceptance evidence. The
+lane stops at `review` only when the caller explicitly requests `stop-at-review`
+(or the project convention sets that boundary).
 
 ## Output
 

package/skills/refactor-design/SKILL.md

@@ -143,14 +143,13 @@ drafting features. Iterate over the target set:
 3. Read-first map of the feature's area; use one exploratory sub-agent only if the
    area is still unclear. Include `.agents/skills/refactor-conventions/` as
    context when present.
-4. Surface strategic ambiguities specific to the refactor (e.g., "preserve API
-   shape or break consumers?", "in-place or shadow-then-swap?", "rollback
-   strategy when atomic?"). Use structured question tool.
+4. Use the structured question tool for refactor-specific strategic ambiguities
+   such as API compatibility, migration shape, or rollback strategy.
 5. Capture answers under `## Design decisions` in the feature body
 6. Do NOT design or advance stage — let the design family pick up later
 7. Commit per feature: `refactor-design --only-questions: <id>`
 
-Requires interactive mode; refuse to run under an active autopilot run or goal.
+Requires interactive mode; refuse under autopilot. Otherwise defer question and advisory policy to `principles/SKILL.md` Parts III–IV.
 
 ## Workflow — per-feature mode
 
@@ -196,8 +195,8 @@ across the lenses below and skip exploratory fanout. If one area is unclear, use
 focused exploratory sub-agent. Use parallel exploratory sub-agents only when the lenses need separate
 attention across a medium/large target.
 
-The first four scan axes are mandatory. Run them even when a project-specific
-refactor-conventions catalog exists. The catalog adds a fifth scan axis; it
+The first five scan axes are mandatory. Run them even when a project-specific
+refactor-conventions catalog exists. The catalog adds a sixth scan axis; it
 does not narrow or disable the default refactor judgment.
 
 - Use the host's generic/general-purpose subagent prompted with the scanner
@@ -208,28 +207,35 @@ does not narrow or disable the default refactor judgment.
   deployment-provided read-only role only if it is already available; otherwise
   keep the host-local scan fallback.
 
-1. **Code Smells** — "Find code that smells off in <area>. Look for: duplicated
+1. **Elimination First** — "Before proposing extraction or a new abstraction,
+   find code, tests, checks, wrappers, options, compatibility paths, and files
+   that can be deleted, inlined, merged, or made unnecessary. Include whole
+   subsystems whose maintenance cost may exceed their current value, but mark
+   any removal that changes behavior or guarantees as a user decision rather
+   than a pure refactor."
+
+2. **Code Smells** — "Find code that smells off in <area>. Look for: duplicated
    logic across files; long files (>500 lines); deep nesting (>4 levels); god
    functions (>100 lines doing multiple distinct things); god modules (>15
    methods or multiple responsibilities); leaky abstractions (consumers reaching
    past a module's public API). Report each with file:line and a one-line
    explanation."
 
-2. **Missing Abstractions** — "Find places where multiple modules implement
+3. **Missing Abstractions** — "Find places where multiple modules implement
    similar logic that could be extracted. Report each with file:line references
    and which modules would benefit."
 
-3. **Pattern Violations & Naming Inconsistencies** — "Read
+4. **Pattern Violations & Naming Inconsistencies** — "Read
    `.agents/skills/patterns/*.md` and legacy `.claude/skills/patterns/*.md` if
    they exist. Find code that deviates from established patterns. Report
    naming inconsistencies — same concept named differently across modules. Report
    each with file:line."
 
-4. **Dead Weight** — "Find dead code: unused exports (cross-check against grep
+5. **Dead Weight** — "Find dead code: unused exports (cross-check against grep
    for importers), commented-out blocks, TODO/FIXME where the work is clearly
    already done, files with very few callers. Report each with file:line."
 
-5. **Project Refactor Conventions** — Run only when
+6. **Project Refactor Conventions** — Run only when
    `.agents/skills/refactor-conventions/` exists. "Read
    `.agents/skills/refactor-conventions/SKILL.md`, its referenced rule files,
    and the `## Refactor Style Conventions` section in AGENTS.md if present.
@@ -246,7 +252,7 @@ findings.
 ### Phase 4: Categorize findings
 
 Sort the findings into:
-- **High value** — reduces duplication, extracts shared abstractions, consolidates
+- **High value** — eliminates code or concepts, reduces duplication, consolidates
   similar code, or corrects convention drift that materially improves module
   boundaries or repeated project workflow
 - **Medium value** — improves consistency, aligns with established patterns
@@ -263,14 +269,15 @@ run summary.
 
 For each step, specify:
 - **Step name and value tier** (High / Medium / Low)
-- **Source lens**: code smell / missing abstraction / pattern drift /
+- **Source lens**: elimination / code smell / missing abstraction / pattern drift /
   dead weight / refactor convention `<rule>` (if applicable)
 - **Files affected**: paths
 - **Current state**: actual code showing what exists now
 - **Target state**: exact code showing what it should look like after
 - **Implementation notes**: how to get from current to target; non-obvious considerations
-- **Acceptance criteria**: build passes, tests pass, plus specific structural/behavioral
-  check
+- **Acceptance criteria**: relevant verification passes plus a specific
+  structural/behavioral check; add or retain tests only where they protect an
+  important interface, complex unit, or regression
 - **Risk**: Low / Medium / High — what could go wrong
 - **Rollback**: how to revert this step if it breaks something
 
@@ -309,7 +316,7 @@ Append to the feature file's body:
 ### Step 1: <name>
 **Priority**: High/Medium/Low
 **Risk**: Low/Medium/High
-**Source Lens**: code smell / missing abstraction / pattern drift / dead weight / refactor convention `<rule>`
+**Source Lens**: elimination / code smell / missing abstraction / pattern drift / dead weight / refactor convention `<rule>`
 **Files**: `src/path/file.ext`, ...
 **Story**: `<story-id>` (if spawned)
 
@@ -370,7 +377,9 @@ In conversation:
   add — escalate via `/agile-workflow:scope` instead.
 - Each step is self-contained and committable in isolation. Multi-step PRs lose the
   ability to roll back individual steps.
-- Specify test verification for every step. A refactor without verification is a hope.
+- Specify proportionate verification for every step. Do not require a new unit
+  test for simple structural edits when build, type, integration, or existing
+  interface evidence is more useful.
 - Prioritize measurable improvements (less duplication, clearer boundaries) over
   aesthetic preferences. Beauty that doesn't reduce complexity isn't worth the risk.
 - Project-specific refactor conventions extend the defaults; they never replace