Task lifecycle

The TCAF task lifecycle separates decision, implementation, verification and project administration. This prevents a model from treating one request as permission to analyse, rewrite, validate, update status, commit and publish without intermediate review.

The normal lifecycle is:

Task source
→ pertinent analysis
→ Task Contract
→ developer review and approval
→ preservation-first implementation
→ checks and evidence
→ outcome-first response
→ developer review
→ optional reconciliation
→ optional commit or other final operation

Not every task needs every optional closing action, but consequential transitions remain explicit.

1. Identify the task source

Start from the declared source of work: a direct request, backlog item, issue, analysis or another authoritative source.

The source establishes intent. It does not automatically define the implementation boundary.

2. Perform pertinent analysis

Inspect only what is needed to understand the current behaviour and authorize the task safely.

Pertinent analysis may include:

• relevant files and nearby implementation;
• architecture and project rules;
• current capability and limitations;
• tests and verification commands;
• canonical documentation;
• developer changes already present;
• contradictions or missing evidence.

The agent should not perform an unbounded repository audit for every small request. It should also not skip inspection and rely on assumptions.

3. Produce the Task Contract

Convert intent and evidence into an explicit contract containing objective, boundaries, preserved areas, acceptance criteria, checks and stop conditions.

The contract should expose uncertainty instead of hiding it behind confident language.

4. Developer review and approval

The developer verifies that the contract describes the right work.

Possible decisions include:

• approve;
• request a targeted correction;
• narrow or expand the proposed surface;
• split the task;
• resolve a contradiction;
• reject the task;
• perform part of the work manually.

No consequential implementation should begin merely because the contract was generated.

5. Preservation-first implementation

After approval, the agent implements only the authorized behaviour.

It should:

• re-read files before changing them;
• integrate with the current repository state;
• reuse local methods, utilities, guards and patterns;
• preserve unrelated behaviour;
• avoid opportunistic refactoring;
• stop when new evidence invalidates the contract.

The developer remains free to edit any area directly. Those edits become current state for the next agent action.

6. Handle changes during the task

New information must be classified rather than absorbed silently.

A change may be:

• clarification;
• correction of contract non-compliance;
• local technical adaptation;
• amendment;
• separate task;
• blocker or contradiction;
• collateral issue to record for later.

A clarification may require only a note. An amendment requires renewed approval. A new objective normally becomes a separate task.

7. Run or report checks

Verification should use the smallest relevant set of meaningful checks, commonly one to three.

Checks may include:

• focused automated tests;
• type checking;
• linting or compilation where relevant;
• a targeted manual UI or integration check;
• structural validation such as tcaf validate.

The response must distinguish:

• checks actually executed by the agent;
• checks reported for the developer to run;
• checks unavailable because of tool limitations;
• failed or incomplete checks.

8. Return an outcome-first response

The first line should state the current outcome, such as PASS, READY FOR CHECK, PARTIAL, BLOCKED or FAIL.

The response then reports only what the developer needs to decide the next action:

• result obtained;
• changed files or areas;
• executed checks and outcomes;
• manual checks still required;
• deviations or limitations;
• precise next developer action.

Routine success should remain compact. Blockers, deviations, amendments and unresolved decisions require more explanation.

9. Developer review of the result

The developer reviews the actual implementation and evidence, not just the agent’s summary.

The developer may:

• accept the work;
• run manual verification;
• request a correction;
• modify the code directly;
• amend the task;
• reject part of the implementation;
• decide that a follow-up belongs in a separate task.

An agent-reported PASS does not remove the human review gate.

10. Optional reconciliation

Backlog, project documentation, capability status or an external issue may need updating after accepted work.

Reconciliation is separate because the implementation result and the project’s recorded state can diverge. The update should reflect actual accepted evidence, not merely the original plan.

Do not mark unrelated roadmap items complete or rewrite historical documentation opportunistically.

11. Optional commit and publication actions

Commit, tag, push, merge, release and deployment are separate authorized operations.

A completed implementation does not automatically authorize them. The developer decides when the work is accepted and which repository operation follows.

Lifecycle states are not conversation states

The task does not become approved because the conversation continued, and it does not become complete because the agent stopped writing.

Explicit state matters:

• proposed contract;
• approved contract;
• implementation in progress;
• ready for manual check;
• blocked;
• accepted;
• reconciled;
• committed.

Keeping these states distinct makes the workflow portable across tools and chat sessions.

Restarting after interruption

When a tool or session fails, resume from project evidence and the approved contract rather than model memory.

Before continuing:

1. inspect the current repository state;
2. identify developer or tool changes already applied;
3. confirm the active contract and approval state;
4. determine completed and remaining work;
5. repeat checks affected by the interruption.

This is how TCAF maintains continuity without depending on one conversation’s memory.