Task Contract fields

The Task Contract defines permission. It is the reviewed boundary for one executable step, not a broad project plan.

Minimum fields

Task ID:
Type:
Goal:
Inspect:
Modify:
Allowed:
Forbidden:
Check mode:
Checks:
Stop:

Task ID

Uses the existing team or tracker convention. TCAF does not impose a universal identifier format and does not rename historical IDs.

Type

Classifies the work, such as feature, fix, documentation/status update, adoption-related task or another project-defined type.

Goal

One bounded outcome. When the primary goal changes, replace the contract or create a separate task.

Inspect

The complete relevant read surface expected before implementation. It should be narrow enough to avoid unnecessary context while covering the behaviour that can affect the task.

Modify

The complete edit surface. A file or area not listed is not authorized for modification.

Allowed

The complete permitted change types inside Modify, for example adding a local branch, adjusting an existing method or adding a targeted test when the project already supports it.

Forbidden

Explicit exclusions that narrow global or project permissions, such as no refactor, no dependency changes, no API changes or no Git operations.

Check mode

One of:

• DEVELOPER_RUN — default; provide exact commands and wait for reported results;
• AGENT_RUN — agent runs explicitly approved non-destructive checks;
• CI — pipeline provides evidence;
• MANUAL — developer verifies behaviour or UI;
• MIXED — combine only what is necessary.

Checks

The smallest relevant executable sequence, normally one to three checks including necessary prerequisites.

Stop

Conditions that require the agent to stop, report and request a decision rather than guessing or broadening scope.

Optional fields

Profile:
Source of truth:
Origin:
Expected behavior:
Acceptance criteria:
Open decisions:

Omit optional fields when they add no useful information. Minimum-first means short, not incomplete.

Approval and amendment

A complete contract approved by the developer authorizes that step only. It does not authorize later reconciliation, commit or push.

Changes to behaviour, acceptance criteria, edit surface, public interface, dependency, risk or explicit exclusions require a visible amendment and approval before implementation.

A scope-neutral clarification, correction required by the approved contract or local adaptation fully inside Modify and Allowed can remain in the same task when reported according to the framework rules.