Execution workflow

The core SOP owns one sequence: Scope → Understand → Produce → Verify → Deliver. Skills supply mechanics and criteria without introducing nested phase graphs.

Repository work carries the same assessment duties into diagnosis, implementation, and review. During Understand, resolve the worktree's issue when applicable and read its complete body and discussion through k-github context intake. Follow linked discussions only to settle named material questions, reuse complete artifacts, and distinguish discussion claims from established behavior. Issue-only work needs no PR or review workflow.

The shared assessment has four components: intent intake, impact, cause classification, and release targets. Before choosing any change not proven light-path, establish affected callers, consumers, invariants, and the co-edit set: SCSI when the repo is indexed, otherwise local rg, confirmed against local code. Impact covers non-code artifacts too (config, templates, generated outputs, docs, completions, instruction text), and the spec packet carries the result as its impact map. Failure assessment distinguishes product, test, infrastructure, mixed, or unresolved causes. Release-relevant work checks branch applicability through verified repository policy and domain overlays; target selection does not authorize labels, publication, or backport execution.

The existing topic and acceptance plan retain evidence or an applicability reason for context, impact, cause, and release targeting. Final Verify checks those conclusions against the integrated change and reuses valid evidence. Mechanical work does not acquire unrelated investigations, and missing material evidence remains explicit. These are instruction contracts; source checks and rendered-content parity do not prove that every future model execution will comply.

The strong root keeps requirements, decisions, dependencies, compact results, and open questions. Substantial research stays strong and isolated; substantive settled implementation uses its cheaper category. Deterministic operations run directly without an LLM. Explicit no-delegation sessions stay inline.

Produce includes tests/docs, generation, integration, and formatting. Workers do not run private QA or claim green. Final Verify freezes the candidate, deduplicates checks by snapshot/environment/input, and retains strong review and adversarial lenses for deep/high-risk work, assigning distinct questions within that same stage. A failed required check blocks dependent actions while the root diagnoses and repairs within existing authority under SOP §3.5. Each repair records its causal evidence and affected checks; the new candidate receives failed and affected checks, while valid evidence is retained. Missing authority, user-only decisions, external blockers, exhausted progress, and explicit user limits stop the affected work. Independent authorized actions continue when their own preconditions hold. External CI status is assessed under the review policy, not treated as a failed local implementation attempt.

The SOP owns continuing authorization (§3.8) and scoped recovery (§3.5). A correction steers an active authorized task; it does not cancel the task or require the user to repeat the action. Authorization, destructive-target/ownership/secret checks, and publication approval stay at the action. Readback confirms an authorized transaction; it does not reopen general review. Existing topic storage holds the compact handoff and terminal packet IDs. Never relaunch an active/completed packet after compaction or let late events overwrite its result.

Source: home/readonly_AGENTS.md §§3.1–3.8; see staged workflows.