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
parent e13513faaa
commit 4a2301b077
572 changed files with 856 additions and 101 deletions
@@ -0,0 +1 @@
+complete
@@ -0,0 +1,2 @@
+research:approved|2026-06-23T01:21:33.749096+00:00|user
+code_review:approved|2026-06-23T01:30:20.274565+00:00|user
@@ -0,0 +1,35 @@
+# 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.
@@ -0,0 +1,32 @@
+# 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.
@@ -0,0 +1,37 @@
+# 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.
@@ -0,0 +1,27 @@
+# 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.
@@ -0,0 +1,14 @@
+# 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.
@@ -0,0 +1,164 @@
+# 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.
@@ -0,0 +1,37 @@
+# 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