0 Fork 0

mirror of https://github.com/ksyasuda/SubMiner.git synced 2026-10-20 17:01:24 -07:00

Files

T

sudacode 78eca52b7e test: add headless end-to-end harness (#286 )

* test: add headless end-to-end harness and CI job

Boot the built app against a real mpv, a synthetic clip, a fixture Yomitan
dictionary, and a fake AnkiConnect inside a private Xvfb display, then assert
on the overlay DOM and the AnkiConnect requests. Adds the test:e2e lane, an
e2e session CLI for exploratory checks, and a three-platform CI job.

* ci: set e2e temp dir from a step

* test: make e2e session startup robust on slow machines

Bun caps node:test hooks at 5s, so boot the session inside the first test.
Keep pausing until the app's resume retries stop, read cue tokens in one
round trip, and resolve Electron through its package entry so CI downloads
the binary.

* test: harden e2e harness for CI runners

Fail fast when mpv cannot be spawned, read every Yomitan popup frame instead
of trusting target order, and put the chocolatey mpv directory on PATH.

* test: add e2e failure diagnostics and mark Windows job experimental

Report what the overlay showed when a cue never renders, dispose the session
when the overlay cannot be opened, skip popup frames that vanish mid-poll,
and turn off AniSkip lookups in the harness config.

* test: read the lookup popup entry from textContent

* test: capture renderer console and main-side subtitle state in e2e failures

* test: expose the Electron main-process inspector to the e2e harness

Adds session.mainProcess() and 'e2e eval main', and reports main's window
list alongside the overlay state when a cue never renders.

* test: tap subtitle sends and receipts in e2e failure diagnostics

* test: probe alternate main-to-renderer paths in e2e failure diagnostics

* test: select the visible overlay layer, not the primed modal window

Windows and macOS pre-create a hidden modal window that loads the same
renderer document, and the harness could attach to it instead of the
visible overlay. Drops the delivery taps that found this.

* ci: run the Windows e2e job as a normal matrix entry

* test: address review on e2e harness

Slice the app log at a byte offset before decoding, create the session state
file owner-only since it carries the inspector URL, and keep the cue failure
when inspector diagnostics are unavailable.

* test: create the e2e session state file exclusively

2026-10-05 22:00:58 -07:00

e2e-harness.md

test: add headless end-to-end harness (#286 )

2026-10-05 22:00:58 -07:00

README.md

chore(release): generate concise release notes per feature or area

2026-10-02 19:52:16 -07:00

setup-launcher-badge-label.md

fix(setup): label missing launcher "Not set up" instead of "Not installed" (#284 )

2026-10-04 17:13:10 -07:00

README.md

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

PR branch workflow:

Before adding a fragment or bullet, inspect the changes/*.md files 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 (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.
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.
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
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.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