4grayandClaude Opus 5 d3e337261e fix(portals): stop a pin write from landing on the next movie ...

Two findings from the review of the previous round.

A pin write is an IPC round-trip, and the user can navigate during it. The
continuation then applied one film's answer to another film's controller —
and because unpinning returns "nothing pinned", it would clear the pin the
new movie had just loaded and its Play action would quietly stop starting
from the preferred source. It now commits only while the same film is still
on screen, like every other async path here.

The short-title scan drops its row limit. FTS keeps its window because it
ranks by relevance, so what it keeps is what matters; a scan cannot rank, so
a window there silently decides which valid sources the user is allowed to
see. It also bought nothing: the GLOB cannot use an index, so SQLite reads
every row either way and the limit only truncated the answer. What bounds
the scan is its predicate — reaching it means the whole title is one or two
characters.

The switch-notice type moves to the module that builds it, which also
removes a circular type import between the two.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-07-27 21:40:34 +02:00

..

architecture

fix(portals): stop a pin write from landing on the next movie

2026-07-27 21:40:34 +02:00

superpowers

feat(mock-data): add shared screenshot-safe poster catalog (#1271)

2026-07-27 08:10:57 +02:00