feat(aidd-dev): commit implementation by phase category

[alexsoyes]

🎯 What & why

Commit each phase category as one unit, without a commit per step.
Keep the skill instructions concise.

🛠️ How it works

• Commit rules follow the user request or VCS policy.
• Execution gates phase done on assertion; final validation gates implemented.
• Authoring rules avoid redundant self-links and template boilerplate.

🧪 How to verify

Run pnpm exec lefthook run pre-commit.

⚠️ Heads-up

PR #708 also edits implementation actions.

🔗 Linked issue

Refs #413

✅ I certify

• I DO CERTIFY I READ EACH LINE OF THE PULL REQUEST BECAUSE I AM A SOFTWARE ENGINEER, NOT A AI PUPPY.

[waewoo]

Nice improvement over committing every phase/step.

I have one question about the commit unit itself. Should commit boundaries necessarily follow the AIDD plan structure (### categories / phases), or should they primarily follow logical changes?

For example, a small feature may go through several AIDD phases/categories and update multiple aidd_docs artifacts, while still representing a single coherent change from a Git perspective. In that case, preserving category boundaries can still result in several small commits that do not provide much additional review or revert value.

I see AIDD phases/categories primarily as execution boundaries for the agent, while Git commits are history/review boundaries. Those boundaries do not necessarily have to match.

Would it make sense for after feature to allow all related implementation, tests, documentation, and AIDD status updates to land in a single coherent commit when they form one logical change, while keeping multiple commits when the feature actually contains independently reviewable or revertible changes?

In other words, could the rule be closer to one commit per coherent logical change, with the plan structure guiding execution but not necessarily dictating Git history?