Learn

GitHub Release Pattern

When the miss is release-quality related (for example "release notes missed npm-impacting runtime changes"), do all of the following:

1. Inspect commit range for the release tag (for example vX.Y.(Z-1)..vX.Y.Z).
2. Classify changes into:
   • npm package/runtime impact (src/, package.json, package-lock.json, README.md, openapi.yaml)
   • docs/site/process-only impact
3. Update GitHub release notes with an explicit NPM Package Impact section.
4. Include clear "changed/not changed" statements for API surface artifacts (notably openapi.yaml).
5. Verify by reading the release body after update.

Constraints

• Do not commit changes unless user explicitly asks.
• Do not change generated copies when a source-of-truth file exists.
• Do not perform destructive operations without explicit user approval.
• For release-note fixes, prefer updating the existing GitHub release over creating duplicate releases.