Review and verification

Verification asks whether the implementation satisfies the approved contract. Review asks whether the developer accepts the implementation, evidence and remaining limitations.

They are related but not interchangeable.

A model can report evidence. It cannot replace engineering acceptance.

Evidence over confident claims

A response such as “the task is complete” is not evidence. TCAF expects the result to identify what was actually checked and what remains unknown.

Useful evidence may include:

• a focused automated test and its result;
• typecheck, build or lint output relevant to the changed area;
• structural validation;
• inspected diffs and affected files;
• a manual scenario performed by the developer;
• an observed UI or integration result;
• explicit confirmation that a required check could not be executed.

The framework does not require every possible check. It requires honest representation of the checks that matter for the contract.

Use the smallest meaningful checks

Normally choose one to three checks that cover the principal risks of the task.

Examples:

• unit test plus typecheck for a domain function change;
• targeted API test plus manual error-path verification;
• build plus one UI flow for a visual integration;
• tcaf validate --target <path> after project-document changes.

Large test suites may be appropriate when the project or contract requires them. They should not be run merely to create the appearance of thoroughness when a smaller focused set is more informative.

Automatic and manual verification

Tool limitations are expected. An agent may be unable to run terminal commands, open a browser, access credentials or reproduce an external dependency.

In that case it should report a developer check such as:

DEVELOPER_RUN: pnpm test -- customer-service.test.ts
MANUAL_CHECK: submit the form with an invalid email and confirm the inline error

The agent must not present an unexecuted command as passed.

Attribution matters

Each result should make clear who performed the verification:

• agent-executed;
• developer-executed;
• CI-executed;
• pending;
• unavailable.

This is especially important when a task moves across tools or sessions. Future reviewers need to know whether evidence was observed or merely requested.

Review the actual change

Human review should inspect the implementation and not rely exclusively on the final response.

Check that:

• the diff matches the approved objective;
• unrelated files and behaviours remain untouched;
• local methods, guards and utilities were reused appropriately;
• acceptance criteria are satisfied;
• tests or manual checks cover the important behaviour;
• no hidden dependency, refactor or configuration change entered the task;
• developer edits were preserved;
• reported limitations are accurate.

Review gates

A review gate is a deliberate stop before a consequential transition.

Typical gates include:

• after project adoption documents are generated;
• after a Task Contract is proposed;
• after implementation and checks;
• before reconciliation changes project status;
• before commit, push, merge, tag, release or deploy.

The gate allows the developer to approve, correct, reject, split or continue the work.

Verification does not prove everything

Passing tests demonstrate only what those tests cover. A successful build does not prove business correctness. A structural validator does not prove that documentation is factually accurate.

The final response should interpret evidence narrowly:

• typecheck PASS means the checked types compiled;
• target validation PASS means the required document structure is valid;
• a focused test PASS means the tested scenario passed;
• manual review is still required for behaviour not covered by those checks.

Failed checks

A failed required check produces FAIL unless the failure is clearly unrelated and the developer explicitly decides how to treat it.

Do not:

• delete a failing test to obtain PASS;
• weaken acceptance criteria after implementation;
• label the task complete while hiding the failure;
• broaden the task into an unrelated repair without approval.

Report the command, failure, affected contract criterion and next decision.

Incomplete verification

When implementation is complete but a required manual check remains, use READY FOR CHECK rather than PASS.

When only part of the approved work is implemented, use PARTIAL.

When verification cannot continue because of a missing decision, dependency or environment condition, use BLOCKED.

The outcome label should describe the current evidence, not the agent’s confidence.

Acceptance remains explicit

Even after successful verification, the developer decides whether to accept the work.

Acceptance may be withheld because:

• the behaviour is technically correct but not desirable;
• the implementation is inconsistent with local architecture;
• a manual check reveals a usability problem;
• the diff is larger than approved;
• project context changed during the task.

TCAF supports engineering judgement; it does not reduce acceptance to automated test status.

After acceptance

Accepted work may then authorize separate actions:

• update backlog or issue state;
• reconcile project documentation;
• create a commit;
• open a pull request;
• publish or deploy.

These actions should use the accepted implementation and evidence as their source, not assume that verification automatically authorized release operations.