Skip to content
TCAFTask-Contract AI Development Framework
TCAF 0.3.3

Task sources

Learn how TCAF accepts work from different authoritative sources without forcing every project into one backlog model.

Content: completeWorkflow: framework aligned

TCAF does not require every project to manage work through the same tracker or repository file. A task can originate from different sources as long as the source is explicit, authoritative for that project and sufficient to create a bounded Task Contract.

The task source answers a simple question:

Which request, issue, analysis or decision authorizes this unit of work?

Supported source patterns

Typical task sources include:

  • a direct developer request;
  • a repository backlog item;
  • a GitHub Issue or another external tracker item;
  • a functional or technical analysis;
  • a bug report with reproduction evidence;
  • a project roadmap or planning document;
  • one open task declared during bootstrap;
  • a follow-up created from an accepted previous task.

The framework can represent other sources when the project manifest identifies them clearly.

The project decides what is canonical

TCAF should not create a competing backlog when the project already has an authoritative source.

Examples:

  • If GitHub Issues is the official backlog, project documentation should reference it rather than silently creating a second list.
  • If a repository backlog file is authoritative, issue trackers may remain supporting context.
  • If the developer issues a direct bounded request, a backlog entry is not required merely to satisfy the framework.
  • If an analysis defines a larger body of work, the current Task Contract should still authorize only one reviewable unit.

The project manifest records where authoritative task information lives.

Preserve source identity

When a source has an identifier, retain it in the contract and final result.

Examples:

GitHub Issue: #42
Backlog item: B-016
Analysis section: Authentication / Password reset
Direct request: 2026-07-31 developer instruction

This connection helps reviewers trace the implementation back to its origin without copying the entire source into every document.

Source content is not automatically the contract

A backlog item or issue may be incomplete, outdated or too broad for direct implementation. TCAF reads the source, inspects pertinent project evidence and creates a Task Contract that exposes the operational interpretation.

The contract may clarify:

  • the exact behaviour to implement now;
  • assumptions supported by the repository;
  • unresolved decisions;
  • affected and preserved areas;
  • acceptance criteria;
  • checks;
  • exclusions.

The source remains authoritative for intent, while the approved Task Contract becomes authoritative for the current implementation boundary.

Conflicting sources

When sources disagree, the agent must not choose silently.

Examples include:

  • an issue requests behaviour that contradicts current canonical documentation;
  • a backlog item describes a feature already implemented differently;
  • an analysis assumes an API that the repository does not contain;
  • a direct request conflicts with an accepted architectural constraint.

The correct outcome is to expose the contradiction, identify the affected decision and stop for developer guidance. The developer may correct the source, override it explicitly, amend project documentation or define a separate task.

Source freshness

A recently modified file is not automatically the freshest authority, and an old document is not automatically obsolete. Determine freshness from content, project rules and declared canonical roles.

During pertinent analysis, check:

  • whether the source describes current or planned behaviour;
  • whether its status is open, completed, superseded or historical;
  • whether repository evidence already satisfies part of the request;
  • whether another document is declared canonical for the same decision;
  • whether the developer has provided a newer instruction.

Do not infer completion or priority from filenames alone.

Direct developer requests

A direct request is a valid source when it is sufficiently bounded or can be converted into a reviewable contract.

The framework should not force the developer to create administrative artifacts before every small task. However, the contract still needs enough information to prevent hidden scope expansion.

For a very small request, the source record can remain concise:

Source: direct developer request
Objective: correct the validation message for an empty email field

Large analyses and roadmaps

An analysis or roadmap can authorize planning, but it should not automatically authorize implementation of every described capability.

The agent should separate:

  • current project state;
  • desired future state;
  • confirmed decisions;
  • proposals;
  • open questions;
  • the single unit selected for implementation now.

This prevents planning documents from becoming an unlimited mandate.

Changes during an active task

A new instruction received after approval must be classified against the current contract.

It may be:

  • a clarification;
  • a correction of contract non-compliance;
  • a local technical adaptation;
  • an amendment;
  • a separate new task;
  • a blocker or contradiction.

The fact that the developer mentioned it during the same conversation does not automatically make it part of the existing source boundary.

What the final response should reference

The result should identify the source when that helps traceability, especially for backlog items and issues. It should also distinguish:

  • source intent;
  • approved contract;
  • actual implementation;
  • verification evidence;
  • any remaining source work not included in the current task.

This keeps task completion honest without forcing the source itself to become an implementation log.