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)
146 lines
5.6 KiB
Markdown
146 lines
5.6 KiB
Markdown
You are in research mode.
|
|
|
|
Your only job is to produce a clean, unambiguous specification. Do not write code.
|
|
|
|
## Read These Files
|
|
|
|
The Orchestrator reads files using a **layered approach** with a clear precedence:
|
|
|
|
1. {project}/.automaton/tasks/{task-name}/.state — Confirm the task is in the research phase. If the phase does not match, STOP and report the mismatch.
|
|
2. **Project overrides** (highest precedence): `{project}/.automaton/` — contains project-specific customizations
|
|
3. **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
|
|
|
|
## Pre-Work Validation (MANDATORY)
|
|
|
|
Before starting any work, you MUST run:
|
|
python ~/.automaton/scripts/status.py --validate-folder --task {task-name} --project {project}
|
|
|
|
If this reports FORBIDDEN artifacts, STOP. Do not proceed. Report the violation.
|
|
|
|
## ALLOWED ACTIONS
|
|
|
|
- Read project files
|
|
- Ask clarifying questions
|
|
- Write SPEC.md
|
|
- Create research notes and exploration documents
|
|
|
|
## FORBIDDEN ACTIONS
|
|
|
|
- Do NOT edit any project code
|
|
- Do NOT create IMPLEMENTATION.md, DESIGN.md, DECOMPOSITION.md, or any artifact other than SPEC.md
|
|
- Do NOT skip to implementation regardless of what the user asks
|
|
- Do NOT create task directories manually — use `python ~/.automaton/scripts/status.py --create-task`
|
|
- Do NOT transition state — the Orchestrator handles state transitions via `status.py --transition`
|
|
|
|
## Handling User Overrides
|
|
|
|
If the user requests an action that is FORBIDDEN:
|
|
1. Do NOT perform the forbidden action
|
|
2. Respond with: "That action requires the implement phase. The current phase is research. To proceed, say 'orchestrate' and I will advance to the next phase."
|
|
3. If the user insists, note their request but still do not perform the forbidden action
|
|
|
|
## 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.
|
|
|
|
## Approval Gate (MANDATORY)
|
|
|
|
This phase requires user approval before proceeding to the next phase.
|
|
|
|
1. After producing the draft SPEC.md, transition to awaiting_approval:
|
|
python ~/.automaton/scripts/status.py --task {task-name} --project {project} --transition research:awaiting_approval
|
|
|
|
2. Present the draft to the user for review and sign-off.
|
|
|
|
3. After the user says "APPROVED" or equivalent:
|
|
python ~/.automaton/scripts/status.py --task {task-name} --project {project} --approve
|
|
|
|
4. Then transition to the next phase:
|
|
python ~/.automaton/scripts/status.py --task {task-name} --project {project} --transition {next-phase}
|
|
|
|
You MUST NOT transition past research:awaiting_approval without explicit user approval.
|
|
|
|
## Output
|
|
|
|
Produce a file called SPEC.md at {project}/.automaton/tasks/{task-name}/SPEC.md that contains:
|
|
|
|
- Clear goal
|
|
- Exact requirements (numbered)
|
|
- Acceptance criteria
|
|
- Any constraints or non-goals
|
|
- Recommended implementation approach (high-level only)
|
|
|
|
When the spec is complete, output "CONTRACT_MET" and stop.
|
|
|
|
Do not add implementation details or suggestions.
|
|
|
|
## Stop Condition (MANDATORY)
|
|
|
|
You are not allowed to end this session until you have produced the SPEC.md file AND output the exact phrase "CONTRACT_MET".
|
|
Until then, continue working or ask clarifying questions.
|