automaton/tasks/fix-context-sizing/BUG_REPORT.md

Bug Report: fix-context-sizing

Status: NO_BUGS_FOUND

Method

Static re-read of vram_detect.py changes against the SPEC and against pre-existing behaviors. Focused on:

1. Backward compatibility: non-loop callers must keep prior behavior.
2. Override authority: _parse_config_model's override flow must still be authoritative in loop mode.
3. Negative-budget propagation: max_peak_kb can now be negative when overhead exceeds budget — does any consumer read it without wrapping in max(0, ...)?
4. Exit codes: --loop-mode refuse paths must exit 2, not 0.

Findings

F1. Non-loop behavior preserved — CONFIRMED SAFE

Pre-existing CLI callers (vram_detect.py without --loop-mode) and dashboard invocations are unaffected. Warning lines are emitted on degraded conditions but exit code stays 0. Verified by test_non_loop_mode_does_not_refuse_unknown_model.

F2. Override authority — CONFIRMED SAFE

In detect_model_context, the if override_context and override_context != "auto" branch (line 343-345) returns the override before reaching the fallback-return-zero path. So when a user has set Override context window in config.md, detect_model_context returns a positive value and the --loop-mode unknown-model refuse never fires. Matches D13 spec.

F3. Negative max_peak_kb propagation — LOW RISK, OUT OF SCOPE

recommend_context now returns a negative max_peak_kb when overhead_tokens > recommended_kb. No current consumer reads it without arithmetic. The dashboard (automaton/dashboard/__main__.py) computes its own derived numbers and does not display this value directly. The loop runner (task add-loop-runner) must max(0, available_context_kb) before scheduling; that's the runner's obligation, not this task's. Acceptable.

F4. Exit code correctness — CONFIRMED

--loop-mode refuse paths call return 2. Verified directly: python3 vram_detect.py --model zzz --loop-mode; echo $? returns 2. Support: test_loop_mode_refuses_unknown_model writes a regression guard.

Bugs Found

None.

Out of Scope (for downstream tasks)

• Loop runner's max(0, available_context_kb) wrap (task 3 add-loop-runner)
• Dashboard showing the new loop_mode_eligible field (v1.1 dashboard panel)
• Tier 2 cleanup: last-read-sha drift detection, etc.