execution

Topics in the source

• Execution Workflow
• Steps
• Step 1: Prepare
• Step 2: Implement each task — RED → GREEN → RECORD
• Step 3: Check
• Step 4: Independent review
• Step 5: Create the PR
• Abbreviation

CANARY: execution-loaded-2026-05-19-4597aff5bb98dd36 Reads status/specification.md and status/plan.md and updates the plan's task statuses as work progresses. Per-task notes go in tmp/ -notes.md (gitignored); load references/template.md when creating one. Keep the notes' Resume section (Decided / Ruled out / Next step) current after RED, after GREEN, and after each decision: it is what the session reads back after context compaction. Work through every task in the plan and on to the PR without pausing between tasks for confirmation; stop only when blocked or before a step that is hard to undo. Deliver the scope the plan asks for, and list pre-existing bugs and unrequested cleanup as follow-ups in the PR description rather than fixing them in this diff. The design is approved and the branch is created from the default branch. Where the work lives. Run git status --short and check the branch. A clean tree on the default branch (or on a finished, unrelated branch) works in place. A dirty tree, an in-flight branch the user may still be using, or a long-running process pinned to the checkout gets a worktree, because a worktree never destroys state: Run every later step from the worktree

This is an excerpt. Refer to the complete source and its current requirements.