gitea
05c76852a2
CI / build (push) Has been cancelled
State Enforcement (v2.0):
- .state file as single source of truth for task phase
- Approval gates for research, decomposition, design, test_design
- status.py --transition refuses illegal phase transitions
- status.py --validate-folder detects out-of-order artifacts
- status.py --audit checks all tasks for violations
- status.py --create-task is the only valid way to create tasks
- Pre-v2.0 tasks without .state are UNTRACKED -- all commands refuse them
- New --upgrade command bootstraps .state files for existing tasks
Project Scoping:
- --project flag added to all status.py commands across 16+ files
- _find_project_dir errors instead of silently falling back to ~/.automaton/
- --scope-check marks framework files OUT_OF_SCOPE when working on a project
- Dashboard handlers use stored project_root instead of re-detecting from CWD
- Prompts reference ~/.automaton/scripts/vram_detect.py (not {project}/.automaton/)
Harness Integration:
- status.py --can-edit now supports project-level checks (no --task required)
- --can-edit --file checks file scope without --task
- --json output for machine-readable harness integration
- opencode plugin (plugins/automaton-guard/plugin.ts) intercepts edit/write
- Git pre-commit hook (scripts/git-hooks/pre-commit) blocks commits without task
- Formal integration contract (contracts/harness-integration.md)
Other:
- upgrade.sh delegates to status.py --upgrade instead of manual heuristics
- Phase prompts reference --project {project} for multi-project scoping
- 200 tests passing (14 new)
1.6 KiB
1.6 KiB
Bug Report: project-scoping-enforcement
Summary
Critical process violation: the agent performed all implementation work before creating a task, completely bypassing the framework's workflow enforcement.
Bugs Found
Bug 1: No framework self-enforcement prevents untasked work (Critical)
- Severity: Critical
- Location: Agent behavior, not code
- Description: The agent identified 7 scoping issues, then directly implemented all fixes across 20+ files without first creating a task through
status.py --create-task. The task was only created after all work was done, as a retrospective documentation exercise. - Reproduction: Any agent session where the user asks for work to be done. Nothing prevents the agent from editing files directly.
- Suggested Fix: This is a behavioral fix, not a code fix. The agent should always create a task first for any non-trivial work, then implement within that task's phase constraints.
Bug 2: Process gap — no automated check that edits have a corresponding task
- Severity: Medium
- Location: Framework enforcement model
- Description:
status.py --can-editonly checks if a task is in the right phase for code edits. But it doesn't verify that the files being edited are within that task's scope. An agent can create task "foo" for project A, then edit files in project B without any task at all. - Suggested Fix: Future enhancement —
--can-editcould optionally check that the files being modified are relevant to the task's SPEC.md or DESIGN.md scope.
Score
+10 (Bug 1 is a process violation worth documenting; Bug 2 is a future enhancement)