The visible feature was only the surface
Commit logs are implementation-centric and can lead release authors to omit user impact, invent compatibility, or choose the wrong comparison boundary.
The system also had to respect concrete constraints. Tag/version/range ambiguity can materially change the release. Only user-visible changes supported by commits, diffs, issues, or changelogs belong in notes. Creating/editing a GitHub release is a remote mutation distinct from drafting.
My role covered agent workflow design and automation engineering, with responsibility for agent workflow, validation automation, and packaging.
I turned the constraints into boundaries
Git/tag/diff evidence collector; release-note rules and drafting workflow; optional GitHub release adapter with explicit output/validation report.
Resolve target and comparison boundary before prose.
Separate breaking changes from ordinary improvements and qualify inferred impact.
Keep drafting read-only and gate remote release creation independently.
The key decision: Resolve target and comparison boundary before prose.
The implementation had to prove the model
I delivered the work across the full path: Built release evidence collection. Codified note structure and evidence rules. Implemented uncertainty and authorization checkpoints. Packaged portable installers and tests for release behavior.
The result is concrete: Agents can turn repository history into scoped notes. Exclude unsupported names/compatibility/test claims. Flag breaking changes. Hand off final notes or an authorized release URL with evidence.
The senior engineering lesson was that solving the visible workflow is only half the job. The architecture must also make constraints, failure modes, evidence, and ownership explicit enough for the next change to remain safe.