Files

T

CI / build (push) Has been cancelled

Details

Archive completed tasks, add cleanup commands, self-documenting dashboard UI

- Archive 79 completed framework-dev tasks from tasks/ -> tasks/complete/
- status.py: add --cleanup-done and --install-cleanup-schedule commands
- Add scripts/automaton-cleanup.sh for periodic task archiving
- Dashboard: rename 'Background' tab -> 'Agent', 'Cleanup' agent -> 'Completed Task Archiver', remove redundant group headers and pill badges, dim inactive agent placeholders
- .rules.md: add Self-Documenting UI Names rule
- New tests: test_cleanup_done.py, expanded test_app.py and test_task.py

2026-06-24 22:43:33 -04:00

2.9 KiB

Raw Blame History

Adversarial Bug Report: task-status-reason

Summary

Deep-dive audit found 3 subtle issues: misleading red border on bug_find cards, redundant verdict parsing, and no status_reason propagation to subtasks.

Bugs Found

Bug 1: Red error border on bug_find task cards is misleading

Severity: Low
Location: automaton/dashboard/html/styles.css — .task-card-reason rule
Description: The .task-card-reason CSS uses border-left: 2px solid var(--error) for all three states (blocked, bug_find, adv_bug_find). But bug_find and adv_bug_find are normal workflow states, not errors. A green or neutral border would be more appropriate for non-terminal states.
Reproduction: Open any task in bug_find or adv_bug_find state — the reason banner shows a red border suggesting something is wrong, when it's expected behavior.
Suggested Fix: Use var(--warning) for bug_find states and reserve var(--error) for blocked only.

Bug 2: Redundant verdict parsing on every status_reason access

Severity: Low
Location: automaton/dashboard/core/task.py:136-175 — status_reason property
Description: status_reason calls parse_verdict_status() again for BLOCKED/DONE tasks, even though determine_task_state() already parsed the verdict to classify the state. For DONE, it doesn't re-parse (just returns "Verdict: PASS"), but for BLOCKED it re-reads the verdict content and re-parses. This is redundant but cheap given the small number of tasks.
Reproduction: Every time the dashboard renders, BLOCKED tasks trigger a second verdict parse just for the display string.
Suggested Fix: Cache the parsed verdict status on the Task object during discover_tasks(), e.g., a _verdict_status field that status_reason can reference instead of re-parsing.

Bug 3: Subtask state not visible in detail panel reason

Severity: Low
Location: automaton/dashboard/html/dashboard.js:236-241 — subtask list in detail panel
Description: Subtasks in the detail panel show only a verdict pass/fail indicator. Unlike parent tasks, blocked subtasks don't display their status_reason in the list. A blocked subtask just shows "✗" next to its name with no explanation of why.
Suggested Fix: For blocked subtasks, include the subtask's verdict status (FAIL/NEEDS_REVIEW) in the list item, or hover tooltip with the reason.

Bug 4: Fallthrough status_reason never reached, masks missing states

Severity: Low
Location: automaton/dashboard/core/task.py:175
Description: The fallthrough return f"In {self.state.value} phase" is dead code — every TaskState value is covered by explicit branches. If a new state is added (e.g., INTEGRATION_TEST), no compile-time error occurs and a vague message is shown. Contrast with Python enums which have no exhaustiveness checking.
Suggested Fix: Add # pragma: no cover or raise/log a warning if a new state goes unhandled.

2.9 KiB Raw Blame History