Run a development task
Execute one bounded software change from task source to evidence and developer acceptance.
A TCAF task is one bounded unit of engineering work. If the requested outcome is broader than one coherent task, use tcaf plan first.
Start the task
tcaf task --target <project> --request "<requested change>"
Or use an existing task source:
tcaf task --target <project> --input <task-source>
Required sequence
- Identify the authoritative task source.
- Inspect only the project evidence and implementation pertinent to the task.
- Resolve material ambiguity before implementation.
- Produce a Task Contract with objective, allowed edit surface, preserved areas, acceptance criteria, checks and stop conditions.
- Obtain developer review and approval.
- The AI can execute the approved work inside that boundary, using the smallest coherent preservation-first change.
- Run or report the smallest relevant checks.
- Present the diff, evidence, limitations and outcome.
- Wait for developer acceptance before status updates or commit.
The developer remains in control
The developer can edit code directly, replace an approach, clarify the request, stop the AI or perform part of the work manually. Those edits become current repository state and must be re-read before the AI continues.
Scope discipline
A task does not authorize opportunistic refactoring, unrelated dependency changes, broad formatting, silent backlog updates or Git operations.
If new work is discovered, classify it as a clarification, correction, amendment, separate task or blocker instead of absorbing it silently.
Verification
Only executed evidence supports a verified claim. Pending or developer-run checks must remain visible.
If repository or project state changes later outside the current run, use tcaf sync before relying on stale state.