Update documentation or status

Documentation and status updates are real project work, but they should remain distinguishable from application implementation.

Use a documentation-only Task Contract

Define:

• which canonical documents may change;
• the implementation evidence that supports the update;
• statuses or decisions that may be reconciled;
• historical information that must remain intact;
• validation commands;
• an explicit exclusion of application code unless separately authorized.

Common uses

• update project status after accepted work;
• record an architectural decision;
• reconcile backlog completion;
• correct paths or capability descriptions after adoption review;
• document a verified limitation;
• add evidence from manual validation.

Preserve evidence and history

Do not rewrite old decisions to make the project appear cleaner. Add the current decision, supersession or correction explicitly. Distinguish facts observed in the repository from plans and proposals.

Validate

Run:

tcaf validate --target <project>

Also review the documentation diff for accidental scope expansion, removed history and unsupported claims.

Keep Git operations separate

A documentation update does not automatically authorize commit or push. Present the result for review and wait for explicit acceptance.