- **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).
2.5 KiB
2.5 KiB
SPEC: Enforce Task-Driven Development via Framework Rules
Overview
The automaton framework has a task-driven workflow (SPEC → Design → Implementation → Verification → Resolution) but nothing tells the AI agent to follow it. The agent makes ad-hoc edits instead of creating proper tasks first.
Root Cause
The agent reads system-prompt.md, .agent.md, and .rules.md at startup, but none instruct it to use the task-driven process. The agent treats framework modifications as "normal coding."
Framework Audit Context
This task covers 4 gaps identified in framework-audit/RESEARCH.md:
| Gap | Principle | Rule to Add |
|---|---|---|
| G1 | Task-driven development | Create task before editing files |
| G2 | VRAM-aware task sizing | Check config.md VRAM before scoping tasks |
| G4 | No manual task creation | Never mkdir tasks/ — use Orchestrator |
| G5 | Agent reads global rules | system-prompt.md must read global .rules.md |
| G6 | Self-improving rules | Add rules per failure mode observed |
Changes
1. ~/.automaton/.rules.md
Replace the template with concrete rules:
# .rules.md
## Task-Driven Development
- All changes must go through a task in tasks/{name}/ with SPEC.md → phases → VERDICT.md
- Never edit files directly without a corresponding task
- Never create task directories manually (mkdir tasks/) — use the Orchestrator
## VRAM-Aware Task Sizing
- Before creating or scoping a task, check ~/.automaton/config.md for VRAM limits
- Verify the task fits within max peak context (default: 12k tokens)
- If no config exists, default to 8k with 25% headroom
## Self-Improvement
- Add one rule per observed failure mode with a concrete example
- Consolidate contradictions monthly. Remove stale rules.
- No rule without a real example of the problem it prevents
2. system-prompt.md
After existing instructions, add:
4. Read ~/.automaton/.rules.md (global framework rules)
Acceptance Criteria
~/.automaton/.rules.mdhas Task-Driven Development, VRAM-Aware Sizing, and Self-Improvement sectionssystem-prompt.mdinstructs agent to read global.rules.md- Agent creates tasks before making changes
- Agent checks VRAM limits before scoping tasks
- Agent never creates task directories manually
Out of Scope
- Documentation/changelog process (separate task)
- Project migration/cleanup (separate task)
- Onboarding changes (separate task)
- Dashboard task review UI (separate task)