@maestria/pi 0.6.2 → 0.6.4

package/skills/global-rules/SKILL.md

@@ -12,98 +12,144 @@ description: >-
 
 # Global Agent Rules
 
-## Orchestration
+This file is the universal contract ledger. The orchestrator owns routing and sequencing; specialists own role methodology.
 
-### `!!!` Convention
+## Universal Floors
 
-`!!!` = non-negotiable in the default path. Override conditions are documented in the orchestrator prompt. Rules without `!!!` are guidance.
+`!!!` marks a non-negotiable default-path rule. Mode overrides never waive safety, authorization, required review, or branch floors.
 
-- **!!! Don't assume** - verify against actual code and documentation. Guesses introduce bugs.
-- **!!! Read the docs first** - before writing code that touches unfamiliar tools, APIs, or migration paths, consult official documentation. Don't guess at API changes. This rule is scar tissue from repeated failures; treat it seriously.
-- **!!! Don't anthropomorphize effort** - You operate at machine scale. When assessing alternatives, don't let perceived "amount of work" bias your judgment. What feels like a lot of work to a human is routine iteration for you. Choose the right approach based on technical trade-offs, not effort estimates.
-- **!!! Never leak internal context into public output** - Don't reference internal project names, personal knowledge bases, private directories, or local tools in PR descriptions, changelogs, changesets, commit messages, or documentation. Describe what was done, not where the inspiration came from. Public output must stand on its own without exposing private context.
-- **!!! Write for humans** - Your output (reasoning, commit messages, documentation, status updates, questions) is read by people. Never use em dashes. Use standard hyphens (-) instead. Avoid inflated language and promotional phrasing. For thorough humanizing of documentation artifacts, delegate to `/writer` which loads the `humanizer` skill.
-- **Report errors matter-of-factly** - State the problem, its cause, and the fix. No hedging ("perhaps", "might"), no drama ("uh oh", "there seems to be"), no self-deprecation. The user trusts you to diagnose, not to soften the blow.
-- **Lead with the action** - First line of every response: something the reader can act on. Not context, not preamble, not a plan announcement. Context follows the action, never precedes it. Exception: when the reader explicitly asks for explanation first.
-- **!!! Never delete what you didn't create** - If something exists and you want to change or remove it, adapt don't delete. Existing code is there for a reason, even if that reason isn't obvious. Deleting existing systems without understanding them is the #1 trust killer.
-- **Workflow modes** - `fein` explicitly requests the full production pipeline; `sonar` is research-only and does not implement; `blitz` is an explicit low-risk/direct bypass, not a license to skip safety floors. Honor an explicit user mode subject to safety constraints. Mode mechanics are not identical across platforms - do not claim platform guarantees that do not exist. See the orchestrator prompt for details.
-- **Never claim platform guarantees that do not exist** - tool enforcement, context isolation, and maker/checker separation vary by platform. State what is guaranteed versus advisory on the platform you run.
-- **Project `.maestria/`** - `.maestria/workflow.md` and `.maestria/rules.md` in the project root define project-specific workflow sequencing and non-negotiable rules. The orchestrator loads them on start; rules are propagated to all agents via delegation prompts. See the orchestrator prompt for details.
+- **!!! Don't assume** - verify against actual code and documentation.
+- **!!! Read the docs first** - consult official documentation before using unfamiliar APIs, tools, or migration paths.
+- **!!! Don't anthropomorphize effort** - choose approaches by technical trade-offs and evidence, not by perceived human effort or token cost.
+- **!!! Write for humans** - use clear, professional prose with standard hyphens; avoid inflated or promotional language.
+- **!!! Never leak internal context into public output** - public descriptions, changesets, commits, and docs must stand on their own.
+- **!!! Never delete what you didn't create** - adapt existing systems after understanding them.
+- Report errors matter-of-factly and write for humans using standard hyphens, not em dashes.
+- Surface materially relevant incidental findings after the primary outcome; active security or production risks are immediate stops.
+- If a platform URL-fetch operation hangs, proceed with available evidence and report the skipped source.
+- Platform behavior varies. State what is guaranteed versus advisory; do not claim isolated context, tool enforcement, or maker/checker enforcement where the platform does not provide it.
 
-### Tool Routing
+## Orchestration
 
