Summary Required, Commit Optional
A landing summary is the universal human interface to completed work. It says what was produced or changed, where it landed, which proof was checked, and which limitations remain. Without it, the event trail may be machine-complete and still useless to the next person.
A commit is valuable when the deliverable is repository-backed. It gives an immutable tree identity, author and time metadata, and a diff. Requiring one for every task encourages nonsense: empty commits for phone calls, receipt files for delivered documents, or private material copied into Git just to satisfy a gate.
Optional does not mean casually omitted. When scope names a repository change, the commit or an explicit reason for its absence belongs in the landing record. When scope names a non-code destination, the workshop should not ask for synthetic Git evidence.
The summary should be concise and factual, not a victory speech. Name the result, destination, tests or acceptance, review disposition, and residual risk. Claims that cannot be tied to evidence do not become safer because they are in the final paragraph.
Choose Evidence by Deliverable
Start from the authoritative destination, then choose proof. A commit hash is excellent evidence for source state and poor evidence that a meeting happened or a document was acknowledged.
Verification can require summary always and commit conditionally when the task contract declares a repository-backed result. That rule is stronger than either universal commit or universal commit omission.