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)
15 lines
1.5 KiB
Markdown
15 lines
1.5 KiB
Markdown
# Adversarial Bug Report: Multi-Agent Support
|
|
|
|
## Deep Review
|
|
The multi-agent system is well-designed for file-system-based coordination. Single-agent mode has no overhead. Claim/release uses atomic writes. Work discovery correctly prioritizes tasks closer to completion.
|
|
|
|
## Potential Issues
|
|
1. **Agent identity is self-reported**: `--agent` is a command-line flag with no authentication. Any agent can claim to be any agent-id. In a trusted environment (single machine, same user), this is fine. In adversarial or distributed scenarios, this would need cryptographic signing.
|
|
|
|
2. **Lock file race on NFS/Linux**: The atomic rename pattern (`.state.lock.tmp` → `.state.lock`) is atomic on local filesystems but may not be atomic on NFS. The spec explicitly scopes this out ("file-based locks are sufficient for local agent coordination").
|
|
|
|
3. **Expired lock window**: Between lock expiry and overclaiming, there's a window where two agents could both see an expired lock and both try to claim. The atomic write pattern means only one wins, but the loser gets an error rather than a graceful retry message.
|
|
|
|
4. **No lock inheritance on sub-task creation**: When the coordinator creates a sub-task via `--create-task`, the sub-task is unclaimed by default. The coordinator must explicitly claim it on behalf of an agent. This is correct behavior but could be surprising.
|
|
|
|
## Verdict: PASS — the self-reported identity is a known design choice (trusted environment), not a security vulnerability in the intended threat model. |