feat: add declarative review loops

[apresmoi]

Summary

• Add declarative Loop packages with direct execution plus built-in review, gate, and branch workflows, frozen per-item assignments, bounded budgets, trusted checks, recoverable Runs, and CLI-owned atomic completion.
• Keep provider execution host-native: Burnlist prepares the current node and accepts a bounded semantic result through the normal next -> execute -> submit flow; native subagents or external providers remain host choices rather than embedded runtime adapters.
• Add opt-in Claude and Codex hooks that correlate agent lifecycle, tool activity, changed paths, timing, model, effort, and available usage with the active Run while keeping observations separate from canonical transitions.
• Add bounded local model/effort-aware time and token forecasts with explicit confidence and provenance. Missing usage and pricing remain unavailable rather than inferred.
• Add truthful per-item PENDING, ACTIVE, WAITING, BLOCKED, and COMPLETED states plus simplified Checklist and Loop Progress views with graph state, current agent/node, checks, retries, forecasts, and progressively disclosed telemetry.
• Add burnlist recommend for advisory Loop, model class, effort, P0-P4 review policy, metric, and coarse-to-fine sequencing guidance.
• Make lifecycle, registration, Loop, and Oven commands print useful next actions and canonical dashboard URLs.
• Update the skill, README, built-in Loop/Oven instructions, CLI help, and the complete public website documentation for the operational UX.

Validation

• npm run verify - 923 core assertions plus all serial and dashboard suites
• Dashboard TypeScript suite - 223/223 after syncing latest main
• npm run verify:package - 222 packaged files
• Website Astro/Pagefind build - 18 pages
• Website internal link and anchor audit - 16 documentation pages
• Focused operational guidance, recommendation, state, hook, event, and help tests - 62/62
• npm run build:dashboard
• git diff --check
• Two clean-room Loop trials with fresh workers and no Burnlist worker skill: host-visible actions reduced from 7 to 5 and correlated hook activity remained complete

Architecture

• .loop packages remain declarative and provider-neutral. The compiler proves grammar and topology; setup/preflight resolves trusted capabilities; runtime enforces current claims, candidate boundaries, budgets, evidence, and legal transitions.
• The host chooses and invokes native or CLI agents. Burnlist never installs, authenticates, embeds, or launches provider runtimes.
• Hooks and the event feed are observational. They may update read-only activity projections but cannot report semantic outcomes, select graph edges, or mutate Burnlist state.
• Canonical Run state is an append-only hash-chained journal. The CLI owns lifecycle locks, item completion, receipts, and atomic Burnlist mutations.
• Ovens remain declarative, non-executable read-only views. The dashboard remains an observer and refetches canonical projections after invalidation events.
• Root runtime dependencies remain zero and new authored files stay within the repository line limit.

Built-in choices

• No Loop assignment: direct implementation and ordinary Burn.
• loop:builtin:gate: implement, trusted check, Burn.
• loop:builtin:review: implement, trusted check, independent review, convergence gate, Burn.
• loop:builtin:branch: plan, host-owned worker slices, merge, trusted check, independent review, Burn.

Notes

• Normal host execution is intentionally small: request the next prepared node, execute it through an available native or external agent, then submit one legal semantic result. Lower-level claim/report commands remain for recovery and diagnostics.
• Reviewer filesystem restrictions are supervised rather than an OS sandbox. Docker isolation, nested Runs, automatic provider selection, background execution, and generic runtime plugins remain outside this stage.
• Forecasts are local estimates learned only from truthful completed observations; they are not billing claims.
• The operational-usability implementation and documentation are committed. Final Burnlist close remains gated on user visual approval of the simplified Loop Progress view.