Two follow-ups deferred out of the architecture-refactor D-series (completed in #669/#670/#671). Both are genuine improvements that were intentionally not done as part of the decomposition because they require a redesign rather than a behavior-preserving move.
1. Decompose the runImprovePreparationStage accumulator blocks
After D1c, src/commands/improve/preparation.ts holds the prep pipeline, but ~3 internal phases could not be extracted as pure moves:
- WS-2 Outcome loop, the proactive / high-salience selectors, and the replay-selection layer.
They are entangled through salienceMap — a cross-phase mutable accumulator that the salience-ranking phase, the Outcome loop, and replay-seeding all read and mutate in place. Carving any one out as a function changes behavior unless the accumulator is threaded explicitly.
Proposed work: redesign the prep stage to pass the salience accumulator (and the related pendingForgettingRefs) explicitly between phase functions (or build it in one pass and pass it read-only downstream), then extract the Outcome loop / selectors / replay as named functions. This is a behavior-changing refactor → needs its own RED characterization tests for the salience ranking + forgetting-candidate outputs first.
2. Move command-layer asset_salience / asset_outcome SQL into repositories, then widen X4
X4 (#671) shipped a narrow repository-boundary lint (scripts/lint-repository-sql.ts) guarding src/registry/** + src/workflows/runtime/**. It was deliberately not widened to the improve command layer because raw asset_salience / asset_outcome SQL still lives directly in:
src/commands/improve/salience.ts
src/commands/improve/outcome-loop.ts
src/commands/improve/homeostatic.ts
- (read-side also in
src/commands/health.ts)
Proposed work: extract src/core/state/salience-repo.ts + src/core/state/outcome-repo.ts (mirroring the D2 repo pattern), move the raw SQL behind them, then add src/commands/improve/** (or the specific files) to the X4 guard's GUARDED_PREFIXES so the boundary covers the improve layer too. The X4 meta-test already proves the guard fires, so widening is a one-line allowlist change once the SQL is relocated.
Notes
- These are independent of each other and of the merged D-series; neither is a regression.
- Separately, the
#499 health test (tests/health-command.test.ts — "legacy row with started_at==completed_at falls back…") remains an intermittent host-load flake (passes in isolation; fails only under heavy concurrent sharded load). Root cause is the documented open test-isolation issue, not the refactor.
Plan of record: docs/technical/architecture-refactor-plan.md (see the X4 row + "genuine future follow-ups" in the priming section).
Two follow-ups deferred out of the architecture-refactor D-series (completed in #669/#670/#671). Both are genuine improvements that were intentionally not done as part of the decomposition because they require a redesign rather than a behavior-preserving move.
1. Decompose the
runImprovePreparationStageaccumulator blocksAfter D1c,
src/commands/improve/preparation.tsholds the prep pipeline, but ~3 internal phases could not be extracted as pure moves:They are entangled through
salienceMap— a cross-phase mutable accumulator that the salience-ranking phase, the Outcome loop, and replay-seeding all read and mutate in place. Carving any one out as a function changes behavior unless the accumulator is threaded explicitly.Proposed work: redesign the prep stage to pass the salience accumulator (and the related
pendingForgettingRefs) explicitly between phase functions (or build it in one pass and pass it read-only downstream), then extract the Outcome loop / selectors / replay as named functions. This is a behavior-changing refactor → needs its own RED characterization tests for the salience ranking + forgetting-candidate outputs first.2. Move command-layer
asset_salience/asset_outcomeSQL into repositories, then widen X4X4 (#671) shipped a narrow repository-boundary lint (
scripts/lint-repository-sql.ts) guardingsrc/registry/**+src/workflows/runtime/**. It was deliberately not widened to the improve command layer because rawasset_salience/asset_outcomeSQL still lives directly in:src/commands/improve/salience.tssrc/commands/improve/outcome-loop.tssrc/commands/improve/homeostatic.tssrc/commands/health.ts)Proposed work: extract
src/core/state/salience-repo.ts+src/core/state/outcome-repo.ts(mirroring the D2 repo pattern), move the raw SQL behind them, then addsrc/commands/improve/**(or the specific files) to the X4 guard'sGUARDED_PREFIXESso the boundary covers the improve layer too. The X4 meta-test already proves the guard fires, so widening is a one-line allowlist change once the SQL is relocated.Notes
#499health test (tests/health-command.test.ts— "legacy row with started_at==completed_at falls back…") remains an intermittent host-load flake (passes in isolation; fails only under heavy concurrent sharded load). Root cause is the documented open test-isolation issue, not the refactor.Plan of record:
docs/technical/architecture-refactor-plan.md(see the X4 row + "genuine future follow-ups" in the priming section).