Archive completed tasks, add cleanup commands, self-documenting dashboard UI
CI / build (push) Has been cancelled
CI / build (push) Has been cancelled
- 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
This commit is contained in:
Lap Tran
@@ -1 +0,0 @@
|
||||
complete
|
||||
@@ -1,2 +0,0 @@
|
||||
research:approved|2026-06-23T01:21:33.749096+00:00|user
|
||||
code_review:approved|2026-06-23T01:30:20.274565+00:00|user
|
||||
@@ -1,35 +0,0 @@
|
||||
# Adversarial Bug Report: fix-context-sizing
|
||||
|
||||
## Status: NO_NEW_DEFECTS
|
||||
|
||||
Adversarial review applied the 5 attack vectors from `design/loops/functional.md` §6 to confirm the changes don't introduce enforcement gaps:
|
||||
A1. Concurrent state divergence
|
||||
A2. Single-session harness loops can merge 2 sessions
|
||||
A3. VM/CI environment with no GPU detection
|
||||
A4. User types "loop mode" instead of "--loop-mode"
|
||||
A5. Model auto-picks "auto" through config.md but isn't detected
|
||||
|
||||
Note: the loop system itself ( brakes, runner, verifier) is tasks 2–4. This task only ships the *foundation* the loop runner consumes. Adversarial focus is therefore: (a) has the foundation been honestly graded, (b) can it break the existing enforcement layer, (c) does it lie in a way that loops would silently accept bad budgets.
|
||||
|
||||
## Attacks
|
||||
|
||||
### A1: Concurrent state divergence
|
||||
`vram_detect.py` is read-only w.r.t. task state. No `.state` file mutation. No enforcement-layer coupling. Safe by design.
|
||||
|
||||
### A2: Single-session harness fails to detect two sessions
|
||||
Not in scope for this task. Roles and harness invocation are task 6's `templates/loops/`. This task only adds the `## Loop Role Models` documentation block to `config.md`; no logic affects session binding.
|
||||
|
||||
### A3: VM/CI environment, GPU detection returns 0
|
||||
The fallback chain in `recommend_context` already handles `gpu_vram_gb == 0` (falls through to RAM or model context). The new `--loop-mode` floor check correctly refuses when `max_peak_kb < 16_000`. Manually exercised logic with `gpu_vram_gb=0, ram_gb=8, model_context_kb=0`; `max_peak_kb` computation flows through RAM branch (8 * 750 = 6000), minus overhead, * 75% = under 16k → loop-mode refuses. Behavior correct.
|
||||
|
||||
### A4: User misspells conf
|
||||
Mangled flag is rejected by argparse; not silent. Confirmed `--help` shows the flag; argparse errors on unknown flag. Safe.
|
||||
|
||||
### A5: Model "auto" in config.md
|
||||
Existing flow already handles "auto" by returning None from `_parse_config_model` value check (line 454, 458). When user has left `Model: auto` AND no `Override context window`: `detect_model_context` proceeds to attempt API config probing and ollama probe. If both fail, returns 0, and `--loop-mode` refuses with the exact D13 message. Non-loop mode warns. Matches SPEC intent.
|
||||
|
||||
## New Defects
|
||||
None.
|
||||
|
||||
## Adversarial Verdict
|
||||
Foundation holds. All 5 attacks correctly produce refuse/warn behavior or are out-of-scope for this task. Ready to ship.
|
||||
@@ -1,32 +0,0 @@
|
||||
# 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.
|
||||
@@ -1,37 +0,0 @@
|
||||
# Code Review: fix-context-sizing
|
||||
|
||||
## Status: PASS
|
||||
|
||||
## Author
|
||||
AI assistant (per user directive "i approve all tasks. drive them to completion")
|
||||
|
||||
## Files Reviewed
|
||||
- `scripts/vram_detect.py` (350-line region) — `recommend_context` rewrite, `main()` extension with `--loop-mode`, JSON output additions
|
||||
- `config.md` — new `## Loop Role Models` section
|
||||
- `prompts/decompose.md` — 4k tier added, 16k floor `REFUSE` line added
|
||||
- `tests/test_context_sizing.py` — 15 new tests
|
||||
- `tests/test_vram_detect.py:76` — updated `test_recommend_context_api_model` to assert the corrected single-headroom contract
|
||||
|
||||
## Spec Conformance (R1–R6)
|
||||
|
||||
- R1 (single headroom): PASS — `recommend_context` returns `recommended_kb` pre-headroom, `max_peak_kb = net_kb * (100 - headroom_pct) // 100` (headroom exactly once). Confirmed by `test_recommend_context_single_headroom`.
|
||||
- R2 (no fake defaults): PASS — `else 8` / `else 6` fallbacks removed; `max(0, ...)` clamp removed. Warning emitted in non-loop mode when budget ≤ 0 or model unknown. Confirmed by `test_no_fake_defaults_when_budget_zero`, `test_no_max_zero_clamp_in_output`.
|
||||
- R3 (`--loop-mode` refuse): PASS — unknown model exits 2 ("model context window is unknown"); sub-floor budget check gated on `LOOP_MODE_CONTEXT_FLOOR_KB == 16_000`. User override is authoritative per existing `_parse_config_model` flow. Confirmed by `test_loop_mode_refuses_unknown_model`, `test_loop_mode_passes_for_known_model`.
|
||||
- R4 (JSON fields): PASS — `available_context_kb`, `loop_mode_eligible`, `loop_mode` present; `available_context_kb == max_peak_context_kb`. Confirmed by `test_json_includes_available_context_kb_and_eligible`.
|
||||
- R5 (`config.md` `## Loop Role Models`): PASS — section added verbatim with role definitions, D12/D13 references. Confirmed by `test_config_md_includes_loop_role_models_section`.
|
||||
- R6 (decompose.md 4k tier + 16k floor): PASS — `**4k VRAM**` in guidelines, `(4k VRAM)` in size targets, `≤ 16k ... REFUSE` floor line present. Confirmed by `test_decompose_md_includes_4k_tier`, `test_decompose_md_includes_16k_floor_refuse`.
|
||||
|
||||
## Test Results
|
||||
|
||||
- New tests: 15 passed
|
||||
- Full suite: 264 passed (one pre-existing test updated to match fixed contract; no regression)
|
||||
- Pre-existing self-consistency suite: 74 passed (no regression to prompt path enforcement or framework invariants)
|
||||
|
||||
## Risks and Observations
|
||||
|
||||
- One pre-existing test (`test_recommend_context_api_model`) was *asserting the bug*. Updated to assert the fixed contract. Documented inline as the reason.
|
||||
- `--loop-mode` is opt-in via CLI flag. Non-loop callers preserve prior behavior + gain a human-readable warning. Backward-compatible.
|
||||
- The override-is-authoritative path (D13) was already honored by `_parse_config_model`; no new parsing code needed.
|
||||
|
||||
## Verdict
|
||||
Ship. No defects blocking transition.
|
||||
@@ -1,27 +0,0 @@
|
||||
# Doc Review: fix-context-sizing
|
||||
|
||||
## Status: PASS
|
||||
|
||||
## Docs Updated
|
||||
1. `config.md` — added `## Loop Role Models` section between System Requirements and Framework Version.
|
||||
2. `prompts/decompose.md` — added `**4k VRAM**` row in peak-context Guideline and `(4k VRAM)` rows in Sub-Task Size Targets; added `≤ 16k VRAM: REFUSE` line as a non-negotiable floor.
|
||||
3. `tasks/fix-context-sizing/SPEC.md` SPEC.md, IMPLEMENTATION.md — present in task folder.
|
||||
4. `tests/test_context_sizing.py` — 15 new test cases.
|
||||
|
||||
## Documentation Gaps Closed
|
||||
- Loop role contract now exists in user-facing `config.md` (was previously implicit / absent).
|
||||
- `decompose.md`'s context budget guidance now exposes the 4k tier and refuses ≤16k budgets explicitly, so users decomposing tasks for small models can plan correctly.
|
||||
- `--loop-mode` CLI flag is documented in script's `--help` output.
|
||||
- JSON output schema now carries `available_context_kb` and `loop_mode_eligible` which downstream consumers (loop runner) can rely on.
|
||||
|
||||
## Gaps Remaining (out of scope — deferred to Tier 2 per D17)
|
||||
- `README.md` does not yet document `--loop-mode` in the human-facing CLI section (Tier 2 task).
|
||||
- Dashboard does not surface `loop_mode_eligible` (v1.1 panel).
|
||||
- `prompts/decompose.md` line 135 still says "If model detection fails, use 128k tokens as default" — the auto-detection flow's fallback. This is the user-facing decompose prompt's narrative; changing it would alter how decomposition agents behave in the research phase. Left intact; loop runner uses `--loop-mode` instead which *refuses* on this condition.
|
||||
|
||||
## Cross-References
|
||||
- DESIGN.md not produced — task went directly research → implement per locked plan (Tier 1 fixes don't warrant a separate design phase).
|
||||
- This DOC_REVIEW covers the doc-side of the task; referee step is final.
|
||||
|
||||
## Verdict
|
||||
Documentation is consistent with SPEC. No blocking gaps.
|
||||
@@ -1,14 +0,0 @@
|
||||
# Implementation: fix-context-sizing
|
||||
|
||||
Implements SPEC.md R1–R6. Files touched:
|
||||
|
||||
- `scripts/vram_detect.py` — R1 (double headroom), R2 (fake clamps), R3 (--loop-mode refuse), R4 (JSON fields)
|
||||
- `config.md` — R5 (`## Loop Role Models` section)
|
||||
- `prompts/decompose.md` — R6 (4k tier + 16k floor)
|
||||
- `tests/test_context_sizing.py` — new tests
|
||||
|
||||
## Approach
|
||||
|
||||
`recommend_context` rewritten so headroom is applied exactly once. `main()` reports honest numbers (no `else 8`/`else 6` fallbacks). New `--loop-mode` CLI flag refuses zero-context-unknown and sub-16k available budget; non-loop callers keep prior behavior. JSON output exposes `available_context_kb` and `loop_mode_eligible`.
|
||||
|
||||
`config.md` gets a `## Loop Role Models` section. `decompose.md`'s context-budget table grows a 4k row and an explicit `≤ 16k: refuse` floor statement.
|
||||
@@ -1,164 +0,0 @@
|
||||
# Fix Context Sizing
|
||||
|
||||
Tier 1 context-sizing fixes — the foundational layer that `add-status-brakes` and downstream loop tasks consume. Per `design/loops/technical.md` §11 and the locked Tier 1 list.
|
||||
|
||||
## Goal
|
||||
|
||||
Make the framework's context-budget reporting honest, single-headroom-applied, and machine-readable with a hard floor. Today `vram_detect.py` lies: it reports fake 8k/6k defaults when the actual budget is zero, silently applies headroom twice, and never refuses to run on an unknown model. The loop runner (task `add-loop-runner`) needs accurate, authoritative numbers — its 16k floor check (D13) is meaningless against fabricated defaults.
|
||||
|
||||
## Requirements
|
||||
|
||||
### R1. Remove double-headroom application in `recommend_context`
|
||||
|
||||
`scripts/vram_detect.py:618-656` applies headroom twice:
|
||||
|
||||
- Line 642 / 644 / 648: applies `(100 - headroom_pct) // 100` while constructing `recommended_kb` from `vram_context_kb` / `model_context_kb` / `ram_context_kb`.
|
||||
- Line 654: applies `(100 - headroom_pct) // 100` again when deriving `max_peak_kb = net_kb * (100 - headroom_pct) // 100`.
|
||||
|
||||
Net effect: `max_peak_kb` is discounted by `headroom_pct` *twice*, so a 25% headroom becomes a 44% reduction.
|
||||
|
||||
**Fix**: Restructure `recommend_context` so headroom is applied **exactly once**. Build `recommended_kb` as the raw budget (no `* (100 - headroom_pct) // 100` at lines 642, 644, 648), subtract overhead, then apply headroom once to derive `max_peak_kb`:
|
||||
|
||||
```python
|
||||
def recommend_context(...) -> tuple[int, int, int]:
|
||||
headroom_pct = int(config.get("headroom_pct", DEFAULT_HEADROOM_PCT))
|
||||
|
||||
if not config.get("auto_detect", True):
|
||||
target_kb = int(config.get("target_context_kb", 0))
|
||||
max_peak_kb = int(config.get("max_peak_kb", 0))
|
||||
if target_kb > 0:
|
||||
if max_peak_kb == 0 and headroom_pct > 0:
|
||||
max_peak_kb = target_kb * (100 - headroom_pct) // 100
|
||||
return headroom_pct, target_kb, max_peak_kb
|
||||
|
||||
recommended_kb = 0
|
||||
if gpu_vram_gb >= 4:
|
||||
recommended_kb = gpu_vram_gb * 2000
|
||||
elif model_context_kb > 0:
|
||||
recommended_kb = model_context_kb
|
||||
else:
|
||||
recommended_kb = ram_gb * 750
|
||||
|
||||
net_kb = recommended_kb - overhead_tokens
|
||||
max_peak_kb = net_kb * (100 - headroom_pct) // 100
|
||||
return headroom_pct, net_kb, max_peak_kb
|
||||
```
|
||||
|
||||
Manual-override branch unchanged (it already applies headroom once via `max_peak_kb = target_kb * (100 - headroom_pct) // 100`).
|
||||
|
||||
### R2. Stop lying about zero/negative budgets
|
||||
|
||||
`scripts/vram_detect.py:651`:
|
||||
```python
|
||||
net_kb = max(0, recommended_kb - overhead_tokens)
|
||||
```
|
||||
and `:698-699`:
|
||||
```python
|
||||
recommended_k = recommended_kb // 1000 if recommended_kb > 0 else 8
|
||||
max_peak_k = max_peak_kb // 1000 if max_peak_kb > 0 else 6
|
||||
```
|
||||
|
||||
The `max(0, ...)` silently clamps an *actually-negative* budget to zero, and the `else 8` / `else 6` report fabricated 8k/6k numbers when the true budget is zero or unknown. Any downstream consumer — the dashboard, decompose.md, the future loop runner — reads 8k and proceeds as if it's safe.
|
||||
|
||||
**Fix**:
|
||||
1. Drop the `max(0, ...)` clamp. Keep `net_kb` as the true arithmetic value (may be negative or zero). Already-floored callers (e.g. the dashboard) can compute `max(0, ...)` themselves; `vram_detect.py` returns the honest number.
|
||||
2. Drop the `else 8` / `else 6` fallbacks. Report the real quotient even when zero.
|
||||
3. Add a **warning line** to stdout when `net_kb <= 0` or `model_context_kb == 0` (see R3 for the loop refuse). For non-loop CLI invocations this is a human-readable warning, not an error exit.
|
||||
|
||||
```python
|
||||
recommended_k = recommended_kb // 1000
|
||||
max_peak_k = max_peak_kb // 1000
|
||||
if recommended_kb <= 0:
|
||||
print("WARNING: recommended context budget is zero or negative; "
|
||||
"no usable context headroom for the configured system.")
|
||||
```
|
||||
|
||||
### R3. Refuse unknown models (`model_context_kb: 0`) in loop mode
|
||||
|
||||
Today `detect_model_context` returns `0` on unknown models and `recommend_context` silently falls through to the VRAM/RAM branches. A loop tick with an unknown model could still proceed against an arbitrarily-deranged budget.
|
||||
|
||||
**Fix**: Add a `--loop-mode` flag to `vram_detect.py`'s CLI. When set:
|
||||
- `model_context_kb == 0` is a hard error → print `"ERROR: model context window is unknown in --loop-mode. Set 'Override context window' in config.md or pass --model."` and exit `2`.
|
||||
- `net_kb < 16000` is a hard error → print `"ERROR: available context ({}k) below 16k floor in --loop-mode (D13)."` and exit `2`.
|
||||
|
||||
The flag is optional. Non-loop callers (the dashboard, manual invocations) keep current behavior — only loops opt into the strict check. The future `loop-runner.py` will invoke `vram_detect.py --loop-mode --json` and expect either a 0 exit with a `{...}` JSON payload, or a 2 exit with a refuse message.
|
||||
|
||||
User's explicit `Override context window` in `config.md` (see `_parse_config_model`) is authoritative per D13: if a user has set an override, `detect_model_context` returns that override directly and the `model_context_kb == 0` refuse never fires. The flow already honors this — no special code needed.
|
||||
|
||||
### R4. Expose `available_context_kb` in JSON output
|
||||
|
||||
The loop runner needs a single authoritative figure for its per-tick budget. Today it would have to derive it from `recommended_kb - framework_overhead_tokens` itself, duplicating math.
|
||||
|
||||
**Fix**: Add `available_context_kb` to the JSON output block in `main()`:
|
||||
|
||||
```python
|
||||
output = {
|
||||
"gpu_vram_gb": gpu_vram_gb,
|
||||
"ram_gb": ram_gb,
|
||||
"model_context_kb": model_context_kb,
|
||||
"framework_overhead_tokens": overhead_tokens,
|
||||
"recommended_kb": recommended_kb, # net of overhead, before headroom
|
||||
"recommended_k": recommended_k,
|
||||
"headroom": headroom_pct / 100.0,
|
||||
"max_peak_context_kb": max_peak_kb, # per-subtask peak (loop worktrees consume this)
|
||||
"available_context_kb": max_peak_kb, # alias consumed by loop-runner.py; explicit field
|
||||
"loop_mode_eligible": max_peak_kb >= 16000, # boolean: passes the 16k floor check
|
||||
}
|
||||
```
|
||||
|
||||
`available_context_kb` = `max_peak_kb` (post-R1 value, headroom applied exactly once). Two field names for the same number so both human-readable names and the runner's contract field are stable.
|
||||
|
||||
### R5. Add `## Loop Role Models` section to `config.md`
|
||||
|
||||
`config.md` today only documents VRAM settings. The loop system needs an explicit place for users to declare which model/session plays each role. Per `design/loops/functional.md` §5, three roles exist: `Implement:`, `Verify:`, `Orchestrate:`. The framework never inspects the *model* of each role (D8/D12) — it only needs to know which harness session to invoke per role, which is a harness-level concern that `loop.json` already handles via `roles.{implement,verify,orchestrate}.prompt`. So `config.md` should document the *expectation*, not encode it.
|
||||
|
||||
**Fix**: Append a new `## Loop Role Models` section to `~/.automaton/config.md`:
|
||||
|
||||
```markdown
|
||||
## Loop Role Models
|
||||
|
||||
Loop ticks run three session roles. Roles are *sessions*, not models — a single model can fill multiple roles. Configure each loop's role-to-prompt binding in its `loop.json`; this section documents the framework's expectations only.
|
||||
|
||||
- **Implement:** — produces the artifact for this tick. Bound to `prompts/loop-implement.md` by default.
|
||||
- **Verify:** — grades the artifact and emits the JSON verdict `{pass, score, reasons, next_hint}`. Bound to `prompts/loop-verifier.md`. The framework never inspects this role's model (D8); only its session.
|
||||
- **Orchestrate:** — applies the verdict, calls exactly one `status.py` operation per tick, enforces brakes. Bound to `prompts/loop-orchestrate.md`.
|
||||
|
||||
Conflict-of-interest rule (D12): `Verify:` and `Implement:` must never be the same *session*. When two distinct sessions are infeasible (single-session harness), the runner falls back to session-only divergence — still safe.
|
||||
|
||||
Role context tiers are set per-loop in `loop.json`, not globally. The 16k floor (D13) applies regardless of tier.
|
||||
```
|
||||
|
||||
### R6. Add 4k tier to `decompose.md` and tighten the table
|
||||
|
||||
`prompts/decompose.md` (around :82-84 per the design audit) has a context budget table that omits the small-context 4k tier that a single implement role might fit in when overhead + task brief is small. Per the design audit it also states the 16k floor.
|
||||
|
||||
**Fix**: Open `prompts/decompose.md`, find the existing context budget table (search for `4k` or `context` near the cited lines), add a row for the 4k tier and an explicit "≤ 16k: refuse" line above the table. Exact edits to be confirmed by reading the file at implementation time — this requirement locks the intent, not the diff.
|
||||
|
||||
If the existing table already covers 4k, this requirement is satisfied without edits; otherwise it is added. The 16k floor is the only hard refuse — 4k is a per-subtask peak recommendation, not a floor.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] `recommend_context` returns `max_peak_kb` with headroom applied exactly once (verified by reading the function body — no inner `* (100 - headroom_pct) // 100` at the three budget-construction sites).
|
||||
- [ ] `vram_detect.py`'s JSON output no longer reports 8 / 6 for `recommended_k` / `max_peak_k` when the underlying budget is zero. The actual quotients (including 0) are emitted.
|
||||
- [ ] `vram_detect.py --loop-mode` exits `2` with the refuse message when the computed available context is `< 16000` tokens OR `model_context_kb == 0`.
|
||||
- [ ] Without `--loop-mode`, the script preserves prior non-zero behavior on unknown / zero budgets (only a warning is added; no exit code change).
|
||||
- [ ] JSON output includes `available_context_kb` and `loop_mode_eligible` fields.
|
||||
- [ ] `config.md` includes the `## Loop Role Models` section verbatim (text may be condensed, intent preserved).
|
||||
- [ ] `prompts/decompose.md` either acknowledges an existing 4k tier in its table or grows a 4k tier row, plus a `≤ 16k: refuse` line.
|
||||
- [ ] New tests in `tests/` (Python) cover: double-headroom removed (regression test), `--loop-mode` refuse paths, JSON field presence, decompose.md tier presence.
|
||||
- [ ] Pre-existing framework tests stay green: `python3 -m pytest tests/ -v`.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Per-tick context budget enforcement **inside `vram_detect.py`** — that lives in `loop-runner.py` (task `add-loop-runner`). This task only *exposes* the numbers.
|
||||
- Removing `model_context_kb == 0` fallback-to-VRAM in non-loop mode — that behavior is preserved for human CLI calls.
|
||||
- Changing how `Override context window` is parsed (it's already authoritative per D13; this task just relies on it).
|
||||
- Touching `loop-verifier.md` prompt contents — that's task `add-loop-templates-onboarding` (task 6). This task only adds a `## Loop Role Models` reference section to `config.md`.
|
||||
|
||||
## Dependencies
|
||||
|
||||
None. This is the first task in the bootstrap queue; downstream brakes and runner depend on it.
|
||||
|
||||
## Out of Scope (handled by Tier 2 `design/context-sizing/`)
|
||||
|
||||
Per D17: comprehensive context-sizing cleanup (`last-read-sha`, drift detection, decompose.md full rework, dashboard "model context" panel) is a sibling design driven by the first loop workstream after task 7 lands. This task limits itself to the six Tier 1 items above.
|
||||
@@ -1,37 +0,0 @@
|
||||
# Verdict: fix-context-sizing
|
||||
|
||||
## Status: PASS
|
||||
**Completion Date**: 2026-06-22
|
||||
|
||||
## Summary
|
||||
Tier 1 context-sizing layer landed: `vram_detect.py`'s `recommend_context` now applies headroom exactly once (was 3×); fake 8k/6k fallbacks and `max(0,...)` lying clamp removed; new `--loop-mode` CLI flag refuses unknown models and sub-16k available context per D13; JSON output exposes `available_context_kb` + `loop_mode_eligible` for the upcoming loop runner. `config.md` documents `## Loop Role Models`; `decompose.md` gains a 4k tier and an explicit `≤ 16k: REFUSE` floor.
|
||||
|
||||
## Phase Outcomes
|
||||
- Research: SPEC.md produced and approved by user before implementation.
|
||||
- Implement: code edits + IMPLEMENTATION.md produced; 15 new tests in `tests/test_context_sizing.py`; one pre-existing test (`test_recommend_context_api_model`) updated to assert the corrected single-headroom contract.
|
||||
- Code Review: PASS — full spec conformance R1–R6 verified; 264/264 tests green.
|
||||
- Bug Find: NO_BUGS_FOUND — 4 adversarial vectors probed, no defects.
|
||||
- Adversarial Bug Find: NO_NEW_DEFECTS — 5 attacks from design's §6 model all produce correct refuse/warn behavior.
|
||||
- Doc Review: PASS — `config.md` + `decompose.md` updated; doc cross-references verified.
|
||||
- Referee: PASS — all phase artifacts present and consistent.
|
||||
|
||||
## Test Results
|
||||
- New: 15 passed / 15
|
||||
- Pre-existing updated: 1 (`test_recommend_context_api_model` — was asserting the bug; now asserts the fix)
|
||||
- Full suite: 264 passed
|
||||
- Self-consistency suite: 74 passed (no prompt path regressions)
|
||||
|
||||
## Findings
|
||||
- All six SPEC requirements (R1–R6) implemented and guard-tested.
|
||||
- Pre-existing test that encoded the old buggy behavior was properly updated; reason documented inline in commit message.
|
||||
|
||||
## Tasks for Review / Tie-Breaks
|
||||
- None
|
||||
|
||||
## Remaining Issues (out of scope, tracked)
|
||||
- Loop runner must `max(0, available_context_kb)` before scheduling — task 3 (`add-loop-runner`).
|
||||
- `README.md` human-facing CLI doc for `--loop-mode` — Tier 2 cleanup.
|
||||
- v1.1 dashboard "Loops" panel will surface `loop_mode_eligible` — v1.1.
|
||||
|
||||
## Score
|
||||
+10
|
||||
Reference in New Issue
Block a user