Starlight graph, SW cache, Playwright triage, ESLint guardrail

What this covers

Five technical threads in one day. I added Canvas starlight nodes to a document relation graph on this blog, and in another codebase I fully reviewed Playwright CI logs to separate flaky from deterministic failed. In the same vein I built a Service Worker image cache (stale-while-revalidate + byte-LRU) and blocked original re-exposure after masking and logout with a generation guard. On the design-system side, MCP alone was not enough, so I added an ESLint guardrail plugin.

Each task is grouped in the order background → the situation → core work → lesson.

Day summary

1. Canvas starlight nodes

Background (concepts)

• Canvas 2D: Browser API that paints directly into a pixel buffer. Not DOM, so CSS animation cannot attach to individual nodes.
• force-directed graph: Graph visualization that positions nodes with attraction and repulsion. Usually drawn on Canvas.
• prefers-reduced-motion: OS/browser "reduce animation" setting.

What the situation was

• Local relation graph nodes on knowledge and TIL detail pages looked like orange dots, mismatched with a night-sky visual tone.
• Panel background stars twinkled via CSS, but document nodes live inside Canvas and could not use the same approach.

Core work

• Stable color (warm white, white, cool white), twinkle period, and phase from document ID hash.
• Apply globalAlpha and shadowBlur in draw callback, then restore state.
• autoPauseRedraw={reducedMotion} to stop twinkle when motion is reduced.
• Neutral legend colors — node color does not encode document type.

Lesson

• Canvas drawing state persists into the next frame — always reset alpha and shadow.
• Attach visual meta once; each frame updates only time-based alpha.

→ Canvas deterministic node rendering

2. Playwright flaky vs failed

Background (concepts)

• flaky: First run fails → retry succeeds.
• deterministic failed: All retries fail for the same reason.
• CDP: Diagnostic protocol that reads browser exception URL and line number.

What the situation was

• E2E CI looked unstable; needed to tell whether a spec was flaky or broken every time.

Core work

• Full analysis of months of push workflow logs → 36 flaky cases across 8 tests.
• 100% identical SyntaxError traced to custom webpack splitChunks putting CSS into JS entry — a build defect.
• SSE timers, Radix portal focus, networkidle, and loose waitForRequest were top flaky causes.

Lesson

• Do not judge flaky from CI conclusion alone — read retry results.
• Reproduce deterministic failed with production build + CDP.

→ Playwright flaky vs failed triage · Webpack splitChunks trap

3. Service Worker stale-while-revalidate

Background (concepts)

• Service Worker: Browser script that intercepts fetch and stores responses in Cache Storage.
• stale-while-revalidate: Return cache immediately + refresh in background.
• presigned URL: Temporary download URL with expiry signature.

What the situation was

• Cloud storage images required network wait on every reopen.

Core work

• Return immediately on cache hit; await only on miss.
• Strip auth queries from cache key only; keep semantic queries such as masked=1.
• 100MB byte-LRU (body + access metadata).

Lesson

• Presigned cache is not "remove entire query" but "strip signature only".
• Byte LRU moves body and metadata together.

→ Service Worker stale-while-revalidate · Presigned URL cache key normalization

4. Masking and logout cache security

Background (concepts)

• SWR is a performance pattern, but right after masking original re-exposure is a security problem.
• race condition: In-flight fetch during deletion can store the original again.
• generation: Generation number incremented on each delete to judge store eligibility.

What the situation was

• After masking API success, browser cache could briefly show the original.

Core work

• Masking success → wait for cache delete ACK → update UI data.
• Generation guard blocks put from revalidate started before deletion.
• Both logout paths clear entire image cache.

Lesson

• For sensitive data, "delete" and "cancel in-flight store" are separate concerns.
• At security boundaries, ACK comes before UI update.

→ Cache generation stale-write guard

5. Design system ESLint guardrail

Background (concepts)

• ESLint plugin: Static analysis that reports code pattern violations.
• MCP: Standard for AI agents to access external docs and tools — provides DS docs as push.
• Guardrails complement MCP (push) and ESLint (catch).

What the situation was

• AI and developers rebuilt native <button> and local Modal, bypassing the design system.
• Hardcoded hex and spacing were allowed; only "not using DS" should be caught.

Core work

• Two rules: prefer-ds-component, no-reimplement.
• Messages include import paths and MCP tool hints (agent-cognizable).
• Workspace and per-package CI publish setup.
• Plugin applies to consumer repos only — not DS source itself.

Lesson

• DS guardrails are more practical as "no component bypass" than "forbid values".
• When adding a publishable package, verify lockfile and CI publish job together.

Derived knowledge

• Canvas deterministic node rendering
• Playwright flaky vs failed triage
• Service Worker stale-while-revalidate
• Cache generation stale-write guard
• Presigned URL cache key normalization