Keep the whole job together
A commit records a code change, but a useful agent history needs more context than that. It should connect the change to its original purpose and the evidence used to justify it.
The planned audit record is a product requirement. This website’s demo is illustrative and does not create real agent job records.
The proposed record
For each job, preserve the following:
- The goal, scope, and permission policy.
- The source material and time it was checked.
- The proposed brief or change set.
- Validation results and unresolved issues.
- The reviewed revision and approval decision.
- The deployment reference and outcome-review date.
The record should make it possible to answer what changed, why it changed, who or what approved it, and which version is live.
Keep the diff small
A focused change is easier to review than a mixed collection of copy edits, component refactors, and dependency updates.
If the agent discovers a different problem while working, it should record a follow-up rather than silently expand the original job. That keeps the approval meaningful.
Plan the recovery before publication
For the first Git-based website workflow, the intended recovery path is to return to a known good revision through the normal deployment process.
Some tasks have consequences that a code rollback cannot undo. An email that has been sent or data changed in another system needs a different recovery plan. Those actions should not be smuggled into a content workflow.
A rollback is not the end of the review
After recovering from an unwanted change, the useful question is why the system allowed it. The fix may belong in the brief, the permission boundary, the tests, or the review process.
We want repeated mistakes to improve the agent workflow rather than merely increase the amount of cleanup work around it.