Skip to content
TCAFTask-Contract AI Development Framework
TCAF 0.4.0 · public preview

Choose your path

Pick the TCAF 0.4.0 operation that matches the current project state and the next decision you need to make.

Choose from the current project state, not from the AI tool you plan to use. Adapters transport the workflow; they do not decide it.

New project → bootstrap

Use bootstrap when you are starting a project and want TCAF to organize the material you already have into the minimum useful project state.

tcaf bootstrap --target <project-path> --request "<starting request>"
tcaf bootstrap --target <project-path> --input <existing-material>

Ordinary specifications, notes, plans and architecture material remain source evidence. They do not need TCAF-specific preprocessing.

Continue to Bootstrap a new project.

Existing project → adopt

Use adopt when working software already exists but TCAF has not yet inspected it.

tcaf adopt --target <project-path>

Adoption is inspection-first. It preserves application code, history and existing documentation while establishing only the project evidence that is actually needed.

Continue to Adopt an existing project.

Broad feature or outcome → plan

Use plan when the requested work is too broad to execute safely as one task.

tcaf plan --target <project-path> --request "<feature or outcome>"

Planning proposes dependencies, task boundaries, open decisions and the next executable work. It does not implement code, write Task Contracts or change project state.

Continue to Plan a feature or change.

One clear change → task

Use task when the next unit of work is already known.

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

TCAF inspects the pertinent evidence, prepares a Task Contract and waits for developer approval before consequential implementation.

Continue to Run a development task.

Project changed outside the current run → sync

Use sync after manual developer edits, a new specification, an external change or any out-of-run repository change that can affect documented state or planned work.

tcaf sync --target <project-path>

Sync first inspects and proposes. It does not overwrite developer work automatically and it does not implement features.

Continue to Sync project state.

The active task itself changed

Do not silently enlarge the current Task Contract. A clarification may stay inside the task; a material scope change needs an amendment or a separate task.

The developer can also edit the code directly at any time. The AI must re-read and preserve the new repository state before continuing.

Work accepted → commit remains separate

Successful implementation does not automatically authorize staging, commit, tag, push or remote tracker changes. Those remain separate developer-authorized actions.

Continue to Commit accepted work.

When unsure

Prefer the smallest operation that answers the current question:

  • inspect before writing;
  • plan before forcing a broad feature into one task;
  • task before implementation;
  • sync before trusting stale project state;
  • stop for developer review instead of converting uncertainty into scope.