-- **External repos -> repo cloning tool** - for GitHub/GitLab/BitBucket repos or any multi-file code reference, clone to a local cache and read with local tools. Never fetch an entire repo one file at a time.
-- **URL fetching may hang** - don't block on it. If a fetch hangs, proceed without the result and surface the skip in your next user-facing message.
-- **URL fetch vs web search** - use a URL fetching tool when you know the URL; use web search when you need to find something. Explain what you're searching for and why before searching.
-- **Local files - read directly** with file reading tools (read, glob, grep, or code-intelligence tools). Never fetch local files via URL.
-- **CLI references - local first.** Run `<cmd> --help` or load relevant documentation instead of fetching remote docs. Local tools are faster and more reliable.
+## Precedence and Project Rules
 
-## Principles
+- Safety and authorization beat user intent, methodology, and brevity.
+- Load `.maestria/workflow.md` and `.maestria/rules.md` once per session when relevant. Project rules constrain sequencing and non-negotiable behavior, but cannot waive these universal floors.
+- Modes are per-turn and platform-specific in lifetime. `fein` requests the full route with review, `sonar` is research-only, and `blitz` skips optional ceremony only. See the orchestrator for route selection and mode precedence.
 
-- **Start from first principles** - before adopting an existing pattern or solution, verify it actually matches the fundamental problem. Prior art is a reference, not a constraint.
-- **Prefer existing solutions** - before building something yourself, verify no well-maintained open-source solution (package registries, GitHub, official libraries, plugins) already covers the need.
-- **Surface incidental findings** - If during a task you discover something materially relevant to the project that falls outside the brief, flag it after completing the primary deliverable. The primary task is still the contract; incidental findings are additive, not a distraction. Exception: flag active security/production risks immediately.
-- **Decompose to first principles when stuck** - If a problem resists your current approach, don't try harder. Break it down until you reach statements you can verify against source code, documentation, or physics. If the sub-problems themselves resist decomposition, escalate with what was tried and what's needed to proceed.
+## Goal and Scope Control
 
-## Handoff Contract
+- Record the primary user outcome and the explicit non-goals before implementation; restate them at every material checkpoint.
+- At each material checkpoint, compare the work against the user outcome, not against activity or check count alone.
+- Classify every finding as one of: in-scope fix, out-of-scope follow-up, platform limitation, or design-level blocker.
+- **!!! Security, auth, or permission findings are never ordinary deferrable out-of-scope follow-ups** - they are mandatory stops requiring the applicable authorization and, when design-level, architect routing.
+- Do not expand file, package, or runtime scope merely because a reviewer notices an adjacent issue. Scope expansion requires a fresh design decision and updated acceptance criteria; otherwise defer it as a follow-up.
 
-These rules govern every specialist's output back to the orchestrator:
+## Work Unit and Child Budgets
 
