Adopt an existing project
Inspect an existing repository, preserve its code and history, and establish only the project evidence TCAF needs.
Use adopt when the software already exists but TCAF has not yet inspected the project.
Adoption observes the project. It does not modernize, refactor or rewrite it.
Run adoption
tcaf adopt --target <existing-project>You can also provide relevant existing material with --request or --input when useful.
What TCAF reads
Only the evidence needed to understand the project, such as:
- repository structure and application boundaries;
- dependency and build manifests;
- existing test, lint and validation commands;
- architecture and implementation patterns;
- CI or deployment evidence;
- existing documentation, backlog and task sources;
- known limitations.
Existing code, history and documentation are preserved. Existing documents remain source evidence rather than being rewritten just to fit a TCAF template.
What adoption may derive
When useful, TCAF can propose a separate canonical project state that maps the evidence needed for later operations. It should create only what is missing or genuinely useful.
Absence is evidence: TCAF must not invent a test suite, architecture, database or delivery capability that the repository does not show.
Adoption does not authorize implementation
Unless the developer opens a separate task, adoption must not change application code, dependencies, history, backlog completion or remote systems.
Review the proposed state and validate the target when appropriate:
tcaf validate --target <existing-project>Structural validation checks consistency; it does not prove every statement is semantically true.
After adoption
Use tcaf plan if the next feature needs decomposition, or tcaf task when the next bounded change is already known.