Files
SubMiner/changes
sudacode d33009d4a3 style: update subtitle text shadow, JLPT underlines, and frequency topX default (#96)
* style: update subtitle text shadow, JLPT underlines, and frequency topX

- Replace directional text-shadow with 4-corner outline shadow for sharper readability
- Increase JLPT level border-bottom from 2px to 3px; add drop-shadow filter
- Add margin-left 0.18em to character image token
- Raise frequencyDictionary topX default from 1000 to 10000

* docs: add subtitle style changelog fragment

* docs: update generated config examples

* style: wrap long textShadow strings and add blank line in CSS
2026-05-28 00:18:39 -07:00
..

Changelog Fragments

Add one .md file per user-visible PR in this directory.

Use this format:

type: added
area: overlay

- Added keyboard navigation for Yomitan popups.
- Added auto-pause toggle when opening the popup.

For breaking changes, add breaking: true:

type: changed
area: config
breaking: true

- Renamed `foo.bar` to `foo.baz`.

Rules:

  • type required: added, changed, fixed, docs, or internal
  • area required: short product area like overlay, launcher, release
  • breaking optional: set to true to flag as a breaking change
  • each non-empty body line becomes a bullet
  • README.md is ignored by the generator
  • if a PR should not produce release notes, apply the skip-changelog label instead of adding a fragment

How fragments turn into a release:

  • At release time, bun run changelog:build (and bun run changelog:prerelease-notes) pipes every pending fragment through claude -p to merge related items, drop noise, and rewrite into a clean user-facing release body. Write fragments as raw, informative notes — don't worry about polished prose, deduping across PRs, or line-by-line phrasing. The polish step handles all of that.
  • The polish step treats pending fragments as the final release outcome, not prerelease history. If a feature is added and then renamed or fixed before the stable cut, ship the final feature bullet instead of separate prerelease-only breaking/fix entries.
  • internal fragments stay in CHANGELOG.md (inside a collapsed <details> block) but are dropped from the GitHub release notes entirely.
  • The polished CHANGELOG.md and release/release-notes.md are committed and reviewed before tagging — edit the Markdown by hand if Claude misses something.

Prerelease notes:

  • prerelease tags like v0.11.3-beta.1 and v0.11.3-rc.1 reuse the current pending fragments to generate release/prerelease-notes.md
  • existing prerelease notes are a reviewed baseline; later prerelease runs should replace stale beta/RC wording with the current outcome instead of appending fix churn
  • prerelease note generation does not consume fragments and does not update CHANGELOG.md or docs-site/changelog.md
  • the final stable release is the point where bun run changelog:build consumes fragments into the stable changelog and release notes