Idea: reflective share card (tilt on phone, cursor on desktop), re-implementing sveltebits reflective-card #76

New issue

Open

opened 2026-10-07 10:04:39 +00:00 by kayg · 11 comments

kayg commented 2026-10-07 10:04:39 +00:00

Owner

Copy link

Owner idea (2026-10-07): when the machine info card is open for sharing (D126 share card), make it a reflective card, re-implementing the behaviour of the sveltebits "Reflective Card" (https://sveltebits.xyz, registry item reflective-card). That code is MIT + Commons Clause, so re-implement, never copy (CLAUDE.md).

• On phones, the reflection/specular highlight moves with device orientation (tilt).
• On desktop, it follows the cursor.
• It should feel very polished.

The sveltebits original is described as a "webcam-fed metallic glass card using SVG turbulence and specular" lighting. We would drive it from orientation or pointer instead of a webcam, so no camera permission is needed.

A research job fills this issue with everything needed to start later (no implementation yet).

Owner idea (2026-10-07): when the machine info card is open for **sharing** (D126 share card), make it a **reflective card**, re-implementing the behaviour of the sveltebits "Reflective Card" (https://sveltebits.xyz, registry item `reflective-card`). That code is MIT + Commons Clause, so **re-implement, never copy** (CLAUDE.md). - On phones, the reflection/specular highlight moves with **device orientation** (tilt). - On desktop, it follows the **cursor**. - It should feel very polished. The sveltebits original is described as a "webcam-fed metallic glass card using SVG turbulence and specular" lighting. We would drive it from orientation or pointer instead of a webcam, so no camera permission is needed. A research job fills this issue with everything needed to start later (no implementation yet).

kayg commented 2026-10-07 10:05:13 +00:00

Author

Owner

Copy link

Starting research on branch research-reflective from base SHA 3e7b90bb67. Issue view reports 0 comments; locating the parent issue before proceeding.

Starting research on branch research-reflective from base SHA 3e7b90bb6787c4466103f0a6de48ea9318aa28d2. Issue view reports 0 comments; locating the parent issue before proceeding.

kayg referenced this issue 2026-10-07 10:11:03 +00:00

Status board: work in flight (kept current) #24

kayg commented 2026-10-07 10:19:35 +00:00

Author

Owner

Copy link

Finding: final demo harness (Chromium 153, CPU 4x, 393x852 at DPR 3) recorded p50 16.7 ms, p95 33.4 ms, p99 66.6 ms, max 249.9 ms; 23 of 297 intervals exceeded 33.3 ms. Host load average was 9.88 with concurrent rustc/cc1/infraternal processes. After spring settle (1069 ms), callbacks were 0 for 1 s idle and 0 for 750 ms after close. This is a loaded desktop proxy, not an iPhone measurement.

Finding: final demo harness (Chromium 153, CPU 4x, 393x852 at DPR 3) recorded p50 16.7 ms, p95 33.4 ms, p99 66.6 ms, max 249.9 ms; 23 of 297 intervals exceeded 33.3 ms. Host load average was 9.88 with concurrent rustc/cc1/infraternal processes. After spring settle (1069 ms), callbacks were 0 for 1 s idle and 0 for 750 ms after close. This is a loaded desktop proxy, not an iPhone measurement.

kayg commented 2026-10-07 10:19:35 +00:00

Author

Owner

Copy link

Finding: iOS Safari exposes the motion requestPermission API from Safari 13, and the W3C method requires transient activation when it needs to prompt. I could not verify device-orientation grants failing to persist across every Home Screen PWA launch on iOS 17–27: WebKit #197750 describes older session-scoped grants; #280394 is camera-only. Recommend a tap on Enable tilt and a touch-drag fallback; no prompt on card open. Sources: https://developer.apple.com/documentation/safari-release-notes/safari-13-release-notes https://www.w3.org/TR/orientation-event/ https://bugs.webkit.org/show_bug.cgi?id=197750 https://bugs.webkit.org/show_bug.cgi?id=280394

Finding: iOS Safari exposes the motion requestPermission API from Safari 13, and the W3C method requires transient activation when it needs to prompt. I could not verify device-orientation grants failing to persist across every Home Screen PWA launch on iOS 17–27: WebKit #197750 describes older session-scoped grants; #280394 is camera-only. Recommend a tap on Enable tilt and a touch-drag fallback; no prompt on card open. Sources: https://developer.apple.com/documentation/safari-release-notes/safari-13-release-notes https://www.w3.org/TR/orientation-event/ https://bugs.webkit.org/show_bug.cgi?id=197750 https://bugs.webkit.org/show_bug.cgi?id=280394

kayg commented 2026-10-07 10:19:35 +00:00

Author

Owner

Copy link

Finding: Android sensor APIs are changing. Chromium's June 2026 ship plan targets M151, initially default ALLOW with a future plan to ASK; this worktree's headless Chromium 153 exposes DeviceOrientationEvent.requestPermission as a function. Use feature detection, not Android user-agent assumptions. Source: https://groups.google.com/a/chromium.org/g/blink-dev/c/ckd2rFmT3PA

Finding: Android sensor APIs are changing. Chromium's June 2026 ship plan targets M151, initially default ALLOW with a future plan to ASK; this worktree's headless Chromium 153 exposes DeviceOrientationEvent.requestPermission as a function. Use feature detection, not Android user-agent assumptions. Source: https://groups.google.com/a/chromium.org/g/blink-dev/c/ckd2rFmT3PA

kayg commented 2026-10-07 10:19:35 +00:00

Author

Owner

Copy link

Read all 43 comments on parent #48. D126 requires a square themed card shared as image or text with IPs hidden by default; D158 updates Machine presentation; D160 requires one reusable primitive in packages/ui. This worktree has no packages/ui directory at base 3e7b90b.

Read all 43 comments on parent #48. D126 requires a square themed card shared as image or text with IPs hidden by default; D158 updates Machine presentation; D160 requires one reusable primitive in packages/ui. This worktree has no packages/ui directory at base 3e7b90b.

kayg commented 2026-10-07 10:21:42 +00:00

Author

Owner

Copy link

Reflective share card: research report

Research date: 2026-10-07
Issue: kayg/infraternal#76
Scope: research only; the only behavior artifact is the standalone demo.

Recommendation

Use a single reusable packages/ui reflective surface made from a few static CSS gradient layers and one moving highlight overlay. Drive the overlay with transform and the existing shared spring, then stop the animation frame loop as soon as it settles. This gives the share card a soft metallic sheen without a camera, a filter graph, a WebGL context, or a per-frame gradient repaint.

On phones, show an Enable tilt affordance on the card. Call DeviceOrientationEvent.requestPermission() directly from that tap when the browser exposes it. Do not prompt just because the share card opened. Touch drag remains available if access is declined, unavailable, or produces no sensor events. On desktop, pointer position drives the same spring. Use one static, intentionally composed reflection pose for reduced motion and PNG export.

The live Reflective Card preview was inspected as a visual reference: it reads as softly cloudy metallic glass, with a broad pale sheen, a few edge glints, and enough diffuse texture to keep the surface from looking flat. This report describes that appearance and the general technique family only. The preview source was not reused or paraphrased; the demo was written from scratch.

1. Technique and cost

Technique	How it creates the look	Runtime cost and fit here
CSS gradients and blend modes	A dark or themed base, a radial hotspot, a broad conic or diagonal sheen, and a restrained edge highlight. screen, soft-light, or a theme-specific blend gives the layers a glassy overlap.	Cheapest suitable choice. Keep the gradients static and translate one overlay. The browser may keep that overlay in a composited layer, so pointer and tilt updates can avoid layout and repaint. Blend modes still need compositing and use pixels for the overlay bounds. Verify Safari paint/compositing on a phone.
SVG filter (feTurbulence, feSpecularLighting, optional displacement)	Turbulence makes a procedural noise field that can act like a rough surface; specular lighting turns its surface variation into bright glints; displacement can bend the underlying image. This produces richer, less uniform reflections than CSS alone.	Filter primitives operate on image regions and can create intermediate RGBA images. The SVG spec says processing and memory scale with the filter region and filterRes; MDN cautions that referenced SVG filters can be slow. WebKit historically described animated SVG filters as CPU-heavy. Current Safari behavior is hardware-, filter-, and version-dependent, so this is a profiling risk, not a claim that every current Safari filter always runs on CPU. Avoid recomputing a turbulence/light/displacement graph on each input event. SVG filter region and resolution, feTurbulence, feSpecularLighting, historical WebKit performance issue.
WebGL	A fragment shader can calculate procedural normals, colored highlights, and refraction in GPU passes. It can animate a surface with much more control than CSS.	Pixel work moves mostly to the GPU, but cost still grows with covered pixels, overdraw, passes, and texture size. A context, shader lifecycle, texture memory, and device-specific fallback are unnecessary complexity for one square card. Consider only if the owner asks for visibly warped/liquid reflections and a real-device benchmark justifies it. WebGL API overview.

Cheapest look that is close enough

The share card needs a moving highlight, not a physically correct reflection of the room. Use a themed base, two or three static radial/linear/conic gradient layers, a thin stationary edge treatment, and a single translated overlay. Keep the overlay modestly larger than the card so its edges do not show during movement. Avoid animating background-position, gradient stops, filter parameters, or a parent CSS variable on every sensor sample; those choices can trigger style recalculation or paint. Only the overlay itself needs to move.

This is an approximation: CSS gives a smooth light sweep and colored haze, but it does not refract the card's surroundings or create true view-dependent reflection. If that visual gap matters after owner review, benchmark an SVG filter against a small WebGL shader on a real iPhone. Do not add a rendering library based on a desktop-only result.

The filter cost is tied to surface area. As a rough scale example, the demo's 361 CSS-pixel card at DPR 3 covers about 1.17 million device pixels. One full-resolution RGBA8 intermediate for that area is about 4.7 MB; four simultaneous full-size buffers would be about 18.8 MB before filter padding and engine overhead. That is a raw-buffer estimate, not a measured Safari allocation; engines can tile, reuse buffers, or choose another resolution. It illustrates why a multi-pass filter should stay small and should not be assumed free when several cards reuse the material. The SVG spec's region and filterRes guidance.

2. Input and motion

iOS Safari and Home Screen web apps

Safari added the device motion/orientation permission API on iOS 13. DeviceOrientationEvent.requestPermission() resolves to granted or denied; when the permission is still at its prompt state, the call needs transient user activation. The method is secure-context only, so the real phone test must use HTTPS. Call it in the tap handler itself, before any timer or unrelated await. The default argument requests relative orientation; there is no need to ask for compass/magnetometer access for a decorative tilt. Safari 13 release notes, MDN requestPermission reference, W3C method steps.

Treat the installed Home Screen web app as its own test context. Apple describes it as an app-like standalone launch, but I found no current Apple/WebKit documentation or motion-specific test matrix that establishes whether a deviceorientation grant persists identically between Safari and a Home Screen app for every iOS release from 17 through 27. The WebKit 2019 permission discussion describes grants cached for the current session; it is useful history, not proof of behavior on current iOS releases. Reports of repeated prompts in WebKit's PWA camera issue concern getUserMedia camera access, not orientation. The older WKWebView issue is a native-app web view, not Safari or an installed Home Screen web app. Those reports do not verify that motion permission resets on every PWA launch.

Finding: the reported lack of persistence is plausible enough to design around, but it is not verified for DeviceOrientationEvent across iOS 17–27. Safari's API gives the page a grant/deny result rather than a reliable cross-version persistence query. Keep a clear tap-to-enable control available after each launch; if the browser retained access, the call can resolve without a new prompt. If it did not, the user can grant again. A refusal or error must leave drag and pointer input working.

There is also a WebKit iOS 26 iframe report where an accepted motion prompt did not result in events inside a cross-origin frame. It was later marked as a duplicate after a fix landed in WebKit, but the tracker does not establish which shipped OS release contains it. Keep the reflective surface in the app's top-level document instead of introducing an iframe boundary.

Android, desktop, and fallback

Android browsers have generally delivered device orientation without a Safari-style prompt. That assumption is changing in Chromium: its June 2026 Intent to Ship targets milestone 151 for desktop and Android. The initial rollout keeps the existing default permission as ALLOW, while the proposal says the longer-term plan may move it to ASK. In this worktree, headless Chromium 153 exposed DeviceOrientationEvent.requestPermission as a function. Feature-detect the method and handle its result; do not branch on Android user-agent strings or assume that a method's presence means a prompt will appear.

Input	Recommended behavior
Desktop mouse/trackpad	Map pointer position inside the card to a clamped highlight target. Return gently toward a composed rest angle on pointer leave.
Touch	Allow a one-finger drag over the card as the fallback. Use pointer capture after drag begins so the gesture can finish outside the card. The demo uses touch-action: none on the isolated card; product code must preserve the canvas's existing scroll and gesture contract.
Phone orientation	Ask only after the user taps Enable tilt. Read relative beta/gamma, calibrate against the first event, clamp the range, and remap axes if screen orientation changes. If permission is denied, the device has no usable sensor, or no events arrive, keep touch drag available.
Keyboard and assistive technology	Expose the enable control as a real button with a pressed state. The reflective motion is decorative; it must not carry host information or be required to share the card.

Spring and lifecycle

The local animation standards recommend a spring for decorative mouse tracking because it preserves velocity when the user reverses direction. Reuse the package's shared spring if available; do not add a one-off spring helper. The demo uses mass 1, stiffness 150, damping 25, which is close to critical damping and gives a responsive settle without visible bounce. Those numbers are a behavior example, not a locked product contract.

An input event should update a target and schedule at most one requestAnimationFrame. The frame callback advances the spring and writes transform on the highlight element. When position and velocity are within a small threshold, stop scheduling frames. Use visibilitychange to cancel an in-flight frame and detach orientation listening while hidden; close does the same. On return, refresh card bounds and reattach only if the user enabled tilt. Browsers usually pause animation frames in hidden tabs, but explicit cleanup also stops sensor work and makes the component lifecycle clear. Chrome animation guidance, Page Visibility API, W3C visibility requirements for sensor events.

While a visible card has tilt enabled, retain the minimal orientation listener so a new physical tilt can wake the effect. Do not run a polling loop. Ignore unchanged or sub-deadzone samples, and do no paint work when the target has not changed. Apple describes DeviceOrientationEvent as firing while the user changes device orientation. Apple DeviceOrientationEvent reference.

3. Performance evidence

The final demo was measured in Chromium 153.0.8010.12, headless, with DevTools CPU throttling at 4×, a 393×852 CSS viewport and DPR 3. Chrome documents 4× throttling as a mobile CPU proxy and cautions that desktop throttling cannot reproduce mobile CPU architecture. Chrome runtime performance guidance.

The harness swept a pointer over the card for 3.2 seconds and sampled frame timestamps. It recorded 298 timestamps (297 intervals) and 104 pointer updates. Frame interval results were 19.18 ms mean, 16.7 ms median, 33.4 ms p95, 66.6 ms p99, 249.9 ms maximum; 23 of 297 intervals exceeded 33.3 ms. The spring returned to rest in about 1,069 ms. After the data-moving state cleared, it produced 0 spring callbacks during the next 1 second. Closing the card produced 0 more callbacks during 750 ms. A separate behavior check confirmed a pointer change to translate3d(13.0976px, -11.4604px, 0px), theme switching, zero callbacks after close, and zero animation callbacks with reduced motion enabled.

This was a loaded desktop stress observation, not an iPhone benchmark: the 8-CPU Intel Core i9-9900K host reported a 9.88 load average after the run, and concurrent Rust/C compilation and infraternal processes were visible. The median was one 60 Hz interval, but p95 and the long-tail intervals missed the 16.7 ms budget. The run therefore confirms that the demo becomes idle after settling; it does not prove a 60 fps iPhone result. Rerun the surface on an idle pinned perf machine and a physical iPhone before setting a product budget or approving the visual layer.

4. PNG and text export

CSS in the DOM does not appear automatically in a separately painted CanvasRenderingContext2D. If the image exporter draws the card on canvas, it must also draw the same gradient layers, blend treatment, and border itself; otherwise the exported PNG will omit the live reflection. A canvas can render radial gradients and export PNG data through toBlob. Canvas radial gradients, HTMLCanvasElement.toBlob.

Freeze a deliberate, attractive reflection pose for export—such as a soft upper-left sheen—and render it into the PNG. Do not let a transient pointer or device angle determine the shared file. D126 also allows a text share; text output has no visual reflection. For image sharing, test navigator.canShare({ files }) and call navigator.share() from the share-button activation. Web Share API, file share support.

5. Accessibility and contrast

• Under prefers-reduced-motion: reduce, use a static highlight pose, do not request or listen to motion sensors, and do not start a spring. MDN reduced motion.
• No flashing, pulsing, or automatic shimmer. The only movement follows explicit pointer, drag, or tilt input.
• Keep the card's text on a stable tinted/scrim layer above the highlight. Check contrast at the brightest and darkest highlight positions in both ink and paper themes. Normal text needs at least 4.5:1 and large text at least 3:1 under WCAG AA. WCAG 1.4.3.
• Preserve the existing accessible share-card labels and make the tilt control keyboard operable. Do not require tilt to read or export the Machine facts.

6. Reuse under D160

Make this a reusable ReflectiveSurface primitive in packages/ui, with the share-card content supplied by a slot/children. Suggested per-instance API:

intensity: 0..1
highlightColor: theme token or CSS color
inputSource: auto | pointer | orientation | static
active: card-open and visible state
reducedMotion: resolved user preference

The primitive should own the one sheen overlay, its input-to-target mapping, spring lifecycle, and cleanup. Reuse the shared spring and shared button/control patterns; let the share card provide the label for its tilt affordance. Do not copy a surface, button, or spring per card. Keep one active overlay per visible surface and zero scheduled animation frames at rest. The current worktree does not yet contain a packages/ui directory, so this report specifies the destination without creating or changing product code.

7. Suggested implementation plan and owner questions

1. Owner UX decision: use a visible Enable tilt tap inside the share card; do not show an iOS permission prompt just because the card opened. This is the recommended choice for an optional decorative effect. Keep drag available for users who decline or cannot use motion. If a later session needs permission again, the user taps again.
2. Surface contract: confirm intensity, highlightColor, inputSource, and active as per-instance properties. Keep the component content-agnostic and put it in packages/ui when that package is available.
3. Build the CSS version first: static layers, one transformed highlight, shared spring, card-relative pointer mapping, opt-in relative orientation, touch drag, and complete close/hidden/reduced-motion cleanup. No camera, no WebGL context, no animated SVG filter.
4. Implement export separately from live input: render a frozen default reflection into the PNG. Keep text sharing separate and continue hiding IPs by default per D126.
5. Review real production screenshots in ink and paper themes at phone and desktop sizes. Check the resting angle and extreme highlight positions for text contrast, and verify that the mobile drag does not break the canvas's existing gestures.
6. Test platform permission behavior on real devices: compare Safari and installed Home Screen web app on supported iOS 17/18/26/27 devices where available; test first grant, deny, relaunch, background/foreground, and rotation. Test current Chrome Android and a non-Chromium Android browser. The current public evidence does not settle cross-launch motion permission persistence.
7. Measure before approval: capture a clean 4× Chromium performance trace and a real iPhone Safari trace, including spring p95/p99, idle callbacks, card-close cleanup, and visible/hidden sensor work. A GPU or filter-heavy alternative needs a measured visual/performance reason to replace CSS.

Open owner questions:

• Approve tap-to-enable tilt rather than prompting on first open? Recommended: tap-to-enable.
• Should a prior in-app preference resume orientation automatically when a card reopens, or should each new launch show Enable tilt until tapped? Recommended: do not issue permission requests without a tap; keep an explicit control when the browser's persisted grant is uncertain.
• Approve a fixed, attractive PNG reflection angle independent of the user's live tilt? Recommended: yes, for consistent exports.
• Is the CSS approximation visually close enough, or does the owner want a separate measured SVG/WebGL spike for visible refraction? Recommended: review CSS screenshots first, then request a spike only if the visual gap matters.

<!-- Role: research findings and implementation guidance for issue #76; this file does not change product contracts or code. --> # Reflective share card: research report Research date: 2026-10-07 Issue: `kayg/infraternal#76` Scope: research only; the only behavior artifact is the standalone [demo](./demo.html). ## Recommendation Use a single reusable `packages/ui` reflective surface made from a few static CSS gradient layers and one moving highlight overlay. Drive the overlay with `transform` and the existing shared spring, then stop the animation frame loop as soon as it settles. This gives the share card a soft metallic sheen without a camera, a filter graph, a WebGL context, or a per-frame gradient repaint. On phones, show an **Enable tilt** affordance on the card. Call `DeviceOrientationEvent.requestPermission()` directly from that tap when the browser exposes it. Do not prompt just because the share card opened. Touch drag remains available if access is declined, unavailable, or produces no sensor events. On desktop, pointer position drives the same spring. Use one static, intentionally composed reflection pose for reduced motion and PNG export. The live [Reflective Card preview](https://sveltebits.xyz/components/reflective-card) was inspected as a visual reference: it reads as softly cloudy metallic glass, with a broad pale sheen, a few edge glints, and enough diffuse texture to keep the surface from looking flat. This report describes that appearance and the general technique family only. The preview source was not reused or paraphrased; the demo was written from scratch. ## 1. Technique and cost | Technique | How it creates the look | Runtime cost and fit here | | --- | --- | --- | | CSS gradients and blend modes | A dark or themed base, a radial hotspot, a broad conic or diagonal sheen, and a restrained edge highlight. `screen`, `soft-light`, or a theme-specific blend gives the layers a glassy overlap. | **Cheapest suitable choice.** Keep the gradients static and translate one overlay. The browser may keep that overlay in a composited layer, so pointer and tilt updates can avoid layout and repaint. Blend modes still need compositing and use pixels for the overlay bounds. Verify Safari paint/compositing on a phone. | | SVG filter (`feTurbulence`, `feSpecularLighting`, optional displacement) | Turbulence makes a procedural noise field that can act like a rough surface; specular lighting turns its surface variation into bright glints; displacement can bend the underlying image. This produces richer, less uniform reflections than CSS alone. | Filter primitives operate on image regions and can create intermediate RGBA images. The SVG spec says processing and memory scale with the filter region and `filterRes`; MDN cautions that referenced SVG filters can be slow. WebKit historically described animated SVG filters as CPU-heavy. Current Safari behavior is hardware-, filter-, and version-dependent, so this is a **profiling risk**, not a claim that every current Safari filter always runs on CPU. Avoid recomputing a turbulence/light/displacement graph on each input event. [SVG filter region and resolution](https://www.w3.org/TR/SVG11/filters/#FilterElement), [`feTurbulence`](https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Element/feTurbulence), [`feSpecularLighting`](https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Element/feSpecularLighting), [historical WebKit performance issue](https://bugs.webkit.org/show_bug.cgi?id=43903). | | WebGL | A fragment shader can calculate procedural normals, colored highlights, and refraction in GPU passes. It can animate a surface with much more control than CSS. | Pixel work moves mostly to the GPU, but cost still grows with covered pixels, overdraw, passes, and texture size. A context, shader lifecycle, texture memory, and device-specific fallback are unnecessary complexity for one square card. Consider only if the owner asks for visibly warped/liquid reflections and a real-device benchmark justifies it. [WebGL API overview](https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API). | ### Cheapest look that is close enough The share card needs a moving highlight, not a physically correct reflection of the room. Use a themed base, two or three static radial/linear/conic gradient layers, a thin stationary edge treatment, and a single translated overlay. Keep the overlay modestly larger than the card so its edges do not show during movement. Avoid animating `background-position`, gradient stops, filter parameters, or a parent CSS variable on every sensor sample; those choices can trigger style recalculation or paint. Only the overlay itself needs to move. This is an approximation: CSS gives a smooth light sweep and colored haze, but it does not refract the card's surroundings or create true view-dependent reflection. If that visual gap matters after owner review, benchmark an SVG filter against a small WebGL shader on a real iPhone. Do not add a rendering library based on a desktop-only result. The filter cost is tied to surface area. As a rough scale example, the demo's 361 CSS-pixel card at DPR 3 covers about 1.17 million device pixels. One full-resolution RGBA8 intermediate for that area is about 4.7 MB; four simultaneous full-size buffers would be about 18.8 MB before filter padding and engine overhead. That is a raw-buffer estimate, **not** a measured Safari allocation; engines can tile, reuse buffers, or choose another resolution. It illustrates why a multi-pass filter should stay small and should not be assumed free when several cards reuse the material. [The SVG spec's region and `filterRes` guidance](https://www.w3.org/TR/SVG11/filters/#FilterElement). ## 2. Input and motion ### iOS Safari and Home Screen web apps Safari added the device motion/orientation permission API on iOS 13. `DeviceOrientationEvent.requestPermission()` resolves to `granted` or `denied`; when the permission is still at its prompt state, the call needs transient user activation. The method is secure-context only, so the real phone test must use HTTPS. Call it in the tap handler itself, before any timer or unrelated `await`. The default argument requests relative orientation; there is no need to ask for compass/magnetometer access for a decorative tilt. [Safari 13 release notes](https://developer.apple.com/documentation/safari-release-notes/safari-13-release-notes), [MDN requestPermission reference](https://developer.mozilla.org/en-US/docs/Web/API/DeviceOrientationEvent/requestPermission_static), [W3C method steps](https://www.w3.org/TR/orientation-event/#dom-deviceorientationevent-requestpermission). Treat the installed Home Screen web app as its own test context. Apple describes it as an app-like standalone launch, but I found no current Apple/WebKit documentation or motion-specific test matrix that establishes whether a `deviceorientation` grant persists identically between Safari and a Home Screen app for every iOS release from 17 through 27. The WebKit [2019 permission discussion](https://bugs.webkit.org/show_bug.cgi?id=197750) describes grants cached for the current session; it is useful history, not proof of behavior on current iOS releases. Reports of repeated prompts in [WebKit's PWA camera issue](https://bugs.webkit.org/show_bug.cgi?id=280394) concern `getUserMedia` camera access, not orientation. The older [WKWebView issue](https://bugs.webkit.org/show_bug.cgi?id=213468) is a native-app web view, not Safari or an installed Home Screen web app. Those reports do not verify that motion permission resets on every PWA launch. **Finding:** the reported lack of persistence is plausible enough to design around, but it is not verified for `DeviceOrientationEvent` across iOS 17–27. Safari's API gives the page a grant/deny result rather than a reliable cross-version persistence query. Keep a clear tap-to-enable control available after each launch; if the browser retained access, the call can resolve without a new prompt. If it did not, the user can grant again. A refusal or error must leave drag and pointer input working. There is also a [WebKit iOS 26 iframe report](https://bugs.webkit.org/show_bug.cgi?id=301294) where an accepted motion prompt did not result in events inside a cross-origin frame. It was later marked as a duplicate after a fix landed in WebKit, but the tracker does not establish which shipped OS release contains it. Keep the reflective surface in the app's top-level document instead of introducing an iframe boundary. ### Android, desktop, and fallback Android browsers have generally delivered device orientation without a Safari-style prompt. That assumption is changing in Chromium: its [June 2026 Intent to Ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/ckd2rFmT3PA) targets milestone 151 for desktop and Android. The initial rollout keeps the existing default permission as `ALLOW`, while the proposal says the longer-term plan may move it to `ASK`. In this worktree, headless Chromium 153 exposed `DeviceOrientationEvent.requestPermission` as a function. **Feature-detect the method and handle its result; do not branch on Android user-agent strings or assume that a method's presence means a prompt will appear.** | Input | Recommended behavior | | --- | --- | | Desktop mouse/trackpad | Map pointer position inside the card to a clamped highlight target. Return gently toward a composed rest angle on pointer leave. | | Touch | Allow a one-finger drag over the card as the fallback. Use pointer capture after drag begins so the gesture can finish outside the card. The demo uses `touch-action: none` on the isolated card; product code must preserve the canvas's existing scroll and gesture contract. | | Phone orientation | Ask only after the user taps **Enable tilt**. Read relative `beta`/`gamma`, calibrate against the first event, clamp the range, and remap axes if screen orientation changes. If permission is denied, the device has no usable sensor, or no events arrive, keep touch drag available. | | Keyboard and assistive technology | Expose the enable control as a real button with a pressed state. The reflective motion is decorative; it must not carry host information or be required to share the card. | ### Spring and lifecycle The local animation standards recommend a spring for decorative mouse tracking because it preserves velocity when the user reverses direction. Reuse the package's shared spring if available; do not add a one-off spring helper. The demo uses mass 1, stiffness 150, damping 25, which is close to critical damping and gives a responsive settle without visible bounce. Those numbers are a behavior example, not a locked product contract. An input event should update a target and schedule at most one `requestAnimationFrame`. The frame callback advances the spring and writes `transform` on the highlight element. When position and velocity are within a small threshold, stop scheduling frames. Use `visibilitychange` to cancel an in-flight frame and detach orientation listening while hidden; close does the same. On return, refresh card bounds and reattach only if the user enabled tilt. Browsers usually pause animation frames in hidden tabs, but explicit cleanup also stops sensor work and makes the component lifecycle clear. [Chrome animation guidance](https://web.dev/articles/animations-and-performance), [Page Visibility API](https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API), [W3C visibility requirements for sensor events](https://www.w3.org/TR/orientation-event/#deviceorientation). While a visible card has tilt enabled, retain the minimal orientation listener so a new physical tilt can wake the effect. Do not run a polling loop. Ignore unchanged or sub-deadzone samples, and do no paint work when the target has not changed. Apple describes `DeviceOrientationEvent` as firing while the user changes device orientation. [Apple DeviceOrientationEvent reference](https://developer.apple.com/documentation/webkitjs/deviceorientationevent). ## 3. Performance evidence The final demo was measured in Chromium **153.0.8010.12**, headless, with DevTools CPU throttling at **4×**, a **393×852 CSS viewport** and **DPR 3**. Chrome documents 4× throttling as a mobile CPU proxy and cautions that desktop throttling cannot reproduce mobile CPU architecture. [Chrome runtime performance guidance](https://developer.chrome.com/docs/devtools/performance). The harness swept a pointer over the card for 3.2 seconds and sampled frame timestamps. It recorded 298 timestamps (297 intervals) and 104 pointer updates. Frame interval results were **19.18 ms mean, 16.7 ms median, 33.4 ms p95, 66.6 ms p99, 249.9 ms maximum**; 23 of 297 intervals exceeded 33.3 ms. The spring returned to rest in about **1,069 ms**. After the `data-moving` state cleared, it produced **0 spring callbacks during the next 1 second**. Closing the card produced **0 more callbacks during 750 ms**. A separate behavior check confirmed a pointer change to `translate3d(13.0976px, -11.4604px, 0px)`, theme switching, zero callbacks after close, and zero animation callbacks with reduced motion enabled. This was a **loaded desktop stress observation**, not an iPhone benchmark: the 8-CPU Intel Core i9-9900K host reported a 9.88 load average after the run, and concurrent Rust/C compilation and infraternal processes were visible. The median was one 60 Hz interval, but p95 and the long-tail intervals missed the 16.7 ms budget. The run therefore confirms that the demo becomes idle after settling; it does **not** prove a 60 fps iPhone result. Rerun the surface on an idle pinned perf machine and a physical iPhone before setting a product budget or approving the visual layer. ## 4. PNG and text export CSS in the DOM does not appear automatically in a separately painted `CanvasRenderingContext2D`. If the image exporter draws the card on canvas, it must also draw the same gradient layers, blend treatment, and border itself; otherwise the exported PNG will omit the live reflection. A canvas can render radial gradients and export PNG data through `toBlob`. [Canvas radial gradients](https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/createRadialGradient), [`HTMLCanvasElement.toBlob`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toBlob). Freeze a deliberate, attractive reflection pose for export—such as a soft upper-left sheen—and render it into the PNG. Do not let a transient pointer or device angle determine the shared file. D126 also allows a text share; text output has no visual reflection. For image sharing, test `navigator.canShare({ files })` and call `navigator.share()` from the share-button activation. [Web Share API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Share_API), [file share support](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/share). ## 5. Accessibility and contrast - Under `prefers-reduced-motion: reduce`, use a static highlight pose, do not request or listen to motion sensors, and do not start a spring. [MDN reduced motion](https://developer.mozilla.org/en-US/docs/Web/CSS/%40media/prefers-reduced-motion). - No flashing, pulsing, or automatic shimmer. The only movement follows explicit pointer, drag, or tilt input. - Keep the card's text on a stable tinted/scrim layer above the highlight. Check contrast at the brightest and darkest highlight positions in both ink and paper themes. Normal text needs at least **4.5:1** and large text at least **3:1** under WCAG AA. [WCAG 1.4.3](https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html). - Preserve the existing accessible share-card labels and make the tilt control keyboard operable. Do not require tilt to read or export the Machine facts. ## 6. Reuse under D160 Make this a reusable `ReflectiveSurface` primitive in `packages/ui`, with the share-card content supplied by a slot/children. Suggested per-instance API: ```text intensity: 0..1 highlightColor: theme token or CSS color inputSource: auto | pointer | orientation | static active: card-open and visible state reducedMotion: resolved user preference ``` The primitive should own the one sheen overlay, its input-to-target mapping, spring lifecycle, and cleanup. Reuse the shared spring and shared button/control patterns; let the share card provide the label for its tilt affordance. Do not copy a surface, button, or spring per card. Keep one active overlay per visible surface and zero scheduled animation frames at rest. The current worktree does not yet contain a `packages/ui` directory, so this report specifies the destination without creating or changing product code. ## 7. Suggested implementation plan and owner questions 1. **Owner UX decision:** use a visible **Enable tilt** tap inside the share card; do not show an iOS permission prompt just because the card opened. This is the recommended choice for an optional decorative effect. Keep drag available for users who decline or cannot use motion. If a later session needs permission again, the user taps again. 2. **Surface contract:** confirm `intensity`, `highlightColor`, `inputSource`, and `active` as per-instance properties. Keep the component content-agnostic and put it in `packages/ui` when that package is available. 3. **Build the CSS version first:** static layers, one transformed highlight, shared spring, card-relative pointer mapping, opt-in relative orientation, touch drag, and complete close/hidden/reduced-motion cleanup. No camera, no WebGL context, no animated SVG filter. 4. **Implement export separately from live input:** render a frozen default reflection into the PNG. Keep text sharing separate and continue hiding IPs by default per D126. 5. **Review real production screenshots** in ink and paper themes at phone and desktop sizes. Check the resting angle and extreme highlight positions for text contrast, and verify that the mobile drag does not break the canvas's existing gestures. 6. **Test platform permission behavior on real devices:** compare Safari and installed Home Screen web app on supported iOS 17/18/26/27 devices where available; test first grant, deny, relaunch, background/foreground, and rotation. Test current Chrome Android and a non-Chromium Android browser. The current public evidence does not settle cross-launch motion permission persistence. 7. **Measure before approval:** capture a clean 4× Chromium performance trace and a real iPhone Safari trace, including spring p95/p99, idle callbacks, card-close cleanup, and visible/hidden sensor work. A GPU or filter-heavy alternative needs a measured visual/performance reason to replace CSS. Open owner questions: - Approve tap-to-enable tilt rather than prompting on first open? **Recommended: tap-to-enable.** - Should a prior in-app preference resume orientation automatically when a card reopens, or should each new launch show **Enable tilt** until tapped? **Recommended: do not issue permission requests without a tap; keep an explicit control when the browser's persisted grant is uncertain.** - Approve a fixed, attractive PNG reflection angle independent of the user's live tilt? **Recommended: yes, for consistent exports.** - Is the CSS approximation visually close enough, or does the owner want a separate measured SVG/WebGL spike for visible refraction? **Recommended: review CSS screenshots first, then request a spike only if the visual gap matters.**

kayg commented 2026-10-07 10:22:29 +00:00

Author

Owner

Copy link

Gate blocked: scripts/verify is absent from this worktree; scripts/ contains only perf-run. Running scripts/verify fast exited 127: zsh:1: no such file or directory: scripts/verify. A repository fast-gate entry point is needed from the owner/orchestrator to produce a valid gate result. No product code was changed.

Gate blocked: scripts/verify is absent from this worktree; scripts/ contains only perf-run. Running scripts/verify fast exited 127: zsh:1: no such file or directory: scripts/verify. A repository fast-gate entry point is needed from the owner/orchestrator to produce a valid gate result. No product code was changed.

kayg commented 2026-10-07 10:22:44 +00:00

Author

Owner

Copy link

Finished research-only work. Commits: e6c9fed (behavior demo), a7c03e7 (report). HEAD: a7c03e75c7. Worktree clean. Full findings are posted above and committed in research/reflective-card/REPORT.md; standalone demo: research/reflective-card/demo.html. scripts/verify fast exited 127; output verbatim: zsh:1: no such file or directory: scripts/verify

Finished research-only work. Commits: e6c9fed (behavior demo), a7c03e7 (report). HEAD: a7c03e75c7760a164a1cdae048e2432fa3cdc2f0. Worktree clean. Full findings are posted above and committed in research/reflective-card/REPORT.md; standalone demo: research/reflective-card/demo.html. scripts/verify fast exited 127; output verbatim: zsh:1: no such file or directory: scripts/verify

kayg commented 2026-10-07 10:25:32 +00:00

Author

Owner

Copy link

Review findings to fix: the report recommends orientation-axis remapping but the demo maps beta/gamma directly; the W3C event coordinates remain device-relative when the screen rotates. Also, pointerleave only recenters when tilt is disabled, so a no-sensor-event fallback can stay parked. Finally, Chrome 4x throttle is relative to the host, and the sampled rAF intervals should be compared to a 60 Hz interval, not called misses against an established card budget. I will align the demo and wording.

Review findings to fix: the report recommends orientation-axis remapping but the demo maps beta/gamma directly; the W3C event coordinates remain device-relative when the screen rotates. Also, pointerleave only recenters when tilt is disabled, so a no-sensor-event fallback can stay parked. Finally, Chrome 4x throttle is relative to the host, and the sampled rAF intervals should be compared to a 60 Hz interval, not called misses against an established card budget. I will align the demo and wording.

kayg commented 2026-10-07 10:27:41 +00:00

Author

Owner

Copy link

Reflective share card: research report

Research date: 2026-10-07
Issue: kayg/infraternal#76
Scope: research only; the only behavior artifact is the standalone demo.

Recommendation

Use a single reusable packages/ui reflective surface made from a few static CSS gradient layers and one moving highlight overlay. Drive the overlay with transform and the existing shared spring, then stop the animation frame loop as soon as it settles. This gives the share card a soft metallic sheen without a camera, a filter graph, a WebGL context, or a per-frame gradient repaint.

On phones, show an Enable tilt affordance on the card. Call DeviceOrientationEvent.requestPermission() directly from that tap when the browser exposes it. Do not prompt just because the share card opened. Touch drag remains available if access is declined, unavailable, or produces no sensor events. On desktop, pointer position drives the same spring. Use one static, intentionally composed reflection pose for reduced motion and PNG export.

The live Reflective Card preview was inspected as a visual reference: it reads as softly cloudy metallic glass, with a broad pale sheen, a few edge glints, and enough diffuse texture to keep the surface from looking flat. This report describes that appearance and the general technique family only. The preview source was not reused or paraphrased; the demo was written from scratch.

1. Technique and cost

Technique	How it creates the look	Runtime cost and fit here
CSS gradients and blend modes	A dark or themed base, a radial hotspot, a broad conic or diagonal sheen, and a restrained edge highlight. screen, soft-light, or a theme-specific blend gives the layers a glassy overlap.	Cheapest suitable choice. Keep the gradients static and translate one overlay. The browser may keep that overlay in a composited layer, so pointer and tilt updates can avoid layout and repaint. Blend modes still need compositing and use pixels for the overlay bounds. Verify Safari paint/compositing on a phone.
SVG filter (feTurbulence, feSpecularLighting, optional displacement)	Turbulence makes a procedural noise field that can act like a rough surface; specular lighting turns its surface variation into bright glints; displacement can bend the underlying image. This produces richer, less uniform reflections than CSS alone.	Filter primitives operate on image regions and can create intermediate RGBA images. The SVG spec says processing and memory scale with the filter region and filterRes; MDN cautions that referenced SVG filters can be slow. WebKit historically described animated SVG filters as CPU-heavy. Current Safari behavior is hardware-, filter-, and version-dependent, so this is a profiling risk, not a claim that every current Safari filter always runs on CPU. Avoid recomputing a turbulence/light/displacement graph on each input event. SVG filter region and resolution, feTurbulence, feSpecularLighting, historical WebKit performance issue.
WebGL	A fragment shader can calculate procedural normals, colored highlights, and refraction in GPU passes. It can animate a surface with much more control than CSS.	Pixel work moves mostly to the GPU, but cost still grows with covered pixels, overdraw, passes, and texture size. A context, shader lifecycle, texture memory, and device-specific fallback are unnecessary complexity for one square card. Consider only if the owner asks for visibly warped/liquid reflections and a real-device benchmark justifies it. WebGL API overview.

Cheapest look that is close enough

The share card needs a moving highlight, not a physically correct reflection of the room. Use a themed base, two or three static radial/linear/conic gradient layers, a thin stationary edge treatment, and a single translated overlay. Keep the overlay modestly larger than the card so its edges do not show during movement. Avoid animating background-position, gradient stops, filter parameters, or a parent CSS variable on every sensor sample; those choices can trigger style recalculation or paint. Only the overlay itself needs to move.

This is an approximation: CSS gives a smooth light sweep and colored haze, but it does not refract the card's surroundings or create true view-dependent reflection. If that visual gap matters after owner review, benchmark an SVG filter against a small WebGL shader on a real iPhone. Do not add a rendering library based on a desktop-only result.

The filter cost is tied to surface area. As a rough scale example, the demo's 361 CSS-pixel card at DPR 3 covers about 1.17 million device pixels. One full-resolution RGBA8 intermediate for that area is about 4.7 MB; four simultaneous full-size buffers would be about 18.8 MB before filter padding and engine overhead. That is a raw-buffer estimate, not a measured Safari allocation; engines can tile, reuse buffers, or choose another resolution. It illustrates why a multi-pass filter should stay small and should not be assumed free when several cards reuse the material. The SVG spec's region and filterRes guidance.

2. Input and motion

iOS Safari and Home Screen web apps

Safari added the device motion/orientation permission API on iOS 13. DeviceOrientationEvent.requestPermission() resolves to granted or denied; when the permission is still at its prompt state, the call needs transient user activation. The method is secure-context only, so the real phone test must use HTTPS. Call it in the tap handler itself, before any timer or unrelated await. The default argument requests relative orientation; there is no need to ask for compass/magnetometer access for a decorative tilt. Safari 13 release notes, MDN requestPermission reference, W3C method steps.

Treat the installed Home Screen web app as its own test context. Apple describes it as an app-like standalone launch, but I found no current Apple/WebKit documentation or motion-specific test matrix that establishes whether a deviceorientation grant persists identically between Safari and a Home Screen app for every iOS release from 17 through 27. The WebKit 2019 permission discussion describes grants cached for the current session; it is useful history, not proof of behavior on current iOS releases. Reports of repeated prompts in WebKit's PWA camera issue concern getUserMedia camera access, not orientation. The older WKWebView issue is a native-app web view, not Safari or an installed Home Screen web app. Those reports do not verify that motion permission resets on every PWA launch.

Finding: the reported lack of persistence is plausible enough to design around, but it is not verified for DeviceOrientationEvent across iOS 17–27. Safari's API gives the page a grant/deny result rather than a reliable cross-version persistence query. Keep a clear tap-to-enable control available after each launch; if the browser retained access, the call can resolve without a new prompt. If it did not, the user can grant again. A refusal or error must leave drag and pointer input working.

There is also a WebKit iOS 26 iframe report where an accepted motion prompt did not result in events inside a cross-origin frame. It was later marked as a duplicate after a fix landed in WebKit, but the tracker does not establish which shipped OS release contains it. Keep the reflective surface in the app's top-level document instead of introducing an iframe boundary.

Android, desktop, and fallback

Android browsers have generally delivered device orientation without a Safari-style prompt. That assumption is changing in Chromium: its June 2026 Intent to Ship targets milestone 151 for desktop and Android. The initial rollout keeps the existing default permission as ALLOW, while the proposal says the longer-term plan may move it to ASK. In this worktree, headless Chromium 153 exposed DeviceOrientationEvent.requestPermission as a function. Feature-detect the method and handle its result; do not branch on Android user-agent strings or assume that a method's presence means a prompt will appear.

Input	Recommended behavior
Desktop mouse/trackpad	Map pointer position inside the card to a clamped highlight target. Return gently toward a composed rest angle on pointer leave.
Touch	Allow a one-finger drag over the card as the fallback. Use pointer capture after drag begins so the gesture can finish outside the card. The demo uses touch-action: none on the isolated card; product code must preserve the canvas's existing scroll and gesture contract.
Phone orientation	Ask only after the user taps Enable tilt. Read relative beta/gamma, calibrate against the first event, clamp the range, and remap axes if screen orientation changes because sensor coordinates remain device-relative. If permission is denied, the device has no usable sensor, or no events arrive, keep touch drag available. W3C coordinate model.
Keyboard and assistive technology	Expose the enable control as a real button with a pressed state. The reflective motion is decorative; it must not carry host information or be required to share the card.

Spring and lifecycle

The local animation standards recommend a spring for decorative mouse tracking because it preserves velocity when the user reverses direction. Reuse the package's shared spring if available; do not add a one-off spring helper. The demo uses mass 1, stiffness 150, damping 25, which is close to critical damping and gives a responsive settle without visible bounce. Those numbers are a behavior example, not a locked product contract.

An input event should update a target and schedule at most one requestAnimationFrame. The frame callback advances the spring and writes transform on the highlight element. When position and velocity are within a small threshold, stop scheduling frames. Use visibilitychange to cancel an in-flight frame and detach orientation listening while hidden; close does the same. On return, refresh card bounds and reattach only if the user enabled tilt. Browsers usually pause animation frames in hidden tabs, but explicit cleanup also stops sensor work and makes the component lifecycle clear. Chrome animation guidance, Page Visibility API, W3C visibility requirements for sensor events.

While a visible card has tilt enabled, retain the minimal orientation listener so a new physical tilt can wake the effect. Do not run a polling loop. Ignore unchanged or sub-deadzone samples, and do no paint work when the target has not changed. Apple describes DeviceOrientationEvent as firing while the user changes device orientation. Apple DeviceOrientationEvent reference.

3. Performance evidence

The final demo was measured in Chromium 153.0.8010.12, headless, with DevTools CPU throttling at 4×, a 393×852 CSS viewport and DPR 3. Chrome describes CPU throttling as a relative slowdown applied to the host and recommends calibrated presets when approximating a target device. This 4× run is a relative stress factor, not a mobile CPU proxy; desktop throttling cannot reproduce mobile CPU architecture. Chrome CPU throttling guidance.

The harness swept a pointer over the card for 3.2 seconds and sampled requestAnimationFrame timestamps. Two runs recorded 104 pointer updates each:

Run	Samples	Mean / p50 / p95 / p99 / max interval	Intervals over 33.3 ms	Host load
Initial run	298 timestamps (297 intervals)	19.18 / 16.7 / 33.4 / 66.6 / 249.9 ms	23	1-minute load 9.88 after run
Updated demo rerun	194 timestamps (193 intervals)	16.67 / 16.7 / 16.7 / 16.8 / 16.8 ms	0	7.68 / 7.92 / 7.08 (1 / 5 / 15-minute load before run)

Both runs used the same spring and frame-update path. The source changes between them added screen-axis remapping and restored pointer-leave recentering; the host load also changed, so the interval difference does not isolate a code effect. The spring returned to rest in about 1,069 ms. In the updated run, after the data-moving state cleared, it produced 0 spring callbacks during the next 1 second; closing the card produced 0 more callbacks during 750 ms. The behavior check confirmed a simulated 90° screen rotation moved a beta tilt into the horizontal axis (translate x 8.55 px, y −0.01 px) and mouse leave returned the overlay to within 0.01 px of rest. A separate check confirmed theme switching, zero callbacks after close, and zero animation callbacks with reduced motion enabled.

These were loaded desktop stress observations, not an iPhone benchmark: the host has 8 CPU cores (Intel Core i9-9900K), and concurrent Rust/C compilation and infraternal processes were visible during the initial run. The median was one 60 Hz interval in both runs; the initial run's p95 and long-tail intervals exceeded one 60 Hz interval. These are sampled requestAnimationFrame timestamp intervals, not rendered-frame latency, and no reflective-card frame budget has been established. The runs confirm that the demo becomes idle after settling; they do not prove a 60 fps iPhone result. Rerun the surface on an idle pinned perf machine and a physical iPhone before setting a product budget or approving the visual layer.

4. PNG and text export

CSS in the DOM does not appear automatically in a separately painted CanvasRenderingContext2D. If the image exporter draws the card on canvas, it must also draw the same gradient layers, blend treatment, and border itself; otherwise the exported PNG will omit the live reflection. A canvas can render radial gradients and export PNG data through toBlob. Canvas radial gradients, HTMLCanvasElement.toBlob.

Freeze a deliberate, attractive reflection pose for export—such as a soft upper-left sheen—and render it into the PNG. Do not let a transient pointer or device angle determine the shared file. D126 also allows a text share; text output has no visual reflection. For image sharing, test navigator.canShare({ files }) and call navigator.share() from the share-button activation. Web Share API, file share support.

5. Accessibility and contrast

• Under prefers-reduced-motion: reduce, use a static highlight pose, do not request or listen to motion sensors, and do not start a spring. MDN reduced motion.
• No flashing, pulsing, or automatic shimmer. The only movement follows explicit pointer, drag, or tilt input.
• Keep the card's text on a stable tinted/scrim layer above the highlight. Check contrast at the brightest and darkest highlight positions in both ink and paper themes. Normal text needs at least 4.5:1 and large text at least 3:1 under WCAG AA. WCAG 1.4.3.
• Preserve the existing accessible share-card labels and make the tilt control keyboard operable. Do not require tilt to read or export the Machine facts.

6. Reuse under D160

Make this a reusable ReflectiveSurface primitive in packages/ui, with the share-card content supplied by a slot/children. Suggested per-instance API:

intensity: 0..1
highlightColor: theme token or CSS color
inputSource: auto | pointer | orientation | static
active: card-open and visible state
reducedMotion: resolved user preference

The primitive should own the one sheen overlay, its input-to-target mapping, spring lifecycle, and cleanup. Reuse the shared spring and shared button/control patterns; let the share card provide the label for its tilt affordance. Do not copy a surface, button, or spring per card. Keep one active overlay per visible surface and zero scheduled animation frames at rest. The current worktree does not yet contain a packages/ui directory, so this report specifies the destination without creating or changing product code.

7. Suggested implementation plan and owner questions

1. Owner UX decision: use a visible Enable tilt tap inside the share card; do not show an iOS permission prompt just because the card opened. This is the recommended choice for an optional decorative effect. Keep drag available for users who decline or cannot use motion. If a later session needs permission again, the user taps again.
2. Surface contract: confirm intensity, highlightColor, inputSource, and active as per-instance properties. Keep the component content-agnostic and put it in packages/ui when that package is available.
3. Build the CSS version first: static layers, one transformed highlight, shared spring, card-relative pointer mapping, opt-in relative orientation, touch drag, and complete close/hidden/reduced-motion cleanup. No camera, no WebGL context, no animated SVG filter.
4. Implement export separately from live input: render a frozen default reflection into the PNG. Keep text sharing separate and continue hiding IPs by default per D126.
5. Review real production screenshots in ink and paper themes at phone and desktop sizes. Check the resting angle and extreme highlight positions for text contrast, and verify that the mobile drag does not break the canvas's existing gestures.
6. Test platform permission behavior on real devices: compare Safari and installed Home Screen web app on supported iOS 17/18/26/27 devices where available; test first grant, deny, relaunch, background/foreground, and rotation. Test current Chrome Android and a non-Chromium Android browser. The current public evidence does not settle cross-launch motion permission persistence.
7. Measure before approval: capture a clean 4× Chromium performance trace and a real iPhone Safari trace, including spring p95/p99, idle callbacks, card-close cleanup, and visible/hidden sensor work. A GPU or filter-heavy alternative needs a measured visual/performance reason to replace CSS.

Open owner questions:

• Approve tap-to-enable tilt rather than prompting on first open? Recommended: tap-to-enable.
• Should a prior in-app preference resume orientation automatically when a card reopens, or should each new launch show Enable tilt until tapped? Recommended: do not issue permission requests without a tap; keep an explicit control when the browser's persisted grant is uncertain.
• Approve a fixed, attractive PNG reflection angle independent of the user's live tilt? Recommended: yes, for consistent exports.
• Is the CSS approximation visually close enough, or does the owner want a separate measured SVG/WebGL spike for visible refraction? Recommended: review CSS screenshots first, then request a spike only if the visual gap matters.

<!-- Role: research findings and implementation guidance for issue #76; this file does not change product contracts or code. --> # Reflective share card: research report Research date: 2026-10-07 Issue: `kayg/infraternal#76` Scope: research only; the only behavior artifact is the standalone [demo](./demo.html). ## Recommendation Use a single reusable `packages/ui` reflective surface made from a few static CSS gradient layers and one moving highlight overlay. Drive the overlay with `transform` and the existing shared spring, then stop the animation frame loop as soon as it settles. This gives the share card a soft metallic sheen without a camera, a filter graph, a WebGL context, or a per-frame gradient repaint. On phones, show an **Enable tilt** affordance on the card. Call `DeviceOrientationEvent.requestPermission()` directly from that tap when the browser exposes it. Do not prompt just because the share card opened. Touch drag remains available if access is declined, unavailable, or produces no sensor events. On desktop, pointer position drives the same spring. Use one static, intentionally composed reflection pose for reduced motion and PNG export. The live [Reflective Card preview](https://sveltebits.xyz/components/reflective-card) was inspected as a visual reference: it reads as softly cloudy metallic glass, with a broad pale sheen, a few edge glints, and enough diffuse texture to keep the surface from looking flat. This report describes that appearance and the general technique family only. The preview source was not reused or paraphrased; the demo was written from scratch. ## 1. Technique and cost | Technique | How it creates the look | Runtime cost and fit here | | --- | --- | --- | | CSS gradients and blend modes | A dark or themed base, a radial hotspot, a broad conic or diagonal sheen, and a restrained edge highlight. `screen`, `soft-light`, or a theme-specific blend gives the layers a glassy overlap. | **Cheapest suitable choice.** Keep the gradients static and translate one overlay. The browser may keep that overlay in a composited layer, so pointer and tilt updates can avoid layout and repaint. Blend modes still need compositing and use pixels for the overlay bounds. Verify Safari paint/compositing on a phone. | | SVG filter (`feTurbulence`, `feSpecularLighting`, optional displacement) | Turbulence makes a procedural noise field that can act like a rough surface; specular lighting turns its surface variation into bright glints; displacement can bend the underlying image. This produces richer, less uniform reflections than CSS alone. | Filter primitives operate on image regions and can create intermediate RGBA images. The SVG spec says processing and memory scale with the filter region and `filterRes`; MDN cautions that referenced SVG filters can be slow. WebKit historically described animated SVG filters as CPU-heavy. Current Safari behavior is hardware-, filter-, and version-dependent, so this is a **profiling risk**, not a claim that every current Safari filter always runs on CPU. Avoid recomputing a turbulence/light/displacement graph on each input event. [SVG filter region and resolution](https://www.w3.org/TR/SVG11/filters/#FilterElement), [`feTurbulence`](https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Element/feTurbulence), [`feSpecularLighting`](https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Element/feSpecularLighting), [historical WebKit performance issue](https://bugs.webkit.org/show_bug.cgi?id=43903). | | WebGL | A fragment shader can calculate procedural normals, colored highlights, and refraction in GPU passes. It can animate a surface with much more control than CSS. | Pixel work moves mostly to the GPU, but cost still grows with covered pixels, overdraw, passes, and texture size. A context, shader lifecycle, texture memory, and device-specific fallback are unnecessary complexity for one square card. Consider only if the owner asks for visibly warped/liquid reflections and a real-device benchmark justifies it. [WebGL API overview](https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API). | ### Cheapest look that is close enough The share card needs a moving highlight, not a physically correct reflection of the room. Use a themed base, two or three static radial/linear/conic gradient layers, a thin stationary edge treatment, and a single translated overlay. Keep the overlay modestly larger than the card so its edges do not show during movement. Avoid animating `background-position`, gradient stops, filter parameters, or a parent CSS variable on every sensor sample; those choices can trigger style recalculation or paint. Only the overlay itself needs to move. This is an approximation: CSS gives a smooth light sweep and colored haze, but it does not refract the card's surroundings or create true view-dependent reflection. If that visual gap matters after owner review, benchmark an SVG filter against a small WebGL shader on a real iPhone. Do not add a rendering library based on a desktop-only result. The filter cost is tied to surface area. As a rough scale example, the demo's 361 CSS-pixel card at DPR 3 covers about 1.17 million device pixels. One full-resolution RGBA8 intermediate for that area is about 4.7 MB; four simultaneous full-size buffers would be about 18.8 MB before filter padding and engine overhead. That is a raw-buffer estimate, **not** a measured Safari allocation; engines can tile, reuse buffers, or choose another resolution. It illustrates why a multi-pass filter should stay small and should not be assumed free when several cards reuse the material. [The SVG spec's region and `filterRes` guidance](https://www.w3.org/TR/SVG11/filters/#FilterElement). ## 2. Input and motion ### iOS Safari and Home Screen web apps Safari added the device motion/orientation permission API on iOS 13. `DeviceOrientationEvent.requestPermission()` resolves to `granted` or `denied`; when the permission is still at its prompt state, the call needs transient user activation. The method is secure-context only, so the real phone test must use HTTPS. Call it in the tap handler itself, before any timer or unrelated `await`. The default argument requests relative orientation; there is no need to ask for compass/magnetometer access for a decorative tilt. [Safari 13 release notes](https://developer.apple.com/documentation/safari-release-notes/safari-13-release-notes), [MDN requestPermission reference](https://developer.mozilla.org/en-US/docs/Web/API/DeviceOrientationEvent/requestPermission_static), [W3C method steps](https://www.w3.org/TR/orientation-event/#dom-deviceorientationevent-requestpermission). Treat the installed Home Screen web app as its own test context. Apple describes it as an app-like standalone launch, but I found no current Apple/WebKit documentation or motion-specific test matrix that establishes whether a `deviceorientation` grant persists identically between Safari and a Home Screen app for every iOS release from 17 through 27. The WebKit [2019 permission discussion](https://bugs.webkit.org/show_bug.cgi?id=197750) describes grants cached for the current session; it is useful history, not proof of behavior on current iOS releases. Reports of repeated prompts in [WebKit's PWA camera issue](https://bugs.webkit.org/show_bug.cgi?id=280394) concern `getUserMedia` camera access, not orientation. The older [WKWebView issue](https://bugs.webkit.org/show_bug.cgi?id=213468) is a native-app web view, not Safari or an installed Home Screen web app. Those reports do not verify that motion permission resets on every PWA launch. **Finding:** the reported lack of persistence is plausible enough to design around, but it is not verified for `DeviceOrientationEvent` across iOS 17–27. Safari's API gives the page a grant/deny result rather than a reliable cross-version persistence query. Keep a clear tap-to-enable control available after each launch; if the browser retained access, the call can resolve without a new prompt. If it did not, the user can grant again. A refusal or error must leave drag and pointer input working. There is also a [WebKit iOS 26 iframe report](https://bugs.webkit.org/show_bug.cgi?id=301294) where an accepted motion prompt did not result in events inside a cross-origin frame. It was later marked as a duplicate after a fix landed in WebKit, but the tracker does not establish which shipped OS release contains it. Keep the reflective surface in the app's top-level document instead of introducing an iframe boundary. ### Android, desktop, and fallback Android browsers have generally delivered device orientation without a Safari-style prompt. That assumption is changing in Chromium: its [June 2026 Intent to Ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/ckd2rFmT3PA) targets milestone 151 for desktop and Android. The initial rollout keeps the existing default permission as `ALLOW`, while the proposal says the longer-term plan may move it to `ASK`. In this worktree, headless Chromium 153 exposed `DeviceOrientationEvent.requestPermission` as a function. **Feature-detect the method and handle its result; do not branch on Android user-agent strings or assume that a method's presence means a prompt will appear.** | Input | Recommended behavior | | --- | --- | | Desktop mouse/trackpad | Map pointer position inside the card to a clamped highlight target. Return gently toward a composed rest angle on pointer leave. | | Touch | Allow a one-finger drag over the card as the fallback. Use pointer capture after drag begins so the gesture can finish outside the card. The demo uses `touch-action: none` on the isolated card; product code must preserve the canvas's existing scroll and gesture contract. | | Phone orientation | Ask only after the user taps **Enable tilt**. Read relative `beta`/`gamma`, calibrate against the first event, clamp the range, and remap axes if screen orientation changes because sensor coordinates remain device-relative. If permission is denied, the device has no usable sensor, or no events arrive, keep touch drag available. [W3C coordinate model](https://www.w3.org/TR/orientation-event/#deviceorientation). | | Keyboard and assistive technology | Expose the enable control as a real button with a pressed state. The reflective motion is decorative; it must not carry host information or be required to share the card. | ### Spring and lifecycle The local animation standards recommend a spring for decorative mouse tracking because it preserves velocity when the user reverses direction. Reuse the package's shared spring if available; do not add a one-off spring helper. The demo uses mass 1, stiffness 150, damping 25, which is close to critical damping and gives a responsive settle without visible bounce. Those numbers are a behavior example, not a locked product contract. An input event should update a target and schedule at most one `requestAnimationFrame`. The frame callback advances the spring and writes `transform` on the highlight element. When position and velocity are within a small threshold, stop scheduling frames. Use `visibilitychange` to cancel an in-flight frame and detach orientation listening while hidden; close does the same. On return, refresh card bounds and reattach only if the user enabled tilt. Browsers usually pause animation frames in hidden tabs, but explicit cleanup also stops sensor work and makes the component lifecycle clear. [Chrome animation guidance](https://web.dev/articles/animations-and-performance), [Page Visibility API](https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API), [W3C visibility requirements for sensor events](https://www.w3.org/TR/orientation-event/#deviceorientation). While a visible card has tilt enabled, retain the minimal orientation listener so a new physical tilt can wake the effect. Do not run a polling loop. Ignore unchanged or sub-deadzone samples, and do no paint work when the target has not changed. Apple describes `DeviceOrientationEvent` as firing while the user changes device orientation. [Apple DeviceOrientationEvent reference](https://developer.apple.com/documentation/webkitjs/deviceorientationevent). ## 3. Performance evidence The final demo was measured in Chromium **153.0.8010.12**, headless, with DevTools CPU throttling at **4×**, a **393×852 CSS viewport** and **DPR 3**. Chrome describes CPU throttling as a relative slowdown applied to the host and recommends calibrated presets when approximating a target device. This 4× run is a relative stress factor, not a mobile CPU proxy; desktop throttling cannot reproduce mobile CPU architecture. [Chrome CPU throttling guidance](https://developer.chrome.com/docs/devtools/performance/reference/#throttle-the-cpu-while-recording). The harness swept a pointer over the card for 3.2 seconds and sampled `requestAnimationFrame` timestamps. Two runs recorded 104 pointer updates each: | Run | Samples | Mean / p50 / p95 / p99 / max interval | Intervals over 33.3 ms | Host load | | --- | --- | --- | ---: | --- | | Initial run | 298 timestamps (297 intervals) | 19.18 / 16.7 / 33.4 / 66.6 / 249.9 ms | 23 | 1-minute load 9.88 after run | | Updated demo rerun | 194 timestamps (193 intervals) | 16.67 / 16.7 / 16.7 / 16.8 / 16.8 ms | 0 | 7.68 / 7.92 / 7.08 (1 / 5 / 15-minute load before run) | Both runs used the same spring and frame-update path. The source changes between them added screen-axis remapping and restored pointer-leave recentering; the host load also changed, so the interval difference does not isolate a code effect. The spring returned to rest in about **1,069 ms**. In the updated run, after the `data-moving` state cleared, it produced **0 spring callbacks during the next 1 second**; closing the card produced **0 more callbacks during 750 ms**. The behavior check confirmed a simulated 90° screen rotation moved a beta tilt into the horizontal axis (`translate` x **8.55 px**, y **−0.01 px**) and mouse leave returned the overlay to within **0.01 px** of rest. A separate check confirmed theme switching, zero callbacks after close, and zero animation callbacks with reduced motion enabled. These were **loaded desktop stress observations**, not an iPhone benchmark: the host has 8 CPU cores (Intel Core i9-9900K), and concurrent Rust/C compilation and infraternal processes were visible during the initial run. The median was one 60 Hz interval in both runs; the initial run's p95 and long-tail intervals exceeded one 60 Hz interval. These are sampled `requestAnimationFrame` timestamp intervals, not rendered-frame latency, and no reflective-card frame budget has been established. The runs confirm that the demo becomes idle after settling; they do **not** prove a 60 fps iPhone result. Rerun the surface on an idle pinned perf machine and a physical iPhone before setting a product budget or approving the visual layer. ## 4. PNG and text export CSS in the DOM does not appear automatically in a separately painted `CanvasRenderingContext2D`. If the image exporter draws the card on canvas, it must also draw the same gradient layers, blend treatment, and border itself; otherwise the exported PNG will omit the live reflection. A canvas can render radial gradients and export PNG data through `toBlob`. [Canvas radial gradients](https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/createRadialGradient), [`HTMLCanvasElement.toBlob`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toBlob). Freeze a deliberate, attractive reflection pose for export—such as a soft upper-left sheen—and render it into the PNG. Do not let a transient pointer or device angle determine the shared file. D126 also allows a text share; text output has no visual reflection. For image sharing, test `navigator.canShare({ files })` and call `navigator.share()` from the share-button activation. [Web Share API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Share_API), [file share support](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/share). ## 5. Accessibility and contrast - Under `prefers-reduced-motion: reduce`, use a static highlight pose, do not request or listen to motion sensors, and do not start a spring. [MDN reduced motion](https://developer.mozilla.org/en-US/docs/Web/CSS/%40media/prefers-reduced-motion). - No flashing, pulsing, or automatic shimmer. The only movement follows explicit pointer, drag, or tilt input. - Keep the card's text on a stable tinted/scrim layer above the highlight. Check contrast at the brightest and darkest highlight positions in both ink and paper themes. Normal text needs at least **4.5:1** and large text at least **3:1** under WCAG AA. [WCAG 1.4.3](https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html). - Preserve the existing accessible share-card labels and make the tilt control keyboard operable. Do not require tilt to read or export the Machine facts. ## 6. Reuse under D160 Make this a reusable `ReflectiveSurface` primitive in `packages/ui`, with the share-card content supplied by a slot/children. Suggested per-instance API: ```text intensity: 0..1 highlightColor: theme token or CSS color inputSource: auto | pointer | orientation | static active: card-open and visible state reducedMotion: resolved user preference ``` The primitive should own the one sheen overlay, its input-to-target mapping, spring lifecycle, and cleanup. Reuse the shared spring and shared button/control patterns; let the share card provide the label for its tilt affordance. Do not copy a surface, button, or spring per card. Keep one active overlay per visible surface and zero scheduled animation frames at rest. The current worktree does not yet contain a `packages/ui` directory, so this report specifies the destination without creating or changing product code. ## 7. Suggested implementation plan and owner questions 1. **Owner UX decision:** use a visible **Enable tilt** tap inside the share card; do not show an iOS permission prompt just because the card opened. This is the recommended choice for an optional decorative effect. Keep drag available for users who decline or cannot use motion. If a later session needs permission again, the user taps again. 2. **Surface contract:** confirm `intensity`, `highlightColor`, `inputSource`, and `active` as per-instance properties. Keep the component content-agnostic and put it in `packages/ui` when that package is available. 3. **Build the CSS version first:** static layers, one transformed highlight, shared spring, card-relative pointer mapping, opt-in relative orientation, touch drag, and complete close/hidden/reduced-motion cleanup. No camera, no WebGL context, no animated SVG filter. 4. **Implement export separately from live input:** render a frozen default reflection into the PNG. Keep text sharing separate and continue hiding IPs by default per D126. 5. **Review real production screenshots** in ink and paper themes at phone and desktop sizes. Check the resting angle and extreme highlight positions for text contrast, and verify that the mobile drag does not break the canvas's existing gestures. 6. **Test platform permission behavior on real devices:** compare Safari and installed Home Screen web app on supported iOS 17/18/26/27 devices where available; test first grant, deny, relaunch, background/foreground, and rotation. Test current Chrome Android and a non-Chromium Android browser. The current public evidence does not settle cross-launch motion permission persistence. 7. **Measure before approval:** capture a clean 4× Chromium performance trace and a real iPhone Safari trace, including spring p95/p99, idle callbacks, card-close cleanup, and visible/hidden sensor work. A GPU or filter-heavy alternative needs a measured visual/performance reason to replace CSS. Open owner questions: - Approve tap-to-enable tilt rather than prompting on first open? **Recommended: tap-to-enable.** - Should a prior in-app preference resume orientation automatically when a card reopens, or should each new launch show **Enable tilt** until tapped? **Recommended: do not issue permission requests without a tap; keep an explicit control when the browser's persisted grant is uncertain.** - Approve a fixed, attractive PNG reflection angle independent of the user's live tilt? **Recommended: yes, for consistent exports.** - Is the CSS approximation visually close enough, or does the owner want a separate measured SVG/WebGL spike for visible refraction? **Recommended: review CSS screenshots first, then request a spike only if the visual gap matters.**

kayg commented 2026-10-07 10:28:39 +00:00

Author

Owner

Copy link

Finished research-only work. HEAD: 9d6903f85f; worktree clean. Commits: e6c9fed (demo), a7c03e7 (report), 71b1133 (screen-axis and fallback fixes), 9d6903f (benchmark caveats and updated measurements). The corrected full report is posted above and committed at research/reflective-card/REPORT.md; demo: research/reflective-card/demo.html. Updated 4x Chromium run: 194 timestamps / 193 intervals, p50 16.7 ms, p95 16.7 ms, p99/max 16.8 ms, zero intervals >33.3 ms, zero callbacks during 1s idle and 750ms after close. Independent review found no blocking issues. Gate command scripts/verify fast exited 127; output verbatim: zsh:1: no such file or directory: scripts/verify. scripts/verify is absent from this worktree.

Finished research-only work. HEAD: 9d6903f85fd91c5ecc909581b1dd7f19ab60f496; worktree clean. Commits: e6c9fed (demo), a7c03e7 (report), 71b1133 (screen-axis and fallback fixes), 9d6903f (benchmark caveats and updated measurements). The corrected full report is posted above and committed at research/reflective-card/REPORT.md; demo: research/reflective-card/demo.html. Updated 4x Chromium run: 194 timestamps / 193 intervals, p50 16.7 ms, p95 16.7 ms, p99/max 16.8 ms, zero intervals >33.3 ms, zero callbacks during 1s idle and 750ms after close. Independent review found no blocking issues. Gate command scripts/verify fast exited 127; output verbatim: zsh:1: no such file or directory: scripts/verify. scripts/verify is absent from this worktree.

kayg referenced this issue from a commit 2026-10-10 09:20:38 +00:00

research(reflective-card): keep the reflective share card research and demo on main (#76)

kayg referenced this issue from a commit 2026-10-10 09:20:59 +00:00

Research #76: add standalone reflective card behavior demo

kayg referenced this issue from a commit 2026-10-10 09:20:59 +00:00

Research #76: document reflective card implementation findings

kayg referenced this issue from a commit 2026-10-10 09:20:59 +00:00

Research #76: align demo tilt with screen orientation

kayg referenced this issue from a commit 2026-10-10 09:20:59 +00:00

Research #76: correct performance evidence and caveats

kayg referenced this issue 2026-10-28 17:53:56 +00:00

Orchestrator handover 2026-10-28: moving to a new machine #254

kayg referenced this issue 2026-10-28 18:00:45 +00:00

Orchestrator handover 2026-10-28: moving to a new machine #254

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

j470b-server-mesh-rejoin

mesh-compat-382

j444b-d381-key-wins-flood

j461b-macos-utun-reader-thread

j475b-remove-host-motion

fix-reconnect-new-link

j481-d380

dev

j479-mesh-soak

fix/j476-host-facts

j475-motion-pill-split

j470-mac-node-join

root-upgrade-d376

j474-review-merge

latency-targets-120hz

nightly-suite-shards

gotatun-pin-j469

macos-utun-reader-thread

fix-flood-echo-stall

wip/j416

motion-fast-ease-out

mesh-addhost-j259

takeover-close-terminals-d368

kbd-instant-followups

fix-trust-key-double-click

nightly-suite-partial-report

appwin-icons-j207

rusqlite-slice1

swipe-content-first-d374

mesh-mtu-381

addhost-instant-open

glass-contrast-d365-mock

glass-contrast-d365

signout-followups-442

fix-startup-toast-red

research-gotatun-matrix-j317

themes-sync-j304

fix-load-flakes

fix-nix-zig-patch

fix-compute01-browser-baseline

ratchet-size-baseline-419

predict-auto-d130

revoke-coverage-d367

nightly-suite-queue-timeout

nightly-browser-suite

fix-rustsec-2026-0459

fonts-ioskeley-obel

log-retention-d375

fix-kbd-no-anim-427

fix-dev-red-specs-2

takeover-proof-305-j205

wip/j410-server-pump

ui-consistency-d372

fix-osc52-clipboard

libghostty-vt-1.0

forget-retired-host-d369

j404-merge-426

fix-setup-lock-race

fix-touch-select-426

revoke-access-report-ui

fix-predictive-echo-specs

fix-selinux-agent-exec

wip/j395-checkpoint2

wip/j395

j391-review-scratch

ui-consistency-j195-deferred-rebased

fix-rustc-paths-421

decisions-wording-341

fix-install-suite-red

fix-dev-rtt-specs

fix-pending-removal-align

fix-privileged-skip

fix-install-suite-404

review-j368

mesh-dns-j254

revoke-access-report-d356b

revoke-privilege-round5

fix-removal-confirm

review-j360

gotatun-rotation-367

deps-refresh-340

review-j354

review-J351

review-j350

addhost-takeover-d359

revoke-report-items-347

revoke-end-sessions-d362

review-j348

size-mesh-ssh-346

size-trim-337

revoke-access-diff-d356

j259-pre-rebase-b06c5a6

j305-ended-at-start-spec

addhost-sudo-consent

fix-layout-real-specs-411

fix-shell-open-411

fix-console-hosts-373

fix-shell-exit

fuzz-host-name-353

fix-host-details-410

macos-filter-j197

research-gotatun-tricks

revoke-p3-j216l

stale-state-pill

revoke-followups-j216k

revoke-progress-j216e

backup/macos01-20261106/lume/j197

backup/macos01-20261106/lume/appwin-icons-j207-stash0

backup/macos01-20261106/claude/stash-0

backup/macos01-20261106/claude/stash-1

backup/macos01-20261106/claude/J80-macos-s1

backup/macos01-20261106/claude/J80

backup/macos01-20261106/claude/J80-slice1-20261102

backup/macos01-20261106/claude/J16b-appwin-on-dev

backup/macos01-20261106/claude/appwin-launch-idle-146

backup/macos01-20261106/claude/J80-s1-run

wip/j259

trust-285-p3c

runtime-lock-j216f

mesh-ssh-p3-j175

tun-proof-p3b

trust-285-p3

terminal-polish-j271

tun-proof-p3

ssh-install-flakes-j216i

fuzz-fixes-j264

trust-285-a

trust-285-b

restart-oversized-fixture-j198

backup/macos01-20261106/lume/appwin-icons-j207

restart-bound-j216h

up-preflight-p3-j198

backup/macos01-20261106/lume/j251

up-preflight-j198

wip/up-preflight-j198-j245-p2

wip/up-preflight-j198-j245-p1

agent-fsync-offloop-j196

wip/up-preflight-j198-j245

settings-offscreen-j231

wip/up-preflight-j198-j226-inspection

wip/j103f

themes-j206

wip/up-preflight-j198-j226

flakes-j216c

backup/macos01-20261106/claude/j197

flakes-j216b

backup/macos01-20261106/claude/j197-red

wip/up-preflight-j198-review

flakes-j216

backup/macos01-20261106/claude/appwin-icons-j207

engineering-j208b

appwin-mock-j209

toast-stack-j165

engineering-j208

decisions-d351

decisions-d350

decisions-d349

appearance-presets-mock-j129

decisions-d348

docs-audit-spec

doc-coverage-baseline-raise

decisions-d347

decisions-d346b

decisions-d346

j88h-profile

ui-consistency-j195-deferred

ui-consistency-j195

engineering-practices-j194

preferred-login-ui-j166

signin-pools-263-j174

macos-node-265-s1

decisions-d345

decisions-d344

proxy-cgroup-j164

verify-quick-fuzz-329

proxy-start-io-j168

timing-flakes-j163

up-263-s1

mcp-events-j147

verify-quick-fuzz-j158

proxy-p3-j159

agent-resource-j157-detect

wip/j103d-final

remote-cancel-hang-j155

proxy-traefik-281-j62d

j149-verify-quick

proxy-traefik-281-j62b

j150-drop-unnamed

wip/j79d-red-r4

wip/j103d-d332

rootless-toast-j142

wip/j103d-head

wip/j103d

j125c-mcp

macos-build-j136

backup/macos01-20261106/claude/j136

wip/j79d-red-cli

wip/j79d-red-server

j121-link-liveness

j118c-tracer-failures

wip/j79c-head

release-desktop-j131

j124c-signed-macos

wip/j79c-red-p3

wip/j79c-red-p23

wip/j79c-red-p22

merge-j128-check

perf-deferred-j128

sidebar-toggle-260

j127-shortcut-changed-dot

j125-mcp

j118-tracer-failures

j126-account-summary

settings-sections-mock-j92

j120-pinch-lock

sidebar-292

backup/macos01-20261106/claude/j120

taste-2026-11-03

row-actions-242-215

backup/macos01-20261106/claude/stash-0-untracked

backup/macos01-20261106/claude/J80-265-s1-run

backup/macos01-20261106/claude/J80-macos-s1-20261102

j112-canvas-commands

ui-no-overshoot-scroll

fix-recovery-restart

backup/macos01-20261106/claude/stash-1-untracked

taste-2026-11-02

size-baseline-ratchet

machine-cards-structure-j108

j109-boot-copy-mockups

fix-dev-red

wip/up-263-s1

j95b-settings-rows

proxy-traefik-281

j95-option-rows

docs-human-j91

docs-keys-palette

fix-flood-1013-270-j38d

mesh-ssh-s1

mesh-ssh-s0

addhost-d291-tunnel

test-stability-load

mesh-relay-220

repro-296

shim-thp-off-24

mesh-pins-258-v2

mesh-dns

signin-d311-merged

docs-pages

ui-size-283

fix-ui-batch-specs

wip/j12b-edge-update

gate-on-arm

fix-rename-sync-293

trust-285-j60b

fix-focus-ring-clip

integ-ui-1101

edge-update-v2

signin-d311

taste-2026-11-01

layout-per-tab-250

ui-approved-splitopt-224

ui-approved-splitopt-224-on-dev

icon-text-centre-282

ui-approved-189-212-216

research-reverse-proxy

transfer-budget-320

review-mesh-pins-258-r2

sidebar-pill-259

review-mesh-relay-220

wip/j12-edge-update-v2

nix-package

status-crash-loop-237

fix-dev-test-failures

fix-fixture-socket-path

wip/mesh-relay-220-pre-dev-advance-rebase

fix-canvas-side-clip

research-head-to-head

frosted-real-256

review-mesh-pins-258

wip/mesh-relay-220-pre-final-rebase

review-layout-per-tab-250-r2

broad-suite-triage

nix-devshell

review-status-crash-loop-237-r3

wip/nix-devshell-pre-p3

taste-frosted-real

wip/code-serve-demo-2026-10-30

wip/code-serve-glass-2026-10-30

wip/code-serve-clusters-2026-10-30

wip/code-merge-release94-dev-2026-10-30

wip/rproxy-delta-scratch-2026-10-30

wip/stale-note-257-staged-2026-10-30

wip/d241-size-staged-2026-10-30

review-broad-suite-207

wip/mesh-pins-258-pre-split

wip/mesh-relay-220-pre-rebase

mesh-measure-220

plan-211-update

review-edge-autoupdate-r3

perf24-reconnect

review-stale-note-r2

release-prod-live

d241-shell-marker

review-mesh-pins-server-258

review-revocation-r3

review-setup-token-r2

review-sync-journal-r3

wip/review-mesh-pins-258-prune-review-1995fee46

frosted-scroll-256

sync-journal-r3

revocation-per-account-wip

review-tokio-asyncfd-0386

review-sync-p3s

wip/stash-8by64-stash0-2026-10-30

mesh-drag-r2

setup-token-data-wip

release-9-4

auth-busy-1013

mesh-view-overlap

sync-p3s

review-auth-busy-wake

review-readd-r8-wip

mesh-drag-bounds

audit-auth-93

app-windows-stream-start

review-authority-cap-r3

app-windows-r7-measure

readd-minimal-r6

readd-minimal-r5

app-windows-r7-soak

readd-minimal-r4

app-windows-r7

app-windows-r6

readd-minimal-r3

readd-minimal-r2

readd-minimal

merge-release8-dev

review-busy-page-liveness-r2

review-busy-page-liveness

mesh-view-trim

review-authority-read-retry-r2

review-remove-uninstall-r2

release-retry-reattach

release-retry

review-remove-uninstall

review-authority-read-retry

app-windows-ship

mesh-autoswitch-p2

mesh-ssh

mesh-relay

mesh-macos-node

screen-and-control

session-labels

review-real-logins-r5

review-real-logins-r4

review-real-logins-r3

shim-memory-r2

review-real-logins-r2

shim-memory

shadow-addhost-instant

shadow-real-logins

shadow-same-session-flood

shadow-prod-perf-fix

hosts-from-server

app-windows-real

app-windows-transport

release-prod-6w

mesh-policy-verify

quiet-close-toast

dev-merge-r4

review-mesh-agent-transport

review-app-windows-transport

settings-roundtrip

review-release-pipeline-r4

mesh-agent-transport

ended-strip-fix

review-audit-ca-update-d244

settings-rows

phone-width

signout-clear

fix-restart-tests

dev-merge-rp

signer-hardening

review-audit-ca-update

terminal-fidelity

review-audit-ca-update-wip

mesh-integrate

review-mesh-agent-transport-515d3712

review-mesh-dataplane-feec1988

mesh-dataplane

signout

research-canvas-node

wip/review-renderer-cost

wip/review-terminal-fidelity

padlock-glyph

review-release-pipeline-2e95b689

phone-polish

sidebar-polish

inbox-generic

review-mesh-dataplane-378d4055

prod-batch

ui-inbox

ui-ca-unlock

ui-machine-sections

review-mesh-dataplane-a5f744fb

tls-session-prod

session-bounds-prod

fix-dead-session

session-bounds

tls-session

palette-polish

shortcuts-d222

research-appmeta

phone-gutter

ui-centre-button

wip/ui-centre-button

wip/tls-session

review-addhost-breakit

ui-platform

renderer-cost

remote-agents

mesh-api

ssh-bootstrap

prod-hotfix2

prod-fixes

review-remote-agents

review-mesh-dataplane

session-life

research-browser

review-mesh-api

research-capture

review-mesh-api-round3

review-mesh-api-round1

gate-stability

review-gate-stability

review-relay-direct

review-mesh-api-findings

proto-sessions

font-picker

proto-addhost

proto-windows

mesh-core

latency-gate

research-bsd

research-discovery

keytray-mods

mock-core

ui-tweaks

fix-motion-sel

fix-motion

integrate2

fix-robust

t-web

t-server

vt-ghostty

fix-snap-echo

t-web-auth

review-vt2

t-agent

lane-protocol

lane-shim

lane-auth

s1-base

s1-contracts

s1-workspace

No results found.

Labels

Clear labels   

launch-qa

Findings from launch QA.

No labels

launch-qa

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

kayg/infraternal#76

No description provided.