53 lines
1.6 KiB
Markdown
53 lines
1.6 KiB
Markdown
# Tasks
|
|
|
|
Tasks are the handoff contract between agents. They are not a real-time queue; sync scripts move them between PC and VPS through Git.
|
|
|
|
## Status Values
|
|
|
|
- `draft`: Created but not ready to claim.
|
|
- `ready`: Ready for the assigned role.
|
|
- `claimed`: Agent has started the task.
|
|
- `blocked`: Agent cannot proceed and wrote the blocker.
|
|
- `done`: Executor has completed the task and produced evidence.
|
|
- `accepted`: Verifier or ORCHESTRATOR accepted the task.
|
|
|
|
## Ownership
|
|
|
|
- ORCHESTRATOR creates and updates task intent.
|
|
- Executors update only tasks assigned to their role.
|
|
- Verifiers update verification tasks and may mark executor tasks accepted after review.
|
|
- CORRECTION may mark a task blocked if it detects drift or unsafe execution.
|
|
|
|
## G0 Boundary
|
|
|
|
- G0 is complete only for requirements, role boundaries, and acceptance criteria.
|
|
- Until G1 baseline evidence is independently verified, executor tasks are read-only discovery tasks.
|
|
- No PC/VPS configuration mutation, service restart, network exposure change, approval action, or deployment change is authorized by a task unless ORCHESTRATOR explicitly opens a later gate.
|
|
- The `smartmotor.cloud` filing-review freeze is a hard constraint for all VPS tasks.
|
|
- Git polling sync plus task files are the MVP communication layer; future work should upgrade or supplement this with asynchronous notification or a coordinator after baseline work is stable.
|
|
|
|
## File Naming
|
|
|
|
Use:
|
|
|
|
```text
|
|
T<ID>-short-topic.md
|
|
```
|
|
|
|
Example:
|
|
|
|
```text
|
|
T3-PC-baseline.md
|
|
```
|
|
|
|
## Required Fields
|
|
|
|
Each task should include:
|
|
|
|
- Status
|
|
- Owner
|
|
- Dependencies
|
|
- Scope
|
|
- Required evidence
|
|
- Stop conditions
|