Make your changes commit-ready

Turn a working change into a committable change that reviewers and future readers can trust.

1. Review what you implemented

• Are all verification criteria and expected outcomes met?
• Is the implementation complete (no dummy data or placeholder stubs left)?
• Are all of the gjalla rules met?
• Does this elegantly build on top of / within the existing state/architecture/properties?
• Does it match the plan / gjalla spec?
• Are positive, negative, and edge cases saliently tested?
• Has the code review process been completed?

If the answer to any of these questions is no, determine what changes are needed. We absolutely cannot tolerate any whack-a-mole changes. It's better to take a step back and design the elegant and sustainable solution to any issues. If a tradeoff needs human review, you may prompt your user.

Once you can confidently answer 'yes', note what you verified (which suite ran, exit code, DoD items) so your change summary carries evidence, not just claims.

2. Present the process (the second human gate)

• Write a short change report for the human: the phases you went through, the evidence for each (reviews, test runs, DoD), and the system impact.