Restore archived tasks, fix dashboard scroll-reset, bind ornith, add Playwright smoke test

- **Restore 82 completed tasks** from tasks/complete/ back to tasks/ top
  level (all <7 days old per the cleanup policy; premature bulk archive
  was fixed).
- **Dashboard: fix scroll-reset on auto-refresh** — renderBoard rebuilds
  the board via innerHTML every 2s, destroying each column-body's
  scrollTop. Now snapshots column-body scrollTop + board.scrollLeft +
  view.scrollTop before rebuild and restores after (matched by
  PHASE_GROUPS index).
- **Dashboard UI additions** (pre-existing unstaged work): approval
  section cards, transition buttons, inline artifact editor (textarea for
  writing missing SPEC/VERDICT/etc from the detail modal).
- **Bind ornith as Implement model** — config.md: Model explicit to
  omlx/Ornith-1.0-35B-4bit-mlx, context window 32768. Interactive
  autopilot already used ornith via opencode default; now explicit.
- **Fix cleanup stub** — automaton-cleanup.sh had a stale --project arg
  pointing at a pytest temp dir (test isolation leak). Rewired to point
  at ~/.automaton.
- **Fix plist-isolation test** — test asserted host plist doesn't exist,
  but a real install creates it. Now snapshots mtime before run, asserts
  unchanged after (only a write during the test counts as bleed).
- **New Playwright smoke test** (tests/test_dashboard_ui.py) — 2 tests:
  board renders tasks, column scroll survives auto-refresh tick.
  Verified the test fails without the scroll fix (scrollTop resets to 0).
  Skipped via importorskip when playwright is absent (main CI stays
  green).
- **Clarify SI loop scope in README** — new-project onboarding section
  documents the framework-scoped self-improvement loop and options
  (leave/pause/create project loop).
- **CHANGELOG** documents all changes including the known model-divergence
  gap (mde tasks marked complete but per-role model binding was never
  implemented).

tasks/add-loop-templates-onboarding/ADVERSARIAL_BUG_REPORT.md

@@ -0,0 +1,55 @@
+# ADVERSARIAL_BUG_REPORT: add-loop-templates-onboarding
+
+## Methodology
+
+Targeted attack on the weakest points of the implementation:
+1. Path traversal via `prompt_ref`
+2. Token injection via `extras` values
+3. Race condition on `outputs/` directory
+4. Large file DoS via `{artifact_content}`
+5. Unicode/encoding edge cases
+6. Concurrent ticks writing to the same `outputs/` dir
+
+## Findings
+
+### Attack 1: Path traversal via `prompt_ref` -- NOT VULNERABLE
+
+`_resolve_prompt` constructs candidate paths as `loop_path / prompt_ref` and `AUTOMATON_DIR / "prompts" / prompt_ref`. If `prompt_ref` were `"../../etc/passwd"`, `Path / "../../etc/passwd"` would resolve to a path outside the loop dir. However, `prompt_ref` comes from `loop.json` `roles.*.prompt`, which is a trusted config file written by the user/framework. An attacker who can write `loop.json` already has full code execution via `harness.command`. No additional risk.
+
+**Verdict:** NOT VULNERABLE (trusted input)
+
+### Attack 2: Token injection via extras values -- NOT VULNERABLE
+
+If `task_brief` contained `{task_brief}`, the `str(value)` substitution would not cause infinite recursion because `content.replace` is a single-pass operation. The substituted value is inserted as-is, and no further substitution is applied to the result. No injection vector.
+
+**Verdict:** NOT VULNERABLE
+
+### Attack 3: Race condition on `outputs/` directory -- NOT EXPLOITABLE
+
+`out_dir.mkdir(parents=True, exist_ok=True)` is atomic. If two ticks run concurrently (which the scheduler should prevent, but could happen in daemon mode with a bug), they would write to different files (`tickN-<role>-prompt.md` where N differs). The only shared state is the directory itself, and `mkdir(exist_ok=True)` handles that. The `.state.loop` write is atomic (tmp+rename), so `iteration_count` won't be corrupted.
+
+**Verdict:** NOT EXPLOITABLE (different tick numbers produce different file paths)
+
+### Attack 4: Large file DoS via `{artifact_content}` -- ACCEPTED RISK
+
+If the implement artifact is very large (e.g. 10MB), `{artifact_content}` reads the entire file into memory and substitutes it into the prompt. This could produce a prompt that exceeds the model's context window. However, the runner already has a `_truncate_tokens` function (from task 4) that caps `task_brief` at 4k tokens, `acceptance_criteria` at 2k, and `next_hint` at 1k. The `{artifact_content}` token is NOT truncated, which is by design -- the verifier needs to see the full artifact to grade it. The 16k context floor gate (D13) catches undersized contexts before the harness is invoked. For oversized contexts, the harness's own context management handles it.
+
+**Verdict:** ACCEPTED RISK (mitigated by context floor gate and harness-side context management)
+
+### Attack 5: Unicode/encoding edge cases -- NOT VULNERABLE
+
+`Path.read_text()` and `Path.write_text()` use UTF-8 by default on all platforms. The `str(value)` conversion handles all Python string types. No encoding issues found.
+
+**Verdict:** NOT VULNERABLE
+
+### Attack 6: Concurrent ticks writing to same `outputs/` dir -- NOT EXPLOITABLE
+
+Same as Attack 3. Different tick numbers produce different file paths. The `.state.loop` atomic write prevents `iteration_count` corruption.
+
+**Verdict:** NOT EXPLOITABLE
+
+## Summary
+
+No exploitable vulnerabilities found. All attack surfaces are either mitigated by existing controls (context floor gate, atomic state writes, trusted input assumption) or produce no harmful behavior.
+
+**Verdict: CLEAN**