Skip to content
TCAFTask-Contract AI Development Framework
TCAF 0.3.3

How TCAF works

Follow the complete TCAF operating path from a developer request to bounded implementation, evidence and review.

Content: completeWorkflow: —

TCAF provides one operating discipline for different AI models, tools, project states and task sources. It does not ask the developer to hand over software development to an autonomous agent. It gives the AI a precise, temporary assignment while the developer or team remains free to work directly on any part of the codebase.

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

The public operations

The runtime exposes a small set of public operations:

tcaf bootstrap --target <target> [--request <text> | --input <path>]
tcaf adopt --target <target>
tcaf task --target <target> --request <bounded-request>
tcaf run <agent-id> --target <target>

They cover four distinct needs:

  • bootstrap establishes a new project from an idea, analysis, scaffold, roadmap or first task;
  • adopt inspects an existing project and creates the canonical project evidence required by TCAF;
  • task prepares a bounded development task from an explicit request;
  • run invokes a registered public agent directly when that agent already represents the desired operation.

The developer chooses the operation and the target. The runtime resolves the internal framework modules.

The operating pipeline

Every operation follows the same high-level path:

  1. Operation selection — the developer chooses what kind of work is being requested.
  2. Registry resolution — TCAF resolves the public operation or agent ID.
  3. Agent manifest loading — the manifest declares the exact modules, target policy and expected output.
  4. Pertinent context loading — only the framework instructions and project evidence relevant to that operation are loaded.
  5. Single-target binding — the run is bound to exactly one project or target path.
  6. Adapter selection — the same core behavior is transported through Codex, Cline, a generic CLI or another supported host.
  7. Run Envelope generation — the model receives the operation, target, constraints, evidence requirements and review gate.
  8. Developer review — the developer reviews the proposed contract, output or file before the next consequential step.

The internal framework remains outside the target project. Project evidence and framework instructions are deliberately separated.

From request to Task Contract

A request is not automatically permission to edit everything that might help achieve the goal.

Before implementation, TCAF turns the request and pertinent project state into a Task Contract. Depending on the task, the contract identifies:

  • objective and requested behavioral difference;
  • allowed edit surface;
  • files, behaviors or systems that must remain unchanged;
  • existing functions, methods, utilities or patterns to reuse;
  • forbidden refactors, dependency changes or collateral work;
  • acceptance criteria;
  • one to three relevant checks or developer-run procedures;
  • stop conditions, blockers and review expectations.

The contract is an authorization boundary, not merely a summary of the request.

Implementation remains developer-owned

TCAF does not reduce the developer to an approver who only accepts or rejects AI output.

The developer or team may at any moment:

  • inspect or change the code directly;
  • design the architecture;
  • replace an implementation decision;
  • add tests or diagnostics;
  • interrupt the AI run;
  • amend, reject or replace the Task Contract;
  • perform part of the task manually and let the AI continue from the new state.

Manual developer changes become authoritative project state. The AI must reread and integrate with them rather than restoring an earlier snapshot or treating them as interference.

Preservation-first implementation

When modifying implemented software, the agent should extend the local implementation language rather than substitute its preferred solution.

That means reusing relevant:

  • methods and service boundaries;
  • shared utilities and helper modules;
  • validations, guards and permission checks;
  • error handling and logging conventions;
  • state, dependency injection and data-access patterns;
  • naming, typing and folder conventions;
  • public interfaces, tests and verification commands.

A theoretically cleaner alternative does not authorize a rewrite. Refactoring remains possible, but it must be required by the task, declared in the contract or approved separately.

Read the full preservation-first principle.

Verification and evidence

The agent must distinguish work produced from work verified.

A normal task uses the smallest relevant verification set, usually one to three checks. Depending on the tool, the agent may execute those checks or report exact DEVELOPER_RUN commands and manual procedures.

The final outcome should make clear:

  • what changed;
  • what was actually checked;
  • what could not be checked;
  • whether the result is ready for developer review;
  • whether a blocker, partial result or failure remains;
  • what the developer should do next.

Plausible output is not treated as evidence.

The adapter changes transport, not authority

Different tools require different interaction envelopes:

  • Codex currently supports verified native invocation;
  • Cline currently uses a verified manual-envelope procedure with explicit INSPECT, WRITE and VALIDATE steps;
  • generic CLI and generic chat transports have different access constraints.

The adapter may change how instructions reach the model, but it must not expand the target, task scope or permissions defined by the core operation.

Why this is not vibe coding

Vibe coding commonly starts from intent and lets the model infer architecture, scope and implementation choices while the user reacts to the result.

TCAF starts from the opposite ownership model:

  • the repository and its existing decisions are evidence;
  • the developer remains the active engineer;
  • the AI receives bounded work;
  • changes are integrated rather than opportunistically rewritten;
  • verification is reported separately from generation;
  • every consequential transition returns to human review.

The purpose is not to slow development. It is to make AI acceleration compatible with real engineering responsibility and a codebase that must remain understandable after the current session ends.

Continue from here