Introduction

TCAF is a governance-first, spec-driven framework for controlled AI software delivery. It implements Task-Contract Development: an approach that integrates spec-driven planning, agentic/harness execution and software delivery governance into explicit, bounded and verifiable units of change.

TCAF constrains AI execution, not developer authority.

The idea in one minute

TCAF keeps a few things explicit:

specifications and repository evidence describe what exists and what should change;
broader work can be planned before it is split into executable tasks;
each consequential task receives a Task Contract with objective, boundaries, checks and stop conditions;
the AI can execute the approved work inside that boundary;
developer changes and repository state remain authoritative;
verification evidence is separated from claims;
project state can be synchronized after manual, external or out-of-run changes.

The developer still owns architecture, technical decisions, code review, verification and final acceptance.

Task-Contract Development

TCAF uses the term Task-Contract Development for the operating approach that brings three complementary disciplines into one delivery model:

Spec-Driven Development — specifications and evidence define what should be built;
Agentic / Harness Engineering — runtime, adapters, context and rules make AI execution repeatable across tools;
Software Delivery Governance — planning, authorization boundaries, synchronization, verification and approval keep delivery controlled.

The Task Contract is where these concerns become operational for one unit of change: intent, execution authority, preservation, checks and stop conditions are made explicit before consequential implementation begins.

You do not need to learn these terms before using TCAF. They explain the design; the CLI remains small.

Five operations

tcaf bootstrap   # start a new project from the material you already have
tcaf adopt       # inspect and adopt an existing project
tcaf plan        # decompose a broader feature or outcome
tcaf task        # prepare one bounded Task Contract
tcaf sync        # re-read the project and reconcile approved state updates

Use only the operation that matches the next decision you need to make.

Why TCAF exists

AI coding tools are fast, but an open prompt can leave too much implicit. A model may infer missing requirements, expand scope, refactor working code, ignore local conventions or report checks it did not actually run.

TCAF replaces that implicit freedom with explicit evidence, a bounded authorization surface and developer review.

The goal is not more process. The goal is to make AI assistance easier to trust, review and continue across tools and sessions.

Repository-grounded, not chat-memory-driven

Ordinary project material can be source evidence: README files, specifications, architecture notes, plans, roadmaps, existing code and other repository documents. TCAF does not require you to rewrite them into a special format first.

When a separate canonical project state is useful, TCAF can derive it from that evidence. It is not a mandatory input format.

This keeps the workflow model-agnostic and reduces dependence on one chat history.

What TCAF is not

TCAF is not an autonomous project manager, a replacement for engineering judgement or a more structured form of vibe coding. The AI does not own architecture, scope or acceptance.

It executes delegated work. The developer or team owns the software.

Validation scope

TCAF 0.4.0 has semantic BLACK_BOX acceptance evidence for the covered core scenarios, including ordinary project material without expert manual preprocessing. That is a scoped claim, not a statement that every model, adapter, host, repository type or configuration has been tested.

See Validation coverage for the exact current boundary.