mirror of
https://github.com/ksyasuda/SubMiner.git
synced 2026-08-24 00:15:26 -07:00
sudacode
9f08adbfb9
Generated lyric effects can overlay each syllable with animated single letters
rendered through \fn in a symbol font, where ordinary letters draw as sparkles.
Reading them as text corrupted reconstructed lines ("sotto mimi ni ateru to a z
x") and leaked junk cues ("hlk"). A font a style group uses only for scattered
animated single glyphs now marks those events as decoration: they stay out of
fragment reconstruction and are suppressed alongside the line they overlay.
Per-glyph word gaps measured across a wide glyph ("waves|within" over s/w)
normalize to nearly a common advance, so the ratio test missed them. A word
space adds a roughly constant extra distance regardless of neighbor widths, so
glyph runs with enough gap samples also split when the advance exceeds the
width-predicted advance by a material fraction of the line's common unit.
Capital-to-lowercase pairs and short sample counts are excluded; both guards
are pinned by corpus-derived regression tests.
Across the 145-file library corpus this removes every scattered-letter
malformation and recovers 30+ missing word spaces with no other output change.
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:
typerequired:added,changed,fixed,docs, orinternalarearequired: short product area likeoverlay,launcher,releasebreakingoptional: set totrueto flag as a breaking change- each non-empty body line becomes a bullet
README.mdis ignored by the generator- if a PR should not produce release notes, apply the
skip-changeloglabel instead of adding a fragment
PR branch workflow:
- Before adding a fragment or bullet, inspect the
changes/*.mdfiles already changed in the PR - If the new work fixes, modifies, renames, or supersedes behavior introduced or referenced by that fragment, edit or remove the stale bullet instead of adding follow-up churn
- Add a new bullet only when it describes a truly separate user-visible outcome
- Multiple fragment files are allowed when one PR has genuinely separate release-note outcomes, but keep them minimized and current
How fragments turn into a release:
- At release time,
bun run changelog:build(andbun run changelog:prerelease-notes) pipes every pending fragment throughclaude -pto 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.
- GitHub release notes and prerelease notes use short top-level items with nested bullets for the change, user benefit, and any useful action note. The stable
CHANGELOG.mdcan stay in compact single-line bullets. internalfragments stay inCHANGELOG.md(inside a collapsed<details>block) but are dropped from the GitHub release notes entirely.- The polished
CHANGELOG.mdandrelease/release-notes.mdare committed and reviewed before tagging — edit the Markdown by hand if Claude misses something.
Prerelease notes:
- prerelease tags like
v0.11.3-beta.1andv0.11.3-rc.1reuse the current pending fragments to generaterelease/prerelease-notes.md - from the second prerelease of a base version onward, the notes also open with a
## Changes since <previous tag>section generated from the fragment diff against the previous beta/RC tag; keep fragment edits meaningful. Editorial-only rewording is filtered out of that section, while genuinely changed behavior and deleted fragments (reverted changes) are reported - 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.mdordocs-site/changelog.md - the final stable release is the point where
bun run changelog:buildconsumes fragments into the stable changelog and release notes