Skip to content
TCAFTask-Contract AI Development Framework
TCAF 0.3.3

Run a development task

Execute one bounded software change from task source to evidence and human acceptance.

Content: completeWorkflow: verified

A TCAF development task is one bounded unit of engineering work. It starts from a source selected by the developer and ends with evidence, limitations and an explicit acceptance decision.

Start the task

Use an inline request:

tcaf task --target <project> --request "<requested change>"

Or provide a file, directory, archive or supported host resource:

tcaf task --target <project> --input <task-source>

The command produces a Run Envelope. The host agent uses it to inspect the target and prepare the task.

Required sequence

  1. Identify the authoritative task source.
  2. Inspect only the project evidence and implementation pertinent to that task.
  3. Resolve material ambiguity before implementation.
  4. Produce a Task Contract with objective, allowed edit surface, preserved areas, acceptance criteria, checks and stop conditions.
  5. Obtain developer review and approval.
  6. Implement the smallest coherent change using local patterns and existing working behaviour.
  7. Run or report the smallest relevant checks.
  8. Present the diff, evidence, limitations and outcome label.
  9. Wait for developer acceptance before status reconciliation or commit.

Developer authority during the task

The developer can edit code directly, replace an approach, clarify the request, stop the agent or choose to perform part of the work manually. Those changes become current authoritative state and must be re-read before the agent continues.

Scope discipline

The task does not authorize:

  • opportunistic refactoring;
  • dependency upgrades not required by the approved change;
  • unrelated formatting;
  • broad test or infrastructure additions;
  • silent changes to backlog, documentation, Git history or remote systems.

When new work is discovered, classify it as clarification, local correction, amendment, separate task or blocker instead of absorbing it silently.

Verification and outcome

A normal task should use the smallest checks that materially support acceptance, often one to three targeted commands or manual procedures.

The final report must distinguish PASS, READY FOR CHECK, PARTIAL, BLOCKED and FAIL. Only executed evidence can support a verified claim.