mirror of
https://github.com/ksyasuda/SubMiner.git
synced 2026-11-10 04:46:07 -08:00
sudacode
b31ddce627
* feat(controller): add hold + press combos to main bindings Main Alt+C actions can now be learned as combos such as L1 + D-pad right. A combo fires on each press while its hold button is down, and claims its press input so token move and popup scroll ignore it until it is released. A plain action on a hold button fires on release, unless another bound button was pressed during the hold. The save path needed two changes for combos to persist. The IPC validator rebuilt bindings field by field and dropped `hold`, so Alt+C showed a combo from its local copy until the next reload turned it back into a plain button. Validator and config resolver now share one parser. Saves also replace the controller section, since the deep merge in patchRawConfig kept the old `hold` when a combo was rebound to one button. Also fixes Learn on the (D-pad) rows, which threw after cancel() cleared the capture target. * test(launcher): wait for content in background child test The test polled for the fake app's output files to exist, but the shell creates a redirect target before writing to it. A poll landing in that gap read an empty env file and failed with '' !== '1', as seen once in CI. Wait until both files have content instead. * fix(controller): keep a diagonal push from learning as a combo Learn took the first axis of a diagonal stick push as the hold and the second as the press, saving a combo that one axis could never trigger. This reached main Alt+C rows when they moved to combo capture. Axes crossing the threshold in the same poll as the first input now count as one movement. A second axis moved in a later poll still records a combo. * fix(controller): only treat simultaneous axes as one movement The diagonal push guard also blocked an axis activated in the same poll as a button, so L1 plus a stick direction could not record the stick until it was released and moved again. Apply the guard only when the first input is an axis, so that input pair records as a combo again.
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.
CHANGELOG.md, GitHub release notes, and prerelease notes all use one item per feature or area, inline by default:- **Name**: one or two short sentences.Items with several separate changes may use a few short nested bullets instead of a run-on sentence. Items say what changed and how to reach it; implementation details, edge cases, and step-by-step usage belong in the docs, not the release body.internalfragments stay inCHANGELOG.md(inside a collapsed<details>block) but are dropped from the GitHub release notes entirely.- The polished
CHANGELOG.mdandpackaging/release-notes/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 generatepackaging/release-notes/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