Skip to content
TCAFTask-Contract AI Development Framework
TCAF 0.3.3

Choose your path

Select the correct TCAF workflow from the state of the project and the kind of work you need to perform.

Content: completeWorkflow: —

TCAF uses one operating model, but the correct starting operation depends on what already exists and what you need to achieve.

Choose the path from the current project state, not from the tool you plan to use. Codex, Cline and other adapters transport the workflow; they do not determine it.

You are starting a new project

Use bootstrap when the target does not yet have the canonical project evidence required by TCAF and you want to establish a new product or codebase.

tcaf bootstrap --target <target> --request <starting-request>

A bootstrap can start from:

  • a product idea;
  • a complete or partial functional analysis;
  • an initialized repository or scaffold;
  • an existing roadmap;
  • one first open task;
  • a proposed backlog to be reviewed by the developer.

The target does not need to be a mature Git repository before the operation begins. The developer still reviews architecture, planning assumptions and proposed project documents before implementation proceeds.

Continue to Bootstrap a new project.

You have an existing project that has not adopted TCAF

Use adopt when the software already exists but TCAF does not yet have reliable canonical evidence about its architecture, capabilities, rules and workflow.

tcaf adopt --target <project-path>

Adoption is inspection-first. It should observe the repository, identify actual paths and capabilities, create or reconcile the canonical project documents and stop at a developer review gate.

The adoption operation must not quietly:

  • change application code;
  • refactor working areas;
  • update dependencies;
  • implement backlog work;
  • commit or push changes.

Continue to Adopt an existing project.

The project is already ready and you need to perform one bounded task

Use task when the project evidence is available and the next unit of work is known.

tcaf task --target <project-path> --request <bounded-request>

The request may originate from:

  • a repository backlog;
  • a GitHub Issue;
  • an open developer request;
  • a functional or technical analysis;
  • a bug report;
  • a documentation or status discrepancy.

TCAF performs pertinent analysis, produces a Task Contract and returns to developer review before implementation authority expands.

Continue to Run a development task.

The task is active and the request changes

Do not automatically enlarge the current task.

First classify the new information as one of the following:

  • clarification — it explains the existing requirement without changing its authorized result;
  • correction — it brings the work back into compliance with the current contract;
  • local technical adaptation — it changes implementation detail without changing scope or acceptance;
  • amendment — it changes the authorized task and requires explicit developer approval;
  • separate task — it is valuable but independent work;
  • blocker or contradiction — it prevents safe continuation;
  • developer edit — it changes the current project state and must be reread and preserved.

Continue to Changes during an active task.

The code and the recorded project state disagree

Use the reconciliation workflow when implementation, backlog, issue status or project documentation no longer describe the same reality.

Reconciliation should determine what is actually implemented, what remains open and which records must be updated. It should not invent feature completion from labels or assume that recent file timestamps prove current behavior.

Continue to Reconcile project status.

The work has been reviewed and accepted

Commit is a separate developer-authorized operation. A successful implementation or verification result does not automatically grant permission to:

  • stage files;
  • update backlog items;
  • close issues;
  • create a commit;
  • tag a release;
  • push to a remote.

Continue to Commit accepted work.

Choose the adapter only after choosing the workflow

The adapter determines how the Run Envelope reaches the model:

  • use codex for the verified native Codex integration;
  • use cline for the verified manual-envelope procedure;
  • use generic-cli when a command-line host can receive the envelope but cannot edit directly;
  • use generic-chat only when the host can maintain persistent framework availability and bind the target reliably.

Read Select an adapter before the first run.

When you are unsure

Prefer the narrower path:

  • adopt before assuming an existing project is ready;
  • inspect before writing;
  • create one bounded task before generating a broad implementation plan;
  • stop for review rather than silently converting uncertainty into scope.

TCAF is designed to make the next safe decision explicit. It is not designed to maximize autonomous activity.