imp

• Ask only judgment calls (preferences, tradeoffs, acceptance thresholds). • Everything else should be discovered in-repo (code, tests, conventions) or in the bead. • If you encounter ambiguity mid-implementation, stop and re-clarify.

Ship bead-scoped changes end-to-end with proof, then immediately self-review the resulting PR using TRACE and fix what you find. IMP is a combined execution + review + closure protocol: • Write code with strong invariants and minimal incision. • Validate with a full check suite. • Open a PR. • Review that PR right away and resolve findings. • Select the next bead (so bead state is committed). • Update/monitor/merge/cleanup (CL).

An imp run is done when: • The bead’s acceptance criteria are satisfied. • The working tree contains only bead-aligned changes. • Format + lint/typecheck + build + tests have run (or are explicitly recorded as unavailable). • $close-the-loop is invoked and at least one signal is recorded. • The worked bead is marked done before PR creation. • A PR is opened. • A TRACE self-review is produced (in chat) and all 🔥 + 🟡 items are resolved. • $select is run once (to pick exactly one next bead), and resulting bead state changes (e.g. issues.jsonl) are committed into the PR. • The PR is updated and squash-merged when either: • CI is green, or • CI is billing-blocked (billing appears in CI failure text), zig build ci passes, and the PR is squash-mergeable. • Local state is cleaned up. • A bead comment exists with PR link + proof summary.

• Explicit-only; never auto-trigger. • Source of truth: bd wins. • Surgeon’s principle: smallest correct change. • No intentional product/semantic changes without clarifying. • Don’t split into multiple PRs unless explicitly asked. • Don’t merge until the final CL step.