| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The per-feature design notes were merged into docs/MESHBAY_DESIGN.md and
deleted from the tree on 2026-09-11, but ~230 comments across the three
packages still named them — usually written `docs/musicbay.md §3.2`, as
though the file were still in docs/. A reader had to know §16 existed to
resolve any of them. They now name the section directly.
Every mapping comes from §16, the concordance, which already records where
each old section landed: musicbay -> §9.8, mediacenter -> §9.7 for the
Videos app and §6.5 where the subject is derived data, photos -> §9.9,
auth-confirm -> §3.6, refactoring-search -> §9.11, invite-pairing-v1 ->
§3.4, per-node-identity-v1 -> §3.2, captcha -> §7.7, chat-sender-keys ->
§4.5, apps/refactor-groups -> §9.1–§9.4, desktop-client-v1 per section.
Bare citations of the same documents (`draft-v6 §2.11`, `§4.8`, `§3.4`)
are retargeted too: those collide with real section numbers in the design
document, so leaving them would have been worse than the named form.
Four cases the concordance does not cover, each decided rather than guessed:
Sub-item references into documents that no longer exist — mediacenter's
`§3.3 row 4`, `§3.4b/c`, `apps.md §3b` — name rows and sub-items §9.7 and
§9.2 do not reproduce. The module-level citation stays; the sub-item
pointer is dropped.
The V-findings keep their labels but lose the dead `§10.1/` prefix.
§13.8 lists V1–V13 as per-application open items, which is not what the
labels mean in these comments, so pointing them at §13.8 would have been
a false citation.
`apps.md §5`'s virtualization requirement has no counterpart anywhere in
the design document. The requirement is stated in the comment itself, so
the citation is dropped rather than aimed at a section that does not say
it.
Comments that attributed a *sentence* to an old note — musicbay's "several
thousand files" example, its "what got measured" note, its measured
~11%/~26% cover-art figures, the "original no root, whole shared tree"
call — state the fact without attribution now. §9.8 does not contain those
sentences and citing it for them would have been wrong.
CLAUDE.md's "a reference to a document that no longer exists" row now says
the concordance is for git history and out-of-tree material; the code cites
sections directly.
Verified: 2851 passed, 4 skipped. The 12 errors in the run are the Firefox
leg of test_sticky_header.py's browser harness, which is broken at the
browser level on this machine — headless Firefox (snap) dies with
`[GFX1-]: RenderCompositorSWGL failed mapping default framebuffer`, renders
nothing, and the probe exits `{"error": "no measurement"}` after its full
90s wait. Chrome runs the same 12 assertions in 3.2s and passes. Nothing
here can affect it: every changed line in style.css is inside a comment.
Also checked: ast.parse on every changed .py, `node --check` on every
changed .js, the /* */ balance in style.css, and that no changed line
exceeds the width its file already used.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
|
|
The tab bar paints an opaque ring of page colour around itself, `--band-margin`
wide, so the gap it keeps in the flow is still there once it pins. A box-shadow
spread goes out on all four sides, and above the tab bar there is only whatever
the element before it happened to leave: the join-code form under a group's
title leaves 12px, the ring is 16px, and the form came back with the bottom 4px
of its field and its button painted over — page colour at z-index 30, against
content that has none to answer with. Reported as "the form is slightly cut
off", which is exactly what it looks like and says nothing about a stylesheet.
The same 4px went off the bottom of the "could not reach this node" banner, the
other thing that stands between a group's title and its tabs.
The band reserves that room itself now. `* +`, so it is the gap between two
elements rather than a margin the band always carries: `.search-bar` is a first
child on the Search page, and a margin-top there would collapse through the
page root and take the whole page down with it. Between siblings the two
margins collapse to the larger of the pair, so everywhere that already leaves
enough is untouched and only what was being painted over moves.
Only the two bands that pin against the navigation bar, and that is the rule
rather than an economy. Written for all six it fails 22 of the sticky-header
cases: the gap *between* two bands is the upper one's `--band-margin` and
nothing else — the number `--chrome-h` carries and the offset the lower band
pins at — so a lower band's own margin-top wins the collapse wherever it is the
bigger of the two and leaves the flow layout wider than the pinned one, at
every phone width in every media view. A band under another band needs no room
above it anyway: what is there is a band of higher z-index, which a ring cannot
paint over.
Measured against the shipped GroupPage in the state that was reported — a node
answering `code_required` — in Chrome: 12px of clearance under a 16px ring
before, 16 against 16 after. test_sticky_band_ring.py holds the two selector
lists together out of the source rather than in a browser, because what a
browser shows is the 4px at one width in one of the states that happen to put
something above a band, while what has to hold is which bands are in which
list. docs/apps.md sends the author of a new application to that section to
make its toolbar pin; this is what says the toolbar they add does not get the
gap, and why.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BAJawZ25MZPBJ7TKgnVA1n
|