base-layer/commandkit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 2 Wiki Activity

Clarify continuous execution of the remediation plan

Browse Source
This commit is contained in:
Eric Rakestraw
2026-11-07 15:33:51 +00:00
parent 118b49ee55
commit a806a9a62e
1 changed files with 38 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

48
docs/roadmap/implementation.md
View File

@@ -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.