Phase 5 / Ep 28: Automated Conventional Commits

Today, your feature is finished. If you don't give the Agent standardized restriction instructions, when it tries to commit code on your behalf, it might leave a very perfunctory message in the commit history: "git commit -m 'fixed things'".

In the future, when you need to trace history or roll back a minor release, this will be an absolute nightmare! In the codex at the system root directory, we need to add a rule workflow exclusively governing the version control line: .agents/workflows/git-push.md:

1. Core Instructions of the Version God

# Strictly Controlled Git Commit Standards

If an automatic or proxy commit and publish action is triggered:
1. **Strict Conventional Commits Protocol Constraints**: Any changes must start with `feat: ` (feature), `fix: ` (bug fix), `chore: ` (miscellaneous build tasks), `refactor: `, etc.
2. You must integrate the extensive and complex information from today's `progress.md`. Generate an ultra-detailed commit description that includes why this approach was taken (why), rather than just what was changed.
3. Because you modify code very quickly, you are forced to use `git status` every time to see exactly which files were touched before initiating the packaged integration commit chain. Accidentally including and pushing unrelated files is strictly prohibited!

Now, when the Large Language Model receives your instruction: "Help me tidy up and push to the remote!" The records it generates on GitHub will be extremely elegant and systematically itemized. A commit record with excellent developer professionalism is born, and this god-tier little operation in your code history hasn't cost you a single extra minute of time or energy.