Harden traffic history worker lifecycle and query performance

.codex/skills/design-vpn-client-ui/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: design-vpn-client-ui
-description: Design, implement, review, or refine the client-facing VPN interfaces in this repository using the established calm monospace visual language and smooth state-driven motion. Use for the current macOS client and future end-user gateway client screens, especially power controls, subscriptions, traffic usage, proxy copy controls, server selection, responsive layout, hover feedback, transitions, and animation polish. Do not use for the administrative gateway UI unless the user explicitly asks to apply the client visual language there.
+description: "Use when changing or reviewing Harbor Connect and Gateway client UI. Apply the established visual and motion language; not for administrative Gateway UI unless explicitly requested."
 ---
 
 # Design VPN Client UI
@@ -9,23 +9,20 @@ Preserve the repo's focused one-screen VPN client language: a centered primary a
 
 ## Workflow
 
-1. Read `PRODUCT.md` and the complete client component and styles before editing.
+1. Inspect the affected client component, state owner, relevant styles, and nearest analogue. Read `PRODUCT.md` when product behavior or mode semantics change; expand context when shared invariants require it.
 2. Inspect supplied evidence and trace the real DOM and state change that causes the visual issue. Follow repository testing policy; do not launch manual or interactive visual testing unless the user explicitly requests it in the current prompt.
 3. Read [visual-language.md](references/visual-language.md) for layout, hierarchy, color, and typography work.
 4. Read [motion-and-interaction.md](references/motion-and-interaction.md) for animation, hover, refresh, input, copy, or state-transition work.
 5. Reuse existing React state, CSS variables, formatters, and API paths. Prefer a narrow CSS/markup change over a new abstraction or dependency.
 6. Keep geometry stable across every state. Reserve space before animating content.
 7. Implement `prefers-reduced-motion` alongside every new animation.
-8. Run `npm test`, `npm run build`, and `git diff --check`. Perform manual visual inspection only when explicitly requested.
+8. Run focused automated checks for affected behavior and `npm run build` for client code changes; use the full `npm test` suite when shared behavior changes or narrower evidence is insufficient. Documentation-only work uses structural/link checks and `git diff --check`. Manual visual inspection requires an explicit request in the current prompt.
 
 ## Communicating a proposed change
 
-For implementation proposals and progress summaries, combine structure instead of maximizing it:
-
-- start with one compact table grouped by affected modules such as frontend, UI, backend/API, styles, tests, and versions;
-- use short lists only for cross-cutting details such as states, accessibility, motion, or changed files;
-- keep unaffected modules visible in the table when that clarifies scope;
-- avoid both an unstructured paragraph and a separate table for every subsection.
+For a local correction, report the result and focused evidence briefly. For a change spanning
+several owners or state lifecycles, use one compact table of affected modules plus the
+relevant states, accessibility, and motion decisions. Omit empty sections and unrelated modules.
 
 ## Non-negotiable decisions
 
@@ -49,7 +46,7 @@ For implementation proposals and progress summaries, combine structure instead o
 
 ## Acceptance pass
 
-Before handing off, verify:
+Check the affected behaviors below using automated evidence where possible. Shared layout or motion changes require broader coverage; a local correction does not require exercising unrelated controls. Manual inspection remains limited to an explicit request in the current prompt:
 
 - Power on/off is unmistakable without reading the label.
 - Switching on/off preserves the exact positions of title, timer, and hint.