Files

T

CI / build (push) Has been cancelled

Details

Archive completed tasks, add cleanup commands, self-documenting dashboard UI

- Archive 79 completed framework-dev tasks from tasks/ -> tasks/complete/
- status.py: add --cleanup-done and --install-cleanup-schedule commands
- Add scripts/automaton-cleanup.sh for periodic task archiving
- Dashboard: rename 'Background' tab -> 'Agent', 'Cleanup' agent -> 'Completed Task Archiver', remove redundant group headers and pill badges, dim inactive agent placeholders
- .rules.md: add Self-Documenting UI Names rule
- New tests: test_cleanup_done.py, expanded test_app.py and test_task.py

2026-06-24 22:43:33 -04:00

2.3 KiB

Raw Blame History

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:

Backward compatibility: non-loop callers must keep prior behavior.
Override authority: _parse_config_model's override flow must still be authoritative in loop mode.
Negative-budget propagation: max_peak_kb can now be negative when overhead exceeds budget — does any consumer read it without wrapping in max(0, ...)?
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.

2.3 KiB Raw Blame History