commit-changeslisted

# Commit changes A commit is a durable claim about the repository. Commit only approved and verified work, and make each commit one complete change a reviewer could understand and revert on its own. ## When to use - The ledger decision for the task is `finalize` (`python3 scripts/tm.py task decide <id> finalize`) and committing is in scope. - A task is being finalized and its change should be recorded. ## When not to use - The work is unverified or unapproved. Prove it with `verify-evidence` and get approval first. - Committing was not authorized. Committing is a consequential action; a worker leaves the tree for the primary unless its brief says otherwise. - The project commits itself — a release bot, a changelog generator, or a commit hook. Follow the project's process instead of bypassing it. ## Inputs - The approved, verified change and the scope that was approved. - The project's commit convention (from `load-project-context`). - The evidence that the change works (from `verify-evidence`). ## Before you commit 1. Confirm the gate. The task's recorded decision is `finalize` (`python3 scripts/tm.py task show <id>`); an `approve` alone does not authorize a commit. 2. Load the project's conventions with `load-project-context`: its commit format, scope vocabulary, and any commit hooks. The project's convention wins over the default below. 3. Confirm the evidence. Every change in the commit should be backed by `verify-evidence`; never commit a k