Ensure generated SDK changes reach release notes

[sjmiller609]

Summary

Automatically makes every generated SDK change releasable. Explicit feat:, fix:, perf:, and revert: commit types are preserved; all other SDK-affecting merges are classified as features instead of being silently omitted by release-please.

Validation

• actionlint passed
• shell normalization checks cover untyped, api:, fix:, and breaking feat!: titles
• the PR workflow runs real generation and SDK validation

---

Note

Low Risk
Changes only CI commit-message shaping for SDK staging pushes; wrong classification could affect semver/changelog but not application runtime.

Overview
SDK pushes on main now run merged PR titles (or the commit subject) through normalize-sdk-commit-message.sh before stlc build --commit, so release-please always sees a conventional type instead of skipping untyped titles.

The normalizer keeps explicit feat / fix / perf / revert messages (including scoped and ! breaking forms). Non-matching titles get a feat: prefix; titles that look like a custom breaking type (type!:) are rewritten to feat!: plus the original text.

stlc-generate.yml runs the shell test script in the generate job and watches the script paths on PR/push. The SDK generation runbook documents that every merged API/SDK PR is treated as releasable with this classification.

^{Reviewed by Cursor Bugbot for commit 295831b. Bugbot is set up for automated code reviews on this repo. Configure here.}

[masnwilliams]

requesting changes for one release-policy correctness issue:

.github/workflows/stlc-generate.yml:203-210 reimplements release-please's Conventional Commit grammar, but the grammars disagree. api/v2!: and api.sdk!: are valid breaking headers to release-please, yet the breaking regex misses them and rewrites them as non-breaking features. Conversely, feat(): matches conventional even though release-please rejects the empty scope, so that commit can still be omitted entirely.

Please make these patterns match the actual parser boundary—nonempty scopes without nested parentheses and types excluding only whitespace/()/!/:—and check in table-driven tests for these boundary cases. This release policy is too consequential to leave as manually tested inline shell.

For example:

conventional='^(feat|fix|perf|revert)(\([^()]+\))?!?:[[:space:]]+'
breaking='^[^()!:[:space:]]+(\([^()]+\))?!:[[:space:]]+'

[sjmiller609]

Addressed Mason’s parser-contract feedback in f07d211. The normalizer now accepts zero whitespace, rejects empty/nested scopes, supports the parser’s type boundary, and preserves breaking markers when remapping types. Committed table-driven tests cover the requested boundary cases and run in the generation job.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit f07d211. Configure here.}

addressed