Review 4314
PR #4314 · author zeroryu · base main
Round 1 — 2026-08-24, head 8dd51e56. request-changes, posted. No wiki record was written at the time; this page begins at round 2 and quotes round 1 rather than reconstructing it. Round 1 asked for three things and noted a fourth:
The one I can't take is
minmax(0, 1fr)at CodeBlock.tsx:313. It isn't gated onisWrapped, so it reaches every existing line-numbered block: an unwrapped one whose lines are wider than its container now has no horizontal scroll at all, and the rest of each line is unreachable.
The
pr-a11yfailure isn't yours —--color-syntax-punctuationis 2.42:1 today, and only became visible to axe when the numbers moved out of a::before. Ours to fix. I would like to understandhasStickyLineNumbersitself before it's permanent, though: what would someone set it to false for? This also needs a merge with main.
An earlier request-changes from ernestt (2026-07-28, head fbb7701d) reported the original defect: "I did notice that the number lines gets scrolled away though", with a video.
8545add78bb4e8ebfae5d901b9e99f9616fdae83
Previous reviewed head: 8dd51e5627d40d29c67588ca7ee60c80bfe19b49. Head confirmed before work and again before publication; it did not move during the run.
LOOP VERSION: 1.6.0 AUDIT RUBRIC: 1.13
LANE: full
WHY: four fast-lane conditions fail — a behaviour default changes for every existing caller (hasLineNumbers on an unwrapped block), two prior CHANGES_REQUESTED reviews are open, pixels are intended to change so the visual gate cannot stand alone, and the required test job is red on this head.
Collaborator, treated as internal. zeroryu is in neither .github/ENGOWNERS nor .github/DESIGNOWNERS, but has write permission, two merged PRs, and the branch lives on facebook/astryx itself rather than a fork. So: no Discord clause, and no full-review link on the PR.
| who | what they asked | at 8545add
|
|---|---|---|
| ernestt | the number gutter scrolls away | satisfied — frames below |
| round 1 (ours) |
minmax(0, 1fr) ungated kills horizontal scroll on unwrapped blocks |
satisfied — the scroll range is identical to main: scrollWidth 531 / clientWidth 198 / maxScrollLeft 333 on both |
| round 1 (ours) |
--color-syntax-punctuation at 2.42:1 — ours, not the author's |
still ours, unchanged — see A11Y |
| round 1 (ours) | what would someone set hasStickyLineNumbers to false for? |
satisfied — the prop is gone; sticky is now the default of hasLineNumbers
|
| round 1 (ours) | needs a merge with main
|
satisfied — rebased; merge-base e6507a9, main is 3 commits ahead and none touch packages/core/src/CodeBlock/
|
This round extends round 1 rather than contradicting it. Everything it blocked on is done. The two findings below are defects this head introduced.
WHY 1: On a CodeBlock narrower than its longest line, scrolling right takes the line numbers away with the code. Measured on main at a 200px block: the numbered row sits at x=33 unscrolled and at x=−300.5 at the far edge — off the region entirely.
WHY 2: The number is the only handle a reader has on a line. Once you scroll right to finish a long line you can no longer say which line you are looking at, so you scroll back to count, or you give up matching the snippet to the prose that references "line 12".
WHY 3: CodeBlock exists so someone can read and refer to code they did not write. Numbers are the referring mechanism, and they disappear in exactly the case that made them worth turning on — a block too wide to read at once.
USER-FACING PROBLEM: someone reading a numbered snippet in a narrow column scrolls right to finish a long line and can no longer tell which line they are on. PROBLEM SEVERITY: harmful friction — the task completes (you can scroll back), but you lose your place and repeat work. Nothing is unreachable, so not broken task.
VERDICT: clear
When a code block does not wrap, its numbers are drawn once in a column of their own, that column is pinned to the reading edge of the scroll region, and it paints an opaque background so the code slides behind it instead of through it. When a block does wrap, nothing changes: each number stays in the row of its own line, because a wrapped line is taller than one row and a fixed column could not follow it. Which of the two you get is decided by whether the block wraps — not by a setting, because turning numbers on is the whole request.
SOLUTION (2 decisions · ~91 runtime lines of 195)
- unwrapped + numbered gets one pinned, opaque number column — the fix, traces to the stated problem
- wrapped + numbered keeps per-row numbers and is constrained to
width:100%; min-width:0so long lines wrap rather than keeping intrinsic width — traces to the stated problem "Constrains wrapped layouts … so long lines wrap"
Both trace to problems written in the body; neither is piggybacked. Two is under the >2 threshold, and they must ship together — splitting the wrapped and unwrapped paths is one change.
BURDEN: low — zero state, zero Effects, zero listeners, zero timers, zero observers, no new public prop. One component-local render function and one internal CSS custom property. BURDEN MATCH: proportionate — a render-only mechanism for a render-only problem.
VERDICT: clear
OWNER: CodeBlock — line numbering is its own presentation; no shared system owns it.
TIER 1: none — no layer, focus, announcement or themeProps system participates.
TIER 2: size — the gutter takes the same sizeSm/sizeMd style as the code (CodeBlock.tsx:465), which is why the rows line up.
SEAMS: container (card | section) · style/xstyle override · syntaxTheme provider · isWrapped · span vs CSS-Custom-Highlight content path · maxHeight scroll region · direction.
BEHAVIOR UNIT: inline — correct here. There is no state machine: no Effects, no refs, no timers. StickyLineNumberGutter (CodeBlock.tsx:451) is a pure function of lines and highlightSet, and the existing DOM tests cover it.
| seam | driven result |
|---|---|
container="card", unwrapped |
works — gutter pinned at x=17 across all 333px of scroll; scrollWidth 531 / clientWidth 198, identical to main
|
container="section", unwrapped |
pinned and scrolling both work — but it paints --color-background-card (rgb 255,255,255) over a block whose own background is rgba(0,0,0,0) by design. Finding 2 |
isWrapped |
works — no gutter; rows stay display: grid with the number in the row, same as main
|
span content path (highlightMode: spans) |
works — spans present, gutter x=17, number 1 at x=33 at full scroll |
CSS Custom Highlight path (highlightMode: highlight) |
works — same numbers, same geometry |
| RTL | works — gutter pins to the right edge (x=837.2 of a region ending at 883), scroll range −333, numbers aligned |
vertical scroll (maxHeight) |
works by construction — the gutter is sticky on the inline axis only (insetInlineStart: 0, CodeBlock.tsx:178), so numbers travel with the code vertically |
The behaviour lives with its owner and survives every seam except one, and that one is a paint question rather than a placement question: the gutter decides its own colour from a var CodeBlock sets, with no way for the surface it sits on to say otherwise. That is a consequence, so it is a note here and the block is filed where the paint is chosen.
VERDICT: note — the gutter's paint colour is chosen inside CodeBlock and is not reachable from outside it
End users of every app on the next release, with no opt-in. Anyone reading a numbered code block narrower than its longest line: the numbers now stay put while the code slides under them. On the 200px arm they held at x=33 through the full 333px scroll where before they left the region entirely — you can read the end of line 18 and still see that it is line 18.
Every existing unwrapped numbered CodeBlock repaints, whether or not it scrolls: the code column now begins 45.8px in, behind an opaque column with a divider, where the numbers used to sit inline with the code. Nothing around it moves — the row was 499.48px wide before and is 45.8 + 453.68 = 499.48 after, and scrollWidth is 531 on both. So no neighbour reflows.
Builders write nothing new. hasLineNumbers means more than it did; no call site changes.
What landing this newly exposes: a numbered CodeBlock with container="section" gains a card-coloured column on a surface that painted nothing before. That variant exists specifically to blend into a parent — its own comment at CodeBlock.tsx:71 says so — so this is new at merge, not still-broken. packages/cli/assets/templates/pages/ide/page.tsx:278 ships exactly that combination.
VERDICT: clear
no API change.
hasStickyLineNumbers existed only on this branch's previous head and never shipped, so removing it breaks nobody. Public props, exports and types are untouched.
OSSIFICATION: nothing public ossifies. One thing does become permanent, and it is the finding: the diff adds the internal custom property --_codeblock-sticky-background (CodeBlock.tsx:63, :70, read at :190). The repo treats a component CSS var as declared theming surface — derivedVarRegistry.test.ts enforces it — so it is surface whether or not it is spelled --_.
VERDICT: clear
No new theme targets; astryx-code-block* and the deprecated astryx-codeblock* aliases are unchanged.
+ --_codeblock-sticky-background → the sticky number column's background
card: var(--color-syntax-background) CodeBlock.tsx:63
section: colorVars['--color-background-card'] CodeBlock.tsx:70
read at: backgroundColor CodeBlock.tsx:190
documented in CodeBlock.doc.mjs theming.vars[]: NO (:161-163 lists only --_codeblock-gutter-width)
This fails the repo's own gate. packages/core/src/theme/derivedVarRegistry.test.ts:333:
AssertionError: CodeBlock has undocumented CSS vars in source:
--_codeblock-sticky-background. Add them to CodeBlock.doc.mjs theming.vars[]
and add a derived[] entry mapping the standard CSS property to the internal var.
Confirmed three independent ways: the CI log for run 33106991266 (test job, conclusion failure), a local focused run of that test file at this head (1 failed / 1 passed), and grepping CodeBlock.doc.mjs. And it is this PR's — the same test at main c6041cf passes (2 passed, 96 skipped), so main does not already do this.
T1 clean — no raw hex, rgb or hsl anywhere in the new styles; every colour is a token reference or an existing syntax var. Writing 'var(--color-syntax-background)' as a string rather than a token reference matches how the file already spells it at CodeBlock.tsx:119, so that is house style, not a defect.
T2: a theme that sets a background through astryx-code-block still reaches the code area but not the number column, because the column reads a var no theme is told about. Same finding, not a second one.
VERDICT: BLOCKS — the new var is undeclared theming surface and the repo's registry test fails on it
BEHAVIOR: yes, deliberately. hasLineNumbers on an unwrapped block now produces a pinned opaque column instead of inline numbers. Every existing caller is enrolled; nobody opted in. This is the change round 1 asked for, it is recorded in the changeset and in CodeBlock.doc.mjs, and the doc line was updated to say so. States walked: empty (code="" → one line, gutter renders "1", no crash), single line, 25 lines, 50 lines, wrapped, highlighted, collapsed. No loading/error/disabled states exist on this component.
API: no — no signature, export or default on a public prop changed.
VISUAL: yes, twice. Every unwrapped numbered block repaints (intended). And container="section" gains a painted column (not intended — finding 2). Outer geometry unchanged: 499.48px row before, 45.8 + 453.68 after, scrollWidth 531 both, so nothing grew and no neighbour reflows.
THEME: yes. The gutter's paint is not reachable from any documented target or var.
VERDICT: note — behaviour and the general repaint are intended and recorded; the section repaint and the theme half are carried as findings in JUDGEMENT
EFFECTS: zero. No useEffect, no useLayoutEffect, no ref, no timer, no listener, no observer added, changed, moved or removed. StickyLineNumberGutter is a plain render function.
RENDER: no new render passes — nothing sets state.
LISTENERS/OBSERVERS: none added; nothing to tear down.
LAYOUT: no forced reflow — no getComputedStyle, offsetWidth or getBoundingClientRect anywhere in the diff. Sticky positioning is compositor-side.
BUNDLE: no new dependency. The PR Analysis Report puts @astryxdesign/core at 4.8KB CJS / 1.2KB gzipped.
DOM: the gutter adds exactly lines.length + 1 elements — measured 40 → 66 at 25 lines. These sit outside the contentVisibility: auto chunking the code lines get, so they always participate in layout. Worst realistic N taken from the repo rather than imagination: the largest CodeBlock fixture shipped under packages/cli/assets or apps/docsite/src is 18 lines, so +19 boxes.
Reproduction: the banked review probe codeblock-sticky-gutter.cjs, driven against core-codeblock--default with args=width:200px.
No layout-time cost was measured and none is claimed: 19 extra boxes at the repo's worst realistic N is a count, not a finding.
VERDICT: clear
VISUAL CHECK: manual frames required WHY: pixels are intended to change — the PR's own body says it adds "a full-height opaque gutter surface and continuous divider". The stable visual-regression job is green on this head but reports 334 added frames and 0 removed, i.e. it has no baseline for the affected state, so it cannot be the evidence. Every frame below was captured in real Chromium and opened and looked at.
core-codeblock--default, args=width:200px, scrolled to scrollLeft max (333 of 333).
Before (main c6041cf) |
After (head 8545add) |
|---|---|
 |
 |