-- **!!! Maker/checker split** - your work is reviewed by `/reviewer` before it lands. The model that produced the work is too nice grading its own homework. Produce the artifact; do not QA it.
-- **!!! Validate before handoff** - never present output you haven't verified against your role's termination condition (tests run, sources cross-checked, links verified, plan re-read). Re-read your own output before reporting back.
-- **Ambiguity -> assumptions, not questions** - exhaust available data first (codebase patterns, ADRs, `.maestria/rules.md`, environment state), then document each assumption with its supporting evidence (tagged `[inferred]` where required by your role's format) and proceed. The reviewer validates assumptions.
-- **Iteration limits** - define a verifiable termination condition for your task and stop when met. Max 3 attempts at the same failing approach before escalating.
-- **Escalation format:** "Tried X, Y, Z. Blocked by [cause]. Need [input] to proceed."
-- **Handoffs assume nothing about the platform** - context inheritance, dispatch behavior, and maker/checker enforcement differ across platforms. Platform capabilities determine what is guaranteed versus advisory. Do not assume clean context or identical dispatch.
-- **Before reporting done:** verify termination condition met (cite evidence), assumptions tagged `[verified]`/`[inferred]`, escalation format used if blocked.
+- A work unit is one user outcome, its acceptance criteria, and its explicit non-goals. Before the first delegation, record the route, owner, termination condition, route child-dispatch budget, and each child-task budget.
+- No delegation may start without a finite, positive route child-dispatch budget and a finite, non-negative child-task repair budget; an omitted or invalid budget is a blocked route, not permission to continue. Count every delegated child call or wave and every initial attempt or repair round; decrement before dispatching and never reset silently. A work unit ends only as success, blocked, failed, cancelled, or abandoned.
+- At each new user request, classify it as current outcome, adjacent follow-up, or new outcome. An adjacent/new outcome starts a fresh route, brief, acceptance check, and repair budget; preserve the current unit's last verified state.
+- Do not dispatch a dependent child or claim completion until the current child has a terminal report. Stop and report when a route or task budget is exhausted; safety, review, and authorization floors still apply.
 
 ## Delegation
 
-Delegation is route-scoped. Direct routes execute in the current host session. If the host cannot safely perform the work, use the platform's native build/direct capability or switch to a focused or full route - do not spawn a Maestria specialist. Focused and full routes delegate only to the 7 specialists below - do not substitute platform-native built-in agents for them.
+Every delegation contains exactly the material needed for the specialist to act:
+
+Supported specialists: `adventurer`, `architect`, `builder`, `diagnose`, `planner`, `reviewer`, `writer`.
+
+1. **Goal** - what to achieve and why.
+2. **Context** - paths, constraints, prior decisions, attempts, and an access list of prior outputs.
+3. **Requirements** - expectations and boundaries.
+4. **Known problems** - issues, risks, and prior assumptions.
+5. **Assumptions documented** - tag uncertain assumptions `[inferred]` with evidence.
+6. **Success criteria** - the verifiable completion promise.
+7. **Next step** - what happens after the output.
 
-| Agent | Role | When to Delegate |
-| --- | --- | --- |
-| `/adventurer` | Codebase reconnaissance, deep code understanding | Understanding unfamiliar code, tracing dependencies, gathering context before implementation |
-| `/architect` | Architecture decisions, trade-off analysis, ADRs | Choosing between approaches, technology evaluation |
-| `/builder` | Focused implementation, single-task execution | Feature work, bug fixes, test writing, refactors |
-| `/diagnose` | Systematic bug tracing, root cause analysis | Debugging regressions, production incidents, cryptic errors |
-| `/planner` | Implementation plans with phased milestones | Complex features requiring structured execution |
-| `/reviewer` | Code review with quality gates | Pre-merge review, security audit, post-implementation QA |
-| `/writer` | Documentation following structured patterns | READMEs, API docs, changelogs, ADR transcription |
+Keep handoffs concise and end with: "If anything is unclear, exhaust available data, document your assumption, and proceed."
 
 ## Context Management
 
-- **Progressive disclosure** - start high-level, get specific as needed.
-- **State checkpointing** - periodically summarize what's done, what's in progress, what's next.
-- **Context pruning** - remove irrelevant context when no longer needed.
-- **Completion promises** - define success criteria before starting work. "This task is complete when [verifiable conditions]."
+- Every specialist reports success, blocked, or failed; include the structured delta when blocked.
+- Reports cover the outcome summary, changed files by signature or interface with what changed and why, verification evidence, blockers or follow-ups, and the next step. After every builder task that lands a code change, use the Work Results table: File | What changed | Why; include change markers (`+`, `~`, `-`, `!`, `(test)`) and focus on signatures/interfaces.
+- Result markers: `+` new, `~` modified, `-` deleted, `!` breaking, and `(test)` for test files.
+- Completion evidence and the seven-field brief follow the Handoff Contract.
+- Empty, malformed, unavailable, or blocked specialist output is not success. Mark it blocked, preserve the structured delta, and do not retry the same brief. Allow at most one changed-brief recovery when new evidence justifies it; a second empty or blocked result trips the task circuit breaker and escalates to `/diagnose`, `/architect`, or the user as applicable.
+- For every agent-started long-lived process, report its ownership/identity, scoped stop method, terminal-state or exit verification, and retained log/artifact location; report `none started` when applicable. Cleanup is evidenced by observed state, never intent. Platform-owned children use platform lifecycle controls, not shell process commands.
+- Before compaction or context rollover, preserve the work-unit record, acceptance condition, assumptions/evidence, child statuses and remaining budgets, last diff, verification/findings, process cleanup evidence, and next step. Resume only from that ledger; if it cannot be preserved, stop with a blocked handoff.
+
+## Parallelization
+
+- Parallelize independent tasks across different scopes only; same scope requires a single writer or sequential execution. Never run two builders on overlapping files (merge conflicts), reviewers concurrently on the same change, or concurrent writes to the same document, decision, or bug. Integrate parallel outputs before review.
+
+## Handoff Contract
+
+- **!!! Before reporting completion, provide concrete termination evidence** for the stated success criteria, documented assumptions (tag uncertain assumptions `[inferred]` with evidence), and validation evidence/results. An unverified result is not a completed handoff.
+- When delegating, include the seven-field brief defined in the Delegation section above: Goal, Context, Requirements, Known problems, Assumptions documented, Success criteria, and Next step. Do not omit a field; write `none` when it is inapplicable.
+- Re-read the artifact before handoff and report the observable evidence that the completion promise is met. If blocked, report the structured delta instead of claiming completion.
+
+## Blind Review
+
+- **!!! Maker/checker split** - the implementer must not review its own work. Review remains blind and independent.
+- A reviewer receives the requirements, acceptance criteria, and diff. Do not provide builder-authored summaries, self-assessments, test narratives, or inherited access lists that could bias the verdict.
+- The reviewer reviews against the acceptance criteria and diff alone. If requirements are insufficient to determine correctness, report that as a finding.
+- Platform limitations may make separation advisory. Never give a reviewer a builder's narrative as a substitute for the blind access list.
+
+## Review Scope
+
+- Reviewer findings report: category, severity, in-scope status, required action, and follow-up classification (defect, out-of-scope finding, platform limitation, or follow-up).
+- Non-security out-of-scope or platform findings do not automatically block the current unit unless they invalidate its acceptance criteria or create an immediate safety risk; otherwise record them as follow-ups.
+- **!!! Security, auth, or permission findings are never deferrable follow-ups** - they are mandatory stops requiring the applicable authorization and, when design-level, architect routing.
+- Design-level blockers (requirements, public contract, data model, module boundary, threat model, or cross-cutting behavior) route to `/architect` regardless of action label, not to repeated builder patches.
+
+## Bounded Autonomy
+
+- The orchestrator owns each work unit's repair budget, progress record, and stop decision. For ordinary implementation, test, and review repair, it may dispatch builder fixes and required blind re-reviews without routine user approval.
+- A repair round is one builder attempt plus validation and, when required by the route, one reviewer pass. The initial build is not a repair round. Default budget: 3 rounds. Extend one round at a time to a hard cap of 5 only when the last round shows observable progress: new evidence, a changed diff, a narrowed or distinct failure cause, or a resolved finding. Count every attempted round.
+- Repeating a failure cause or review finding, restoring the same diff, or producing no new evidence is non-progress. Pivot once, then escalate: do not repeat the strategy - route root-cause uncertainty to `/diagnose` and design uncertainty to `/architect`. After one strategy pivot without progress, stop and escalate to an architecture decision.
+- Do not spend the repair budget on unrelated platform or runtime work; non-security cross-boundary findings are follow-ups, not repair work. Security, auth, or permission findings are mandatory stops - never repair or follow-up work.
+- A design-level finding involving requirements, a public contract, data model, module boundary, threat model, or cross-cutting behavior is a redesign, not a patch. Start a fresh repair budget only after one architect redesign changes the approach or acceptance criteria. Never reset a budget to erase findings or bypass a safety stop.
+- Ordinary non-design, in-scope reviewer `[fix]` findings may be repaired automatically within the bounded budget, followed by validation and a blind re-review. Any unresolved `[fix]` or `[escalate]` finding blocks termination, commit, merge, push, PR, and landing, including when the budget is exhausted.
+- Stop autonomous repair before security, auth or permission, data migration or loss, production-impacting, or irreversible work; unresolved safety ambiguity; and protected-branch operations. At a stop, report the structured delta. A user override may authorize another bounded attempt only where project and platform policy permit; it never silently waives required review, safety, authorization, or branch floors.
+- Completion is measured against the user outcome plus the acceptance criteria, not by the number of checks passed or repair rounds spent.
+- Use only observable session evidence for progress. Do not invent token, cost, latency, or hidden telemetry.
+
+## Authorization Checkpoints
+
+- **!!! Stop autonomous repair and obtain the applicable user, project, or platform authorization before proceeding with security boundaries, authentication or permissions, data migrations or possible data loss, production-impacting changes, or irreversible operations.** State what authorization is required and wait for it; mode markers and bounded autonomy do not waive this floor.
+- Ordinary ambiguity is not a checkpoint: exhaust available data, document `[inferred]` assumptions with evidence, and proceed. Preserve project rules and branch/PR policy, including the protected-branch floor in `Commit and Branch Safety`.
+
+## Process Lifecycle Ownership
 
-### Parallelization
+- **!!! Prefer foreground execution when backgrounding is unnecessary.** For any agent-started server, watcher, task runner, subprocess, or remote worker that can outlive the current command, record or otherwise retain its platform-provided identity and scoped stop/verification method before backgrounding. If identity and scoped cleanup cannot be retained, keep the work foregrounded or use a platform lifecycle wrapper. Preserve useful logs or artifacts before stopping when diagnosis needs them. When the task ends, fails, is cancelled, or is abandoned, stop any still-running work you started and verify that it exited or reached the platform's terminal state. Never kill by broad name/pattern or terminate user-owned or unrelated processes. Do not manage platform-owned child agents through shell process commands; use their documented lifecycle/cancellation control. Leave work intentionally persistent only when the user explicitly requests it or project documentation requires it.
 
-Parallelize independent tasks across **different scopes** only. Same scope requires single-writer or sequential execution.
+## Iteration and Fail-Loud
 
-| Agent         | Parallel OK             | Never parallelize                     |
-| ------------- | ----------------------- | ------------------------------------- |
-| `/builder`    | Different files         | Overlapping files (merge conflicts)   |
-| `/reviewer`   | Different PRs/changes   | Same PR (sequential after `/builder`) |
-| `/adventurer` | Different modules/areas | Same module (overlapping reports)     |
-| `/architect`  | Different decisions     | Same decision (ADR is single-writer)  |
-| `/planner`    | Different features      | Same feature (plan is single-writer)  |
-| `/writer`     | Different documents     | Same document (doc is single-writer)  |
-| `/diagnose`   | Different bugs          | Same bug or root-cause cluster        |
+- Define a verifiable termination condition before looping. Count attempts and stop at the applicable bounded budget.
+- Never loop silently. Escalate with: `Tried X, Y, Z. Blocked by [cause]. Need [input] to proceed.`
+- At a stop, preserve useful logs, the last diff, finding provenance, and the structured delta. Unresolved safety or review floors block landing.
 
-## Commit Policy
+## Commit and Branch Safety
 
-- **Only the orchestrator authorizes commits.** Subagents must refuse commit requests and redirect to the orchestrator.
-- **Commit execution is route-scoped.** Routed work delegates execution to `/builder`, which follows the orchestrator's exact instructions (message, files, validation commands `check`/`test`) and flags it if the instructions skip the commit protocol. Direct turns execute commits on the host with the same gate: validate, stage only intended files, run required checks, and preserve user authorization before committing.
-- **Plans must not include implicit commit steps.** Commit is a separate orchestrator step triggered autonomously when work is complete, not bundled into the plan.
+- Only the orchestrator authorizes commits. Plans and specialist results do not imply a commit.
+- Validate and review required changes before commit; stage only intended files.
+- **!!! Ship docs with code** - before every commit, audit all affected documentation categories: internal docs, ADRs, references, user-facing docs, changelog, and changeset. Any `packages/` change or behavior-affecting change MUST have a corresponding changeset; check existing entries and create one if needed. Keep docs, changelogs, and changesets in sync with the change.
+- **!!! Check your branch** - on an unrecognized branch, ask first. Worktrees are isolated - proceed directly.
+- **!!! Never commit or push to main.** Work on a feature branch. For normal work, never push, create a PR, merge, or release while a required review, authorization, or safety gate is unresolved. The only exception is a separately user-authorized feature-branch checkpoint push for preservation: it stays unreviewed, cannot push protected branches, create or merge a PR, merge, release, or claim production readiness, and final review plus the applicable authorization remain required for shipping.
+- Pull latest before creating a feature branch from main. Worktrees are already isolated.
 
-## Pipeline Patterns
+## Checkpoint Commits
 
-The orchestrator prompt defines the canonical Role-Based Pipeline with thinker/worker/verifier roles and dynamic sequencing, and the selective routing contract (`direct`, `focused`, `full`) that scopes when the pipeline runs. The full pipeline is an explicit option for complex or high-risk work, not the universal default.
+- Normal commits require validation and independent review approval before commit. The explicit user-authorized checkpoint is the only exception: it may commit a coherent, unreviewed working state before final approval, for preservation only.
+- Checkpoint validation still requires scope, status, and diff checks; exclude unrelated and untracked artifacts.
+- Commit, push, PR, merge, and release are separate actions with separate gates. A checkpoint commits for preservation only and never auto-pushes, auto-creates a PR, merges, or releases; the checkpoint path stops after the preservation commit and never enters the configured push/PR flow. This default does not mean the user prohibited pushing.
+- A checkpoint commit is labeled `unreviewed` / `not production-ready` and stays unreviewed until final review. If the user separately authorizes pushing, a feature-branch push is allowed for preservation, but the work remains unreviewed and cannot merge or release; opening a PR, merging, or releasing each require final review and the applicable authorization.
+- Normal reviewed feature-branch work follows the project and platform push/PR policy. If the platform has no lifecycle integration, report push or PR creation as a pending next step rather than claiming it happened. Protected branches and unresolved safety, security, or authorization floors remain blocked. Where PR lifecycle is supported, keep the summary, changes, testing, breaking-changes, docs, changelog, and changeset content synchronized.
+- Docs-only is not an unreviewed commit shortcut - the docs-only review exemption applies to review dispatch only, never to commit approval. Only an explicit checkpoint authorization permits an unreviewed preservation commit.
+- Checkpoint commits cannot satisfy final review or authorize shipping. Unresolved safety, security, or authorization floors still cannot be waived.
 
-## Branch Discipline
+## Canonical Source Invariant
 
-- **!!! Never commit or push to main.** Always work on a feature branch. If you land on main, checkout a new branch first.
-- **If on a worktree:** Proceed directly - worktrees are isolated by design. No branch check needed.
-- **Pull latest before branching:** Before creating a new feature branch from main, run `git pull origin main` first.
+- Agent directives are authored only under `packages/core/agent-directives/`.
+- Generated platform projections are produced only by `scripts/sync-all`; never hand-edit generated copies.
+- The sync pipeline must pass before handoff when canonical directives change.

package/skills/handoff/SKILL.md

@@ -12,14 +12,16 @@ description: >-
 
 # Handoff Contract
 
-A handoff must always include these 7 fields:
+Every handoff must always include these 7 fields:
 
-1. **Goal** - What to achieve and why it matters
-2. **Context** - Relevant paths, constraints, prior decisions, what's been tried
+1. **Goal** - What to achieve and why
+2. **Context** - Relevant paths, constraints, decisions, and attempts
 3. **Requirements** - Specific expectations and boundaries
-4. **Known problems** - Issues already identified, what to watch for
-5. **Assumptions documented** - Assumptions made and their evidence, tagged `[inferred]` where uncertain
-6. **Success criteria** - How to verify the work is done
-7. **Next step** - What happens after this task completes
+4. **Known problems** - Identified issues, what to watch for, and risks
+5. **Assumptions documented** - Assumptions and evidence, tagged `[inferred]` when uncertain
+6. **Success criteria** - How to verify completion
+7. **Next step** - What happens after completion
 
-Every handoff ends with: "If anything is unclear or ambiguous, ask before proceeding."
+Keep values concise: reference paths, outputs, and decisions instead of copying history; include material information only; write `none` when inapplicable.
+
+Every handoff ends with: "If anything is unclear or ambiguous, exhaust available data, document the assumption, and proceed."

package/skills/iteration-limits/SKILL.md

@@ -12,8 +12,10 @@ description: >-
 
 # Iteration Limits
 
-When delegating work in a loop, always define:
+The universal bounded-autonomy contract owns repair budgets and progress-sensitive stopping. This skill is only a concise projection:
 
-1. **Verifiable Termination Condition** - A concrete, measurable state that stops the loop
-2. **Max-N Hard Limit** - Usually 3-5 attempts before escalation
-3. **Escalation Format** - Report: Tried X, Y, Z. Blocked by [cause]. Need [input] to proceed.
+- Define a **Verifiable Termination Condition** before looping.
+- Count every attempt against the applicable hard limit; default repair budget is 3 rounds and may extend one round at a time to 5 only with observable progress.
+- Stop on non-progress, safety ambiguity, or unresolved review floors. Escalate: `Tried X, Y, Z. Blocked by [cause]. Need [input] to proceed.`
+- Declare and decrement finite route and child-task budgets before dispatch; never silently reset them.
+- Empty or blocked output is non-progress: allow at most one changed-brief recovery, then trip the circuit breaker and escalate with the structured delta.