dc4b9a0909
* docs(settings): define the cross-platform settings contract Turns the audit in #376 into a decision-complete design for how user settings work across the server, bundled web client, Apple clients, and Android clients. Today there are three partial contracts - the server registry, the web client's own manifest, and independently owned key constants in each native client - and they have measurably drifted. The root enabler is that keyUsesUserScope returns true for any unregistered key, so a client can invent a production setting unilaterally and the server stores it as an unvalidated string. The design decides: Ownership. Every production user-facing setting needs a server-owned manifest entry, even when the value is stored only on one client. The single exception is private local.<client>.* diagnostics, bounded by five conditions. Types and scopes. Native JSON values instead of strings. Five remote scopes plus client_local, and each definition declares its own resolution order rather than inheriting a global precedence. Preferences versus restrictions. internal/policy already resolves max_playback_quality and metadata-language limits over the same controls this contract resolves preferences for. Definitions declare constrained_by, the effective response reports the permitted value alongside the user's stored one, and a mutation exceeding a restriction is stored rather than rejected - a capped 4K preference should take effect the day the cap lifts, not be destroyed by it. Compatibility. Widening a scope, adding an enum member, or widening a range is additive and revision-tagged; narrowing anything needs a new key. introduced_in is a manifest revision attached to individual enum members and scopes, not just whole definitions, so a newer client never offers a choice an older server will reject. Rollout. One coordinated breaking release, with no compatibility shim, projection, or client fallback. After the cutover no future setting requires coordination. No settings version check goes in the authenticated middleware and nothing returns 426: deleting the old routes already produces the break, and a gate would be more code in four repos for the same outcome while permanently coupling every endpoint to one subsystem's versioning. Scope placement. Appearance and date/time move from account to profile scope. Account scope was an artifact of pre-profile storage; leaving it there means a household shares one theme and text size, and any non-child profile can restyle everyone else. Read path. Batched context resolution, index requirements, a session-snapshot rule, and a no-regression benchmark gating storage consolidation - profile_series resolution is per-item, so a season view would otherwise issue one request per episode. Verified against the current server, Apple, and Android implementations. Two findings shape it: the unknown-key extension bag is real, and v1 scope reads NOT LOCKED, so removing the legacy surface needs no amendment if it lands before lock. Related to #376. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(settings): add the canonical settings contract manifest First implementation step for the cross-platform settings contract (#376). Adds the artifact everything else depends on: the manifest, its JSON Schema, the object value schemas, and a Go loader that validates the whole thing at load time. No routes, no storage, no behavior change — nothing reads this yet. contracts/settings/v1/ holds the artifact at a stable path because clients vendor it and generate bindings from it. The embed directive has to sit beside it (go:embed cannot reach outside its own directory), so that directory is a tiny Go package containing nothing else; loading and validation live in internal/settingscontract. 38 definitions: 35 remote, 3 contract-known client_local. That covers every key the legacy registry accepts, every unregistered key the extension bag was silently accepting from the web client, every unregistered device key Android writes, and the profile preference columns that become settings. Registering the previously-unregistered keys is where the drift shows up, and the manifest records each case in a notes field: - ui_theme, ui_text_scale, ui_text_weight, ui_high_contrast, ui_custom_theme_vars, and ui_custom_css reached the server only because keyUsesUserScope returns true for any unregistered key. They are now typed, renamed to the dotted convention every other key uses, and moved to profile scope per the design. - player.match_frame_rate and player.sleep_timer_default_minutes are written by Android against a server that does not register them, so every write and reset is currently rejected. Registered. - player.next_up_prompt_seconds is Android's alias for playback.next_up_prompt_seconds and does not become a definition; the test matrix pins it as a migration alias. - player.playback_speed is capped at 3.0, matching the server rather than Android's 4.0. - subtitle_appearance becomes playback.subtitle_appearance. Every other canonical key carries a domain prefix, and preserving accidental key names is an explicit non-goal of the design. Validation is deliberately stricter than the schema can express. Beyond shape, it enforces that a resolution order ends in "default", that it only resolves scopes the definition allows, and — the one most likely to bite — that every writable scope is actually read, so a setting cannot accept writes at a scope it will never honor. Defaults are validated against their own value schema, so a default that violates its own range or enum fails at load. Revision tags are checked to never run ahead of the manifest revision, which is what makes revision-aware client filtering trustworthy. Ceiling and floor policy constraints are rejected on unordered types, where capping would silently do nothing; playback.preferred_quality's enum is therefore ordered ascending. ValidateValue is the single validation path, so the mutation endpoint, the migration, and the manifest's own default checks cannot diverge later. Numbers decode through json.Number so an integer setting rejects 30.5 rather than truncating, and object values validate against their referenced JSON Schema instead of accepting arbitrary JSON the way validateJSONSetting does today. Canonicalization implements RFC 8785 over the value domain the contract uses: sorted keys, no insignificant whitespace, ECMAScript number formatting. The digest is the ETag, and PublicBytes strips maintainer notes so the served manifest never carries internal commentary. Promotes santhosh-tekuri/jsonschema/v6 from indirect to direct. Verification: 124 tests pass across 16 cases; golangci-lint clean; make verify-local-paths passes. Two failures in internal/api/handlers (TestRemoveJellyfinCompatWebDisablesWebSetting, the playback v3 seek recovery test) reproduce unchanged on main and are unrelated. Part of #376. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(settings): give ui.theme a device override Theme joins text scale, text weight, and high contrast as a profile default with an optional per-device override, resolving profile_device -> profile -> default. The right theme is partly a function of the screen and the room — a light theme on a phone in daylight, a dark one on a TV at night — which is the same reasoning the other three appearance keys already used. All four appearance settings now cascade consistently, which also means one rule to explain in the UI rather than "these three follow the device, that one does not". ui.custom_theme_vars and ui.custom_css stay profile-wide. They are authored styling rather than a contextual preference, so a profile's custom tokens still apply on top of whichever theme a device resolves to. Recorded in the definition notes because it is a visible consequence: vars tuned against a dark theme will sit on top of a light one if a device overrides the theme. Widening those to profile_device later is an additive revision bump if it turns out to matter. Part of #376. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(web): tag local appearance caches with their owning account The theme, text scale, text weight, high contrast, custom theme variable and custom CSS caches in localStorage were untagged, so on a shared browser a second account inherited the first account's appearance: with no server value of its own, every fallback resolved to whatever the previous account had stored, and the leftover `silo-theme` key also suppressed the admin-configured default theme for the new account. DateTimeFormatProvider already solved this by stamping its cache with the authenticated user id and refusing another account's values. Extract that mechanism into `createOwnedCache` in utils/storage.ts (where key namespacing lives) and put all three groups behind it, so appearance and custom theme get the same protection instead of a third copy of the rule. - Each group carries its own owner stamp. A shared stamp would be unsafe: the groups are written by hooks nested inside each other, and effects run inner-first, so whichever hook stamped first would vouch for the other's still-stale values. - A null owner (auth bootstrapping, or signed out) still trusts the cache, which keeps the warm start and the login screen's last look. - An unstamped cache is not trusted once an account is known, so existing users take a one-time appearance reset on first load rather than a chance of seeing someone else's settings. - When a foreign cache is detected the values are dropped and the empty cache is handed to the new account, so a later single save cannot re-trust the rest of the previous account's state. Owner is the user id because /settings is user-scoped server side; it lives in one helper (`appearanceCacheOwner`) so it can be widened if appearance moves to profile scope. `shouldLoadApiTheme` is gone: it had become a synonym for `appearanceCacheOwner(...) !== null` with no callers left. Part of #376 AI-use disclosure: implemented with Claude Code. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(settings): make the settings contract enforceable and fix the appearance cache The contract manifest landed as a document nothing checked. This makes it a mechanism, and fixes the one defect in the change set that hurt users on merge rather than at cutover. Web appearance cache. useTheme cleared the cache for any account whose stamp did not match and never repopulated it — the only writers were the four user-action setters — so every upgrading user lost their warm start on every load, not once, and x-large-text and high-contrast users lost theirs too. The owner-stamp protocol is replaced with per-account key namespacing (`silo-theme:7`): a foreign value is absent rather than present-and-distrusted, so nothing has to be deleted, the first account keeps its warm start, and there is no shared stamp for a second tab, a stale debounce timer, or an out-of-order effect to race on. Widening ownership to profile scope, which this manifest requires, is now a change to appearanceCacheOwner alone. Adds the API-to-cache mirror useTheme was missing, cancels pending debounced writes across an account change, and re-seeds provider state during render so no frame paints the previous account's look. Canonicalization. writeCanonical used json.Marshal, which HTML-escapes < > and &, and canonicalNumber used Go's 'g' format — both diverge from RFC 8785, so the first label containing an ampersand or bound below 1e-4 would have forked the server's ETag from every conforming client. Output is now byte-identical to ECMAScript String() across the edge cases, verified against node. The ETag also covers the value schemas, which decide what the server accepts and previously could change while the tag stood still. All four derived representations are memoized; a conditional GET no longer costs a full parse and re-serialize. Validation. strictUnmarshal's decoder.More() answered false for a stray ] or }, so `true]` validated as a boolean. Enum matching compared fmt.Sprintf tokens, so the string "3" satisfied an integer member. Declared steps were never enforced. The language pattern rejected tags both mobile platforms emit unprompted (en_US, ca-ES-valencia, ar-EG-u-nu-latn) and never normalized case, so en-US and en-us were two rows for one preference; NormalizeValue now canonicalizes on the shared path. Manifest. show_forced_subtitles defaulted false where the server column is NOT NULL DEFAULT true, which would have turned forced subtitles off for every profile that never touched it. preferred_quality declared 13 members where the planner speaks 6 and collapses the rest to auto. metadata_language's allowlist was bound to the very column it migrates from. subtitle-appearance pinned fontFamily to three families while Apple stores any installed system font. Registers five user-facing settings the clients already ship, and corrects three notes that described Android behaviour that was not true. Enforcement. The package had no non-test callers, so MustLoad never ran; it now loads and logs at startup. The inventory test compared the manifest against a hand-copied map and could not see the drift it named; it now iterates settingsRegistry and checks defaults too — both verified to fail on injected drift. Adds .github/workflows/ci.yml, the repo's first CI that runs go test, go vet, gofmt, and the frontend suite. Known pre-existing failures are named individually in the Makefile so everything else stays gated and the list can only shrink. Part of #135 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(settings): align the sleep timer default and range with the shipped client Android is the only client that implements this setting. It clamps to 0..240 and defaults to 30. The manifest said 0..480 with a default of 0, so a manifest-driven UI would have offered durations no client can store, and every user who never opened the picker would have had the preset silently turned off at cutover. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * ci: give the new workflow the deps it actually needs The first run exposed two gaps in the workflow itself. go build ./... fails without libvips headers, because h2non/bimg binds libvips through cgo and pkg-config; the Dockerfile installs the same package. And pnpm/action-setup resolves its version from package.json, but there is no package.json at the repo root — the packageManager field lives in web/package.json, and a job's defaults.run.working-directory does not apply to an action's inputs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test(web): stop the diagnostics download test depending on the Node version new Response(blob) reads the body through blob.stream(), which jsdom's Blob does not implement on Node 22 — the version the Dockerfile builds with. The test passed locally on Node 24 and threw "object.stream is not a function" in CI. Nothing in it asserts on the body, only that the object URL and filename reach the anchor, so a string body is equivalent and works on both. Surfaced by the CI workflow added in this branch, which is the first thing in this repo to run the frontend suite anywhere but a developer's machine. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(build): copy the settings contract into the container build context Both Dockerfiles copy cmd/, internal/, migrations/ and web/embed.go, but the manifest lives in contracts/settings/v1 — an embedded Go package that sits outside internal/ because clients vendor those files. The image build therefore fails with "no required module provides package .../contracts/settings/v1". Caught deploying to the dev box. Nothing had built an image since the manifest landed: the Docker workflow only runs on pushes to main and workflow_dispatch, and CI's go build runs against a full checkout, so neither gate covers the container context. This would have broken the published image on merge. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(settings): enforce the language-tag and step constraints the manifest declares A sweep of all 43 manifest definitions against the running server (160 checks: declared default, both boundaries, and deliberate violations for each remote key) found two places where the live registry accepts what the contract forbids. Both are fixed by calling the contract's own validators rather than adding a second implementation. playback.audio_language was checked as "32 characters or fewer", so the server stored "!!!" for a field the manifest declares as language_tag — a value track matching would then silently never match. It now requires a well-formed tag via settingscontract.NormalizeLanguageTag. The empty string is still accepted: the string-only endpoint has no way to send null, and both Android and web send "" to clear the choice, so rejecting it would break clearing the preference. player.playback_speed declared step 0.05 and nothing enforced it, so 0.26 was stored — a value no client's stepper can represent and that every client would silently snap on the next write. settingscontract.StepAligned is now exported and used by both the contract validator and the registry, so there is one definition of "on step" rather than two that can drift. This gives the contract its first production consumer beyond the startup load, which is the direction Phase 2 continues in. Also fixes a genuinely flaky test that the new CI gate would have hit intermittently: TestRemoveJellyfinCompatWebDisablesWebSetting used t.TempDir as the install root, but the endpoint returns 202 and its goroutine keeps writing there after the test body returns, so cleanup tripped "directory not empty" roughly one run in four. Confirmed pre-existing and unrelated to settings; the suite now passes six consecutive full-package runs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(settings): keep widened numeric bounds resolvable at older revisions A bound was one scalar plus the revision that introduced it, which discards the value it replaced. Widening a maximum from 240 to 480 at revision 3 left a revision-3 client with no correct answer against a revision-1 server: honoring 480 offers values that server rejects, and filtering the tagged bound out leaves the setting unbounded. Since clients are specified to filter their pinned contract against the server's advertised revision, the bound has to carry what it used to be. Bounds now hold their full history, oldest first, and AtRevision hands back the limit a given peer actually enforces. A bound nobody has widened still serializes as a bare number, so the manifest reads the same and untouched entries do not churn the ETag. Validation gains the rules the representation makes checkable: a maximum may only grow and a minimum may only shrink, history is strictly ordered, later entries must say when they arrived, and the first entry cannot predate the definition. That last rule is the lower bound allowed_scopes already enforced; the same gap is closed for enum members, which could previously claim to predate the definition containing them. Reported by Codex review on #479. * fix(settings): accept the partial subtitle appearance objects already stored The schema required all nine properties, but the current API accepts and round-trips sparse objects — settings_device_test.go stores {"fontSize":"xxlarge"} and reads it back — and the web client has always merged whatever it gets over DEFAULT_SUBTITLE_APPEARANCE. Requiring the full object would have made the cutover migration quarantine preferences users really set, or block on them. Every property is now optional and a stored value is documented as a sparse override merged over the definition's complete default. An empty object is still rejected: an override that overrides nothing is the same state as no override, which the contract represents as unset. Cross-scope resolution is deliberately unchanged. A device override still replaces the profile's object rather than merging into it, because a device override means "draw subtitles this way on this screen", not "amend the profile" — and that is what the server does today. Reported by Codex review on #479. * fix(jellycompat): scan the parent directory when a sidecar changes Autoscan matched scantrigger rejections by comparing RequestError.Message against literal strings. One of those messages became "Unsupported media file extension for library type" and the copy in handlers_autoscan.go did not, so the comparison silently stopped matching. The effect is user-visible: a Jellyfin client posting a change for Movie.nfo or poster.jpg gets a 400 and the batch is abandoned, when the sidecar should have resolved to a scan of the directory containing it. Three tests covered exactly this and had been excluded rather than read. RequestError now carries a Reason the caller can switch on. Message stays prose for the client reading the response — it is meant to be reworded, and nothing should break when it is. Also makes two tests honest about asynchronous work. The Jellyfin Web teardown deleted its install root while the operation goroutine was still writing to it, where a late write recreates a path RemoveAll already walked past; it now waits for the operation's terminal state, which required exporting CurrentWebOperation. And the direct-play If-Range test pinned size and mtime so ctime was the only remaining validator, then read it back inside a single coarse-clock tick — it failed about 85% of the time on main for a reason unrelated to what it tests, and now rewrites until the stamp moves. With those fixed, GOTEST_KNOWN_FAILURES is empty and gone: make test-go runs the whole Go suite. The one test that cannot pass yet — TestHandleReplanPlaybackV3SeekFailureRecoveryNeverChangesMediaVersion, which has failed since the commit that introduced it and describes unimplemented v3 planner behavior — carries a t.Skip explaining that where the test is, rather than a regex in the Makefile. Reported by CodeRabbit review on #479. * fix(settings): reject JSON the decoder would otherwise rewrite Two cases where encoding/json accepts input by quietly changing it, which is the one thing a contract promising byte-identical agreement between peers cannot tolerate. Duplicate object properties. jsonschema.UnmarshalJSON keeps the last occurrence, so {"fontSize":"small","fontSize":"large"} validated and stored "large". Which one wins is a property of the parser, not of the contract: a client generated against a different JSON library can disagree about what it just sent, and the canonical form cannot represent the duplicate at all. Lone surrogates. An unpaired \ud800 became U+FFFD and canonicalization reported success, so the server would issue canonical bytes and an ETag for an artifact a conforming implementation must refuse — RFC 8785 requires terminating here. Substitution also means the value read back is not the value written. Both checks run before the decode that would hide them, on the shared decodeJSON path that the manifest, its public projection and every value schema go through, and again on the object branch of ValidateValue, which uses a different decoder. Reported by Codex review on #479. * ci: gate Go lint on the lines a branch changes AGENTS.md told contributors CI ran the same checks as `make lint`, and the Go job ran only gofmt and vet. A change failing the documented Go lint gate passed all three jobs. Running the linter as-is is not an option: the tree has ~296 findings today, which is why this half of `make lint` was never enforced. Blocking every PR on a cleanup nobody has scheduled gets the gate deleted again, so CI runs with --new-from-merge-base and only the lines a branch touches have to be clean. The count can then only fall. golangci-lint is built from source at a pinned version rather than downloaded. A released binary refuses to run against a Go newer than the one it was built with, and go.mod here tracks Go closely enough that the current release already fails that way on 1.26.4. .golangci.yml declared version 2 while still using v1's issues.exclude-rules key. Current golangci-lint ignores it, so the "allow repeated strings and unchecked cleanup errors in tests" exclusions silently did not apply — 16 findings in test files that the config says to skip. Moved to linters.exclusions, which `golangci-lint config verify` accepts. The four lines this surfaced in scantrigger are fixed rather than excluded: its repeated status codes and messages are now named constants, so one condition cannot end up worded two ways. Also drops the workflow token to contents:read and stops persisting credentials in the three checkouts, neither of which any job needs. Reported by CodeRabbit and Codex review on #479. * docs(v1): record the settings removal as a pre-lock exception The design removes the legacy /api/v1/settings routes and the profile DTO preference fields, while AGENTS.md states /api/v1 is additive-only and removals go through Deprecation/Sunset. Read together those contradict. They do not actually conflict: v1-scope.md scopes the additive-only rule to "when the scope locks", and the scope is still open, so a removal taken now is in scope and there is no amendment process to invoke yet. But that reasoning lived only in the settings design, where nobody checking the API policy would find it. v1-scope.md now carries a pre-lock removals table naming what goes and why waiting is worse, and states the deadline the argument depends on: a removal listed there must ship before lock or fall back to Deprecation/Sunset. AGENTS.md points at the table and says to treat an unlisted removal as a mistake. Reported by CodeRabbit review on #479. * fix(settings): clear the remaining review findings Small, unrelated except that each was raised on #479. compileObjectSchemas parsed every non-directory file under schemas/ as a JSON Schema, so a stray editor backup or .DS_Store would panic the server at startup through MustLoad. schema_ref can only name a .json file; anything else is skipped. cmd/silo used MustLoad while the ETag check beside it and every other startup failure use log.Fatalf. It now fails the same way, so a bad contract prints an error instead of a stack trace. TestRegistryDefaultsMatchTheContract called scalarDefault before handling null, and scalarDefault rejects null as non-scalar — so the subtest skipped and the comparison after it was unreachable. A nullable contract default could disagree with a non-empty registry default and nothing failed. Confirmed by injecting that drift, which now reports it. The three appearance providers each adapted the auth context to AppearanceAuth with identical code, putting the shape of auth back in three places that widening cache ownership would have to find. useAppearanceCacheOwner now does it once. useTheme.test.ts cleared storage.KEYS between cases, but appearanceCache writes namespaced keys and an owner pointer that are not in that list, so both survived and the suite was order-dependent. It clears the store, as storage.test.ts already did. The abs_smart_collection_store comment is reworded rather than given back its SQL quotes: gofmt folds a pair of apostrophes in a doc comment into a typographic quote, which is how it became one in the first place. Reported by CodeRabbit review on #479. * feat(settings): add canonical typed storage for the settings contract The cross-platform settings contract needs one typed store behind it before a resolver, routes or a migration can exist. This adds that storage to both user-store backends and holds them to identical behavior. PostgreSQL gets user_setting_values with the scope CHECK constraints, the five partial unique indexes that enforce one explicit value per identity, and the covering indexes the one-query read path needs, plus user_setting_mutations for mutation_id idempotency and the inert user_setting_migration_rejects audit table. The per-user SQLite store gets the same shape minus user_id, since that database is already user-scoped. The UserStore interface grows the typed operations: read one explicit value at one scope, collect every candidate row for a resolution request in a single query, upsert with a revision increment, unset, and the idempotency receipt operations. The resolution read deliberately returns unranked candidates so the resolver can rank in Go — one query per request, never one per scope, which the pgx query-count test pins. Delete behavior is application-enforced. Neither backend can inherit it from constraints: the SQLite store declares no foreign keys, and library, series and device columns are not FK targets in Postgres either. Profile deletion cascades to profile-anchored values while account scope survives, forgetting a device clears its profile_device values alongside the legacy overrides, and the library/series purges remove only what is scoped to that entity. The shared conformance suite covers all of it, including the set-versus-unset distinction for false, 0, "" and null, so a divergence between the two backends fails a test rather than reaching a client. Part of #376 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test(settings): pin the settings-value schema constraints in both backends Completes the storage track. The conformance suite exercises the store API, which validates identities in Go before any SQL runs — so nothing noticed whether the CHECK constraints and partial unique indexes actually existed. The one-time migration writes these rows in bulk without going through the per-request path, so the schema is the only thing guarding it. Adds constraint tests to both backends covering every scope's column requirements, rejection of an unknown scope, a profile that does not exist, non-JSON values, and each of the five partial unique indexes. Also clears the lint the storage commit did not get to: sql.ErrNoRows and pgx.ErrNoRows compared with == rather than errors.Is (which fails on a wrapped error), an unchecked rows.Close, and repeated fixture literals in the shared suite now named so a backend that confuses two scope columns fails on the assertion rather than on a typo. * fix(settings): close the review findings in the validator and the theme cache Four defects the existing tests did not reach. The web theme resolver compared the server's value against the appearance cache and fell back when they agreed, but the mirroring effect writes the server's value into that same cache — so the comparison held on the first render and stopped holding on the second, reverting an explicitly chosen theme to the default. The server's value is this account's own stored choice, so it now simply wins. The regression test re-renders rather than asserting on the first paint, which is why the original one passed. golangci-lint's exclusions.paths is a path regex, not a directory list, so a bare `web` also excluded internal/jellycompat/web_component.go, internal/webhooksync/, internal/notifications/webhook*.go and eleven other non-test files that were being linted before. Anchored. json.Number is a string kind, so `"1.5"` unmarshalled into it happily and Float64 parsed the quoted digits: a numeric setting validated as a JSON string and NormalizeValue stored the quoted form into jsonb. Rejected. The lone-surrogate check ran only on the object branch, so a lone surrogate in ui.custom_css decoded to U+FFFD on SQLite and was refused outright by Postgres jsonb — the two backends disagreeing about whether the same value could be stored. Hoisted to cover every type. The strict language-tag validation this branch added is correct, but it rejects what the shipped Android client sends; the companion fix is silo-android 4aeb78b4. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test(auth): stop TestJWT_TamperedToken passing a valid signature The test overwrote the last character of the signature with "X". An HMAC-SHA256 signature is 32 bytes, so its base64url encoding is 43 characters and the final one carries only four significant bits — U, V, W and X all decode to the same trailing byte. Roughly one token in sixteen was therefore left byte-identical and validly signed, and the test failed because ValidateToken correctly accepted it. Measured at 3098/50000 (6.2%) over distinct signatures; it just failed the Go job on this branch for reasons unrelated to the branch. Flipping a character in the middle of the signature is 0/50000. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(settings): reject raw invalid UTF-8, not just escaped surrogates The previous commit hoisted the lone-surrogate check to cover every value type, but that only closes the escaped path. A raw 0xff byte inside a quoted string — what an HTTP body carries when a client encodes text in the wrong charset — is not an escape, so the surrogate scan never sees it, while encoding/json still substitutes U+FFFD and reports success. NormalizeValue then stores the original bytes, which SQLite's json_valid accepts and Postgres jsonb refuses: the same backend divergence, reached the other way. Found by the Codex review bot on the previous commit's own diff. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(settings): size the library page state bound to what the web client writes ui.library_page_state's `search` was bounded at 256 characters. The web client serializes an advanced library view as URLSearchParams, encoding each filter rule as three groups[i][rules][j][field|op|value] keys — measured at 216 characters for one rule, 518 for three, 820 for five. The current endpoint validates this key by checking only that it parses, so those oversized values are already stored in production. Typing them at the declared bound would have failed the migration for anyone who had saved a view with more than one filter rule, and rejected the equivalent write afterwards. Raised to 4096, which clears ten rules with room to spare while staying a real bound. The test pins it against the key shapes libraryPageSearchParams.ts actually emits rather than a round number. Reported by the Codex review bot; the lengths above were measured by calling serializeLibraryPageSearchParams, not estimated. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(settings): split quality into two axes and register the orphan keys Two manifest changes the cutover needs. **Quality becomes resolution + bitrate.** The legacy ladder values (1080p-high, 720p-medium, 1080p-8, 420p, 328p) were never a third dimension — they are a bitrate spelled into the resolution string. The web player already decomposes them: useTranscodeQuality.ts defines 1080p-high as {resolution: 1080p, bitrate: 10000} and sends the two separately, so the compound form never reached the wire. Downloads went further and kept only a bitrate ladder. So playback.preferred_quality keeps the six clean resolutions and playback.max_bitrate_kbps becomes the second axis, nullable because "uncapped" is a real answer and a numeric sentinel would need widening every time hardware improves. Clients compose their own presets from the pair, which means retuning what "High" means is a client release rather than a contract break. Migration decomposes each legacy value losslessly, so none of them lands in the rejects table. **The five extension-bag keys are now definitions.** card_overlays, next_up_mode, sidebar_pins, disabled_library_ids and library_order reached the server only through the unknown-key path, stored as unvalidated strings. Two of them the server reads back — next_up_mode decides home section assembly and card_overlays falls back to an admin default — so they cannot be demoted to client-local. Registering them is what lets the extension bag close. Adds three schemas for their shapes and a test that exercises every schema_ref against a real value: each of these is nullable with a null default, so the existing default-validation test returns at the null branch without ever compiling the reference. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(settings): add the canonical resolution engine One answer to "what is this setting, for this profile, on this device, for this content". Before this, each caller carried its own ladder: catalog/detail.go resolved subtitles across four levels by hand and audio across three, handlers/settings.go had a two-level device/user resolution with a lazy write-back inside a GET, and jellycompat read profile columns directly. Those disagreed about precedence, which is the drift the contract exists to remove. Resolution is one batched read regardless of how many keys, libraries, or series are in play — ranking happens in Go against each definition's declared resolution_order. Five sequential index lookups per key per item is the implementation the design rejects, and a season view is exactly where it would have shown up. An absent identity drops its scope rather than erroring, so one code path serves an identified client, an anonymous jellycompat seed, and a batch spanning many series. Rows for a foreign profile, device, library or series are ignored even though the batched read returns them. Constraints narrow without destroying: a capped 4K preference resolves to the cap, reports itself constrained, and keeps the authored value so it takes effect the day the cap lifts. Two cases needed care — null on a nullable numeric means unbounded, so a ceiling must cap it rather than rank it equal and let the value that most needs capping slip past; and an allowlist falls back to a permitted member rather than the definition's default, which may itself be outside the list. Adds ValueSchema.CompareValues to the contract package, since ordering values is what makes a ceiling or floor mean anything and value semantics belong with the schema that declares them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(settings): add the one-time migration planner The conversion rules from legacy settings storage to canonical values, as ordinary Go rather than twice in two SQL dialects. Both backends read their own rows, hand them to Plan, and write what comes back — so the decisions are testable without a database and SQLite and Postgres cannot drift apart in what they decide. The rules that needed care, each pinned by a test: Column defaults are not choices. quality_preference is NOT NULL DEFAULT '1080p' while the contract defaults to auto, so migrating the column unconditionally would pin every profile in the install to 1080p having never chosen it — and that stored value would then outrank the contract default forever. Same for language 'en', subtitle_mode 'auto', and show_forced_subtitles true. The empty string is unset, not a value. The legacy string API had no way to send null, so both Android and web spell "clear my choice" as "". Storing that would make a cleared setting outrank the default. Legacy quality decomposes rather than rejects. Every compound value maps to a resolution and a bitrate from the ladder in useTranscodeQuality.ts, so nothing lands in the rejects table. Account rows fan out to every profile, which is the account-to-profile move the contract makes for appearance and search scope: a household that shared one theme each end up owning theirs. Legacy strings become typed JSON — "true" to true, "30" to 30 — or every generated binding would fail to decode what the migration wrote. Nullability differs per backend, so profile columns arrive as pointers and the caller resolves "chose the default" versus "never written" when it reads. jellycompat's DisplayPreferences blobs ride the same table under synthetic keys and are left alone; they are that subsystem's storage. Everything that cannot convert is recorded with a reason rather than dropped, and a final test asserts every planned row would be accepted by the mutation endpoint's own validation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(settings): run the one-time migration on the SQLite backend Wires the planner to real storage as userdb migration V15. V14 created the tables; this fills them. It runs inside runMigrations' existing transaction, so a database either comes out fully migrated or untouched — a partial migration is the one state neither the operator's backup nor a rollback covers. Pinned by a test that rolls back and asserts nothing was left behind. Two things the wiring had to get right that the planner could not see: Reject identities are JSON. Postgres declares that column jsonb NOT NULL and SQLite guards it with a json_valid CHECK, so the free-form "profile=p1 device=d1" the planner emitted would have failed to insert — on exactly the rows the table exists to record. They are structured documents now, which is also queryable. Subtitle and audio preferences are two tables keyed the same way, so they merge into one per-series record before planning. Converting them independently would have produced two rows racing for the same identity. Every legacy read tolerates a missing table, since this runs against databases created at any schema version, and preferred_metadata_language is deliberately absent: that column exists only in the Postgres schema. Tested end to end against a real database rather than only through the planner — the rows land, satisfy the scope CHECK and the partial unique indexes, and hold valid JSON. Also covers the empty-install case and asserts a second run fails rather than silently doubling every value. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(settings): run the one-time migration on the Postgres backend The mirror of userdb V15, registered with goose as a Go migration rather than SQL: the conversion validates every value against its own definition and re-encodes it as typed JSON, and one legacy quality string becomes two rows — neither is expressible in SQL without duplicating the manifest. The rules stay in internal/settingsmigrate, so the two backends cannot disagree. RunTx, so the whole backfill lands in goose's transaction. The down migration empties the canonical tables; the legacy ones are never touched by the up, which is what keeps the cutover reversible until the follow-up migration drops the superseded columns. preferred_metadata_language is read here and only here — the column exists in this schema and not in SQLite's, so this is the sole source for catalog.metadata_language. Verified against a real Postgres: the full goose chain runs, 1080p-high decomposes to ("1080p", 10000), values land as typed jsonb rather than strings (jsonb_typeof reports number), rejects carry a queryable jsonb identity, and the composite profile foreign key refuses a row naming a profile that does not exist. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(settings): add the canonical settings API The routes that make the typed storage reachable. Until now the manifest, the resolver and the migration all existed with nothing able to call them. GET /settings/contract serves the public manifest behind an ETag — clients vendor a pinned copy and generate bindings from it, so the common request asks "still the same contract?" rather than transferring it. Its capabilities sibling reports revision and supported scopes for feature detection instead of version sniffing. /settings/values/{key} reads, writes and clears an explicit value at one named scope, which is what a reset affordance needs: "did I set this here" is a different question from "what applies", and the old endpoint could only answer a blurred version of both. Scope comes from the query while profile and device come from session headers, so one profile cannot address another's settings by naming it. /settings/values/effective resolves any number of keys in one request, with the resolution ladder and the source of each answer reported so a client can offer "reset this device's override" against the exact row holding it. Asking for no keys returns every remote setting, which is what a settings screen wants. Writes are idempotent when a client sends X-Silo-Mutation-Id: a retry after a dropped response replays the receipt, and reusing an id with different content is a conflict rather than a silent overwrite of the wrong thing. Three things the string-only endpoint could not do, each pinned by a test: an unknown key is refused rather than stored in the extension bag, values are checked against their declared type and range, and a write to a scope the definition does not allow is rejected. Registered before the catch-all /{key} routes, which would otherwise swallow "contract" and "values" as setting names. The legacy endpoints stay live for now; deleting them is the next commit, once their consumers move. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(settings): generate typed bindings for all four languages One generator rather than one per repo. The point of the contract is that four codebases agree on keys, types, scopes and defaults, and four independently written generators would be four chances to disagree. Go and TypeScript land in this repo; Kotlin and Swift are written into the sibling client checkouts, skipped with a note when they are not present so a server-only developer can still run it. Output is sorted by key so an unrelated manifest edit does not produce spurious diffs. The Kotlin output is the interesting one: it generates the DeviceSettings allowlist Android maintained by hand, plus the BOOLEAN_KEYS/INT_KEYS/ DOUBLE_KEYS classification it kept as a *second* hand-maintained table that had to agree with the first. Both are manifest questions now, so the whole class of "wrote a local key to the server" and "flushed a value the store could not parse" bugs stops being possible by construction. The TypeScript output carries the full definition table — labels, controls, enum members, bounds — so web/src/lib/settingsManifest.ts can be deleted rather than kept in sync: it declared 17 definitions against the contract's 49, with its own two-scope model that does not match the contract's five. make verify-settings-bindings fails when the committed output disagrees with the manifest, wired into CI, so a manifest change cannot merge leaving every client reading stale keys. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(web): add the two-axis quality picker and typed settings hooks Quality becomes one picker over two stored values. The server holds a resolution cap and a bandwidth cap independently, which is what the player has always sent on the wire — useTranscodeQuality.ts has decomposed 1080p-high into {resolution, bitrate} for as long as it has existed. Presets live in the client rather than the contract so retuning what "High" means is a one-line edit here instead of a contract change four codebases have to agree on, and an older server keeps working because it only ever sees the two axes it already understands. A combination no preset covers still gets a truthful label rather than a picker showing the wrong entry: reachable by setting the axes separately through the API, or from a legacy value whose bitrate is off this ladder. Choosing an uncapped preset clears the bitrate rather than storing a sentinel, so "no cap" stays the absence of a value at every layer. Adds hooks over the canonical API alongside the legacy ones rather than replacing them wholesale — a key that is not in the manifest cannot be expressed, because SettingKey is generated from it, and the default for an unset value comes from the generated table rather than a literal at the call site. That last part is what stops the flip-off bug the Apple client carries a hand-written guard for. A test asserts every preset composes values the contract actually accepts, so a preset naming a resolution outside the enum or a bitrate outside the declared bounds fails here rather than 400ing when a user picks it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(settings): resolve catalog playback preferences through the contract catalog/detail.go held the two hardest ladders in the codebase: subtitles resolved across four levels by hand, audio across three, each partially overriding the last through Has* flags. Both now call the canonical resolver, so the precedence lives in the manifest and this file cannot disagree with the contract about which override wins. Adding a scope is a manifest change rather than another branch here. The subtitle track signature stays on its specialized table — it identifies a concrete track rather than expressing a preference, so it is not a setting. Resolution keeps the memoization the old lookups had: the audio resolver still reads once per profile and once per library rather than once per file, which is what kept a many-track audiobook detail page fast. The test that guards it now counts resolver reads instead of GetProfile calls, since the guarantee is about scaling with file count rather than about which method does the reading. Four tests seeded the profile column directly. That column is a migration source now, not a read path, so they seed the canonical value instead — they were passing against storage nothing reads. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(settings): close the unknown-key extension bag keyUsesUserScope returned true for any key the registry did not know, so a client could invent a production setting unilaterally and the server stored it as an unvalidated string. That is how six ui.* settings and five orphan keys reached production untyped, and it is the root enabler the design names. An unknown key is no longer a user setting, so the legacy write path rejects it and the canonical API — which validates every value against its own definition — is the only way to store something new. jellycompat's DisplayPreferences blobs ride the same table under synthetic keys and keep working: they are that subsystem's storage rather than user settings, and they move to dedicated storage in the follow-up rather than being dropped here. Also repoints the DisplayPreferences seed at the canonical resolver. Resolved at profile scope with no device on purpose — Jellyfin clients do not carry Silo's device identity, so a device override leaking into the seed would hand one device's settings to every Jellyfin client on the account. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(settings): enforce viewer quality caps through resolver constraints constraintsFor was the unwired half of the preferences-versus-restrictions seam: it returned nil, so a profile capped at 1080p by policy still resolved its stored 2160p preference at face value through the effective endpoint. The settings routes are mounted inside RequireViewerAccess, so the resolved access scope is already on the request context. Scope.MaxPlaybackQuality holds a literal member of the contract's quality enum ("1080p"/"2160p"), which is exactly what the manifest binds playback.preferred_quality's ceiling to under policy_input "max_playback_quality" — so the wiring is a direct map with no translation table. An empty value means the policy sets no cap, expressed by returning nil so the resolver leaves the preference alone. catalog.metadata_language deliberately stays unconstrained: the manifest notes record that the allowlist draft was circular (the policy input it would bind to is populated from the very preference it would narrow). The handler test covers both halves of the seam: a 2160p preference under a 1080p cap resolves to the cap with constrained:true/ceiling and the authored value reported in stored_value, the stored row itself is not rewritten, and an uncapped viewer gets the preference unchanged with no constraint noise. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * feat(settings): publish user_settings change events Add a user_settings realtime channel so clients learn when a setting changed on another device without polling. The channel is modeled on user_state: non-admin subscribable, per-user addressed envelopes, null snapshot. SettingValuesHandler gains an EventsHub and publishes user_settings.changed after every successful PUT and DELETE on /settings/values/{key}. The payload carries only key, scope and profile_id — never the value. Admins receive every user's user-scoped events, so a value in the payload would leak private settings to admins; interested clients re-fetch over the scoped REST API instead. The payload is always non-empty because an empty Data falls back to a null snapshot in the hub. A nil hub (tests) skips publishing. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * feat(settings): sweep expired mutation receipts daily Setting-mutation idempotency receipts were written with an expires_at that nothing enforced, so the table grew forever. Add a hidden daily system task (05:00) that walks every login account, opens its user store, and calls DeleteExpiredSettingMutations. A user whose store fails to open or sweep is logged and skipped so one broken store cannot stall retention for everyone else; the delete is idempotent, so the next run repairs anything missed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * refactor(settings): resolve metadata language canonically in access and policy Repoint the last legacy column readers onto canonical contract resolution (settings cutover task A4a): - access.Resolver and policy.ViewerResolver now resolve catalog.metadata_language through settingsresolve (profile scope -> contract default) via a shared access.PreferredMetadataLanguage helper, instead of reading user_profiles.preferred_metadata_language. Resolution is deliberately unconstrained: the policy input this preference feeds is the one a constraint would have to reference, which is circular — see the key's manifest notes. - playback start now resolves playback.audio_language canonically for the profile default instead of reading user_profiles.language, matching the catalog detail path. Series and library override handling is unchanged. - items.go needed no change: it already consumes the resolver-produced scope.PreferredMetadataLanguage. The legacy columns keep their values but are no longer read on these paths; a profile with only a column value now resolves to the contract default, and a stored canonical value wins. Tests pin both directions in access, policy (including scope parity, where the column is now a decoy), and the playback handler. Read cost is one batched store read per resolution, same as the profile-row read it replaces. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * refactor(jellycompat): give DisplayPreferences its own table The Jellyfin DisplayPreferences blobs rode the legacy user_settings key/value table under synthetic jellycompat:* keys, which forced the legacy settings API to carry a prefix carve-out in its otherwise-closed unknown-key gate. They are the compat subsystem's storage, not user settings: the contract neither validates nor resolves them. Move them to a dedicated jellycompat_displayprefs table in both backends, keyed by (prefs id, client) per user, with the blob stored as opaque text served back byte-for-byte (deliberately not jsonb, which would re-serialize it). The data-copy migrations — per-user SQLite V16 and a paired SQL + Go goose migration for Postgres — are transactional and harmless to re-run, and both drive their key parsing and row classification from the new internal/jellycompat/displayprefs package so the backends cannot diverge, following the internal/settingsmigrate precedent. A jellycompat:* row that does not parse as a DisplayPrefs key (only ever writable through the removed carve-out) is recorded in user_setting_migration_rejects rather than silently deleted. With the last non-settings tenant gone, the jellycompatSettingPrefix carve-out is deleted: the legacy settings endpoints now refuse jellycompat:* keys like any other unknown key and never surface them. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * feat(settings): serve admin user-settings through the canonical API Replace the ten string-registry /admin/users/{id}/settings* and device-settings* routes with the canonical contract surface: one list of every explicit value the target user has stored across all scopes, and set/delete at an explicit scope named in the query string. The admin handlers live on SettingValuesHandler and share the session routes' implementation rather than duplicating it — the same key/scope parsing, identity validation, contract scope allowance, value normalization and mutation-receipt idempotency, factored into keyedScopeFromRequest/completeIdentity and setValueAt/deleteValueAt. The only admin-specific parts are the target user coming from the path, profile and device ids coming from the query (an admin holds no session claim to the user being inspected, so its named profile is checked to exist), and change events attributed to the target user so their clients refresh. The list is a new UserStore read, ListAllSettingValues, implemented in both backends and pinned by the shared storetest conformance suite: the admin surface wants the stored truth (which overrides exist, for a per-row reset affordance), which no resolution-shaped read answers. The ten removed routes are recorded in the pre-lock removals table in docs/architecture/v1-scope.md per the v1 API rules; the web admin device-overrides page moves onto the new surface in the Phase B rewrite inside this same unmerged PR. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * test(settings): add the cross-platform conformance fixture and its Go and web runners contracts/settings/v1/conformance.json is the spec's named drift gate: 21 hand-authored cases of {keys, stored rows, context, constraints, expected effective value + source}, every one executable against the shipped manifest. They pin the semantics most likely to drift across four resolver implementations: the full resolution ladder (series > library > device > profile > default), an absent identity dropping its scopes, foreign-identity rows never resolving, ceiling caps that report the authored value with constrained:true, the ordered-enum sentinels (auto below every cap, original above), null-on-a-nullable-numeric meaning unbounded and being brought down by a ceiling but ignored by a floor, allowlist falling back to the first allowed member rather than the (possibly forbidden) default, and playback.subtitle_appearance resolving device > profile only with the sparse device object replacing, not merging. Cases may inject a constraint binding onto a copy of a real definition so constraint kinds no shipped definition carries stay testable. The Go runner (internal/settingsresolve/conformance_test.go) resolves each case through the real resolver against the embedded manifest. The web runner (web/src/lib/settingsConformance.test.ts) runs the same cases through a new client-side resolver, web/src/lib/settingsResolve.ts, which mirrors the server's semantics; the TypeScript bindings now carry each definition's ordered flag and constrained_by binding so that resolver derives constraint behavior from the contract instead of hardcoding it. Both runners reject unknown fixture fields — schema drift in the fixture itself is drift — and both refuse a fixture authored against a different manifest revision. The fixture travels with the bindings: make settings-bindings vendors the copy the web runner reads, and make verify-settings-bindings fails CI when that copy goes stale. The Kotlin and Swift copies land together with their runners in the client repos, which will pick their own test-resource paths. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(settings): review pass over the phase A stack Fixes the eight adversarially-confirmed defects the review of the unpushed phase A stack (40e0f77a..1f2c7fe4) found, each with a test that fails without its fix. Writers left behind by the language cutover (high).22e9d7f1made access, policy and playback start resolve catalog.metadata_language and playback.audio_language exclusively from user_setting_values, but POST/PUT /profiles — the write path the shipped web UI uses — still wrote only the legacy columns, so a language change after the one-time backfill never took effect (a stale backfilled row, or the contract default, won forever). Profile mutations now mirror their preference fields into the canonical profile-scope rows through the same contract validation /settings/values applies (audio, subtitle and metadata language, subtitle mode, forced subtitles; the empty string clears the row, matching the migration's unset spelling), publish user_settings.changed for each row moved, and 400 on a value the canonical endpoint would refuse. quality_preference is deliberately not mirrored: the server never resolves the legacy column and the two-axis picker already writes canonically. Web admin settings 404s (high + medium).facad78dremoved the ten /admin/users/{id}/settings* and device-settings* routes but shipped no web changes, so the user-detail settings and device-overrides tabs and the devices-page override editor were dead. The seven admin hooks now speak the canonical values API: one list across all scopes feeds both tabs, mutations address an explicit scope identity, values re-type through the generated contract (display stringifies for the registry-era controls), device rows are enriched with device and profile names client-side, and the removed bulk device reset becomes per-key deletes that treat 404 as already-reset. Silent metadata-language degrade (medium). PreferredMetadataLanguage now logs a warning with the profile and error when contract load or store resolution fails, so pool exhaustion is distinguishable from "no preference"; the healthy paths stay quiet. Displayprefs move data loss (medium). Under READ COMMITTED the blanket pattern DELETEs in moveDisplayPrefs/unmoveDisplayPrefs could destroy a row an old-binary instance committed between the SELECT and the DELETE during a rolling deploy — reproduced against real Postgres. Both directions now delete only the exact rows they read (rejects restore by primary key), leaving a late row stranded for a re-run to pick up. Coverage the review proved missing (medium x3): admin mutations are now tested to attribute change events to the target user, not the acting admin (the exact regression passed the whole suite before); the user_settings websocket channel is subscribed through the real events websocket, failing if the channel is dropped from either allowedChannelsForRole or AllChannels; and the conformance fixture gains three locked-constraint cases (replace, equal-value pass-through, locked default) so the Go and TypeScript locked branches — previously executable by no test on either platform — are pinned by the shared drift gate. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * feat(web): read and write appearance and format preferences through the settings contract Move the four identity-sensitive preference hooks — useTheme, useCustomTheme, useDateTimeFormat, useSearchMediaScope — off the legacy string-only /settings endpoints and onto the canonical settings API. Each surface now reads through one batched useEffectiveSettings call and writes via useSetSettingValue at scope "profile", matching what the generated manifest declares: ui.theme / ui.text_scale / ui.text_weight / ui.high_contrast are profile-scoped with a profile_device override the effective read already resolves (no device-override UI exists, so writes stay profile-wide), and ui.custom_theme_vars / ui.custom_css / ui.date_format / ui.time_format / search.media_scope are profile-wide. Keys come from the generated SETTING_KEYS table, so a typo'd or unmanifested key can no longer be expressed. Because the canonical effective endpoint always answers — resolving unset keys to the contract default with source "default" — the hooks now use the source to distinguish "the profile chose this" from "nobody stored anything". That preserves the admin-default theme layering and keeps resolved-but-unchosen values out of the warm-start mirror. ui.theme moving account→profile scope means the appearance warm-start cache must not be shared by sibling profiles on one account, so appearanceCacheOwner widens its token from the user id to user id plus active profile id. Every cache read/write already resolves through that one function, so no call site could be left behind; the API→cache mirror, the render-time re-seed on identity change, and the debounced write cancellation all follow automatically. The ownership tests now cover profile switches within one account: no theme/text-scale/CSS leaks between profiles, each profile's warm start survives the switch, and a debounce armed by one profile never persists under its sibling. Part of the Phase B settings-contract cutover; the legacy hooks in queries/settings.ts keep their remaining callers until B4 deletes them. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * feat(web): store library, sidebar, and overlay preferences through the settings contract Phase B2 of the settings-contract cutover: the query-layer preference stores — sidebar pins, library page state, disabled libraries, library order, and card overlay prefs — move off the legacy string-valued /settings endpoints onto the canonical values API, using generated SETTING_KEYS and each definition's declared scope (profile for pins, visibility, order, and overlays; profile_device for page state and the remember toggle). Values are now written as typed JSON matching the contract schemas (sidebar-pins.json, library-page-state.json, library-id-list.json, card-overlays.json) instead of JSON-encoded strings, so the encoding the migration produced keeps validating. Every parser accepts both the canonical object value and the legacy string encoding, so nothing breaks while caches or older rows still hold strings. Semantics preserved deliberately: - Sidebar pin toggles keep their optimistic update with the revision-guarded rollback, now layered on the effective-settings cache entry (effectiveSettingsQueryKey is exported for exactly this). - The remember-library-pages toggle clears the device override to inherit again rather than storing the default, via useClearSettingValue; the canonical DELETE's 404 for "nothing stored" is treated as already-done, matching the legacy delete's idempotency. - Overlay prefs keep the admin default / kill-switch layering: the contract default null means "no preference expressed", which is what lets /settings/overlay-config defaults apply, and only a stored value overrides them. - Library visibility/order keep their optimistic local state with rollback on error; ids are normalized client-side with the same rules library-id-list.json enforces. parseDisabledLibraryIDs/parseLibraryOrder collapse into one parseLibraryIDList (they were byte-identical), and the serialize helpers disappear with the string encoding. Legacy hooks in queries/settings.ts stay for the remaining consumers until B4. Part of the settings-contract cutover (see docs/superpowers/specs/2026-07-10-cross-platform-user-settings-contract-design.md). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * feat(web): write playback, subtitle, and library preferences at canonical scopes The settings screens and the player panels were the last web surfaces still speaking the legacy string API, and each carried its own idea of where a preference lives. Playback and subtitle behavior wrote profile columns through PUT /profiles; auto-play and next-up wrote untyped strings; subtitle appearance went through three bespoke routes that existed only because the string API had no way to express an object-valued setting per device. All of them now read one batched effective resolution and write typed JSON at an explicit scope. Where each preference lands follows the manifest rather than the endpoint that happened to hold it: - Playback and subtitle defaults, and next-up mode, write at profile. - Subtitle appearance writes playback.subtitle_appearance at profile_device, replacing /settings/subtitle_appearance/effective and the PUT/DELETE pair on /settings/device/subtitle_appearance. One hook now owns that value for the settings screen, the in-player panel, and the cue renderer, which before each parsed the effective response separately. - Per-library edits write at profile_library with the library identity, one key at a time. The legacy endpoint replaced a composite row, so clearing one field meant re-sending the other three and losing any concurrent change to them; independent per-key writes have no such coupling, and "inherit" is a delete rather than a sentinel. - The in-player series choice splits along the line the contract draws: language and mode are preferences and move to profile_series, while the track index and signature stay on /subtitle-prefs because they identify a concrete track rather than expressing a preference. Controls render from the generated SETTING_DEFINITIONS. The hand-written registry beside it had drifted — it declared several profile-only keys as device overrides, and disagreed with the manifest about the bounds of two sliders — so the display helpers now derive control shape, options, bounds, and the device-overridable key list from the contract. (Deleting settingsManifest.ts itself is B4; nothing outside its own test imports it any more.) Two follow-on fixes fell out of reading the contract rather than the registry. playback.auto_skip_recap and playback.auto_play_next_preview are declared at profile_device but only the intro override was ever consulted, so a device override on either silently did nothing; the player resolves all three now. And per-library "Original Language" is gone: the contract types these as BCP 47 tags, and the phase-A migration already rejects "original" at profile_library, so offering it would have written a value the server refuses. Risk worth naming: LibrarySettings decides "overrides" from the resolved source rather than by comparing values, which is what keeps three distinct cases apart — a library row holding the same value as the profile is still an override, and a library row holding null is an explicit "no subtitles" rather than an absent choice. A screen that compared values would collapse the first into "inherits" and the second into "unset". Part of #135 AI-assisted: authored with Claude Code; reviewed and verified by the committer. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * feat(web): refresh settings from the user_settings channel A canonical settings write reached only the tab that made it. The server already publishes user_settings.changed on every write and delete, but no web client subscribed, so a preference changed on a phone or by an admin sat stale here until a manual reload or the 5-minute staleTime expired. Subscribe the channel and treat the frame purely as an invalidation signal. The payload carries the key, the scope and the profile — never a value, because admins receive other accounts' user-scoped events and a value there would leak private settings. Marking the value queries stale lets react-query refetch only what a mounted screen is reading, and a burst of writes coalesces into one fetch per key rather than one per event. A profile-addressed change to a profile other than the signed-in one is dropped: it cannot alter what this tab resolves. Account-scoped changes carry no profile and always invalidate. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * refactor(web): render settings from the generated contract web/src/lib/settingsManifest.ts was a hand-written table of labels, controls, defaults and bounds sitting beside the generated contract, and it had already drifted: it declared profile-scoped keys as device overrides, disagreed with the server on the type and range of several keys, and enumerated a language subset narrower than the one the player speaks. lib/settingsDisplay.ts has derived all of that from SETTING_DEFINITIONS since the contract landed, and nothing but the manifest's own test still imported it. Delete the manifest and its test. The one piece it owned that the contract cannot express is the language list — language settings are typed as BCP 47 rather than as an enum, so there is no member list to render — which moves to lib/languageOptions.ts and is now derived from the shared player language list. Two shapes ship: NAMED_LANGUAGE_OPTIONS for a control that spells its own unset entry, and LANGUAGE_OPTIONS with the leading "no preference" row for a nullable setting. The per-library editor's LANGUAGE_OPTIONS re-export goes with it, so every language dropdown in settings now iterates one list in one shape. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(web): show canonical device overrides in admin devices The device detail panel read its override rows from GET /admin/devices/{user}/{device}, whose `settings` array still comes out of the legacy user_device_settings table. The settings-contract migration folded that table into user_setting_values and nothing writes to it any more, so an override created since the cutover — including one the admin had just saved through this very panel — was invisible here, while the migrated rows stayed visible. The panel's own writes go to the canonical route, which made the list look like it silently dropped edits. Read the overrides from the canonical values API instead, filtered to device scope and to this device. Both storage generations show, because the migration moved the legacy rows into the same table. The detail endpoint is still the source for registration metadata — device name, owner, which profiles have used it — which is not a setting and has no canonical equivalent. The override count and last-updated readouts move to the canonical rows for the same reason: override_count is computed over the legacy table and would disagree with the rows rendered underneath it. "Reset all for device" has no bulk canonical route, so it keeps issuing one delete per key, now over the keys that actually exist. The reset button also takes the profile id from the tab rather than from its first row, which a profile registered on the device with no override yet does not have. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * refactor(web): delete the legacy settings hooks hooks/queries/settings.ts spoke the string-only registry API: every value a string, scope implied by which function you called, and an unknown key silently accepted. Phase B moved every consumer onto the canonical value hooks, and the last importer left was the file's own test — so both go together, along with the client functions they were the only callers of. hooks/queries/libraryPlaybackPreferences.ts goes with them. It wrapped GET/PUT/DELETE /library-playback-prefs, which LibrarySettings replaced with profile_library-scoped canonical writes; nothing in web has called it since. The server route stays for now — the Android and Apple clients may still use it — but the web type and query keys have no reason to linger. settingsKeys keeps only `all` (the prefix the canonical invalidation targets) and the plugin entries, which are a different system. The list/detail/deviceDetail/effective builders described the registry's cache layout and had no remaining callers; effectiveSettingsQueryKey in settingValues.ts owns the canonical shape. hooks/useSettingsForm.ts is deliberately untouched: it edits admin server_settings through /admin/settings, which is a separate surface from the per-user contract, and has more than twenty live consumers. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(web): review pass over the phase B adoption Phase B moved the web client onto the canonical settings surface. Three scope mistakes slipped in, all of the same shape: a value written at a scope no UI can reach, shadowing the one the user can edit. Auto-play next. The post-roll toggle wrote profile_device while Settings → Playback wrote profile, and the contract resolves the device row above the profile row. Turning auto-play off in the player therefore made the settings switch permanently inert — it saved a profile value the device row kept shadowing and snapped straight back, with no web affordance able to clear the device row. Both surfaces now share useAutoPlayNextSetting, which writes the profile and clears any device row (also the only way a migrated per-device override becomes reachable). Before Phase B both writers used useSetDeviceSetting, so they could not disagree; this restores that invariant at the scope the rest of the Playback screen edits. In-player subtitle picks. handleSubtitleChanged wrote three canonical keys at profile_series, the top of the resolution ladder, while "Auto" on the item page still deleted only the legacy /subtitle-prefs row — so the reset silently stopped working and the abandoned language kept resolving for every episode of the series, forever. One of the three, show_forced_subtitles, was worse: the player has no forced-subtitle control, so the value it wrote back was the *resolved* one, which for a viewer who never expressed a preference is the contract default. That pinned the default above the profile-scope toggle on the Subtitles screen. The written set now comes from SERIES_SUBTITLE_SETTING_KEYS — language and mode only, both derived from the user's actual choice — and useDeleteSubtitlePreference clears exactly that list, so the writer and the reset cannot drift. show_forced_subtitles still rides the legacy composite row, which is keyed to a concrete track selection and is not part of the canonical ladder. Admin user settings. The tab now lists every non-device canonical row, which includes the object-valued profile settings (sidebar pins, card overlays, disabled libraries, library order, custom theme vars). It gated only on `definition`, and controlKindFor has no `object` branch, so those fell through to RegistrySettingControl's select — rendering a user's pins as a one-entry "Unset" dropdown whose only option nulls them. It now uses the same isStructuredSetting guard the device tab got, routing them to a raw JSON editor. Tests: each fix has a test that fails without it, verified by reverting the fix in place. The auto-play and subtitle tests resolve through lib/settingsResolve rather than a canned answer, so the scope-precedence assertions exercise the real ladder. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(settings): serve profile preference fields from canonical resolution PUT /settings/values?scope=profile writes only user_setting_values, but GET /profiles still served the legacy user_profiles columns. A preference saved through the canonical API was therefore invisible in every profile DTO reader on every platform — Apple's shipped build reads exactly those fields — while profiles_settings_sync.go mirrored one way only, legacy column write to canonical row. Serve those five fields (language, preferred_metadata_language, subtitle_language, subtitle_mode, show_forced_subtitles) by resolving their canonical keys through the settingsresolve seam at profile scope, falling back to the contract default rather than to the stale column. This matches the cutover direction taken everywhere else: the legacy columns stay written but stop being read, so "clear this preference" cannot resurface a pre-cutover value the one-time backfill already converted. The write paths that accept these fields and mirror them are unchanged; this is read-side only, and the DTO's field names and types are untouched. Resolution is batched. A profile list serves the whole household, so SettingResolutionQuery.ProfileID becomes ProfileIDs and the new Resolver.ResolveProfiles ranks every profile against one candidate set — one store read per list request instead of one per profile. Both backends carry the widened predicate and the shared storetest conformance suite gains a household case, so they cannot drift on it. quality_preference stays column-backed: the legacy column is one compound value while the contract splits it across playback.preferred_quality and playback.max_bitrate_kbps, so there is no lossless read. The auto_skip_* and auto_play_next_preview fields stay column-backed too — the sync path never mirrored them, so their canonical rows can lag the columns. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(web): repair CI findings after the main merge CI runs checks the local loop does not: golangci-lint (not installed here) flagged two unchecked Close errors in the new websocket test, and tsc -b (the tests were only vitest-run locally) rejected strict indexed-access in four test files touched by the review passes. The merge also brought main's onboarding tour, whose SettingControl wrote through the legacy useSetSetting hook this branch deletes — it now writes the canonical scoped mutation, re-typing the tour's string values through the generated contract like the admin surface does. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * style(settings): satisfy the incremental lint pass golangci-lint reports findings incrementally, so these three surfaced only after the previous fix: errors.Is for the pgx.ErrNoRows compare (wrapped errors), and named constants for the repeated "values" response key and the "usersettings" prefs id goconst flagged. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(database): pin the read value when deleting moved displayprefs rows Under READ COMMITTED the move's DELETE takes its own snapshot, so during a rolling deploy an old-binary instance could update a jellycompat row between the migration's SELECT and its delete — and the (user_id, key) predicate would destroy the newer value after copying only the older one. Naming the value the transaction actually read makes such a row survive as a stranded legacy row instead, the same disposition a late-inserted row already had. Extends the concurrent-write migration test to commit an update to an already-read row during the stall and assert the newer value survives. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(api): make canonical mutation writes honest under failure Three review findings on the canonical settings endpoints: - Idempotency receipts were recorded via defer, so a failed upsert still left a receipt and the client's retry replayed a success for a write that never happened. The receipt is now written only after the upsert lands, and it stores the actual response — revision and updated_at included — so a replay is byte-identical instead of a reconstruction of the input with revision 0. - The mutation envelope accepted trailing JSON after the first document, leaving the interpreted mutation parser-dependent. The decoder now requires EOF after the envelope. - Resolving a device-aware key without X-Silo-Device-Id silently skipped every stored device override and passed the profile fallback off as the effective value. The effective endpoint now fails closed with 400, matching the write path's existing requirement. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(settings): stop the contract rejecting values shipped clients store Four bounds in the contract were narrower than what a shipped client already produces, so real stored preferences would fail validation or be quarantined at migration: - The BCP 47 grammar rejected extlang tags (zh-cmn) and private-use-only tags (x-private) the legacy length-only validator accepted, turning an existing 204 into a 400. The pattern now covers both, and NormalizeLanguageTag cases a script correctly after an extlang and leaves private-use content lowercase. - subtitle_appearance.fontFamily allowlisted ASCII, contradicting its own description: Apple clients store CTFontManager family names verbatim and those are routinely CJK. The pattern now excludes unsafe characters instead of allowlisting ASCII. - theme-var-overrides capped CSS values at 128 characters, which real multi-stop gradients exceed; the web importer stores them unchecked. Raised to 1024. Plus one tightening the review asked for: card-overlays.order now declares uniqueItems, matching library-id-list, so an overlay cannot be rendered twice. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(userstore): reject non-canonical identities and bound resolution batches Three review findings on the canonical settings storage layer: - SettingIdentity.Validate trimmed ids only to check emptiness, so a padded id like " p1 " validated, persisted verbatim, and was then invisible to resolution queries, which bind trimmed forms — a silently orphaned row. Validation now rejects any id that is not in canonical trimmed form, pinned in the shared conformance suite so both backends hold the line. - The effective-values endpoint accepted unbounded library_ids and series_ids lists; the SQLite backend expands each id into a bound parameter, so a crafted batch could exhaust the host-parameter budget and fail the whole resolution. The request boundary now caps the combined content ids at 200. - pickForScope's doc comment promised ties broken "by the most specific id in the request order" while the implementation sorts by ascending library then series id; the comment now describes the actual (deliberately deterministic-only) behavior. Plus: the pgstore conformance cleanups now assert the ON DELETE CASCADE they rely on instead of discarding the delete error, so a dropped FK can no longer leak seeded rows into the shared test database silently. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(settings): close the discovery gaps around the canonical API Three review findings: - Canonical profile_device writes never touched the device registry, so a device that only ever wrote through /settings/values was invisible to ListDevices and the admin device surfaces — undiscoverable and unforgettable. Device-scope writes now refresh the registry from the request's device headers, throttled the same way the legacy route is. - The contract spec tells clients to probe GET /settings/manifest (and /settings/capability), and to read a 404 as "pre-contract server"; the router only exposed /settings/contract*. The documented paths now alias the same handlers. - The plugin proxy's X-Silo-Theme header came from the legacy account-level user_settings.ui_theme row, so a profile's theme change through the canonical API never reached plugins and profiles sharing an account were indistinguishable. The lookup now resolves the canonical profile-scoped ui.theme row (falling back to the legacy row for stores the backfill has not covered) using the request's active profile. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * feat(settings): emit revision metadata in generated bindings and verify the TS one Two review findings on the generator surface: - The bindings dropped every introduced_in tag, so a client generated from revision N could not filter its pinned contract down to an older server's advertised revision — the promised negotiation had no data. The TypeScript definitions now carry introducedIn per definition, per scope, per enum member, and the full history of any widened numeric bound. (Go/Kotlin/Swift emit keys, not definition tables, so they only need the Revision constant they already have.) - make verify-settings-bindings compared only the generated Go file and the conformance fixture, so a manifest change could merge with a stale web/src/lib/settingsContract.ts. The target now regenerates and diffs the TypeScript binding too, through the same prettier config the bindings target applies. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * chore: drop the accidentally committed settingsgen binary24ee9952checked in a 5.5 MB compiled settingsgen alongside its source. The binary is a local build artifact — cmd/settingsgen is the source of truth and make settings-bindings runs it with go run. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(settings): close the migration planner's data-loss and crash findings Four review findings on the one-time legacy-to-canonical migration: - A device holding both player.next_up_prompt_seconds and its playback.* rename canonicalized to one identity, and both backends insert bare — a unique violation that failed NewUserDB (SQLite) or aborted the goose migration (Postgres). Plan now ends with a deterministic dedup keyed on the canonical identity; a canonically keyed row beats a renamed alias, since the runtime writes the canonical spelling first and only best-effort-deletes the alias. - The four auto-skip profile columns (auto_skip_intro/credits/recap, auto_play_next_preview) were never read, so an explicit true silently became the contract default false. They now migrate — explicit true only, so an untouched false column does not become a choice. - Profiles with language 'en' emitted no playback.audio_language row because the column default was suppressed, but that default WAS the effective behavior: the old playback path preferred English, while the canonical null default skips language matching entirely. English now migrates as an explicit row. The other suppressed defaults stay suppressed — their empty-string defaults already meant unset. - Stored v1 card_overlays documents were quarantined because the planner validated them against the v2-only schema; the web parser has upgraded v1 at read time all along. The planner now applies the same v1-to-v2 upgrade before validation. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(settings): delete canonical library-scoped values with the library The canonical settings schema deliberately has no FK on library_id or series_id, and the migration comment promised the owning delete paths would clean these rows up — but nothing called DeleteSettingValuesForLibrary/-Series outside stores and tests, so a deleted library left orphaned profile_library preferences in every user's store forever. Adds userstore.SettingValuesCleaner, a per-user best-effort sweep in the mutation-sweeper's mold, and wires it into the library delete job. The series-side cleanup is exposed on the same cleaner for the scanner's orphan pruning to adopt; series have no single delete executor today. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(settings): keep off-step playback speeds working until cutover The legacy device endpoint gained step enforcement mid-branch, turning an existing in-range PUT of 0.26 from 204 into 400 — a behavior change on a live /api/v1 endpoint before the coordinated break, which the v1 rules forbid. The legacy validator is back to range-only; the typed mutation endpoint keeps enforcing the manifest's step. The migration planner now snaps stored off-step numbers onto their definition's step grid instead of quarantining them: a stored 0.26 is a real preference, and every client's stepper was going to snap it on the next write anyway. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(settings): serve canonical values to the readers the cutover stranded Four P1 review findings where the web writes canonical rows the server never reads — and the legacy keys those readers use are now unwritable, so the values are frozen and user edits silently do nothing: - access.DisabledLibraryIDs and the policy viewer resolver read the legacy account key while the library screen writes profile-scoped ui.disabled_library_ids. Both now resolve the canonical profile row, falling back to the legacy key only when no canonical row exists. - The sections fetcher and handler read the legacy next_up_mode account key while the playback screen writes ui.next_up_mode. Same ladder, behind one shared sections.NextUpMode helper. - Profile creation committed the profile and then synced settings non-atomically, so a mid-sync failure left a profile the retry could not recreate (name conflict) with preferences that read as contract defaults forever. The create path now compensates by deleting the profile it created. - The mounted legacy PUT /subtitle-prefs/{series_id} wrote only user_subtitle_preferences, but item detail resolves those three keys canonically, so a post-upgrade client's "subtitles off" returned 204 and was ignored. The legacy handler now dual-writes the canonical profile_series rows, and its delete clears them. Plus the migration's disposition for stranded Apple device-scope audio language rows: nothing read them before the contract, so promoting them to real overrides would change track selection at upgrade. They are recorded in the rejects table instead of copied. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(web): make canonical settings writes take effect Three P1 review findings on the web half of the cutover: - Every profile-default editor reads the resolved value but writes the profile row, so a device override — left by the migration converting legacy user_device_settings, or written by another client — kept shadowing the save and snapped the control back with no affordance to remove it. useAutoPlayNextSetting already solved this for one key; that logic is now a shared useProfileDefaultWriter used by the playback screen, the quality picker, subtitle behavior, and the four appearance setters. It only clears when the key is device-scopable and the resolved value actually came from a device row. - The appearance cache only ever grew: when the effective response resolved a key to "default" — because another client deleted it — the namespaced entry and local state survived and kept winning the fallback, so a removal never reached this browser. The mirror now runs both ways, clearing only on an explicit default answer (silence is not a deletion) and only within the current identity's namespace. Custom theme vars and CSS do the same, except while a local draft is unsaved. - The quality picker wrote the canonical two-axis keys while playback still derived its cap from currentProfile.quality_preference, a legacy compound column the canonical write deliberately does not mirror — so choosing a quality changed nothing about what played. The watch route and both item-detail pages now read playback.preferred_quality, falling back to the profile column until the settings read resolves so playback never blocks on it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ci): repair the type error and the bindings gate's job placement Two breaks from the previous commits: - useTheme referenced storage.StorageKey, but storage is a value, not a namespace — the Web job's tsc caught what the local incremental typecheck had already cached past. Imported the type properly. - verify-settings-bindings gained a prettier step, and the Go job that runs it has no pnpm, so the check failed on its own tooling rather than on a stale binding. Split the web half into verify-settings-bindings-web and moved it to the Web job, which has pnpm; verify-settings-bindings-all runs both locally. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(settings): close the second-round review findings Three from the review of the pushed work: - The live profile sync omitted auto_skip_intro/credits/recap and auto_play_next_preview, which my own change made load-bearing: the player now resolves those keys canonically, so a legacy PUT /profiles moved the columns, returned 200, and changed nothing about playback. All four now mirror on write. The DTO read block keeps its shape — clients pin it — and its columns are what the sync keeps current. - The effective endpoint dropped unknown keys silently, letting a client fill the gap with its own vendored default and present a value this server would refuse to store. Unknown keys now 404 by name. - Two sidebar-pin toggles in flight at once could commit in either order, and the server upsert is last-write-wins, so the first request landing second restored the pre-toggle document. The writes are now chained, and each link reads the document when it runs, so a queued toggle sends the newest state rather than the one it was queued with. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * feat(database): make the settings-contract deploy reversible Rolling back this release meant restoring a backup, for a reason that was not obvious: the DisplayPreferences move deletes the jellycompat rows from user_settings once it has copied them, and the previous binary reads exactly those rows. An older server therefore starts cleanly and silently serves defaults, so every Jellyfin client's saved view preferences look reset. The down functions were already written and correct — nothing could invoke them. The backfill and the DisplayPreferences move are Go migrations registered in-process, so the standalone goose CLI in the Makefile cannot see them, and the server exposed only --migrate-only and --migrate-status. Adds MigrateDownTo, the --migrate-down-to flag, and a make target, plus a rehearsal test that seeds a legacy row the way the old binary wrote it, applies the move, rolls back, and asserts the row returns byte-for-byte. Documents the ordering in the spec's cutover section, including the two caveats an operator needs beforehand: take a backup, and the per-user SQLite backend cannot be rolled back at all — its migrations have no down path and an older binary refuses to open a newer database, so those installs restore from backup rather than degrade. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(settings): skip legacy rows whose profile was deleted The dev-server migration aborted on real data: writing playback.subtitle_appearance at profile_device for user 1: violates foreign key constraint user_setting_values_profile_fkey user_device_settings carries an ON DELETE CASCADE on (user_id, profile_id) today, but rows written before that constraint outlived the profiles they belonged to — that install had 46 such rows across 14 deleted profiles. The planner copied them faithfully and the canonical table, which declares the same foreign key, refused them; because the backfill runs in one transaction, the whole migration failed and the server could not start. An override belonging to a profile nobody can select is not a preference anyone can be shown or reset, so Plan now drops those rows rather than repairing them, recording each in user_setting_migration_rejects so an operator can see what was left behind. Account-scope rows carry no profile and pass through untouched. Verified by replaying that install's 514 device rows through the planner: 9 rows would have hit the constraint before, 0 after. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(settings): address canonical cutover review findings * fix(settings): address latest review findings --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
70 lines
3.1 KiB
Docker
70 lines
3.1 KiB
Docker
# Stage 1: Build frontend
|
|
FROM node:22-slim AS frontend
|
|
RUN corepack enable && corepack prepare pnpm@10.32.1 --activate
|
|
WORKDIR /app/web
|
|
COPY web/package.json web/pnpm-lock.yaml ./
|
|
COPY web/vendor/foliate-js ./vendor/foliate-js
|
|
RUN --mount=type=cache,target=/root/.local/share/pnpm/store \
|
|
pnpm install --frozen-lockfile
|
|
COPY web/ .
|
|
RUN pnpm run build
|
|
|
|
# Allow CI to inject prebuilt frontend assets via a named `frontend_dist`
|
|
# context while local builds keep using the in-Docker frontend stage.
|
|
FROM scratch AS frontend_dist
|
|
COPY --from=frontend /app/web/dist/. /
|
|
|
|
# Stage 2: Build Go binary
|
|
FROM golang:1.26 AS build
|
|
ENV CGO_ENABLED=1
|
|
ENV GOPROXY=https://proxy.golang.org,direct
|
|
ENV GOPRIVATE=github.com/Silo-Server/*
|
|
ENV GONOSUMDB=github.com/Silo-Server/*
|
|
RUN apt-get update && apt-get install -y --no-install-recommends libvips-dev && rm -rf /var/lib/apt/lists/*
|
|
WORKDIR /app
|
|
COPY go.mod go.sum ./
|
|
COPY internal/compat/zishang520-webtransport-go/ internal/compat/zishang520-webtransport-go/
|
|
RUN --mount=type=cache,target=/root/.cache/go-build \
|
|
--mount=type=cache,target=/go/pkg/mod \
|
|
go mod download
|
|
COPY web/embed.go web/embed.go
|
|
COPY --from=frontend_dist / web/dist
|
|
COPY cmd/ cmd/
|
|
COPY internal/ internal/
|
|
COPY migrations/ migrations/
|
|
# The settings contract is a Go package (contracts/settings/v1) that embeds the
|
|
# manifest, so the binary carries the exact bytes it was built from. It lives
|
|
# outside internal/ because clients vendor these files.
|
|
COPY contracts/ contracts/
|
|
ARG BUILD_REVISION
|
|
ARG BUILD_DIRTY=false
|
|
RUN --mount=type=cache,target=/root/.cache/go-build \
|
|
--mount=type=cache,target=/go/pkg/mod \
|
|
go build \
|
|
-ldflags "-X github.com/Silo-Server/silo-server/internal/buildinfo.revisionOverride=${BUILD_REVISION} -X github.com/Silo-Server/silo-server/internal/buildinfo.dirtyOverride=${BUILD_DIRTY}" \
|
|
-o /silo ./cmd/silo/
|
|
|
|
# Stage 3: Runtime
|
|
FROM debian:bookworm-slim
|
|
ARG TARGETARCH
|
|
RUN apt-get update && \
|
|
apt-get install -y --no-install-recommends ca-certificates curl gnupg && \
|
|
curl -fsSL https://repo.jellyfin.org/jellyfin_team.gpg.key \
|
|
| gpg --dearmor -o /usr/share/keyrings/jellyfin.gpg && \
|
|
echo "deb [signed-by=/usr/share/keyrings/jellyfin.gpg arch=${TARGETARCH}] https://repo.jellyfin.org/debian bookworm main" \
|
|
> /etc/apt/sources.list.d/jellyfin.list && \
|
|
apt-get update && \
|
|
apt-get install -y --no-install-recommends jellyfin-ffmpeg7 git libvips42 fonts-noto-core fonts-noto-cjk && \
|
|
apt-get purge -y gnupg && apt-get autoremove -y && \
|
|
rm -rf /var/lib/apt/lists/*
|
|
RUN mkdir -p /tmp/silo-transcode /var/lib/silo/compat/jellyfin-web
|
|
COPY --from=frontend /usr/local/bin/node /usr/local/bin/node
|
|
COPY --from=frontend /usr/local/lib/node_modules/npm /usr/local/lib/node_modules/npm
|
|
RUN ln -sf ../lib/node_modules/npm/bin/npm-cli.js /usr/local/bin/npm && \
|
|
ln -sf ../lib/node_modules/npm/bin/npx-cli.js /usr/local/bin/npx
|
|
COPY --from=build /silo /usr/local/bin/silo
|
|
EXPOSE 8080 8096 13378
|
|
HEALTHCHECK --interval=15s --timeout=5s --start-period=10s --retries=3 \
|
|
CMD curl -f http://localhost:${PORT:-8080}/api/v1/health || exit 1
|
|
ENTRYPOINT ["silo"]
|