fix: restore green CI on main (runtime prune regression + non-hermetic CLI color tests)

[Astro-Han]

Summary

CI on main has been red since #1066/#986 landed. Two independent breakages were masking each other — the runtime failure halted the sequential workspace chain before the CLI suite ran, so the CLI failure only surfaced once the runtime one was fixed. Neither fix can go CI-green alone, so both land here as two independently revertable commits.

1. fix(runtime): mid-turn capacity prune regression (#986)

#986 changed collectPrunablePrepareStepToolCallIds to unconditionally exclude the newest completed step from active tool-result pruning, so a freshly fetched result stays raw for one request. That default is right for the proactive token-saving path, but applied unconditionally it broke three pre-existing reviewed invariants that all require pruning the newest step when mid-turn capacity compaction is active:

• the final-payload verdict must be able to rescue an oversized newest result to a placeholder instead of declaring context_budget_exhausted (mid-turn review finding C)
• capacity/recovery rebuilds re-materialize raw bodies from the ledger, and the prune must re-archive them (capacity-replacement re-convergence)
• an actively pruned tool result must stay a placeholder in the overflow retry request (overflow review round-3 P1)

The fix makes the newest-step exclusion conditional: the prune covers every completed step exactly when mid-turn capacity compaction is wired (midTurnState !== undefined), keeping #986's keep-newest-raw default for every other configuration. #986's semantic/attention compaction feature and its new tests are untouched; no test expectations changed. Isolation evidence: the two failing test files were not modified by #986, steps.slice(0, -1) was the only behavioral change on this path, and toggling that condition alone flips all 5 failures. #986's own newest-kept-raw tests only cover configurations without mid-turn capacity, which is why the conditional satisfies both contracts.

2. test(cli): non-hermetic ANSI color assertions (#1064/#1066)

tui-ansi.ts detects color capability from TERM/COLORTERM at module load and caches it. The pi-transcript and pi-tui-runner ANSI assertions never pinned the level, so they inherited ambient terminal capability: truecolor locally (macOS shells set COLORTERM=truecolor even with piped stdout), level 0 on Actions runners (no TERM/COLORTERM), where every color function is a no-op and the color assertions fail deterministically. The fix pins level 3 in both test files via the existing _setColorLevelForTesting seam, matching tui-ansi.test.ts's convention. Product detection is untouched and no assertion is weakened.

Verification

• packages/runtimenpm test: 1963 pass, 0 fail, 7 skipped (was 5 fail); npm run typecheck clean
• packages/clinpm test: 393 pass, 0 fail; npm run typecheck clean
• CLI cluster under the reproducing condition: env -u COLORTERM TERM=dumb CI=true node --test → 0 fail across 10/10 iterations (pre-fix: 8 fail, proven by stashing the fix)
• Repo-root npm run test:dist under CI-like env (env -u TERM -u COLORTERM CI=true): exit 0, 0 failures across all workspaces

Root cause of the masking

Runs 29477460801/29478404301 "passed" the CLI suite only because test:dist's sequential && chain halted at the runtime workspace; grep for the CLI suite names in those logs returns nothing. Every CI run that actually reached packages/cli since #1066 failed the color cluster.

[Astro-Han]

Summary

CI on main has been red since #1066/#986 landed. Two independent breakages were masking each other — the runtime failure halted the sequential workspace chain before the CLI suite ran, so the CLI failure only surfaced once the runtime one was fixed. Neither fix can go CI-green alone, so both land here as two independently revertable commits.

1. fix(runtime): mid-turn capacity prune regression (#986)

#986 changed collectPrunablePrepareStepToolCallIds to unconditionally exclude the newest completed step from active tool-result pruning, so a freshly fetched result stays raw for one request. That default is right for the proactive token-saving path, but applied unconditionally it broke three pre-existing reviewed invariants that all require pruning the newest step when mid-turn capacity compaction is active:

• the final-payload verdict must be able to rescue an oversized newest result to a placeholder instead of declaring context_budget_exhausted (mid-turn review finding C)
• capacity/recovery rebuilds re-materialize raw bodies from the ledger, and the prune must re-archive them (capacity-replacement re-convergence)
• an actively pruned tool result must stay a placeholder in the overflow retry request (overflow review round-3 P1)

The fix makes the newest-step exclusion conditional: the prune covers every completed step exactly when mid-turn capacity compaction is wired (midTurnState !== undefined), keeping #986's keep-newest-raw default for every other configuration. #986's semantic/attention compaction feature and its new tests are untouched; no test expectations changed. Isolation evidence: the two failing test files were not modified by #986, steps.slice(0, -1) was the only behavioral change on this path, and toggling that condition alone flips all 5 failures. #986's own newest-kept-raw tests only cover configurations without mid-turn capacity, which is why the conditional satisfies both contracts.

2. test(cli): non-hermetic ANSI color assertions (#1064/#1066)

tui-ansi.ts detects color capability from TERM/COLORTERM at module load and caches it. The pi-transcript and pi-tui-runner ANSI assertions never pinned the level, so they inherited ambient terminal capability: truecolor locally (macOS shells set COLORTERM=truecolor even with piped stdout), level 0 on Actions runners (no TERM/COLORTERM), where every color function is a no-op and the color assertions fail deterministically. The fix pins level 3 in both test files via the existing _setColorLevelForTesting seam, matching tui-ansi.test.ts's convention. Product detection is untouched and no assertion is weakened.

Verification

• packages/runtimenpm test: 1963 pass, 0 fail, 7 skipped (was 5 fail); npm run typecheck clean
• packages/clinpm test: 393 pass, 0 fail; npm run typecheck clean
• CLI cluster under the reproducing condition: env -u COLORTERM TERM=dumb CI=true node --test → 0 fail across 10/10 iterations (pre-fix: 8 fail, proven by stashing the fix)
• Repo-root npm run test:dist under CI-like env (env -u TERM -u COLORTERM CI=true): exit 0, 0 failures across all workspaces

Root cause of the masking

Runs 29477460801/29478404301 "passed" the CLI suite only because test:dist's sequential && chain halted at the runtime workspace; grep for the CLI suite names in those logs returns nothing. Every CI run that actually reached packages/cli since #1066 failed the color cluster.

[Astro-Han]

Summary

CI on main has been red since #1066/#986 landed. Two independent breakages were masking each other — the runtime failure halted the sequential workspace chain before the CLI suite ran, so the CLI failure only surfaced once the runtime one was fixed. Neither fix can go CI-green alone, so both land here as two independently revertable commits.

1. fix(runtime): mid-turn capacity prune regression (#986)

#986 changed collectPrunablePrepareStepToolCallIds to unconditionally exclude the newest completed step from active tool-result pruning, so a freshly fetched result stays raw for one request. That default is right for the proactive token-saving path, but applied unconditionally it broke three pre-existing reviewed invariants that all require pruning the newest step when mid-turn capacity compaction is active:

• the final-payload verdict must be able to rescue an oversized newest result to a placeholder instead of declaring context_budget_exhausted (mid-turn review finding C)
• capacity/recovery rebuilds re-materialize raw bodies from the ledger, and the prune must re-archive them (capacity-replacement re-convergence)
• an actively pruned tool result must stay a placeholder in the overflow retry request (overflow review round-3 P1)

The fix makes the newest-step exclusion conditional: the prune covers every completed step exactly when mid-turn capacity compaction is wired (midTurnState !== undefined), keeping #986's keep-newest-raw default for every other configuration. #986's semantic/attention compaction feature and its new tests are untouched; no test expectations changed. Isolation evidence: the two failing test files were not modified by #986, steps.slice(0, -1) was the only behavioral change on this path, and toggling that condition alone flips all 5 failures. #986's own newest-kept-raw tests only cover configurations without mid-turn capacity, which is why the conditional satisfies both contracts.

2. test(cli): non-hermetic ANSI color assertions (#1064/#1066)

tui-ansi.ts detects color capability from TERM/COLORTERM at module load and caches it. The pi-transcript and pi-tui-runner ANSI assertions never pinned the level, so they inherited ambient terminal capability: truecolor locally (macOS shells set COLORTERM=truecolor even with piped stdout), level 0 on Actions runners (no TERM/COLORTERM), where every color function is a no-op and the color assertions fail deterministically. The fix pins level 3 in both test files via the existing _setColorLevelForTesting seam, matching tui-ansi.test.ts's convention. Product detection is untouched and no assertion is weakened.

Verification

• packages/runtimenpm test: 1963 pass, 0 fail, 7 skipped (was 5 fail); npm run typecheck clean
• packages/clinpm test: 393 pass, 0 fail; npm run typecheck clean
• CLI cluster under the reproducing condition: env -u COLORTERM TERM=dumb CI=true node --test → 0 fail across 10/10 iterations (pre-fix: 8 fail, proven by stashing the fix)
• Repo-root npm run test:dist under CI-like env (env -u TERM -u COLORTERM CI=true): exit 0, 0 failures across all workspaces

Root cause of the masking

Runs 29477460801/29478404301 "passed" the CLI suite only because test:dist's sequential && chain halted at the runtime workspace; grep for the CLI suite names in those logs returns nothing. Every CI run that actually reached packages/cli since #1066 failed the color cluster.

[Astro-Han]

Summary

CI on main has been red since #1066/#986 landed. Two independent breakages were masking each other — the runtime failure halted the sequential workspace chain before the CLI suite ran, so the CLI failure only surfaced once the runtime one was fixed. Neither fix can go CI-green alone, so both land here as two independently revertable commits.

1. fix(runtime): mid-turn capacity prune regression (#986)

#986 changed collectPrunablePrepareStepToolCallIds to unconditionally exclude the newest completed step from active tool-result pruning, so a freshly fetched result stays raw for one request. That default is right for the proactive token-saving path, but applied unconditionally it broke three pre-existing reviewed invariants that all require pruning the newest step when mid-turn capacity compaction is active:

• the final-payload verdict must be able to rescue an oversized newest result to a placeholder instead of declaring context_budget_exhausted (mid-turn review finding C)
• capacity/recovery rebuilds re-materialize raw bodies from the ledger, and the prune must re-archive them (capacity-replacement re-convergence)
• an actively pruned tool result must stay a placeholder in the overflow retry request (overflow review round-3 P1)

The fix makes the newest-step exclusion conditional: the prune covers every completed step exactly when mid-turn capacity compaction is wired (midTurnState !== undefined), keeping #986's keep-newest-raw default for every other configuration. #986's semantic/attention compaction feature and its new tests are untouched; no test expectations changed. Isolation evidence: the two failing test files were not modified by #986, steps.slice(0, -1) was the only behavioral change on this path, and toggling that condition alone flips all 5 failures. #986's own newest-kept-raw tests only cover configurations without mid-turn capacity, which is why the conditional satisfies both contracts.

2. test(cli): non-hermetic ANSI color assertions (#1064/#1066)

tui-ansi.ts detects color capability from TERM/COLORTERM at module load and caches it. The pi-transcript and pi-tui-runner ANSI assertions never pinned the level, so they inherited ambient terminal capability: truecolor locally (macOS shells set COLORTERM=truecolor even with piped stdout), level 0 on Actions runners (no TERM/COLORTERM), where every color function is a no-op and the color assertions fail deterministically. The fix pins level 3 in both test files via the existing _setColorLevelForTesting seam, matching tui-ansi.test.ts's convention. Product detection is untouched and no assertion is weakened.

Verification

• packages/runtimenpm test: 1963 pass, 0 fail, 7 skipped (was 5 fail); npm run typecheck clean
• packages/clinpm test: 393 pass, 0 fail; npm run typecheck clean
• CLI cluster under the reproducing condition: env -u COLORTERM TERM=dumb CI=true node --test → 0 fail across 10/10 iterations (pre-fix: 8 fail, proven by stashing the fix)
• Repo-root npm run test:dist under CI-like env (env -u TERM -u COLORTERM CI=true): exit 0, 0 failures across all workspaces

Root cause of the masking

Runs 29477460801/29478404301 "passed" the CLI suite only because test:dist's sequential && chain halted at the runtime workspace; grep for the CLI suite names in those logs returns nothing. Every CI run that actually reached packages/cli since #1066 failed the color cluster.

[Astro-Han]

Summary

CI on main has been red since #1066/#986 landed. Two independent breakages were masking each other — the runtime failure halted the sequential workspace chain before the CLI suite ran, so the CLI failure only surfaced once the runtime one was fixed. Neither fix can go CI-green alone, so both land here as two independently revertable commits.

1. fix(runtime): mid-turn capacity prune regression (#986)

#986 changed collectPrunablePrepareStepToolCallIds to unconditionally exclude the newest completed step from active tool-result pruning, so a freshly fetched result stays raw for one request. That default is right for the proactive token-saving path, but applied unconditionally it broke three pre-existing reviewed invariants that all require pruning the newest step when mid-turn capacity compaction is active:

• the final-payload verdict must be able to rescue an oversized newest result to a placeholder instead of declaring context_budget_exhausted (mid-turn review finding C)
• capacity/recovery rebuilds re-materialize raw bodies from the ledger, and the prune must re-archive them (capacity-replacement re-convergence)
• an actively pruned tool result must stay a placeholder in the overflow retry request (overflow review round-3 P1)

The fix makes the newest-step exclusion conditional: the prune covers every completed step exactly when mid-turn capacity compaction is wired (midTurnState !== undefined), keeping #986's keep-newest-raw default for every other configuration. #986's semantic/attention compaction feature and its new tests are untouched; no test expectations changed. Isolation evidence: the two failing test files were not modified by #986, steps.slice(0, -1) was the only behavioral change on this path, and toggling that condition alone flips all 5 failures. #986's own newest-kept-raw tests only cover configurations without mid-turn capacity, which is why the conditional satisfies both contracts.

2. test(cli): non-hermetic ANSI color assertions (#1064/#1066)

tui-ansi.ts detects color capability from TERM/COLORTERM at module load and caches it. The pi-transcript and pi-tui-runner ANSI assertions never pinned the level, so they inherited ambient terminal capability: truecolor locally (macOS shells set COLORTERM=truecolor even with piped stdout), level 0 on Actions runners (no TERM/COLORTERM), where every color function is a no-op and the color assertions fail deterministically. The fix pins level 3 in both test files via the existing _setColorLevelForTesting seam, matching tui-ansi.test.ts's convention. Product detection is untouched and no assertion is weakened.

Verification

• packages/runtimenpm test: 1963 pass, 0 fail, 7 skipped (was 5 fail); npm run typecheck clean
• packages/clinpm test: 393 pass, 0 fail; npm run typecheck clean
• CLI cluster under the reproducing condition: env -u COLORTERM TERM=dumb CI=true node --test → 0 fail across 10/10 iterations (pre-fix: 8 fail, proven by stashing the fix)
• Repo-root npm run test:dist under CI-like env (env -u TERM -u COLORTERM CI=true): exit 0, 0 failures across all workspaces

Root cause of the masking

Runs 29477460801/29478404301 "passed" the CLI suite only because test:dist's sequential && chain halted at the runtime workspace; grep for the CLI suite names in those logs returns nothing. Every CI run that actually reached packages/cli since #1066 failed the color cluster.

[Astro-Han]

Summary

CI on main has been red since #1066/#986 landed. Two independent breakages were masking each other — the runtime failure halted the sequential workspace chain before the CLI suite ran, so the CLI failure only surfaced once the runtime one was fixed. Neither fix can go CI-green alone, so both land here as two independently revertable commits.

1. fix(runtime): mid-turn capacity prune regression (#986)

#986 changed collectPrunablePrepareStepToolCallIds to unconditionally exclude the newest completed step from active tool-result pruning, so a freshly fetched result stays raw for one request. That default is right for the proactive token-saving path, but applied unconditionally it broke three pre-existing reviewed invariants that all require pruning the newest step when mid-turn capacity compaction is active:

• the final-payload verdict must be able to rescue an oversized newest result to a placeholder instead of declaring context_budget_exhausted (mid-turn review finding C)
• capacity/recovery rebuilds re-materialize raw bodies from the ledger, and the prune must re-archive them (capacity-replacement re-convergence)
• an actively pruned tool result must stay a placeholder in the overflow retry request (overflow review round-3 P1)

The fix makes the newest-step exclusion conditional: the prune covers every completed step exactly when mid-turn capacity compaction is wired (midTurnState !== undefined), keeping #986's keep-newest-raw default for every other configuration. #986's semantic/attention compaction feature and its new tests are untouched; no test expectations changed. Isolation evidence: the two failing test files were not modified by #986, steps.slice(0, -1) was the only behavioral change on this path, and toggling that condition alone flips all 5 failures. #986's own newest-kept-raw tests only cover configurations without mid-turn capacity, which is why the conditional satisfies both contracts.

2. test(cli): non-hermetic ANSI color assertions (#1064/#1066)

tui-ansi.ts detects color capability from TERM/COLORTERM at module load and caches it. The pi-transcript and pi-tui-runner ANSI assertions never pinned the level, so they inherited ambient terminal capability: truecolor locally (macOS shells set COLORTERM=truecolor even with piped stdout), level 0 on Actions runners (no TERM/COLORTERM), where every color function is a no-op and the color assertions fail deterministically. The fix pins level 3 in both test files via the existing _setColorLevelForTesting seam, matching tui-ansi.test.ts's convention. Product detection is untouched and no assertion is weakened.

Verification

• packages/runtimenpm test: 1963 pass, 0 fail, 7 skipped (was 5 fail); npm run typecheck clean
• packages/clinpm test: 393 pass, 0 fail; npm run typecheck clean
• CLI cluster under the reproducing condition: env -u COLORTERM TERM=dumb CI=true node --test → 0 fail across 10/10 iterations (pre-fix: 8 fail, proven by stashing the fix)
• Repo-root npm run test:dist under CI-like env (env -u TERM -u COLORTERM CI=true): exit 0, 0 failures across all workspaces

Root cause of the masking

Runs 29477460801/29478404301 "passed" the CLI suite only because test:dist's sequential && chain halted at the runtime workspace; grep for the CLI suite names in those logs returns nothing. Every CI run that actually reached packages/cli since #1066 failed the color cluster.

[Astro-Han]

Summary

CI on main has been red since #1066/#986 landed. Two independent breakages were masking each other — the runtime failure halted the sequential workspace chain before the CLI suite ran, so the CLI failure only surfaced once the runtime one was fixed. Neither fix can go CI-green alone, so both land here as two independently revertable commits.

1. fix(runtime): mid-turn capacity prune regression (#986)

#986 changed collectPrunablePrepareStepToolCallIds to unconditionally exclude the newest completed step from active tool-result pruning, so a freshly fetched result stays raw for one request. That default is right for the proactive token-saving path, but applied unconditionally it broke three pre-existing reviewed invariants that all require pruning the newest step when mid-turn capacity compaction is active:

• the final-payload verdict must be able to rescue an oversized newest result to a placeholder instead of declaring context_budget_exhausted (mid-turn review finding C)
• capacity/recovery rebuilds re-materialize raw bodies from the ledger, and the prune must re-archive them (capacity-replacement re-convergence)
• an actively pruned tool result must stay a placeholder in the overflow retry request (overflow review round-3 P1)

The fix makes the newest-step exclusion conditional: the prune covers every completed step exactly when mid-turn capacity compaction is wired (midTurnState !== undefined), keeping #986's keep-newest-raw default for every other configuration. #986's semantic/attention compaction feature and its new tests are untouched; no test expectations changed. Isolation evidence: the two failing test files were not modified by #986, steps.slice(0, -1) was the only behavioral change on this path, and toggling that condition alone flips all 5 failures. #986's own newest-kept-raw tests only cover configurations without mid-turn capacity, which is why the conditional satisfies both contracts.

2. test(cli): non-hermetic ANSI color assertions (#1064/#1066)

tui-ansi.ts detects color capability from TERM/COLORTERM at module load and caches it. The pi-transcript and pi-tui-runner ANSI assertions never pinned the level, so they inherited ambient terminal capability: truecolor locally (macOS shells set COLORTERM=truecolor even with piped stdout), level 0 on Actions runners (no TERM/COLORTERM), where every color function is a no-op and the color assertions fail deterministically. The fix pins level 3 in both test files via the existing _setColorLevelForTesting seam, matching tui-ansi.test.ts's convention. Product detection is untouched and no assertion is weakened.

Verification

• packages/runtimenpm test: 1963 pass, 0 fail, 7 skipped (was 5 fail); npm run typecheck clean
• packages/clinpm test: 393 pass, 0 fail; npm run typecheck clean
• CLI cluster under the reproducing condition: env -u COLORTERM TERM=dumb CI=true node --test → 0 fail across 10/10 iterations (pre-fix: 8 fail, proven by stashing the fix)
• Repo-root npm run test:dist under CI-like env (env -u TERM -u COLORTERM CI=true): exit 0, 0 failures across all workspaces

Root cause of the masking

Runs 29477460801/29478404301 "passed" the CLI suite only because test:dist's sequential && chain halted at the runtime workspace; grep for the CLI suite names in those logs returns nothing. Every CI run that actually reached packages/cli since #1066 failed the color cluster.

[Astro-Han]

Summary

CI on main has been red since #1066/#986 landed. Two independent breakages were masking each other — the runtime failure halted the sequential workspace chain before the CLI suite ran, so the CLI failure only surfaced once the runtime one was fixed. Neither fix can go CI-green alone, so both land here as two independently revertable commits.

1. fix(runtime): mid-turn capacity prune regression (#986)

#986 changed collectPrunablePrepareStepToolCallIds to unconditionally exclude the newest completed step from active tool-result pruning, so a freshly fetched result stays raw for one request. That default is right for the proactive token-saving path, but applied unconditionally it broke three pre-existing reviewed invariants that all require pruning the newest step when mid-turn capacity compaction is active:

• the final-payload verdict must be able to rescue an oversized newest result to a placeholder instead of declaring context_budget_exhausted (mid-turn review finding C)
• capacity/recovery rebuilds re-materialize raw bodies from the ledger, and the prune must re-archive them (capacity-replacement re-convergence)
• an actively pruned tool result must stay a placeholder in the overflow retry request (overflow review round-3 P1)

The fix makes the newest-step exclusion conditional: the prune covers every completed step exactly when mid-turn capacity compaction is wired (midTurnState !== undefined), keeping #986's keep-newest-raw default for every other configuration. #986's semantic/attention compaction feature and its new tests are untouched; no test expectations changed. Isolation evidence: the two failing test files were not modified by #986, steps.slice(0, -1) was the only behavioral change on this path, and toggling that condition alone flips all 5 failures. #986's own newest-kept-raw tests only cover configurations without mid-turn capacity, which is why the conditional satisfies both contracts.

2. test(cli): non-hermetic ANSI color assertions (#1064/#1066)

tui-ansi.ts detects color capability from TERM/COLORTERM at module load and caches it. The pi-transcript and pi-tui-runner ANSI assertions never pinned the level, so they inherited ambient terminal capability: truecolor locally (macOS shells set COLORTERM=truecolor even with piped stdout), level 0 on Actions runners (no TERM/COLORTERM), where every color function is a no-op and the color assertions fail deterministically. The fix pins level 3 in both test files via the existing _setColorLevelForTesting seam, matching tui-ansi.test.ts's convention. Product detection is untouched and no assertion is weakened.

Verification

• packages/runtimenpm test: 1963 pass, 0 fail, 7 skipped (was 5 fail); npm run typecheck clean
• packages/clinpm test: 393 pass, 0 fail; npm run typecheck clean
• CLI cluster under the reproducing condition: env -u COLORTERM TERM=dumb CI=true node --test → 0 fail across 10/10 iterations (pre-fix: 8 fail, proven by stashing the fix)
• Repo-root npm run test:dist under CI-like env (env -u TERM -u COLORTERM CI=true): exit 0, 0 failures across all workspaces

Root cause of the masking

Runs 29477460801/29478404301 "passed" the CLI suite only because test:dist's sequential && chain halted at the runtime workspace; grep for the CLI suite names in those logs returns nothing. Every CI run that actually reached packages/cli since #1066 failed the color cluster.