Small things to polish: a logo that stops leading away, two lists that keep their order, and a place a phone can add (#66)

[Devski]

Closes #66 — all four things on it.

The logo above the card leads nowhere

It was a link to / on all seven auth screens. A visitor part-way through making an
account was being offered a way out of the view — a conversion question before a styling
one (Dawid, 12.09.2026). It was also broken as navigation: / sends a signed-in visitor
onward and one who has not finished setting up straight back, so after verification that
link looped to the page it was on.

href on Logo/LogoMark is optional now, and no href means no anchor — a span, which a
keyboard and a screen reader both pass by, rather than a link plus a second prop that could
contradict it. One rule for the whole auth shell: each of those screens carries its own
links, so nobody is stranded. The homepage hero, the public profile, settings and the
owner's view keep theirs.

A place a phone could not add

Only Enter committed, and a phone's keyboard offers "next" — which is Tab, so the key moved
focus and took the typed text with it.

• Tab commits what Enter would, and still moves on. On a desktop it only rescues text
  that tabbing away was about to discard.
• enterKeyHint="done", so the phone's key says what it does — the field is not inside
  a <form>, so it had nothing to infer that from.
• The hint under the field names both keys, in both languages.
• Blur still discards, on purpose.

Two lists the owner can put in order

Places and works both had one order: the one they were added in.

One piece of machinery for both, because they look nothing alike — a wrapped row of chips,
a grid of cards. lib/reorder.ts has the arithmetic (move an item; which box a pointer is
over, falling back to the nearest middle so a finger in the gap between two cards still
means something), components/ui/use-reorder.ts the hand on it.

• Pointer events, not HTML5 drag-and-drop: dragstart never fires on a touch screen,
  and half of this product is used on a phone. One path serves a mouse, a finger and a
  stylus.
• The same grip answers the arrow keys and keeps focus on the item it moved — without
  that, one press moves the card and drops the keyboard out of the list entirely.
• The drag reads its state from refs, not from the render it started in: a pointerup can
  arrive before the render a pointermove scheduled has committed, and a handler closed over
  the older render sees the drag still sitting where it began.

Places cost nothing to order — the order is the array, saved by the call that already
saves them.

Works needed a column. position, backfilled from created_at so nothing shuffled the
day it arrived, with created_at still breaking the tie; a new work takes the next number.
The whole order goes to POST /api/works/order, which refuses one about any list other than
the owner's current works — a second tab adding or deleting a work makes the save fail
rather than quietly move something nobody touched. A refused save puts the order on screen
back.

The schema canaries did their job and were extended consciously: works grew a column, and
its index was re-created with the owner's order in front of the adding order it used to
carry alone.

Added while in there

The place list says out loud what happened to it, and so does the works list (role="status",
visually hidden). A chip appearing was the whole of the feedback, and the field empties
itself the moment a place is taken — which to a screen reader is indistinguishable from the
text having been thrown away.

Verified

pnpm check green. In a browser: on /register the wordmark is a span with the screen's
own "Log in" link intact; on the homepage the logo is still a link.

Against the test database (e2e/db/works-order.spec.ts, new, and a case added to
profile-sections.spec.ts): grips only while editing; the arrows moving a work with the
save asserted and the order surviving a reload; a drag by the grip landing where it was
dropped; a visitor seeing the owner's order; and the same for places.

The drag test earned its keep by failing twice — once on a reload racing the save (the
test now waits for the response, which is the honest assertion anyway), once on dragging a
card at coordinates below the fold.

🤖 Generated with Claude Code

[Devski]

Two review lanes went over this — one on the change as a whole, one on the new endpoint.

The endpoint came back clean. No critical, high or medium findings: userId comes only from the session, the id set is compared against the owner's own works under the lock, and the UPDATE is scoped by user_id as well as by id — two independent answers to "are these yours", not one with a comment. A foreign id and a non-existent one give the same stale_order, so there is no enumeration oracle either.

The hand on the list did not come back clean. Six things, now fixed:

A refused save could resurrect a deleted work — permanently. The revert put back a snapshot taken before the save. If the list had changed underneath (another tab deleted a work, which is exactly what stale_order exists for), that snapshot brought the deleted work back on screen with live edit and delete buttons, and the derived-state resync had already fired, so nothing corrected it short of a page load. In the two-tab case every retry failed identically, for ever. Nothing is reverted from a snapshot now: a failure says what happened and refreshes, and the server's own answer is the way back.

Saves were not sequenced. An arrow key repeats about twenty-five times a second, and each press was its own request: several in flight at once, committed in whatever order they reached the lock, the tail refused by the rate limit — and each refusal reverting to its own stale snapshot, so the screen and the database could disagree silently. The order is now sent once the moving stops (300 ms), and Zapisz flushes a waiting one rather than claiming "Zapisano" over a save that never left the page.

An open work form disabled every pointer drag, silently. The in-place form's row is not one of the measured boxes, so the measuring loop bailed out for every grip — while the grips stayed on screen with cursor-grab, and the keyboard path still worked. No reordering at all while a form stands in the list now, grips included.

A second finger took over a drag in flight, and the first finger's release then committed the second one's half-finished move. One drag at a time.

Plus: the order error outlived editing and was never cleared, and capture lost without a cancel (the grip unmounting mid-drag) left a card looking held.

Accessibility, which no e2e test would have caught. A grip is a button, and a button's keys are Enter and Space — neither moves anything here. Both lists now point every grip at one line naming the arrows, and every grip says where its item sits ("2 of 5"). Written down rather than fixed: in a screen reader's browse mode the arrows are consumed before they reach the button, so the conventional pick-up-and-drop model (Space picks up, arrows move, Space drops, Escape cancels) is the fuller answer — a separate decision, since it trades away the "no mode to forget to leave" property.

From the security lane: the ten UPDATEs are one UPDATE … FROM (VALUES …) now, so the per-user lock and the pooled connection are held for one round trip rather than a dozen. The owner stays in the WHERE.

One finding belongs outside this branch: src/db/client.ts builds its pool with pg's defaults — connectionTimeoutMillis: 0 (waits for ever) and no statement_timeout/lock_timeout anywhere, so contention queues instead of failing. That is every route, not this one.