Lap Tran
bc7daf8590
- **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).
78 lines
3.1 KiB
Markdown
78 lines
3.1 KiB
Markdown
# SPEC: Dashboard Task Review and Approval
|
|
|
|
## Overview
|
|
|
|
The dashboard currently shows tasks grouped by phase but has no workflow for reviewing and approving tasks before they proceed to the next phase. A user should be able to review a task's artifacts (SPEC.md, DESIGN.md, IMPLEMENTATION.md, etc.) and approve or reject it directly from the dashboard.
|
|
|
|
## Motivation
|
|
|
|
The framework has phases that require user sign-off (Research → SPEC.md review, Design → DESIGN.md review, etc.) but this sign-off happens via agent interaction, not through the dashboard. Adding review/approval to the dashboard provides:
|
|
|
|
1. **Asynchronous review** — approve or flag tasks without an active agent session
|
|
2. **Audit trail** — who approved what and when
|
|
3. **Blocked task management** — reject a task to move it to Blocked column
|
|
4. **Self-service** — approve multiple tasks at a glance
|
|
|
|
## Requirements
|
|
|
|
### 1. Review State Per Task
|
|
|
|
Each task can have a review status:
|
|
|
|
| Status | Meaning |
|
|
|--------|---------|
|
|
| `pending` | Awaiting review (default for new artifacts) |
|
|
| `approved` | Reviewer approved, task can proceed |
|
|
| `changes_requested` | Reviewer wants changes, task moves to Blocked |
|
|
| `not_needed` | No review needed (e.g., automated phases) |
|
|
|
|
### 2. Review Data Storage
|
|
|
|
Store review state in the task directory:
|
|
- `REVIEW.md` — review metadata (status, reviewer, timestamp, comments)
|
|
- Or embed in existing artifact files if simpler
|
|
|
|
### 3. Dashboard UI
|
|
|
|
- Each task card shows review status badge (🟡 pending, ✅ approved, ❌ changes requested)
|
|
- Clicking a task opens a detail panel with:
|
|
- Artifact preview (SPEC.md, DESIGN.md, etc.)
|
|
- Approve / Request Changes buttons
|
|
- Comment box
|
|
- Phase columns show a review filter toggle (show all / show pending only)
|
|
- Stats view includes review metrics (pending approvals count)
|
|
|
|
### 4. Integration with Phase Flow
|
|
|
|
- A task in "Research" phase with a new SPEC.md starts as `pending` review
|
|
- When approved, the task proceeds to next phase
|
|
- When "changes requested", the task moves to Blocked column with a note
|
|
- Review status is checked by the Orchestrator before auto-executing next phase
|
|
|
|
### 5. API Endpoints
|
|
|
|
- `GET /api/tasks/{name}/review` — get review status
|
|
- `POST /api/tasks/{name}/review` — submit review (approve/changes_requested + comment)
|
|
- `GET /api/review-summary` — aggregate review metrics for all tasks
|
|
|
|
## Acceptance Criteria
|
|
|
|
- [ ] Tasks have review state stored in REVIEW.md
|
|
- [ ] Dashboard shows review status badge on task cards
|
|
- [ ] Detail panel has Approve / Request Changes buttons
|
|
- [ ] Filter for pending reviews only
|
|
- [ ] Stats shows pending approval count
|
|
- [ ] API serves review data and accepts review submissions
|
|
- [ ] Orchestrator checks review status before auto-executing
|
|
|
|
## Out of Scope
|
|
|
|
- Multi-user review workflow (single user for now)
|
|
- Email/notification system for pending reviews
|
|
- Role-based permissions
|
|
|
|
## Notes
|
|
|
|
- This builds on the existing Blocked column (when changes_requested, task goes to Blocked)
|
|
- Review state is simple — approve or changes_requested, no multi-level approval
|