## TL;DR
Make the writer look for BREAKING CHANGE footers and `!` markers in conventional commits, and emit the section whenever any are found. The section is dropped because the writer never scans for the markers.

## Error
```text
(release notes published with no breaking-changes section despite breaking commits in the range)
```

## Steps
1. Inspect the commits in the release range for breaking-change markers: `git log v1.2.0..v1.3.0 --grep="BREAKING CHANGE" --grep="!"`. Expected: the breaking commits identified.
2. Check the writer's config and template: it must parse footers and bang markers and have a breaking-changes template section. Expected: the gap in parsing or templating found.
3. Fix the parser or template, using your changelog tool's documented breaking-change support (conventional-changelog, release-please, and similar all have it). Expected: the writer emits the section.
4. Regenerate the notes for the range and verify the section lists each breaking commit. Expected: complete breaking-changes section.

## When to use
- Release notes omit known breaking changes
- A custom changelog writer or agent generates the notes
- Commits use `!` or BREAKING CHANGE footers inconsistently

## When not to use
- There are genuinely no breaking changes (the section correctly absent)
- The whole changelog is missing (a generation problem, not a section problem)
- Commits do not follow conventional commits (adopt the convention first)

## Tool compatibility
conventional-changelog, release-please, semantic-release, and custom writers. All key off the same markers.

### Variant phrasings
### writer finds some breaking changes but not all
The parser handles footers but not `!` markers, or vice versa. Support both.

### breaking changes listed under features instead
The template misclassifies the commit type. Fix the type mapping.

## Why it happens
Breaking changes are signaled by convention (footer or bang), not by a dedicated field. Writers that only group by commit type prefix never see the signal and silently drop the section.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IlC9gOL-OWLrJaKlXP3QqA