| numbers gone; the row sits at x=−300.5 | numbers 1–25 held at x=33, opaque column, divider |
Difference verdict: intentional. Quoted from the PR body: "Keeps unwrapped line numbers pinned to the inline-start edge of CodeBlock's native scroll region." And it is what ernestt's review asked for.
SENSOR RECEIPT (both frames): build c6041cf / 8545add · story core-codeblock--default · theme neutral · mode light · direction ltr · viewport 900×600@1 · media {forcedColors:false, reducedMotion:false, coarsePointer:false, hover:true} · targetCount 1 · state {lineCount:25, atScrollEnd:true} · fonts loaded · 0 page errors. Identical on every sensor except Build.
Same story, container="section", hasLineNumbers on, embedded in a panel painting --color-background-muted.
Before (main c6041cf) |
After (head 8545add) |
|---|---|
 |
 |
| the panel colour runs uninterrupted under the code | a 45.8px white column, then the panel colour resumes |
Sampled from the PNGs, not from computed style — one horizontal scan line at 62% height, image x-coordinates:
| x | 5 | 30 | 55 | 75 | 110 | 160 | 215 | 235 |
|---|---|---|---|---|---|---|---|---|
| before | 241,241,241 | 241 | 241 | 241 | 241 | 241 | 241 | 241 |
| after | 241,241,241 | 255,255,255 | 255,255,255 | 241 | 241 | 241 | 241 | 241 |
The block begins at image x=20 and its gutter is 45.8px wide, so x=30 and x=55 are inside the gutter and x=75 is the transparent code area with the panel showing through.
Difference verdict: unintentional — a finding. Nothing in the PR body says a section-container block should start painting. The variant's own comment (CodeBlock.tsx:71) says the opposite: "Transparent background so the block blends into the surface it's embedded in (a card or panel) instead of painting its own muted layer."
MUTATED ARM, and the two versions of it that silently failed, because the failure is the lesson: the arm is one inline declaration set identically on both sides after load — element.style.background = 'var(--color-background-muted)' — on the ancestor that actually paints the surface (Storybook's theme-decorator root). No layout property, no size, no other colour; the block's width stays fixed by args=width:200px. Version 1 set it on #storybook-root; getComputedStyle reported rgb(241,241,241) there and the state sensor passed, but sampling the captured PNG gave 255,255,255 at every x — the element computes the value without painting it at those coordinates. Version 2 added html, body with !important and failed the same way, because the decorator root above them paints white. Both frame pairs were captured, believed, and thrown away. A computed value is not a pixel.
SENSOR RECEIPT (both frames): story core-codeblock--container-section · theme neutral · mode light · direction ltr · viewport 900×600@1 · same media · targetCount 1 · state {lineCount:25, atScrollEnd:true, panelPainted:"rgb(241, 241, 241)", blockTransparent:true} · fonts loaded · 0 errors. Identical on every sensor except Build.
core-codeblock--with-highlighted-lines, lines 9–13. The accent band runs unbroken from the gutter into the code: number 13 at y=314 h=20 with background rgb(241,241,241), its line at y=314 h=20 with the same background, separated only by the 1px divider. Row 14 is transparent on both sides. This is the seam most likely to be half-done and it is not.
SENSOR RECEIPT: build 8545add · story core-codeblock--with-highlighted-lines · theme neutral · mode light · ltr · 900×600@1 · targetCount 1 · state {highlighted:[9,10,11,12,13], atScrollEnd:true} · fonts loaded · 0 errors.
Alignment, checked because it is what a fixed column usually gets wrong: number 1 at y=74 h=20 against line 1 at y=74 h=20, and number 25 at y=554 h=20 against line 25 at y=554 h=20. No cumulative drift over 25 rows.
VERDICT: BLOCKS — with container="section" the gutter paints a 45.8px card-coloured column over a block that is transparent by design, in a configuration a shipped template uses
REMEDY SEARCH: not triggered — author owns HOW; acceptance criteria are sufficient
Ownership is settled (CodeBlock owns its own gutter paint), the public shape is settled (no new prop is on the table), and the constraint is stateable as an outcome. No system or design decision is needed to pick a correct fix, and the repo's own test message already names the mechanical half of it.
A1 accessible name — auto-covered and unchanged: the scroll region keeps role + aria-label="Code"; the existing test asserting it passes at this head.
A3 state exposed — n/a; the gutter carries no state.
A4 keyboard — checked by driving it: nothing focusable is added, tab order is unchanged, and the gutter is pointerEvents: 'none' (CodeBlock.tsx:195) so it intercepts neither pointer nor scroll.
A5 focus — n/a; no element is added to or removed from the focus order.
A13 / A14 / A15 — n/a; no animation, no painted state, no focus ring added.
A18 axe — pr-a11y is green on this head and .github/a11y-baseline.json is untouched by the diff. But green here is not the same as fixed. The gutter is aria-hidden="true" (CodeBlock.tsx:462), so axe no longer evaluates the numbers' contrast at all. --color-syntax-punctuation is the same token round 1 measured at 2.42:1; the diff does not change it, and it remains ours rather than the author's. In the default neutral/light theme the gutter numbers measure rgb(110,110,110) on rgb(250,250,250) = 4.89:1, which passes; the other syntax themes were not swept, so which one produced the 2.42:1 reading is unresolved.
A6 / A7 announcements — n/a; no live region, no announcement.
AT exposure — unwrapped numbers are now explicitly aria-hidden, while wrapped numbers are still ::before generated content that Chromium does expose. So the same prop produces two different behaviours for a screen-reader user depending on isWrapped. Nothing becomes unreachable and no state goes unannounced — the code text is untouched — so this is a note, not a block.
I1 / I4 / I5 — no new user-visible or AT-facing strings; the digits are generated from the line index exactly as before.
I8 / I9 logical properties and values — every new declaration is logical: insetInlineStart, borderInlineEnd{Width,Style,Color}, paddingInline{Start,End}, marginInline{Start,End}, textAlign: 'end'. No physical property anywhere in the new styles.
I11, the one lint cannot catch — checked by driving it, not by reading. In RTL the gutter pins to the region's right edge (x=837.2, region ends at 883), the scroll range is −333 (the mirror of LTR's +333), and numbers 1 and 25 stay aligned with their rows at y=74 and y=554. No unflipped physical companion.
VERDICT: note — unwrapped and wrapped numbered blocks now differ in what a screen reader hears
| slot | verdict |
|---|---|
| PROBLEM | clear |
| SOLUTION | clear |
| ARCHITECTURE | note — gutter paint is chosen inside CodeBlock, unreachable from outside |
| IMPACT | clear |
| API | clear — no API change |
| THEMING |
BLOCKS — --_codeblock-sticky-background undeclared; registry test red |
| BREAKING | note — behaviour + general repaint intended and recorded; the rest carried below |
| PERFORMANCE | clear |
| VISUAL | BLOCKS — section-container paints a column over a deliberately transparent block |
| A11Y & I18N | note — wrapped and unwrapped numbers differ in AT exposure |
Reading the bodies rather than the labels: ARCHITECTURE's note, THEMING's block and VISUAL's block are three faces of one thing — the diff introduced a var that decides what the gutter paints, did not declare it, and guessed wrong for the one container variant that paints nothing of its own. Declaring it properly is the same act that gives the section case a way out. So the review has one subject and one ask, not three findings. Beyond that, no slot's prose contains a sentence a user would call a bug: nobody is stuck, nothing is unreachable, nothing is unannounced, no focus is lost, no data is lost.
GOAL: met — the stated problem is that numbers scroll away, and they no longer do: pinned at x=33 across the full 333px range where main loses them to x=−300.5, in both content paths and in RTL. And the thing round 1 blocked on is repaired with the number to prove it: scrollWidth 531 / clientWidth 198 / maxScrollLeft 333 on this head, identical to main.
DISPOSITION:
-
--_codeblock-sticky-backgroundundeclared,testjob red → blocks now - section-container gutter paints the card colour over a transparent block → blocks now. Found by driving a muted-panel arm and sampling the resulting pixels; confirmed two other ways — reading
containerStyles.section, where the card-coloured var and the transparent background sit six lines apart (CodeBlock.tsx:70,:76), and grepping the tree for shipped call sites of that configuration (packages/cli/assets/templates/pages/ide/page.tsx:278) - BREAKING · Behaviour,
hasLineNumberschanging meaning for every existing caller → accepted. It is the change round 1 asked for, the changeset and the doc both record it, and no caller has to do anything. Not worth raising with the author - BREAKING · Visual, the general repaint of every unwrapped numbered block → accepted. Intended, and measured not to move anything around it (row 499.48px before and after, scrollWidth 531 both), so no consumer has a page to go fix
- Wrapped vs unwrapped AT exposure differs → accepted — no user is harmed, and hiding decorative line numbers from AT is the better half of the inconsistency. Recorded here rather than raised with the author
-
--color-syntax-punctuationcontrast → carried from round 1, still ours and still unowned. Unchanged by this diff and explicitly not this author's. Raised with the maintainer in the handoff rather than promised in the review; thearia-hiddengutter now keeps it out of CI's view, so nothing will re-raise it on its own
ADVICE: bounded outcome criteria — ownership, shape and constraints are settled and only the HOW is open, so no implementation is prescribed. The one mechanism named in the public text is quoted from the repo's own failing assertion, not invented.
AUTHOR CAN PROCEED: yes — two things must be true: derivedVarRegistry.test.ts passes (the var declared in CodeBlock.doc.mjs theming.vars[] with its derived[] entry), and a numbered container="section" block does not paint a colour its parent never asked for. Both are checkable by the author: a focused run of that test file, and the core-codeblock--container-section story with hasLineNumbers on a non-white surface.
WORST OUTCOME: "a numbered CodeBlock with container="section" gains a card-coloured column on a surface that painted nothing before" → request changes. Compatible: it is a visible difference a builder can see and did not ask for, which is a change request. Nobody is blocked, stuck, or unable to use anything, so it is not stronger than that.
JUDGEMENT NEEDED: none — no new public surface, no new concept. The shape (sticky as the default of hasLineNumbers) was chosen by round 1, and the author implemented exactly it.
request changes
-
[BLOCKS] The gutter's background var is not declared, so the theming registry check fails and
testis red → the branch cannot merge, and no theme can reach the column the numbers sit on ·packages/core/src/CodeBlock/CodeBlock.tsx:63,:70,:190· absent fromCodeBlock.doc.mjs:161-163 -
[BLOCKS] With
container="section"the block is transparent on purpose and the gutter paints--color-background-cardover it → a builder embedding a numbered block in a panel gets a 45.8px white column their panel never asked for;packages/cli/assets/templates/pages/ide/page.tsx:278ships that combination ·CodeBlock.tsx:70
Finding 1 carries the verdict on its own — the check is red. Finding 2 is why declaring the var is worth doing properly rather than mechanically. The mechanism, the default, the wrapped path, RTL, the highlight seam and the API are all fine, and none of them is being asked about.
Thanks — this is the shape I wanted, and both of the things I asked for are done. The unwrapped block now scrolls exactly as far as it does on main, and the gutter holds all the way to the end of it.
testwent red after you posted, though:--_codeblock-sticky-backgroundisn't declared, so the theming registry check fails on it.Worth declaring rather than just quieting the check, because the same var is what's wrong with
container="section"— that block is transparent on purpose, and the gutter paints--color-background-cardover it, so an embedded one gets a white column its panel never asked for.templates/pages/ide/page.tsx:278is that exact combination.Can the gutter take its colour from something the surface can set, instead of a fixed card colour?
-
packages/core/src/CodeBlock/CodeBlock.tsx:70— Section blocks are transparent on purpose, so this paints a card-coloured column on whatever panel they sit on. -
packages/core/src/CodeBlock/CodeBlock.doc.mjs:162—--_codeblock-sticky-backgroundneeds a row here too; the registry test is failing on it.
- Number/row alignment holds exactly over 25 rows (y=74 and y=554 on both sides) — the drift a fixed column usually has is simply not there, so there was nothing to say.
- The gutter adds
lines.length + 1DOM boxes outside thecontentVisibilitychunking; at the repo's largest shipped fixture (18 lines) that is 19 boxes, which is not worth a contributor's attention. - ernestt's
CHANGES_REQUESTEDfrom 28 Jul is also still open on this PR, and only his account can clear it.
TIME total 36m
setup 3m worktree at exact head + seeded install + storybook dev (warm main reused: yes)
reading 5m the kit, the PR body, both prior reviews, CodeBlock source
measuring 15m 14 probe runs across 2 arms, 5 sensor-receipted frames, 1 re-measure
writing 9m 3 presentations, 3 critic passes, this record and its push
waste 4m drove the section story before checking it has no hasLineNumbers, so the
first section arm measured an unnumbered block · wrote a probe option
openStory does not accept · built the muted-panel arm twice on a computed
value that painted nothing, capturing and believing two white-on-white
frame pairs before sampling the pixels
- Which syntax theme produces the 2.42:1
--color-syntax-punctuationreading from round 1. The defaultneutral/light theme measures 4.89:1; the others were not swept, because the token is unchanged by this diff and is ours either way. - What colour the IDE page template's editor area actually resolves to. The mismatch is proven on a
--color-background-mutedpanel and the shipped call site with that configuration is named; that template was not rendered.
Three presentations, three passes.
| pass | what it failed | fixed by |
|---|---|---|
| 1 | four file:line anchors pointed at the wrong line at this head; VISUAL said note while its body described an unintended visible change; DISPOSITION and the numbered findings disagreed about whether finding 2 blocks; two non-"no" BREAKING axes never reached JUDGEMENT; the closing line was a design question rather than the ask |
re-opening every anchor at the head; promoting VISUAL to BLOCKS; making the disposition consistent; adding the two explicit accept lines; rewriting the closing line so answering it is the fix |
| 2 | the muted-panel arm never painted. Finding 2 had been promoted to BLOCKS on a frame pair that reads 255,255,255 at every sampled x on both arms. The state sensor passed on a computed value | re-pointing the arm at the element that actually paints, sampling the PNGs before believing them, re-opening both frames |
| 3 | nothing | — |
Nothing yet — read-only run. Nothing was posted to the PR, no code was pushed, and both standing CHANGES_REQUESTED reviews remain as they were.