mirror of
https://github.com/ksyasuda/SubMiner.git
synced 2026-08-04 19:21:33 -07:00
sudacode
f43674cc39
onSubtitleChange paused prefetching unconditionally, but the processing controller returns early when the text matches what it already has. Nothing is tokenized, so nothing is emitted, so the resume that rides on the emit never fires and prefetching idles for the rest of the cue. The reachable trigger is a repeat arriving after a cache invalidation, such as mining a card while the same line is still on screen. The controller now reports whether it scheduled processing and the caller resumes when it did not, so every pause has a matching resume. Also harden the character-name candidate prefilter: Yomitan collapses emphatic sequences before matching, so a stretched spelling still resolves to its entry (ミナァァト matches ミナト). The candidate match now skips small kana and prolonged marks, which only widens the probe set and so cannot drop a name.
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 - 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