Files
automaton/tasks/project-scoping-enforcement/SPEC.md
T
gitea 05c76852a2
CI / build (push) Has been cancelled
v2.0: state enforcement, project scoping, harness integration
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)
2026-06-15 14:16:46 -04:00

2.1 KiB

Project Scoping Enforcement

Goal

Fix scoping issues that arise when working on the automaton framework and another project using the framework simultaneously on the same machine. Also close the gap where pre-v2.0 tasks (without .state files) could be operated on by all commands, bypassing state enforcement entirely.

Requirements

  1. status.py must error (not silently fall back) when no project is detected and --project is not specified
  2. status.py --scope-check must mark framework files as OUT_OF_SCOPE when working on a project (not IN_SCOPE)
  3. Dashboard handler methods must use stored project_root instead of re-detecting from CWD
  4. All status.py command invocations in prompts and config files must include --project {project}
  5. _infer_state_from_artifacts must NOT be used as a silent fallback in operational commands — only --upgrade, --audit, and --validate-folder may use it
  6. All operational commands (--transition, --can-edit, --task, --approve, --claim) must refuse tasks without .state files
  7. --list must show tasks without .state as UNTRACKED, not silently bootstrap them
  8. New --upgrade command must bootstrap .state files for pre-v2.0 tasks
  9. upgrade.sh must call status.py --upgrade instead of manual shell heuristic bootstrapping
  10. All documentation and prompts must reference --upgrade for pre-v2.0 tasks

Acceptance Criteria

  • status.py errors when run from /tmp/ without --project
  • Framework files are OUT_OF_SCOPE when --project points to a project
  • Dashboard uses stored project_root for all handler methods
  • Every status.py command reference in prompts includes --project {project}
  • _find_project_dir no longer has cwd.name == ".automaton" false positive
  • _find_project_dir errors instead of silently falling back
  • --transition, --can-edit, --task, --claim refuse untracked tasks
  • --list shows UNTRACKED for tasks without .state
  • --upgrade --task {name} bootstraps .state for a single task
  • --upgrade (no --task) bootstraps all tasks missing .state
  • All 192 tests pass