Sign-in: port the approved mockup into the app #19

New issue

Closed

opened 2026-08-10 13:13:06 +00:00 by aiko · 1 comment

aiko commented

2026-08-10 13:13:06 +00:00

Owner

Parent

What to build

mockups/sign-in.html is the approved design, arrived at in a live session and accepted as-is. Port it into the real sign-in path. The mockup is the specification — read it, including its direction-contract comment at the top, before changing anything.

The idea it commits to: the sign-in is a Cue. The app's whole visual home is one line of white text low on a black screen, so the first thing it ever shows is that. It refuses both the centred card the category ships and the drifting jellyfish the name suggests.

What carries over exactly:

Empty upper field, lower-third band. The emptiness is the video not yet playing and is doing a job.
海月読み at Cue size with くらげよみ muted beneath it, in the position a translation line takes.
Fields as underlines with the label below as a muted gloss, not a floating placeholder.
The action at Cue size, the loudest line on the screen, with a 1.3s karaoke fill sweeping the glyphs in the accent while the request is in flight. That fill is the loading state — the karaoke timing tag every ASS subtitle in the library already uses — and there is no spinner anywhere.
Signing in produces a different screen, not a success state. The fill completes, the band leaves, and the app shows whatever comes next. Holding a filled line read as stuck rather than done, which is why the mockup does it this way.

The real sign-in has jobs the mockup does not: a genuine Jellyfin authentication request, a real failure message from the server, and landing on the watching screen when a Playback Session already exists rather than always on the waiting state.

The existing renderSignIn had two defects fixed in #15 — it was rebuilding the form on every repaint, taking the password out from under someone typing, and signedIn was hardcoded so the branch was dead. Do not reintroduce either.

Acceptance criteria

The sign-in renders as the mockup specifies, at 412px wide
A real Jellyfin authentication runs; the fill covers the actual request, however long it takes
A failed sign-in shows the server's reason and returns the action to its resting state
A successful sign-in leaves the sign-in screen rather than confirming itself
After signing in, an existing Playback Session goes straight to watching; otherwise the waiting state
The form is not rebuilt on repaint, and a typed password survives one
Reduced-motion replaces the fill rather than removing the loading state
Contrast holds: ink, muted, and accent all clear 4.5:1 on the ground
Whatever logic this adds is tested; CSS is not faked with a test that restates it

Blocked by

## Parent #1 ## What to build `mockups/sign-in.html` is the approved design, arrived at in a live session and accepted as-is. Port it into the real sign-in path. The mockup is the specification — read it, including its direction-contract comment at the top, before changing anything. The idea it commits to: **the sign-in is a Cue.** The app's whole visual home is one line of white text low on a black screen, so the first thing it ever shows is that. It refuses both the centred card the category ships and the drifting jellyfish the name suggests. What carries over exactly: - Empty upper field, lower-third band. The emptiness is the video not yet playing and is doing a job. - 海月読み at Cue size with くらげよみ muted beneath it, in the position a translation line takes. - Fields as underlines with the label *below* as a muted gloss, not a floating placeholder. - The action at Cue size, the loudest line on the screen, with a 1.3s karaoke fill sweeping the glyphs in the accent while the request is in flight. That fill is the loading state — the karaoke timing tag every ASS subtitle in the library already uses — and there is no spinner anywhere. - **Signing in produces a different screen, not a success state.** The fill completes, the band leaves, and the app shows whatever comes next. Holding a filled line read as stuck rather than done, which is why the mockup does it this way. The real sign-in has jobs the mockup does not: a genuine Jellyfin authentication request, a real failure message from the server, and landing on the watching screen when a Playback Session already exists rather than always on the waiting state. The existing `renderSignIn` had two defects fixed in #15 — it was rebuilding the form on every repaint, taking the password out from under someone typing, and `signedIn` was hardcoded so the branch was dead. Do not reintroduce either. ## Acceptance criteria - [ ] The sign-in renders as the mockup specifies, at 412px wide - [ ] A real Jellyfin authentication runs; the fill covers the actual request, however long it takes - [ ] A failed sign-in shows the server's reason and returns the action to its resting state - [ ] A successful sign-in leaves the sign-in screen rather than confirming itself - [ ] After signing in, an existing Playback Session goes straight to watching; otherwise the waiting state - [ ] The form is not rebuilt on repaint, and a typed password survives one - [ ] Reduced-motion replaces the fill rather than removing the loading state - [ ] Contrast holds: ink, muted, and accent all clear 4.5:1 on the ground - [ ] Whatever logic this adds is tested; CSS is not faked with a test that restates it ## Blocked by - #15

aiko added the

ready-for-agent

label

2026-08-10 13:13:06 +00:00

aiko referenced this issue from a commit

2026-08-10 16:20:44 +00:00

feat(web): the sign-in is a Cue

aiko referenced this issue from a commit

2026-08-10 16:20:44 +00:00

merge: the sign-in is a Cue (#19)

aiko commented

2026-08-10 16:21:26 +00:00

Author

Owner

This was generated by AI during triage.

Merged to main in af73452. Suites at merge: 79 C#, 335 phone.

The approved mockup ported into the app. The sign-in is a Cue: one line of white text low on a black screen, refusing both the centred card the category ships and the jellyfish the name suggests. The karaoke fill is the loading state and covers the real request however long it takes.

Signing in produces a different screen rather than a success state — holding a filled line read as stuck, and that was tested and rejected.

Three deliberate departures from the mockup, all recorded: the error line is ink rather than accent (DESIGN.md enumerates the accent's uses and a wrong password is not one), no transition on the focus border (opacity-only motion is enforced), and the sizes moved onto the app's type ladder so they scale with the reader's choice.

> *This was generated by AI during triage.* Merged to `main` in af73452. Suites at merge: 79 C#, 335 phone. The approved mockup ported into the app. The sign-in is a Cue: one line of white text low on a black screen, refusing both the centred card the category ships and the jellyfish the name suggests. The karaoke fill is the loading state and covers the real request however long it takes. Signing in produces a different screen rather than a success state — holding a filled line read as stuck, and that was tested and rejected. Three deliberate departures from the mockup, all recorded: the error line is ink rather than accent (DESIGN.md enumerates the accent's uses and a wrong password is not one), no transition on the focus border (opacity-only motion is enforced), and the sizes moved onto the app's type ladder so they scale with the reader's choice.

aiko closed this issue

2026-08-10 16:21:27 +00:00