ADR-0021: the two absent columns are filled, and point 7 is done - #87
Merged
Conversation
They were built, seen to render blank on every row while their headers sorted, and removed — recorded as a schema change and a query change. Both have landed, so the record catches up: what shipped, what was verified against the live library, and the two shapes the work turned on. Also records what the rollout to the other six lists will run into, which the original note did not anticipate: those lists hold their rows whole, but they do not hold the same columns. `AlbumTrack` carries four fields against `TrackResponse`'s twenty, so a shared table has to be told what each list can fill or the album screen draws eleven empty columns. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014P9p2fvFnyiywBxGkv4gfW
Records what the rollout to the other six lists actually met: the endpoints are not equally generous, so the shared table had to be told what each list can fill; a playlist can hold the same track twice; `FavoriteTrack` was discarding most of what `/favorites` returns; and the downloads screen needed two columns no server-backed list has, or a table would have been a worse version of the rows it replaced. Also records the floor moving 14.0 → 14.4, which refines point 2 rather than reversing it — conditional columns in a `TableColumnBuilder` are 14.4 — and the one thing not verified in the running app: whether a shared column customization keeps ids a given table does not build. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014P9p2fvFnyiywBxGkv4gfW
…ubtful The Implementation block said it was not verified in the running app, and described the failure it might have had: one `TableColumnCustomization` shared across tables that build different column sets, quietly pruning the library's layout after a detour through a two-column album screen. It does not. Driven on 2026-08-04 — columns turned on for Tracks survive album and artist tables that never build them — so point 7's "one column preference across them" stands as written and the per-list storage key is not needed. Corrected rather than left standing because an ADR is read months later as fact, and this one would have been read as an open risk. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014P9p2fvFnyiywBxGkv4gfW
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The record for phase 4 of the Mac's lists. The code is in seethroughlab/familiar-apple#61; this is the ADR catching up, as an accepted ADR's Implementation block is meant to.
What it records
The two columns that were built and deleted. They came out because they rendered blank on every row while their headers sorted, and the note said filling them was a schema change and a query change. Both have landed —
created_atreachedTrackResponsein #82, and the Mac now asks forinclude_features— so the record says what shipped and what was verified against the live 26,396-track library:bpmdescending returns 215.3 / 198.8 / 198.8,playCount42 / 38 / 35, andcreated_atspans 2026-01-25 to 2026-05-29. That last one is the check worth having: a column showing the same value on every row is the blank-column defect wearing a value.What point 7's rollout actually met, which the original note did not anticipate. The six lists hold their rows whole, so sorting them on-device was the easy half — but they do not hold the same columns.
AlbumTrackcarries five fields andArtistTracksix againstTrackResponse's twenty, so a shared table had to be told what each list can fill or the album screen draws eleven empty columns. Also recorded: a playlist can hold the same track twice;FavoriteTrackwas discarding sixteen of the twenty fields/favoritesreturns; and the downloads screen needed two columns no server-backed list has, or a table would have been worse than the rows it replaced.The floor moving 14.0 → 14.4, which refines point 2 rather than reversing it — conditional columns inside a
TableColumnBuilderare 14.4, and so isTableColumnForEach. Recorded here rather than as a new ADR because it implements point 2's direction instead of setting a new one; the decision that the Mac targets 14 is unchanged.One thing not verified, stated as such: whether a single
TableColumnCustomizationshared across tables with different column sets keeps the ids a given table does not build. If visiting an album prunes the library's layout, the fallback is a key per list — at the cost of point 7's "one column preference across them".No Decision text is edited; both changes are Implementation-block entries, plus a pointer from the acceptance line to where the floor moved.
🤖 Generated with Claude Code
https://claude.ai/code/session_014P9p2fvFnyiywBxGkv4gfW