From a806a9a62e914c0c7bff826a38f44e1f8ca43d73 Mon Sep 17 00:00:00 2001 From: Eric Rakestraw Date: Sat, 7 Nov 2026 15:33:51 +0000 Subject: [PATCH] Clarify continuous execution of the remediation plan --- docs/roadmap/implementation.md | 48 +++++++++++++++++++++++++++------- 1 file changed, 38 insertions(+), 10 deletions(-) diff --git a/docs/roadmap/implementation.md b/docs/roadmap/implementation.md index 57acc81..8483bea 100644 --- a/docs/roadmap/implementation.md +++ b/docs/roadmap/implementation.md @@ -11,12 +11,26 @@ its original audit links own defect evidence. The ## Instructions for the implementing agent -Execute Stage 1 through Stage 23 in order as one sprint. Each stage is sized as -one bounded Luna assignment; stages 11–12 split the cross-module diagnostic -change. Intermediate stages need not compile independently. If a check depends -on a later stage, record it as pending and run it when its prerequisites exist; -do not add temporary compatibility machinery to make an intermediate stage green. -The final source must be coherent and validated through the aligned workspace. +Once the user approves this sprint, execute Stage 1 through Stage 23 in order +under that approval. Stages are bounded work units within one continuous run, +not separate prompts, approval gates, or handoffs. Proceed to the next stage +without asking for confirmation after a stage, test run, or local commit. +Keep progress updates concise and report the assembled result after Stage 23. +Stages 11–12 split the cross-module diagnostic change for implementation clarity. + +Intermediate stages need not compile independently. If a check depends on a later +stage, record it as pending, continue in order, and run it when its prerequisites +exist. Stage completion criteria describe what must eventually be evidenced; +they do not require stopping for dependent verification before later work can +proceed. Do not add temporary compatibility machinery to make an intermediate +stage green. The final source must be coherent and validated through the aligned +workspace. + +Resolve ordinary implementation choices and fix failures within the approved +scope without another design round. A real contradiction in the selected target +or an unavoidable external blocker may require input; first investigate in-scope +remedies and complete remaining independent work. Do not silently change the +target, waive a relevant failing check, or claim blocked work is complete. Read [development guidance](../development.md) and the applicable [agent](../policy/agents.md), [architecture](../policy/architecture.md), @@ -46,7 +60,9 @@ Record stage completion and actual verification here. Add completion evidence to the corresponding catalog finding only after its entire remedy is implemented and verified. F21 spans stages 11–12; F24 spans stages 3, 13, and 20. Preserve the original audits and accepted decisions. Commit completed nonempty work units with -plain English messages under repository policy; do not publish or push. +plain English messages under repository policy; a commit is not a user-review +checkpoint. Related stages may form one validated commit when needed. Do not +publish or push. ## Validation conventions @@ -78,6 +94,16 @@ module files may use explicit local replacements as additional boundary evidence label them as local-source checks. Once appropriate releases exist, dependency alignment and independent validation follow the [release procedure](../release.md) as separate work. Publication is neither authorized nor a prerequisite here. +Do not wait for those releases or request publication to advance or finish this +source sprint. Record the known independent-module limitation and continue. + +Unavailable optional shell prerequisites or race-detector support are evidence +limitations, not stage gates. Run the available checks, record what could not +run, and continue. Deterministic regression checks remain required; failures in +supported checks require investigation and in-scope correction. Revisit checks +deferred for internal dependencies before the final report. A genuine inability +to run required final verification must be reported as incomplete verification, +not converted into a passed check or a request for per-stage approval. ## Stage 1 — Retain aggregate smoke cancellation @@ -144,7 +170,8 @@ Findings: F03 and the reporter-lifecycle portion of F24. Source: `reporter.go`. presented; assert ErrReporterClosed. Check pre-cutoff accepted delivery, completion/terminal ordering and visibility, plus render/write failure evidence. Avoid sleeps and callback reentry. Run the focused reporter tests - with `-race -count=1` as well as ordinary focused checks. + with `-race -count=1` where supported, supplementing the required deterministic + acceptance/finalization regression. Record unavailable race support and proceed. 6. Document the cutoff in Reporter/AtEnd GoDoc and relevant reporting guidance. Complete F03 when acceptance cannot succeed into an abandoned batch. Keep F24 @@ -570,8 +597,9 @@ Findings: all F01–F27; no new feature work. GOTOOLCHAIN=local GOPROXY=off go test -mod=readonly ./... ./integrations/ckconfig/... ./integrations/ckprompt/... ``` - Run focused reporter race checks for the final reporting changes. Broaden or - repeat tests only for changed content, failures or unresolved concerns. + Run focused reporter race checks where supported for the final reporting + changes, recording unavailable support. Broaden or repeat tests only for + changed content, failures or unresolved concerns. 3. Run independent suites from the root and each integration directory with `GOWORK=off GOTOOLCHAIN=local GOPROXY=off go test -mod=readonly ./...` when their selected dependencies support the changes. Record exact selections.