Deploy the lookup slice and tune it on the Pixel #13

Open
opened 2026-08-10 09:27:08 +00:00 by aiko · 1 comment
Owner

Parent

#1

What to build

Not a build — a sitting with the phone. Deploy per docs/deploy-brief-hermes.md, then answer the questions the design deliberately left to the hand rather than to paper.

  • Type size. ADR 0007 puts it in a CSS custom property precisely so it is found at sofa distance. Find it.
  • Tap accuracy. The one risk nothing on paper settles. Does tapping a specific character on real kanji work, and if it misses, does it miss consistently in one direction? A systematic off-by-one is fixable; random slop means the per-character hitboxes rejected in ADR 0007 come back.
  • Two stacked horizontal strips. The regions are distinct so the browser is never in doubt, but whether it feels mushy in the hand is unknown until it is held.
  • The one-second no-entry flash. Long enough to read, short enough not to be in the way?
  • First-start dictionary build. Time it on dionysus. If it is minutes rather than tens of seconds, the building state needs to say more than that it is building.

Remember the two things that waste time: dex-win has to be awake for the fetch, and the phone caches main.js — hard-reload after deploying or you will debug the previous build.

Acceptance criteria

  • Deployed to dionysus and reachable on the Pixel over the tailnet
  • Reading type size settled and committed
  • Tap accuracy assessed, and any systematic bias written down as an issue rather than a memory
  • The frozen state and catch-up control behave when a real episode is playing
  • First-start dictionary build time recorded

Blocked by

## Parent #1 ## What to build Not a build — a sitting with the phone. Deploy per `docs/deploy-brief-hermes.md`, then answer the questions the design deliberately left to the hand rather than to paper. - **Type size.** ADR 0007 puts it in a CSS custom property precisely so it is found at sofa distance. Find it. - **Tap accuracy.** The one risk nothing on paper settles. Does tapping a specific character on real kanji work, and if it misses, does it miss consistently in one direction? A systematic off-by-one is fixable; random slop means the per-character hitboxes rejected in ADR 0007 come back. - **Two stacked horizontal strips.** The regions are distinct so the browser is never in doubt, but whether it feels mushy in the hand is unknown until it is held. - **The one-second no-entry flash.** Long enough to read, short enough not to be in the way? - **First-start dictionary build.** Time it on dionysus. If it is minutes rather than tens of seconds, the building state needs to say more than that it is building. Remember the two things that waste time: dex-win has to be awake for the fetch, and the phone caches `main.js` — hard-reload after deploying or you will debug the previous build. ## Acceptance criteria - [ ] Deployed to dionysus and reachable on the Pixel over the tailnet - [ ] Reading type size settled and committed - [ ] Tap accuracy assessed, and any systematic bias written down as an issue rather than a memory - [ ] The frozen state and catch-up control behave when a real episode is playing - [ ] First-start dictionary build time recorded ## Blocked by - #12
Author
Owner

This was generated by AI during triage.

Unblocked — #8, #9, #10, #11 and #12 are merged to main at 168b131. Suites: 56 C#, 179 phone.

Things the batch turned up that this sitting should settle, in rough order of how much they matter:

Will it even load. Microsoft.Data.Sqlite is not shipped in the plugin; it resolves at runtime from Jellyfin's own copy (10.11 uses EF Core SQLite for jellyfin.db). That is what keeps the deploy to one dll, and it is unverified on a real server. If the plugin fails to load on dionysus, this is the first suspect.

The dictionary build. 4.4s and 62MB on dex-win. Time it on dionysus — if it is minutes rather than seconds there, the building state needs to say more than that it is building.

Tap accuracy. The risk nothing on paper settles. Does tapping a specific character work, and if it misses, does it miss consistently in one direction? A systematic off-by-one is fixable; random slop means the per-character hitboxes ADR 0007 rejected come back. The one-second no entry highlight exists precisely to show you where your finger actually landed — use it.

Type size. --cue-reading-size, --entry-headword-size, --entry-reading-size, --entry-sense-size are all custom properties in Web/index.html. Tune and commit.

Two stacked horizontal strips. Regions are distinct so the browser is never in doubt, but whether it feels mushy in the hand is unknown until it is held.

Three known-wrong things, deliberately left for you to judge rather than fixed blind:

  • Halfwidth katakana (U+FF66–FF9D) is silently ignored rather than getting the no entry highlight. Rare in subtitles, and the deinflector would not handle it anyway.
  • Swiping the Cue strip while the sheet is open leaves the pre-lookup position stale, so dismissing may not return to live. Back to live is right there.
  • The 1/4 indicator is not sticky, so a very long Entry scrolls it out of view. The attribution is sticky.

Remember: dex-win has to be awake for the fetch, and the phone caches main.js — hard-reload after deploying or you will debug the previous build.

> *This was generated by AI during triage.* Unblocked — #8, #9, #10, #11 and #12 are merged to `main` at 168b131. Suites: 56 C#, 179 phone. Things the batch turned up that this sitting should settle, in rough order of how much they matter: **Will it even load.** `Microsoft.Data.Sqlite` is not shipped in the plugin; it resolves at runtime from Jellyfin's own copy (10.11 uses EF Core SQLite for `jellyfin.db`). That is what keeps the deploy to one dll, and it is unverified on a real server. If the plugin fails to load on dionysus, this is the first suspect. **The dictionary build.** 4.4s and 62MB on dex-win. Time it on dionysus — if it is minutes rather than seconds there, the building state needs to say more than that it is building. **Tap accuracy.** The risk nothing on paper settles. Does tapping a specific character work, and if it misses, does it miss consistently in one direction? A systematic off-by-one is fixable; random slop means the per-character hitboxes ADR 0007 rejected come back. The one-second `no entry` highlight exists precisely to show you where your finger actually landed — use it. **Type size.** `--cue-reading-size`, `--entry-headword-size`, `--entry-reading-size`, `--entry-sense-size` are all custom properties in `Web/index.html`. Tune and commit. **Two stacked horizontal strips.** Regions are distinct so the browser is never in doubt, but whether it feels mushy in the hand is unknown until it is held. **Three known-wrong things, deliberately left for you to judge rather than fixed blind:** - Halfwidth katakana (U+FF66–FF9D) is silently ignored rather than getting the `no entry` highlight. Rare in subtitles, and the deinflector would not handle it anyway. - Swiping the Cue strip while the sheet is open leaves the pre-lookup position stale, so dismissing may not return to live. `Back to live` is right there. - The `1/4` indicator is not sticky, so a very long Entry scrolls it out of view. The attribution is sticky. Remember: dex-win has to be awake for the fetch, and the phone caches `main.js` — hard-reload after deploying or you will debug the previous build.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
mobrule/kurageyomi#13
No description provided.