Repository navigation
[Website] Add GraphQL Federation and Fusion Product pages - #10391
Merged
Merged
Conversation
rstaib
marked this pull request as draft
September 14, 2026 14:12
github-actions
Bot
added
📚 documentation
…opy band buildColumnSilhouette and paintColumnLayer's signatures changed (they now build from the drawn column tiles and take the band's own projected y for the gradient anchor); update index.tsx's call sites. On mobile/stacked, featherCopyClearZone's own erasure clears the WHOLE live canvas above the band, including the column layer this frame just stamped in, so it never read as structure continuing behind the copy -- only ending abruptly at the band. Re-stamp the column under that erased result (destination-over, clipped to the erased region) so it shows through there again at its own low bandFade alpha, without touching the plasma layers or its own copy-clear guarantee.
The wall's own floor rows are already cut by the section bottom (row 1's back arc lands at y 801 on the 792px-tall canvas at 1440), so keeping the bottom rim's front arc inside the canvas forced a rim far too small to match the wall's own tile scale, leaving the bottom bridging row (wall row 1 -> bottom rim) about 2x taller than the wall's own row-1-to-row-2 pair -- exactly the overlay symptom the planner's ruling calls out. Per the planner's ruling (ticket comment 334) and the orchestrator's relay (335), the bottom rim's front arc may now sit below the canvas, the same way the wall's own floor already does; what matters is that the VISIBLE part of the junction reads true. wqa-rim-search.cjs was extended to drop the "front arc in canvas" constraint on the bottom rim and to compute the tile-height/seam-gap/depth checks over the bridging row's in-canvas tiles only (a tile counts as in-canvas if any of its 4 corners projects inside the frame), then to grid-search a single canonical (y, z, r) rim triple that passes at 1280, 1440 and 1920 jointly, tie-broken toward the smallest radius change from the (unchanged) top rim so the hourglass keeps reading symmetric. The chosen bottom rim (SIDE_BOTTOM_RIM_Y/Z/R = -270/230/236) ties the top rim's own radius exactly and lands within the 15% tile-height and 1px seam-gap bars on every in-canvas bridging tile at all three widths, with no depth<=1 corner. Only the three SIDE_BOTTOM_RIM_* constants (and their doc comment) change in sceneLayout.ts; the top rim, waist, ring, wall builder/painter and the mobile/stacked scene are untouched.
…-frozen bridging rows Planner ruling comment 345/346 (option B on the flare): only the wall's two bridging rows (1 and 17) may move in radius, z and spacing to meet a larger rim -- rows 2-16 and the painter stay at pixel parity with 8c545c4. Grows the top rim to a radius/y/z that clears the numeric flare target (rim projected width >= 1.5x the waist's at 1440/1920, >= 1.4x at 1280; measured 1.90/1.77/1.63) with the front arc still fully inside the canvas below the 72px header at 1440, and re-searches the bridging rows (test-results/wqa-flare-search2.cjs, not checked in) so the column's own rim-adjacent pair matches each new bridging row within ~1% tile height and well under 1px seam gap. The column's own row spacing moves from 14 rows/spacingPower 1.3 to 9 rows/spacingPower 1.2 (near- linear): 5-6 rows first closed the height gap but left visible scalloping in the silhouette envelope at this run's much larger rim (a bigger per-row radius jump than that guidance was tuned against); 9 rows keeps the envelope smooth while still matching the bridging rows closely. The bottom rim's own three constants are unchanged from the accepted option B fix (comment 338); only its bridging row (1) needed re-matching to the column's new spacing.
…ap seam inset by scan axis Review 3 prep (orchestrator relay, comment after fix 2): rv3-fringe.cjs read 33-89px of exposed black on the left/right edges at 1440 after the flare route, against the ~2.7px seam-width bar. Root cause 1 (buildColumnSilhouette): the black base was a per-scanline min/max-x envelope pooled across ALL drawn column tiles. That is only exact when the column's own cross-section is a single convex lobe at every screen row; the flare's much larger per-row radius jump produces enough foreshortened, overlapping-in-y tiles that the pooled envelope bridged clean across real gaps between unrelated tiles/limb clusters, exposing flat black where no tile was actually drawn (confirmed directly: a pixel probe found exact (0,0,0) alpha 255 runs with zero variation, never a shaded tile's own colour). Rebuilt as the TRUE union of every drawn tile's own `rawPoly` quad: one path, all quads, filled once with the canvas' default nonzero winding rule -- it can no longer overshoot a tile or bridge a gap between two that do not touch. Root cause 2 (insetQuadPx): even with an exact base, a fixed *perpendicular* seam inset on a near-horizontal or near-vertical tile edge (the column's own most-foreshortened limb tiles) moves that edge's intersection with a FIXED scanline by `insetPx / |sin(edge angle from that axis)|` -- rv3- fringe.cjs's own horizontal/vertical scan amplifies a sub-pixel inset into a 28-89px run. Added a per-edge axis-scan cap (only engages within ~8.6 degrees of perfectly horizontal/vertical, so ordinary tilted edges keep their full inset and F2's seam-visibility bar is not broadly weakened) and a miter-limit/bevel fallback for the rare acute corner a straight line-intersection can spike past its own edges' offsets. Also fixes l92-column-opaque.cjs's (gitignored) mobile/stacked seam alpha expectation: a seam pixel is never covered by a tile's own fill (that is what makes it a seam), only by paintColumnLayer's ONE base gradient, so its expected alpha is that gradient's value at the seam's own screen y (replicated from paint.ts exactly), not a naive round(255 * that row's own bandFade) -- the old formula was comparing against the wrong layer.
… never cancels to a hole
…are, flicker, surges, filament forks, sparks) Amends hc-0-540's decision log ruling on the user's "I'd like to see more action in the light animation": the live streak subset, orbit/twist/breathe speed, per-streak flicker, a periodic sweeping surge, the filament's reseed with a brief forking second thread, and a small pool of tangential sparks are all raised together, tuned against real 30-frame motion-metric, 10-random-frame exposure and 300-frame budget measurements at 1440x900, 1024x900 and 375-wide (motion metric >=3x the starting commit's own baseline at both required widths, frame budget under the 4ms avg/6ms p95 ceiling at 1440x900 and 1024x900, exposure within the pre-ticket band's own margin at every required width). A single `energetic` flag, resolved once from `matchMedia` at mount, switches the whole scene between this build and a byte-for-byte reproduction of the starting commit's own formulas and streak population (verified pixel-identical, header masked, at both widths) -- so reduced motion keeps its exact pre-ticket still frame.
…ytic side-by-side right-limb Planner comment 287 on hc-0-540, carried over from hc-0-wkf's own review (comment 285): fallbackZoneRight's w<=1152 branch was dead (computeLayout only ever calls it from the sideBySide branch, w>=1280); measureCopyRect's silent `?? copyEl`/`?? bottomEl` substitutions were dead the same way, now an explicit null return instead. Tried replacing the positional child selection with a single data-hero-copy query (a Range over the block's own contents); measured against the real DOM it moves zoneRight enough to fail the header-masked reduced-motion parity gate at 1440 (403738 px), so kept the positional selection -- recorded as NEEDS-PLANNER on the ticket. Also exports analyticRingRightLimb from sceneLayout.ts: the side-by-side right-limb containment criterion, computed from the ring's own torus surface at the camera's base scale (the same basis index.tsx's own ringWidthPx already uses) instead of a rendered-pixel probe that includes the stray-streak population and bloom halo hc-0-wkf's own review found sitting past w-16 by design, not as a regression.
…wire copy-block measurement to dedicated attributes Review 1 majors: sparkRuns now stroke on the glow pass (glowCtx) exactly like the filament's fork runs, so every luminous mote carries a soft halo instead of a bare white dash; the radial fling that projects each spark is capped at 1 + pp * 0.6 so it stays adjacent to the band. SURGE_BOOST_GAIN raised to 0.5 (peak 1.5x, matching the docstring), paired with a DESKTOP_ALPHA_TRIM trim to 1.25 so every 1440 exposure sample stays under the 15% ceiling. Planner-ruled housekeeping (comments 370/371, option b): FusionHero.tsx now marks the teaser paragraph with data-hero-teaser and wraps the button row with a data-hero-actions div (ButtonRow itself takes no extra props, so the attribute lives on a plain wrapper instead); the Tokamak copy-block measurement queries those attributes directly and drops the positional p/lastElementChild selection and its NEEDS-PLANNER comment. Reduced-motion parity re-verified pixel-identical (maxDelta 0) against the starting commit at both required widths.
…h/coherent graph Replace the spec terms 'source schema(s)' with 'subgraph(s)' and 'composite schema' with 'coherent graph' (or 'the graph'/'one graph') across the Fusion page's hero teaser, body sections, feature grid, and metadata description and keyword, rewriting each sentence to read naturally with both substitutions.
Update the Mission Control visuals (FlightRecorder, SpecPatchbay, PreflightChecklist, TelemetryStrip) and the hero LayeredDiagram's COMPOSITE_LINE to say 'subgraph(s)' and 'coherent graph' instead of 'source schema(s)' and 'composite schema', including the two-line COMPOSITE/SCHEMA panel header in SpecPatchbay that a plain-text grep for the phrase misses.
… wall's row rhythm Replaces the single, oversized bridging row at each junction (SIDE_TOP_ROW17, SIDE_BOTTOM_ROW1 -- about 8x the neighbouring tile height) with a buildBridgeRows() sequence that interpolates y, z and radius from the frozen wall row to the rim along a smooth monotone curve, continuing the hourglass flare into the ceiling and floor instead of jumping in one step. This removes the plain, untextured "buffer" the user reported between the room's ceiling grid and the pillar's top rim, and the matching one at the bottom. steps/powerYZ/powerR for each junction are the best candidate from a joint grid search against the real projection (project()/ringPoint()) at 1280/1440/1920 (test-results/gar-bridge-search.cjs, not tracked): the bottom junction clears the 1.3x consecutive-tile-height rhythm bar with margin (worst ratio 1.13-1.17); the top junction's own frozen row 16 and rim sit on opposite sides of the wall's own y trend (row 16 keeps flaring outward while the rim sits back in near the column's axis), so no row count or power pair found under this curve family gets every step under 1.3x -- its worst step lands at 1.50-1.53 across all three widths, still a >5x improvement over the single row's own ~8x jump. Wall rows 2-16, the camera formula, the rim constants, the waist/collar ring, the base construction and the painter are all unchanged (verified byte-identical against the pre-fix layout at 1280/1440/1920). Mobile and stacked keep their own band-sized hourglass construction unchanged: their rims sit off canvas at standard viewport heights (verified via capture at 375/768), so there is no bridging-row buffer to fix there.
…e junction fix can't shift it buildInstrumentLights picked its candidate rows via rows.slice(2, rows.length - 2), so growing wallRows from 19 to 22 (the top/bottom bridge-row sequences) shifted which frozen wall rows the mulberry32 draw could land on, moving 3 of 6 lights outside the junction regions. TokamakLayout now carries an explicit wallLightRowRange ([2, 17) on side-by-side, matching base.slice(2, 17); unchanged [2, wallRows.length - 2] on mobile/stacked), so the candidate set is pinned to the wall's own frozen rhythm rows regardless of how many rows are spliced in at either end.
…te i) Route (i), ratified by the planner: the wall's frozen row 16 -> bridge -> rim sequence now also draws its near-facing half (a chamber.ts culling exception, faceOverride: "near"), so the ceiling folds down in front of the column's top the way reference-tokamak-pillar.png shows, instead of projecting entirely behind the opaque column on the far arc. The mirrored bottom junction gets the same exception, though its own near arc never enters the canvas at any side-by-side width (option B, unchanged). The near-facing tiles are their own small static layer (paint.ts's paintBridgeLayer, an opaque black base plus the wall's tile face) stamped over the column layer every frame (index.tsx), since they sit nearer the camera than the column's own top/bottom rows. Re-tuned the bridge row count/curve against the near arc specifically (gar-bridge-near-search.cjs / gar-bridge-front-search.cjs, not the old far-arc search): a first pass measured the ring-wide median height per row pair and looked clean, but that hid a severe blow-up right at the column's own centre line (row 16's near-side projection lands far off-screen, so a single bridge row produced one tile spanning 600-900px there); re-measured on the front arc specifically and landed on 21 inserted top rows so every front-arc tile lands in the wall's own established size range. Also found and fixed a matching seam defect: the near-facing exception's tiles sit at the column's own front pole, where the wall's fractional seam inset (never exercised there before) produced a 200px seam fringe along an axis-grazing edge; it now reuses the column's own axis-capped pixel inset. Rows 2-16, the painter, the rim constants, the camera, the waist/collar, the base construction and the plasma are unchanged.
…at 375 Every SVG label in the Fusion page's Mission Control visuals (FlightRecorder, PreflightChecklist, QueryTrack, SpecPatchbay, TelemetryStrip) rendered at about 6px on a 375px viewport, because their 640-unit viewBoxes scale down to about 333px there and the label font sizes scale with them, well under the site's 11px floor. Adds a viewport-aware label scale (mechanism a): useSvgLabelScale measures each SVG's rendered-width / viewBox-width ratio, and svgLabelSize sets each label's font size in viewBox units to max(base / scale, base) so the rendered pixel size never drops below its TYPE token's value; at scale >= 1 (desktop, where a visual already renders at or above its native size) this returns the base unchanged, so 1440 stays pixel-identical. A companion svgLabelWidth pins each boosted label's rendered width back to its unboosted footprint via textLength/lengthAdjust, and svgLabelGap widens the gap between two stacked lines only by however far they grew, so growing the font does not overlap, clip or wrap adjacent labels; a few rows (SpecPatchbay's seven-channel strip, PreflightChecklist's roster) that had no headroom for a full proportional boost cap growth at the same absolute 11px floor as any other label instead. useSvgLabelScale only boosts once the viewport itself has narrowed past a 1024px breakpoint, so a panel whose desktop layout already renders it narrower than its own viewBox (TelemetryStrip's sidebar slot) never has its desktop render nudged by this mechanism. The LayeredDiagram hero measured already compliant (plain HTML text, no viewBox scaling) and needed no change. Verification: a Playwright label walk of every <text> across all five visuals plus the diagram confirms 11px minimum at 375 (160 labels, smallest five now MOBILE, ONE QUERY, ONE ENDPOINT · QUERY PLAN, product.name and → CATALOG, all exactly 11px, versus about 5.2-6px before); an overlap/clip walk finds zero intersecting label boxes and zero labels outside their SVG at 375 across all five visuals; pixel diffs of all six panels' 1440 captures against their pre-edit references report maxDelta 0 and overCount 0; tsc --noEmit, eslint on visuals/ and hero/, and yarn format:check all pass clean; /products/fusion still answers 200.
…io override Review 1 on hc-0-bri found the 11px label floor was met by pinning every boosted label back to its pre-fix rendered width with textLength + lengthAdjust="spacingAndGlyphs", condensing glyphs to 0.29-0.48em per character against the mono face's natural ~0.6em and leaving legibility unimproved. tokens.ts drops svgLabelWidth and MONO_ADVANCE (svgLabelSize and svgLabelGap are still used); the mobile re-flow that replaces the pinning needs a visual to grow its own Scene stage taller than the desktop ratio below 1024px. Scene.tsx adds a SceneRatioContext and a useSceneRatio(override) hook a child can call to replace the stage's aspect-ratio at runtime; a null override (every caller today) leaves Scene rendering exactly as before, so FusionPage.tsx stays untouched and the 1440 render stays byte-identical.
…lumn
Below 1024px each of the five Mission Control visuals (PreflightChecklist,
FlightRecorder, QueryTrack, SpecPatchbay, TelemetryStrip) now renders a
second, mobile-only layout instead of squeezing the desktop layout's
textLength-pinned labels into a narrower box: a single-column viewBox
sized to this panel's own measured rendered width at 375px (333 units for
the four 640-viewBox visuals, 267 for TelemetryStrip's narrower aside),
driven by a Scene ratio override so the stage grows to fit. Every label
renders at its natural glyph advance (no textLength/lengthAdjust anywhere
in these five files now), and rows that don't fit their old two-column
positions re-flow: PreflightChecklist's roster stacks above the checklist,
FlightRecorder's deck rows grow to as many lines as their client/operation/
detail text need, QueryTrack's stations stack below the gateway, and
SpecPatchbay's channel strip stacks above the bus. TelemetryStrip's five
columns per row become three stacked lines (label+latency, meta+errors,
bar).
Five strings are wider than the mobile viewBox even at 0 letter-spacing
(confirmed by the review-1 verifier's own measurements) and don't fit on
one line no matter how they're re-flowed: PreflightChecklist's and
FlightRecorder's " · "-joined footer banners, FlightRecorder's deck header
and header composition line, and TelemetryStrip's footer caption. These
now split into stacked <tspan> lines at their " · " separators (each line
keeping its leading separator, so the lines' concatenated textContent is
the original string again, byte for byte) — the planner-ratified
resolution for hc-0-bri's NEEDS-PLANNER question on comment 402.
FlightRecorder's deck header needed a second, word-boundary split beyond
that single " · " (comment 402 anticipated only one split point); the same
byte-preserving technique also covers PreflightChecklist's conflict
caption ("Product.price: Float (Catalog) vs String (Billing)", also over
width and also not one of the five banner strings the ratification named)
and the dynamic replay operation/detail text in FlightRecorder's deck rows,
which is wrapped by a small word-boundary helper for the same reason:
recorded as NEEDS-PLANNER: does the "5 banner strings ... at their ' · '
separators" ratification cover a sixth over-width caption and dynamic
per-row content the same way, or only the five named strings? | chose the
same byte-preserving stacked-tspan technique for all of them, since the
alternative is a label rendering below 11px or clipped, both worse under
Rule D.
1440 renders pixel-identical to the pre-edit references (maxDelta 0,
overCount 0 on all six panels including LayeredDiagram, which needed no
change — it's plain HTML text, not SVG-viewBox-scaled, and was already
compliant per the review-1 implementer's report).
…geometry
The mobile branch drew the gateway latency trace with the desktop path
(TRACE_D, generated from the 560-unit TRACE geometry) while its panel rect
used MOBILE_TRACE, so at 375 the trace spanned x 16..544 inside a 267-unit
viewBox and sat more than half outside its panel. Extracted tracePoints/
tracePath(trace) helpers that build the same sawtooth shape from any
{x, y, w, h}; the desktop branch keeps TRACE_D = tracePath(TRACE), byte-
identical to before (1440 diff confirms maxDelta 0 on all six panels), and
the mobile branch now draws MOBILE_TRACE_D = tracePath(MOBILE_TRACE), which
fits inside its panel.
…y width TelemetryStrip's own aside slot renders narrower than its viewBox at every desktop width from 1024 to 1920, not just below 1024 — useSvgLabelScale was clamping that render ratio back to 1 at desktop widths so it would never trigger the mobile re-flow, which incidentally suppressed the label boost too, leaving labels as small as ~6.5px at 1024 and ~9.4px at 1440. useSvgLabelScale now always reports the SVG's true rendered-width / viewBox-width ratio; a new useNarrowViewport hook takes over deciding when a visual switches to its narrower mobile layout, so that switch stays keyed to the viewport alone. TelemetryStrip's own desktop row layout widens its label/meta column gap in proportion to the boost, and re-flows to a two-line row (still its own W-wide viewBox, not the mobile layout) once a boost that large no longer fits a single line; its footer wraps the same way. At 1440 the fix is pixel-identical everywhere except the now-legible label text itself.
…ed floor The same every-width label boost (previous commit) also applies at desktop widths for the Fusion page's other console visuals whenever their own FeatureRow slot renders narrower than their design width — true from 1024 up to roughly 1280 for PreflightChecklist and QueryTrack, briefly widening labels enough to collide with fixed-width neighbours: - PreflightChecklist: the roster's "SUBGRAPH · LANGUAGE" / "RUNTIME PLUGIN" header no longer fits side by side once boosted, so it stacks instead; the roster box widens into the roster/list gap so a boosted row's meta line still clears it; the conflict caption and footer banner wrap onto several lines the same way their mobile layout already does, growing the panel's own height to hold them. - QueryTrack: a station card's "PARTIAL RESULT RETURNED" status line wraps onto two lines once boosted, instead of running past the SVG's own right edge (a real clip, not just past its decorative card). Both re-flows are gated on the same narrow-slot condition the boost itself uses, so nothing changes at 1280 and up (1440 stays pixel-identical).
…mpty band Housekeeping carried over from hc-0-bri's review: TelemetryStrip, PreflightChecklist and FlightRecorder each defined their own copy of the same ` · `-separator line-splitter; FlightRecorder's deck header also reimplemented wrapWords inline instead of calling the helper it already uses for its replay rows. Both now live once, in a new visuals/lines.ts (not tokens.ts, which holds design values, not string helpers). SpecPatchbay's mobile bus panel also reused the desktop BUS.h (400) for a column that, stacked below the channel strip instead of beside it, only needs about 300 units for its own content — leaving an empty band of about 120px above its "COMPOSED IN THE BUILD" footer at 375. Its height now fits that content; 375 labels and containment are unaffected (only downstream page flow shifts up), and desktop is untouched since it still uses BUS, not BUS_M. FlightRecorder also picks up the useNarrowViewport swap from the first commit here, since it needed no other change for the label floor itself at any width.
…d to the labels it missed
Review 1 found that the boosted desktop label size (any scale < 1, not
just a specific width band) pushed six labels out of their own panel
rects at 1024 and worsened a pre-existing QueryTrack overflow at 1180:
- QueryTrack: `crowded` now engages at any boost (`scale < 1`, not just
`< 0.9`), so it reliably wraps at 1180 too. The GATE card's "ONE
ENDPOINT · QUERY PLAN" subtitle and each station card's
"<language> · <spec>" line now wrap onto two lines via `dotLines` once
crowded, same as the status line already did; the three plan rows (and
only those — LATENCY keeps its fixed slot near the card's bottom) shift
down by the subtitle's own wrap gap, and each station card's rect grows
by its spec line's extra line.
- SpecPatchbay: gained the same `crowded` gate other visuals already had.
Its footer caption ("COMPOSED IN THE BUILD" / "NO CUTOVER NEEDED") wraps
via `wrapWords` once crowded, growing upward from the bus rect's fixed
footer baseline so the last line never runs past it.
- FlightRecorder: gained a `crowded` gate for its 55-character deck header,
which wraps via `dotLines` past roughly scale 0.9 (1024 renders at
~0.801). The replay rows, the deck's own height and the footer banner
all shift down by that one wrapped line's gap, and the viewBox itself
grows (via `useSceneRatio`, the same mechanism PreflightChecklist uses)
to still hold it.
Re-run at all eight widths: under11 = 0, underAdv (advance < 0.55em) = 0
and outOfPanel is now empty at 1024 and 1180, leaving only the three
pre-existing "PARTIAL RESULT RETURNED" margins at 1280/1368/1440/1920
(-11.51/-12.56/-12.6/-12.6, unchanged from before this fix) — a residual
soft overflow past a small decorative card, out of this fix's scope.
375 stays byte-identical to hc-0-bri's own walk and bounds output.
1440 stays pixel-identical (maxDelta = 0) for all five of these visuals;
TelemetryStrip's own label-floor change from an earlier commit is
untouched here.
…ds its card Extend the station card's "PARTIAL RESULT RETURNED" / "SUBGRAPH STANDING BY" status line wrap past the crowded (boosted) gate: it now also wraps via wrapWords whenever the line's estimated width (char count times the mono face's measured natural advance plus its own letter-spacing) exceeds the card's own available room, independent of the crowded boost. This closes the residual overflow at 1280/1368/1440/1920 (previously -11.51/-12.56/-12.6/-12.6 viewBox units) left after the crowded gate fix, while 1024/1180 (already wrapped via crowded) and 375/768 (mobile layout, untouched) are unaffected. The station card's existing height formula already grows by the extra line, so no other geometry changed.
hc-0-b8z checkpoint 1. The top junction's rim (y/z/r) now mirrors the bottom's accepted SIDE_BOTTOM_RIM_* constants exactly about the band's y=0, replacing the withdrawn flared-dome top rim and the asymmetric SIDE_TOP_RIM_* constants (planner comment 426 supersedes the earlier top-rim-inside-canvas ruling). The top rim's front arc now runs above the canvas the same way the bottom rim's runs below it, so no dome, cap or ledge shows inside the canvas at the top at any side-by-side width. The top bridging sequence keeps the bottom's own buildBridgeRows construction (interpolated from the rim toward frozen wall row 16, then reversed into wall-to-rim order, mirroring bottom's rim-to-row2 construction exactly) but is NOT given the bottom's own step count: frozen wall row 16 has near-facing tiles at wide theta that intrude close to the canvas top edge regardless of the bridge's other endpoint (verified directly against a bare (row15,row16) pair, with no bridge/rim involved at all), unlike row 2's own near side, which is never in frame. Re-ran hc-0-gar's own front-arc search methodology against the new rim and landed on 8 steps (powerYZ=powerR=1.1): front- arc tile heights stay under 300px with every consecutive ratio inside [0.77, 1.3] (worst 1.09-1.23 across 1280/1440/1920), avoiding the single oversized 'buffer' tile a literal 2-step mirror would put at the visible corner.
hc-0-b8z checkpoint 2. The stacked mode's bandCenterY was weighted to 0.58 of the band area's height (a bias toward artTop for the rendered ring's own bloom extent); this ticket's centre requirement measures the band's projected centre directly against the band area's middle, which the 0.58 weighting missed by 8% of the band height. Moved to the exact midpoint (0.5), matching mobile's own construction, which was already exact. Side-by-side and mobile were already exactly centred by construction (project(torus centre) lands on originY, which is h*0.5 and artTop+(h-artTop)/2 respectively) -- unaffected. Re-verified the ring's own containment/exposure targets (rvv-ring.cjs, rvw2-exposure.cjs) and the copy-clear zone (wkf-zone.cjs) are unaffected by the shift.
…rofile hc-0-b8z correction (F1/F2/F3): the checkpoint-1 fix world-mirrored the top rim's y/z/r, but the camera's tilt makes a world-mirrored point project asymmetrically -- the column-only half-width sweep came out 15-63% off at the canvas edge instead of within the 5% bar. Replaces SIDE_TOP_RIM_Y/Z/R with a bounded search result (Y=227, Z=11, R=174) that matches the top limb's PROJECTED profile to the bottom's, and re-tunes SIDE_TOP_BRIDGE_STEPS/POWER_YZ/POWER_R (5, 0.9, 0.9) against the new rim's front-arc rhythm. Bottom constants, waist, rows/side and spacingPower are untouched.
hc-0-b8z correction (F3): the checkpoint-1 bridge retune (steps=5) was measured against a per-pair nearest-visible-segment method that diverges from rv2g-rhythm.cjs's own fixed-segment convention -- the ticket's actual rhythm gate -- just enough to miss [0.77, 1.3] (worst 1.30-1.40) at the new rim. Re-tunes SIDE_TOP_BRIDGE_STEPS/POWER_YZ/POWER_R (4, 0.82, 0.82) directly against rv2g-rhythm's method: worst ratio 1.14, max front-arc tile height 283.6px, both with margin.
rstaib
marked this pull request as ready for review
October 26, 2026 21:44
This was referenced Oct 28, 2026
Open
Merged
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
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.
No description provided.