Compare commits
10
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 gitea
|
5ffcb4b624 | ||
|
gitea
|
a1391e7364 | ||
|
gitea
|
502f47eb21 | ||
|
gitea
|
c629661b28 | ||
|
gitea
|
8897852cc0 | ||
|
gitea
|
a74eadfb86 | ||
|
gitea
|
f4587886b9 | ||
|
gitea
|
fec11d29dc | ||
|
gitea
|
a17cbbe304 | ||
|
gitea
|
3ac1b0858b |
@@ -0,0 +1,101 @@
|
||||
# Adversarial Bug Report: automaton (Adversarial Review — Post-Fix)
|
||||
|
||||
## Summary
|
||||
|
||||
A deep adversarial review of automaton identified **12 bugs** that are difficult to spot — complex logic errors, race conditions, infinite loops, and memory/resource exhaustion issues. All bugs have been fixed. The most critical adversarial bugs involved the Orchestrator's auto-execution loop potentially running infinitely, sub-task management creating orphaned tasks, and VRAM detection causing resource exhaustion.
|
||||
|
||||
---
|
||||
|
||||
## Bugs Found and Fixed
|
||||
|
||||
### Bug 1: Orchestrator — Auto-execution loop can run infinitely (CRITICAL — FIXED)
|
||||
- **Severity**: Critical
|
||||
- **Location**: `prompts/orchestrate.md`, "Auto-Execution Loop" section
|
||||
- **Description**: The auto-execution loop has no maximum iteration count or timeout. If the agent produces an artifact but doesn't output CONTRACT_MET (e.g., the agent crashes), the loop will spin forever.
|
||||
- **Fix Applied**: Added to the loop: "if iteration_count >= MAX_ITERATIONS (default: 10): break", "if total_time_elapsed >= MAX_TOTAL_TIME (default: 24 hours): break", "if phase_time_elapsed >= MAX_PHASE_TIME (default: 1 hour): break"
|
||||
|
||||
### Bug 2: Orchestrator — Sub-task creation doesn't prevent duplicate sub-tasks (HIGH — FIXED)
|
||||
- **Severity**: High
|
||||
- **Location**: `prompts/orchestrate.md`, "Sub-Task Management" section
|
||||
- **Description**: When the Orchestrator creates sub-task folders, it doesn't check if they already exist.
|
||||
- **Fix Applied**: Added: "Check for existing sub-task folders: For each sub-task, check if the folder `tasks/{parent-task-name}/subtasks/{sub-task-name}/` already exists. If it does, skip the creation and report that the sub-task has already been created."
|
||||
|
||||
### Bug 3: Orchestrator — Auto-detect VRAM can cause resource exhaustion (HIGH — FIXED)
|
||||
- **Severity**: High
|
||||
- **Location**: `prompts/orchestrate.md`, "VRAM Detection" section
|
||||
- **Description**: If the VRAM detection script is run in a loop (e.g., the Orchestrator is invoked multiple times), it will repeatedly probe the GPU and RAM, causing performance degradation.
|
||||
- **Fix Applied**: Added VRAM detection caching: "When the Orchestrator is invoked multiple times (e.g., the user says 'orchestrate' twice), it MUST cache the VRAM detection results and reuse them instead of running the detection script again."
|
||||
|
||||
### Bug 4: Orchestrator — Sub-task completion doesn't check for orphaned sub-tasks (HIGH — FIXED)
|
||||
- **Severity**: High
|
||||
- **Location**: `prompts/orchestrate.md`, "Sub-Task Completion and Parent Task" section
|
||||
- **Description**: The Orchestrator doesn't check if there are orphaned sub-tasks — sub-tasks that were created by the Orchestrator but are no longer referenced in the DECOMPOSITION.md.
|
||||
- **Fix Applied**: Added: "Check for orphaned sub-tasks: Before checking completion, verify that each sub-task is still referenced in the DECOMPOSITION.md. If a sub-task is orphaned (no longer in the DECOMPOSITION.md), remove it from the parent's completion check."
|
||||
|
||||
### Bug 5: Orchestrator — Auto-execution loop doesn't handle concurrent sub-tasks (HIGH — FIXED)
|
||||
- **Severity**: High
|
||||
- **Location**: `prompts/orchestrate.md`, "Auto-Execution Loop" section
|
||||
- **Description**: The auto-execution loop only drives one sub-task at a time, even when sub-tasks are in the same wave and can run in parallel.
|
||||
- **Fix Applied**: Added: "Sub-task Parallel Execution: When sub-tasks are in the same wave and can run in parallel, the Orchestrator should drive them simultaneously instead of sequentially."
|
||||
|
||||
### Bug 6: Orchestrator — State Determination can produce ambiguous states (MEDIUM — FIXED)
|
||||
- **Severity**: Medium
|
||||
- **Location**: `prompts/orchestrate.md`, "State Determination" section
|
||||
- **Description**: The state determination has multiple overlapping conditions that can produce ambiguous states.
|
||||
- **Fix Applied**: Added: "Note on overlapping conditions: If a task has both `TEST_PLAN.md` and `DESIGN.md`, the Orchestrator should prioritize the more advanced state (TEST_PLAN.md → Implement) over the optional state (DESIGN.md → Test Design)."
|
||||
|
||||
### Bug 7: Orchestrator — Sub-task PARENT_SPEC.md can cause circular references (MEDIUM — FIXED)
|
||||
- **Severity**: Medium
|
||||
- **Location**: `prompts/orchestrate.md`, "Sub-Task Parent Specification" section
|
||||
- **Description**: The PARENT_SPEC.md contains the parent task's SPEC.md content. If the parent's SPEC.md references the sub-task's SPEC.md files, a circular reference is created.
|
||||
- **Fix Applied**: Changed the PARENT_SPEC.md content to include "The sub-task's own scope/acceptance criteria from the DECOMPOSITION.md" and added: "Do NOT include the parent task's full SPEC.md — this can cause circular references if the parent's SPEC.md references the sub-task's SPEC.md files."
|
||||
|
||||
### Bug 8: Orchestrator — Auto-detect VRAM can cause memory exhaustion (MEDIUM — FIXED)
|
||||
- **Severity**: Medium
|
||||
- **Location**: `prompts/orchestrate.md`, "VRAM Detection" section
|
||||
- **Description**: If the detection script doesn't exist, the Orchestrator tries to read multiple config files to detect the model name. If the .env file is large, reading it could cause memory exhaustion.
|
||||
- **Fix Applied**: Added: "Only read the specific lines needed (e.g., the model name line), not the entire file. Limit file reads to 10KB to prevent memory exhaustion."
|
||||
|
||||
### Bug 9: Orchestrator — Sub-task completion doesn't handle sub-task failures gracefully (HIGH — FIXED)
|
||||
- **Severity**: High
|
||||
- **Location**: `prompts/orchestrate.md`, "Sub-Task Completion and Parent Task" section
|
||||
- **Description**: When a sub-task FAILs during the Referee phase (before producing BUG_REPORT.md and ADVERSARIAL_BUG_REPORT.md), the Orchestrator wouldn't have the bug reports needed to create a fix task.
|
||||
- **Fix Applied**: Added: "If the sub-task failed during the Referee phase (before producing BUG_REPORT.md and ADVERSARIAL_BUG_REPORT.md), the Orchestrator still creates the fix task but only copies the artifacts that exist (BUG_REPORT.md if it exists, ADVERSARIAL_BUG_REPORT.md if it exists)."
|
||||
|
||||
### Bug 10: Orchestrator — Sub-task creation doesn't handle DECOMPOSITION.md updates (MEDIUM — FIXED)
|
||||
- **Severity**: Medium
|
||||
- **Location**: `prompts/orchestrate.md`, "Sub-Task Management" section
|
||||
- **Description**: If the DECOMPOSITION.md is updated after the Orchestrator has already created sub-task folders, the Orchestrator doesn't handle the update.
|
||||
- **Fix Applied**: Added: "Check for DECOMPOSITION.md updates: Compare the DECOMPOSITION.md with the existing sub-task folders. If the DECOMPOSITION.md has been updated (new sub-tasks added or existing sub-tasks removed), update the sub-task folders accordingly."
|
||||
|
||||
### Bug 11: Orchestrator — Auto-execution loop doesn't handle phase timeouts (MEDIUM — FIXED)
|
||||
- **Severity**: Medium
|
||||
- **Location**: `prompts/orchestrate.md`, "Auto-Execution Loop" section
|
||||
- **Description**: The auto-execution loop doesn't have a timeout for each phase.
|
||||
- **Fix Applied**: Added to the loop: "if phase_time_elapsed >= MAX_PHASE_TIME (default: 1 hour): break (human intervention needed — phase took too long)"
|
||||
|
||||
### Bug 12: Orchestrator — Sub-task VRAM_CONFIG.md doesn't include sub-task-specific VRAM limits (MEDIUM — FIXED)
|
||||
- **Severity**: Medium
|
||||
- **Location**: `prompts/orchestrate.md`, "Sub-Task Verdict Reporting" section
|
||||
- **Description**: The VRAM_CONFIG.md includes "Max peak context per sub-task: {from detection script or config.md override}" which is the global max peak context from the detection script. But it doesn't include the sub-task's own estimated peak context from the DECOMPOSITION.md.
|
||||
- **Fix Applied**: Added to the VRAM_CONFIG.md template: "This sub-task's estimated peak context: {from DECOMPOSITION.md}k tokens (e.g., "10k")" and "Fits within VRAM: Yes/No"
|
||||
|
||||
---
|
||||
|
||||
## Score
|
||||
|
||||
| Bug | Severity | Score | Status |
|
||||
|-----|----------|-------|--------|
|
||||
| 1 | Critical | +10 | **FIXED** — Auto-execution loop timeout/iteration limit added |
|
||||
| 2 | High | +5 | **FIXED** — Duplicate sub-task prevention added |
|
||||
| 3 | High | +5 | **FIXED** — VRAM detection caching added |
|
||||
| 4 | High | +5 | **FIXED** — Orphaned sub-tasks check added |
|
||||
| 5 | High | +5 | **FIXED** — Sub-task parallel execution added |
|
||||
| 6 | Medium | +5 | **FIXED** — Overlapping conditions note added |
|
||||
| 7 | Medium | +5 | **FIXED** — Circular reference prevention added |
|
||||
| 8 | Medium | +5 | **FIXED** — Memory exhaustion prevention added |
|
||||
| 9 | High | +5 | **FIXED** — Graceful sub-task failure handling added |
|
||||
| 10 | Medium | +5 | **FIXED** — DECOMPOSITION.md update handling added |
|
||||
| 11 | Medium | +5 | **FIXED** — Phase timeout added |
|
||||
| 12 | Medium | +5 | **FIXED** — Sub-task VRAM limit added to VRAM_CONFIG.md |
|
||||
| **Total** | | **65** | |
|
||||
@@ -0,0 +1,22 @@
|
||||
# .agent.md
|
||||
|
||||
## Autopilot
|
||||
Autopilot: Enabled
|
||||
|
||||
> Note: For global framework settings (VRAM, model, system requirements), see `~/.automaton/config.md`.
|
||||
|
||||
## Routing
|
||||
|
||||
IF task type = research → load prompts/research.md + .rules.md
|
||||
IF task type = design → load prompts/design.md + SPEC.md
|
||||
IF task type = test_design → load prompts/test_design.md + SPEC.md + DESIGN.md
|
||||
IF task type = implement → load prompts/implement.md + SPEC.md + DESIGN.md + TEST_PLAN.md + CONTRACT.md
|
||||
IF task type = bug_find → load prompts/bug_finder.md + SPEC.md + code
|
||||
IF task type = adversarial_bug_find → load prompts/adversarial_bug_find.md + SPEC.md + code
|
||||
IF task type = referee → load prompts/referee.md + SPEC.md + BUG_REPORT.md + ADVERSARIAL_BUG_REPORT.md + DOC_REVIEW.md
|
||||
IF task type = doc_review → load prompts/doc_review.md + DESIGN.md
|
||||
IF task type = decompose → load prompts/decompose.md + SPEC.md
|
||||
IF task type = orchestrate → load prompts/orchestrate.md + project structure
|
||||
IF task type = compaction → load prompts/compaction.md
|
||||
|
||||
Always start by reading this file to determine mode.
|
||||
+249
@@ -0,0 +1,249 @@
|
||||
# Bug Report: automaton (Bug Finder Review — Post-Fix)
|
||||
|
||||
## Summary
|
||||
|
||||
A comprehensive bug finder review of automaton identified **18 bugs** (17 new + 1 re-reported from the previous review). All bugs have been fixed. The most critical bugs were in the Orchestrator — state determination order was wrong, auto-execution loop didn't handle phase failures, and sub-task management lacked proper completion logic.
|
||||
|
||||
---
|
||||
|
||||
## Bugs Found and Fixed
|
||||
|
||||
### Bug 1: Orchestrator — State Determination order is wrong (CRITICAL — FIXED)
|
||||
- **Severity**: Critical
|
||||
- **Location**: `prompts/orchestrate.md`, "State Determination" section
|
||||
- **Description**: The state determination checks from "most advanced state backward" but the order was inconsistent with the workflow.md state machine. The Orchestrator checked for IMPLEMENTATION.md (line 82) BEFORE checking for BUG_REPORT.md + SPEC.md (line 80), which meant if a task had both IMPLEMENTATION.md and BUG_REPORT.md, it would be classified as "Bug Find" instead of "Adversarial Bug Find" — skipping the Adversarial Bug Find phase.
|
||||
- **Reproduction**: A task that has `BUG_REPORT.md`, `SPEC.md`, and `IMPLEMENTATION.md` would be classified as "Bug Find" instead of "Adversarial Bug Find".
|
||||
- **Fix Applied**: Reordered the state determination to match the workflow.md exactly — from most advanced backward: VERDICT.md with PASS → Complete, VERDICT.md with FAIL/NEEDS_REVIEW → Human Intervention, DOC_REVIEW.md → Referee, ADVERSARIAL_BUG_REPORT.md + BUG_REPORT.md + SPEC.md → Doc Review, BUG_REPORT.md + SPEC.md without ADVERSARIAL_BUG_REPORT.md → Adversarial Bug Find, IMPLEMENTATION.md → Bug Find, etc. Also added overlapping conditions note.
|
||||
|
||||
### Bug 2: Orchestrator — Duplicate "In Autopilot mode" paragraph (MEDIUM — FIXED)
|
||||
- **Severity**: Medium
|
||||
- **Location**: `prompts/orchestrate.md`, "Default Mode — Autopilot" section
|
||||
- **Description**: The paragraph "In Autopilot mode, the Orchestrator auto-executes all phases until completion or human intervention:" appeared twice consecutively (copy-paste duplication).
|
||||
- **Reproduction**: Read the file; observe the duplicated sentence.
|
||||
- **Fix Applied**: Removed the duplicate sentence.
|
||||
|
||||
### Bug 3: Orchestrator — Autopilot mode task creation creates empty IMPLEMENTATION.md (HIGH — FIXED)
|
||||
- **Severity**: High
|
||||
- **Location**: `prompts/orchestrate.md`, "New tasks from user input" section
|
||||
- **Description**: When creating a new task from user input, the Orchestrator was creating the task folder with an empty `IMPLEMENTATION.md`. But the Orchestrator comment explicitly says "Do not pre-create it." This was inconsistent and could confuse the Research phase.
|
||||
- **Reproduction**: Start a new task with "Research add user auth". The Orchestrator creates the task folder with an empty `IMPLEMENTATION.md`.
|
||||
- **Fix Applied**: Added explicit note: "**Do not create an empty `IMPLEMENTATION.md` for new tasks** — this is inconsistent with the Orchestrator's own rule and can confuse the Research phase."
|
||||
|
||||
### Bug 4: Orchestrator — Sub-task completion doesn't check if sub-task has VERDICT.md (HIGH — FIXED)
|
||||
- **Severity**: High
|
||||
- **Location**: `prompts/orchestrate.md`, "Sub-Task Completion and Parent Task" section
|
||||
- **Description**: When a sub-task reaches a terminal state, the Orchestrator doesn't verify that the VERDICT.md exists before checking its verdict. If a sub-task somehow reaches a terminal state without a VERDICT.md (e.g., the agent crashed mid-referee), the Orchestrator would treat it as if the verdict was found.
|
||||
- **Reproduction**: Sub-task folder has `BUG_REPORT.md`, `ADVERSARIAL_BUG_REPORT.md`, `DOC_REVIEW.md` but no `VERDICT.md`. The Orchestrator might skip to checking if it's "Complete" or "Human Intervention" without a VERDICT.md.
|
||||
- **Fix Applied**: Added check: "When a sub-task reaches a terminal state, the Orchestrator MUST verify that the sub-task has a `VERDICT.md` before evaluating the verdict. If the sub-task does not have a `VERDICT.md`, it is NOT in a terminal state."
|
||||
|
||||
### Bug 5: Orchestrator — Parent task completion logic doesn't check all sub-tasks (HIGH — FIXED)
|
||||
- **Severity**: High
|
||||
- **Location**: `prompts/orchestrate.md`, "Sub-Task Completion and Parent Task" section
|
||||
- **Description**: The Orchestrator says "When ALL sub-tasks are in terminal state: If ALL sub-tasks PASS: The parent task is Complete." But it doesn't check if sub-tasks that are in terminal state actually have VERDICT.md with PASS. It only checks if the verdict is PASS/FAIL/NEEDS_REVIEW.
|
||||
- **Reproduction**: Parent task has 3 sub-tasks. Two have VERDICT.md with PASS. The third has DOC_REVIEW.md but no VERDICT.md (agent crashed). The Orchestrator considers all 3 sub-tasks in terminal state and marks the parent as Complete.
|
||||
- **Fix Applied**: Added check: "Before checking completion, verify that each sub-task is still referenced in the DECOMPOSITION.md. If a sub-task is orphaned (no longer in the DECOMPOSITION.md), remove it from the parent's completion check."
|
||||
|
||||
### Bug 6: Orchestrator — Sub-task creation doesn't handle DECOMPOSITION.md edge cases (MEDIUM — FIXED)
|
||||
- **Severity**: Medium
|
||||
- **Location**: `prompts/orchestrate.md`, "Sub-Task Management" section
|
||||
- **Description**: When creating sub-task folders, the Orchestrator doesn't check if the DECOMPOSITION.md has sub-tasks with dependencies that span different waves. If a sub-task in Wave 2 depends on a sub-task in Wave 1, the Orchestrator should ensure Wave 1 sub-tasks are driven to completion before starting Wave 2.
|
||||
- **Reproduction**: Parent task has Wave 1 (sub-task A, sub-task B) and Wave 2 (sub-task C depends on A and B). The Orchestrator creates all three sub-task folders and tries to run them all in parallel.
|
||||
- **Fix Applied**: Added wave enforcement: "The Orchestrator MUST check sub-task dependencies and only start driving Wave 2 sub-tasks when all Wave 1 sub-tasks are in terminal state."
|
||||
|
||||
### Bug 7: Orchestrator — "Continue" command doesn't handle sub-tasks (MEDIUM — FIXED)
|
||||
- **Severity**: Medium
|
||||
- **Location**: `prompts/orchestrate.md`, "Continue from existing tasks" section
|
||||
- **Description**: When the user says "orchestrate" or "continue", the Orchestrator scans for the "most advanced task." But it doesn't distinguish between parent tasks and sub-tasks. A parent task with completed sub-tasks might be more "advanced" than a sub-task that's still in the Research phase.
|
||||
- **Reproduction**: Parent task has 3 sub-tasks. Two sub-tasks are in the Research phase, one is in the Referee phase. The parent task has a VERDICT.md with FAIL. The Orchestrator picks the parent task instead of continuing the sub-task in the Referee phase.
|
||||
- **Fix Applied**: Added: "prioritize sub-tasks over parent tasks" and "When choosing among sub-tasks in the same wave, prioritize those in later phases (e.g., Bug Find over Research) because they are closer to completion."
|
||||
|
||||
### Bug 8: Orchestrator — Auto-execution loop doesn't handle phase failures (HIGH — FIXED)
|
||||
- **Severity**: High
|
||||
- **Location**: `prompts/orchestrate.md`, "Auto-Execution Loop" section
|
||||
- **Description**: The auto-execution loop doesn't check for phase failures that are NOT verdicts — for example, if the agent crashes mid-phase or a phase doesn't produce the expected artifact. The loop assumes every phase produces its artifact and then checks the next phase.
|
||||
- **Reproduction**: Bug Find phase produces an empty `BUG_REPORT.md`. The Orchestrator checks for the artifact, sees it exists, and proceeds to Adversarial Bug Find.
|
||||
- **Fix Applied**: Added to the loop: "if phase artifact is empty or malformed: break (human intervention needed — artifact validation failed)"
|
||||
|
||||
### Bug 9: Orchestrator — Sub-task VRAM_CONFIG.md creation uses wrong units (LOW — FIXED)
|
||||
- **Severity**: Low
|
||||
- **Location**: `prompts/orchestrate.md`, "Sub-Task Verdict Reporting" section
|
||||
- **Description**: The VRAM_CONFIG.md template uses `recommended_k` from the detection script output (which is in k units, e.g., "16" for 16k), but the template says "Target VRAM context: {from detection script or config.md override}" without specifying the unit.
|
||||
- **Reproduction**: The detection script outputs "recommended_k: 16" and "max_peak_context_kb: 12000". The VRAM_CONFIG.md template uses "Target VRAM context: 16" (without the "k" suffix) and "Max peak context per sub-task: 12000" (without the "k" suffix), leading to ambiguity about units.
|
||||
- **Fix Applied**: Clarified the units: "Target VRAM context: {value}k tokens (e.g., "16k")", "Max peak context per sub-task: {value}k tokens (e.g., "12k")", "This sub-task's estimated peak context: {value}k tokens (e.g., "10k")". Also added note: "The units must be clarified."
|
||||
|
||||
### Bug 10: Orchestrator — Sub-task PARENT_SPEC.md doesn't include sub-task scope (MEDIUM — FIXED)
|
||||
- **Severity**: Medium
|
||||
- **Location**: `prompts/orchestrate.md`, "Sub-Task Parent Specification" section
|
||||
- **Description**: The PARENT_SPEC.md is supposed to contain "the parent task's SPEC.md content" and "any context the sub-task needs from the parent." But it doesn't include the sub-task's own scope/acceptance criteria from the DECOMPOSITION.md.
|
||||
- **Reproduction**: Parent task's SPEC.md has 5 requirements. The DECOMPOSITION.md says sub-task A is only for requirements 1-2. The PARENT_SPEC.md only contains the parent's SPEC.md (all 5 requirements).
|
||||
- **Fix Applied**: Changed the PARENT_SPEC.md content to include "The sub-task's own scope/acceptance criteria from the DECOMPOSITION.md" and added: "Do NOT include the parent task's full SPEC.md — this can cause circular references if the parent's SPEC.md references the sub-task's SPEC.md files."
|
||||
|
||||
### Bug 11: Orchestrator — No mechanism to handle sub-task failures in parent (HIGH — FIXED)
|
||||
- **Severity**: High
|
||||
- **Location**: `prompts/orchestrate.md`, "Sub-Task Completion and Parent Task" section
|
||||
- **Description**: When a sub-task FAILs or NEEDS_REVIEW, the Orchestrator reports "human intervention is required" but doesn't create fix tasks for the failing sub-task.
|
||||
- **Reproduction**: Sub-task A FAILs. The Orchestrator reports "human intervention is required." The parent task is stuck.
|
||||
- **Fix Applied**: Added fix task creation for sub-tasks in Manual Mode: "Task name: `{parent-task-name}-fix-{sub-task-name}` (e.g., `add-user-auth-fix-auth-gateway`) — The Orchestrator creates the folder with an empty `IMPLEMENTATION.md` — The task starts at the **Bug Find** phase — The Orchestrator copies the sub-task's `SPEC.md`, `BUG_REPORT.md`, and `ADVERSARIAL_BUG_REPORT.md` (if they exist) into the new task folder"
|
||||
|
||||
### Bug 12: Orchestrator — Auto-detect VRAM doesn't handle missing detection script (MEDIUM — FIXED)
|
||||
- **Severity**: Medium
|
||||
- **Location**: `prompts/orchestrate.md`, "VRAM Detection" section
|
||||
- **Description**: The Orchestrator's VRAM detection priority says "Auto-detect via script: Run {project}/.automaton/scripts/vram_detect.sh". If the script is not available, it falls back to "Auto-detect via API config." But the Orchestrator doesn't check if the detection script exists before trying to run it.
|
||||
- **Reproduction**: User starts a new task. The Orchestrator tries to run `{project}/.automaton/scripts/vram_detect.sh` but the script doesn't exist.
|
||||
- **Fix Applied**: Added: "Check if `{project}/.automaton/scripts/vram_detect.sh` exists. If it does, run it..." and "If the detection script does not exist, skip to the next detection method."
|
||||
|
||||
### Bug 13: Orchestrator — Auto-detect VRAM doesn't handle script failure (MEDIUM — FIXED)
|
||||
- **Severity**: Medium
|
||||
- **Location**: `prompts/orchestrate.md`, "VRAM Detection" section
|
||||
- **Description**: Even if the detection script exists, it might fail (e.g., `nvidia-smi` is not installed, the GPU is busy, etc.). The Orchestrator doesn't handle script failures gracefully.
|
||||
- **Reproduction**: The detection script exists but `nvidia-smi` is not installed. The script fails with an error.
|
||||
- **Fix Applied**: Added: "If the detection script fails (e.g., `nvidia-smi` is not installed, the GPU is busy, etc.), check the exit code and fall back to the next detection method."
|
||||
|
||||
### Bug 14: Orchestrator — Sub-task completion doesn't aggregate verdicts for parent (MEDIUM — FIXED)
|
||||
- **Severity**: Medium
|
||||
- **Location**: `prompts/orchestrate.md`, "Sub-Task Verdict Reporting" section
|
||||
- **Description**: The Orchestrator says "The Orchestrator should aggregate sub-task verdicts when reporting the parent task's status." But it doesn't actually implement this aggregation.
|
||||
- **Reproduction**: Parent task has 3 sub-tasks. Two PASS, one FAIL. The Orchestrator reports the parent task as "Complete" because it doesn't aggregate sub-task verdicts.
|
||||
- **Fix Applied**: Added: "The Orchestrator MUST aggregate sub-task verdicts when reporting the parent task's status: If ANY sub-task FAILs or NEEDS_REVIEW, the parent task should be marked as **Human Intervention** regardless of whether the parent's own VERDICT.md says PASS."
|
||||
|
||||
### Bug 15: Orchestrator — No mechanism to handle sub-task "Tie-Breaks" (LOW — FIXED)
|
||||
- **Severity**: Low
|
||||
- **Location**: `prompts/referee.md`
|
||||
- **Description**: The referee has "Tasks for Review / Tie-Breaks" but the Orchestrator doesn't have logic to handle sub-task tie-breaks.
|
||||
- **Reproduction**: Sub-task A has tie-breaks. The Orchestrator doesn't create tie-break tasks for the sub-task.
|
||||
- **Fix Applied**: Added: "If a sub-task has 'Tasks for Review / Tie-Breaks' in its VERDICT.md, the Orchestrator should create tie-break tasks for the sub-task: Task name: `{parent-task-name}-tiebreak-{sub-task-name}`"
|
||||
|
||||
### Bug 16: Orchestrator — State Determination doesn't check for empty artifacts (MEDIUM — FIXED)
|
||||
- **Severity**: Medium
|
||||
- **Location**: `prompts/orchestrate.md`, "State Determination" section
|
||||
- **Description**: The Orchestrator checks for the existence of artifacts (e.g., "Has `SPEC.md`") but doesn't check if they are empty.
|
||||
- **Reproduction**: Research phase produces an empty `SPEC.md`. The Orchestrator checks for `SPEC.md` and sees it exists, so it classifies the task as "Design" (optional) or "Implement".
|
||||
- **Fix Applied**: Added "(non-empty)" after every artifact check: "Has `VERDICT.md` with `PASS` (non-empty)", "Has `DOC_REVIEW.md` (non-empty)", etc.
|
||||
|
||||
### Bug 17: Orchestrator — "Continue" doesn't prioritize sub-tasks in the same wave (MEDIUM — FIXED)
|
||||
- **Severity**: Medium
|
||||
- **Location**: `prompts/orchestrate.md`, "Continue from existing tasks" section
|
||||
- **Description**: When the user says "orchestrate" or "continue", the Orchestrator should prioritize sub-tasks in the same wave that are still in progress.
|
||||
- **Reproduction**: Wave 1 has sub-tasks A, B, and C. A is in the Research phase, B is in the Implement phase, and C is in the Bug Find phase. The Orchestrator picks A (Research phase) instead of C (Bug Find phase).
|
||||
- **Fix Applied**: Added: "When choosing among sub-tasks in the same wave, prioritize those in later phases (e.g., Bug Find over Research) because they are closer to completion."
|
||||
|
||||
### Bug 18: Orchestrator — Auto-Execution Rules section is duplicated (LOW — FIXED)
|
||||
- **Severity**: Low
|
||||
- **Location**: `prompts/orchestrate.md`, "Auto-Execution Rules (Autopilot Mode Only)" section
|
||||
- **Description**: The section "Auto-Execution Rules (Autopilot Mode Only)" appears after the "Auto-Execution Loop" section and contains overlapping rules.
|
||||
- **Reproduction**: Read the file; observe that the Auto-Execution Loop and Auto-Execution Rules sections contain overlapping rules.
|
||||
- **Fix Applied**: Consolidated the Auto-Execution Loop and Auto-Execution Rules sections into a single section with additional rules for artifact validation, timeout, iteration limit, and sub-task parallel execution.
|
||||
|
||||
---
|
||||
|
||||
## Adversarial Bugs Found and Fixed
|
||||
|
||||
### Adversarial Bug 1: Orchestrator — Auto-execution loop can run infinitely (CRITICAL — FIXED)
|
||||
- **Severity**: Critical
|
||||
- **Location**: `prompts/orchestrate.md`, "Auto-Execution Loop" section
|
||||
- **Description**: The auto-execution loop has no maximum iteration count or timeout. If the agent produces an artifact but doesn't output CONTRACT_MET, the loop will spin forever.
|
||||
- **Fix Applied**: Added to the loop: "if iteration_count >= MAX_ITERATIONS (default: 10): break (human intervention needed — too many iterations)", "if total_time_elapsed >= MAX_TOTAL_TIME (default: 24 hours): break (human intervention needed — too much time elapsed)", "if phase_time_elapsed >= MAX_PHASE_TIME (default: 1 hour): break (human intervention needed — phase took too long)"
|
||||
|
||||
### Adversarial Bug 2: Orchestrator — Sub-task creation doesn't prevent duplicate sub-tasks (HIGH — FIXED)
|
||||
- **Severity**: High
|
||||
- **Location**: `prompts/orchestrate.md`, "Sub-Task Management" section
|
||||
- **Description**: When the Orchestrator creates sub-task folders, it doesn't check if they already exist.
|
||||
- **Fix Applied**: Added: "Check for existing sub-task folders: For each sub-task, check if the folder `tasks/{parent-task-name}/subtasks/{sub-task-name}/` already exists. If it does, skip the creation and report that the sub-task has already been created."
|
||||
|
||||
### Adversarial Bug 3: Orchestrator — Auto-detect VRAM can cause resource exhaustion (HIGH — FIXED)
|
||||
- **Severity**: High
|
||||
- **Location**: `prompts/orchestrate.md`, "VRAM Detection" section
|
||||
- **Description**: If the VRAM detection script is run in a loop (e.g., the Orchestrator is invoked multiple times), it will repeatedly probe the GPU and RAM, causing performance degradation.
|
||||
- **Fix Applied**: Added VRAM detection caching: "When the Orchestrator is invoked multiple times (e.g., the user says 'orchestrate' twice), it MUST cache the VRAM detection results and reuse them instead of running the detection script again."
|
||||
|
||||
### Adversarial Bug 4: Orchestrator — Sub-task completion doesn't check for orphaned sub-tasks (HIGH — FIXED)
|
||||
- **Severity**: High
|
||||
- **Location**: `prompts/orchestrate.md`, "Sub-Task Completion and Parent Task" section
|
||||
- **Description**: The Orchestrator doesn't check if there are orphaned sub-tasks — sub-tasks that were created by the Orchestrator but are no longer referenced in the DECOMPOSITION.md.
|
||||
- **Fix Applied**: Added: "Check for orphaned sub-tasks: Before checking completion, verify that each sub-task is still referenced in the DECOMPOSITION.md. If a sub-task is orphaned (no longer in the DECOMPOSITION.md), remove it from the parent's completion check."
|
||||
|
||||
### Adversarial Bug 5: Orchestrator — Auto-execution loop doesn't handle concurrent sub-tasks (HIGH — FIXED)
|
||||
- **Severity**: High
|
||||
- **Location**: `prompts/orchestrate.md`, "Auto-Execution Loop" section
|
||||
- **Description**: The auto-execution loop only drives one sub-task at a time, even when sub-tasks are in the same wave and can run in parallel.
|
||||
- **Fix Applied**: Added: "Sub-task Parallel Execution: When sub-tasks are in the same wave and can run in parallel, the Orchestrator should drive them simultaneously instead of sequentially."
|
||||
|
||||
### Adversarial Bug 6: Orchestrator — State Determination can produce ambiguous states (MEDIUM — FIXED)
|
||||
- **Severity**: Medium
|
||||
- **Location**: `prompts/orchestrate.md`, "State Determination" section
|
||||
- **Description**: The state determination has multiple overlapping conditions that can produce ambiguous states.
|
||||
- **Fix Applied**: Added: "Note on overlapping conditions: If a task has both `TEST_PLAN.md` and `DESIGN.md`, the Orchestrator should prioritize the more advanced state (TEST_PLAN.md → Implement) over the optional state (DESIGN.md → Test Design). Similarly, if a task has both `IMPLEMENTATION.md` and `BUG_REPORT.md`, the Orchestrator should prioritize the more advanced state (BUG_REPORT.md → Adversarial Bug Find) over the earlier state (IMPLEMENTATION.md → Bug Find)."
|
||||
|
||||
### Adversarial Bug 7: Orchestrator — Sub-task PARENT_SPEC.md can cause circular references (MEDIUM — FIXED)
|
||||
- **Severity**: Medium
|
||||
- **Location**: `prompts/orchestrate.md`, "Sub-Task Parent Specification" section
|
||||
- **Description**: The PARENT_SPEC.md contains the parent task's SPEC.md content. If the parent's SPEC.md references the sub-task's SPEC.md files, a circular reference is created.
|
||||
- **Fix Applied**: Changed the PARENT_SPEC.md content to include "The sub-task's own scope/acceptance criteria from the DECOMPOSITION.md" and added: "Do NOT include the parent task's full SPEC.md — this can cause circular references if the parent's SPEC.md references the sub-task's SPEC.md files."
|
||||
|
||||
### Adversarial Bug 8: Orchestrator — Auto-detect VRAM can cause memory exhaustion (MEDIUM — FIXED)
|
||||
- **Severity**: Medium
|
||||
- **Location**: `prompts/orchestrate.md`, "VRAM Detection" section
|
||||
- **Description**: If the detection script doesn't exist, the Orchestrator tries to read multiple config files to detect the model name. If the .env file is large, reading it could cause memory exhaustion.
|
||||
- **Fix Applied**: Added: "Only read the specific lines needed (e.g., the model name line), not the entire file. Limit file reads to 10KB to prevent memory exhaustion."
|
||||
|
||||
### Adversarial Bug 9: Orchestrator — Sub-task completion doesn't handle sub-task failures gracefully (HIGH — FIXED)
|
||||
- **Severity**: High
|
||||
- **Location**: `prompts/orchestrate.md`, "Sub-Task Completion and Parent Task" section
|
||||
- **Description**: When a sub-task FAILs during the Referee phase (before producing BUG_REPORT.md and ADVERSARIAL_BUG_REPORT.md), the Orchestrator wouldn't have the bug reports needed to create a fix task.
|
||||
- **Fix Applied**: Added: "If the sub-task failed during the Referee phase (before producing BUG_REPORT.md and ADVERSARIAL_BUG_REPORT.md), the Orchestrator still creates the fix task but only copies the artifacts that exist (BUG_REPORT.md if it exists, ADVERSARIAL_BUG_REPORT.md if it exists)."
|
||||
|
||||
### Adversarial Bug 10: Orchestrator — Sub-task creation doesn't handle DECOMPOSITION.md updates (MEDIUM — FIXED)
|
||||
- **Severity**: Medium
|
||||
- **Location**: `prompts/orchestrate.md`, "Sub-Task Management" section
|
||||
- **Description**: If the DECOMPOSITION.md is updated after the Orchestrator has already created sub-task folders, the Orchestrator doesn't handle the update.
|
||||
- **Fix Applied**: Added: "Check for DECOMPOSITION.md updates: Compare the DECOMPOSITION.md with the existing sub-task folders. If the DECOMPOSITION.md has been updated (new sub-tasks added or existing sub-tasks removed), update the sub-task folders accordingly."
|
||||
|
||||
### Adversarial Bug 11: Orchestrator — Auto-execution loop doesn't handle phase timeouts (MEDIUM — FIXED)
|
||||
- **Severity**: Medium
|
||||
- **Location**: `prompts/orchestrate.md`, "Auto-Execution Loop" section
|
||||
- **Description**: The auto-execution loop doesn't have a timeout for each phase.
|
||||
- **Fix Applied**: Added to the loop: "if phase_time_elapsed >= MAX_PHASE_TIME (default: 1 hour): break (human intervention needed — phase took too long)"
|
||||
|
||||
### Adversarial Bug 12: Orchestrator — Sub-task VRAM_CONFIG.md doesn't include sub-task-specific VRAM limits (MEDIUM — FIXED)
|
||||
- **Severity**: Medium
|
||||
- **Location**: `prompts/orchestrate.md`, "Sub-Task Verdict Reporting" section
|
||||
- **Description**: The VRAM_CONFIG.md includes "Max peak context per sub-task: {from detection script or config.md override}" which is the global max peak context from the detection script. But it doesn't include the sub-task's own estimated peak context from the DECOMPOSITION.md.
|
||||
- **Fix Applied**: Added to the VRAM_CONFIG.md template: "This sub-task's estimated peak context: {from DECOMPOSITION.md}k tokens (e.g., "10k")" and "Fits within VRAM: Yes/No"
|
||||
|
||||
---
|
||||
|
||||
## Score
|
||||
|
||||
| Bug | Severity | Score | Status |
|
||||
|-----|----------|-------|--------|
|
||||
| 1 | Critical | +10 | **FIXED** — State determination reordered |
|
||||
| 2 | Medium | +5 | **FIXED** — Duplicate paragraph removed |
|
||||
| 3 | High | +5 | **FIXED** — Empty IMPLEMENTATION.md creation removed |
|
||||
| 4 | High | +5 | **FIXED** — VERDICT.md check added |
|
||||
| 5 | High | +5 | **FIXED** — Orphaned sub-tasks check added |
|
||||
| 6 | Medium | +5 | **FIXED** — Wave enforcement added |
|
||||
| 7 | Medium | +5 | **FIXED** — Sub-task prioritization added |
|
||||
| 8 | High | +5 | **FIXED** — Artifact validation added |
|
||||
| 9 | Low | +1 | **FIXED** — Units clarified in VRAM_CONFIG.md |
|
||||
| 10 | Medium | +5 | **FIXED** — Sub-task scope added to PARENT_SPEC.md |
|
||||
| 11 | High | +5 | **FIXED** — Sub-task fix task creation added |
|
||||
| 12 | Medium | +5 | **FIXED** — Script existence check added |
|
||||
| 13 | Medium | +5 | **FIXED** — Script failure handling added |
|
||||
| 14 | Medium | +5 | **FIXED** — Sub-task verdict aggregation added |
|
||||
| 15 | Low | +1 | **FIXED** — Sub-task tie-break task creation added |
|
||||
| 16 | Medium | +5 | **FIXED** — Empty artifact checks added |
|
||||
| 17 | Medium | +5 | **FIXED** — Sub-task wave prioritization added |
|
||||
| 18 | Low | +1 | **FIXED** — Auto-Execution Rules consolidated |
|
||||
| Adv1 | Critical | +10 | **FIXED** — Auto-execution loop timeout/iteration limit added |
|
||||
| Adv2 | High | +5 | **FIXED** — Duplicate sub-task prevention added |
|
||||
| Adv3 | High | +5 | **FIXED** — VRAM detection caching added |
|
||||
| Adv4 | High | +5 | **FIXED** — Orphaned sub-tasks check added |
|
||||
| Adv5 | High | +5 | **FIXED** — Sub-task parallel execution added |
|
||||
| Adv6 | Medium | +5 | **FIXED** — Overlapping conditions note added |
|
||||
| Adv7 | Medium | +5 | **FIXED** — Circular reference prevention added |
|
||||
| Adv8 | Medium | +5 | **FIXED** — Memory exhaustion prevention added |
|
||||
| Adv9 | High | +5 | **FIXED** — Graceful sub-task failure handling added |
|
||||
| Adv10 | Medium | +5 | **FIXED** — DECOMPOSITION.md update handling added |
|
||||
| Adv11 | Medium | +5 | **FIXED** — Phase timeout added |
|
||||
| Adv12 | Medium | +5 | **FIXED** — Sub-task VRAM limit added to VRAM_CONFIG.md |
|
||||
| **Total** | | **143** | |
|
||||
@@ -0,0 +1,91 @@
|
||||
# Onboarding a Project
|
||||
|
||||
This document defines the **Agent Protocol** for initializing a new project. When the agent is asked to "Onboard a project," it must follow these steps.
|
||||
|
||||
## The Exploration Ritual
|
||||
|
||||
The agent's first task in any project is to perform an "Initial Exploration" to establish context.
|
||||
|
||||
### Step 1: Discovery
|
||||
The agent must:
|
||||
1. Explore the project root using `ls` and `find`.
|
||||
2. Read `.automaton/.agent.md`
|
||||
3. Read `.automaton/.rules.md`
|
||||
4. Read the global `~/.automaton/.agent.md`
|
||||
|
||||
### Step 2: Reporting
|
||||
The agent must report back with:
|
||||
- Confirmation that the framework files were found and read.
|
||||
- A summary of the project rules.
|
||||
- The expected workflow for this project.
|
||||
- Key observations from the project structure.
|
||||
|
||||
---
|
||||
|
||||
## The Lifecycle of a Project
|
||||
|
||||
Once onboarded, the project moves through these phases. The agent should use the provided prompts to transition between them.
|
||||
|
||||
### Easier workflow with "orchestrate"
|
||||
|
||||
Instead of memorizing trigger phrases for each phase, you can just say **"orchestrate"** or **"continue"** and the Orchestrator will:
|
||||
- In **Autopilot mode**: automatically drive the task all the way to completion
|
||||
- In **manual mode**: tell you the next step and give you the command
|
||||
|
||||
### Phase 1: Research
|
||||
**Template**: `prompts/research.md`
|
||||
**Output**: `SPEC.md`
|
||||
**Trigger**: *"Research {task-description}"* (or just *"orchestrate"* in manual mode)
|
||||
**Interaction**: Agent will grill you for requirements, edge cases, and constraints. Present draft for review. Get your sign-off before finalizing.
|
||||
|
||||
### Phase 1b: Design (Optional)
|
||||
**Template**: `prompts/design.md`
|
||||
**Output**: `DESIGN.md`
|
||||
**Trigger**: *"Design the {task-name} task"* (or just *"orchestrate"* in manual mode)
|
||||
**Interaction**: Agent will grill you for design decisions, trade-offs, and constraints. Present draft for review. Get your sign-off before finalizing.
|
||||
|
||||
### Phase 1c: Test Design (Optional)
|
||||
**Template**: `prompts/test_design.md`
|
||||
**Output**: `TEST_PLAN.md`
|
||||
**Trigger**: *"Design tests for the {task-name} task"* (or just *"orchestrate"* in manual mode)
|
||||
**Interaction**: Agent will grill you for test coverage, edge cases, and test strategy. Present draft for review. Get your sign-off before finalizing.
|
||||
|
||||
### Phase 2: Implementation
|
||||
**Template**: `prompts/implement.md`
|
||||
**Output**: Code changes + test results
|
||||
**Trigger**: *"Implement the {task-name} task"* (or just *"orchestrate"* in manual mode)
|
||||
**Note**: The implementer follows the TEST_PLAN.md (if present) and implements code with tests using TDD.
|
||||
|
||||
### Phase 3: Bug Finding
|
||||
**Template**: `prompts/bug_finder.md`
|
||||
**Output**: `BUG_REPORT.md`
|
||||
**Trigger**: *"Find bugs in the {task-name} task"* (or just *"orchestrate"* in manual mode)
|
||||
|
||||
### Phase 4: Adversarial Verification
|
||||
**Template**: `prompts/adversarial_bug_find.md`
|
||||
**Output**: `ADVERSARIAL_BUG_REPORT.md`
|
||||
**Trigger**: *"Perform adversarial bug find for {task-name}"* (or just *"orchestrate"* in manual mode)
|
||||
|
||||
### Phase 5: Documentation Review
|
||||
**Template**: `prompts/doc_review.md`
|
||||
**Output**: `DOC_REVIEW.md`
|
||||
**Trigger**: *"Review docs for the {task-name} task"* (or just *"orchestrate"* in manual mode)
|
||||
|
||||
### Phase 6: Referee
|
||||
**Template**: `prompts/referee.md`
|
||||
**Output**: `VERDICT.md`
|
||||
**Trigger**: *"Review the {task-name} task"* (or just *"orchestrate"* in manual mode)
|
||||
|
||||
## Prompt Rendering Convention
|
||||
|
||||
All prompts are stored as template files in `~/.automaton/prompts/`. They use `{placeholder}` syntax.
|
||||
|
||||
### Placeholders
|
||||
- `{project}`: Absolute path to the project root.
|
||||
- `{task-name}`: The task folder name (kebab-case).
|
||||
- `{task-description}`: A brief, clear summary of the current work.
|
||||
|
||||
When the agent receives a trigger command, it must:
|
||||
1. Read the corresponding template file.
|
||||
2. Replace all `{placeholders}` with the actual project values.
|
||||
3. Execute the rendered prompt.
|
||||
@@ -1,4 +1,4 @@
|
||||
# RULES.md
|
||||
# .rules.md
|
||||
|
||||
- Add one rule per observed failure mode with a concrete example.
|
||||
- Consolidate contradictions monthly. Remove stale rules.
|
||||
+72
@@ -0,0 +1,72 @@
|
||||
# Verdict: automaton
|
||||
|
||||
## Status: PASS
|
||||
**Completion Date**: 2026-06-11
|
||||
|
||||
## Summary
|
||||
|
||||
automaton has a **score of 78** from the Bug Finder and **65** from the Adversarial Bug Finder, for a combined score of **143**. All 30 bugs have been fixed. The framework is well-designed at a high level and the critical issues in the Orchestrator — the state machine logic, auto-execution loop, and sub-task management — have been resolved.
|
||||
|
||||
## Findings
|
||||
|
||||
### What Passed
|
||||
- The overall framework architecture is sound — the state machine, phase separation, and artifact-based progression are well-designed
|
||||
- The interactive protocol for Research and Design phases is robust
|
||||
- The VRAM configuration and detection system is comprehensive
|
||||
- The bug finder and adversarial bug finder prompts are thorough and well-structured
|
||||
- The doc review phase fills a genuine gap in the workflow
|
||||
- **All 30 bugs have been fixed**
|
||||
|
||||
### What Failed
|
||||
- **None** — all bugs have been fixed
|
||||
|
||||
### What Needs Review
|
||||
- **None** — all bugs have been fixed
|
||||
|
||||
## Tasks for Review / Tie-Breaks
|
||||
None.
|
||||
|
||||
## Remaining Issues
|
||||
None.
|
||||
|
||||
## Score
|
||||
|
||||
| Bug | Severity | Score | Status |
|
||||
|-----|----------|-------|--------|
|
||||
| 1 | Critical | +10 | **FIXED** — State determination reordered |
|
||||
| 2 | Medium | +5 | **FIXED** — Duplicate paragraph removed |
|
||||
| 3 | High | +5 | **FIXED** — Empty IMPLEMENTATION.md creation removed |
|
||||
| 4 | High | +5 | **FIXED** — VERDICT.md check added |
|
||||
| 5 | High | +5 | **FIXED** — Orphaned sub-tasks check added |
|
||||
| 6 | Medium | +5 | **FIXED** — Wave enforcement added |
|
||||
| 7 | Medium | +5 | **FIXED** — Sub-task prioritization added |
|
||||
| 8 | High | +5 | **FIXED** — Artifact validation added |
|
||||
| 9 | Low | +1 | **FIXED** — Units clarified in VRAM_CONFIG.md |
|
||||
| 10 | Medium | +5 | **FIXED** — Sub-task scope added to PARENT_SPEC.md |
|
||||
| 11 | High | +5 | **FIXED** — Sub-task fix task creation added |
|
||||
| 12 | Medium | +5 | **FIXED** — Script existence check added |
|
||||
| 13 | Medium | +5 | **FIXED** — Script failure handling added |
|
||||
| 14 | Medium | +5 | **FIXED** — Sub-task verdict aggregation added |
|
||||
| 15 | Low | +1 | **FIXED** — Sub-task tie-break task creation added |
|
||||
| 16 | Medium | +5 | **FIXED** — Empty artifact checks added |
|
||||
| 17 | Medium | +5 | **FIXED** — Sub-task wave prioritization added |
|
||||
| 18 | Low | +1 | **FIXED** — Auto-Execution Rules consolidated |
|
||||
| Adv1 | Critical | +10 | **FIXED** — Auto-execution loop timeout/iteration limit added |
|
||||
| Adv2 | High | +5 | **FIXED** — Duplicate sub-task prevention added |
|
||||
| Adv3 | High | +5 | **FIXED** — VRAM detection caching added |
|
||||
| Adv4 | High | +5 | **FIXED** — Orphaned sub-tasks check added |
|
||||
| Adv5 | High | +5 | **FIXED** — Sub-task parallel execution added |
|
||||
| Adv6 | Medium | +5 | **FIXED** — Overlapping conditions note added |
|
||||
| Adv7 | Medium | +5 | **FIXED** — Circular reference prevention added |
|
||||
| Adv8 | Medium | +5 | **FIXED** — Memory exhaustion prevention added |
|
||||
| Adv9 | High | +5 | **FIXED** — Graceful sub-task failure handling added |
|
||||
| Adv10 | Medium | +5 | **FIXED** — DECOMPOSITION.md update handling added |
|
||||
| Adv11 | Medium | +5 | **FIXED** — Phase timeout added |
|
||||
| Adv12 | Medium | +5 | **FIXED** — Sub-task VRAM limit added to VRAM_CONFIG.md |
|
||||
| **Bug Finder Total** | | **78** | |
|
||||
| **Adversarial Bug Finder Total** | | **65** | |
|
||||
| **Combined Score** | | **143** | |
|
||||
|
||||
## Reviewer Comments
|
||||
|
||||
(Leave blank for the human reviewer to provide feedback)
|
||||
@@ -1,12 +0,0 @@
|
||||
# AGENT.md
|
||||
|
||||
IF task type = research → load prompts/research.md + RULES.md
|
||||
IF task type = design → load prompts/design.md + SPEC.md
|
||||
IF task type = implement → load prompts/implement.md + SPEC.md + DESIGN.md + CONTRACT.md
|
||||
IF task type = bug_find → load prompts/bug_finder.md + SPEC.md + code
|
||||
IF task type = adversarial_bug_find → load prompts/adversarial_bug_find.md + SPEC.md + code
|
||||
IF task type = referee → load prompts/referee.md + SPEC.md + BUG_REPORT.md + ADVERSARIAL_BUG_REPORT.md
|
||||
IF task type = orchestrate → load prompts/orchestrate.md + project structure
|
||||
IF task type = compaction → load prompts/compaction.md
|
||||
|
||||
Always start by reading this file to determine mode.
|
||||
@@ -1,66 +0,0 @@
|
||||
# Onboarding a Project
|
||||
|
||||
This document defines the **Agent Protocol** for initializing a new project. When the agent is asked to "Onboard a project," it must follow these steps.
|
||||
|
||||
## The Exploration Ritual
|
||||
|
||||
The agent's first task in any project is to perform an "Initial Exploration" to establish context.
|
||||
|
||||
### Step 1: Discovery
|
||||
The agent must:
|
||||
1. Explore the project root using `ls` and `find`.
|
||||
2. Read `.agent-framework/AGENT.md`
|
||||
3. Read `.agent-framework/RULES.md`
|
||||
4. Read the global `~/.agent-framework/AGENT.md`
|
||||
|
||||
### Step 2: Reporting
|
||||
The agent must report back with:
|
||||
- Confirmation that the framework files were found and read.
|
||||
- A summary of the project rules.
|
||||
- The expected workflow for this project.
|
||||
- Key observations from the project structure.
|
||||
|
||||
---
|
||||
|
||||
## The Lifecycle of a Project
|
||||
|
||||
Once onboarded, the project moves through these phases. The agent should use the provided prompts to transition between them.
|
||||
|
||||
### Phase 1: Research
|
||||
**Template**: `prompts/research.md`
|
||||
**Output**: `SPEC.md`
|
||||
**Trigger**: *"Research {task-description}"*
|
||||
|
||||
### Phase 2: Implementation
|
||||
**Template**: `prompts/implement.md`
|
||||
**Output**: Code changes + test results
|
||||
**Trigger**: *"Implement the {task-name} task"*
|
||||
|
||||
### Phase 3: Bug Finding
|
||||
**Template**: `prompts/bug_finder.md`
|
||||
**Output**: `BUG_REPORT.md`
|
||||
**Trigger**: *"Find bugs in the {task-name} task"*
|
||||
|
||||
### Phase 4: Adversarial Verification
|
||||
**Template**: `prompts/adversarial_bug_find.md`
|
||||
**Output**: `ADVERSARIAL_BUG_REPORT.md`
|
||||
**Trigger**: *"Perform adversarial bug find for {task-name}"*
|
||||
|
||||
### Phase 5: Referee
|
||||
**Template**: `prompts/referee.md`
|
||||
**Output**: `VERDICT.md`
|
||||
**Trigger**: *"Review the {task-name} task"*
|
||||
|
||||
## Prompt Rendering Convention
|
||||
|
||||
All prompts are stored as template files in `~/.agent-framework/prompts/`. They use `{placeholder}` syntax.
|
||||
|
||||
### Placeholders
|
||||
- `{project}`: Absolute path to the project root.
|
||||
- `{task-name}`: The task folder name (kebab-case).
|
||||
- `{task-description}`: A brief, clear summary of the current work.
|
||||
|
||||
When the agent receives a trigger command, it must:
|
||||
1. Read the corresponding template file.
|
||||
2. Replace all `{placeholders}` with the actual project values.
|
||||
3. Execute the rendered prompt.
|
||||
@@ -1,4 +1,4 @@
|
||||
# Agent Framework
|
||||
# Automaton
|
||||
|
||||
A contract-based operating system for LLM agents, designed to enforce disciplined engineering workflows.
|
||||
|
||||
@@ -10,10 +10,10 @@ Before you can use the framework in any project, you must install the core logic
|
||||
|
||||
```bash
|
||||
# Clone the framework into the global config directory
|
||||
git clone [INSERT_FRAMEWORK_REPO_URL_HERE] ~/.agent-framework
|
||||
git clone [INSERT_FRAMEWORK_REPO_URL_HERE] ~/.automaton
|
||||
|
||||
# Enter the directory
|
||||
cd ~/.agent-framework
|
||||
cd ~/.automaton
|
||||
|
||||
# Make the installation script executable and run it
|
||||
chmod +x install.sh
|
||||
@@ -21,6 +21,22 @@ chmod +x install.sh
|
||||
```
|
||||
*Note: This creates the "brain" of the framework (prompts, state machines, and rules) in your home directory.*
|
||||
|
||||
### Updating the Framework
|
||||
|
||||
When the framework is updated, you can update your global installation:
|
||||
|
||||
```bash
|
||||
cd ~/.automaton
|
||||
./update.sh
|
||||
```
|
||||
|
||||
This will:
|
||||
- Fetch the latest changes from the repository
|
||||
- Check for uncommitted changes and warn you
|
||||
- Pull the latest updates
|
||||
|
||||
**Upgrading existing projects:** When the framework is updated, existing projects may need their framework files upgraded (new phases added, new prompts, etc.). To upgrade an existing project, tell the agent: "Upgrade automaton for this project." The agent will check for missing files and update them.
|
||||
|
||||
---
|
||||
|
||||
## 2. Project Setup (Per project)
|
||||
@@ -30,18 +46,18 @@ Once the framework is installed globally, you must "onboard" every individual pr
|
||||
### Option A: The Agent-Driven Way (Recommended)
|
||||
If you want the agent to handle the configuration for you, navigate to your project root and run:
|
||||
|
||||
> *"Onboard this project into the agent-framework."*
|
||||
> *"Onboard this project into automaton."
|
||||
|
||||
The agent will automatically:
|
||||
1. Detect your project type (New, Existing, or Upgrade).
|
||||
2. Create the `./.agent-framework/` directory.
|
||||
3. Generate your `AGENT.md` and `RULES.md` files.
|
||||
2. Create the `./.automaton/` directory.
|
||||
3. Generate your `.agent.md` and `.rules.md` files.
|
||||
4. Initiate the "Exploration Ritual" to understand your codebase.
|
||||
|
||||
### Option B: The Manual Way
|
||||
If you prefer to set it up manually, create a `.agent-framework/` directory in your project root and add:
|
||||
- `AGENT.md`: Project-specific configuration (Mode, rules, etc.).
|
||||
- `RULES.md`: Project-specific constraints and past failure modes.
|
||||
If you prefer to set it up manually, create a `.automaton/` directory in your project root and add:
|
||||
- `.agent.md`: Project-specific configuration (Mode, rules, etc.).
|
||||
- `.rules.md`: Project-specific constraints and past failure modes.
|
||||
|
||||
---
|
||||
|
||||
@@ -49,22 +65,141 @@ If you prefer to set it up manually, create a `.agent-framework/` directory in y
|
||||
The framework features an **Autopilot** mode that allows the agent to drive a project to completion with minimal intervention.
|
||||
|
||||
### Lifecycle of a Task
|
||||
1. **Research**: Produce a `SPEC.md` (Contract). No code allowed.
|
||||
2. **Implement**: Write code and tests based *only* on the `SPEC.md`.
|
||||
3. **Bug Find**: Aggressive search for bugs and spec deviations.
|
||||
4. **Adversarial Bug Find**: Deep search for complex logic errors, race conditions, and performance issues.
|
||||
5. **Referee**: Objective evaluation of all bugs and the final verdict.
|
||||
1. **Research**: Produce a `SPEC.md` (Contract). No code allowed. **Interactive** — agent grills you for requirements and gets sign-off.
|
||||
2. **Decomposition** (optional): Break the task into sub-tasks sized for your VRAM. **Interactive** — agent analyzes the spec and proposes sub-tasks with token budget estimates, gets sign-off. See [VRAM Configuration](#vram-configuration) below.
|
||||
3. **Design** (optional): Produce a `DESIGN.md` (Architecture). No code allowed. **Interactive** — agent grills you for design decisions and gets sign-off.
|
||||
3. **Test Design** (optional): Produce a `TEST_PLAN.md` (Test specification). No code allowed. **Interactive** — agent grills you for test coverage and edge cases, then presents draft test cases for review and sign-off.
|
||||
4. **Implement**: Write code and tests based *only* on the `SPEC.md`, `DESIGN.md` (if present), and `TEST_PLAN.md` (if present). Follow TDD (Red/Green/Refactor). The TEST_PLAN.md (if present) serves as the test specification the implementer follows.
|
||||
5. **Bug Find**: Aggressive search for bugs and spec deviations.
|
||||
6. **Adversarial Bug Find**: Deep search for complex logic errors, race conditions, and performance issues.
|
||||
7. **Doc Review**: Review documentation against DESIGN.md plan and fix missing docs.
|
||||
8. **Referee**: Objective evaluation of all bugs, docs, and the final verdict.
|
||||
|
||||
### How to use Autopilot
|
||||
Add `Autopilot: Enabled` to your project's `.agent-framework/AGENT.md` and use the following command:
|
||||
|
||||
> *"Initialize Autopilot for this project. Scan the tasks/ directory and report the current status of all tasks and the recommended next actions."*
|
||||
#### Autopilot mode (default)
|
||||
The default mode is **Autopilot: Enabled**. The Orchestrator automatically drives tasks through all phases. Just say:
|
||||
- **Start a new task**: "Research add user authentication" (the Orchestrator creates the task and drives it all the way to completion)
|
||||
- **Decompose a task**: "Decompose the add-user-auth task" (the Orchestrator breaks it into sub-tasks sized for your VRAM)
|
||||
- **Continue**: "orchestrate" or "continue" (the Orchestrator finds the most advanced task and drives it)
|
||||
|
||||
#### VRAM Configuration
|
||||
For low-VRAM systems (8GB, 16GB), set your VRAM limits in `~/.automaton/config.md`:
|
||||
|
||||
```markdown
|
||||
## VRAM Configuration
|
||||
- **Auto-detect**: Yes # Let the agent detect your VRAM automatically
|
||||
- **Target VRAM context**: 16k tokens # Override auto-detect if needed
|
||||
- **Headroom**: 25%
|
||||
- **Max peak context per sub-task**: 12k tokens
|
||||
```
|
||||
|
||||
**Auto-detection**: When `Auto-detect: Yes`, the Orchestrator runs `scripts/vram_detect.sh` to probe:
|
||||
- GPU VRAM (via `nvidia-smi`)
|
||||
- System RAM (via `free`)
|
||||
- Model context window (from config.md or API config files)
|
||||
- Framework overhead (by counting token load in loaded prompts)
|
||||
|
||||
**Manual override**: When `Auto-detect: No`, use the manually specified values:
|
||||
|
||||
```markdown
|
||||
## VRAM Configuration
|
||||
- **Auto-detect**: No
|
||||
- **Target VRAM context**: 8k
|
||||
- **Headroom**: 30%
|
||||
- **Max peak context per sub-task**: 5.6k
|
||||
```
|
||||
|
||||
#### Model Configuration
|
||||
When using a local LLM or a specific API model, set the model in `~/.automaton/config.md`:
|
||||
|
||||
```markdown
|
||||
## Model Configuration
|
||||
- **Model**: auto # Use auto-detection from API config files
|
||||
- **Override context window**: auto # Override auto-detection, or specify (e.g., 128k, 200k)
|
||||
```
|
||||
|
||||
**Auto-detection**: When `Model: auto`, the framework detects the model name from API config files (`.env`, `config.yaml`, etc.) and looks up its context window.
|
||||
|
||||
**Manual override**: When you know your model name, specify it:
|
||||
|
||||
```markdown
|
||||
## Model Configuration
|
||||
- **Model**: gpt-4o
|
||||
- **Override context window**: 128k
|
||||
```
|
||||
|
||||
When you run "Decompose the X task", the Orchestrator will:
|
||||
1. Analyze the task's SPEC.md
|
||||
2. Detect VRAM limits (auto or manual)
|
||||
3. Break it into sub-tasks, each sized to fit within your VRAM limit
|
||||
4. Estimate the token budget for each sub-task
|
||||
5. Create sub-task folders under `tasks/{parent-task}/subtasks/{sub-task}/`
|
||||
6. Propagate VRAM config to each sub-task
|
||||
|
||||
Sub-tasks run independently through the full lifecycle. The parent task is complete only when ALL sub-tasks pass.
|
||||
|
||||
#### Manual mode (opt-in)
|
||||
Set `Autopilot: Disabled` in your project's `.automaton/.agent.md` if you prefer to manually run each phase. The Orchestrator reports the current state and tells you the next command. Then run phases by saying things like:
|
||||
- "Research add user authentication" — starts a new task
|
||||
- "Decompose the add-user-auth task" — breaks into VRAM-sized sub-tasks (optional)
|
||||
- "Design the add-user-auth task" — designs the architecture (optional)
|
||||
- "Design tests for the add-user-auth task" — designs test cases (optional)
|
||||
- "Implement the add-user-auth task" — implements the task with tests
|
||||
- "Find bugs in the add-user-auth task" — finds bugs
|
||||
- "Perform adversarial bug find for add-user-auth" — deep bug search
|
||||
- "Review docs for the add-user-auth task" — reviews documentation
|
||||
- "Review the add-user-auth task" — referee evaluates
|
||||
- "orchestrate" — asks the Orchestrator what to do next
|
||||
|
||||
## Sub-Task Management
|
||||
|
||||
When a task is decomposed, the Orchestrator creates sub-tasks under `tasks/{parent-task}/subtasks/`. Each sub-task:
|
||||
|
||||
- Has its own full lifecycle (Research → Decomposition → Design → ... → Complete)
|
||||
- Starts at the Research phase with an empty folder
|
||||
- Receives a `PARENT_SPEC.md` with the parent task's context
|
||||
- Receives a `VRAM_CONFIG.md` with the VRAM constraints
|
||||
- Runs independently — sub-tasks in the same wave can run in parallel
|
||||
- The parent task is NOT complete until ALL sub-tasks pass
|
||||
|
||||
## Key Components
|
||||
- `AGENT.md`: Project-specific configuration and mode selection.
|
||||
- `RULES.md`: Living document of project constraints and past failure modes.
|
||||
- `prompts/`: Specialized system prompts for each phase (Research, Implement, Bug Finder, etc.).
|
||||
- `.agent.md`: Project-specific agent behavior (Autopilot mode, routing rules).
|
||||
- `config.md`: Global framework settings (VRAM, model, system requirements).
|
||||
- `.rules.md`: Living document of project constraints and past failure modes.
|
||||
- `prompts/`: Specialized system prompts for each phase (Research, Design, Test Design, Implement, Bug Finder, Adversarial Bug Finder, Doc Review, Referee, Decompose, etc.).
|
||||
- `workflow.md`: The state machine governing the Autopilot lifecycle.
|
||||
- `test_design.md`: Produces a TEST_PLAN.md — an explicit test specification before implementation.
|
||||
- `decompose.md`: Breaks a task into VRAM-sized sub-tasks.
|
||||
- `scripts/vram_detect.sh`: Auto-detects GPU VRAM, RAM, model context window, and framework overhead.
|
||||
- `contracts/vram_config.md`: Contract for VRAM-aware task decomposition.
|
||||
|
||||
## Layered File System
|
||||
|
||||
The framework uses a **layered approach** to file management, with a clear precedence:
|
||||
|
||||
1. **Project overrides** (highest precedence): `{project}/.automaton/` — contains project-specific customizations
|
||||
2. **Global framework** (default): `~/.automaton/` — contains the base framework files
|
||||
|
||||
**Precedence rule**: If a file exists in the project's `.automaton/` directory, the Orchestrator reads it from there. If it doesn't exist, the Orchestrator reads it from the global `~/.automaton/` directory.
|
||||
|
||||
### What files belong in each layer?
|
||||
|
||||
- **Project's `.automaton/`**: .agent.md (project-specific settings like Autopilot mode, rules override), .rules.md (project-specific constraints)
|
||||
- **Global `~/.automaton/`**: All prompt files, contracts, scripts, config.md, workflow.md
|
||||
|
||||
### Upgrading
|
||||
|
||||
When you upgrade the global framework (e.g., after pushing bug fixes), existing projects may need their framework files upgraded. Tell the agent:
|
||||
|
||||
> "Upgrade automaton for this project."
|
||||
|
||||
The agent will:
|
||||
1. Compare the project's `.automaton/` files with the global `~/.automaton/` files
|
||||
2. **Customized files** — If the project has customized a file (differs from global), **keep the project's version**
|
||||
3. **Outdated files** — If the project's file is identical to the old global version, **update from global**
|
||||
4. **New files** — If the global framework has new files, **add them to the project**
|
||||
5. Report what was upgraded, added, and skipped
|
||||
|
||||
## Contact & Support
|
||||
[Insert Contact Info]
|
||||
|
||||
@@ -0,0 +1,150 @@
|
||||
# Automaton Dashboard
|
||||
|
||||
Interactive web dashboard for monitoring automaton framework task progress.
|
||||
|
||||
## Installation
|
||||
|
||||
The dashboard is part of the automaton framework. No separate installation is needed.
|
||||
|
||||
```bash
|
||||
# From your automaton installation directory
|
||||
python -m automaton.dashboard
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
```bash
|
||||
# Start from the current directory
|
||||
python -m automaton.dashboard
|
||||
|
||||
# Start from a specific project directory
|
||||
python -m automaton.dashboard /path/to/project
|
||||
|
||||
# Custom host/port
|
||||
python -m automaton.dashboard --host 0.0.0.0 --port 3000
|
||||
```
|
||||
|
||||
The dashboard opens in your browser at `http://localhost:8080`.
|
||||
|
||||
## Scope-Aware
|
||||
|
||||
The dashboard automatically detects its scope based on the current working directory:
|
||||
|
||||
- **Framework mode**: When run from `~/.automaton/`, tracks framework development tasks
|
||||
- **Project mode**: When run from a project root (a project that has installed automaton), tracks that project's tasks
|
||||
|
||||
## Views
|
||||
|
||||
### Board View (Default)
|
||||
The primary Kanban board view showing tasks organized by their current phase:
|
||||
|
||||
```
|
||||
Backlog (0) │ Research (1) │ Design (0) │ Implement (0) │ Done (1) │ Blocked (1)
|
||||
──────────────│────────────────│──────────────│─────────────────│──────────────│──────────────
|
||||
— empty — │ ▸ research- │ │ │ ✅ implement │ ❌ bad-impl
|
||||
│ task │ │ │ task │
|
||||
────────────────│───────────────│─────────────────│──────────────│──────────────
|
||||
─ empty — │ ──────────────── │──────────────│──────────────
|
||||
```
|
||||
|
||||
### Statistics View
|
||||
Shows task statistics including phase distribution, pass/fail rates, and sub-task statistics.
|
||||
|
||||
### Timeline View
|
||||
Shows task progress through phases as a timeline with wave visualization for decomposed tasks.
|
||||
|
||||
## Keyboard Shortcuts
|
||||
|
||||
| Key | Action |
|
||||
|-----|--------|
|
||||
| `Space` | Cycle views (Board → Stats → Timeline) |
|
||||
| `1` | Board view |
|
||||
| `2` | Statistics view |
|
||||
| `3` | Timeline view |
|
||||
| `t` | Cycle themes (default → dark → light) |
|
||||
| `r` | Manual refresh |
|
||||
| `f` | Toggle filter bar |
|
||||
| `s` | Focus search |
|
||||
| `?` | Show help |
|
||||
| `Esc` | Close modals / clear search |
|
||||
| `q` | Quit |
|
||||
|
||||
## Configuration
|
||||
|
||||
Create a `dashboard-config.json` file in your project's `.automaton/` directory:
|
||||
|
||||
```json
|
||||
{
|
||||
"auto_refresh_interval": 2,
|
||||
"default_view": "board",
|
||||
"column_width": 30,
|
||||
"show_timelines": true,
|
||||
"theme": "default"
|
||||
}
|
||||
```
|
||||
|
||||
### Configuration Options
|
||||
|
||||
| Option | Type | Default | Description |
|
||||
|--------|------|---------|-------------|
|
||||
| `auto_refresh_interval` | int | 2 | Seconds between auto-refreshes (1-60) |
|
||||
| `default_view` | string | "board" | View to show on startup |
|
||||
| `column_width` | int | 30 | Minimum width of each column in characters |
|
||||
| `show_timelines` | bool | true | Show time elapsed on cards |
|
||||
| `theme` | string | "default" | Color theme ("default", "dark", "light") |
|
||||
|
||||
## Color Themes
|
||||
|
||||
- **Default**: Bright colors on dark background
|
||||
- **Dark**: Dimmed colors for a darker appearance
|
||||
- **Light**: Softer colors for light terminals
|
||||
|
||||
## Phase Mapping
|
||||
|
||||
| Kanban Column | Automaton State | Artifact |
|
||||
|---------------|-----------------|----------|
|
||||
| Backlog | New | No artifacts |
|
||||
| Research | Research | SPEC.md |
|
||||
| Decomposition | Decomposition | SPEC.md + DECOMPOSITION.md |
|
||||
| Design | Design | DESIGN.md |
|
||||
| Test Design | Test Design | TEST_PLAN.md |
|
||||
| Implement | Implement | IMPLEMENTATION.md |
|
||||
| Bug Find | Bug Find | BUG_REPORT.md |
|
||||
| Adversarial Bug Find | Adversarial Bug Find | ADVERSARIAL_BUG_REPORT.md |
|
||||
| Doc Review | Doc Review | DOC_REVIEW.md |
|
||||
| Referee | Referee | VERDICT.md |
|
||||
| Done | Complete | VERDICT.md (PASS) |
|
||||
| Blocked | Human Intervention | VERDICT.md (FAIL/NEEDS_REVIEW) |
|
||||
|
||||
## Architecture
|
||||
|
||||
```
|
||||
automaton/dashboard/
|
||||
├── __init__.py # Package marker
|
||||
├── __main__.py # Entry point (python -m automaton.dashboard)
|
||||
├── config.py # Configuration management
|
||||
├── themes.py # Color themes (for TUI fallback)
|
||||
├── pyproject.toml # Python package config
|
||||
├── README.md # This file
|
||||
├── core/
|
||||
│ ├── scope.py # Scope detection (framework vs project mode)
|
||||
│ ├── task.py # Task model, state machine, artifact parsing
|
||||
│ ├── board.py # Kanban board logic
|
||||
│ ├── stats.py # Statistics calculations
|
||||
│ ├── timeline.py # Timeline data
|
||||
│ └── refresh.py # File system watcher (for future use)
|
||||
└── ui/
|
||||
├── app.py # Web server (HTTP + API endpoints)
|
||||
└── html/
|
||||
├── index.html # Dashboard UI
|
||||
├── styles.css # All styling (3 themes via CSS variables)
|
||||
└── dashboard.js # All UI logic (Kanban, stats, timeline, filtering)
|
||||
```
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Real-time collaboration — single-user only
|
||||
- Task creation/editing — read-only view
|
||||
- Notification system — no push notifications
|
||||
- Calendar integration — no date-based scheduling
|
||||
- External PM tool integration — standalone only
|
||||
@@ -0,0 +1 @@
|
||||
# Automaton Dashboard - Interactive web dashboard for automaton task progress
|
||||
@@ -0,0 +1,43 @@
|
||||
#!/usr/bin/env python3
|
||||
"""Automaton Dashboard - Interactive web dashboard for automaton task progress.
|
||||
|
||||
Usage:
|
||||
python -m automaton.dashboard # Start from current directory
|
||||
python -m automaton.dashboard /path/to/project # Start from specific directory
|
||||
python -m automaton.dashboard --host 0.0.0.0 --port 3000 # Custom host/port
|
||||
|
||||
The dashboard is scope-aware:
|
||||
- When run from ~/.automaton/, it tracks framework development
|
||||
- When run from a project root, it tracks that project's tasks
|
||||
"""
|
||||
|
||||
import argparse
|
||||
import sys
|
||||
from pathlib import Path
|
||||
|
||||
# Add the automaton dashboard to the path
|
||||
sys.path.insert(0, str(Path(__file__).parent.parent.parent))
|
||||
|
||||
from automaton.dashboard.ui.app import DashboardApp
|
||||
|
||||
|
||||
def main():
|
||||
parser = argparse.ArgumentParser(description="Automaton Dashboard")
|
||||
parser.add_argument("path", nargs="?", default=None,
|
||||
help="Project directory (defaults to current directory)")
|
||||
parser.add_argument("--host", default="localhost",
|
||||
help="Host to bind to (default: localhost)")
|
||||
parser.add_argument("--port", type=int, default=8080,
|
||||
help="Port to listen on (default: 8080)")
|
||||
args = parser.parse_args()
|
||||
|
||||
start_path = Path(args.path) if args.path else None
|
||||
app = DashboardApp(start_path=start_path, host=args.host, port=args.port)
|
||||
if not app.initialize():
|
||||
sys.exit(1)
|
||||
|
||||
app.run()
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
@@ -0,0 +1,63 @@
|
||||
"""Dashboard configuration management."""
|
||||
|
||||
import json
|
||||
from dataclasses import dataclass, field, asdict
|
||||
from pathlib import Path
|
||||
from typing import Optional
|
||||
|
||||
DEFAULTS = {
|
||||
"auto_refresh_interval": 2,
|
||||
"default_view": "board",
|
||||
"column_width": 30,
|
||||
"show_timelines": True,
|
||||
"theme": "default",
|
||||
}
|
||||
|
||||
VALID_VIEWS = {"board", "statistics", "timeline"}
|
||||
VALID_THEMES = {"default", "dark", "light"}
|
||||
|
||||
|
||||
@dataclass
|
||||
class DashboardConfig:
|
||||
auto_refresh_interval: int = 2
|
||||
default_view: str = "board"
|
||||
column_width: int = 30
|
||||
show_timelines: bool = True
|
||||
theme: str = "default"
|
||||
|
||||
def validate(self) -> list[str]:
|
||||
errors = []
|
||||
if self.auto_refresh_interval < 1 or self.auto_refresh_interval > 60:
|
||||
errors.append(f"auto_refresh_interval must be 1-60, got {self.auto_refresh_interval}")
|
||||
if self.default_view not in VALID_VIEWS:
|
||||
errors.append(f"default_view must be one of {VALID_VIEWS}, got {self.default_view}")
|
||||
if self.column_width < 10:
|
||||
errors.append(f"column_width must be >= 10, got {self.column_width}")
|
||||
if self.theme not in VALID_THEMES:
|
||||
errors.append(f"theme must be one of {VALID_THEMES}, got {self.theme}")
|
||||
return errors
|
||||
|
||||
def to_dict(self) -> dict:
|
||||
return asdict(self)
|
||||
|
||||
@classmethod
|
||||
def from_dict(cls, data: dict) -> "DashboardConfig":
|
||||
merged = {**DEFAULTS, **data}
|
||||
return cls(**merged)
|
||||
|
||||
@classmethod
|
||||
def from_file(cls, config_path: Path) -> "DashboardConfig":
|
||||
if config_path.exists():
|
||||
with open(config_path) as f:
|
||||
data = json.load(f)
|
||||
return cls.from_dict(data)
|
||||
return cls()
|
||||
|
||||
def save(self, config_path: Path) -> None:
|
||||
config_path.parent.mkdir(parents=True, exist_ok=True)
|
||||
with open(config_path, "w") as f:
|
||||
json.dump(self.to_dict(), f, indent=2)
|
||||
|
||||
|
||||
def get_config_path(project_root: Path) -> Path:
|
||||
return project_root / ".automaton" / "dashboard-config.json"
|
||||
@@ -0,0 +1 @@
|
||||
# Core modules for the dashboard
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
@@ -0,0 +1,92 @@
|
||||
"""Kanban board logic for the dashboard."""
|
||||
|
||||
from collections import defaultdict
|
||||
from typing import Optional
|
||||
from .task import Task, TaskState, COLUMN_HEADERS
|
||||
|
||||
|
||||
class KanbanBoard:
|
||||
# Grouping configuration
|
||||
GROUPS = {
|
||||
"Planning": [
|
||||
TaskState.BACKLOG, TaskState.RESEARCH, TaskState.DECOMPOSITION
|
||||
],
|
||||
"Design": [
|
||||
TaskState.DESIGN, TaskState.TEST_DESIGN
|
||||
],
|
||||
"Implementation": [
|
||||
TaskState.IMPLEMENT
|
||||
],
|
||||
"Verification": [
|
||||
TaskState.BUG_FIND, TaskState.ADV_BUG_FIND, TaskState.DOC_REVIEW, TaskState.REFEREE
|
||||
],
|
||||
"Resolution": [
|
||||
TaskState.DONE, TaskState.BLOCKED
|
||||
],
|
||||
}
|
||||
|
||||
def _build_columns(self) -> dict[TaskState, list[Task]]:
|
||||
columns = {state: [] for state in self.COLUMNS}
|
||||
for task in self.tasks:
|
||||
if task.state in columns:
|
||||
columns[task.state].append(task)
|
||||
else:
|
||||
columns[TaskState.BACKLOG].append(task)
|
||||
return columns
|
||||
|
||||
@property
|
||||
def columns(self) -> dict[TaskState, list[Task]]:
|
||||
return self._columns
|
||||
|
||||
@property
|
||||
def column_order(self) -> list[TaskState]:
|
||||
return self.COLUMNS
|
||||
|
||||
def get_grouped_columns(self) -> dict[str, list[Task]]:
|
||||
grouped = {group_name: [] for group_name in self.GROUPS.keys()}
|
||||
for state, tasks in self._columns.items():
|
||||
for group_name, states in self.GROUPS.items():
|
||||
if state in states:
|
||||
grouped[group_name].extend(tasks)
|
||||
break
|
||||
return grouped
|
||||
|
||||
@property
|
||||
def total_tasks(self) -> int:
|
||||
return len(self.tasks)
|
||||
|
||||
def get_column_width(self, col: TaskState) -> int:
|
||||
header = COLUMN_HEADERS.get(col, col.value)
|
||||
return max(self.column_width, len(header) + 4)
|
||||
|
||||
def filter_columns(
|
||||
self, phase_filter: Optional[TaskState] = None,
|
||||
wave_filter: Optional[str] = None, search_query: Optional[str] = None,
|
||||
) -> dict[TaskState, list[Task]]:
|
||||
filtered = {state: [] for state in self.COLUMNS}
|
||||
for task in self.tasks:
|
||||
if phase_filter and task.state != phase_filter:
|
||||
continue
|
||||
if wave_filter == "no-waves" and task.sub_tasks:
|
||||
continue
|
||||
elif wave_filter == "has-waves" and not task.sub_tasks:
|
||||
continue
|
||||
if search_query:
|
||||
query_lower = search_query.lower()
|
||||
name_match = query_lower in task.name.lower() or query_lower in task.display_name.lower()
|
||||
subtask_match = any(query_lower in st.name.lower() for st in task.sub_tasks)
|
||||
if not name_match and not subtask_match:
|
||||
continue
|
||||
filtered[task.state].append(task)
|
||||
return filtered
|
||||
|
||||
def get_tasks_by_state(self, state: TaskState) -> list[Task]:
|
||||
return self._columns.get(state, [])
|
||||
|
||||
def get_wip_count(self) -> int:
|
||||
wip_states = [
|
||||
TaskState.RESEARCH, TaskState.DECOMPOSITION, TaskState.DESIGN,
|
||||
TaskState.TEST_DESIGN, TaskState.IMPLEMENT, TaskState.BUG_FIND,
|
||||
TaskState.ADV_BUG_FIND, TaskState.DOC_REVIEW, TaskState.REFEREE,
|
||||
]
|
||||
return sum(len(self._columns.get(s, [])) for s in wip_states)
|
||||
@@ -0,0 +1,84 @@
|
||||
"""File system watcher for auto-refresh."""
|
||||
|
||||
import time
|
||||
from pathlib import Path
|
||||
from typing import Callable, Optional
|
||||
from threading import Thread, Event
|
||||
|
||||
try:
|
||||
import inotify.adapters
|
||||
HAS_INOTIFY = True
|
||||
except ImportError:
|
||||
HAS_INOTIFY = False
|
||||
|
||||
|
||||
class FileSystemWatcher:
|
||||
def __init__(self, tasks_dir: Path, callback: Optional[Callable] = None):
|
||||
self.tasks_dir = tasks_dir
|
||||
self.callback = callback
|
||||
self._running = False
|
||||
self._thread: Optional[Thread] = None
|
||||
self._stop_event = Event()
|
||||
|
||||
def start(self) -> None:
|
||||
if not self.tasks_dir.exists():
|
||||
return
|
||||
self._running = True
|
||||
self._stop_event.clear()
|
||||
if HAS_INOTIFY:
|
||||
self._thread = Thread(target=self._watch_inotify, daemon=True)
|
||||
else:
|
||||
self._thread = Thread(target=self._watch_polling, daemon=True)
|
||||
self._thread.start()
|
||||
|
||||
def stop(self) -> None:
|
||||
self._running = False
|
||||
self._stop_event.set()
|
||||
if self._thread and self._thread.is_alive():
|
||||
self._thread.join(timeout=1)
|
||||
|
||||
def _watch_inotify(self) -> None:
|
||||
try:
|
||||
watcher = inotify.adapters.Inotify()
|
||||
watcher.add_watch(self.tasks_dir)
|
||||
while self._running and not self._stop_event.is_set():
|
||||
try:
|
||||
events = watcher.inotify_read(timeout_ms=1000)
|
||||
for event in events:
|
||||
if self._stop_event.is_set():
|
||||
break
|
||||
if self.callback:
|
||||
self.callback()
|
||||
except Exception:
|
||||
if self.callback:
|
||||
self.callback()
|
||||
time.sleep(1)
|
||||
watcher.remove_watch(self.tasks_dir)
|
||||
except Exception:
|
||||
self._watch_polling()
|
||||
|
||||
def _watch_polling(self) -> None:
|
||||
last_hash = _dir_hash(self.tasks_dir)
|
||||
while self._running and not self._stop_event.is_set():
|
||||
time.sleep(2)
|
||||
if self._stop_event.is_set():
|
||||
break
|
||||
current_hash = _dir_hash(self.tasks_dir)
|
||||
if current_hash != last_hash:
|
||||
last_hash = current_hash
|
||||
if self.callback:
|
||||
self.callback()
|
||||
|
||||
|
||||
def _dir_hash(directory: Path) -> str:
|
||||
if not directory.exists():
|
||||
return ""
|
||||
entries = []
|
||||
for item in sorted(directory.rglob("*")):
|
||||
if item.is_file():
|
||||
try:
|
||||
stat = item.stat()
|
||||
entries.append(f"{item.name}:{stat.st_mtime}:{stat.st_size}")
|
||||
except (OSError, IOError):
|
||||
pass
|
||||
return "|".join(entries)
|
||||
@@ -0,0 +1,25 @@
|
||||
"""Scope detection for the dashboard."""
|
||||
|
||||
from pathlib import Path
|
||||
|
||||
|
||||
def find_automaton_root(start: Path | None = None) -> Path | None:
|
||||
if start is None:
|
||||
start = Path.cwd()
|
||||
current = start.resolve()
|
||||
while current != current.parent:
|
||||
automaton = current / ".automaton"
|
||||
if automaton.exists() and automaton.is_dir():
|
||||
return current
|
||||
current = current.parent
|
||||
return None
|
||||
|
||||
|
||||
def detect_scope(start: Path | None = None) -> tuple[Path | None, str]:
|
||||
project_root = find_automaton_root(start)
|
||||
if project_root is None:
|
||||
return None, "none"
|
||||
home = Path.home().resolve()
|
||||
if project_root.resolve() == home:
|
||||
return project_root, "framework"
|
||||
return project_root, "project"
|
||||
@@ -0,0 +1,123 @@
|
||||
"""Statistics calculations for the dashboard."""
|
||||
|
||||
from collections import defaultdict
|
||||
from .task import Task, TaskState, VERDICT_PASS, VERDICT_FAIL, VERDICT_NEEDS_REVIEW, COLUMN_HEADERS
|
||||
|
||||
|
||||
class TaskStats:
|
||||
def __init__(self, tasks: list[Task]):
|
||||
self.tasks = tasks
|
||||
|
||||
@property
|
||||
def total_tasks(self) -> int:
|
||||
return len(self.tasks)
|
||||
|
||||
@property
|
||||
def tasks_by_phase(self) -> dict[TaskState, int]:
|
||||
counts = defaultdict(int)
|
||||
for task in self.tasks:
|
||||
counts[task.state] += 1
|
||||
return dict(counts)
|
||||
|
||||
@property
|
||||
def pass_count(self) -> int:
|
||||
return sum(1 for t in self.tasks if t.is_done)
|
||||
|
||||
@property
|
||||
def fail_count(self) -> int:
|
||||
return sum(1 for t in self.tasks if t.is_blocked)
|
||||
|
||||
@property
|
||||
def in_progress_count(self) -> int:
|
||||
wip_states = [
|
||||
TaskState.RESEARCH, TaskState.DECOMPOSITION, TaskState.DESIGN,
|
||||
TaskState.TEST_DESIGN, TaskState.IMPLEMENT, TaskState.BUG_FIND,
|
||||
TaskState.ADV_BUG_FIND, TaskState.DOC_REVIEW, TaskState.REFEREE,
|
||||
]
|
||||
return sum(1 for t in self.tasks if t.state in wip_states)
|
||||
|
||||
@property
|
||||
def backlog_count(self) -> int:
|
||||
return sum(1 for t in self.tasks if t.state == TaskState.BACKLOG)
|
||||
|
||||
@property
|
||||
def pass_rate(self) -> float:
|
||||
if self.total_tasks == 0:
|
||||
return 0.0
|
||||
return (self.pass_count / self.total_tasks) * 100
|
||||
|
||||
@property
|
||||
def fail_rate(self) -> float:
|
||||
if self.total_tasks == 0:
|
||||
return 0.0
|
||||
return (self.fail_count / self.total_tasks) * 100
|
||||
|
||||
@property
|
||||
def sub_task_stats(self) -> dict[str, dict[str, int]]:
|
||||
stats = {}
|
||||
for task in self.tasks:
|
||||
if task.sub_tasks:
|
||||
total = len(task.sub_tasks)
|
||||
passed = sum(1 for st in task.sub_tasks if st.verdict_status == VERDICT_PASS)
|
||||
failed = sum(1 for st in task.sub_tasks if st.verdict_status == VERDICT_FAIL)
|
||||
needs_review = sum(1 for st in task.sub_tasks if st.verdict_status == VERDICT_NEEDS_REVIEW)
|
||||
incomplete = total - passed - failed - needs_review
|
||||
stats[task.name] = {"total": total, "passed": passed, "failed": failed,
|
||||
"needs_review": needs_review, "incomplete": incomplete}
|
||||
return stats
|
||||
|
||||
@property
|
||||
def wave_stats(self) -> dict[str, dict[str, int]]:
|
||||
stats = {}
|
||||
for task in self.tasks:
|
||||
if task.sub_tasks:
|
||||
half = len(task.sub_tasks) // 2
|
||||
if half > 0:
|
||||
wave1 = task.sub_tasks[:half]
|
||||
wave2 = task.sub_tasks[half:]
|
||||
else:
|
||||
wave1 = task.sub_tasks
|
||||
wave2 = []
|
||||
wave1_done = sum(1 for st in wave1 if st.has_verdict and st.verdict_status == VERDICT_PASS)
|
||||
wave2_done = sum(1 for st in wave2 if st.has_verdict and st.verdict_status == VERDICT_PASS)
|
||||
stats[task.name] = {"wave1_total": len(wave1), "wave1_done": wave1_done,
|
||||
"wave2_total": len(wave2), "wave2_done": wave2_done}
|
||||
return stats
|
||||
|
||||
def get_bar_chart(self, width: int = 50) -> str:
|
||||
if self.total_tasks == 0:
|
||||
return " No tasks"
|
||||
phase_counts = self.tasks_by_phase
|
||||
max_count = max(phase_counts.values()) if phase_counts else 1
|
||||
lines = []
|
||||
lines.append(f" Task Distribution by Phase (Total: {self.total_tasks})")
|
||||
lines.append(" " + "─" * width)
|
||||
for state in TaskState:
|
||||
count = phase_counts.get(state, 0)
|
||||
if count == 0:
|
||||
continue
|
||||
bar_width = max(1, int((count / max_count) * (width - 20)))
|
||||
bar = "█" * bar_width
|
||||
header = COLUMN_HEADERS.get(state, state.value)
|
||||
lines.append(f" {header:<20} {bar} {count}")
|
||||
lines.append(" " + "─" * width)
|
||||
lines.append(f" In Progress: {self.in_progress_count} | Done: {self.pass_count} | Blocked: {self.fail_count}")
|
||||
return "\n".join(lines)
|
||||
|
||||
def get_summary(self) -> str:
|
||||
lines = []
|
||||
lines.append(f" Task Statistics Summary")
|
||||
lines.append(" " + "─" * 40)
|
||||
lines.append(f" Total Tasks: {self.total_tasks}")
|
||||
lines.append(f" In Progress: {self.in_progress_count}")
|
||||
lines.append(f" Completed: {self.pass_count} ({self.pass_rate:.1f}%)")
|
||||
lines.append(f" Blocked: {self.fail_count} ({self.fail_rate:.1f}%)")
|
||||
lines.append(f" In Backlog: {self.backlog_count}")
|
||||
if self.sub_task_stats:
|
||||
lines.append("")
|
||||
lines.append(" Sub-Task Statistics:")
|
||||
lines.append(" " + "─" * 40)
|
||||
for task_name, stats in self.sub_task_stats.items():
|
||||
lines.append(f" {task_name}: {stats['passed']}/{stats['total']} passed, "
|
||||
f"{stats['failed']} failed, {stats['needs_review']} needs review")
|
||||
return "\n".join(lines)
|
||||
@@ -0,0 +1,283 @@
|
||||
"""Task model and parsing logic."""
|
||||
|
||||
import os
|
||||
from dataclasses import dataclass, field
|
||||
from enum import Enum
|
||||
from pathlib import Path
|
||||
from typing import Optional
|
||||
|
||||
|
||||
class TaskState(Enum):
|
||||
BACKLOG = "backlog"
|
||||
RESEARCH = "research"
|
||||
DECOMPOSITION = "decomposition"
|
||||
DESIGN = "design"
|
||||
TEST_DESIGN = "test_design"
|
||||
IMPLEMENT = "implement"
|
||||
BUG_FIND = "bug_find"
|
||||
ADV_BUG_FIND = "adv_bug_find"
|
||||
DOC_REVIEW = "doc_review"
|
||||
REFEREE = "referee"
|
||||
DONE = "done"
|
||||
BLOCKED = "blocked"
|
||||
|
||||
# State display labels (maps task.state to kanban column headers)
|
||||
COLUMN_HEADERS = {
|
||||
TaskState.BACKLOG: "Backlog",
|
||||
TaskState.RESEARCH: "Research",
|
||||
TaskState.DECOMPOSITION: "Decomposition",
|
||||
TaskState.DESIGN: "Design",
|
||||
TaskState.TEST_DESIGN: "Test Design",
|
||||
TaskState.IMPLEMENT: "Implement",
|
||||
TaskState.BUG_FIND: "Bug Find",
|
||||
TaskState.ADV_BUG_FIND: "Adversarial Bug Find",
|
||||
TaskState.DOC_REVIEW: "Doc Review",
|
||||
TaskState.REFEREE: "Referee",
|
||||
TaskState.DONE: "Done",
|
||||
TaskState.BLOCKED: "Blocked",
|
||||
}
|
||||
|
||||
ARTIFACTS = {
|
||||
"SPEC.md": TaskState.RESEARCH,
|
||||
"DECOMPOSITION.md": TaskState.DECOMPOSITION,
|
||||
"DESIGN.md": TaskState.DESIGN,
|
||||
"TEST_PLAN.md": TaskState.TEST_DESIGN,
|
||||
"IMPLEMENTATION.md": TaskState.IMPLEMENT,
|
||||
"BUG_REPORT.md": TaskState.BUG_FIND,
|
||||
"ADVERSARIAL_BUG_REPORT.md": TaskState.ADV_BUG_FIND,
|
||||
"DOC_REVIEW.md": TaskState.DOC_REVIEW,
|
||||
"VERDICT.md": TaskState.REFEREE,
|
||||
}
|
||||
|
||||
VERDICT_PASS = "PASS"
|
||||
VERDICT_FAIL = "FAIL"
|
||||
VERDICT_NEEDS_REVIEW = "NEEDS_REVIEW"
|
||||
|
||||
|
||||
@dataclass
|
||||
class ArtifactStatus:
|
||||
name: str
|
||||
exists: bool
|
||||
content: Optional[str] = None
|
||||
is_corrupted: bool = False
|
||||
|
||||
|
||||
@dataclass
|
||||
class SubTask:
|
||||
name: str
|
||||
state: TaskState
|
||||
has_spec: bool
|
||||
has_verdict: bool
|
||||
verdict_status: Optional[str] = None
|
||||
has_bug_report: bool = False
|
||||
has_adversarial_bug_report: bool = False
|
||||
|
||||
|
||||
@dataclass
|
||||
class Task:
|
||||
name: str
|
||||
folder_path: Path
|
||||
state: TaskState
|
||||
artifacts: dict[str, ArtifactStatus] = field(default_factory=dict)
|
||||
sub_tasks: list[SubTask] = field(default_factory=list)
|
||||
parent_spec: Optional[str] = None
|
||||
verdict_content: Optional[str] = None
|
||||
bug_report_content: Optional[str] = None
|
||||
adversarial_bug_report_content: Optional[str] = None
|
||||
doc_review_content: Optional[str] = None
|
||||
design_content: Optional[str] = None
|
||||
spec_content: Optional[str] = None
|
||||
is_corrupted: bool = False
|
||||
|
||||
@property
|
||||
def display_name(self) -> str:
|
||||
return " ".join(word.capitalize() for word in self.name.split("-"))
|
||||
|
||||
@property
|
||||
def has_verdict(self) -> bool:
|
||||
return self.state in (TaskState.REFEREE, TaskState.DONE, TaskState.BLOCKED)
|
||||
|
||||
@property
|
||||
def is_done(self) -> bool:
|
||||
return self.state == TaskState.DONE
|
||||
|
||||
@property
|
||||
def is_blocked(self) -> bool:
|
||||
return self.state == TaskState.BLOCKED
|
||||
|
||||
@property
|
||||
def sub_task_progress(self) -> tuple[int, int]:
|
||||
total = len(self.sub_tasks)
|
||||
completed = sum(1 for st in self.sub_tasks if st.has_verdict and st.verdict_status == VERDICT_PASS)
|
||||
return completed, total
|
||||
|
||||
@property
|
||||
def sub_task_progress_str(self) -> str:
|
||||
completed, total = self.sub_task_progress
|
||||
if total == 0:
|
||||
return ""
|
||||
return f"[{completed}/{total}]"
|
||||
|
||||
@property
|
||||
def status_indicator(self) -> str:
|
||||
if self.is_done:
|
||||
return "✅"
|
||||
elif self.is_blocked:
|
||||
return "❌"
|
||||
else:
|
||||
return "🔄"
|
||||
|
||||
@property
|
||||
def has_issues(self) -> bool:
|
||||
return bool(self.artifacts.get("BUG_REPORT.md")) or bool(self.artifacts.get("ADVERSARIAL_BUG_REPORT.md"))
|
||||
|
||||
|
||||
def determine_task_state(folder_path: Path) -> tuple[TaskState, dict[str, ArtifactStatus]]:
|
||||
artifacts = {}
|
||||
has_fail_verdict = False
|
||||
|
||||
for filename, expected_state in ARTIFACTS.items():
|
||||
filepath = folder_path / filename
|
||||
if filepath.exists():
|
||||
is_corrupted = False
|
||||
content = None
|
||||
try:
|
||||
content = filepath.read_text(encoding="utf-8", errors="replace")
|
||||
if not content or len(content) == 0:
|
||||
if filename == "VERDICT.md":
|
||||
has_fail_verdict = True
|
||||
is_corrupted = True
|
||||
except (OSError, IOError):
|
||||
is_corrupted = True
|
||||
content = None
|
||||
|
||||
artifacts[filename] = ArtifactStatus(
|
||||
name=filename, exists=True, content=content, is_corrupted=is_corrupted
|
||||
)
|
||||
|
||||
# Check for FAIL/NEEDS_REVIEW verdict first
|
||||
if has_fail_verdict or (
|
||||
"VERDICT.md" in artifacts
|
||||
and artifacts["VERDICT.md"].content
|
||||
and (VERDICT_FAIL in artifacts["VERDICT.md"].content or VERDICT_NEEDS_REVIEW in artifacts["VERDICT.md"].content)
|
||||
):
|
||||
return TaskState.BLOCKED, artifacts
|
||||
|
||||
# Check for PASS verdict (Done)
|
||||
if "VERDICT.md" in artifacts and artifacts["VERDICT.md"].content:
|
||||
if VERDICT_PASS in artifacts["VERDICT.md"].content:
|
||||
return TaskState.DONE, artifacts
|
||||
|
||||
# Check overlapping conditions - prioritize more advanced states
|
||||
if "ADVERSARIAL_BUG_REPORT.md" in artifacts and "BUG_REPORT.md" in artifacts:
|
||||
return TaskState.ADV_BUG_FIND, artifacts
|
||||
if "BUG_REPORT.md" in artifacts:
|
||||
return TaskState.BUG_FIND, artifacts
|
||||
if "ADVERSARIAL_BUG_REPORT.md" in artifacts:
|
||||
return TaskState.ADV_BUG_FIND, artifacts
|
||||
if "DOC_REVIEW.md" in artifacts:
|
||||
return TaskState.DOC_REVIEW, artifacts
|
||||
if "TEST_PLAN.md" in artifacts and "DESIGN.md" in artifacts:
|
||||
return TaskState.IMPLEMENT, artifacts
|
||||
if "TEST_PLAN.md" in artifacts:
|
||||
return TaskState.IMPLEMENT, artifacts
|
||||
if "DESIGN.md" in artifacts and "SPEC.md" in artifacts:
|
||||
return TaskState.DESIGN, artifacts
|
||||
if "DESIGN.md" in artifacts:
|
||||
return TaskState.DESIGN, artifacts
|
||||
if "DECOMPOSITION.md" in artifacts and "SPEC.md" in artifacts:
|
||||
return TaskState.DECOMPOSITION, artifacts
|
||||
if "DECOMPOSITION.md" in artifacts:
|
||||
return TaskState.DECOMPOSITION, artifacts
|
||||
if "SPEC.md" in artifacts:
|
||||
return TaskState.RESEARCH, artifacts
|
||||
|
||||
return TaskState.BACKLOG, artifacts
|
||||
|
||||
|
||||
def parse_sub_tasks(parent_folder: Path) -> list[SubTask]:
|
||||
subtasks_dir = parent_folder / "subtasks"
|
||||
if not subtasks_dir.exists():
|
||||
return []
|
||||
|
||||
sub_tasks = []
|
||||
for subtask_folder in sorted(subtasks_dir.iterdir()):
|
||||
if not subtask_folder.is_dir():
|
||||
continue
|
||||
state, artifacts = determine_task_state(subtask_folder)
|
||||
verdict_status = None
|
||||
has_verdict = False
|
||||
if "VERDICT.md" in artifacts and artifacts["VERDICT.md"].content:
|
||||
has_verdict = True
|
||||
content = artifacts["VERDICT.md"].content
|
||||
if VERDICT_PASS in content:
|
||||
verdict_status = VERDICT_PASS
|
||||
elif VERDICT_FAIL in content:
|
||||
verdict_status = VERDICT_FAIL
|
||||
elif VERDICT_NEEDS_REVIEW in content:
|
||||
verdict_status = VERDICT_NEEDS_REVIEW
|
||||
|
||||
sub_tasks.append(SubTask(
|
||||
name=subtask_folder.name, state=state, has_spec="SPEC.md" in artifacts,
|
||||
has_verdict=has_verdict, verdict_status=verdict_status,
|
||||
has_bug_report="BUG_REPORT.md" in artifacts,
|
||||
has_adversarial_bug_report="ADVERSARIAL_BUG_REPORT.md" in artifacts,
|
||||
))
|
||||
|
||||
return sub_tasks
|
||||
|
||||
|
||||
def parse_parent_spec(parent_folder: Path) -> Optional[str]:
|
||||
parent_spec_path = parent_folder / "PARENT_SPEC.md"
|
||||
if parent_spec_path.exists():
|
||||
try:
|
||||
return parent_spec_path.read_text(encoding="utf-8")
|
||||
except (OSError, IOError):
|
||||
return None
|
||||
return None
|
||||
|
||||
|
||||
def discover_tasks(tasks_dir: Path) -> list[Task]:
|
||||
if not tasks_dir.exists():
|
||||
return []
|
||||
|
||||
tasks = []
|
||||
for folder_path in sorted(tasks_dir.iterdir()):
|
||||
if not folder_path.is_dir():
|
||||
continue
|
||||
if folder_path.name == "subtasks":
|
||||
continue
|
||||
|
||||
state, artifacts = determine_task_state(folder_path)
|
||||
sub_tasks = parse_sub_tasks(folder_path)
|
||||
|
||||
task = Task(
|
||||
name=folder_path.name, folder_path=folder_path, state=state,
|
||||
artifacts=artifacts, sub_tasks=sub_tasks,
|
||||
)
|
||||
|
||||
# Load specific artifact contents for detail panel
|
||||
if "VERDICT.md" in artifacts and artifacts["VERDICT.md"].content:
|
||||
task.verdict_content = artifacts["VERDICT.md"].content
|
||||
if "BUG_REPORT.md" in artifacts and artifacts["BUG_REPORT.md"].content:
|
||||
task.bug_report_content = artifacts["BUG_REPORT.md"].content
|
||||
if "ADVERSARIAL_BUG_REPORT.md" in artifacts and artifacts["ADVERSARIAL_BUG_REPORT.md"].content:
|
||||
task.adversarial_bug_report_content = artifacts["ADVERSARIAL_BUG_REPORT.md"].content
|
||||
if "DOC_REVIEW.md" in artifacts and artifacts["DOC_REVIEW.md"].content:
|
||||
task.doc_review_content = artifacts["DOC_REVIEW.md"].content
|
||||
if "DESIGN.md" in artifacts and artifacts["DESIGN.md"].content:
|
||||
task.design_content = artifacts["DESIGN.md"].content
|
||||
if "SPEC.md" in artifacts and artifacts["SPEC.md"].content:
|
||||
task.spec_content = artifacts["SPEC.md"].content
|
||||
|
||||
tasks.append(task)
|
||||
|
||||
# Sort by state (most advanced first)
|
||||
state_order = {
|
||||
TaskState.DONE: 12, TaskState.BLOCKED: 11, TaskState.REFEREE: 10,
|
||||
TaskState.DOC_REVIEW: 9, TaskState.ADV_BUG_FIND: 8, TaskState.BUG_FIND: 7,
|
||||
TaskState.IMPLEMENT: 6, TaskState.TEST_DESIGN: 5, TaskState.DESIGN: 4,
|
||||
TaskState.DECOMPOSITION: 3, TaskState.RESEARCH: 2, TaskState.BACKLOG: 1,
|
||||
}
|
||||
tasks.sort(key=lambda t: state_order.get(t.state, 0), reverse=True)
|
||||
return tasks
|
||||
@@ -0,0 +1,95 @@
|
||||
"""Timeline visualization data for the dashboard."""
|
||||
|
||||
from dataclasses import dataclass, field
|
||||
from .task import Task, TaskState, SubTask, VERDICT_PASS
|
||||
|
||||
|
||||
@dataclass
|
||||
class PhaseEntry:
|
||||
state: TaskState
|
||||
is_complete: bool
|
||||
is_current: bool
|
||||
|
||||
|
||||
@dataclass
|
||||
class WaveEntry:
|
||||
wave_number: int
|
||||
sub_tasks: list[SubTask]
|
||||
is_complete: bool
|
||||
is_current: bool
|
||||
|
||||
|
||||
@dataclass
|
||||
class TaskTimeline:
|
||||
task_name: str
|
||||
display_name: str
|
||||
phases: list[PhaseEntry] = field(default_factory=list)
|
||||
waves: list[WaveEntry] = field(default_factory=list)
|
||||
is_complete: bool = False
|
||||
is_blocked: bool = False
|
||||
|
||||
@property
|
||||
def progress_str(self) -> str:
|
||||
if self.waves:
|
||||
total = len(self.waves[0].sub_tasks) if self.waves else 0
|
||||
if total > 0:
|
||||
completed = sum(1 for st in self.waves[0].sub_tasks if st.has_verdict and st.verdict_status == VERDICT_PASS)
|
||||
return f"[{completed}/{total}]"
|
||||
return ""
|
||||
|
||||
|
||||
def build_task_timelines(tasks: list[Task]) -> list[TaskTimeline]:
|
||||
timelines = []
|
||||
for task in tasks:
|
||||
timeline = TaskTimeline(task_name=task.name, display_name=task.display_name,
|
||||
is_complete=task.is_done, is_blocked=task.is_blocked)
|
||||
all_states = [TaskState.RESEARCH, TaskState.DECOMPOSITION, TaskState.DESIGN,
|
||||
TaskState.TEST_DESIGN, TaskState.IMPLEMENT, TaskState.BUG_FIND,
|
||||
TaskState.ADV_BUG_FIND, TaskState.DOC_REVIEW, TaskState.REFEREE]
|
||||
for state in all_states:
|
||||
is_complete = False
|
||||
is_current = False
|
||||
if state == TaskState.RESEARCH:
|
||||
is_complete = "SPEC.md" in task.artifacts
|
||||
is_current = task.state == state and not is_complete
|
||||
elif state == TaskState.DECOMPOSITION:
|
||||
is_complete = "DECOMPOSITION.md" in task.artifacts
|
||||
is_current = task.state == state and not is_complete
|
||||
elif state == TaskState.DESIGN:
|
||||
is_complete = "DESIGN.md" in task.artifacts
|
||||
is_current = task.state == state and not is_complete
|
||||
elif state == TaskState.TEST_DESIGN:
|
||||
is_complete = "TEST_PLAN.md" in task.artifacts
|
||||
is_current = task.state == state and not is_complete
|
||||
elif state == TaskState.IMPLEMENT:
|
||||
is_complete = "IMPLEMENTATION.md" in task.artifacts
|
||||
is_current = task.state == state and not is_complete
|
||||
elif state == TaskState.BUG_FIND:
|
||||
is_complete = "BUG_REPORT.md" in task.artifacts
|
||||
is_current = task.state == state and not is_complete
|
||||
elif state == TaskState.ADV_BUG_FIND:
|
||||
is_complete = "ADVERSARIAL_BUG_REPORT.md" in task.artifacts
|
||||
is_current = task.state == state and not is_complete
|
||||
elif state == TaskState.DOC_REVIEW:
|
||||
is_complete = "DOC_REVIEW.md" in task.artifacts
|
||||
is_current = task.state == state and not is_complete
|
||||
elif state == TaskState.REFEREE:
|
||||
is_complete = task.has_verdict
|
||||
is_current = task.state == state and not is_complete
|
||||
timeline.phases.append(PhaseEntry(state=state, is_complete=is_complete, is_current=is_current))
|
||||
if task.sub_tasks:
|
||||
half = len(task.sub_tasks) // 2
|
||||
if half > 0:
|
||||
wave1_subtasks = task.sub_tasks[:half]
|
||||
wave2_subtasks = task.sub_tasks[half:]
|
||||
wave1_complete = all(st.has_verdict for st in wave1_subtasks)
|
||||
wave2_complete = all(st.has_verdict for st in wave2_subtasks)
|
||||
wave1_current = not wave1_complete
|
||||
wave2_current = wave1_complete and not wave2_complete
|
||||
timeline.waves.append(WaveEntry(wave_number=1, sub_tasks=wave1_subtasks, is_complete=wave1_complete, is_current=wave1_current))
|
||||
timeline.waves.append(WaveEntry(wave_number=2, sub_tasks=wave2_subtasks, is_complete=wave2_complete, is_current=wave2_current))
|
||||
else:
|
||||
all_complete = all(st.has_verdict for st in task.sub_tasks)
|
||||
timeline.waves.append(WaveEntry(wave_number=1, sub_tasks=task.sub_tasks, is_complete=all_complete, is_current=not all_complete))
|
||||
timelines.append(timeline)
|
||||
return timelines
|
||||
@@ -0,0 +1,400 @@
|
||||
const state = {
|
||||
scope: 'none', currentView: 'board', theme: 'default', selectedTask: null,
|
||||
tasks: [], refreshCount: 0, autoRefresh: true, showWaves: true,
|
||||
filterPhase: 'all', filterWave: 'all', searchQuery: '', filterVisible: false,
|
||||
refreshInterval: null, projectName: null,
|
||||
};
|
||||
|
||||
const COLUMNS = [
|
||||
{ id: 'backlog', label: 'Backlog', color: 'backlog' },
|
||||
{ id: 'research', label: 'Research', color: 'research' },
|
||||
{ id: 'decomposition', label: 'Decomposition', color: 'decomposition' },
|
||||
{ id: 'design', label: 'Design', color: 'design' },
|
||||
{ id: 'test_design', label: 'Test Design', color: 'test_design' },
|
||||
{ id: 'implement', label: 'Implement', color: 'implement' },
|
||||
{ id: 'bug_find', label: 'Bug Find', color: 'bug_find' },
|
||||
{ id: 'adv_bug_find', label: 'Adversarial Bug Find', color: 'adv_bug_find' },
|
||||
{ id: 'doc_review', label: 'Doc Review', color: 'doc_review' },
|
||||
{ id: 'referee', label: 'Referee', color: 'referee' },
|
||||
{ id: 'done', label: 'Done', color: 'done' },
|
||||
{ id: 'blocked', label: 'Blocked', color: 'blocked' },
|
||||
];
|
||||
|
||||
const COLUMN_HEADERS = {};
|
||||
COLUMNS.forEach(col => { COLUMN_HEADERS[col.id] = col.label; });
|
||||
|
||||
// Phase group definitions: maps state to phase group and displays group
|
||||
const PHASE_GROUPS = [
|
||||
{ id: 'planning', label: 'Planning', color: '#42a5f5', states: ['backlog', 'research', 'decomposition'] },
|
||||
{ id: 'design', label: 'Design', color: '#26c6da', states: ['design', 'test_design'] },
|
||||
{ id: 'implementation', label: 'Implementation', color: '#66bb6a', states: ['implement'] },
|
||||
{ id: 'verification', label: 'Verification', color: '#ffa726', states: ['bug_find', 'adv_bug_find', 'doc_review', 'referee'] },
|
||||
{ id: 'resolution', label: 'Resolution', color: '#66bb6a', states: ['done', 'blocked'] },
|
||||
];
|
||||
|
||||
// State icon map
|
||||
const STATE_ICONS = {
|
||||
'backlog': '📋', 'research': '🔬', 'decomposition': '🔀',
|
||||
'design': '🎨', 'test_design': '🧪', 'implement': '⚙️',
|
||||
'bug_find': '🐛', 'adv_bug_find': '🔍', 'doc_review': '📝',
|
||||
'referee': '⚖️', 'done': '✅', 'blocked': '❌'
|
||||
};
|
||||
|
||||
// Get phase group for a state
|
||||
function getPhaseGroupForState(state) {
|
||||
const group = PHASE_GROUPS.find(g => g.states.includes(state));
|
||||
return group ? group.id : null;
|
||||
}
|
||||
|
||||
// Get sub-label text for a state
|
||||
function getSubLabel(state) {
|
||||
const label = COLUMN_HEADERS[state] || state;
|
||||
const icon = STATE_ICONS[state] || '○';
|
||||
return `${icon} ${label}`;
|
||||
}
|
||||
|
||||
async function fetchTasks() {
|
||||
try { const res = await fetch('/api/tasks'); const data = await res.json(); return data.tasks || []; }
|
||||
catch (err) { console.error('Failed to fetch tasks:', err); return []; }
|
||||
}
|
||||
|
||||
async function fetchScope() {
|
||||
try { const res = await fetch('/api/scope'); const data = await res.json(); return data; }
|
||||
catch (err) { console.error('Failed to fetch scope:', err); return { scope: 'none' }; }
|
||||
}
|
||||
|
||||
function renderHeader() {
|
||||
const scopeBadge = document.getElementById('scope-badge');
|
||||
const scopeLabel = document.getElementById('scope-label');
|
||||
const totalTasks = document.getElementById('total-tasks');
|
||||
const wipTasks = document.getElementById('wip-tasks');
|
||||
const doneTasks = document.getElementById('done-tasks');
|
||||
const blockedTasks = document.getElementById('blocked-tasks');
|
||||
const filtered = getFilteredTasks();
|
||||
const wipStates = ['research', 'decomposition', 'design', 'test_design', 'implement', 'bug_find', 'adv_bug_find', 'doc_review', 'referee'];
|
||||
totalTasks.textContent = filtered.length;
|
||||
wipTasks.textContent = filtered.filter(t => wipStates.includes(t.state)).length;
|
||||
doneTasks.textContent = filtered.filter(t => t.state === 'done').length;
|
||||
blockedTasks.textContent = filtered.filter(t => t.state === 'blocked').length;
|
||||
// Project name display
|
||||
const projectName = state.projectName;
|
||||
if (projectName) {
|
||||
scopeBadge.textContent = '📂';
|
||||
scopeLabel.textContent = projectName;
|
||||
document.title = `${projectName} - Automaton Dashboard`;
|
||||
} else {
|
||||
const scopeText = state.scope === 'framework' ? '🏗 Framework' : state.scope === 'project' ? '📁 Project' : '❌ Not in project';
|
||||
scopeBadge.textContent = scopeText.split(' ')[0];
|
||||
scopeLabel.textContent = scopeText.split(' ').slice(1).join(' ');
|
||||
}
|
||||
}
|
||||
|
||||
async function fetchProjectName() {
|
||||
try {
|
||||
const res = await fetch('/api/project-name');
|
||||
const data = await res.json();
|
||||
return data.project_name || null;
|
||||
} catch (err) {
|
||||
console.error('Failed to fetch project name:', err);
|
||||
return null;
|
||||
}
|
||||
}
|
||||
|
||||
function renderBoard() {
|
||||
const board = document.getElementById('board');
|
||||
const filtered = getFilteredTasks();
|
||||
const groups = {};
|
||||
PHASE_GROUPS.forEach(group => { groups[group.id] = []; });
|
||||
filtered.forEach(task => {
|
||||
const groupId = getPhaseGroupForState(task.state);
|
||||
if (groupId && groups[groupId]) groups[groupId].push(task);
|
||||
});
|
||||
|
||||
const maxGroupCount = Math.max(...PHASE_GROUPS.map(g => groups[g.id].length), 1);
|
||||
|
||||
const html = PHASE_GROUPS.map(group => {
|
||||
const tasks = groups[group.id];
|
||||
const count = tasks.length;
|
||||
const cardsHtml = count > 0
|
||||
? tasks.map(task => renderTaskCard(task)).join('')
|
||||
: '<div class="column-empty">No tasks in this phase</div>';
|
||||
return `<div class="column">
|
||||
<div class="column-header" data-color="${group.id}">
|
||||
<span style="flex:1">${group.label}</span>
|
||||
<div style="display: flex; align-items: center; gap: 8px; flex: 1;">
|
||||
<div style="flex: 1; height: 4px; background: var(--bg-primary); border-radius: 2px; overflow: hidden;">
|
||||
<div style="height: 100%; width: ${maxGroupCount > 0 ? (count / maxGroupCount * 100) : 0}%; background: ${group.color};"></div>
|
||||
</div>
|
||||
<span class="count" style="background: ${group.color}20; color: ${group.color}; padding: 2px 8px; border-radius: 10px; font-size: 10px;">${count}</span>
|
||||
</div>
|
||||
</div>
|
||||
<div class="column-body">${cardsHtml}</div>
|
||||
</div>`;
|
||||
}).join('');
|
||||
board.innerHTML = html;
|
||||
attachCardListeners();
|
||||
}
|
||||
|
||||
function renderTaskCard(task) {
|
||||
const statusClass = task.state === 'done' ? 'done' : task.state === 'blocked' ? 'blocked' : 'in_progress';
|
||||
const statusIcon = task.state === 'done' ? '✅' : task.state === 'blocked' ? '❌' : '🔄';
|
||||
const subLabel = getSubLabel(task.state);
|
||||
const progressHtml = task.sub_tasks.length > 0
|
||||
? `<span class="subtask-progress">${task.sub_tasks.filter(st => st.has_verdict && st.verdict_status === 'PASS').length}/${task.sub_tasks.length}</span>`
|
||||
: '';
|
||||
const subtasksHtml = task.sub_tasks.length > 0
|
||||
? `<div class="subtask-list">${task.sub_tasks.map(st => {
|
||||
const stStatus = st.has_verdict && st.verdict_status === 'PASS' ? 'pass' : st.has_verdict && st.verdict_status === 'FAIL' ? 'fail' : 'incomplete';
|
||||
const stIcon = stStatus === 'pass' ? '✓' : stStatus === 'fail' ? '✗' : '○';
|
||||
return `<div class="subtask-item"><span class="subtask-status ${stStatus}">${stIcon}</span><span>${st.name}</span></div>`;
|
||||
}).join('')}</div>`
|
||||
: '';
|
||||
return `<div class="task-card" data-task="${task.name}" data-status="${statusClass}">
|
||||
<div class="task-card-header"><span class="task-card-name">${task.display_name}</span><span class="task-card-status ${statusClass}">${statusIcon}</span></div>
|
||||
<div class="task-card-sublabel">${subLabel}</div>
|
||||
${progressHtml ? `<div class="task-card-footer"><span class="subtask-progress">${progressHtml}</span></div>` : ''}
|
||||
${subtasksHtml}
|
||||
</div>`;
|
||||
}
|
||||
|
||||
function renderDetail(task) {
|
||||
const detail = document.getElementById('detail-panel');
|
||||
const title = document.getElementById('detail-title');
|
||||
const content = document.getElementById('detail-content');
|
||||
detail.classList.add('open');
|
||||
const statusClass = task.state === 'done' ? 'done' : task.state === 'blocked' ? 'blocked' : 'in_progress';
|
||||
const statusText = task.state === 'done' ? '✅ PASS' : task.state === 'blocked' ? '❌ BLOCKED' : '🔄 IN PROGRESS';
|
||||
const phaseGroup = getPhaseGroupForState(task.state);
|
||||
const phaseGroupColor = phaseGroup ? PHASE_GROUPS.find(g => g.id === phaseGroup).color : '#999';
|
||||
title.textContent = task.display_name;
|
||||
const artifactsHtml = COLUMNS.map(col => {
|
||||
const has = task.artifacts[col.id];
|
||||
const icon = has ? '✓' : '✗';
|
||||
const cls = has ? 'check' : 'missing';
|
||||
return `<span class="detail-artifact"><span class="${cls}">${icon}</span>${col.label}</span>`;
|
||||
}).join('');
|
||||
const phaseGroupHtml = phaseGroup ? `<span class="detail-phase-badge" style="background: ${phaseGroupColor}20; color: ${phaseGroupColor}">${PHASE_GROUPS.find(g => g.id === phaseGroup).label}</span>` : '';
|
||||
content.innerHTML = `
|
||||
<div class="detail-section"><h4>Status</h4><span class="detail-status-badge ${statusClass}">${statusText}</span>${phaseGroupHtml}</div>
|
||||
<div class="detail-section"><h4>Artifacts</h4><div class="detail-artifacts">${artifactsHtml}</div></div>
|
||||
${task.sub_tasks.length > 0 ? `<div class="detail-section"><h4>Sub-tasks (${task.sub_tasks.filter(st => st.has_verdict).length}/${task.sub_tasks.length})</h4>
|
||||
<ul class="detail-subtask-list">${task.sub_tasks.map(st => {
|
||||
const stStatus = st.has_verdict && st.verdict_status === 'PASS' ? 'pass' : st.has_verdict && st.verdict_status === 'FAIL' ? 'fail' : 'incomplete';
|
||||
const stIcon = stStatus === 'pass' ? '✓' : stStatus === 'fail' ? '✗' : '○';
|
||||
return `<li><span class="${stStatus}">${stIcon}</span><span>${st.name}</span></li>`;
|
||||
}).join('')}</ul></div>` : ''}
|
||||
${task.verdict_content ? `<div class="detail-section"><h4>Verdict</h4><pre class="detail-content-text">${escapeHtml(task.verdict_content)}</pre></div>` : ''}
|
||||
${task.bug_report_content ? `<div class="detail-section"><h4>Bug Report</h4><pre class="detail-content-text">${escapeHtml(task.bug_report_content)}</pre></div>` : ''}`;
|
||||
}
|
||||
|
||||
function closeDetail() {
|
||||
document.getElementById('detail-panel').classList.remove('open');
|
||||
state.selectedTask = null;
|
||||
}
|
||||
|
||||
function renderStats() {
|
||||
const panel = document.getElementById('stats-panel');
|
||||
const filtered = getFilteredTasks();
|
||||
const wipStates = ['research', 'decomposition', 'design', 'test_design', 'implement', 'bug_find', 'adv_bug_find', 'doc_review', 'referee'];
|
||||
const total = filtered.length;
|
||||
const wip = filtered.filter(t => wipStates.includes(t.state)).length;
|
||||
const done = filtered.filter(t => t.state === 'done').length;
|
||||
const blocked = filtered.filter(t => t.state === 'blocked').length;
|
||||
|
||||
// Phase group counts
|
||||
const groupCounts = {};
|
||||
PHASE_GROUPS.forEach(g => { groupCounts[g.id] = 0; });
|
||||
filtered.forEach(t => {
|
||||
const groupId = getPhaseGroupForState(t.state);
|
||||
if (groupId && groupCounts[groupId] !== undefined) groupCounts[groupId]++;
|
||||
});
|
||||
const maxGroupCount = Math.max(...Object.values(groupCounts), 1);
|
||||
const groupBarHtml = PHASE_GROUPS.filter(g => groupCounts[g.id] > 0)
|
||||
.sort((a, b) => groupCounts[b.id] - groupCounts[a.id])
|
||||
.map(g => `<div class="bar-row"><span class="bar-label" style="color: ${g.color}">${g.label}</span><div class="bar-track"><div class="bar-fill" style="width: ${(groupCounts[g.id] / maxGroupCount * 100)}%; background: ${g.color}"></div></div><span class="bar-count">${groupCounts[g.id]}</span></div>`).join('');
|
||||
|
||||
// Individual state counts
|
||||
const columnCounts = {};
|
||||
COLUMNS.forEach(col => { columnCounts[col.id] = 0; });
|
||||
filtered.forEach(t => { if (columnCounts[t.state] !== undefined) columnCounts[t.state]++; });
|
||||
const maxCount = Math.max(...Object.values(columnCounts), 1);
|
||||
const barHtml = COLUMNS.filter(col => columnCounts[col.id] > 0)
|
||||
.sort((a, b) => columnCounts[b.id] - columnCounts[a.id])
|
||||
.map(col => `<div class="bar-row"><span class="bar-label">${col.label}</span><div class="bar-track"><div class="bar-fill" style="width: ${(columnCounts[col.id] / maxCount * 100)}%; background: var(--col-${col.color})"></div></div><span class="bar-count">${columnCounts[col.id]}</span></div>`).join('');
|
||||
const subTaskStats = filtered.filter(t => t.sub_tasks.length > 0);
|
||||
const subTaskHtml = subTaskStats.map(task => {
|
||||
const total = task.sub_tasks.length;
|
||||
const passed = task.sub_tasks.filter(st => st.has_verdict && st.verdict_status === 'PASS').length;
|
||||
const bar = `<div class="bar-fill" style="width: ${total > 0 ? (passed / total * 100) : 0}%; background: var(--success)"></div>`;
|
||||
return `<div class="bar-row"><span class="bar-label">${task.display_name}</span><div class="bar-track">${bar}</div><span class="bar-count">${passed}/${total}</span></div>`;
|
||||
}).join('');
|
||||
const waveStats = filtered.filter(t => t.sub_tasks.length > 0);
|
||||
const waveHtml = waveStats.map(task => {
|
||||
const half = Math.ceil(task.sub_tasks.length / 2);
|
||||
const wave1 = task.sub_tasks.slice(0, half);
|
||||
const wave2 = task.sub_tasks.slice(half);
|
||||
const w1Done = wave1.filter(st => st.has_verdict && st.verdict_status === 'PASS').length;
|
||||
const w2Done = wave2.filter(st => st.has_verdict && st.verdict_status === 'PASS').length;
|
||||
return `<div class="bar-row"><span class="bar-label">${task.display_name} W1</span><div class="bar-track"><div class="bar-fill" style="width: ${wave1.length > 0 ? (w1Done / wave1.length * 100) : 0}%; background: var(--success)"></div></div><span class="bar-count">${w1Done}/${wave1.length}</span></div>
|
||||
<div class="bar-row"><span class="bar-label">${task.display_name} W2</span><div class="bar-track"><div class="bar-fill" style="width: ${wave2.length > 0 ? (w2Done / wave2.length * 100) : 0}%; background: var(--success)"></div></div><span class="bar-count">${w2Done}/${wave2.length}</span></div>`;
|
||||
}).join('');
|
||||
panel.innerHTML = `
|
||||
<div class="stats-grid">
|
||||
<div class="stat-card total"><div class="stat-value">${total}</div><div class="stat-label">Total</div></div>
|
||||
<div class="stat-card wip"><div class="stat-value">${wip}</div><div class="stat-label">In Progress</div></div>
|
||||
<div class="stat-card done"><div class="stat-value">${done}</div><div class="stat-label">Completed</div></div>
|
||||
<div class="stat-card blocked"><div class="stat-value">${blocked}</div><div class="stat-label">Blocked</div></div>
|
||||
</div>
|
||||
<div class="stats-section"><h4>Tasks by Phase Group</h4><div class="bar-chart">${groupBarHtml}</div></div>
|
||||
<div class="stats-section"><h4>Tasks by State</h4><div class="bar-chart">${barHtml}</div></div>
|
||||
${subTaskStats.length > 0 ? `<div class="stats-section"><h4>Sub-Task Progress</h4><div class="bar-chart">${subTaskHtml}</div></div>` : ''}
|
||||
${waveStats.length > 0 ? `<div class="stats-section"><h4>Wave Progress</h4><div class="bar-chart">${waveHtml}</div></div>` : ''}`;
|
||||
}
|
||||
|
||||
function renderTimeline() {
|
||||
const panel = document.getElementById('timeline-panel');
|
||||
const filtered = getFilteredTasks();
|
||||
|
||||
// Group phases by phase group
|
||||
const phaseGroupStates = {};
|
||||
PHASE_GROUPS.forEach(group => {
|
||||
phaseGroupStates[group.id] = {
|
||||
states: group.states,
|
||||
label: group.label,
|
||||
color: group.color,
|
||||
};
|
||||
});
|
||||
|
||||
// Legend: show phase groups
|
||||
const legend = PHASE_GROUPS.map(group => {
|
||||
return `<div class="legend-item"><span class="legend-dot" style="background: ${group.color}"></span><span>${group.label}</span></div>`;
|
||||
}).join('');
|
||||
|
||||
const itemsHtml = filtered.map(task => {
|
||||
// For each phase group, check if the task has completed any state in that group
|
||||
const phaseGroupHtml = PHASE_GROUPS.map(group => {
|
||||
const groupStates = group.states;
|
||||
const hasArtifact = groupStates.some(s => task.artifacts[s]);
|
||||
const isComplete = task.state === 'done' || hasArtifact;
|
||||
const isCurrent = groupStates.includes(task.state) && !hasArtifact;
|
||||
const cls = isComplete ? 'complete' : isCurrent ? 'in_progress' : 'incomplete';
|
||||
const icon = isComplete ? '✓' : isCurrent ? '◐' : '○';
|
||||
return `<div class="timeline-phase ${cls}" title="${group.label}: ${cls}">${icon}</div>`;
|
||||
}).join('');
|
||||
const statusClass = task.state === 'done' ? 'done' : task.state === 'blocked' ? 'blocked' : 'in_progress';
|
||||
const statusIcon = task.state === 'done' ? '✅' : task.state === 'blocked' ? '❌' : '🔄';
|
||||
const waveHtml = task.sub_tasks.length > 0
|
||||
? `<div class="timeline-wave"><h5>Sub-tasks (${task.sub_tasks.filter(st => st.has_verdict).length}/${task.sub_tasks.length})</h5>
|
||||
<div class="timeline-subtask-list">${task.sub_tasks.map(st => {
|
||||
const stStatus = st.has_verdict && st.verdict_status === 'PASS' ? 'pass' : st.has_verdict && st.verdict_status === 'FAIL' ? 'fail' : 'incomplete';
|
||||
const stIcon = stStatus === 'pass' ? '✓' : stStatus === 'fail' ? '✗' : '○';
|
||||
return `<div class="timeline-subtask ${stStatus}"><span>${stIcon}</span><span>${st.name}</span></div>`;
|
||||
}).join('')}</div></div>`
|
||||
: '';
|
||||
return `<div class="timeline-item">
|
||||
<div class="timeline-item-header"><span class="timeline-item-name">${task.display_name}</span><span class="timeline-item-status">${statusIcon}</span></div>
|
||||
<div class="timeline-phases">${phaseGroupHtml}</div>${waveHtml}</div>`;
|
||||
}).join('');
|
||||
panel.innerHTML = `<div class="timeline-header"><h4>Phase Legend:</h4><div class="phase-legend">${legend}</div></div>${itemsHtml}`;
|
||||
}
|
||||
|
||||
function getFilteredTasks() {
|
||||
let filtered = [...state.tasks];
|
||||
if (state.filterPhase !== 'all') filtered = filtered.filter(t => t.state === state.filterPhase);
|
||||
if (state.filterWave === 'has-waves') filtered = filtered.filter(t => t.sub_tasks.length > 0);
|
||||
else if (state.filterWave === 'no-waves') filtered = filtered.filter(t => t.sub_tasks.length === 0);
|
||||
if (state.searchQuery) {
|
||||
const q = state.searchQuery.toLowerCase();
|
||||
filtered = filtered.filter(t => t.name.toLowerCase().includes(q) || t.display_name.toLowerCase().includes(q) || t.sub_tasks.some(st => st.name.toLowerCase().includes(q)));
|
||||
}
|
||||
return filtered;
|
||||
}
|
||||
|
||||
function switchView(view) {
|
||||
state.currentView = view;
|
||||
document.querySelectorAll('.tab').forEach(tab => { tab.classList.toggle('active', tab.dataset.view === view); });
|
||||
document.querySelectorAll('.view').forEach(v => v.classList.remove('active'));
|
||||
const target = document.getElementById(`view-${view}`);
|
||||
if (target) target.classList.add('active');
|
||||
renderCurrentView();
|
||||
}
|
||||
|
||||
function renderCurrentView() {
|
||||
switch (state.currentView) {
|
||||
case 'board': renderBoard(); break;
|
||||
case 'stats': renderStats(); break;
|
||||
case 'timeline': renderTimeline(); break;
|
||||
}
|
||||
renderHeader();
|
||||
}
|
||||
|
||||
function switchTheme() {
|
||||
const themes = ['default', 'dark', 'light'];
|
||||
const currentIdx = themes.indexOf(state.theme);
|
||||
state.theme = themes[(currentIdx + 1) % themes.length];
|
||||
document.documentElement.setAttribute('data-theme', state.theme === 'default' ? '' : state.theme);
|
||||
}
|
||||
|
||||
function attachCardListeners() {
|
||||
document.querySelectorAll('.task-card').forEach(card => {
|
||||
card.addEventListener('click', () => {
|
||||
const taskName = card.dataset.task;
|
||||
const task = state.tasks.find(t => t.name === taskName);
|
||||
if (task) {
|
||||
document.querySelectorAll('.task-card.selected').forEach(c => c.classList.remove('selected'));
|
||||
card.classList.add('selected');
|
||||
state.selectedTask = task;
|
||||
renderDetail(task);
|
||||
}
|
||||
});
|
||||
});
|
||||
}
|
||||
|
||||
function setupKeyboard() {
|
||||
document.addEventListener('keydown', (e) => {
|
||||
if (e.key === 'Escape') { closeDetail(); document.getElementById('help-modal').classList.remove('open'); document.getElementById('search-input').value = ''; state.searchQuery = ''; renderCurrentView(); }
|
||||
else if (e.key === ' ' && !e.target.matches('input, textarea, select')) { e.preventDefault(); const views = ['board', 'stats', 'timeline']; const idx = views.indexOf(state.currentView); switchView(views[(idx + 1) % views.length]); }
|
||||
else if (e.key === '1' && !e.target.matches('input, textarea, select')) { switchView('board'); }
|
||||
else if (e.key === '2' && !e.target.matches('input, textarea, select')) { switchView('stats'); }
|
||||
else if (e.key === '3' && !e.target.matches('input, textarea, select')) { switchView('timeline'); }
|
||||
else if (e.key === 't' && !e.target.matches('input, textarea, select')) { switchTheme(); }
|
||||
else if (e.key === 'r' && !e.target.matches('input, textarea, select')) { refreshData(); }
|
||||
else if (e.key === 'f' && !e.target.matches('input, textarea, select')) { state.filterVisible = !state.filterVisible; document.getElementById('filter-bar').classList.toggle('visible', state.filterVisible); }
|
||||
else if (e.key === 's' && !e.target.matches('input, textarea, select')) { document.getElementById('search-input').focus(); }
|
||||
else if (e.key === '?' && !e.target.matches('input, textarea, select')) { document.getElementById('help-modal').classList.toggle('open'); }
|
||||
});
|
||||
}
|
||||
|
||||
function setupUI() {
|
||||
document.querySelectorAll('.tab').forEach(tab => { tab.addEventListener('click', () => switchView(tab.dataset.view)); });
|
||||
document.getElementById('btn-refresh').addEventListener('click', refreshData);
|
||||
document.getElementById('btn-theme').addEventListener('click', switchTheme);
|
||||
document.getElementById('btn-help').addEventListener('click', () => { document.getElementById('help-modal').classList.toggle('open'); });
|
||||
document.getElementById('btn-close-help').addEventListener('click', () => { document.getElementById('help-modal').classList.remove('open'); });
|
||||
document.getElementById('btn-close-detail').addEventListener('click', closeDetail);
|
||||
document.getElementById('filter-phase').addEventListener('change', (e) => { state.filterPhase = e.target.value; renderCurrentView(); });
|
||||
document.getElementById('filter-wave').addEventListener('change', (e) => { state.filterWave = e.target.value; renderCurrentView(); });
|
||||
document.getElementById('search-input').addEventListener('input', (e) => { state.searchQuery = e.target.value; renderCurrentView(); });
|
||||
}
|
||||
|
||||
async function refreshData() {
|
||||
try {
|
||||
const [tasksData, scopeData, projectNameData] = await Promise.all([fetchTasks(), fetchScope(), fetchProjectName()]);
|
||||
state.tasks = tasksData || [];
|
||||
state.scope = scopeData.scope || 'none';
|
||||
state.projectName = projectNameData;
|
||||
state.refreshCount++;
|
||||
document.getElementById('refresh-count').textContent = state.refreshCount;
|
||||
renderCurrentView();
|
||||
} catch (err) { console.error('Refresh failed:', err); }
|
||||
}
|
||||
|
||||
function startAutoRefresh() { refreshData(); state.refreshInterval = setInterval(refreshData, 2000); }
|
||||
|
||||
function escapeHtml(text) { const div = document.createElement('div'); div.textContent = text; return div.innerHTML; }
|
||||
|
||||
document.addEventListener('DOMContentLoaded', () => {
|
||||
setupKeyboard();
|
||||
setupUI();
|
||||
startAutoRefresh();
|
||||
});
|
||||
@@ -0,0 +1,115 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>Automaton Dashboard</title>
|
||||
<link rel="stylesheet" href="styles.css">
|
||||
</head>
|
||||
<body>
|
||||
<div id="app">
|
||||
<header class="header">
|
||||
<div class="header-left">
|
||||
<span class="scope-badge" id="scope-badge"></span>
|
||||
<span class="scope-label" id="scope-label"></span>
|
||||
</div>
|
||||
<div class="header-center">
|
||||
<div class="view-tabs">
|
||||
<button class="tab active" data-view="board">Board</button>
|
||||
<button class="tab" data-view="stats">Stats</button>
|
||||
<button class="tab" data-view="timeline">Timeline</button>
|
||||
</div>
|
||||
</div>
|
||||
<div class="header-right">
|
||||
<div class="stats-mini">
|
||||
<span class="stat-total">Tasks: <strong id="total-tasks">0</strong></span>
|
||||
<span class="stat-wip">WIP: <strong id="wip-tasks">0</strong></span>
|
||||
<span class="stat-done">Done: <strong id="done-tasks">0</strong></span>
|
||||
<span class="stat-blocked">Blocked: <strong id="blocked-tasks">0</strong></span>
|
||||
</div>
|
||||
<div class="header-controls">
|
||||
<button class="btn btn-icon" id="btn-refresh" title="Refresh">↻</button>
|
||||
<button class="btn btn-icon" id="btn-theme" title="Switch theme">🎨</button>
|
||||
<button class="btn btn-icon" id="btn-help" title="Help">?</button>
|
||||
</div>
|
||||
</div>
|
||||
</header>
|
||||
|
||||
<div class="filter-bar" id="filter-bar">
|
||||
<div class="filter-group">
|
||||
<label>Phase:</label>
|
||||
<select id="filter-phase">
|
||||
<option value="all">All</option>
|
||||
<option value="research">Research</option>
|
||||
<option value="design">Design</option>
|
||||
<option value="implement">Implement</option>
|
||||
<option value="bug_find">Bug Find</option>
|
||||
<option value="done">Done</option>
|
||||
<option value="blocked">Blocked</option>
|
||||
</select>
|
||||
</div>
|
||||
<div class="filter-group">
|
||||
<label>Waves:</label>
|
||||
<select id="filter-wave">
|
||||
<option value="all">All</option>
|
||||
<option value="has-waves">Has Waves</option>
|
||||
<option value="no-waves">No Waves</option>
|
||||
</select>
|
||||
</div>
|
||||
<div class="filter-group">
|
||||
<label>Search:</label>
|
||||
<input type="text" id="search-input" placeholder="Search tasks..." />
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<main class="main-content">
|
||||
<div class="view active" id="view-board">
|
||||
<div class="board" id="board"></div>
|
||||
</div>
|
||||
<div class="view" id="view-stats">
|
||||
<div class="stats-panel" id="stats-panel"></div>
|
||||
</div>
|
||||
<div class="view" id="view-timeline">
|
||||
<div class="timeline-panel" id="timeline-panel"></div>
|
||||
</div>
|
||||
</main>
|
||||
|
||||
<div class="detail-panel" id="detail-panel">
|
||||
<div class="detail-header">
|
||||
<h3 id="detail-title">Select a task</h3>
|
||||
<button class="btn btn-close" id="btn-close-detail">✕</button>
|
||||
</div>
|
||||
<div class="detail-content" id="detail-content">
|
||||
<p class="detail-empty">Click on a task to view details</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<footer class="footer">
|
||||
<span class="footer-scope" id="footer-scope"></span>
|
||||
<span class="footer-info">Auto-refresh: <span id="refresh-status">on</span> | <span id="refresh-count">0</span> refreshes</span>
|
||||
</footer>
|
||||
</div>
|
||||
|
||||
<div class="help-modal" id="help-modal">
|
||||
<div class="help-modal-content">
|
||||
<h2>Keyboard Shortcuts</h2>
|
||||
<table class="help-table">
|
||||
<tr><td><kbd>Space</kbd></td><td>Cycle views (Board → Stats → Timeline)</td></tr>
|
||||
<tr><td><kbd>1</kbd></td><td>Board view</td></tr>
|
||||
<tr><td><kbd>2</kbd></td><td>Statistics view</td></tr>
|
||||
<tr><td><kbd>3</kbd></td><td>Timeline view</td></tr>
|
||||
<tr><td><kbd>t</kbd></td><td>Toggle wave display on Timeline</td></tr>
|
||||
<tr><td><kbd>r</kbd></td><td>Manual refresh</td></tr>
|
||||
<tr><td><kbd>f</kbd></td><td>Toggle filter bar</td></tr>
|
||||
<tr><td><kbd>s</kbd></td><td>Focus search</td></tr>
|
||||
<tr><td><kbd>Esc</kbd></td><td>Close modals / clear search</td></tr>
|
||||
<tr><td><kbd>q</kbd></td><td>Quit</td></tr>
|
||||
<tr><td><kbd>?</kbd></td><td>Show this help</td></tr>
|
||||
</table>
|
||||
<button class="btn btn-primary" id="btn-close-help">Close</button>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<script src="dashboard.js"></script>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,245 @@
|
||||
:root {
|
||||
--bg-primary: #1a1b2e; --bg-secondary: #232442; --bg-card: #2a2b4a;
|
||||
--bg-card-hover: #35365a; --text-primary: #e8e8f0; --text-secondary: #9a9ab0;
|
||||
--text-muted: #6a6a80; --border-color: #3a3b5a; --border-active: #5a5b8a;
|
||||
--accent: #4fc3f7; --accent-hover: #81d4fa; --success: #66bb6a;
|
||||
--success-bg: rgba(102,187,106,0.15); --warning: #ffa726;
|
||||
--warning-bg: rgba(255,167,38,0.15); --error: #ef5350;
|
||||
--error-bg: rgba(239,83,80,0.15); --info: #42a5f5; --info-bg: rgba(66,165,245,0.15);
|
||||
--col-backlog: #78909c; --col-research: #42a5f5; --col-decomposition: #ab47bc;
|
||||
--col-design: #26c6da; --col-test_design: #26c6da; --col-implement: #66bb6a;
|
||||
--col-bug_find: #ffa726; --col-adv_bug_find: #ef5350; --col-doc_review: #ffee58;
|
||||
--col-referee: #ce93d8; --col-done: #66bb6a; --col-blocked: #ef5350;
|
||||
}
|
||||
[data-theme="dark"] {
|
||||
--bg-primary: #0d0d1a; --bg-secondary: #141428; --bg-card: #1e1e3a;
|
||||
--bg-card-hover: #282850; --text-primary: #d8d8e8; --text-secondary: #8a8a9a;
|
||||
--text-muted: #5a5a6a; --border-color: #2a2a4a; --border-active: #4a4a6a;
|
||||
}
|
||||
[data-theme="light"] {
|
||||
--bg-primary: #f5f5f5; --bg-secondary: #ffffff; --bg-card: #ffffff;
|
||||
--bg-card-hover: #f0f0f0; --text-primary: #1a1a2e; --text-secondary: #5a5a6a;
|
||||
--text-muted: #9a9ab0; --border-color: #e0e0e0; --border-active: #b0b0c0;
|
||||
}
|
||||
*, *::before, *::after { margin: 0; padding: 0; box-sizing: border-box; }
|
||||
body {
|
||||
font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, 'Helvetica Neue', sans-serif;
|
||||
background: var(--bg-primary); color: var(--text-primary);
|
||||
height: 100vh; overflow: hidden; line-height: 1.4;
|
||||
}
|
||||
#app { display: flex; flex-direction: column; height: 100vh; }
|
||||
.header {
|
||||
display: flex; align-items: center; gap: 16px; padding: 12px 20px;
|
||||
background: var(--bg-secondary); border-bottom: 1px solid var(--border-color);
|
||||
flex-shrink: 0;
|
||||
}
|
||||
.header-left { display: flex; align-items: center; gap: 8px; }
|
||||
.scope-badge { font-size: 18px; }
|
||||
.scope-label { font-weight: 600; color: var(--accent); font-size: 14px; }
|
||||
.header-center { flex: 1; display: flex; justify-content: center; }
|
||||
.view-tabs {
|
||||
display: flex; gap: 4px; background: var(--bg-primary);
|
||||
border-radius: 8px; padding: 2px;
|
||||
}
|
||||
.tab {
|
||||
padding: 6px 16px; border: none; background: transparent;
|
||||
color: var(--text-secondary); border-radius: 6px; cursor: pointer;
|
||||
font-size: 13px; font-weight: 500; transition: all 0.15s;
|
||||
}
|
||||
.tab:hover { color: var(--text-primary); background: var(--bg-card); }
|
||||
.tab.active { color: var(--text-primary); background: var(--accent); }
|
||||
.header-right { display: flex; align-items: center; gap: 16px; }
|
||||
.stats-mini { display: flex; gap: 12px; font-size: 12px; color: var(--text-secondary); }
|
||||
.stat-total strong, .stat-wip strong, .stat-done strong, .stat-blocked strong { color: var(--text-primary); }
|
||||
.stat-blocked strong { color: var(--error); }
|
||||
.header-controls { display: flex; gap: 4px; }
|
||||
.btn {
|
||||
padding: 6px 12px; border: 1px solid var(--border-color);
|
||||
background: var(--bg-card); color: var(--text-primary);
|
||||
border-radius: 6px; cursor: pointer; font-size: 12px; transition: all 0.15s;
|
||||
}
|
||||
.btn:hover { background: var(--bg-card-hover); border-color: var(--border-active); }
|
||||
.btn-icon { width: 32px; height: 32px; display: flex; align-items: center; justify-content: center; font-size: 14px; padding: 0; }
|
||||
.btn-primary { background: var(--accent); color: var(--bg-primary); border: none; padding: 8px 16px; font-weight: 600; }
|
||||
.btn-primary:hover { background: var(--accent-hover); }
|
||||
.btn-close { background: transparent; border: none; color: var(--text-muted); font-size: 16px; padding: 4px 8px; }
|
||||
.btn-close:hover { color: var(--error); }
|
||||
.filter-bar {
|
||||
display: flex; align-items: center; gap: 16px; padding: 8px 20px;
|
||||
background: var(--bg-secondary); border-bottom: 1px solid var(--border-color);
|
||||
flex-shrink: 0; display: none;
|
||||
}
|
||||
.filter-bar.visible { display: flex; }
|
||||
.filter-group { display: flex; align-items: center; gap: 6px; }
|
||||
.filter-group label { font-size: 12px; color: var(--text-secondary); white-space: nowrap; }
|
||||
.filter-group select, .filter-group input {
|
||||
padding: 4px 8px; border: 1px solid var(--border-color);
|
||||
background: var(--bg-primary); color: var(--text-primary); border-radius: 4px; font-size: 12px;
|
||||
}
|
||||
.filter-group input:focus, .filter-group select:focus { outline: none; border-color: var(--accent); }
|
||||
.main-content { flex: 1; overflow: hidden; position: relative; }
|
||||
.view { display: none; height: 100%; overflow-y: auto; padding: 16px; }
|
||||
.view.active { display: block; }
|
||||
.board { display: flex; gap: 8px; height: 100%; overflow-x: auto; padding-bottom: 8px; }
|
||||
.column {
|
||||
flex: 1; min-width: 180px; max-width: 300px;
|
||||
display: flex; flex-direction: column; background: var(--bg-secondary);
|
||||
border-radius: 8px; border: 1px solid var(--border-color);
|
||||
}
|
||||
.column-header {
|
||||
display: flex; justify-content: space-between; align-items: center;
|
||||
padding: 8px 12px; border-bottom: 1px solid var(--border-color);
|
||||
font-size: 12px; font-weight: 600; color: var(--text-secondary);
|
||||
}
|
||||
.column-header .count { background: var(--bg-primary); padding: 2px 8px; border-radius: 10px; font-size: 11px; }
|
||||
.column-header[data-color="research"] { color: var(--col-research); }
|
||||
.column-header[data-color="decomposition"] { color: var(--col-decomposition); }
|
||||
.column-header[data-color="design"] { color: var(--col-design); }
|
||||
.column-header[data-color="test_design"] { color: var(--col-design); }
|
||||
.column-header[data-color="implement"] { color: var(--col-implement); }
|
||||
.column-header[data-color="bug_find"] { color: var(--col-bug_find); }
|
||||
.column-header[data-color="adv_bug_find"] { color: var(--col-adv_bug_find); }
|
||||
.column-header[data-color="doc_review"] { color: var(--col-doc_review); }
|
||||
.column-header[data-color="referee"] { color: var(--col-referee); }
|
||||
.column-header[data-color="done"] { color: var(--col-done); }
|
||||
.column-header[data-color="blocked"] { color: var(--col-blocked); }
|
||||
.column-header[data-color="backlog"] { color: var(--col-backlog); }
|
||||
.column-header[data-color="planning"] { color: var(--col-research); }
|
||||
.column-header[data-color="design"] { color: var(--col-design); }
|
||||
.column-header[data-color="implementation"] { color: var(--col-implement); }
|
||||
.column-header[data-color="verification"] { color: var(--col-bug_find); }
|
||||
.column-header[data-color="resolution"] { color: var(--col-done); }
|
||||
.column-body { padding: 8px; flex: 1; overflow-y: auto; display: flex; flex-direction: column; gap: 6px; }
|
||||
.column-empty { text-align: center; padding: 20px; color: var(--text-muted); font-size: 12px; }
|
||||
.task-card {
|
||||
background: var(--bg-card); border: 1px solid var(--border-color);
|
||||
border-radius: 6px; padding: 8px 10px; cursor: pointer; transition: all 0.15s;
|
||||
border-left: 3px solid transparent;
|
||||
}
|
||||
.task-card:hover { background: var(--bg-card-hover); border-color: var(--border-active); }
|
||||
.task-card.selected { border-color: var(--accent); background: var(--bg-card-hover); }
|
||||
.task-card[data-status="done"] { border-left-color: var(--col-done); }
|
||||
.task-card[data-status="blocked"] { border-left-color: var(--col-blocked); }
|
||||
.task-card[data-status="in_progress"] { border-left-color: var(--accent); }
|
||||
.task-card-sublabel { font-size: 11px; color: var(--text-muted); margin-bottom: 4px; }
|
||||
.task-card-header { display: flex; justify-content: space-between; align-items: center; margin-bottom: 2px; }
|
||||
.task-card-name { font-size: 13px; font-weight: 500; color: var(--text-primary); }
|
||||
.task-card-status { font-size: 14px; }
|
||||
.task-card-status.done { color: var(--success); }
|
||||
.task-card-status.blocked { color: var(--error); }
|
||||
.task-card-status.in_progress { color: var(--warning); }
|
||||
.task-card-footer { display: flex; justify-content: space-between; align-items: center; font-size: 11px; color: var(--text-secondary); }
|
||||
.subtask-progress { background: var(--bg-primary); padding: 2px 6px; border-radius: 10px; font-size: 10px; }
|
||||
.subtask-list { margin-top: 6px; padding-top: 6px; border-top: 1px solid var(--border-color); }
|
||||
.subtask-item { display: flex; align-items: center; gap: 4px; font-size: 11px; color: var(--text-secondary); padding: 2px 0; }
|
||||
.subtask-status { font-size: 12px; }
|
||||
.subtask-status.pass { color: var(--success); }
|
||||
.subtask-status.fail { color: var(--error); }
|
||||
.subtask-status.incomplete { color: var(--text-muted); }
|
||||
.detail-panel {
|
||||
position: fixed; right: 0; top: 0; bottom: 0; width: 380px;
|
||||
background: var(--bg-secondary); border-left: 1px solid var(--border-color);
|
||||
z-index: 100; display: none; flex-direction: column; overflow-y: auto;
|
||||
}
|
||||
.detail-panel.open { display: flex; }
|
||||
.detail-header { display: flex; justify-content: space-between; align-items: center; padding: 12px 16px; border-bottom: 1px solid var(--border-color); }
|
||||
.detail-header h3 { font-size: 14px; font-weight: 600; color: var(--text-primary); }
|
||||
.detail-content { padding: 12px 16px; flex: 1; }
|
||||
.detail-empty { text-align: center; padding: 40px; color: var(--text-muted); font-size: 13px; }
|
||||
.detail-section { margin-bottom: 16px; }
|
||||
.detail-section h4 { font-size: 11px; font-weight: 600; color: var(--text-muted); text-transform: uppercase; letter-spacing: 0.5px; margin-bottom: 6px; }
|
||||
.detail-status-badge {
|
||||
display: inline-flex; align-items: center; gap: 6px; padding: 4px 10px;
|
||||
border-radius: 12px; font-size: 12px; font-weight: 500;
|
||||
}
|
||||
.detail-status-badge.done { background: var(--success-bg); color: var(--success); }
|
||||
.detail-status-badge.blocked { background: var(--error-bg); color: var(--error); }
|
||||
.detail-status-badge.in_progress { background: var(--info-bg); color: var(--info); }
|
||||
.detail-artifacts { display: flex; flex-wrap: wrap; gap: 4px; }
|
||||
.detail-phase-badge { display: inline-flex; align-items: center; gap: 4px; padding: 3px 8px; border-radius: 12px; font-size: 11px; font-weight: 500; margin-left: 8px; }
|
||||
.detail-artifact {
|
||||
display: inline-flex; align-items: center; gap: 4px; padding: 3px 8px;
|
||||
background: var(--bg-primary); border-radius: 4px; font-size: 11px; color: var(--text-secondary);
|
||||
}
|
||||
.detail-artifact .check { color: var(--success); }
|
||||
.detail-artifact .cross { color: var(--error); }
|
||||
.detail-artifact .missing { color: var(--text-muted); }
|
||||
.detail-subtask-list { list-style: none; }
|
||||
.detail-subtask-list li { display: flex; align-items: center; gap: 6px; padding: 4px 0; font-size: 12px; color: var(--text-secondary); }
|
||||
.detail-subtask-list .pass { color: var(--success); }
|
||||
.detail-subtask-list .fail { color: var(--error); }
|
||||
.detail-subtask-list .incomplete { color: var(--text-muted); }
|
||||
.stats-panel { max-width: 800px; margin: 0 auto; }
|
||||
.stats-grid { display: grid; grid-template-columns: repeat(4, 1fr); gap: 12px; margin-bottom: 24px; }
|
||||
.stat-card { background: var(--bg-card); border: 1px solid var(--border-color); border-radius: 8px; padding: 16px; text-align: center; }
|
||||
.stat-card .stat-value { font-size: 32px; font-weight: 700; margin-bottom: 4px; }
|
||||
.stat-card .stat-label { font-size: 12px; color: var(--text-secondary); }
|
||||
.stat-card.total .stat-value { color: var(--accent); }
|
||||
.stat-card.wip .stat-value { color: var(--warning); }
|
||||
.stat-card.done .stat-value { color: var(--success); }
|
||||
.stat-card.blocked .stat-value { color: var(--error); }
|
||||
.stats-section { background: var(--bg-card); border: 1px solid var(--border-color); border-radius: 8px; padding: 16px; margin-bottom: 16px; }
|
||||
.stats-section h4 { font-size: 14px; font-weight: 600; margin-bottom: 12px; color: var(--text-primary); }
|
||||
.bar-chart { display: flex; flex-direction: column; gap: 6px; }
|
||||
.bar-row { display: flex; align-items: center; gap: 8px; }
|
||||
.bar-label { width: 120px; font-size: 12px; color: var(--text-secondary); text-align: right; flex-shrink: 0; }
|
||||
.bar-track { flex: 1; height: 16px; background: var(--bg-primary); border-radius: 4px; overflow: hidden; }
|
||||
.bar-fill { height: 100%; border-radius: 4px; transition: width 0.3s; }
|
||||
.bar-count { width: 30px; font-size: 12px; color: var(--text-secondary); text-align: right; flex-shrink: 0; }
|
||||
.timeline-panel { max-width: 900px; margin: 0 auto; }
|
||||
.timeline-header { display: flex; align-items: center; gap: 8px; margin-bottom: 16px; flex-wrap: wrap; }
|
||||
.phase-legend { display: flex; align-items: center; gap: 8px; }
|
||||
.legend-item { display: flex; align-items: center; gap: 4px; font-size: 11px; color: var(--text-secondary); }
|
||||
.legend-dot { width: 8px; height: 8px; border-radius: 50%; }
|
||||
.legend-dot.complete { background: var(--success); }
|
||||
.legend-dot.in_progress { background: var(--warning); }
|
||||
.legend-dot.incomplete { background: var(--text-muted); }
|
||||
.timeline-item { background: var(--bg-card); border: 1px solid var(--border-color); border-radius: 8px; padding: 12px 16px; margin-bottom: 8px; }
|
||||
.timeline-item-header { display: flex; justify-content: space-between; align-items: center; margin-bottom: 8px; }
|
||||
.timeline-item-name { font-size: 13px; font-weight: 500; }
|
||||
.timeline-item-status { font-size: 12px; }
|
||||
.timeline-phases { display: flex; gap: 4px; }
|
||||
.timeline-phase {
|
||||
width: 24px; height: 24px; border-radius: 4px;
|
||||
display: flex; align-items: center; justify-content: center;
|
||||
font-size: 10px; font-weight: 600;
|
||||
}
|
||||
.timeline-phase.complete { background: var(--success); color: white; }
|
||||
.timeline-phase.in_progress { background: var(--warning); color: var(--bg-primary); }
|
||||
.timeline-phase.incomplete { background: var(--bg-primary); color: var(--text-muted); }
|
||||
.timeline-wave { margin-top: 8px; padding-top: 8px; border-top: 1px solid var(--border-color); }
|
||||
.timeline-wave h5 { font-size: 11px; font-weight: 600; color: var(--text-muted); text-transform: uppercase; letter-spacing: 0.5px; margin-bottom: 6px; }
|
||||
.timeline-subtask-list { display: flex; flex-wrap: wrap; gap: 6px; }
|
||||
.timeline-subtask {
|
||||
display: flex; align-items: center; gap: 4px; padding: 3px 8px;
|
||||
background: var(--bg-primary); border-radius: 4px; font-size: 11px; color: var(--text-secondary);
|
||||
}
|
||||
.timeline-subtask.pass { border-left: 2px solid var(--success); }
|
||||
.timeline-subtask.fail { border-left: 2px solid var(--error); }
|
||||
.timeline-subtask.incomplete { border-left: 2px solid var(--text-muted); }
|
||||
.footer { display: flex; justify-content: space-between; align-items: center; padding: 8px 20px; background: var(--bg-secondary); border-top: 1px solid var(--border-color); font-size: 11px; color: var(--text-muted); flex-shrink: 0; }
|
||||
.help-modal { display: none; position: fixed; inset: 0; background: rgba(0,0,0,0.5); z-index: 200; align-items: center; justify-content: center; }
|
||||
.help-modal.open { display: flex; }
|
||||
.help-modal-content { background: var(--bg-secondary); border: 1px solid var(--border-color); border-radius: 12px; padding: 24px; max-width: 500px; width: 90%; }
|
||||
.help-modal-content h2 { font-size: 18px; margin-bottom: 16px; color: var(--text-primary); }
|
||||
.help-table { width: 100%; margin-bottom: 16px; }
|
||||
.help-table td { padding: 6px 8px; font-size: 13px; color: var(--text-secondary); }
|
||||
.help-table td:first-child { width: 80px; }
|
||||
kbd {
|
||||
display: inline-block; padding: 2px 6px; background: var(--bg-primary);
|
||||
border: 1px solid var(--border-color); border-radius: 4px;
|
||||
font-size: 11px; font-family: monospace; color: var(--text-primary);
|
||||
}
|
||||
::-webkit-scrollbar { width: 6px; height: 6px; }
|
||||
::-webkit-scrollbar-track { background: var(--bg-primary); }
|
||||
::-webkit-scrollbar-thumb { background: var(--border-color); border-radius: 3px; }
|
||||
::-webkit-scrollbar-thumb:hover { background: var(--border-active); }
|
||||
@media (max-width: 768px) {
|
||||
.header { flex-wrap: wrap; gap: 8px; }
|
||||
.header-center { order: 3; width: 100%; }
|
||||
.stats-mini { font-size: 11px; gap: 8px; }
|
||||
.detail-panel { width: 100%; }
|
||||
.stats-grid { grid-template-columns: repeat(2, 1fr); }
|
||||
.board { flex-direction: column; }
|
||||
.column { min-width: unset; max-width: unset; }
|
||||
}
|
||||
@@ -0,0 +1,15 @@
|
||||
[build-system]
|
||||
requires = ["setuptools>=61.0"]
|
||||
build-backend = "setuptools.build_meta"
|
||||
|
||||
[project]
|
||||
name = "automaton"
|
||||
version = "0.1.0"
|
||||
description = "Automaton framework - dashboard and tools"
|
||||
requires-python = ">=3.9"
|
||||
|
||||
[project.scripts]
|
||||
automaton-dashboard = "automaton.dashboard.__main__:main"
|
||||
|
||||
[tool.setuptools.packages.find]
|
||||
include = ["automaton.dashboard*"]
|
||||
@@ -0,0 +1,19 @@
|
||||
"""Color themes for the dashboard."""
|
||||
|
||||
from typing import Dict
|
||||
|
||||
THEMES = {
|
||||
"default": {},
|
||||
"dark": {},
|
||||
"light": {},
|
||||
}
|
||||
|
||||
# ANSI escape sequences (not needed for web dashboard but kept for compat)
|
||||
RESET = "\033[0m"
|
||||
BOLD = "\033[1m"
|
||||
|
||||
def get_theme(theme_name: str = "default") -> Dict[str, str]:
|
||||
return THEMES.get(theme_name, THEMES["default"])
|
||||
|
||||
def colorize(text: str, color_code: str) -> str:
|
||||
return f"{color_code}{text}{RESET}"
|
||||
@@ -0,0 +1 @@
|
||||
# UI components for the dashboard
|
||||
Binary file not shown.
Binary file not shown.
@@ -0,0 +1,234 @@
|
||||
"""Web-based dashboard application."""
|
||||
|
||||
import json
|
||||
import mimetypes
|
||||
import os
|
||||
import posixpath
|
||||
import sys
|
||||
from http.server import HTTPServer, SimpleHTTPRequestHandler
|
||||
from pathlib import Path
|
||||
from typing import Optional
|
||||
from urllib.parse import unquote
|
||||
|
||||
from ..core.scope import detect_scope, find_automaton_root
|
||||
from ..core.task import discover_tasks, TaskState, COLUMN_HEADERS
|
||||
from ..config import DashboardConfig, get_config_path
|
||||
|
||||
# Task states for API responses - maps state names to artifact names
|
||||
TASK_STATE_ARTIFACT = {
|
||||
"research": "SPEC.md",
|
||||
"decomposition": "DECOMPOSITION.md",
|
||||
"design": "DESIGN.md",
|
||||
"test_design": "TEST_PLAN.md",
|
||||
"implement": "IMPLEMENTATION.md",
|
||||
"bug_find": "BUG_REPORT.md",
|
||||
"adv_bug_find": "ADVERSARIAL_BUG_REPORT.md",
|
||||
"doc_review": "DOC_REVIEW.md",
|
||||
"referee": "VERDICT.md",
|
||||
}
|
||||
|
||||
TASK_STATES = list(TASK_STATE_ARTIFACT.keys())
|
||||
|
||||
|
||||
class DashboardHandler(SimpleHTTPRequestHandler):
|
||||
"""HTTP handler that serves the dashboard files and task API data."""
|
||||
|
||||
dashboard_path = Path(__file__).resolve().parent.parent / "html"
|
||||
|
||||
def do_GET(self):
|
||||
if self.path == "/api/tasks":
|
||||
self._serve_tasks()
|
||||
elif self.path == "/api/scope":
|
||||
self._serve_scope()
|
||||
elif self.path == "/api/project-name":
|
||||
self._serve_project_name()
|
||||
elif self.path == "/api/task/" or self.path.startswith("/api/task/"):
|
||||
task_name = self.path.split("/api/task/")[1]
|
||||
self._serve_task(task_name)
|
||||
else:
|
||||
# Serve static files from dashboard HTML directory manually
|
||||
# This avoids redirect loops with the root path
|
||||
self._serve_static()
|
||||
|
||||
def _serve_static(self):
|
||||
"""Serve static files from the dashboard HTML directory."""
|
||||
# Strip query string and fragment
|
||||
path = self.path.split('?', 1)[0]
|
||||
path = path.split('#', 1)[0]
|
||||
# Normalize path and strip leading / (pathlib treats absolute paths specially)
|
||||
path = posixpath.normpath(unquote(path)).lstrip('/')
|
||||
# Handle root path — serve index.html
|
||||
if path == '' or path == '.':
|
||||
path = 'index.html'
|
||||
# Build the full file path
|
||||
full_path = self.dashboard_path / path
|
||||
# Check if file exists and is within the dashboard directory
|
||||
try:
|
||||
resolved = full_path.resolve()
|
||||
base = self.dashboard_path.resolve()
|
||||
# Ensure the resolved path starts with the base directory
|
||||
if not str(resolved).startswith(str(base) + '/'):
|
||||
self._send_error(403, "Forbidden")
|
||||
return
|
||||
except Exception:
|
||||
self._send_error(403, "Forbidden")
|
||||
return
|
||||
if not full_path.exists() or not full_path.is_file():
|
||||
self._send_error(404, "File not found")
|
||||
return
|
||||
# Determine content type
|
||||
content_type, encoding = mimetypes.guess_type(str(full_path))
|
||||
if not content_type:
|
||||
content_type = 'application/octet-stream'
|
||||
# Serve the file
|
||||
try:
|
||||
with open(full_path, 'rb') as f:
|
||||
data = f.read()
|
||||
self.send_response(200)
|
||||
self.send_header("Content-Type", content_type)
|
||||
self.send_header("Content-Length", len(data))
|
||||
self.send_header("Cache-Control", "no-cache")
|
||||
self.end_headers()
|
||||
self.wfile.write(data)
|
||||
except Exception:
|
||||
self._send_error(500, "Internal error")
|
||||
|
||||
def _serve_tasks(self):
|
||||
project_root = find_automaton_root()
|
||||
if not project_root:
|
||||
tasks = []
|
||||
else:
|
||||
tasks_dir = project_root / ".automaton" / "tasks"
|
||||
tasks = discover_tasks(tasks_dir)
|
||||
|
||||
tasks_data = [
|
||||
{
|
||||
"name": t.name,
|
||||
"display_name": t.display_name,
|
||||
"state": t.state.value,
|
||||
"artifacts": {s: TASK_STATE_ARTIFACT[s] in t.artifacts for s in TASK_STATES},
|
||||
"sub_tasks": [
|
||||
{"name": st.name, "has_verdict": st.has_verdict, "verdict_status": st.verdict_status}
|
||||
for st in t.sub_tasks
|
||||
],
|
||||
"verdict_content": t.verdict_content,
|
||||
"bug_report_content": t.bug_report_content,
|
||||
}
|
||||
for t in tasks
|
||||
]
|
||||
self._send_json({"tasks": tasks_data})
|
||||
|
||||
def _serve_scope(self):
|
||||
project_root, scope = detect_scope()
|
||||
self._send_json({"scope": scope, "project_root": str(project_root) if project_root else None})
|
||||
|
||||
def _serve_project_name(self):
|
||||
project_root = find_automaton_root()
|
||||
if not project_root:
|
||||
self._send_json({"project_name": None})
|
||||
return
|
||||
# Try .automaton/project-name.md first
|
||||
project_name_file = project_root / ".automaton" / "project-name.md"
|
||||
if project_name_file.exists():
|
||||
try:
|
||||
project_name = project_name_file.read_text().strip()
|
||||
self._send_json({"project_name": project_name})
|
||||
return
|
||||
except Exception:
|
||||
pass
|
||||
# Fall back to README.md first heading (in automaton root or .automaton dir)
|
||||
for readme_path in [project_root / "README.md", project_root / ".automaton" / "README.md"]:
|
||||
if readme_path.exists():
|
||||
try:
|
||||
lines = readme_path.read_text().strip().split('\n')
|
||||
for line in lines:
|
||||
if line.startswith('# '):
|
||||
self._send_json({"project_name": line[2:].strip()})
|
||||
return
|
||||
except Exception:
|
||||
pass
|
||||
# Fall back to directory name
|
||||
self._send_json({"project_name": project_root.name})
|
||||
|
||||
def _serve_task(self, task_name):
|
||||
project_root = find_automaton_root()
|
||||
if not project_root:
|
||||
self._send_error(404, "Not in automaton project")
|
||||
return
|
||||
tasks = discover_tasks(project_root / "tasks")
|
||||
task = next((t for t in tasks if t.name == task_name), None)
|
||||
if not task:
|
||||
self._send_error(404, "Task not found")
|
||||
return
|
||||
task_data = {
|
||||
"name": task.name,
|
||||
"display_name": task.display_name,
|
||||
"state": task.state.value,
|
||||
"artifacts": {s: TASK_STATE_ARTIFACT[s] in task.artifacts for s in TASK_STATES},
|
||||
"sub_tasks": [
|
||||
{"name": st.name, "has_verdict": st.has_verdict, "verdict_status": st.verdict_status}
|
||||
for st in task.sub_tasks
|
||||
],
|
||||
"verdict_content": task.verdict_content,
|
||||
"bug_report_content": task.bug_report_content,
|
||||
}
|
||||
self._send_json(task_data)
|
||||
|
||||
def _send_json(self, data):
|
||||
self.send_response(200)
|
||||
self.send_header("Content-Type", "application/json")
|
||||
self.send_header("Cache-Control", "no-cache")
|
||||
self.end_headers()
|
||||
self.wfile.write(json.dumps(data).encode())
|
||||
|
||||
def _send_error(self, code, message):
|
||||
self.send_response(code)
|
||||
self.send_header("Content-Type", "application/json")
|
||||
self.end_headers()
|
||||
self.wfile.write(json.dumps({"error": message}).encode())
|
||||
|
||||
def log_message(self, format, *args):
|
||||
pass
|
||||
|
||||
|
||||
class DashboardApp:
|
||||
"""Main dashboard application."""
|
||||
|
||||
def __init__(self, start_path: Optional[Path] = None, host: str = "localhost", port: int = 8080):
|
||||
self.start_path = start_path or Path.cwd()
|
||||
self.host = host
|
||||
self.port = port
|
||||
self.project_root: Optional[Path] = None
|
||||
self.scope: str = "none"
|
||||
self.config: Optional[DashboardConfig] = None
|
||||
self._server: Optional[HTTPServer] = None
|
||||
|
||||
def initialize(self) -> bool:
|
||||
project_root, scope = detect_scope(self.start_path)
|
||||
if scope == "none":
|
||||
print("Error: Not inside an automaton project.")
|
||||
print(" The dashboard must be run from a project root or ~/.automaton/")
|
||||
return False
|
||||
self.project_root = project_root
|
||||
self.scope = scope
|
||||
config_path = get_config_path(self.project_root)
|
||||
self.config = DashboardConfig.from_file(config_path)
|
||||
return True
|
||||
|
||||
def run(self) -> None:
|
||||
self._server = HTTPServer((self.host, self.port), DashboardHandler)
|
||||
scope_text = "Framework" if self.scope == "framework" else "Project"
|
||||
print(f"\n{'=' * 60}")
|
||||
print(f" Automaton Dashboard - {scope_text} Mode")
|
||||
print(f"{'=' * 60}")
|
||||
print(f" Open: http://{self.host}:{self.port}")
|
||||
print(f"{'=' * 60}\n")
|
||||
print("Press Ctrl+C to stop\n")
|
||||
try:
|
||||
self._server.serve_forever()
|
||||
except KeyboardInterrupt:
|
||||
print("\nDashboard stopped.")
|
||||
|
||||
def stop(self) -> None:
|
||||
if self._server:
|
||||
self._server.shutdown()
|
||||
@@ -0,0 +1,61 @@
|
||||
# Framework Configuration
|
||||
|
||||
This file contains global framework settings that apply across all projects.
|
||||
|
||||
## VRAM Configuration
|
||||
|
||||
Settings for task decomposition based on available VRAM.
|
||||
|
||||
- **Auto-detect**: Yes # Detect GPU VRAM, RAM, and model context window automatically
|
||||
- **Target context**: 16k tokens # Override auto-detect if needed
|
||||
- **Headroom**: 25% # Leave headroom for code, context, and reasoning
|
||||
- **Max peak context per sub-task**: 12k tokens # Max context for any single sub-task
|
||||
|
||||
### Auto-detection
|
||||
|
||||
When `Auto-detect: Yes`, the framework probes your system to detect:
|
||||
- GPU VRAM (via `nvidia-smi` or `lspci`)
|
||||
- System RAM (via `free`)
|
||||
- Model context window (via API config or model name lookup)
|
||||
- Framework overhead (by reading all loaded prompt files)
|
||||
|
||||
To disable auto-detection and use manual values:
|
||||
|
||||
```
|
||||
## VRAM Configuration
|
||||
- **Auto-detect**: No
|
||||
- **Target context**: 8k
|
||||
- **Headroom**: 30%
|
||||
- **Max peak context per sub-task**: 5.6k
|
||||
```
|
||||
|
||||
## Model Configuration
|
||||
|
||||
Settings for the LLM model being used.
|
||||
|
||||
- **Model**: auto # Use auto-detection from API config, or specify explicitly (e.g., gpt-4o, claude-3-5-sonnet)
|
||||
- **Override context window**: auto # Override auto-detection, or specify (e.g., 128k, 200k)
|
||||
|
||||
### Auto-detection
|
||||
|
||||
When `Model: auto`, the framework detects the model name from:
|
||||
1. `.agent.md` in the project (if specified there)
|
||||
2. API config files (`.env`, `config.yaml`, `config.json`, etc.)
|
||||
3. Model name lookup by name (e.g., gpt-4o → 128k, claude-3-5-sonnet → 200k)
|
||||
|
||||
To disable auto-detection and use manual values:
|
||||
|
||||
```
|
||||
## Model Configuration
|
||||
- **Model**: gpt-4o
|
||||
- **Override context window**: 128k
|
||||
```
|
||||
|
||||
## System Requirements
|
||||
|
||||
Requirements for the environment the framework runs in.
|
||||
|
||||
- **nvidia-smi**: Required if NVIDIA GPU (for VRAM detection)
|
||||
- **lspci**: Fallback if NVIDIA GPU not available (for AMD GPU VRAM detection)
|
||||
- **/proc/meminfo**: Required for RAM detection (Linux)
|
||||
- **sysctl**: Fallback for RAM detection (macOS)
|
||||
@@ -0,0 +1,11 @@
|
||||
## VRAM Configuration Contract
|
||||
|
||||
### Acceptance Criteria
|
||||
- [ ] Target VRAM context is specified
|
||||
- [ ] Headroom is specified (recommended: 25-40%)
|
||||
- [ ] Max peak context per sub-task is calculated
|
||||
- [ ] Sub-tasks are sized to fit within the max peak context
|
||||
- [ ] VRAM_CONFIG.md is propagated to each sub-task
|
||||
|
||||
### Stop Condition
|
||||
When all checkboxes are checked, output "CONTRACT_MET" and stop.
|
||||
@@ -0,0 +1,9 @@
|
||||
from pathlib import Path
|
||||
from automaton.dashboard.core.scope import find_automaton_root
|
||||
|
||||
print(f"Current directory: {Path.cwd()}")
|
||||
root = find_automaton_root()
|
||||
print(f"Automaton root: {root}")
|
||||
if root:
|
||||
print(f"Tasks directory: {root / '.automaton' / 'tasks'}")
|
||||
print(f"Tasks directory exists: {(root / '.automaton' / 'tasks').exists()}")
|
||||
-16
@@ -1,16 +0,0 @@
|
||||
#!/bin/bash
|
||||
set -e
|
||||
|
||||
FRAMEWORK_DIR="$HOME/.agent-framework"
|
||||
|
||||
if [ -d "$FRAMEWORK_DIR" ]; then
|
||||
echo "agent-framework already installed at $FRAMEWORK_DIR"
|
||||
echo "Run 'cd $FRAMEWORK_DIR && git pull' to update."
|
||||
exit 0
|
||||
fi
|
||||
|
||||
echo "Cloning agent-framework to $FRAMEWORK_DIR..."
|
||||
git clone https://gitea.yourdomain.com/you/agent-framework.git "$FRAMEWORK_DIR"
|
||||
|
||||
echo "Installation complete."
|
||||
echo "Next step: cd into a project and run the onboarding prompt."
|
||||
@@ -1,9 +1,20 @@
|
||||
You are the Adversarial Bug Finder.
|
||||
|
||||
Read the SPEC.md and the code.
|
||||
## Read These Files
|
||||
|
||||
1. {project}/tasks/{task-name}/SPEC.md
|
||||
2. {project}/tasks/{task-name}/VRAM_CONFIG.md (if exists)
|
||||
3. {project}/tasks/{task-name}/PARENT_SPEC.md (if exists)
|
||||
4. The code
|
||||
|
||||
Your job is to find bugs that are difficult to spot, such as complex logic errors, race conditions, and performance bottlenecks. Be more aggressive and exhaustive than a standard bug finder.
|
||||
|
||||
If VRAM_CONFIG.md exists, also check for:
|
||||
- Memory leaks (loading large files into context that could cause OOM)
|
||||
- N+1 query patterns that could cause memory exhaustion
|
||||
- Infinite loops that could run out of context
|
||||
- Unbounded recursion that could cause stack overflow
|
||||
|
||||
Output your findings in ADVERSARIAL_BUG_REPORT.md.
|
||||
|
||||
When finished, output "ADVERSARIAL_BUG_FIND_COMPLETE".
|
||||
@@ -5,6 +5,8 @@ You are the Bug Finder. Your job is to find every bug, deviation from spec, and
|
||||
1. {project}/tasks/{task-name}/SPEC.md
|
||||
2. {project}/tasks/{task-name}/{task-name}_CONTRACT.md (if exists)
|
||||
3. {project}/tasks/{task-name}/IMPLEMENTATION.md (if exists)
|
||||
4. {project}/tasks/{task-name}/VRAM_CONFIG.md (if exists)
|
||||
5. {project}/tasks/{task-name}/PARENT_SPEC.md (if exists)
|
||||
|
||||
## Task
|
||||
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
You are performing a compaction pass on the agent's rules and skills.
|
||||
|
||||
## Read These Files
|
||||
1. {project}/.agent-framework/RULES.md
|
||||
2. {project}/.agent-framework/AGENT.md
|
||||
3. Any accumulated notes or previous RULES.md versions in the project
|
||||
1. {project}/.automaton/.rules.md (if exists — project override) OR ~/.automaton/.rules.md (global default) — project-specific rules
|
||||
2. {project}/.automaton/.agent.md (if exists — project override) OR ~/.automaton/.agent.md (global default) — project agent config
|
||||
3. Any accumulated notes or previous .rules.md versions in the project
|
||||
|
||||
## Task
|
||||
Consolidate and clean up the rules and routing logic.
|
||||
@@ -11,12 +11,12 @@ Consolidate and clean up the rules and routing logic.
|
||||
## Compaction Rules
|
||||
- Remove duplicate or contradictory rules
|
||||
- Merge related rules into the smallest number of clear statements
|
||||
- Update AGENT.md routing logic if any new patterns have emerged
|
||||
- Update .agent.md routing logic if any new patterns have emerged
|
||||
- Keep every rule that still prevents a real observed failure mode
|
||||
- Delete anything that has not been referenced in the last 5 tasks
|
||||
|
||||
## Output
|
||||
Produce an updated RULES.md and AGENT.md.
|
||||
Produce an updated .rules.md and .agent.md.
|
||||
|
||||
At the end, output:
|
||||
"COMPACTION_COMPLETE — X rules removed, Y rules merged, Z rules added."
|
||||
|
||||
@@ -0,0 +1,233 @@
|
||||
You are in decomposition mode.
|
||||
|
||||
Your only job is to take a completed SPEC.md and break it into the smallest possible, independently verifiable sub-tasks. Each sub-task should be small enough to complete in one session and should have clear, testable acceptance criteria.
|
||||
|
||||
## Read These Files
|
||||
|
||||
1. {project}/tasks/{task-name}/SPEC.md
|
||||
2. {project}/.automaton/.rules.md (if exists — project override) OR ~/.automaton/.rules.md (global default) — project-specific rules
|
||||
3. ~/.automaton/config.md — Global framework configuration (VRAM, model settings)
|
||||
4. {project}/.automaton/.agent.md (if exists — project override) OR ~/.automaton/.agent.md (global default) — project agent config
|
||||
5. {project}/.automaton/scripts/vram_detect.sh (if exists — project override) OR ~/.automaton/scripts/vram_detect.sh (global default) — VRAM detection
|
||||
|
||||
## Task
|
||||
|
||||
{task-description}
|
||||
|
||||
## Decomposition Rules
|
||||
|
||||
### Rule 1: Smallest Possible Unit
|
||||
Break every feature into the smallest possible units that are still independently testable. If a sub-task can be done in one session, it should be a sub-task.
|
||||
|
||||
### Rule 2: Each Sub-Task Must Be Self-Contained
|
||||
Each sub-task must have:
|
||||
- Its own goal statement (one sentence)
|
||||
- Clear acceptance criteria (at least 2-3)
|
||||
- Dependencies on other sub-tasks (if any)
|
||||
- Its own contract (SPEC.md) that references the parent task
|
||||
|
||||
### Rule 3: Dependencies Must Be Explicit
|
||||
If sub-task B depends on sub-task A, state it clearly. A sub-task with no dependencies can run in parallel. Sub-tasks that depend on parallel sub-tasks must wait for both.
|
||||
|
||||
### Rule 4: Define Execution Order
|
||||
After listing all sub-tasks, define the execution order considering dependencies. Group independent sub-tasks into "waves" that can be done in parallel.
|
||||
|
||||
### Rule 5: Do Not Create Sub-Sub-Tasks
|
||||
Decomposition produces **one level** of sub-tasks only. If a sub-task is still too large, the implementer should break it down further during implementation, but do NOT nest sub-tasks.
|
||||
|
||||
### Rule 6: Token Budget Per Sub-Task
|
||||
Each sub-task must fit within the target VRAM context window. Estimate the total token budget for each sub-task's full lifecycle and break it down further if it exceeds the limit.
|
||||
|
||||
**How to estimate token budget for a sub-task:**
|
||||
|
||||
During a sub-task's lifecycle, the following files are loaded into context at various phases:
|
||||
|
||||
- **Research phase**: .rules.md + .agent.md + task description
|
||||
- **Design phase**: SPEC.md + .rules.md
|
||||
- **Implement phase**: SPEC.md + DESIGN.md + TEST_PLAN.md + .rules.md + .agent.md + CONTRACT.md
|
||||
- **Bug Find phase**: SPEC.md + code (limited scope)
|
||||
- **Adversarial Bug Find phase**: SPEC.md + code (limited scope)
|
||||
- **Doc Review phase**: DESIGN.md
|
||||
- **Referee phase**: SPEC.md + BUG_REPORT.md + ADVERSARIAL_BUG_REPORT.md + DOC_REVIEW.md
|
||||
|
||||
The **peak context** is during the Implement phase, where all files are loaded together. Estimate the token count of the combined files for the sub-task.
|
||||
|
||||
**Guidelines:**
|
||||
- **8k VRAM**: Peak context for Implement phase should be ≤ 6k tokens (leave 2k headroom). This means the sub-task's SPEC.md + DESIGN.md + TEST_PLAN.md combined should be ≤ 6k tokens.
|
||||
- **16k VRAM**: Peak context for Implement phase should be ≤ 12k tokens (leave 4k headroom). This means the sub-task's SPEC.md + DESIGN.md + TEST_PLAN.md combined should be ≤ 12k tokens.
|
||||
- **32k VRAM**: Peak context for Implement phase should be ≤ 24k tokens (leave 8k headroom).
|
||||
- **64k VRAM**: Peak context for Implement phase should be ≤ 48k tokens (leave 16k headroom).
|
||||
|
||||
If a sub-task's estimated context exceeds the limit, break it into smaller sub-tasks.
|
||||
|
||||
**How to estimate token count:**
|
||||
- Roughly 1 token = 4 characters (for English text)
|
||||
- A SPEC.md with 5 requirements, each with 2-3 acceptance criteria, is typically 500-1000 tokens
|
||||
- A DESIGN.md with 3 sections and 5-10 bullet points is typically 1000-3000 tokens
|
||||
- A TEST_PLAN.md with 5-10 test cases is typically 1000-2000 tokens
|
||||
- .rules.md is typically 200-1000 tokens (varies per project)
|
||||
- .agent.md is typically 300-1000 tokens
|
||||
- A CONTRACT.md is typically 200-500 tokens
|
||||
|
||||
**Quick estimate formula:**
|
||||
```
|
||||
Peak context ≈ SPEC.md tokens + DESIGN.md tokens + TEST_PLAN.md tokens + .rules.md tokens + .agent.md tokens + CONTRACT.md tokens
|
||||
```
|
||||
|
||||
### Rule 7: Sub-Task Size Targets
|
||||
Aim for sub-tasks that are:
|
||||
- **Small** (8k VRAM): ~200-800 tokens of combined spec/design/test files
|
||||
- **Small** (16k VRAM): ~200-1500 tokens of combined spec/design/test files
|
||||
- **Medium** (8k VRAM): ~800-2000 tokens of combined spec/design/test files
|
||||
- **Medium** (16k VRAM): ~1500-4000 tokens of combined spec/design/test files
|
||||
- **Large** (8k VRAM): ~2000-4000 tokens of combined spec/design/test files
|
||||
- **Large** (16k VRAM): ~4000-8000 tokens of combined spec/design/test files
|
||||
|
||||
If a sub-task exceeds the "Large" target for the target VRAM, break it further.
|
||||
|
||||
## Decomposition Protocol (Interactive)
|
||||
|
||||
### Phase 1: Analysis
|
||||
|
||||
Before decomposing, analyze the SPEC.md:
|
||||
1. Identify all distinct features/requirements
|
||||
2. Identify data models that need to be created
|
||||
3. Identify API endpoints or interfaces
|
||||
4. Identify infrastructure changes
|
||||
5. Identify configuration changes
|
||||
6. Estimate the token budget for the full task (sum of all requirements' SPEC + DESIGN + TEST files)
|
||||
7. **Detect VRAM limits**:
|
||||
- Check `~/.automaton/config.md` for VRAM Configuration section
|
||||
- If `Auto-detect: Yes`, run `{project}/.automaton/scripts/vram_detect.sh` to probe GPU VRAM, RAM, and model context window
|
||||
- If `Auto-detect: No`, use the manually specified values from config.md
|
||||
- Report the detected VRAM limits
|
||||
8. **Detect model context window**:
|
||||
- Check `~/.automaton/config.md` for Model Configuration section
|
||||
- If `Model: auto`, run the detection script to detect the model name and its context window
|
||||
- If `Override context window: auto`, use the detected context window
|
||||
- If both are specified, use the specified values
|
||||
- If model detection fails, use 128k tokens as default
|
||||
9. Determine the target VRAM context window based on the detection results
|
||||
|
||||
### Phase 2: Propose Decomposition
|
||||
|
||||
Present a draft decomposition to the user. Format:
|
||||
|
||||
**Target VRAM**: {8k/16k/32k/64k} tokens
|
||||
|
||||
**Waves:**
|
||||
- **Wave 1**: Sub-task 1, Sub-task 2, Sub-task 3 (can run in parallel)
|
||||
- **Wave 2**: Sub-task 4, Sub-task 5 (depends on Wave 1)
|
||||
- **Wave 3**: Sub-task 6 (depends on Wave 2)
|
||||
|
||||
**Sub-task Details:**
|
||||
1. **{sub-task-name}**
|
||||
- Goal: {one sentence}
|
||||
- Dependencies: {list of sub-task names, or "None"}
|
||||
- Acceptance criteria:
|
||||
- [ ] {criterion 1}
|
||||
- [ ] {criterion 2}
|
||||
- Estimated scope: {small/medium/large}
|
||||
- **Estimated token budget**: ~{estimate} tokens (peak: ~{peak} tokens during Implement phase)
|
||||
- **Fits within VRAM**: Yes/No (if No, explain why and suggest how to split further)
|
||||
|
||||
### Phase 3: Review and Refine
|
||||
|
||||
Present the draft decomposition to the user and ask:
|
||||
- "Are there any sub-tasks that are too large?"
|
||||
- "Are there any sub-tasks that should be combined?"
|
||||
- "Are the dependencies correct?"
|
||||
- "Are there any sub-tasks I missed?"
|
||||
- "Is the execution order optimal?"
|
||||
- "Do the token budget estimates look reasonable for your VRAM?"
|
||||
- "Are there any sub-tasks that exceed your VRAM limit?"
|
||||
|
||||
Incorporate the user's feedback and revise the decomposition accordingly.
|
||||
|
||||
### Phase 4: Get Sign-Off
|
||||
|
||||
Before writing the DECOMPOSITION.md, you MUST get explicit sign-off from the user. Say:
|
||||
|
||||
> "Based on our discussion, here is the final decomposition:
|
||||
> [brief summary of waves, sub-tasks, and token budgets]
|
||||
> Does this cover everything? Please confirm with 'APPROVED' before I finalize."
|
||||
|
||||
Only produce the DECOMPOSITION.md after the user says "APPROVED" or equivalent.
|
||||
|
||||
## Output
|
||||
|
||||
Produce a file called DECOMPOSITION.md at {project}/tasks/{task-name}/DECOMPOSITION.md that contains:
|
||||
|
||||
```markdown
|
||||
# Task Decomposition
|
||||
|
||||
## Parent Task
|
||||
{parent-task-name}
|
||||
|
||||
## VRAM Configuration
|
||||
- **Target VRAM**: {8k/16k/32k/64k} tokens
|
||||
- **Headroom**: {25-40%} (leaves headroom for code, context, and reasoning)
|
||||
- **Max peak context per sub-task**: {estimate} tokens
|
||||
|
||||
## Waves
|
||||
|
||||
### Wave 1: {wave-name}
|
||||
- {sub-task-name-1}
|
||||
- {sub-task-name-2}
|
||||
- {sub-task-name-3}
|
||||
|
||||
### Wave 2: {wave-name}
|
||||
- {sub-task-name-4}
|
||||
- {sub-task-name-5}
|
||||
|
||||
## Sub-Task Details
|
||||
|
||||
### 1. {sub-task-name-1}
|
||||
- **Goal**: {one sentence}
|
||||
- **Dependencies**: None (or list sub-task names)
|
||||
- **Acceptance Criteria**:
|
||||
- [ ] {criterion 1}
|
||||
- [ ] {criterion 2}
|
||||
- **Estimated Scope**: {small/medium/large}
|
||||
- **Estimated token budget**: ~{estimate} tokens
|
||||
- SPEC.md: ~{x} tokens
|
||||
- DESIGN.md: ~{x} tokens
|
||||
- TEST_PLAN.md: ~{x} tokens
|
||||
- .rules.md: ~{x} tokens
|
||||
- .agent.md: ~{x} tokens
|
||||
- CONTRACT.md: ~{x} tokens
|
||||
- **Peak context (Implement phase)**: ~{peak} tokens
|
||||
- **Fits within VRAM**: Yes
|
||||
|
||||
### 2. {sub-task-name-2}
|
||||
- **Goal**: {one sentence}
|
||||
- **Dependencies**: {list of sub-task names}
|
||||
- **Acceptance Criteria**:
|
||||
- [ ] {criterion 1}
|
||||
- [ ] {criterion 2}
|
||||
- **Estimated Scope**: {small/medium/large}
|
||||
- **Estimated token budget**: ~{estimate} tokens
|
||||
- SPEC.md: ~{x} tokens
|
||||
- DESIGN.md: ~{x} tokens
|
||||
- TEST_PLAN.md: ~{x} tokens
|
||||
- .rules.md: ~{x} tokens
|
||||
- .agent.md: ~{x} tokens
|
||||
- CONTRACT.md: ~{x} tokens
|
||||
- **Peak context (Implement phase)**: ~{peak} tokens
|
||||
- **Fits within VRAM**: Yes
|
||||
|
||||
... etc ...
|
||||
|
||||
## Execution Order
|
||||
1. Complete Wave 1 (all sub-tasks can run in parallel)
|
||||
2. Complete Wave 2 (depends on Wave 1)
|
||||
3. ... etc ...
|
||||
```
|
||||
|
||||
When the decomposition is complete, output "CONTRACT_MET" and stop.
|
||||
|
||||
Do not create sub-task folders or files. The Orchestrator will handle creating sub-task folders based on this DECOMPOSITION.md.
|
||||
|
||||
## Stop Condition (MANDATORY)
|
||||
You are not allowed to end this session until you have produced the DECOMPOSITION.md file AND output the exact phrase "CONTRACT_MET".
|
||||
Until then, continue working or ask clarifying questions.
|
||||
+59
-9
@@ -5,24 +5,50 @@ Your job is to create a clear, actionable design for the project based on the sp
|
||||
## Read These Files
|
||||
|
||||
1. {project}/tasks/{task-name}/SPEC.md
|
||||
2. {project}/.agent-framework/RULES.md
|
||||
2. {project}/.automaton/.rules.md (if exists — project override) OR ~/.automaton/.rules.md (global default) — project-specific rules
|
||||
|
||||
## Task
|
||||
|
||||
{task-description}
|
||||
|
||||
## Read These Files
|
||||
## Design Protocol (Interactive)
|
||||
|
||||
1. {project}/tasks/{task-name}/SPEC.md
|
||||
2. {project}/.agent-framework/RULES.md
|
||||
You are NOT allowed to produce a DESIGN.md without first having a thorough discussion with the user. You must actively grill the user for design decisions, trade-offs, and constraints.
|
||||
|
||||
## Task
|
||||
### Phase 1: Discovery Questions
|
||||
|
||||
{task-description}
|
||||
Before writing anything, ask the user questions to understand the full design. Group your questions by category:
|
||||
|
||||
## Output
|
||||
**Data Model:**
|
||||
- What are the core entities? What are their relationships?
|
||||
- What are the key fields for each entity?
|
||||
- What are the invariants/constraints that must be enforced?
|
||||
- How will data be stored (database type, caching strategy)?
|
||||
|
||||
Produce a file called `DESIGN.md` at {project}/tasks/{task-name}/DESIGN.md containing:
|
||||
**Architecture:**
|
||||
- Monolith or microservices? Why?
|
||||
- What are the main technology decisions and why?
|
||||
- How will data flow through the system?
|
||||
- What are the external dependencies (APIs, databases, services)?
|
||||
|
||||
**User Flows:**
|
||||
- What are the 3-5 most important user flows?
|
||||
- Are there any complex edge-case flows we need to design for?
|
||||
- What are the error paths and how should they be handled?
|
||||
|
||||
**Scope & Phasing:**
|
||||
- What is in the MVP? What is deferred?
|
||||
- What can be done incrementally?
|
||||
- What are the milestones?
|
||||
|
||||
**Risks:**
|
||||
- What are the biggest technical risks?
|
||||
- What are the biggest product risks?
|
||||
- What needs to be validated before committing?
|
||||
|
||||
### Phase 2: Present Draft DESIGN
|
||||
|
||||
After asking questions, present a draft DESIGN.md for review. The draft should contain:
|
||||
|
||||
### 1. Data Model
|
||||
- Core entities and their relationships
|
||||
@@ -54,9 +80,33 @@ Produce a file called `DESIGN.md` at {project}/tasks/{task-name}/DESIGN.md conta
|
||||
### 7. Non-Functional Requirements
|
||||
- Performance, security, reliability, or scale considerations (if relevant)
|
||||
|
||||
When the design is complete, output "CONTRACT_MET" and stop.
|
||||
### Phase 3: Review and Refine
|
||||
|
||||
Present the draft DESIGN to the user and ask:
|
||||
- "Does this cover everything? What am I missing?"
|
||||
- "Are there any design decisions that are wrong or incomplete?"
|
||||
- "Are there any risks I should have considered?"
|
||||
- "Are there any constraints I should have included?"
|
||||
|
||||
Incorporate the user's feedback and revise the DESIGN accordingly. Repeat this loop until the user signs off.
|
||||
|
||||
### Phase 4: Get Sign-Off
|
||||
|
||||
Before writing the DESIGN.md, you MUST get explicit sign-off from the user. Say:
|
||||
|
||||
> "Based on our discussion, here is the final design:
|
||||
> [brief summary]
|
||||
> Does this cover everything? Please confirm with 'APPROVED' before I finalize."
|
||||
|
||||
Only produce the DESIGN.md after the user says "APPROVED" or equivalent.
|
||||
|
||||
## Rules
|
||||
- Stay at the design level. Do not write code or detailed implementation steps.
|
||||
- Be specific enough that implementation can proceed with clarity.
|
||||
- If something is unclear, state the assumption and move on.
|
||||
|
||||
When the design is complete, output "CONTRACT_MET" and stop.
|
||||
|
||||
## Stop Condition (MANDATORY)
|
||||
You are not allowed to end this session until you have produced the DESIGN.md file AND output the exact phrase "CONTRACT_MET".
|
||||
Until then, continue working or ask clarifying questions.
|
||||
|
||||
@@ -0,0 +1,103 @@
|
||||
You are in Documentation Review mode.
|
||||
|
||||
## Read These Files
|
||||
|
||||
1. {project}/tasks/{task-name}/DESIGN.md — Look for the "Documentation Plan" section
|
||||
2. {project}/tasks/{task-name}/SPEC.md — Check what the spec requires
|
||||
3. {project}/tasks/{task-name}/VRAM_CONFIG.md (if exists)
|
||||
4. {project}/tasks/{task-name}/PARENT_SPEC.md (if exists)
|
||||
5. Any existing documentation files mentioned in the DESIGN.md Documentation Plan
|
||||
6. The code that was implemented (implementation artifacts)
|
||||
|
||||
## Task
|
||||
|
||||
{task-description}
|
||||
|
||||
## Documentation Review Checklist
|
||||
|
||||
### DESIGN.md Documentation Plan
|
||||
- Read the "Documentation Plan" section in DESIGN.md
|
||||
- For each item listed, verify it exists and is accurate:
|
||||
- README sections
|
||||
- API documentation
|
||||
- Docstrings
|
||||
- Architecture diagrams
|
||||
- Any other documentation mentioned
|
||||
|
||||
### Documentation Completeness
|
||||
- Are all code modules/classes/functions documented with docstrings?
|
||||
- Is there a README that explains how to use the feature?
|
||||
- Are there any user-facing interfaces without documentation?
|
||||
- Are edge cases and error conditions documented?
|
||||
|
||||
### Documentation Accuracy
|
||||
- Does the documentation match the final implementation (not just the design)?
|
||||
- Are any references in documentation still pointing to things that no longer exist?
|
||||
- Is the documentation clear enough for a developer to understand the changes?
|
||||
|
||||
### Documentation Gaps
|
||||
- Are there any areas where the documentation is thin or missing?
|
||||
- Are there any complex flows or non-obvious logic that should be documented?
|
||||
- If VRAM_CONFIG.md exists: Is there documentation about low-VRAM constraints and optimization strategies?
|
||||
|
||||
## Output
|
||||
|
||||
If the DESIGN.md has a Documentation Plan section, produce a `DOC_REVIEW.md` at `{project}/tasks/{task-name}/DOC_REVIEW.md` with:
|
||||
|
||||
```markdown
|
||||
# Documentation Review: {task-name}
|
||||
|
||||
## Summary
|
||||
{Brief overview of documentation review}
|
||||
|
||||
## Documentation Plan Compliance
|
||||
- [ ] {Item from DESIGN.md Documentation Plan} — {Status: Complete / Missing / Inaccurate}
|
||||
- [ ] {Item from DESIGN.md Documentation Plan} — {Status: Complete / Missing / Inaccurate}
|
||||
|
||||
## Documentation Completeness
|
||||
- Code documentation: {Status}
|
||||
- User documentation: {Status}
|
||||
- API documentation: {Status}
|
||||
|
||||
## Issues Found
|
||||
### Issue 1: {Title}
|
||||
- **Severity**: Critical / High / Medium / Low
|
||||
- **Description**: {What's wrong}
|
||||
- **Suggested Fix**: {Fix}
|
||||
|
||||
## Score
|
||||
{+5 for Complete, 0 for Missing/Inaccurate, -10 for Critical Missing}
|
||||
```
|
||||
|
||||
If the DESIGN.md does **not** have a Documentation Plan section, produce a `DOC_REVIEW.md` with:
|
||||
|
||||
```markdown
|
||||
# Documentation Review: {task-name}
|
||||
|
||||
## Summary
|
||||
No Documentation Plan found in DESIGN.md. Performing ad-hoc documentation review.
|
||||
|
||||
## Documentation Completeness
|
||||
- Code documentation: {Status}
|
||||
- User documentation: {Status}
|
||||
- API documentation: {Status}
|
||||
|
||||
## Issues Found
|
||||
### Issue 1: {Title}
|
||||
- **Severity**: Critical / High / Medium / Low
|
||||
- **Description**: {What's wrong}
|
||||
- **Suggested Fix**: {Fix}
|
||||
|
||||
## Score
|
||||
{+5 for Complete, 0 for Missing/Inaccurate, -10 for Critical Missing}
|
||||
```
|
||||
|
||||
## Important
|
||||
|
||||
- If documentation is missing or inaccurate, **update it** — don't just report the issue.
|
||||
- The goal is to produce complete, accurate documentation before the Referee evaluates.
|
||||
- Be aggressive — find documentation gaps the implementer may have missed.
|
||||
|
||||
## Stop Condition (MANDATORY)
|
||||
You are not allowed to end this session until you have produced the DOC_REVIEW.md file AND output the exact phrase "CONTRACT_MET".
|
||||
Until then, continue working or ask clarifying questions.
|
||||
+18
-2
@@ -3,10 +3,13 @@ You are in implementation mode.
|
||||
## Read These Files
|
||||
|
||||
1. {project}/tasks/{task-name}/SPEC.md
|
||||
2. {project}/.agent-framework/RULES.md
|
||||
3. {project}/.agent-framework/AGENT.md (if exists)
|
||||
2. {project}/.automaton/.rules.md (if exists — project override) OR ~/.automaton/.rules.md (global default) — project-specific rules
|
||||
3. {project}/.automaton/.agent.md (if exists — project override) OR ~/.automaton/.agent.md (global default) — project agent config
|
||||
4. {project}/tasks/{task-name}/{task-name}_CONTRACT.md (if exists)
|
||||
5. {project}/tasks/{task-name}/DESIGN.md (if exists)
|
||||
6. {project}/tasks/{task-name}/TEST_PLAN.md (if exists)
|
||||
7. {project}/tasks/{task-name}/VRAM_CONFIG.md (if exists — for low-VRAM systems)
|
||||
8. {project}/tasks/{task-name}/PARENT_SPEC.md (if exists — for sub-tasks)
|
||||
|
||||
## Task
|
||||
|
||||
@@ -25,9 +28,22 @@ You are in implementation mode.
|
||||
- Keep functions small and focused.
|
||||
- Use existing patterns in the codebase.
|
||||
|
||||
### VRAM-Aware Implementation (if VRAM_CONFIG.md exists)
|
||||
|
||||
If `VRAM_CONFIG.md` is present, the implementer is working in a low-VRAM environment and must:
|
||||
|
||||
- **Keep functions small**: Each function should be ≤ 50 lines. Break large functions into smaller ones.
|
||||
- **Avoid loading large files into context**: If implementing in an iterative environment (like pi), read files incrementally rather than loading entire files at once.
|
||||
- **Write self-contained modules**: Each module should be independently testable and runnable without loading the entire codebase.
|
||||
- **Prefer streaming over buffering**: Use streaming patterns instead of loading entire datasets into memory.
|
||||
- **Be explicit about dependencies**: Import only what you need, not the entire module.
|
||||
- **Test incrementally**: Run tests frequently rather than building up a large test suite that takes a long time to run.
|
||||
- **Optimize for low-VRAM**: Write code that can be understood and modified by an agent with limited context window.
|
||||
|
||||
### End State
|
||||
- You are NOT done until ALL acceptance criteria in the SPEC.md (and CONTRACT.md if it exists) are met
|
||||
- All tests must pass.
|
||||
- **Tests**: All test cases in the TEST_PLAN.md (if present) must be implemented and passing. The TEST_PLAN.md serves as the test specification — every test case must have a corresponding implementation.
|
||||
- **Documentation**: All documentation identified in the DESIGN.md must be updated or created.
|
||||
- Run the full test suite and report results
|
||||
- Do NOT declare victory until tests pass
|
||||
|
||||
+116
-13
@@ -4,10 +4,11 @@ Your only job is to set up the minimal agent framework structure in the target p
|
||||
|
||||
## Read These Files
|
||||
|
||||
1. ~/.agent-framework/AGENT.md — global framework router
|
||||
2. ~/.agent-framework/ONBOARDING.md — human reference for drop-in vs from-scratch scenarios
|
||||
3. {project}/.agent-framework/AGENT.md (if it exists)
|
||||
4. {project}/.agent-framework/RULES.md (if it exists)
|
||||
1. ~/.automaton/.agent.md — global framework router
|
||||
2. ~/.automaton/.onboarding.md — human reference for drop-in vs from-scratch scenarios
|
||||
3. {project}/.automaton/.agent.md (if it exists — project override)
|
||||
4. {project}/.automaton/.rules.md (if it exists — project override)
|
||||
5. ~/.automaton/scripts/vram_detect.sh (if exists — for VRAM detection)
|
||||
|
||||
## Task
|
||||
|
||||
@@ -15,22 +16,62 @@ Your only job is to set up the minimal agent framework structure in the target p
|
||||
|
||||
## Onboarding Ritual (Strict Sequence)
|
||||
|
||||
1. Check if {project}/.agent-framework/ exists. If not, create it.
|
||||
### Step 0: Check if Framework Needs Upgrade
|
||||
|
||||
Before proceeding, check if the project is running an older version of the framework:
|
||||
1. Compare the project's `.automaton/` files with the global `~/.automaton/` files.
|
||||
2. If the project's `.automaton/` has a file that differs from the current global version, the project needs an upgrade.
|
||||
3. If the project's `.automaton/` is missing files that exist in the global framework (e.g., new prompt files like `doc_review.md`, `test_design.md`), the project needs an upgrade.
|
||||
4. If an upgrade is needed, report it to the user and offer to upgrade the project's framework files.
|
||||
|
||||
**Precedence**: The project's `.automaton/` files override the global `~/.automaton/` files. The Orchestrator reads from the project's directory first, then falls back to the global directory.
|
||||
|
||||
### Step 1: Discovery
|
||||
|
||||
1. Check if {project}/.automaton/ exists. If not, create it.
|
||||
2. Ensure exactly two files exist inside it:
|
||||
- AGENT.md (project-level router)
|
||||
- RULES.md (project-specific constraints)
|
||||
- .agent.md (project-level router — project override of the global framework)
|
||||
- .rules.md (project-specific constraints — project override of the global framework)
|
||||
3. If the files are missing or empty, create minimal versions:
|
||||
- AGENT.md should point to the global framework and list any project-specific additions.
|
||||
- RULES.md should contain only hard, non-negotiable constraints for this project.
|
||||
4. Read the global ~/.agent-framework/AGENT.md and the new project-level AGENT.md + RULES.md.
|
||||
- .agent.md should point to the global framework and list any project-specific additions. By default, Autopilot is Enabled — the Orchestrator will drive tasks through all phases automatically. Set Autopilot: Disabled if you want to manually run each phase.
|
||||
- .rules.md should contain only hard, non-negotiable constraints for this project.
|
||||
4. Read the project's .agent.md + .rules.md, then read the global ~/.automaton/.agent.md for comparison.
|
||||
5. Explore the project root at a high level (ls, key directories, README if present).
|
||||
6. Produce a short onboarding report.
|
||||
|
||||
**Important**: The project's `.automaton/` directory should only contain .agent.md and .rules.md. All other framework files (prompts, contracts, scripts) are read from the global `~/.automaton/` directory. The project's directory is the override layer — if a file exists in both, the project's version takes precedence.
|
||||
|
||||
### Step 2: VRAM Configuration
|
||||
|
||||
Check if VRAM configuration is available in `~/.automaton/config.md`:
|
||||
1. Read `~/.automaton/config.md` to check for VRAM Configuration section.
|
||||
2. If VRAM Configuration section exists, note the values.
|
||||
3. If VRAM Configuration section does NOT exist, check if VRAM detection is available: `~/.automaton/scripts/vram_detect.sh`.
|
||||
4. If available, run it to get VRAM recommendations:
|
||||
```
|
||||
cd ~/.automaton && bash ~/.automaton/scripts/vram_detect.sh
|
||||
```
|
||||
5. Parse the JSON output for `recommended_k`, `max_peak_context_kb`, and `headroom`.
|
||||
6. Add a VRAM Configuration section to `~/.automaton/config.md`:
|
||||
```
|
||||
## VRAM Configuration
|
||||
- **Auto-detect**: Yes
|
||||
- **Target context**: {recommended_k}k tokens
|
||||
- **Headroom**: 25%
|
||||
- **Max peak context per sub-task**: {max_peak_kb/1000}k tokens
|
||||
```
|
||||
7. If VRAM detection failed or is not available, add a minimal section:
|
||||
```
|
||||
## VRAM Configuration
|
||||
- **Auto-detect**: Yes
|
||||
```
|
||||
8. Report the VRAM configuration status in the onboarding report.
|
||||
|
||||
## Output
|
||||
|
||||
Create or update the following inside {project}/.agent-framework/:
|
||||
- AGENT.md
|
||||
- RULES.md
|
||||
Create or update the following inside {project}/.automaton/:
|
||||
- .agent.md
|
||||
- .rules.md
|
||||
|
||||
Then produce a file called ONBOARDING_REPORT.md at {project}/tasks/onboarding/ONBOARDING_REPORT.md containing:
|
||||
|
||||
@@ -39,6 +80,8 @@ Then produce a file called ONBOARDING_REPORT.md at {project}/tasks/onboarding/ON
|
||||
- What process this project expects
|
||||
- Key observations from the project structure
|
||||
- Any missing pieces the human should provide next
|
||||
- **Upgrade status**: Whether the project's framework files are up to date with the global framework
|
||||
- **VRAM Configuration**: Whether VRAM config was auto-detected and applied (if available), or needs manual setup
|
||||
|
||||
When the ritual is complete, output "CONTRACT_MET" and stop.
|
||||
|
||||
@@ -50,3 +93,63 @@ Do not begin any research, implementation, or bug-finding tasks.
|
||||
- Keep everything minimal. Only create the two required files.
|
||||
- Never copy the entire global framework into the project.
|
||||
- This is a one-time setup. After this session the normal research → implement flow takes over.
|
||||
|
||||
---
|
||||
|
||||
## Project Upgrade
|
||||
|
||||
When a user asks to "upgrade automaton for this project," the agent should:
|
||||
|
||||
### Upgrade Process
|
||||
|
||||
1. **Compare the project's `~/.automaton/` files with the global `~/.automaton/` files.**
|
||||
- For each file in the global framework, check if it exists in the project's framework.
|
||||
- If it exists in both, compare their content.
|
||||
|
||||
2. **Identify three categories of files:**
|
||||
- **Customized** — The file exists in both, but they differ. The project has customized it. **Keep the project's version.**
|
||||
- **Outdated** — The file exists in both, but they are identical. The project hasn't customized it, but the global version has changed. **Update from global.**
|
||||
- **New** — The file exists in the global framework but not in the project. **Add from global.**
|
||||
|
||||
3. **Apply upgrades:**
|
||||
- For **Outdated** files: Copy from the global framework to the project's framework (update the project's version).
|
||||
- For **New** files: Copy from the global framework to the project's framework (add the file).
|
||||
- For **Customized** files: **Do NOT overwrite** — keep the project's version and report it as "skipped (customized)."
|
||||
|
||||
4. **Report what was upgraded and what was already up to date.**
|
||||
|
||||
### Upgrade Report Format
|
||||
|
||||
The agent should report:
|
||||
- **Upgraded**: Files that were updated from the global framework (Outdated → Upgraded)
|
||||
- **Added**: New files added from the global framework (New → Added)
|
||||
- **Skipped**: Files that were customized in the project and not overwritten (Customized → Skipped)
|
||||
- **Already up to date**: Files that were already identical (shouldn't happen, but report for completeness)
|
||||
|
||||
### Example Upgrade Scenarios
|
||||
|
||||
**Scenario 1: New file added globally**
|
||||
- User says: "Upgrade automaton for this project"
|
||||
- Agent detects that `prompts/test_design.md` is missing from the project's framework
|
||||
- Agent copies `prompts/test_design.md` from the global framework into the project's framework
|
||||
- Agent reports: "Upgraded: Added prompts/test_design.md. Your framework is now up to date."
|
||||
|
||||
**Scenario 2: Global file changed, project hasn't customized it**
|
||||
- User says: "Upgrade automaton for this project"
|
||||
- Agent detects that `prompts/orchestrate.md` has changed in the global framework, and the project's version is identical to the old global version
|
||||
- Agent copies `prompts/orchestrate.md` from the global framework into the project's framework
|
||||
- Agent reports: "Upgraded: Updated prompts/orchestrate.md. Your framework is now up to date."
|
||||
|
||||
**Scenario 3: Global file changed, project has customized it**
|
||||
- User says: "Upgrade automaton for this project"
|
||||
- Agent detects that `prompts/orchestrate.md` has changed in the global framework, and the project's version differs from the global version
|
||||
- Agent keeps the project's version of `prompts/orchestrate.md`
|
||||
- Agent reports: "Skipped: prompts/orchestrate.md (customized in your project). Your framework is now up to date."
|
||||
|
||||
**Scenario 4: Multiple changes**
|
||||
- User says: "Upgrade automaton for this project"
|
||||
- Agent detects:
|
||||
- `prompts/test_design.md` is new → **Added**
|
||||
- `prompts/workflow.md` has changed, project hasn't customized → **Upgraded**
|
||||
- `.agent.md` has changed, project has customized → **Skipped (customized)**
|
||||
- Agent reports: "Upgraded: Updated prompts/workflow.md. Added: Added prompts/test_design.md. Skipped: .agent.md (customized in your project). Your framework is now up to date."
|
||||
+439
-18
@@ -1,42 +1,463 @@
|
||||
You are the Orchestrator Driver. Your job is to analyze the current state of the project and drive it toward completion by identifying and proposing the next logical step in the lifecycle.
|
||||
You are the Orchestrator Driver. Your job is to act as a **state machine** for the project's tasks. In Autopilot mode, you drive each task all the way to completion (or until human intervention is needed). In manual mode, you only report the current state and the next command.
|
||||
|
||||
## Read These Files
|
||||
|
||||
1. {project}/.agent-framework/AGENT.md
|
||||
2. {project}/.agent-framework/RULES.md
|
||||
3. {project}/.agent-framework/prompts/workflow.md — The State Machine
|
||||
4. Any existing files under {project}/tasks/
|
||||
The Orchestrator reads files using a **layered approach** with a clear precedence:
|
||||
|
||||
1. **Project overrides** (highest precedence): `{project}/.automaton/` — contains project-specific customizations
|
||||
2. **Global framework** (default): `~/.automaton/` — contains the base framework files
|
||||
|
||||
**Precedence rule**: If a file exists in the project's `.automaton/` directory, the Orchestrator reads it from there. If it doesn't exist, the Orchestrator reads it from the global `~/.automaton/` directory.
|
||||
|
||||
Specifically:
|
||||
1. {project}/.automaton/.agent.md (if exists — project override) OR ~/.automaton/.agent.md (global default)
|
||||
2. {project}/.automaton/.rules.md (if exists — project override) OR ~/.automaton/.rules.md (global default)
|
||||
3. ~/.automaton/config.md — Global framework configuration (VRAM, model settings)
|
||||
4. {project}/.automaton/prompts/*.md (if exists — project overrides) OR ~/.automaton/prompts/*.md (global default)
|
||||
5. {project}/.automaton/contracts/*.md (if exists — project overrides) OR ~/.automaton/contracts/*.md (global default)
|
||||
6. {project}/.automaton/scripts/*.sh (if exists — project overrides) OR ~/.automaton/scripts/*.sh (global default)
|
||||
7. Any existing files under {project}/tasks/
|
||||
|
||||
## VRAM Detection
|
||||
|
||||
When VRAM configuration is needed (during task decomposition, sub-task creation, etc.), the Orchestrator MUST attempt to detect VRAM/VRAM limits dynamically.
|
||||
|
||||
### Detection Priority
|
||||
|
||||
1. **Auto-detect via script**: Check if `{project}/.automaton/scripts/vram_detect.sh` exists. If it does, run it to probe GPU VRAM, RAM, and model context window. Parse the JSON output for `recommended_kb`, `headroom`, and `max_peak_context_kb`.
|
||||
2. **Auto-detect via API config**: If the script is not available, try to detect the model name from `.agent.md` or config files (`.env`, `config.yaml`, etc.) and look up its context window. **Important**: Only read the specific lines needed (e.g., the model name line), not the entire file. Limit file reads to 10KB to prevent memory exhaustion.
|
||||
3. **Manual override**: Check if `~/.automaton/config.md` has `Auto-detect: No` under VRAM Configuration. If so, use the manually specified values.
|
||||
4. **Fallback**: Use 8k tokens as default, with 25% headroom.
|
||||
|
||||
### How to Read VRAM Config from config.md
|
||||
|
||||
```markdown
|
||||
## VRAM Configuration
|
||||
- **Auto-detect**: Yes/No
|
||||
- **Target context**: {value}k tokens (override if Auto-detect: No)
|
||||
- **Headroom**: {value}% (override if Auto-detect: No)
|
||||
- **Max peak context per sub-task**: {value}k tokens (override if Auto-detect: No)
|
||||
```
|
||||
|
||||
- If `Auto-detect: Yes`, run the detection script and use its output.
|
||||
- If `Auto-detect: No`, use the manually specified values.
|
||||
- If config.md has no VRAM Configuration section, default to `Auto-detect: Yes`.
|
||||
|
||||
### Model Context Window Detection
|
||||
|
||||
When model context window is needed, the Orchestrator MUST attempt to detect it dynamically.
|
||||
|
||||
#### Detection Priority
|
||||
|
||||
1. **Auto-detect via script**: Check if `{project}/.automaton/scripts/vram_detect.sh` exists. If it does, run it to detect the model name and its context window. Parse the JSON output for `model_context_kb`.
|
||||
2. **Auto-detect via config**: Check `~/.automaton/config.md` for the model name and override context window.
|
||||
3. **Auto-detect via API config**: If the script is not available, try to detect the model name from `.agent.md` or config files (`.env`, `config.yaml`, etc.) and look up its context window. **Important**: Only read the specific lines needed (e.g., the model name line), not the entire file. Limit file reads to 10KB to prevent memory exhaustion.
|
||||
4. **Fallback**: Use 128k tokens as default (common for modern models).
|
||||
|
||||
#### How to Read Model Config from config.md
|
||||
|
||||
```markdown
|
||||
## Model Configuration
|
||||
- **Model**: auto # Use auto-detection, or specify explicitly (e.g., gpt-4o, claude-3-5-sonnet)
|
||||
- **Override context window**: auto # Override auto-detection, or specify (e.g., 128k, 200k)
|
||||
```
|
||||
|
||||
- If `Model: auto`, detect the model name from API config files or .agent.md.
|
||||
- If `Override context window: auto`, use the detected context window.
|
||||
- If both are specified, use the specified values.
|
||||
|
||||
#### Model Name Lookup
|
||||
|
||||
When the model name is detected, look up its context window:
|
||||
- gpt-4o, gpt-4o-mini, gpt-4-turbo, gpt-4: 128k tokens
|
||||
- claude-3-5-sonnet, claude-3-5-haiku, claude-3-opus, claude-3-sonnet, claude-3-haiku, claude-2: 200k tokens
|
||||
|
||||
### Detection Script Output (JSON)
|
||||
|
||||
The detection script outputs JSON like:
|
||||
```json
|
||||
{
|
||||
"gpu_vram_gb": 8,
|
||||
"ram_gb": 16,
|
||||
"model_context_kb": 128000,
|
||||
"framework_overhead_tokens": 4000,
|
||||
"recommended_kb": 16000,
|
||||
"recommended_k": 16,
|
||||
"headroom": 0.25,
|
||||
"max_peak_context_kb": 12000
|
||||
}
|
||||
```
|
||||
|
||||
Use `recommended_kb` for the target context, `headroom` for headroom, and `max_peak_context_kb` for max peak context per sub-task.
|
||||
|
||||
### Auto-Detect When to Run Detection
|
||||
|
||||
The Orchestrator should run VRAM detection in the following scenarios:
|
||||
|
||||
1. **When a new task is created** — to set the VRAM config for the new task.
|
||||
2. **When Decomposition is triggered** — to ensure sub-tasks are sized correctly.
|
||||
3. **When sub-tasks are created** — to propagate VRAM config to sub-task folders.
|
||||
4. **When a sub-task's VRAM_CONFIG.md is missing** — to create one with auto-detected values.
|
||||
|
||||
**VRAM Detection Caching**: When the Orchestrator is invoked multiple times (e.g., the user says "orchestrate" twice), it MUST cache the VRAM detection results and reuse them instead of running the detection script again. This prevents performance degradation from repeated GPU/RAM probing. The cache should be stored in a temporary file (e.g., `{project}/.automaton/.vram_cache.json`) and invalidated when a new task is created or Decomposition is triggered.
|
||||
|
||||
### Reporting Detection Results
|
||||
|
||||
When auto-detecting VRAM, the Orchestrator should report:
|
||||
- GPU VRAM detected (if any)
|
||||
- System RAM detected
|
||||
- Model context window detected (if any)
|
||||
- Framework overhead estimated
|
||||
- Recommended VRAM context window
|
||||
- Whether auto-detection was used or manual override
|
||||
|
||||
Example:
|
||||
```
|
||||
VRAM Detection Results:
|
||||
- GPU VRAM: 8GB (nvidia-smi)
|
||||
- RAM: 16GB
|
||||
- Model context window: 128k (API-based)
|
||||
- Framework overhead: ~4k tokens
|
||||
- **Recommended: 16k tokens** (GPU VRAM-based, 25% headroom)
|
||||
- **Using: 16k tokens** (auto-detected)
|
||||
```
|
||||
|
||||
### Error Handling
|
||||
|
||||
- If the detection script does not exist, skip to the next detection method.
|
||||
- If the detection script fails (e.g., `nvidia-smi` is not installed, the GPU is busy, etc.), check the exit code and fall back to the next detection method.
|
||||
- If API config files are large (>10KB), read only the specific lines needed (e.g., the model name line) and skip the rest.
|
||||
- If API config files contain API keys, warn the user that the VRAM detection script may be reading them.
|
||||
|
||||
## Task
|
||||
|
||||
{task-description}
|
||||
|
||||
## Driver Rules
|
||||
**Note**: If {task-description} is empty or the user just says "orchestrate" or "continue", the Orchestrator should scan for the most advanced task and continue from there. No new task is created.
|
||||
|
||||
Examine the tasks/ directory and determine the state of each task folder. Use the state machine defined in `workflow.md`.
|
||||
## State Machine Definition
|
||||
|
||||
For each task, determine the current phase based on the existence of artifacts:
|
||||
- No `SPEC.md` → Next Phase: **research**
|
||||
- Has `SPEC.md` but no `IMPLEMENTATION.md` → Next Phase: **implement**
|
||||
- Has `IMPLEMENTATION.md` but no `BUG_REPORT.md` → Next Phase: **bug_find**
|
||||
- Has `BUG_REPORT.md` but no `ADVERSARIAL_BUG_REPORT.md` → Next Phase: **adversarial_bug_find**
|
||||
- Has `ADVERSARIAL_BUG_REPORT.md` but no `VERDICT.md` → Next Phase: **referee**
|
||||
- Has `VERDICT.md` with `PASS` → Task is **complete**
|
||||
- Has `VERDICT.md` with `NEEDS_REVIEW` or `FAIL` → Next Phase: **Human Intervention**
|
||||
Each task is a state machine. The Orchestrator determines the current state and transitions to the next state based on the artifacts present.
|
||||
|
||||
### Task States
|
||||
|
||||
| State | Condition | Next State (Autopilot) |
|
||||
|-------|-----------|----------------------|
|
||||
| **New** | No artifacts in task folder | Research |
|
||||
| **Research** | Has `SPEC.md` | Decomposition (optional) or Design (optional) or Implement |
|
||||
| **Decomposition** | Has `SPEC.md` and `DECOMPOSITION.md` | Sub-task Research |
|
||||
| **Design** | Has `DESIGN.md` | Test Design (optional) or Implement |
|
||||
| **Test Design** | Has `TEST_PLAN.md` | Implement |
|
||||
| **Implement** | Has `IMPLEMENTATION.md` | Bug Find |
|
||||
| **Bug Find** | Has `BUG_REPORT.md` | Adversarial Bug Find |
|
||||
| **Adversarial Bug Find** | Has `ADVERSARIAL_BUG_REPORT.md` | Doc Review |
|
||||
| **Doc Review** | Has `DOC_REVIEW.md` | Referee |
|
||||
| **Referee** | Has `VERDICT.md` with `PASS` | **Complete** |
|
||||
| **Referee** | Has `VERDICT.md` with `NEEDS_REVIEW` or `FAIL` | **Human Intervention** |
|
||||
|
||||
## Autopilot Mode (Autopilot: Enabled in .agent.md)
|
||||
|
||||
In Autopilot mode, the Orchestrator MUST **drive the task all the way** to completion or until human intervention is needed. It does this by:
|
||||
|
||||
1. **Scanning**: Determine the current state of each task by checking artifacts
|
||||
2. **Executing**: Run the next phase directly (the agent should execute the phase)
|
||||
3. **Looping**: After each phase completes (check for `CONTRACT_MET` or the phase's stop condition), re-scan and continue to the next phase
|
||||
4. **Stopping**: Stop when the task reaches a terminal state (Complete or Human Intervention)
|
||||
|
||||
### Auto-Execution Loop
|
||||
|
||||
```
|
||||
while task is not in terminal state:
|
||||
if iteration_count >= MAX_ITERATIONS (default: 10):
|
||||
break (human intervention needed — too many iterations)
|
||||
if total_time_elapsed >= MAX_TOTAL_TIME (default: 24 hours):
|
||||
break (human intervention needed — too much time elapsed)
|
||||
if phase_time_elapsed >= MAX_PHASE_TIME (default: 1 hour):
|
||||
break (human intervention needed — phase took too long)
|
||||
determine current state
|
||||
execute the phase that moves the task forward
|
||||
wait for phase to complete (CONTRACT_MET or stop condition)
|
||||
if phase failed (FAIL/NEEDS_REVIEW verdict):
|
||||
break (human intervention needed)
|
||||
if phase artifact is empty or malformed:
|
||||
break (human intervention needed — artifact validation failed)
|
||||
if phase succeeded:
|
||||
iteration_count++
|
||||
continue loop
|
||||
```
|
||||
|
||||
### Task Creation in Autopilot
|
||||
|
||||
#### Continue from existing tasks
|
||||
If the user says "orchestrate" or "continue" with no new task description, the Orchestrator should:
|
||||
1. Scan all tasks in the tasks/ directory, including sub-task folders under `tasks/{parent-task}/subtasks/`
|
||||
2. Find the most advanced task (the one closest to completion) — **prioritize sub-tasks over parent tasks** (because the parent depends on the sub-tasks)
|
||||
3. When choosing among sub-tasks in the same wave, prioritize those in later phases (e.g., Bug Find over Research) because they are closer to completion
|
||||
4. Drive that task through the remaining phases
|
||||
|
||||
#### New tasks from user input
|
||||
If {task-description} contains a description for a NEW task, the Orchestrator MUST:
|
||||
1. Generate a kebab-case task name from the description (e.g., "add user auth" → `add-user-auth`)
|
||||
2. Create the task folder: `{project}/tasks/{task-name}/` (empty — no artifact files)
|
||||
3. **Immediately drive it to completion** using the auto-execution loop
|
||||
|
||||
Note: `IMPLEMENTATION.md` is the artifact produced by the implementation phase, not the Orchestrator. Do not pre-create it. **Do not create an empty `IMPLEMENTATION.md` for new tasks** — this is inconsistent with the Orchestrator's own rule and can confuse the Research phase.
|
||||
|
||||
#### Tasks from bug verdicts (FAIL / NEEDS_REVIEW)
|
||||
If the Orchestrator detects a `VERDICT.md` with `FAIL` or `NEEDS_REVIEW` for an existing task, the behavior depends on the mode:
|
||||
|
||||
**In Manual Mode**: The Orchestrator MUST create new tasks and report them:
|
||||
|
||||
1. **From `FAIL` verdict** (for each failing item under "Findings"):
|
||||
- Task name: `{original-task-name}-fix-{issue}`
|
||||
- Create folder with empty `IMPLEMENTATION.md`
|
||||
- Copy `SPEC.md`, `BUG_REPORT.md`, `ADVERSARIAL_BUG_REPORT.md` from the original task
|
||||
- Report the task for the user to run manually
|
||||
|
||||
2. **From `NEEDS_REVIEW` verdict** (for each item under "Remaining Issues"):
|
||||
- Task name: `{original-task-name}-review-{issue}`
|
||||
- Create folder with empty `IMPLEMENTATION.md`
|
||||
- Copy `SPEC.md`, `BUG_REPORT.md`, `ADVERSARIAL_BUG_REPORT.md` from the original task
|
||||
- Report the task for the user to run manually
|
||||
|
||||
3. **From "Tasks for Review / Tie-Breaks"** (for each item):
|
||||
- Task name: `{original-task-name}-tiebreak-{issue}`
|
||||
- Create folder with empty `IMPLEMENTATION.md`
|
||||
- Copy `SPEC.md`, `BUG_REPORT.md`, `ADVERSARIAL_BUG_REPORT.md` from the original task
|
||||
- Report the task for the user to run manually
|
||||
|
||||
**In Autopilot Mode**: The Orchestrator should NOT auto-create fix/review/tiebreak tasks — it should pause and report that human intervention is required. The user must decide whether to create fix tasks and how to proceed.
|
||||
|
||||
## Manual Mode (Autopilot: Disabled)
|
||||
|
||||
In manual mode, the Orchestrator only **reports** the current state and the next command. It does NOT execute phases. The user must manually run each phase. Manual mode is opt-in — set `Autopilot: Disabled` in .agent.md.
|
||||
|
||||
## State Determination
|
||||
|
||||
Examine the tasks/ directory and determine the state of each task folder. Check from the most advanced state backward. **Important**: Always check that artifacts are non-empty before considering them as indicators of task state.
|
||||
|
||||
1. Has `VERDICT.md` with `PASS` (non-empty) → **Complete**
|
||||
2. Has `VERDICT.md` with `NEEDS_REVIEW` or `FAIL` (non-empty) → **Human Intervention**
|
||||
3. Has `DOC_REVIEW.md` (non-empty) → **Referee**
|
||||
4. Has `ADVERSARIAL_BUG_REPORT.md` (non-empty) and `BUG_REPORT.md` (non-empty) and `SPEC.md` (non-empty) → **Doc Review**
|
||||
5. Has `BUG_REPORT.md` (non-empty) and `SPEC.md` (non-empty) but no `ADVERSARIAL_BUG_REPORT.md` → **Adversarial Bug Find**
|
||||
6. Has `SPEC.md` (non-empty) but no `BUG_REPORT.md` and no `ADVERSARIAL_BUG_REPORT.md` → **Bug Find**
|
||||
7. Has `IMPLEMENTATION.md` (non-empty) → **Bug Find**
|
||||
8. Has `TEST_PLAN.md` (non-empty) → **Implement**
|
||||
9. Has `SPEC.md` (non-empty) and `TEST_PLAN.md` (non-empty) → **Implement**
|
||||
10. Has `DESIGN.md` (non-empty) → **Test Design** (optional) or **Implement** (if user skips test design)
|
||||
11. Has `SPEC.md` (non-empty) and `DESIGN.md` (non-empty) → **Test Design** (optional) or **Implement** (if user skips test design)
|
||||
12. Has `SPEC.md` (non-empty) and `DECOMPOSITION.md` (non-empty) → **Decomposition** (sub-tasks will be created)
|
||||
13. Has `SPEC.md` (non-empty) → **Design** (optional) or **Implement** (if user skips design)
|
||||
14. No artifacts → **New**
|
||||
|
||||
**Note on overlapping conditions**: If a task has both `TEST_PLAN.md` and `DESIGN.md`, the Orchestrator should prioritize the more advanced state (TEST_PLAN.md → Implement) over the optional state (DESIGN.md → Test Design). Similarly, if a task has both `IMPLEMENTATION.md` and `BUG_REPORT.md`, the Orchestrator should prioritize the more advanced state (BUG_REPORT.md → Adversarial Bug Find) over the earlier state (IMPLEMENTATION.md → Bug Find).
|
||||
|
||||
## Output Format
|
||||
|
||||
For each task, output its status and the exact command to move it to the next phase.
|
||||
### Default Mode — Autopilot (Autopilot: Enabled)
|
||||
|
||||
In Autopilot mode, the Orchestrator auto-executes all phases until completion or human intervention:
|
||||
|
||||
**Task: {task-folder-name}**
|
||||
- **Status**: {Current Phase}
|
||||
- **Next Step**: {Next Phase}
|
||||
- **Auto-Execute**: YES
|
||||
- **Command**:
|
||||
> "{Command to trigger the next phase}"
|
||||
|
||||
If a task requires human intervention (e.g., `NEEDS_REVIEW` or a tie-break), explicitly state:
|
||||
If a task has `FAIL` or `NEEDS_REVIEW` verdict or Tie-Breaks, after the task status output, explicitly state:
|
||||
"⚠️ **HUMAN INTERVENTION REQUIRED**: {Reason}"
|
||||
|
||||
When finished, output "ORCHESTRATION_COMPLETE".
|
||||
|
||||
Only recommend one phase at a time. Do not suggest running multiple phases in parallel.
|
||||
### Manual Mode (Autopilot: Disabled)
|
||||
|
||||
In manual mode, the Orchestrator only reports the current state and auto-creates fix/review/tiebreak tasks:
|
||||
|
||||
**Task: {task-folder-name}**
|
||||
- **Status**: {Current Phase}
|
||||
- **Next Step**: {Next Phase}
|
||||
- **Auto-Execute**: NO
|
||||
- **Command**:
|
||||
> "{Command to trigger the next phase}"
|
||||
|
||||
If a task has `FAIL` or `NEEDS_REVIEW` verdict or Tie-Breaks, after the task status output, also list the auto-created tasks:
|
||||
|
||||
**Auto-created tasks from {original-task-name}**:
|
||||
- **{auto-task-name-1}** — Status: {Phase} — Command: > "{Command}"
|
||||
- **{auto-task-name-2}** — Status: {Phase} — Command: > "{Command}"
|
||||
|
||||
If a task requires human intervention, explicitly state:
|
||||
"⚠️ **HUMAN INTERVENTION REQUIRED**: {Reason}"
|
||||
|
||||
When finished, output "ORCHESTRATION_COMPLETE".
|
||||
|
||||
## Auto-Execution Rules (Autopilot Mode Only)
|
||||
|
||||
In Autopilot mode, after outputting the task statuses, the Orchestrator MUST auto-execute the next phase:
|
||||
|
||||
1. Determine the next phase for the most advanced task
|
||||
2. Output the command to run that phase
|
||||
3. **Execute the command** (the agent should run the phase directly)
|
||||
4. Wait for the phase to complete (check for `CONTRACT_MET` or the phase's stop condition)
|
||||
5. If the phase completes successfully, continue to the next phase
|
||||
6. If the phase fails (FAIL verdict, HUMAN INTERVENTION REQUIRED), stop and report
|
||||
7. If the phase artifact is empty or malformed, stop and report human intervention
|
||||
8. If the phase takes too long (exceeds MAX_PHASE_TIME), stop and report human intervention
|
||||
9. If the total iterations exceed MAX_ITERATIONS, stop and report human intervention
|
||||
|
||||
When finished, output "ORCHESTRATION_COMPLETE".
|
||||
|
||||
**Sub-task Parallel Execution**: When sub-tasks are in the same wave and can run in parallel, the Orchestrator should drive them simultaneously instead of sequentially. The Orchestrator should output the commands for all sub-tasks in the wave and wait for all of them to complete before moving to the next wave. This is the only time multiple phases should be suggested in parallel.
|
||||
|
||||
## Sub-Task Management
|
||||
|
||||
When a parent task has a `DECOMPOSITION.md` file, the Orchestrator must create sub-task folders for each sub-task listed.
|
||||
|
||||
### Sub-Task Folder Structure
|
||||
|
||||
When decomposing, the Orchestrator creates sub-tasks under the parent task's `subtasks/` folder:
|
||||
|
||||
```
|
||||
tasks/parent-task/ → Parent task (Research → Decomposition → complete)
|
||||
SPEC.md
|
||||
DECOMPOSITION.md
|
||||
subtasks/
|
||||
subtask-a/ → Sub-task (full lifecycle independently)
|
||||
SPEC.md
|
||||
DESIGN.md
|
||||
IMPLEMENTATION.md
|
||||
BUG_REPORT.md
|
||||
ADVERSARIAL_BUG_REPORT.md
|
||||
DOC_REVIEW.md
|
||||
VERDICT.md
|
||||
subtask-b/
|
||||
SPEC.md
|
||||
...
|
||||
```
|
||||
|
||||
### Sub-Task Creation Rules
|
||||
|
||||
When a parent task reaches the **Decomposition** phase (has `SPEC.md` and `DECOMPOSITION.md`):
|
||||
|
||||
1. **Read `~/.automaton/config.md`** to get the VRAM configuration and check if auto-detect is enabled.
|
||||
2. **If Auto-detect: Yes**, run `{project}/.automaton/scripts/vram_detect.sh` to detect VRAM limits. Parse the JSON output for `recommended_kb`, `headroom`, and `max_peak_context_kb`. Report the detection results.
|
||||
3. **If Auto-detect: No**, use the manually specified values from config.md.
|
||||
4. **Read `DECOMPOSITION.md`** to extract all sub-task names, dependencies, and their estimated token budgets.
|
||||
5. **Verify VRAM constraints**:
|
||||
- For each sub-task, check if its estimated peak context (from DECOMPOSITION.md) is within the max peak context.
|
||||
- If a sub-task exceeds the VRAM limit, create a warning and suggest splitting it further.
|
||||
6. **Check for existing sub-task folders**: For each sub-task, check if the folder `tasks/{parent-task-name}/subtasks/{sub-task-name}/` already exists. If it does, skip the creation and report that the sub-task has already been created. This prevents duplicate sub-tasks when the Orchestrator is invoked multiple times.
|
||||
7. **Check for DECOMPOSITION.md updates**: Compare the DECOMPOSITION.md with the existing sub-task folders. If the DECOMPOSITION.md has been updated (new sub-tasks added or existing sub-tasks removed), update the sub-task folders accordingly:
|
||||
- For new sub-tasks, create the folders.
|
||||
- For removed sub-tasks, report the orphaned sub-tasks and delete the folders.
|
||||
8. **Create sub-task folders** under `tasks/{parent-task-name}/subtasks/{sub-task-name}/`:
|
||||
- For each sub-task, create an empty folder (no files yet — the sub-task starts at the Research phase).
|
||||
- The sub-task name should be a kebab-case version of the sub-task description from DECOMPOSITION.md.
|
||||
9. **Create a VRAM_CONFIG.md** file for each sub-task with the VRAM configuration (see VRAM Config Propagation section).
|
||||
10. **Create a PARENT_SPEC.md** file for each sub-task with:
|
||||
- **The sub-task's own scope/acceptance criteria from the DECOMPOSITION.md** — this is the most important part, as it tells the sub-task's Research phase what the sub-task is responsible for.
|
||||
- A reference to the parent task name.
|
||||
- The VRAM configuration (auto-detected or manual).
|
||||
- **Do NOT include the parent task's full SPEC.md** — this can cause circular references if the parent's SPEC.md references the sub-task's SPEC.md files. Instead, include only the sub-task's own scope from the DECOMPOSITION.md.
|
||||
11. **Do NOT drive sub-tasks through the lifecycle** — sub-tasks are driven through their full lifecycle (Research → Decomposition (optional) → ... → Complete) independently.
|
||||
12. **The parent task is NOT complete** until ALL sub-tasks are in terminal state (Complete or Human Intervention).
|
||||
|
||||
### Sub-Task Lifecycle
|
||||
|
||||
Each sub-task follows the full lifecycle independently:
|
||||
- Starts at the **Research** phase (no artifacts in the sub-task folder)
|
||||
- Goes through Research → Decomposition (optional) → Design (optional) → Test Design (optional) → Implement → Bug Find → Adversarial Bug Find → Doc Review → Referee
|
||||
- Ends at **Complete** (VERDICT.md with PASS) or **Human Intervention** (VERDICT.md with FAIL/NEEDS_REVIEW)
|
||||
|
||||
### VRAM-Aware Sub-Task Splitting
|
||||
|
||||
If a sub-task's estimated peak context exceeds the VRAM limit from .agent.md:
|
||||
1. Split the sub-task into smaller sub-tasks.
|
||||
2. Each new sub-task should fit within the VRAM limit.
|
||||
3. Update the DECOMPOSITION.md to reflect the new sub-tasks.
|
||||
4. Create the new sub-task folders.
|
||||
5. Maintain the same wave structure (new sub-tasks should be in the same wave as the original).
|
||||
|
||||
### VRAM Config Propagation
|
||||
|
||||
When creating a sub-task folder, the Orchestrator should create a `VRAM_CONFIG.md` file with:
|
||||
```markdown
|
||||
# VRAM Configuration for this sub-task
|
||||
|
||||
- **Auto-detect**: Yes/No
|
||||
- **Target VRAM context**: {from detection script or config.md override}k tokens (e.g., "16k")
|
||||
- **Headroom**: {from detection script or config.md override}% (e.g., "25%")
|
||||
- **Max peak context per sub-task**: {from detection script or config.md override}k tokens (e.g., "12k")
|
||||
- **GPU VRAM detected**: {value}GB (or "None")
|
||||
- **RAM detected**: {value}GB
|
||||
- **Model context window**: {value}k tokens (or "Unknown")
|
||||
- **Framework overhead**: ~{value} tokens
|
||||
- **This sub-task's estimated peak context**: {from DECOMPOSITION.md}k tokens (e.g., "10k")
|
||||
- **Fits within VRAM**: Yes/No
|
||||
```
|
||||
|
||||
**Important**: The units must be clarified. `Target VRAM context` uses "k" units (e.g., "16k" for 16k tokens), not raw values like "16". `Max peak context per sub-task` uses the raw value from the detection script (e.g., "12000" for 12000 tokens). `This sub-task's estimated peak context` uses "k" units (e.g., "10k" for 10k tokens). This ensures sub-tasks are aware of the VRAM constraints and can optimize their implementation accordingly.
|
||||
|
||||
### Sub-Task Parent Specification
|
||||
|
||||
When creating a sub-task folder, the Orchestrator should also create a `PARENT_SPEC.md` file that contains:
|
||||
- **The sub-task's own scope/acceptance criteria from the DECOMPOSITION.md** — this is the most important part, as it tells the sub-task's Research phase what the sub-task is responsible for.
|
||||
- A reference to the parent task name
|
||||
- The VRAM configuration (auto-detected or manual)
|
||||
- **Do NOT include the parent task's full SPEC.md** — this can cause circular references if the parent's SPEC.md references the sub-task's SPEC.md files. Instead, include only the sub-task's own scope from the DECOMPOSITION.md.
|
||||
|
||||
This ensures sub-tasks have all the information they need to implement their portion of the parent spec without causing circular references.
|
||||
|
||||
### Sub-Task Dependencies and Wave Management
|
||||
|
||||
Sub-tasks that are in the same wave (can run in parallel) should be driven through the lifecycle in parallel. Sub-tasks that depend on other waves should wait for their dependencies to complete.
|
||||
|
||||
**Wave Enforcement**: The Orchestrator MUST check sub-task dependencies and only start driving Wave 2 sub-tasks when all Wave 1 sub-tasks are in terminal state. If a sub-task in Wave 2 depends on a sub-task in Wave 1, the Orchestrator should not drive the Wave 2 sub-task until the Wave 1 sub-task is in terminal state. This ensures that sub-tasks are driven in the correct order and that the parent task does not complete prematurely.
|
||||
|
||||
### Sub-Task Completion and Parent Task
|
||||
|
||||
When a sub-task reaches a terminal state, the Orchestrator MUST verify that the sub-task has a `VERDICT.md` before evaluating the verdict. If the sub-task does not have a `VERDICT.md`, it is NOT in a terminal state.
|
||||
|
||||
When a sub-task reaches a terminal state:
|
||||
- If the sub-task **PASSes** (VERDICT.md with PASS): The parent task can move to the next wave of sub-tasks.
|
||||
- If a sub-task **FAILs or NEEDS_REVIEW** (VERDICT.md with FAIL/NEEDS_REVIEW):
|
||||
- The Orchestrator pauses and reports human intervention is required.
|
||||
- **In Autopilot Mode**: The Orchestrator does NOT auto-create fix/review tasks — it should pause and report that human intervention is required. The user must decide whether to create fix tasks and how to proceed.
|
||||
- **In Manual Mode**: The Orchestrator MUST create a new task for the failing sub-task:
|
||||
- Task name: `{parent-task-name}-fix-{sub-task-name}` (e.g., `add-user-auth-fix-auth-gateway`)
|
||||
- The Orchestrator creates the folder with an empty `IMPLEMENTATION.md`
|
||||
- The task starts at the **Bug Find** phase
|
||||
- The Orchestrator copies the sub-task's `SPEC.md`, `BUG_REPORT.md`, and `ADVERSARIAL_BUG_REPORT.md` (if they exist) into the new task folder
|
||||
- If the sub-task failed during the Referee phase (before producing BUG_REPORT.md and ADVERSARIAL_BUG_REPORT.md), the Orchestrator still creates the fix task but only copies the artifacts that exist (BUG_REPORT.md if it exists, ADVERSARIAL_BUG_REPORT.md if it exists).
|
||||
|
||||
When ALL sub-tasks are in terminal state (each sub-task has a VERDICT.md):
|
||||
- **Check for orphaned sub-tasks**: Before checking completion, verify that each sub-task is still referenced in the DECOMPOSITION.md. If a sub-task is orphaned (no longer in the DECOMPOSITION.md), remove it from the parent's completion check.
|
||||
- If ALL sub-tasks **PASS**: The parent task is **Complete**.
|
||||
- If ANY sub-task **FAILs or NEEDS_REVIEW**: The Orchestrator creates fix/review tasks for the failing sub-tasks (as described above) and reports human intervention is required.
|
||||
|
||||
### Sub-Task Verdict Reporting
|
||||
|
||||
When a sub-task reaches the Referee phase, the VERDICT.md should include:
|
||||
- The sub-task's own verdict (PASS/FAIL/NEEDS_REVIEW)
|
||||
- A reference to the parent task name
|
||||
- Any findings that affect the parent task
|
||||
|
||||
### Sub-Task Verdict Aggregation
|
||||
|
||||
The Orchestrator MUST aggregate sub-task verdicts when reporting the parent task's status:
|
||||
- If ANY sub-task **FAILs or NEEDS_REVIEW**, the parent task should be marked as **Human Intervention** regardless of whether the parent's own VERDICT.md says PASS.
|
||||
- The parent task's status should include a summary of all sub-task verdicts:
|
||||
- PASS: {count}
|
||||
- FAIL: {count}
|
||||
- NEEDS_REVIEW: {count}
|
||||
- If the parent task has a VERDICT.md with PASS, but a sub-task has a VERDICT.md with FAIL, the Orchestrator should report: "⚠️ **HUMAN INTERVENTION REQUIRED**: Parent task VERDICT.md says PASS, but sub-task {sub-task-name} has VERDICT.md with FAIL. Create a fix task for the failing sub-task."
|
||||
|
||||
### Sub-Task Tie-Breaks
|
||||
|
||||
If a sub-task has "Tasks for Review / Tie-Breaks" in its VERDICT.md, the Orchestrator should create tie-break tasks for the sub-task:
|
||||
- Task name: `{parent-task-name}-tiebreak-{sub-task-name}` (e.g., `add-user-auth-tiebreak-auth-gateway`)
|
||||
- The Orchestrator creates the folder with an empty `IMPLEMENTATION.md`
|
||||
- The task starts at the **Research** phase
|
||||
- The Orchestrator copies the sub-task's `SPEC.md`, `BUG_REPORT.md`, and `ADVERSARIAL_BUG_REPORT.md` (if they exist) into the new task folder
|
||||
|
||||
+19
-8
@@ -6,8 +6,12 @@ You are the Referee. Your job is to objectively evaluate whether the implementat
|
||||
2. {project}/tasks/{task-name}/{task-name}_CONTRACT.md (if exists)
|
||||
3. {project}/tasks/{task-name}/BUG_REPORT.md (if exists)
|
||||
4. {project}/tasks/{task-name}/ADVERSARIAL_BUG_REPORT.md (if exists)
|
||||
5. {project}/tasks/{task-name}/IMPLEMENTATION.md (if exists)
|
||||
6. {project}/tasks/{task-name}/DESIGN.md (if exists)
|
||||
5. {project}/tasks/{task-name}/DOC_REVIEW.md (if exists)
|
||||
6. {project}/tasks/{task-name}/IMPLEMENTATION.md (if exists)
|
||||
7. {project}/tasks/{task-name}/DESIGN.md (if exists)
|
||||
8. {project}/tasks/{task-name}/TEST_PLAN.md (if exists)
|
||||
9. {project}/tasks/{task-name}/VRAM_CONFIG.md (if exists)
|
||||
10. {project}/tasks/{task-name}/PARENT_SPEC.md (if exists)
|
||||
|
||||
## Task
|
||||
|
||||
@@ -36,17 +40,19 @@ You are the Referee. Your job is to objectively evaluate whether the implementat
|
||||
- Are functions small and focused?
|
||||
- Is there proper error handling?
|
||||
- Are there any obvious performance issues?
|
||||
- If VRAM_CONFIG.md exists: Is the code optimized for low-VRAM (small functions, streaming patterns, no large file loading)?
|
||||
|
||||
### Testing
|
||||
- Do all tests pass?
|
||||
- Are edge cases covered?
|
||||
- Are there false positives (tests that pass but don't verify)?
|
||||
- If TEST_PLAN.md exists: Are all test cases from the TEST_PLAN.md implemented? Are any test cases missing or incomplete?
|
||||
|
||||
### Documentation Review (Grill with Docs)
|
||||
- Did the agent update all documentation identified in the DESIGN.md?
|
||||
- Is the documentation accurate and reflects the final implementation?
|
||||
- Is the documentation clear enough for a developer to understand the new changes?
|
||||
- Does the documentation cover any edge cases or non-obvious logic?
|
||||
### Documentation Review
|
||||
- Read the `DOC_REVIEW.md` produced by the Documentation Review phase
|
||||
- Verify the Doc Review findings are accurate — are the docs actually complete and accurate?
|
||||
- If the Doc Review missed any gaps, call them out here
|
||||
- If the Doc Review flagged issues that were resolved, mark them as resolved
|
||||
|
||||
## Verdict
|
||||
|
||||
@@ -55,7 +61,8 @@ Produce a VERDICT.md at {project}/tasks/{task-name}/VERDICT.md with:
|
||||
```markdown
|
||||
# Verdict: {task-name}
|
||||
|
||||
## Verdict: PASS / FAIL / NEEDS_REVIEW
|
||||
## Status: [PASS / FAIL / NEEDS_REVIEW]
|
||||
**Completion Date**: {{CURRENT_DATE}}
|
||||
|
||||
## Summary
|
||||
{Brief overview of findings}
|
||||
@@ -73,6 +80,9 @@ Produce a VERDICT.md at {project}/tasks/{task-name}/VERDICT.md with:
|
||||
|
||||
## Score
|
||||
{Assign a score: +10 for PASS, +5 for NEEDS_REVIEW, -10 for FAIL}
|
||||
|
||||
## Reviewer Comments
|
||||
(Leave blank for the human reviewer to provide feedback)
|
||||
```
|
||||
|
||||
## Important
|
||||
@@ -81,6 +91,7 @@ Produce a VERDICT.md at {project}/tasks/{task-name}/VERDICT.md with:
|
||||
- If you are unsure, mark it as NEEDS_REVIEW and explain why.
|
||||
- Your verdict is final — no appeals.
|
||||
- Explicitly reference both the Bug Finder and Adversarial Bug Finder outputs in your analysis.
|
||||
- Always include the current date in the Completion Date field.
|
||||
|
||||
## Stop Condition (MANDATORY)
|
||||
You are not allowed to end this session until you have produced the VERDICT.md file AND output the exact phrase "CONTRACT_MET".
|
||||
|
||||
+69
-2
@@ -4,13 +4,80 @@ Your only job is to produce a clean, unambiguous specification. Do not write cod
|
||||
|
||||
## Read These Files
|
||||
|
||||
1. {project}/.agent-framework/RULES.md — project-specific rules
|
||||
2. {project}/.agent-framework/AGENT.md — project agent config (if exists)
|
||||
The Orchestrator reads files using a **layered approach** with a clear precedence:
|
||||
|
||||
1. **Project overrides** (highest precedence): `{project}/.automaton/` — contains project-specific customizations
|
||||
2. **Global framework** (default): `~/.automaton/` — contains the base framework files
|
||||
|
||||
**Precedence rule**: If a file exists in the project's `.automaton/` directory, read it from there. If it doesn't exist, read it from the global `~/.automaton/` directory.
|
||||
|
||||
1. {project}/.automaton/.rules.md (if exists — project override) OR ~/.automaton/.rules.md (global default) — project-specific rules
|
||||
2. {project}/.automaton/.agent.md (if exists — project override) OR ~/.automaton/.agent.md (global default) — project agent config
|
||||
|
||||
## Task
|
||||
|
||||
{task-description}
|
||||
|
||||
## Research Protocol (Interactive)
|
||||
|
||||
You are NOT allowed to produce a SPEC.md without first having a thorough discussion with the user. You must actively grill the user for requirements, edge cases, and constraints.
|
||||
|
||||
### Phase 1: Discovery Questions
|
||||
|
||||
Before writing anything, ask the user questions to understand the full scope. Group your questions by category:
|
||||
|
||||
**Core Requirements:**
|
||||
- What is the primary goal of this feature?
|
||||
- What problem does it solve?
|
||||
- Who are the users?
|
||||
- What are the non-negotiable requirements?
|
||||
|
||||
**Edge Cases:**
|
||||
- What happens if the input is empty/null?
|
||||
- What happens if the input is malformed?
|
||||
- What happens if the input is extremely large?
|
||||
- What happens if the system is under heavy load?
|
||||
- What happens if the user cancels mid-operation?
|
||||
|
||||
**Constraints:**
|
||||
- Are there performance requirements? (latency, throughput, memory)
|
||||
- Are there security requirements? (authentication, authorization, data protection)
|
||||
- Are there compliance requirements? (GDPR, HIPAA, etc.)
|
||||
- Are there integration requirements? (APIs, databases, external services)
|
||||
|
||||
**Scope:**
|
||||
- What is explicitly NOT part of this feature?
|
||||
- What can be deferred to a future iteration?
|
||||
|
||||
### Phase 2: Present Draft SPEC
|
||||
|
||||
After asking questions, present a draft SPEC.md for review. The draft should contain:
|
||||
- Clear goal
|
||||
- Exact requirements (numbered)
|
||||
- Acceptance criteria
|
||||
- Constraints and non-goals
|
||||
- Recommended implementation approach (high-level only)
|
||||
|
||||
### Phase 3: Review and Refine
|
||||
|
||||
Present the draft SPEC to the user and ask:
|
||||
- "Does this cover everything? What am I missing?"
|
||||
- "Are there any requirements that are wrong or incomplete?"
|
||||
- "Are there any edge cases I should have considered?"
|
||||
- "Are there any constraints I should have included?"
|
||||
|
||||
Incorporate the user's feedback and revise the SPEC accordingly. Repeat this loop until the user signs off.
|
||||
|
||||
### Phase 4: Get Sign-Off
|
||||
|
||||
Before writing the SPEC.md, you MUST get explicit sign-off from the user. Say:
|
||||
|
||||
> "Based on our discussion, here is the final spec:
|
||||
> [brief summary]
|
||||
> Does this cover everything? Please confirm with 'APPROVED' before I finalize."
|
||||
|
||||
Only produce the SPEC.md after the user says "APPROVED" or equivalent.
|
||||
|
||||
## Output
|
||||
|
||||
Produce a file called SPEC.md at {project}/tasks/{task-name}/SPEC.md that contains:
|
||||
|
||||
@@ -0,0 +1,141 @@
|
||||
You are in Test Design mode.
|
||||
|
||||
Your only job is to produce a comprehensive, explicit test specification for the feature. No code. No implementation. Just test cases.
|
||||
|
||||
## Read These Files
|
||||
|
||||
1. {project}/tasks/{task-name}/SPEC.md — Requirements and acceptance criteria
|
||||
2. {project}/tasks/{task-name}/DESIGN.md — Architecture and data model (if exists)
|
||||
3. {project}/.automaton/.rules.md (if exists — project override) OR ~/.automaton/.rules.md (global default) — Project constraints
|
||||
|
||||
## Task
|
||||
|
||||
{task-description}
|
||||
|
||||
## Test Design Protocol
|
||||
|
||||
### Phase 1: Discovery Questions
|
||||
|
||||
Before writing anything, ask the user questions to understand the testing scope:
|
||||
|
||||
**Coverage:**
|
||||
- What edge cases must be tested? (null inputs, empty lists, large inputs, etc.)
|
||||
- What error conditions need test coverage?
|
||||
- Are there any security-sensitive operations that need specific test cases?
|
||||
- Are there performance requirements that need benchmark tests?
|
||||
|
||||
**Test Levels:**
|
||||
- Should we test at the unit level, integration level, or both?
|
||||
- Are there any end-to-end scenarios that need test coverage?
|
||||
- Are there any third-party integrations that need mock tests?
|
||||
|
||||
**Non-Functional:**
|
||||
- Are there any performance benchmarks needed?
|
||||
- Are there any load or concurrency tests required?
|
||||
|
||||
### Phase 2: Present Draft TEST_PLAN.md
|
||||
|
||||
After asking questions, present a draft TEST_PLAN.md for review. The draft should contain:
|
||||
|
||||
### 1. Unit Tests
|
||||
- Test cases for each requirement in the SPEC.md
|
||||
- Edge case tests (null, empty, boundary, etc.)
|
||||
- Error path tests
|
||||
|
||||
### 2. Integration Tests
|
||||
- Tests for interactions between modules
|
||||
- Tests for API contracts
|
||||
- Tests for data flow between components
|
||||
|
||||
### 3. End-to-End Tests
|
||||
- Complete user flow tests
|
||||
- Critical path scenarios
|
||||
|
||||
### 4. Non-Functional Tests (if applicable)
|
||||
- Performance benchmarks
|
||||
- Concurrency tests
|
||||
- Security tests
|
||||
|
||||
### Phase 3: Review and Refine
|
||||
|
||||
Present the draft TEST_PLAN.md to the user and ask:
|
||||
- "Does this cover all the requirements? What am I missing?"
|
||||
- "Are there any edge cases or error conditions I should have included?"
|
||||
- "Are there any performance or security requirements that need tests?"
|
||||
|
||||
Incorporate the user's feedback and revise the TEST_PLAN.md accordingly. Repeat this loop until the user signs off.
|
||||
|
||||
### Phase 4: Get Sign-Off
|
||||
|
||||
Before writing the TEST_PLAN.md, you MUST get explicit sign-off from the user. Say:
|
||||
|
||||
> "Based on our discussion, here is the final test plan:
|
||||
> [brief summary]
|
||||
> Does this cover everything? Please confirm with 'APPROVED' before I finalize."
|
||||
|
||||
Only produce the TEST_PLAN.md after the user says "APPROVED" or equivalent.
|
||||
|
||||
## Output
|
||||
|
||||
Produce a file called TEST_PLAN.md at {project}/tasks/{task-name}/TEST_PLAN.md that contains:
|
||||
|
||||
```markdown
|
||||
# Test Plan: {task-name}
|
||||
|
||||
## Summary
|
||||
{Brief overview of test strategy}
|
||||
|
||||
## Unit Tests
|
||||
### Test 1: {Test name}
|
||||
- **Requirement**: {Which SPEC.md requirement this tests}
|
||||
- **Scenario**: {What the test verifies}
|
||||
- **Input**: {Test input data}
|
||||
- **Expected Output**: {Expected result}
|
||||
- **Edge Case**: {Any edge case this covers}
|
||||
|
||||
### Test 2: {Test name}
|
||||
- **Requirement**: {Which SPEC.md requirement this tests}
|
||||
- **Scenario**: {What the test verifies}
|
||||
- **Input**: {Test input data}
|
||||
- **Expected Output**: {Expected result}
|
||||
- **Edge Case**: {Any edge case this covers}
|
||||
|
||||
## Integration Tests
|
||||
### Test 1: {Test name}
|
||||
- **Scope**: {What modules/components this tests}
|
||||
- **Scenario**: {What the test verifies}
|
||||
- **Input**: {Test input data}
|
||||
- **Expected Output**: {Expected result}
|
||||
|
||||
## End-to-End Tests
|
||||
### Test 1: {Test name}
|
||||
- **Scenario**: {What the test verifies}
|
||||
- **Steps**: {Step-by-step scenario}
|
||||
- **Expected Output**: {Expected result}
|
||||
|
||||
## Non-Functional Tests
|
||||
### Test 1: {Test name}
|
||||
- **Type**: {Performance / Concurrency / Security}
|
||||
- **Scenario**: {What the test verifies}
|
||||
- **Threshold**: {Performance metric / Security requirement}
|
||||
|
||||
## Test Coverage Summary
|
||||
- Total tests: {Count}
|
||||
- Unit tests: {Count}
|
||||
- Integration tests: {Count}
|
||||
- End-to-end tests: {Count}
|
||||
- Non-functional tests: {Count}
|
||||
```
|
||||
|
||||
## Important
|
||||
- Be thorough. Every requirement in SPEC.md must have at least one test.
|
||||
- Every edge case mentioned in the spec must have a test.
|
||||
- Error conditions must have test cases.
|
||||
- Do NOT write any code — only define test cases.
|
||||
- Do NOT write test implementation — only describe what the tests should verify.
|
||||
|
||||
When the test plan is complete, output "CONTRACT_MET" and stop.
|
||||
|
||||
## Stop Condition (MANDATORY)
|
||||
You are not allowed to end this session until you have produced the TEST_PLAN.md file AND output the exact phrase "CONTRACT_MET".
|
||||
Until then, continue working or ask clarifying questions.
|
||||
+66
-9
@@ -1,21 +1,78 @@
|
||||
# Workflow State Machine
|
||||
|
||||
This file defines the linear progression of a task in the agent-framework. The Orchestrator uses this to determine the next phase.
|
||||
This file defines the linear progression of a task in automaton. The Orchestrator uses this to determine the next phase.
|
||||
|
||||
## Task Lifecycle
|
||||
|
||||
| Current State | Signal (Artifact) | Next Phase | Action |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **New Task** | No `SPEC.md` | Research | Generate `SPEC.md` |
|
||||
| **Research** | Has `SPEC.md` | Implement | Generate code and tests |
|
||||
| **Implementation** | Has `IMPLEMENTATION.md` | Bug Find | Generate `BUG_REPORT.md` |
|
||||
| **Bug Find** | Has `BUG_REPORT.md` | Adversarial Bug Find | Generate `ADVERSARIAL_BUG_REPORT.md` |
|
||||
| **Adversarial Bug Find** | Has `ADVERSARIAL_BUG_REPORT.md` | Referee | Generate `VERDICT.md` |
|
||||
| **Referee** | Has `VERDICT.md` | Complete / Review | Finalize or request user intervention |
|
||||
| **New Task** | Orchestrator creates `tasks/{task-name}/` with **no files** | Research | Generate `SPEC.md` |
|
||||
| **Research** | Has `SPEC.md` (non-empty) | Decomposition (optional) or Design (optional) or Implement | Generate `DECOMPOSITION.md` or `DESIGN.md` or code |
|
||||
| **Decomposition** | Has `SPEC.md` and `DECOMPOSITION.md` (both non-empty) | Sub-task Research | Orchestrator creates sub-task folders |
|
||||
| **Design** | Has `DESIGN.md` (non-empty) | Test Design (optional) or Implement | Generate `TEST_PLAN.md` or code |
|
||||
| **Test Design** | Has `TEST_PLAN.md` (non-empty) | Implement | Generate code and tests |
|
||||
| **Implementation** | Has `IMPLEMENTATION.md` (non-empty) | Bug Find | Generate `BUG_REPORT.md` |
|
||||
| **Bug Find** | Has `BUG_REPORT.md` (non-empty) | Adversarial Bug Find | Generate `ADVERSARIAL_BUG_REPORT.md` |
|
||||
| **Adversarial Bug Find** | Has `ADVERSARIAL_BUG_REPORT.md` (non-empty) | Doc Review | Generate `DOC_REVIEW.md` |
|
||||
| **Doc Review** | Has `DOC_REVIEW.md` (non-empty) | Referee | Generate `VERDICT.md` |
|
||||
| **Referee** | Has `VERDICT.md` (non-empty) | Complete / Review | Finalize or request user intervention |
|
||||
|
||||
## Task Creation (Orchestrator Responsibility)
|
||||
|
||||
The Orchestrator is responsible for creating new task folders automatically — users **never** create task folders manually.
|
||||
|
||||
### New tasks from user input
|
||||
When the Orchestrator detects a new task description:
|
||||
1. Generate a kebab-case task name from the description
|
||||
2. Create `{project}/tasks/{task-name}/` (empty — no artifact files)
|
||||
3. Move the task to the **Research** phase
|
||||
|
||||
The Orchestrator also scans for tasks that have `VERDICT.md` with `PASS` and removes them from the active task list (they can be archived but not auto-deleted).
|
||||
|
||||
**Key principle**: `IMPLEMENTATION.md` is the artifact produced by the **implementation phase**, not the Orchestrator. The Orchestrator only creates the empty folder; the first real artifact is `SPEC.md` from research.
|
||||
|
||||
### Task creation from bugs
|
||||
When the Orchestrator detects a `VERDICT.md` with `FAIL` or `NEEDS_REVIEW`, the behavior depends on the mode:
|
||||
|
||||
**In Manual Mode**: The Orchestrator MUST create new tasks and report them for the user to run:
|
||||
|
||||
1. **From `FAIL` verdict**: For each item listed under "Findings" that failed, create a new task:
|
||||
- Task name: `{original-task-name}-fix-{issue}` (e.g., `add-user-auth-fix-null-handling`)
|
||||
- The Orchestrator creates the folder with an empty `IMPLEMENTATION.md`
|
||||
- The task starts at the **Bug Find** phase (skip research — the spec already exists)
|
||||
- The Orchestrator copies the original `SPEC.md`, `BUG_REPORT.md`, and `ADVERSARIAL_BUG_REPORT.md` into the new task folder
|
||||
|
||||
2. **From `NEEDS_REVIEW` verdict**: For each item listed under "Remaining Issues", create a new task:
|
||||
- Task name: `{original-task-name}-review-{issue}` (e.g., `add-user-auth-review-perf`)
|
||||
- The Orchestrator creates the folder with an empty `IMPLEMENTATION.md`
|
||||
- The task starts at the **Bug Find** phase
|
||||
- The Orchestrator copies the original `SPEC.md`, `BUG_REPORT.md`, and `ADVERSARIAL_BUG_REPORT.md` into the new task folder
|
||||
|
||||
3. **From "Tasks for Review / Tie-Breaks"**: For each item listed, create a new task:
|
||||
- Task name: `{original-task-name}-tiebreak-{issue}` (e.g., `add-user-auth-tiebreak-auth-gateway`)
|
||||
- The Orchestrator creates the folder with an empty `IMPLEMENTATION.md`
|
||||
- The task starts at the **Research** phase (the tie-break may require spec changes)
|
||||
- The Orchestrator copies the original `SPEC.md`, `BUG_REPORT.md`, and `ADVERSARIAL_BUG_REPORT.md` into the new task folder
|
||||
|
||||
4. **From sub-task `FAIL` verdict**: For each sub-task that FAILs or NEEDS_REVIEW, create a new task:
|
||||
- Task name: `{parent-task-name}-fix-{sub-task-name}` (e.g., `add-user-auth-fix-auth-gateway`)
|
||||
- The Orchestrator creates the folder with an empty `IMPLEMENTATION.md`
|
||||
- The task starts at the **Bug Find** phase
|
||||
- The Orchestrator copies the sub-task's `SPEC.md`, `BUG_REPORT.md`, and `ADVERSARIAL_BUG_REPORT.md` (if they exist) into the new task folder
|
||||
|
||||
5. **From sub-task "Tasks for Review / Tie-Breaks"**: For each sub-task that has tie-breaks, create a new task:
|
||||
- Task name: `{parent-task-name}-tiebreak-{sub-task-name}` (e.g., `add-user-auth-tiebreak-auth-gateway`)
|
||||
- The Orchestrator creates the folder with an empty `IMPLEMENTATION.md`
|
||||
- The task starts at the **Research** phase
|
||||
- The Orchestrator copies the sub-task's `SPEC.md`, `BUG_REPORT.md`, and `ADVERSARIAL_BUG_REPORT.md` (if they exist) into the new task folder
|
||||
|
||||
**In Autopilot Mode**: The Orchestrator should NOT auto-create fix/review/tiebreak tasks — it should pause and report that human intervention is required. The user must decide whether to create fix tasks and how to proceed.
|
||||
|
||||
**Note**: When a task starts at the **Bug Find** phase (fix tasks), the Orchestrator skips the Research phase. The implementation agent should first review the existing bugs and spec before fixing them. The Orchestrator signals this by checking for `BUG_REPORT.md` and `ADVERSARIAL_BUG_REPORT.md` in the new task folder.
|
||||
|
||||
## Autopilot Rules
|
||||
|
||||
1. **Linear Progression**: Never skip a phase.
|
||||
1. **Linear Progression**: Never skip a phase (except Design and Test Design, which are optional).
|
||||
2. **Artifact Check**: A phase is only considered "complete" if its corresponding artifact exists and is non-empty.
|
||||
3. **Automatic Transition**: Upon completion of an artifact, the Orchestrator must immediately identify and propose the next phase in the lifecycle.
|
||||
4. **Human Intervention**: If the Referee marks a task as `NEEDS_REVIEW` or identifies "Tie-Breaks", the Autopilot pauses and waits for user input.
|
||||
4. **Human Intervention**: If the Referee marks a task as `FAIL`, `NEEDS_REVIEW`, or identifies "Tie-Breaks", the Autopilot pauses and waits for user input — the Orchestrator does NOT auto-create fix/review/tiebreak tasks in Autopilot mode; the user must decide whether to create fix tasks and how to proceed. (In manual mode, the Orchestrator auto-creates these tasks.)
|
||||
|
||||
@@ -6,11 +6,11 @@ Copy and paste this at the very beginning of every new agent session (before giv
|
||||
|
||||
Read the following files in order, then wait for my instructions:
|
||||
|
||||
1. ~/.agent-framework/AGENT.md (global framework router)
|
||||
2. {project}/.agent-framework/AGENT.md (project-level router, if it exists)
|
||||
3. {project}/.agent-framework/RULES.md (if it exists)
|
||||
1. ~/.automaton/.agent.md (global framework router)
|
||||
2. {project}/.automaton/.agent.md (project-level router, if it exists)
|
||||
3. {project}/.automaton/.rules.md (if it exists)
|
||||
|
||||
After reading these files, acknowledge with: "AGENT.md and RULES.md loaded. Ready."
|
||||
After reading these files, acknowledge with: ".agent.md and .rules.md loaded. Ready."
|
||||
|
||||
---
|
||||
|
||||
@@ -23,4 +23,4 @@ After reading these files, acknowledge with: "AGENT.md and RULES.md loaded. Read
|
||||
- "Implement the fix-alert-test task"
|
||||
- "Onboard this project to the agent framework"
|
||||
|
||||
This guarantees the agent always follows the routing rules in `AGENT.md`.
|
||||
This guarantees the agent always follows the routing rules in `.agent.md`.
|
||||
@@ -54,6 +54,6 @@ Only then output "CONTRACT_MET".
|
||||
- prompts/implement.md
|
||||
- prompts/research.md
|
||||
- prompts/bug_finder.md (optional)
|
||||
- Update ONBOARDING.md to document this pattern under "Define Clear End States"
|
||||
- Update .onboarding.md to document this pattern under "Define Clear End States"
|
||||
|
||||
This turns the voluntary "CONTRACT_MET" into a hard mechanical requirement.
|
||||
Executable
+62
@@ -0,0 +1,62 @@
|
||||
#!/bin/bash
|
||||
set -e
|
||||
|
||||
FRAMEWORK_DIR="$HOME/.automaton"
|
||||
|
||||
if [ -d "$FRAMEWORK_DIR" ]; then
|
||||
echo "automaton already installed at $FRAMEWORK_DIR"
|
||||
echo "Run './update.sh' to update."
|
||||
exit 0
|
||||
fi
|
||||
|
||||
echo "Cloning automaton to $FRAMEWORK_DIR..."
|
||||
git clone https://gitea.yourdomain.com/you/automaton.git "$FRAMEWORK_DIR"
|
||||
|
||||
echo ""
|
||||
echo "=== VRAM / Context Detection ==="
|
||||
echo "Detecting your system's VRAM to recommend task decomposition settings..."
|
||||
echo ""
|
||||
|
||||
# Run VRAM detection script if it exists
|
||||
if [ -f "$FRAMEWORK_DIR/scripts/vram_detect.sh" ]; then
|
||||
# Run in project-dir context so it can read framework overhead
|
||||
detection_output=$(cd "$FRAMEWORK_DIR" && bash "$FRAMEWORK_DIR/scripts/vram_detect.sh" 2>&1)
|
||||
|
||||
# Extract JSON output (last section after "=== JSON Output ===")
|
||||
json_output=$(echo "$detection_output" | sed -n '/=== JSON Output ===/,/EOF/p' | grep -v '=== JSON Output ===' | grep -v '^EOF$')
|
||||
|
||||
if [ -n "$json_output" ]; then
|
||||
echo "$detection_output"
|
||||
|
||||
# Extract key values from JSON for display
|
||||
recommended_k=$(echo "$json_output" | grep '"recommended_k"' | grep -oP '\d+')
|
||||
max_peak_kb=$(echo "$json_output" | grep '"max_peak_context_kb"' | grep -oP '\d+')
|
||||
headroom=$(echo "$json_output" | grep '"headroom"' | grep -oP '\d+\.\d+')
|
||||
gpu_vram=$(echo "$json_output" | grep '"gpu_vram_gb"' | grep -oP '\d+')
|
||||
ram_gb=$(echo "$json_output" | grep '"ram_gb"' | grep -oP '\d+')
|
||||
model_context=$(echo "$json_output" | grep '"model_context_kb"' | grep -oP '\d+')
|
||||
|
||||
echo ""
|
||||
echo "=== Recommended VRAM Configuration ==="
|
||||
echo "For low-VRAM systems (8GB, 16GB VRAM), add this to ~/.automaton/config.md:"
|
||||
echo ""
|
||||
echo "## VRAM Configuration"
|
||||
echo "- **Auto-detect**: Yes # Let the agent detect automatically"
|
||||
echo "- **Target context**: ${recommended_k}k tokens # Override auto-detect if needed"
|
||||
echo "- **Headroom**: ${headroom}%"
|
||||
echo "- **Max peak context per sub-task**: $((max_peak_kb / 1000))k tokens"
|
||||
echo ""
|
||||
echo "This ensures tasks are decomposed into sub-tasks that fit within your"
|
||||
echo "available VRAM. For more information, see the README."
|
||||
else
|
||||
echo "Could not detect VRAM. You can manually set your VRAM configuration in ~/.automaton/config.md."
|
||||
echo "See the README for details."
|
||||
fi
|
||||
else
|
||||
echo "VRAM detection script not found. You can manually set your VRAM configuration in ~/.automaton/config.md."
|
||||
echo "See the README for details."
|
||||
fi
|
||||
|
||||
echo ""
|
||||
echo "Installation complete."
|
||||
echo "Next step: cd into a project and run the onboarding prompt."
|
||||
Executable
+44
@@ -0,0 +1,44 @@
|
||||
#!/bin/bash
|
||||
set -e
|
||||
|
||||
FRAMEWORK_DIR="$HOME/.automaton"
|
||||
|
||||
if [ ! -d "$FRAMEWORK_DIR" ]; then
|
||||
echo "ERROR: automaton not installed at $FRAMEWORK_DIR"
|
||||
echo "Run './install.sh' first."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
echo "Updating automaton at $FRAMEWORK_DIR..."
|
||||
cd "$FRAMEWORK_DIR"
|
||||
|
||||
# Check if it's a git repo
|
||||
if [ ! -d ".git" ]; then
|
||||
echo "ERROR: $FRAMEWORK_DIR is not a git repository."
|
||||
echo "Cannot update. Please reinstall from git."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Fetch latest changes
|
||||
git fetch origin
|
||||
echo ""
|
||||
|
||||
# Check for local changes
|
||||
if ! git diff --quiet HEAD; then
|
||||
echo "WARNING: You have uncommitted changes in $FRAMEWORK_DIR."
|
||||
echo "These will be lost when pulling updates."
|
||||
read -p "Do you want to discard your local changes and update? (y/N) " -n 1 -r
|
||||
echo
|
||||
if [[ ! $REPLY =~ ^[Yy]$ ]]; then
|
||||
echo "Update cancelled."
|
||||
exit 1
|
||||
fi
|
||||
git reset --hard HEAD
|
||||
fi
|
||||
|
||||
# Pull latest changes
|
||||
git pull origin main
|
||||
echo ""
|
||||
|
||||
echo "Update complete."
|
||||
echo "You can check for breaking changes at: https://gitea.yourdomain.com/hermes/automaton"
|
||||
Executable
+549
@@ -0,0 +1,549 @@
|
||||
#!/usr/bin/env bash
|
||||
# VRAM/Context Detection Script
|
||||
# Detects GPU VRAM, system RAM, and model context window to recommend
|
||||
# a safe VRAM context window for task decomposition.
|
||||
#
|
||||
# Usage: ./vram_detect.sh [model_name]
|
||||
# - If model_name is provided, looks up its context window
|
||||
# - Otherwise, tries to detect from API config or config.md
|
||||
|
||||
set -uo pipefail # Don't exit on error - we want to continue even if detection fails
|
||||
|
||||
# ─── GPU VRAM Detection ───
|
||||
detect_gpu_vram() {
|
||||
local total_vram_kb=0
|
||||
local vram_per_gpu_kb=0
|
||||
local num_gpus=0
|
||||
|
||||
# Try nvidia-smi first (NVIDIA GPUs)
|
||||
if command -v nvidia-smi &>/dev/null; then
|
||||
local vram_kb
|
||||
# Use timeout to avoid hanging on nvidia-smi (e.g., driver not loaded)
|
||||
vram_kb=$(timeout 5 nvidia-smi --query-gpu=memory.total --format=csv,noheader,nounits 2>/dev/null | head -1 | tr -d ' ' || true)
|
||||
# Validate that vram_kb is a positive number
|
||||
if [[ -n "$vram_kb" && "$vram_kb" =~ ^[0-9]+$ && "$vram_kb" -gt 0 ]]; then
|
||||
total_vram_kb=$((vram_kb * 1024)) # MB → KB
|
||||
vram_per_gpu_kb=$((total_vram_kb / (num_gpus+1)))
|
||||
num_gpus=1
|
||||
echo "GPU: NVIDIA (nvidia-smi available)"
|
||||
echo "VRAM per GPU: $((vram_kb / 1024))GB ($vram_kb MB)"
|
||||
else
|
||||
echo "GPU: NVIDIA (nvidia-smi available but driver not responding)"
|
||||
fi
|
||||
fi
|
||||
|
||||
# Fallback: lspci
|
||||
if [[ $total_vram_kb -eq 0 && $num_gpus -eq 0 ]]; then
|
||||
local gpu_info
|
||||
gpu_info=$(lspci 2>/dev/null | grep -i -E 'VGA|3D|Display' | head -5)
|
||||
if [[ -n "$gpu_info" ]]; then
|
||||
echo "GPU detected: $gpu_info"
|
||||
# Try to get VRAM from lspci -vnn memory regions
|
||||
# GPUs show VRAM as Memory regions in lspci
|
||||
# Parse patterns like: Memory at f800000000 (64-bit, prefetchable) [size=256M]
|
||||
local total_vram_mb=0
|
||||
while IFS= read -r line; do
|
||||
# Extract the size value from [size=256M] pattern
|
||||
local size_num
|
||||
size_num=$(echo "$line" | grep -oE '[0-9]+(M|G|K)' | head -1 || true)
|
||||
if [[ -n "$size_num" ]]; then
|
||||
local size_val
|
||||
size_val=$(echo "$size_num" | grep -oE '[0-9]+')
|
||||
local size_unit
|
||||
size_unit=$(echo "$size_num" | grep -oE '(M|G|K)')
|
||||
if [[ -n "$size_val" && -n "$size_unit" ]]; then
|
||||
case "$size_unit" in
|
||||
M) total_vram_mb=$((total_vram_mb + size_val)) ;;
|
||||
G) total_vram_mb=$((total_vram_mb + size_val * 1024)) ;;
|
||||
K) total_vram_mb=$((total_vram_mb + size_val / 1024)) ;;
|
||||
esac
|
||||
fi
|
||||
fi
|
||||
done < <(lspci -vnn 2>/dev/null | grep -i -A 15 -E 'VGA|3D|Display' | grep -i 'Memory at')
|
||||
if [[ $total_vram_mb -gt 0 ]]; then
|
||||
local total_vram_gb=$((total_vram_mb / 1024))
|
||||
local total_vram_mb_remain=$((total_vram_mb % 1024))
|
||||
echo "VRAM: $total_vram_mb MB ($total_vram_gb GB $total_vram_mb_remain MB)"
|
||||
else
|
||||
echo "VRAM: Could not determine from lspci"
|
||||
fi
|
||||
# Check for AMD GPU via amdgpu sysfs
|
||||
if lspci -vnn 2>/dev/null | grep -qi 'amd\|ati'; then
|
||||
local amdgpu_info
|
||||
amdgpu_info=$(ls /sys/kernel/debug/amdgpu/ 2>/dev/null | head -1)
|
||||
if [[ -n "$amdgpu_info" ]]; then
|
||||
local vram_total
|
||||
vram_total=$(cat /sys/kernel/debug/amdgpu/${amdgpu_info}/vram_total 2>/dev/null || echo 0)
|
||||
if [[ "$vram_total" -gt 0 ]]; then
|
||||
local vram_gb=$((vram_total / 1024 / 1024 / 1024))
|
||||
local vram_mb=$((vram_total / 1024 / 1024))
|
||||
echo "AMD GPU VRAM: ${vram_gb}GB (${vram_mb}MB)"
|
||||
fi
|
||||
fi
|
||||
fi
|
||||
fi
|
||||
fi
|
||||
|
||||
echo "Total VRAM: $((total_vram_kb / 1024 / 1024))GB"
|
||||
echo "VRAM per GPU: $((vram_per_gpu_kb / 1024 / 1024))GB"
|
||||
echo "Num GPUs: $num_gpus"
|
||||
}
|
||||
|
||||
# ─── System RAM Detection ───
|
||||
detect_ram() {
|
||||
local total_kb=0
|
||||
local available_kb=0
|
||||
|
||||
if [[ -f /proc/meminfo ]]; then
|
||||
total_kb=$(grep MemTotal /proc/meminfo | awk '{print $2}')
|
||||
available_kb=$(grep MemAvailable /proc/meminfo | awk '{print $2}')
|
||||
if [[ $total_kb -gt 0 ]]; then
|
||||
echo "RAM: $((total_kb / 1024 / 1024))GB total, $((available_kb / 1024 / 1024))GB available"
|
||||
echo "$available_kb $total_kb"
|
||||
fi
|
||||
elif command -v sysctl &>/dev/null; then
|
||||
total_kb=$(sysctl -n hw.memsize 2>/dev/null | awk '{print $1 / 1024}')
|
||||
if [[ -n "$total_kb" && "$total_kb" -gt 0 ]]; then
|
||||
echo "RAM: $((total_kb / 1024))GB total"
|
||||
echo "$total_kb $total_kb" # Assume all available
|
||||
fi
|
||||
else
|
||||
echo "RAM: Could not detect"
|
||||
echo "0 0"
|
||||
fi
|
||||
}
|
||||
|
||||
# ─── Model Context Window Detection ───
|
||||
detect_model_context() {
|
||||
local model_name="$1"
|
||||
local context_kb=0
|
||||
|
||||
# If model name provided, look it up
|
||||
if [[ -n "$model_name" ]]; then
|
||||
case "$model_name" in
|
||||
gpt-4o|gpt-4o-2024-05-13|gpt-4o-2024-08-06)
|
||||
context_kb=128000; echo "Model: $model_name"
|
||||
echo "Context window: 128k tokens"
|
||||
;;
|
||||
gpt-4o-mini|gpt-4o-mini-2024-07-18)
|
||||
context_kb=128000; echo "Model: $model_name"
|
||||
echo "Context window: 128k tokens"
|
||||
;;
|
||||
gpt-4-turbo|gpt-4-turbo-2024-04-09)
|
||||
context_kb=128000; echo "Model: $model_name"
|
||||
echo "Context window: 128k tokens"
|
||||
;;
|
||||
gpt-4|gpt-4-0125-preview|gpt-4-1106-preview)
|
||||
context_kb=128000; echo "Model: $model_name"
|
||||
echo "Context window: 128k tokens"
|
||||
;;
|
||||
claude-3-5-sonnet|claude-3-5-sonnet-20241022)
|
||||
context_kb=200000; echo "Model: $model_name"
|
||||
echo "Context window: 200k tokens"
|
||||
;;
|
||||
claude-3-5-haiku|claude-3-5-haiku-20241022)
|
||||
context_kb=200000; echo "Model: $model_name"
|
||||
echo "Context window: 200k tokens"
|
||||
;;
|
||||
claude-3-opus|claude-3-opus-20240229)
|
||||
context_kb=200000; echo "Model: $model_name"
|
||||
echo "Context window: 200k tokens"
|
||||
;;
|
||||
claude-3-sonnet|claude-3-sonnet-20240229)
|
||||
context_kb=200000; echo "Model: $model_name"
|
||||
echo "Context window: 200k tokens"
|
||||
;;
|
||||
claude-3-haiku|claude-3-haiku-20240307)
|
||||
context_kb=200000; echo "Model: $model_name"
|
||||
echo "Context window: 200k tokens"
|
||||
;;
|
||||
claude-2|claude-2.1)
|
||||
context_kb=200000; echo "Model: $model_name"
|
||||
echo "Context window: 200k tokens"
|
||||
;;
|
||||
*)
|
||||
echo "Model: $model_name (unknown context window)"
|
||||
echo "0"
|
||||
;;
|
||||
esac
|
||||
echo "$context_kb"
|
||||
return
|
||||
fi
|
||||
|
||||
# Try to detect from config.md (global framework model settings)
|
||||
local project_dir="${1:-.}"
|
||||
local config_md="${HOME}/.automaton/config.md"
|
||||
local model_from_config=""
|
||||
local override_context=""
|
||||
if [[ -f "$config_md" ]]; then
|
||||
# Check for model name
|
||||
model_from_config=$(grep -i "model:" "$config_md" 2>/dev/null | grep -v "#" | grep -v "model_context" | grep -v "override" | head -1 | sed -E 's/.*[:=[:space:]]+//i' | tr -d '[:space:]')
|
||||
# Check for override context window
|
||||
override_context=$(grep -i "override context" "$config_md" 2>/dev/null | grep -v "#" | head -1 | sed -E 's/.*[:=[:space:]]+//i' | tr -d '[:space:]')
|
||||
fi
|
||||
|
||||
# If config.md specifies a model, use it
|
||||
if [[ -n "$model_from_config" ]]; then
|
||||
echo "Found model in config.md: $model_from_config"
|
||||
# Use override context window if specified in config.md
|
||||
if [[ -n "$override_context" && "$override_context" != "auto" ]]; then
|
||||
echo "Using override context window from config.md: $override_context"
|
||||
local override_kb
|
||||
override_kb=$(echo "$override_context" | sed 's/[kK]$//' | grep -oP '[0-9]+' || true)
|
||||
if [[ -n "$override_kb" ]]; then
|
||||
echo "Context window: ${override_context} tokens (override)"
|
||||
echo "$((override_kb * 1000))"
|
||||
return
|
||||
fi
|
||||
fi
|
||||
detect_model_context "$model_from_config"
|
||||
return
|
||||
fi
|
||||
|
||||
# Try to detect from .agent.md (project-level model override)
|
||||
local agent_md="${project_dir}/.automaton/.agent.md"
|
||||
if [[ -f "$agent_md" ]]; then
|
||||
local model_line
|
||||
model_line=$(grep -i "model" "$agent_md" 2>/dev/null | grep -v "#" | grep -v "target" | grep -v "headroom" | grep -v "peak" | grep -v "Auto-detect" | head -1)
|
||||
if [[ -n "$model_line" ]]; then
|
||||
echo "Found model in .agent.md: $model_line"
|
||||
# Extract model name from the line
|
||||
local model
|
||||
model=$(echo "$model_line" | sed -E 's/.*[:=[:space:]]+//i' | tr -d '[:space:]')
|
||||
if [[ -n "$model" ]]; then
|
||||
# Use override context window if specified in config.md
|
||||
if [[ -n "$override_context" && "$override_context" != "auto" ]]; then
|
||||
echo "Using override context window from config.md: $override_context"
|
||||
# Convert override_context to kb (e.g., 128k -> 128000, 200k -> 200000)
|
||||
local override_kb
|
||||
override_kb=$(echo "$override_context" | sed 's/[kK]$//' | grep -oP '[0-9]+' || true)
|
||||
if [[ -n "$override_kb" ]]; then
|
||||
echo "Context window: ${override_context} tokens (override)"
|
||||
echo "$((override_kb * 1000))"
|
||||
return
|
||||
fi
|
||||
fi
|
||||
detect_model_context "$model"
|
||||
return
|
||||
fi
|
||||
fi
|
||||
fi
|
||||
|
||||
# Try to detect from common API config files
|
||||
local config_files=(
|
||||
".env"
|
||||
".env.local"
|
||||
"config.yaml"
|
||||
"config.yml"
|
||||
"config.json"
|
||||
"settings.yaml"
|
||||
".automaton/config.yaml"
|
||||
".automaton/config.json"
|
||||
)
|
||||
|
||||
for config_file in "${config_files[@]}"; do
|
||||
local abs_file=""
|
||||
for candidate in "${project_dir}/${config_file}" "${project_dir}/.automaton/${config_file}"; do
|
||||
if [[ -f "$candidate" ]]; then
|
||||
abs_file="$candidate"
|
||||
break
|
||||
fi
|
||||
done
|
||||
|
||||
if [[ -n "$abs_file" ]]; then
|
||||
local model
|
||||
model=$(grep -i "model" "$abs_file" 2>/dev/null | grep -v "#" | grep -v "context" | grep -v "max_tokens" | grep -v "temperature" | grep -v "stream" | head -1 | sed -E 's/.*[:=[:space:]]+//i' | tr -d '[:space:]')
|
||||
if [[ -n "$model" ]]; then
|
||||
echo "Found model in $abs_file: $model"
|
||||
# Use override context window if specified in config.md
|
||||
if [[ -n "$override_context" && "$override_context" != "auto" ]]; then
|
||||
echo "Using override context window from config.md: $override_context"
|
||||
local override_kb
|
||||
override_kb=$(echo "$override_context" | sed 's/[kK]$//' | grep -oP '[0-9]+' || true)
|
||||
if [[ -n "$override_kb" ]]; then
|
||||
echo "Context window: ${override_context} tokens (override)"
|
||||
echo "$((override_kb * 1000))"
|
||||
return
|
||||
fi
|
||||
fi
|
||||
detect_model_context "$model"
|
||||
return
|
||||
fi
|
||||
fi
|
||||
done
|
||||
|
||||
echo "Model: Unknown (could not detect from .agent.md or config files)"
|
||||
echo "0"
|
||||
}
|
||||
|
||||
# ─── Agent Framework Overhead Calculation ───
|
||||
calculate_overhead() {
|
||||
local project_dir="${1:-.}"
|
||||
local overhead_tokens=0
|
||||
|
||||
# Count tokens for the framework files that are loaded during orchestration
|
||||
# These are the files loaded during the most common phase (orchestration):
|
||||
# .agent.md + .rules.md + workflow.md + orchestrate.md
|
||||
# Note: other phase files (decompose.md, implement.md, etc.) are only loaded during
|
||||
# their specific phases, so they don't contribute to the peak context during orchestration.
|
||||
local framework_files=(
|
||||
"${project_dir}/.automaton/.agent.md"
|
||||
"${project_dir}/.automaton/.rules.md"
|
||||
"${project_dir}/.automaton/prompts/workflow.md"
|
||||
"${project_dir}/.automaton/prompts/orchestrate.md"
|
||||
)
|
||||
# Fallback: check home directory if project dir doesn't have framework
|
||||
if [[ ! -f "${project_dir}/.automaton/.agent.md" ]]; then
|
||||
framework_files=(
|
||||
"${HOME}/.automaton/.agent.md"
|
||||
"${HOME}/.automaton/.rules.md"
|
||||
"${HOME}/.automaton/prompts/workflow.md"
|
||||
"${HOME}/.automaton/prompts/orchestrate.md"
|
||||
)
|
||||
fi
|
||||
|
||||
for file in "${framework_files[@]}"; do
|
||||
if [[ -f "$file" ]]; then
|
||||
# Rough estimate: 1 token ≈ 4 characters (English text)
|
||||
local chars
|
||||
chars=$(wc -c < "$file" 2>/dev/null || echo 0)
|
||||
local tokens=$((chars / 4))
|
||||
overhead_tokens=$((overhead_tokens + tokens))
|
||||
echo " ${file##*/}: ~${tokens} tokens"
|
||||
fi
|
||||
done
|
||||
|
||||
echo "Framework overhead: ~${overhead_tokens} tokens"
|
||||
echo "$overhead_tokens"
|
||||
}
|
||||
|
||||
# ─── Recommendation Engine ───
|
||||
recommend_context() {
|
||||
local gpu_vram_gb="$1"
|
||||
local ram_gb="$2"
|
||||
local model_context_kb="$3"
|
||||
local overhead_tokens="$4"
|
||||
|
||||
# Read VRAM config from config.md if it exists
|
||||
local config_md="${HOME}/.automaton/config.md"
|
||||
local auto_detect="Yes"
|
||||
local target_context_kb=0
|
||||
local override_headroom=25
|
||||
local override_max_peak_kb=0
|
||||
if [[ -f "$config_md" ]]; then
|
||||
auto_detect=$(grep -i "auto-detect:" "$config_md" 2>/dev/null | grep -v "#" | grep -i "vram" | head -1 | sed -E 's/.*[:=[:space:]]+//i' | tr -d '[:space:]' || true)
|
||||
target_context_kb=$(grep -i "target.*context" "$config_md" 2>/dev/null | grep -v "#" | grep -i "vram" | head -1 | sed -E 's/.*[:=[:space:]]+//i' | grep -oP '\d+' || true)
|
||||
override_headroom=$(grep -i "headroom" "$config_md" 2>/dev/null | grep -v "#" | grep -i "vram" | head -1 | sed -E 's/.*[:=[:space:]]+//i' | grep -oP '\d+' || true)
|
||||
override_max_peak_kb=$(grep -i "max peak" "$config_md" 2>/dev/null | grep -v "#" | grep -i "vram" | head -1 | sed -E 's/.*[:=[:space:]]+//i' | grep -oP '\d+' || true)
|
||||
fi
|
||||
|
||||
# If auto-detect is disabled, use the manually specified values
|
||||
if [[ -n "$auto_detect" && "$auto_detect" == "No" ]]; then
|
||||
if [[ -n "$target_context_kb" ]]; then
|
||||
local max_peak_kb=${override_max_peak_kb:-0}
|
||||
if [[ $max_peak_kb -eq 0 && $headroom_pct -gt 0 ]]; then
|
||||
max_peak_kb=$((target_context_kb * (100 - headroom_pct) / 100))
|
||||
fi
|
||||
echo "$headroom_pct"
|
||||
echo "$target_context_kb"
|
||||
echo "$max_peak_kb"
|
||||
return
|
||||
fi
|
||||
fi
|
||||
|
||||
local recommended_kb=0
|
||||
local headroom_pct=${override_headroom:-25} # Use override from config.md, or default to 25%
|
||||
|
||||
# Output headroom_pct first (for parent to read)
|
||||
# Then output recommended_kb
|
||||
# Then output max_peak_kb (only for manual mode)
|
||||
echo "$headroom_pct"
|
||||
|
||||
# Recommendation logic:
|
||||
# 1. If GPU VRAM >= 4GB: use VRAM (practical for local inference)
|
||||
# 2. If model context window is available: use it (for API inference)
|
||||
# 3. If GPU VRAM < 4GB but > 0: use RAM (VRAM too small for local inference)
|
||||
# 4. If no GPU VRAM and no model: use RAM as fallback
|
||||
|
||||
# If GPU VRAM >= 4GB, base it on VRAM
|
||||
if [[ $gpu_vram_gb -ge 4 ]]; then
|
||||
# Rule of thumb: 1GB VRAM ≈ 4k tokens for local LLMs
|
||||
# But we need to leave room for the model itself
|
||||
# For a model, each ~8k context tokens takes about ~3-5MB of GPU VRAM
|
||||
# So VRAM available for context = VRAM - model size - agent overhead
|
||||
# Conservative: 1GB VRAM ≈ 2k context tokens
|
||||
local vram_context_kb=$((gpu_vram_gb * 2000))
|
||||
|
||||
# Leave headroom for the model itself and agent overhead
|
||||
recommended_kb=$((vram_context_kb * (100 - headroom_pct) / 100))
|
||||
# If model context window is available, use it (for API inference)
|
||||
elif [[ $model_context_kb -gt 0 ]]; then
|
||||
# For API-based, we're limited by the model's context window
|
||||
# But we don't want to use the full window due to overhead
|
||||
recommended_kb=$((model_context_kb * (100 - headroom_pct) / 100))
|
||||
# Fallback: use RAM to estimate
|
||||
else
|
||||
# Moderate estimate for low-VRAM systems where VRAM is too small for local inference
|
||||
# but RAM is available. Use 0.75k tokens per GB of RAM as a moderate estimate.
|
||||
# This balances between being too conservative (0.5k/GB) and too generous (1k/GB).
|
||||
local ram_context_kb=$((ram_gb * 750))
|
||||
recommended_kb=$((ram_context_kb * (100 - headroom_pct) / 100))
|
||||
fi
|
||||
|
||||
# Subtract framework overhead
|
||||
local net_kb=$((recommended_kb - overhead_tokens))
|
||||
if [[ $net_kb -lt 0 ]]; then
|
||||
net_kb=0
|
||||
fi
|
||||
|
||||
# Output: headroom_pct, recommended_kb
|
||||
echo "$net_kb"
|
||||
}
|
||||
|
||||
# ─── Main ───
|
||||
main() {
|
||||
local model_name=""
|
||||
local project_dir="."
|
||||
|
||||
# Parse arguments
|
||||
while [[ $# -gt 0 ]]; do
|
||||
case "$1" in
|
||||
--model|-m)
|
||||
model_name="$2"
|
||||
shift 2
|
||||
;;
|
||||
--project|-p)
|
||||
project_dir="$2"
|
||||
shift 2
|
||||
;;
|
||||
*)
|
||||
# Could be model name as first argument
|
||||
if [[ -z "$model_name" ]]; then
|
||||
model_name="$1"
|
||||
fi
|
||||
shift
|
||||
;;
|
||||
esac
|
||||
done
|
||||
|
||||
echo "=== VRAM / Context Detection ==="
|
||||
echo ""
|
||||
|
||||
# Detect GPU VRAM
|
||||
echo "--- GPU VRAM ---"
|
||||
detect_gpu_vram
|
||||
local gpu_vram_kb=0
|
||||
local gpu_vram_gb=0
|
||||
# Use timeout to avoid hanging
|
||||
gpu_vram_kb=$(timeout 5 nvidia-smi --query-gpu=memory.total --format=csv,noheader,nounits 2>/dev/null | head -1 | tr -d ' ' || true)
|
||||
# Validate that vram_kb is a positive number
|
||||
if [[ -z "$gpu_vram_kb" || ! "$gpu_vram_kb" =~ ^[0-9]+$ || "$gpu_vram_kb" -le 0 ]]; then
|
||||
gpu_vram_kb=0
|
||||
fi
|
||||
# If nvidia-smi didn't work, try to detect from lspci (AMD GPUs)
|
||||
if [[ $gpu_vram_kb -eq 0 ]]; then
|
||||
echo " nvidia-smi failed, checking lspci for AMD GPU VRAM..."
|
||||
local total_vram_mb=0
|
||||
while IFS= read -r line; do
|
||||
local size_num
|
||||
size_num=$(echo "$line" | grep -oE '[0-9]+(M|G|K)' | head -1 || true)
|
||||
if [[ -n "$size_num" ]]; then
|
||||
local size_val
|
||||
size_val=$(echo "$size_num" | grep -oE '[0-9]+')
|
||||
local size_unit
|
||||
size_unit=$(echo "$size_num" | grep -oE '(M|G|K)')
|
||||
if [[ -n "$size_val" && -n "$size_unit" ]]; then
|
||||
case "$size_unit" in
|
||||
M) total_vram_mb=$((total_vram_mb + size_val)) ;;
|
||||
G) total_vram_mb=$((total_vram_mb + size_val * 1024)) ;;
|
||||
K) total_vram_mb=$((total_vram_mb + size_val / 1024)) ;;
|
||||
esac
|
||||
fi
|
||||
fi
|
||||
done < <(lspci -vnn 2>/dev/null | grep -i -A 15 -E 'VGA|3D|Display' | grep -i 'Memory at')
|
||||
if [[ $total_vram_mb -gt 0 ]]; then
|
||||
gpu_vram_kb=$((total_vram_mb * 1024))
|
||||
gpu_vram_gb=$((total_vram_mb / 1024))
|
||||
echo " AMD GPU VRAM from lspci: ${gpu_vram_gb}GB ($total_vram_mb MB)"
|
||||
else
|
||||
echo " No VRAM found from lspci"
|
||||
fi
|
||||
fi
|
||||
echo ""
|
||||
|
||||
# Detect RAM
|
||||
echo "--- RAM ---"
|
||||
detect_ram
|
||||
local ram_kb
|
||||
ram_kb=$(grep MemTotal /proc/meminfo 2>/dev/null | awk '{print $2}' || echo 0)
|
||||
local ram_gb=$((ram_kb / 1024 / 1024))
|
||||
echo ""
|
||||
|
||||
# Detect model context window
|
||||
echo "--- Model Context Window ---"
|
||||
detect_model_context "$model_name"
|
||||
local model_context_kb
|
||||
model_context_kb=$(detect_model_context "$model_name" | tail -1)
|
||||
echo ""
|
||||
|
||||
# Calculate framework overhead
|
||||
echo "--- Framework Overhead ---"
|
||||
calculate_overhead "$project_dir"
|
||||
local overhead_tokens
|
||||
overhead_tokens=$(calculate_overhead "$project_dir" | tail -1)
|
||||
echo ""
|
||||
|
||||
# Recommend context window (also outputs headroom_pct and recommended_kb)
|
||||
echo "--- Recommendation ---"
|
||||
local recommendation_output
|
||||
recommendation_output=$(recommend_context "$gpu_vram_gb" "$ram_gb" "$model_context_kb" "$overhead_tokens")
|
||||
local line_count
|
||||
line_count=$(echo "$recommendation_output" | wc -l)
|
||||
local recommended_kb
|
||||
local headroom_pct
|
||||
local max_peak_kb
|
||||
if [[ $line_count -ge 3 ]]; then
|
||||
# Manual mode: outputs headroom_pct, recommended_kb, max_peak_kb
|
||||
headroom_pct=$(echo "$recommendation_output" | head -1 | tr -d '[:space:]')
|
||||
recommended_kb=$(echo "$recommendation_output" | sed -n '2p' | tr -d '[:space:]')
|
||||
max_peak_kb=$(echo "$recommendation_output" | tail -1 | tr -d '[:space:]')
|
||||
else
|
||||
# Auto-detect mode: outputs headroom_pct, recommended_kb
|
||||
headroom_pct=$(echo "$recommendation_output" | head -1 | tr -d '[:space:]')
|
||||
recommended_kb=$(echo "$recommendation_output" | tail -1 | tr -d '[:space:]')
|
||||
# Calculate max peak context based on headroom
|
||||
max_peak_kb=$((recommended_kb * (100 - headroom_pct) / 100))
|
||||
fi
|
||||
|
||||
# Convert to human-readable
|
||||
local recommended_k
|
||||
if [[ $recommended_kb -gt 0 ]]; then
|
||||
recommended_k=$((recommended_kb / 1000))
|
||||
else
|
||||
recommended_k=8 # Default fallback
|
||||
fi
|
||||
|
||||
echo ""
|
||||
echo "=== Recommended Configuration ==="
|
||||
echo "Target context: ${recommended_k}k tokens"
|
||||
echo "Headroom: ${headroom_pct}%"
|
||||
echo "Max peak context per sub-task: $((recommended_k * (100 - headroom_pct) / 100))k tokens"
|
||||
|
||||
# Output as JSON for programmatic use
|
||||
echo ""
|
||||
echo "=== JSON Output ==="
|
||||
cat <<EOF
|
||||
{
|
||||
"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,
|
||||
"recommended_k": $recommended_k,
|
||||
"headroom": 0.25,
|
||||
"max_peak_context_kb": $max_peak_kb
|
||||
}
|
||||
EOF
|
||||
}
|
||||
|
||||
main "$@"
|
||||
+12
-3
@@ -2,10 +2,19 @@ You are working inside the minimal agent framework.
|
||||
|
||||
At the very start of every session, you must:
|
||||
|
||||
1. Read ~/.agent-framework/AGENT.md (global router)
|
||||
2. Read the current project's .agent-framework/AGENT.md (if it exists)
|
||||
3. Read the current project's .agent-framework/RULES.md (if it exists)
|
||||
1. Read ~/.automaton/.agent.md (global router)
|
||||
2. Read the current project's .automaton/.agent.md (if it exists)
|
||||
3. Read the current project's .automaton/.rules.md (if it exists)
|
||||
|
||||
After reading these files, respond with: "Framework context loaded. Ready for task."
|
||||
|
||||
Only after this acknowledgment should you process the user's actual request.
|
||||
|
||||
## Dashboard
|
||||
|
||||
The automaton dashboard is available for monitoring task progress:
|
||||
- Run: `python -m automaton.dashboard` from any project root or ~/.automaton/
|
||||
- The dashboard is scope-aware: framework mode in ~/.automaton/, project mode in target projects
|
||||
- Views: Board (Kanban), Statistics, Timeline
|
||||
- Keyboard shortcuts: Space (view), t (theme), f (filter), s (search), q (quit), ? (help)
|
||||
- See ~/.automaton/dashboard/README.md for full documentation
|
||||
@@ -0,0 +1,195 @@
|
||||
# Contract: Interactive Dashboard for Automaton Framework
|
||||
|
||||
## Goal
|
||||
|
||||
Build an interactive terminal dashboard that visualizes and monitors task progress within the automaton framework. The dashboard is **scope-aware**: when opened in `~/.automaton/`, it tracks framework development tasks; when opened in any project root (a project that has installed automaton), it tracks that project's tasks.
|
||||
|
||||
## Requirements
|
||||
|
||||
### 1. Scope-Aware Context Detection
|
||||
- **1.1** The dashboard detects its scope by walking up the directory tree from the current working directory to find the nearest `.automaton/` folder.
|
||||
- **1.2** If the nearest `.automaton/` folder is `~/.automaton/`, the dashboard operates in **framework mode** (tracks framework development).
|
||||
- **1.3** If the nearest `.automaton/` folder is inside a project root, the dashboard operates in **project mode** (tracks that project's tasks).
|
||||
- **1.4** The current scope is displayed in the dashboard header.
|
||||
|
||||
### 2. Kanban Board View (Primary View)
|
||||
- **2.1** The board displays tasks as cards organized into columns by their current phase.
|
||||
- **2.2** Columns map directly to the automaton task state machine:
|
||||
- **Backlog** — No artifacts (New state)
|
||||
- **Research** — Has SPEC.md (Research phase)
|
||||
- **Decomposition** — Has SPEC.md + DECOMPOSITION.md (Decomposition phase)
|
||||
- **Design** — Has SPEC.md + DESIGN.md (Design phase)
|
||||
- **Implement** — Has IMPLEMENTATION.md (Implement phase)
|
||||
- **Bug Find** — Has BUG_REPORT.md (Bug Find phase)
|
||||
- **Adversarial Bug Find** — Has ADVERSARIAL_BUG_REPORT.md (Adversarial Bug Find phase)
|
||||
- **Doc Review** — Has DOC_REVIEW.md (Doc Review phase)
|
||||
- **Referee** — Has VERDICT.md (Referee phase)
|
||||
- **Done** — VERDICT.md with PASS (Complete state)
|
||||
- **Blocked** — VERDICT.md with FAIL or NEEDS_REVIEW (Human Intervention)
|
||||
- **2.3** Tasks with sub-tasks show a collapsed indicator (e.g., `[3/5]`) showing sub-task completion progress.
|
||||
- **2.4** Tasks can be expanded to show sub-task details inline.
|
||||
- **2.5** Columns are horizontally scrollable if they overflow the terminal width.
|
||||
|
||||
### 3. Task Cards
|
||||
- **3.1** Each task card displays:
|
||||
- Task name (kebab-case folder name, human-readable)
|
||||
- Current phase/column
|
||||
- Time elapsed since task creation (if timestamp is available)
|
||||
- Sub-task progress indicator (if applicable)
|
||||
- Status indicator (e.g., ✅ PASS, ❌ FAIL, ⏸ BLOCKED, 🔄 IN PROGRESS)
|
||||
- **3.2** Cards are selectable with arrow keys or mouse.
|
||||
- **3.3** Selected card shows expanded details in a side panel or bottom panel.
|
||||
|
||||
### 4. Task Detail Panel
|
||||
- **4.1** When a task card is selected, the detail panel shows:
|
||||
- Full task name and folder path
|
||||
- Current state/mapping to kanban column
|
||||
- List of artifacts present (SPEC.md, DESIGN.md, etc.) with status
|
||||
- Sub-task list (if applicable) with individual statuses
|
||||
- VERDICT.md content (if present)
|
||||
- BUG_REPORT.md content (if present)
|
||||
- **4.2** The detail panel is resizable.
|
||||
- **4.3** Navigating away from a task hides the detail panel.
|
||||
|
||||
### 5. Statistics View
|
||||
- **5.1** A statistics view accessible via keybinding shows:
|
||||
- Total tasks count
|
||||
- Tasks per phase breakdown (bar chart or table)
|
||||
- Pass/Fail/Blocked rate
|
||||
- Average tasks completed per day (if timestamps available)
|
||||
- Current WIP (tasks in progress, not in Backlog or Done)
|
||||
- **5.2** Statistics are calculated in real-time from the `tasks/` directory.
|
||||
|
||||
### 6. Timeline View
|
||||
- **6.1** A timeline view accessible via keybinding shows:
|
||||
- Tasks arranged by their progress through phases over time
|
||||
- Wave visualization for decomposed tasks (Wave 1, Wave 2, etc.)
|
||||
- Sub-task parallel execution visualization
|
||||
- **6.2** Timeline is scrollable and zoomable.
|
||||
|
||||
### 7. Filtering and Search
|
||||
- **7.1** Filter tasks by phase/status using a filter bar.
|
||||
- **7.2** Filter tasks by sub-task wave (for decomposed tasks).
|
||||
- **7.3** Search tasks by name using a search bar.
|
||||
- **7.4** Filters are combinable (e.g., show only "Research" tasks in Wave 2).
|
||||
|
||||
### 8. Keyboard Navigation
|
||||
- **8.1** Arrow keys to move between columns and cards.
|
||||
- **8.2** `Enter` to expand/collapse selected card or view task details.
|
||||
- **8.3** `Space` to cycle through views (Board → Statistics → Timeline).
|
||||
- **8.4** `q` or `Ctrl+C` to quit.
|
||||
- **8.5** `?` to show keybindings help.
|
||||
- **8.6** `f` to open filter bar.
|
||||
- **8.7** `s` to open search bar.
|
||||
- **8.8** `w` to cycle through waves (for decomposed tasks).
|
||||
|
||||
### 9. Auto-Refresh
|
||||
- **9.1** The dashboard auto-refreshes when the `tasks/` directory changes (file system watch).
|
||||
- **9.2** Auto-refresh interval: 2 seconds (configurable).
|
||||
- **9.3** Manual refresh triggered by `r` key.
|
||||
- **9.4** Refresh indicator in the header shows when a refresh occurs.
|
||||
|
||||
### 10. Configuration
|
||||
- **10.1** Dashboard settings stored in `{project}/.automaton/dashboard-config.json`:
|
||||
- `auto_refresh_interval`: seconds between auto-refreshes (default: 2)
|
||||
- `default_view`: which view to show on startup ("board", "statistics", "timeline")
|
||||
- `column_width`: minimum width of each column in characters (default: 30)
|
||||
- `show_timelines`: show time elapsed on cards (default: true)
|
||||
- `theme`: color theme ("default", "dark", "light")
|
||||
- **10.2** Configuration is scoped to the project (not global).
|
||||
|
||||
### 11. Color Theme
|
||||
- **11.1** Default theme uses ANSI color codes for:
|
||||
- Backlog: gray
|
||||
- Research: blue
|
||||
- Decomposition: purple
|
||||
- Design: cyan
|
||||
- Implement: green
|
||||
- Bug Find: orange
|
||||
- Adversarial Bug Find: red (darker)
|
||||
- Doc Review: yellow
|
||||
- Referee: magenta
|
||||
- Done: green (bright)
|
||||
- Blocked: red
|
||||
- **11.2** Theme is switchable via keybinding (`t` to cycle themes).
|
||||
|
||||
### 12. Sub-Task Visualization
|
||||
- **12.1** For decomposed tasks, sub-tasks are shown as indented items under the parent task card.
|
||||
- **12.2** Sub-task progress is shown as a fraction (e.g., `[3/5]` = 3 of 5 sub-tasks complete).
|
||||
- **12.3** Clicking a sub-task shows its detail in the detail panel.
|
||||
- **12.4** Sub-task waves are visualized with visual separation in the Timeline view.
|
||||
|
||||
### 13. Performance
|
||||
- **13.1** Dashboard renders within 500ms of a refresh (for projects with up to 100 tasks).
|
||||
- **13.2** No blocking I/O during rendering.
|
||||
- **13.3** File system watch uses inotify (Linux) or kqueue (macOS) for efficient change detection.
|
||||
|
||||
### 14. Error Handling
|
||||
- **14.1** If `tasks/` directory is missing, show a "No tasks found" message.
|
||||
- **14.2** If a task artifact file is corrupted or unreadable, show a warning indicator on the card.
|
||||
- **14.3** If the dashboard is opened outside any automaton project, show an error and exit gracefully.
|
||||
|
||||
### 15. Documentation
|
||||
- **15.1** README.md in the dashboard module with usage instructions.
|
||||
- **15.2** Keybindings reference accessible via `?` in the dashboard.
|
||||
- **15.3** Configuration schema documented with default values.
|
||||
|
||||
---
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- **15.1** Web UI (browser-based) — this is terminal-only (TUI).
|
||||
- **15.2** Real-time collaboration — single-user only.
|
||||
- **15.3** Task creation/editing — dashboard is read-only for task state.
|
||||
- **15.4** Notification system — no push notifications or alerts.
|
||||
- **15.5** Calendar integration — no date-based scheduling.
|
||||
- **15.6** Integration with external PM tools — standalone only.
|
||||
|
||||
---
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Dashboard detects scope (framework vs. project) correctly based on cwd
|
||||
- [ ] Board view displays all tasks in correct Kanban columns based on state machine
|
||||
- [ ] Task cards show name, phase, status, and sub-task progress
|
||||
- [ ] Task detail panel shows full task information when selected
|
||||
- [ ] Statistics view shows correct counts per phase and pass/fail rates
|
||||
- [ ] Timeline view shows task progress and wave structure
|
||||
- [ ] Filter bar filters tasks by phase and wave
|
||||
- [ ] Search bar finds tasks by name
|
||||
- [ ] All 11 keyboard bindings (Enter, Space, q, ?, f, s, w, t, r) work correctly
|
||||
- [ ] Auto-refresh works on file system changes with 2-second interval
|
||||
- [ ] Dashboard configuration file is created and read correctly
|
||||
- [ ] Color themes cycle correctly with 3 themes
|
||||
- [ ] Sub-task visualization shows progress fraction and expandable details
|
||||
- [ ] Dashboard renders within 500ms for 100 tasks
|
||||
- [ ] Error handling works for missing tasks/ directory and corrupted artifacts
|
||||
- [ ] Documentation includes usage instructions and keybindings reference
|
||||
|
||||
---
|
||||
|
||||
## Risks & Mitigations
|
||||
|
||||
- **Risk 1**: Terminal rendering performance degrades with many tasks
|
||||
- Mitigation: Implement virtual rendering (only render visible columns/cards), lazy-load task details
|
||||
- **Risk 2**: File system watch conflicts with agent writing artifacts
|
||||
- Mitigation: Use debounced file system events, handle partial writes gracefully
|
||||
- **Risk 3**: Task state determination is inconsistent with Orchestrator
|
||||
- Mitigation: Use the same state machine logic as `orchestrate.md` for determining task states
|
||||
- **Risk 4**: Dashboard breaks when automaton framework is upgraded
|
||||
- Mitigation: Dashboard reads state from the same artifacts the Orchestrator reads; no hardcoded state machine logic — it derives from artifact presence
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- The dashboard should be a separate module under `~/.automaton/` (e.g., `~/.automaton/dashboard/`) so it can be upgraded independently.
|
||||
- The dashboard uses the same layered file system approach as the Orchestrator — it reads from project's `.automaton/` first, then falls back to global `~/.automaton/`.
|
||||
- Task names in the dashboard should be human-readable. The kebab-case folder name (e.g., `add-user-auth`) should be converted to a display name (e.g., "Add User Auth") by replacing hyphens with spaces and capitalizing.
|
||||
- The dashboard is a **read-only** view of task state — it does not modify or create artifacts. All task lifecycle operations continue through the Orchestrator.
|
||||
|
||||
---
|
||||
|
||||
## Stop Condition
|
||||
|
||||
When all checkboxes are checked and the dashboard is fully functional, output "CONTRACT_MET" and stop.
|
||||
@@ -0,0 +1,61 @@
|
||||
# Contract: Dashboard Phase Grouping
|
||||
|
||||
## Goal
|
||||
Group the 12 Kanban columns into 5 logical phase groups, with individual task states shown as sub-labels on cards. Also fix the header to show the project name instead of a scope indicator.
|
||||
|
||||
## Header Fix
|
||||
The scope badge currently shows "🏗 Framework" or "📁 Project" — this should be replaced with the actual project name.
|
||||
- Show the project name (from `README.md` first heading, or `.automaton/project-name.md` if it exists)
|
||||
- If no project name is found, show the project directory name
|
||||
- No need for scope indicators (Framework/Project mode is internal)
|
||||
|
||||
## Column Grouping
|
||||
|
||||
| Group | Columns | Rationale |
|
||||
|-------|---------|----------|
|
||||
| **Planning** | Backlog, Research, Decomposition | Early stage — defining the problem and scope |
|
||||
| **Design** | Design, Test Design | Designing the solution |
|
||||
| **Implementation** | Implement | Building the solution |
|
||||
| **Verification** | Bug Find, Adversarial Bug Find, Doc Review, Referee | Quality assurance and validation |
|
||||
| **Resolution** | Done, Blocked | Final states |
|
||||
|
||||
## Card Display
|
||||
Each card shows its specific state as a small sub-label beneath the task name:
|
||||
```
|
||||
┌──────────────────────┐
|
||||
│ Implement Task │
|
||||
│ 🔄 implement │
|
||||
└──────────────────────┘
|
||||
|
||||
┌──────────────────────┐
|
||||
│ Bad Impl │
|
||||
│ ❌ blocked │
|
||||
└──────────────────────┘
|
||||
|
||||
┌──────────────────────┐
|
||||
│ Research Task │
|
||||
│ 🔄 research │
|
||||
└──────────────────────┘
|
||||
```
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Board renders 5 grouped columns instead of 12 individual columns
|
||||
- [ ] Cards in a column display a sub-label with their specific state (e.g., "research", "implement", "bug_find", "blocked")
|
||||
- [ ] Empty columns are hidden (no empty groups shown)
|
||||
- [ ] Column headers show the group name and total count
|
||||
- [ ] Column headers show a colored indicator bar for each group:
|
||||
- Planning: blue (#42a5f5)
|
||||
- Design: cyan (#26c6da)
|
||||
- Implementation: green (#66bb6a)
|
||||
- Verification: amber (#ffa726)
|
||||
- Resolution: green/red (#66bb6a / #ef5350)
|
||||
- [ ] Grouped columns are sortable by total count (same as current board behavior)
|
||||
- [ ] Clicking a card still opens the detail panel with the same information
|
||||
- [ ] Filter bar still works with the grouped view (filter by specific state)
|
||||
- [ ] Statistics view shows group-level breakdowns in addition to individual states
|
||||
- [ ] Timeline view shows grouped phases (Planning, Design, Implementation, Verification, Resolution) instead of 12 individual states
|
||||
- [ ] Header shows the project name (from README.md or directory name) instead of scope indicator
|
||||
- [ ] Scope label no longer shows "🏗 Framework" or "📁 Project"
|
||||
|
||||
## Stop Condition
|
||||
CONTRACT_MET
|
||||
@@ -0,0 +1,53 @@
|
||||
# VERDICT: Dashboard Phase Grouping
|
||||
|
||||
## Summary
|
||||
The dashboard has been modified to group the 12 Kanban columns into 5 logical phase groups. The header now shows the project name instead of the scope indicator. Cards display sub-labels with their specific state.
|
||||
|
||||
## Changes Made
|
||||
|
||||
### 1. Phase Grouping (dashboard.js)
|
||||
- Defined 5 phase groups: Planning, Design, Implementation, Verification, Resolution
|
||||
- Board now renders grouped columns instead of 12 individual columns
|
||||
- Empty groups are hidden (only groups with tasks are shown)
|
||||
- Group column headers show the group name and count with colored indicators
|
||||
|
||||
### 2. Card Sub-labels (dashboard.js)
|
||||
- Each card now displays a sub-label with the specific state (e.g., "🔬 Research", "🐛 Bug Find")
|
||||
- State icons are defined in STATE_ICONS mapping
|
||||
|
||||
### 3. Header Change (dashboard.js + app.py)
|
||||
- Added /api/project-name endpoint that reads from .automaton/project-name.md, README.md, or falls back to directory name
|
||||
- Header now shows project name (📂 Automaton) instead of scope indicator (🏗 Framework / 📁 Project)
|
||||
|
||||
### 4. Stats View (dashboard.js)
|
||||
- Stats view now shows both phase group breakdown and individual state breakdown
|
||||
- Phase group bars are color-coded with group colors
|
||||
|
||||
### 5. Timeline View (dashboard.js)
|
||||
- Timeline now shows 5 phase group indicators instead of 12 individual states
|
||||
- Legend shows phase group colors
|
||||
|
||||
### 6. Detail Panel (dashboard.js)
|
||||
- Detail panel now shows phase group badge next to status
|
||||
|
||||
### 7. CSS Updates (styles.css)
|
||||
- Added column-header data-color styles for phase groups
|
||||
- Added task-card-sublabel style
|
||||
- Added detail-phase-badge style
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- ✅ Board renders 5 grouped columns instead of 12 individual columns
|
||||
- ✅ Cards in a column display a sub-label with their specific state
|
||||
- ✅ Empty columns are hidden (no empty groups shown)
|
||||
- ✅ Column headers show the group name and total count
|
||||
- ✅ Column headers show a colored indicator bar for each group
|
||||
- ✅ Grouped columns are sortable by total count (same as current board behavior)
|
||||
- ✅ Clicking a card still opens the detail panel with the same information
|
||||
- ✅ Filter bar still works with the grouped view (filter by specific state)
|
||||
- ✅ Statistics view shows group-level breakdowns in addition to individual states
|
||||
- ✅ Timeline view shows grouped phases instead of 12 individual states
|
||||
- ✅ Header shows the project name instead of scope indicator
|
||||
- ✅ Scope label no longer shows "🏗 Framework" or "📁 Project"
|
||||
|
||||
## VERDICT: PASS
|
||||
@@ -0,0 +1,13 @@
|
||||
# Adversarial Bug Report: Dashboard Implementation
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: Critical
|
||||
- **Issue**: File system watcher doesn't handle inotify permission errors on some systems
|
||||
- **Impact**: High - dashboard may crash when starting on systems without inotify
|
||||
- **Fix**: Add try/except around inotify initialization, fall back to polling
|
||||
|
||||
### Finding 2: Medium
|
||||
- **Issue**: Dashboard doesn't handle tasks with spaces in folder names
|
||||
- **Impact**: Medium - task names may display incorrectly
|
||||
- **Fix**: Escape special characters in task names
|
||||
@@ -0,0 +1,8 @@
|
||||
# Bug Report: Dashboard Implementation
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: Minor
|
||||
- **Issue**: Filter bar doesn't update column headers immediately when filtered
|
||||
- **Impact**: Low - columns still show all tasks
|
||||
- **Fix**: Re-render board after filter changes
|
||||
@@ -0,0 +1,13 @@
|
||||
# Doc Review: Dashboard Implementation
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: Missing
|
||||
- **Issue**: README.md doesn't document the filter bar keyboard shortcuts
|
||||
- **Impact**: Low - users won't know how to use filters
|
||||
- **Fix**: Add filter bar shortcuts to README
|
||||
|
||||
### Finding 2: Missing
|
||||
- **Issue**: README.md doesn't explain how scope detection works
|
||||
- **Impact**: Low - users won't know the difference between framework and project mode
|
||||
- **Fix**: Add scope detection explanation to README
|
||||
@@ -0,0 +1,16 @@
|
||||
# Implementation: Dashboard
|
||||
|
||||
## Summary
|
||||
The dashboard has been implemented with all core features.
|
||||
|
||||
## Changes
|
||||
- Created core modules: scope, task, board, stats, timeline, refresh
|
||||
- Created UI components: header, board, card, detail_panel, stats_view, timeline_view, filter_bar, search_bar
|
||||
- Created main application: app.py
|
||||
- Created configuration management: config.py
|
||||
- Created color themes: themes.py
|
||||
|
||||
## Tests
|
||||
- Dashboard renders correctly for all views
|
||||
- Task discovery works with various artifact combinations
|
||||
- Scope detection works for framework and project modes
|
||||
@@ -0,0 +1,15 @@
|
||||
# Contract: Dashboard Implementation
|
||||
|
||||
## Goal
|
||||
Implement the interactive terminal dashboard for the automaton framework.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [x] Board view works
|
||||
- [x] Statistics view works
|
||||
- [x] Timeline view works
|
||||
- [x] Filter bar works
|
||||
- [x] Search bar works
|
||||
- [x] Auto-refresh works
|
||||
|
||||
## Stop Condition
|
||||
CONTRACT_MET
|
||||
@@ -0,0 +1,37 @@
|
||||
# VERDICT: Dashboard Implementation
|
||||
|
||||
## Summary
|
||||
The dashboard implementation is mostly complete and functional.
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: Minor
|
||||
- **Status**: Accepted
|
||||
- **Issue**: Filter bar doesn't update column headers immediately
|
||||
- **Resolution**: Will be fixed in a follow-up task
|
||||
|
||||
### Finding 2: Medium
|
||||
- **Status**: Accepted
|
||||
- **Issue**: Dashboard doesn't handle inotify permission errors
|
||||
- **Resolution**: Will be fixed in a follow-up task
|
||||
|
||||
### Finding 3: Medium
|
||||
- **Status**: Accepted
|
||||
- **Issue**: Dashboard doesn't handle tasks with spaces in folder names
|
||||
- **Resolution**: Will be fixed in a follow-up task
|
||||
|
||||
## Doc Review Findings
|
||||
|
||||
### Finding 1: Missing
|
||||
- **Status**: Accepted
|
||||
- **Issue**: README.md doesn't document filter bar shortcuts
|
||||
- **Resolution**: Will be fixed in a follow-up task
|
||||
|
||||
### Finding 2: Missing
|
||||
- **Status**: Accepted
|
||||
- **Issue**: README.md doesn't explain scope detection
|
||||
- **Resolution**: Will be fixed in a follow-up task
|
||||
|
||||
## VERDICT: PASS
|
||||
|
||||
All findings are minor and accepted. The dashboard is functional and ready for use.
|
||||
@@ -0,0 +1,7 @@
|
||||
# Bug Report: Dashboard Bad Implementation
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: Critical
|
||||
- **Issue**: Dashboard crashes when rendering empty task list
|
||||
- **Impact**: High - dashboard is unusable
|
||||
@@ -0,0 +1,4 @@
|
||||
# Implementation: Dashboard Bad
|
||||
|
||||
## Summary
|
||||
This implementation is deliberately broken to test the dashboard's handling of failed tasks.
|
||||
@@ -0,0 +1,12 @@
|
||||
# Contract: Dashboard Bad Implementation
|
||||
|
||||
## Goal
|
||||
This is a deliberately broken implementation to test the dashboard's handling of failed tasks.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] All tests pass (will not)
|
||||
- [ ] No bugs (there are bugs)
|
||||
- [ ] Documentation complete (it's not)
|
||||
|
||||
## Stop Condition
|
||||
CONTRACT_MET
|
||||
@@ -0,0 +1,15 @@
|
||||
# VERDICT: Dashboard Bad Implementation
|
||||
|
||||
## Summary
|
||||
This implementation has critical issues and must be fixed.
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: Critical
|
||||
- **Status**: Rejected
|
||||
- **Issue**: Dashboard crashes when rendering empty task list
|
||||
- **Resolution**: Fix crash before re-implementation
|
||||
|
||||
## VERDICT: FAIL
|
||||
|
||||
The implementation has critical issues that must be fixed.
|
||||
@@ -0,0 +1,21 @@
|
||||
# Research: Dashboard Spec
|
||||
|
||||
## Goal
|
||||
Build an interactive terminal dashboard.
|
||||
|
||||
## Requirements
|
||||
- Scope-aware context detection
|
||||
- Kanban board view
|
||||
- Task cards
|
||||
- Detail panel
|
||||
- Statistics view
|
||||
- Timeline view
|
||||
- Filtering and search
|
||||
- Keyboard navigation
|
||||
- Auto-refresh
|
||||
- Configuration
|
||||
- Color themes
|
||||
- Sub-task visualization
|
||||
|
||||
## Stop Condition
|
||||
CONTRACT_MET
|
||||
@@ -0,0 +1,11 @@
|
||||
# Decomposition: Dashboard Sub-Task Test
|
||||
|
||||
## Sub-Tasks
|
||||
|
||||
### Wave 1 (Parallel)
|
||||
- subtask-a: Implement core scope detection
|
||||
- subtask-b: Implement task model and parsing
|
||||
|
||||
### Wave 2 (Dependent)
|
||||
- subtask-c: Implement Kanban board logic
|
||||
- subtask-d: Implement UI components
|
||||
@@ -0,0 +1,12 @@
|
||||
# Contract: Dashboard Sub-Task Test
|
||||
|
||||
## Goal
|
||||
Test sub-task visualization in the dashboard.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [x] Sub-tasks are discovered and displayed
|
||||
- [x] Sub-task progress is shown as [3/5]
|
||||
- [x] Sub-task details are shown in the detail panel
|
||||
|
||||
## Stop Condition
|
||||
CONTRACT_MET
|
||||
@@ -0,0 +1,11 @@
|
||||
# Parent Specification: Sub-Task A
|
||||
|
||||
## Sub-Task Scope
|
||||
Implement core scope detection for the dashboard.
|
||||
|
||||
## Parent Task
|
||||
subtask-parent
|
||||
|
||||
## VRAM Configuration
|
||||
- Auto-detect: Yes
|
||||
- Target context: 16k tokens
|
||||
@@ -0,0 +1,7 @@
|
||||
# Research: Sub-Task A - Scope Detection
|
||||
|
||||
## Goal
|
||||
Implement scope detection for the dashboard.
|
||||
|
||||
## Stop Condition
|
||||
CONTRACT_MET
|
||||
@@ -0,0 +1,6 @@
|
||||
# VERDICT: Sub-Task A - Scope Detection
|
||||
|
||||
## Summary
|
||||
Scope detection is working correctly.
|
||||
|
||||
## VERDICT: PASS
|
||||
@@ -0,0 +1,11 @@
|
||||
# Parent Specification: Sub-Task B
|
||||
|
||||
## Sub-Task Scope
|
||||
Implement task model and parsing for the dashboard.
|
||||
|
||||
## Parent Task
|
||||
subtask-parent
|
||||
|
||||
## VRAM Configuration
|
||||
- Auto-detect: Yes
|
||||
- Target context: 16k tokens
|
||||
@@ -0,0 +1,7 @@
|
||||
# Research: Sub-Task B - Task Model
|
||||
|
||||
## Goal
|
||||
Implement task model and parsing for the dashboard.
|
||||
|
||||
## Stop Condition
|
||||
CONTRACT_MET
|
||||
@@ -1,285 +0,0 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>Agent Framework • 3D Sphere</title>
|
||||
<script src="https://cdn.tailwindcss.com"></script>
|
||||
<script src="https://cdnjs.cloudflare.com/ajax/libs/three.js/r128/three.min.js"></script>
|
||||
<style>
|
||||
body { margin: 0; overflow: hidden; }
|
||||
#canvas-container { width: 100%; height: 100vh; }
|
||||
.label {
|
||||
position: absolute;
|
||||
color: #a1a1aa;
|
||||
font-size: 11px;
|
||||
pointer-events: none;
|
||||
text-shadow: 0 1px 3px rgba(0,0,0,0.9);
|
||||
font-family: ui-monospace, monospace;
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body class="bg-zinc-950 text-zinc-200">
|
||||
<div class="absolute top-6 left-6 z-10">
|
||||
<div>
|
||||
<div class="text-2xl font-semibold tracking-tight">Agent Framework</div>
|
||||
<div class="text-xs text-zinc-500">3D Phase Visualization</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div id="canvas-container"></div>
|
||||
|
||||
<!-- Details Panel -->
|
||||
<div class="absolute top-6 right-6 w-80 bg-zinc-900/90 backdrop-blur border border-zinc-800 rounded-3xl p-6 z-20 hidden" id="details-panel">
|
||||
<div id="details-content"></div>
|
||||
</div>
|
||||
|
||||
<div class="absolute bottom-6 left-6 text-[10px] text-zinc-500 z-10">
|
||||
Drag to rotate • Scroll to zoom • Click nodes
|
||||
</div>
|
||||
|
||||
<script>
|
||||
const phaseData = {
|
||||
"Research": { prompt: "prompts/research.md", outputs: "SPEC.md", description: "Explores requirements and produces a clear specification." },
|
||||
"Design": { prompt: "prompts/design.md", outputs: "DESIGN.md", description: "Produces data models, flows, architecture, and risks." },
|
||||
"Implement": { prompt: "prompts/implement.md", outputs: "Code + tests", description: "Builds the solution using SPEC.md and DESIGN.md." },
|
||||
"Bug Find": { prompt: "prompts/bug_finder.md", outputs: "BUG_REPORT.md", description: "Adversarially discovers bugs and spec deviations." },
|
||||
"Disprove": { prompt: "prompts/disprover.md", outputs: "DISPROVALS.md", description: "Attempts to disprove findings from the bug report." },
|
||||
"Referee": { prompt: "prompts/referee.md", outputs: "VERDICT.md", description: "Judges implementation and compares Bug Finder vs Disprover." },
|
||||
"Onboard": { prompt: "prompts/onboarding.md", outputs: "Framework files", description: "Initializes the agent framework in a project." },
|
||||
"Orchestrate": { prompt: "prompts/orchestrate.md", outputs: "Recommendation", description: "Suggests the next logical phase based on state." },
|
||||
"Compaction": { prompt: "prompts/compaction.md", outputs: "Clean rules", description: "Consolidates and deduplicates rules." }
|
||||
};
|
||||
|
||||
const phases = Object.keys(phaseData);
|
||||
let scene, camera, renderer;
|
||||
let nodes = [];
|
||||
let lines = [];
|
||||
let raycaster, mouse;
|
||||
|
||||
function initThreeJS() {
|
||||
const container = document.getElementById('canvas-container');
|
||||
|
||||
scene = new THREE.Scene();
|
||||
camera = new THREE.PerspectiveCamera(60, window.innerWidth / window.innerHeight, 0.1, 1000);
|
||||
renderer = new THREE.WebGLRenderer({ antialias: true, alpha: true });
|
||||
renderer.setSize(window.innerWidth, window.innerHeight);
|
||||
container.appendChild(renderer.domElement);
|
||||
|
||||
// Sphere
|
||||
const sphereGeometry = new THREE.SphereGeometry(2.4, 64, 64);
|
||||
const sphereMaterial = new THREE.MeshPhongMaterial({
|
||||
color: 0x18181b,
|
||||
wireframe: true,
|
||||
transparent: true,
|
||||
opacity: 0.12
|
||||
});
|
||||
const sphere = new THREE.Mesh(sphereGeometry, sphereMaterial);
|
||||
scene.add(sphere);
|
||||
|
||||
// Lighting
|
||||
const ambientLight = new THREE.AmbientLight(0xffffff, 0.6);
|
||||
scene.add(ambientLight);
|
||||
const pointLight = new THREE.PointLight(0xffffff, 0.9);
|
||||
pointLight.position.set(10, 10, 10);
|
||||
scene.add(pointLight);
|
||||
|
||||
camera.position.z = 6.5;
|
||||
|
||||
raycaster = new THREE.Raycaster();
|
||||
mouse = new THREE.Vector2();
|
||||
|
||||
// Create nodes + connections
|
||||
createNodesOnSphere();
|
||||
createConnections();
|
||||
|
||||
// Events
|
||||
window.addEventListener('resize', onWindowResize);
|
||||
container.addEventListener('click', onClick);
|
||||
|
||||
// Orbit controls (simple)
|
||||
let isDragging = false;
|
||||
let previousMouseX = 0, previousMouseY = 0;
|
||||
|
||||
container.addEventListener('mousedown', (e) => {
|
||||
isDragging = true;
|
||||
previousMouseX = e.clientX;
|
||||
previousMouseY = e.clientY;
|
||||
});
|
||||
window.addEventListener('mouseup', () => isDragging = false);
|
||||
|
||||
container.addEventListener('mousemove', (e) => {
|
||||
if (!isDragging) return;
|
||||
const deltaMove = { x: e.clientX - previousMouseX, y: e.clientY - previousMouseY };
|
||||
|
||||
const deltaRotation = new THREE.Quaternion().setFromEuler(
|
||||
new THREE.Euler(deltaMove.y * 0.004, deltaMove.x * 0.004, 0, 'XYZ')
|
||||
);
|
||||
|
||||
sphere.quaternion.multiplyQuaternions(deltaRotation, sphere.quaternion);
|
||||
|
||||
nodes.forEach(n => n.position.applyQuaternion(deltaRotation));
|
||||
lines.forEach(line => {
|
||||
line.geometry.dispose();
|
||||
const newGeo = new THREE.BufferGeometry().setFromPoints([
|
||||
line.userData.from.position,
|
||||
line.userData.to.position
|
||||
]);
|
||||
line.geometry = newGeo;
|
||||
});
|
||||
|
||||
previousMouseX = e.clientX;
|
||||
previousMouseY = e.clientY;
|
||||
});
|
||||
|
||||
container.addEventListener('wheel', (e) => {
|
||||
camera.position.z += e.deltaY * 0.008;
|
||||
camera.position.z = Math.max(3.5, Math.min(11, camera.position.z));
|
||||
});
|
||||
|
||||
animate();
|
||||
}
|
||||
|
||||
function createNodesOnSphere() {
|
||||
const radius = 2.4;
|
||||
const nodeCount = phases.length;
|
||||
|
||||
phases.forEach((phase, i) => {
|
||||
const phi = Math.acos(-1 + (2 * i) / nodeCount);
|
||||
const theta = Math.sqrt(nodeCount * Math.PI) * phi;
|
||||
|
||||
const x = radius * Math.sin(phi) * Math.cos(theta);
|
||||
const y = radius * Math.sin(phi) * Math.sin(theta);
|
||||
const z = radius * Math.cos(phi);
|
||||
|
||||
const geometry = new THREE.SphereGeometry(0.11, 16, 16);
|
||||
const material = new THREE.MeshPhongMaterial({
|
||||
color: 0x3b82f6,
|
||||
emissive: 0x1e40af
|
||||
});
|
||||
const nodeMesh = new THREE.Mesh(geometry, material);
|
||||
nodeMesh.position.set(x, y, z);
|
||||
nodeMesh.userData = { phase: phase };
|
||||
scene.add(nodeMesh);
|
||||
nodes.push(nodeMesh);
|
||||
|
||||
// Label
|
||||
const label = document.createElement('div');
|
||||
label.className = 'label';
|
||||
label.textContent = phase;
|
||||
document.getElementById('canvas-container').appendChild(label);
|
||||
nodeMesh.userData.label = label;
|
||||
});
|
||||
}
|
||||
|
||||
function createConnections() {
|
||||
const connections = [
|
||||
["Research", "Design"],
|
||||
["Design", "Implement"],
|
||||
["Implement", "Bug Find"],
|
||||
["Bug Find", "Disprove"],
|
||||
["Disprove", "Referee"],
|
||||
["Referee", "Implement"],
|
||||
["Onboard", "Research"],
|
||||
["Orchestrate", "Research"],
|
||||
["Orchestrate", "Design"],
|
||||
["Orchestrate", "Implement"],
|
||||
["Orchestrate", "Bug Find"],
|
||||
["Orchestrate", "Referee"],
|
||||
["Compaction", "Orchestrate"]
|
||||
];
|
||||
|
||||
const lineMaterial = new THREE.LineBasicMaterial({
|
||||
color: 0x3f3f46,
|
||||
transparent: true,
|
||||
opacity: 0.6
|
||||
});
|
||||
|
||||
connections.forEach(([fromName, toName]) => {
|
||||
const fromNode = nodes.find(n => n.userData.phase === fromName);
|
||||
const toNode = nodes.find(n => n.userData.phase === toName);
|
||||
if (!fromNode || !toNode) return;
|
||||
|
||||
const geometry = new THREE.BufferGeometry().setFromPoints([
|
||||
fromNode.position,
|
||||
toNode.position
|
||||
]);
|
||||
const line = new THREE.Line(geometry, lineMaterial);
|
||||
line.userData = { from: fromNode, to: toNode };
|
||||
scene.add(line);
|
||||
lines.push(line);
|
||||
});
|
||||
}
|
||||
|
||||
function onClick(event) {
|
||||
const rect = renderer.domElement.getBoundingClientRect();
|
||||
mouse.x = ((event.clientX - rect.left) / rect.width) * 2 - 1;
|
||||
mouse.y = -((event.clientY - rect.top) / rect.height) * 2 + 1;
|
||||
|
||||
raycaster.setFromCamera(mouse, camera);
|
||||
const intersects = raycaster.intersectObjects(nodes);
|
||||
|
||||
if (intersects.length > 0) {
|
||||
const phase = intersects[0].object.userData.phase;
|
||||
showDetails(phase);
|
||||
}
|
||||
}
|
||||
|
||||
function showDetails(phase) {
|
||||
const panel = document.getElementById('details-panel');
|
||||
const data = phaseData[phase];
|
||||
|
||||
panel.classList.remove('hidden');
|
||||
panel.innerHTML = `
|
||||
<div class="flex justify-between items-start mb-4">
|
||||
<div>
|
||||
<div class="text-xl font-semibold">${phase}</div>
|
||||
<div class="text-xs text-blue-400 font-mono mt-1">${data.prompt}</div>
|
||||
</div>
|
||||
<button onclick="hideDetails()" class="text-zinc-500 hover:text-white text-xl">×</button>
|
||||
</div>
|
||||
|
||||
<div class="text-sm leading-relaxed text-zinc-300">${data.description}</div>
|
||||
|
||||
<div class="mt-6">
|
||||
<div class="text-xs uppercase tracking-wider text-zinc-500 mb-2">Outputs</div>
|
||||
<div class="text-sm font-mono bg-zinc-950 px-4 py-2 rounded-2xl border border-zinc-800">${data.outputs}</div>
|
||||
</div>
|
||||
`;
|
||||
}
|
||||
|
||||
function hideDetails() {
|
||||
document.getElementById('details-panel').classList.add('hidden');
|
||||
}
|
||||
|
||||
function onWindowResize() {
|
||||
camera.aspect = window.innerWidth / window.innerHeight;
|
||||
camera.updateProjectionMatrix();
|
||||
renderer.setSize(window.innerWidth, window.innerHeight);
|
||||
}
|
||||
|
||||
function animate() {
|
||||
requestAnimationFrame(animate);
|
||||
renderer.render(scene, camera);
|
||||
|
||||
// Update labels
|
||||
nodes.forEach(node => {
|
||||
if (node.userData.label) {
|
||||
const vector = node.position.clone();
|
||||
vector.project(camera);
|
||||
const x = (vector.x * 0.5 + 0.5) * window.innerWidth;
|
||||
const y = (-vector.y * 0.5 + 0.5) * window.innerHeight;
|
||||
node.userData.label.style.left = `${x}px`;
|
||||
node.userData.label.style.top = `${y}px`;
|
||||
}
|
||||
});
|
||||
}
|
||||
|
||||
function init() {
|
||||
initThreeJS();
|
||||
}
|
||||
|
||||
window.onload = init;
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
-216
@@ -1,216 +0,0 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>Agent Framework • Routes</title>
|
||||
<script src="https://cdn.tailwindcss.com"></script>
|
||||
<script src="https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.min.js"></script>
|
||||
<style>
|
||||
.mermaid { font-family: ui-sans-serif, system-ui, sans-serif; }
|
||||
.node { cursor: pointer; }
|
||||
</style>
|
||||
</head>
|
||||
<body class="bg-zinc-950 text-zinc-200">
|
||||
<div class="max-w-7xl mx-auto p-8">
|
||||
<div class="flex items-center justify-between mb-8">
|
||||
<div>
|
||||
<h1 class="text-3xl font-semibold tracking-tight">Agent Framework</h1>
|
||||
<p class="text-zinc-400 mt-1">Phase relationships and routing</p>
|
||||
</div>
|
||||
<div class="text-xs px-3 py-1.5 bg-zinc-900 rounded-full border border-zinc-800">~/.agent-framework</div>
|
||||
</div>
|
||||
|
||||
<div class="grid grid-cols-1 lg:grid-cols-12 gap-6">
|
||||
|
||||
<!-- Graph -->
|
||||
<div class="lg:col-span-8 bg-zinc-900 rounded-3xl p-8 border border-zinc-800">
|
||||
<div class="flex items-center justify-between mb-6">
|
||||
<div class="text-sm font-medium text-zinc-400">Phase Graph</div>
|
||||
<div class="text-[10px] text-zinc-500">Click any node for details</div>
|
||||
</div>
|
||||
<div id="mermaid-diagram" class="overflow-auto"></div>
|
||||
</div>
|
||||
|
||||
<!-- Details -->
|
||||
<div class="lg:col-span-4 bg-zinc-900 rounded-3xl p-8 border border-zinc-800">
|
||||
<div class="text-sm font-medium text-zinc-400 mb-4">Phase Details</div>
|
||||
<div id="details-panel">
|
||||
<div class="text-zinc-500 text-sm">Select a phase to view its prompt, outputs, and dependencies.</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<script>
|
||||
const phaseData = {
|
||||
"Research": {
|
||||
prompt: "prompts/research.md",
|
||||
outputs: "SPEC.md",
|
||||
description: "Explores requirements and produces a clear specification.",
|
||||
dependsOn: []
|
||||
},
|
||||
"Design": {
|
||||
prompt: "prompts/design.md",
|
||||
outputs: "DESIGN.md",
|
||||
description: "Produces data models, user flows, architecture, MVP scope, and risks.",
|
||||
dependsOn: ["SPEC.md"]
|
||||
},
|
||||
"Implement": {
|
||||
prompt: "prompts/implement.md",
|
||||
outputs: "Code + tests",
|
||||
description: "Builds the solution using SPEC.md and DESIGN.md.",
|
||||
dependsOn: ["SPEC.md", "DESIGN.md"]
|
||||
},
|
||||
"Bug Find": {
|
||||
prompt: "prompts/bug_finder.md",
|
||||
outputs: "BUG_REPORT.md",
|
||||
description: "Adversarially discovers bugs and spec deviations.",
|
||||
dependsOn: ["SPEC.md", "IMPLEMENTATION.md"]
|
||||
},
|
||||
"Disprove": {
|
||||
prompt: "prompts/disprover.md",
|
||||
outputs: "DISPROVALS.md",
|
||||
description: "Attempts to disprove findings from the bug report.",
|
||||
dependsOn: ["BUG_REPORT.md"]
|
||||
},
|
||||
"Referee": {
|
||||
prompt: "prompts/referee.md",
|
||||
outputs: "VERDICT.md",
|
||||
description: "Judges implementation quality and compares Bug Finder vs Disprover.",
|
||||
dependsOn: ["SPEC.md", "BUG_REPORT.md", "DISPROVALS.md"]
|
||||
},
|
||||
"Onboard": {
|
||||
prompt: "prompts/onboarding.md",
|
||||
outputs: "Framework files + report",
|
||||
description: "Initializes the agent framework in a new or existing project.",
|
||||
dependsOn: []
|
||||
},
|
||||
"Orchestrate": {
|
||||
prompt: "prompts/orchestrate.md",
|
||||
outputs: "Next phase recommendation",
|
||||
description: "Analyzes current state and suggests the logical next phase.",
|
||||
dependsOn: ["All task artifacts"]
|
||||
},
|
||||
"Compaction": {
|
||||
prompt: "prompts/compaction.md",
|
||||
outputs: "Consolidated rules",
|
||||
description: "Cleans up and deduplicates rules and routing logic.",
|
||||
dependsOn: ["RULES.md", "AGENT.md"]
|
||||
}
|
||||
};
|
||||
|
||||
const diagram = `
|
||||
graph TD
|
||||
Research --> Design
|
||||
Design --> Implement
|
||||
|
||||
Implement --> BugFind[Bug Find]
|
||||
BugFind --> Disprove
|
||||
Disprove --> Referee
|
||||
|
||||
Referee -->|pass| Implement
|
||||
Referee -->|fail| BugFind
|
||||
|
||||
Onboard --> Research
|
||||
Orchestrate -.-> Research
|
||||
Orchestrate -.-> Design
|
||||
Orchestrate -.-> Implement
|
||||
Orchestrate -.-> BugFind
|
||||
Orchestrate -.-> Referee
|
||||
|
||||
Compaction -.-> Orchestrate
|
||||
|
||||
classDef core fill:#1e40af,stroke:#3b82f6,color:#fff
|
||||
classDef quality fill:#854d0e,stroke:#ca8a04,color:#fff
|
||||
classDef meta fill:#334155,stroke:#64748b,color:#fff
|
||||
|
||||
class Research,Design,Implement core
|
||||
class BugFind,Disprove,Referee quality
|
||||
class Onboard,Orchestrate,Compaction meta
|
||||
`;
|
||||
|
||||
function renderDiagram() {
|
||||
const container = document.getElementById('mermaid-diagram');
|
||||
container.innerHTML = `<pre class="mermaid">${diagram}</pre>`;
|
||||
|
||||
mermaid.initialize({
|
||||
startOnLoad: false,
|
||||
theme: 'dark',
|
||||
flowchart: { curve: 'basis', padding: 20 }
|
||||
});
|
||||
|
||||
mermaid.run().then(() => {
|
||||
attachClickHandlers();
|
||||
});
|
||||
}
|
||||
|
||||
function attachClickHandlers() {
|
||||
const nodes = document.querySelectorAll('#mermaid-diagram .node');
|
||||
|
||||
nodes.forEach(node => {
|
||||
let label = node.textContent.trim();
|
||||
// Handle Mermaid's internal node IDs
|
||||
if (label.includes('BugFind')) label = 'Bug Find';
|
||||
if (!phaseData[label]) return;
|
||||
|
||||
node.style.cursor = 'pointer';
|
||||
node.addEventListener('click', () => showDetails(label));
|
||||
});
|
||||
}
|
||||
|
||||
function showDetails(phase) {
|
||||
const panel = document.getElementById('details-panel');
|
||||
const data = phaseData[phase];
|
||||
if (!data) return;
|
||||
|
||||
let html = `
|
||||
<div>
|
||||
<div class="text-xl font-semibold text-white">${phase}</div>
|
||||
<div class="text-xs text-zinc-500 mt-1 font-mono">${data.prompt}</div>
|
||||
</div>
|
||||
|
||||
<div class="mt-6">
|
||||
<div class="text-[10px] uppercase tracking-[1px] text-zinc-500 mb-2">Description</div>
|
||||
<div class="text-sm leading-relaxed">${data.description}</div>
|
||||
</div>
|
||||
|
||||
<div class="mt-6">
|
||||
<div class="text-[10px] uppercase tracking-[1px] text-zinc-500 mb-2">Outputs</div>
|
||||
<div class="inline-block text-sm font-mono bg-zinc-950 border border-zinc-800 px-4 py-2 rounded-xl">${data.outputs}</div>
|
||||
</div>
|
||||
`;
|
||||
|
||||
if (data.dependsOn.length > 0) {
|
||||
html += `
|
||||
<div class="mt-6">
|
||||
<div class="text-[10px] uppercase tracking-[1px] text-zinc-500 mb-2">Depends On</div>
|
||||
<div class="flex flex-wrap gap-2">
|
||||
${data.dependsOn.map(f =>
|
||||
`<span class="text-xs px-3 py-1 bg-zinc-950 border border-zinc-800 rounded-full">${f}</span>`
|
||||
).join('')}
|
||||
</div>
|
||||
</div>
|
||||
`;
|
||||
}
|
||||
|
||||
panel.innerHTML = html;
|
||||
}
|
||||
|
||||
function init() {
|
||||
renderDiagram();
|
||||
|
||||
// Show Research by default after a short delay
|
||||
setTimeout(() => {
|
||||
const panel = document.getElementById('details-panel');
|
||||
if (panel.innerHTML.includes('Select a phase')) {
|
||||
showDetails('Research');
|
||||
}
|
||||
}, 900);
|
||||
}
|
||||
|
||||
window.onload = init;
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
Reference in New Issue
Block a user