How TCAF works

TCAF uses one simple rule: the AI receives only the authority needed for the current operation. The repository, project evidence and developer decisions define the context; chat memory does not.

The developer owns the software. TCAF defines how AI assistance enters that work without acquiring independent authority over it.

The five main operations

tcaf bootstrap --target <target> [--request <text> | --input <material>]
tcaf adopt --target <target> [--request <text> | --input <material>]
tcaf plan --target <target> (--request <feature> | --input <specification>)
tcaf task --target <target> (--request <bounded-request> | --input <task-source>)
tcaf sync --target <target> [--request <new-information> | --input <material>]

They answer five different questions:

• bootstrap — what project state do we need to start safely?
• adopt — what actually exists in this repository today?
• plan — how should this broader feature or outcome be decomposed?
• task — what exactly is the AI authorized to change now?
• sync — what changed outside the current run, and what project state needs reconciliation?

tcaf run <agent-id> remains available for direct registered-agent invocation, but it is an advanced operation rather than the normal starting point.

The delivery path

A typical project does not use all five operations every time.

1. Start or adopt — use bootstrap for a new project or adopt for an existing one.
2. Plan when needed — use plan when the requested outcome is too broad for one bounded task.
3. Execute one task — use task to create the Task Contract, review it and then let the AI execute the approved work inside that boundary.
4. Verify — distinguish executed checks from pending or manual verification.
5. Sync when reality changed — use sync after manual developer edits, new specifications, external changes or other out-of-run updates that affect project state or planned work.

This is Software Delivery Governance around AI-assisted work, not autonomous project ownership.

Inside one task

The task loop stays deliberately short:

request → repository inspection → Task Contract → developer approval → bounded execution → verification evidence → developer acceptance

The Task Contract is the authorization boundary. If the work would need to move outside it, the AI stops or asks for an amendment instead of expanding scope silently.

Specifications and repository evidence

TCAF is spec-driven, but “specification” does not mean one mandatory TCAF file format.

Useful source evidence can already exist as:

• requirements or functional analysis;
• README and architecture notes;
• plans and roadmaps;
• backlog or issues;
• code, tests and configuration;
• direct developer requests.

TCAF reads the evidence relevant to the current operation. When a separate canonical state is useful, it can be derived from that material without rewriting the source documents first.

Preservation-first execution

When changing existing software, the expected result is:

NEW BEHAVIOR = EXISTING VERIFIED BEHAVIOR + REQUESTED DELTA

The AI should reuse local methods, utilities, services, guards, conventions and tests where appropriate. A “cleaner” solution does not authorize an unrelated rewrite.

Verification is evidence

Generated code is not proof that the task is complete. TCAF separates:

• checks that were actually executed;
• checks the developer still needs to run;
• limitations or blockers;
• the final acceptance decision.

A structural validation result is also not semantic truth by itself.

Adapters change transport, not authority

Codex, Cline and other hosts can transport the same operating model differently. A more capable host may perform more of the approved work directly, but it does not receive a wider scope.

Current adapter coverage is documented separately in Validation coverage and Select an adapter.

Continue from here

• Quick Start for the shortest path.
• Choose your path when you know the project state but not the command.
• The Task Contract for the authorization boundary.