Harden traffic history worker lifecycle and query performance
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: design-harbor-device-ecosystem
|
||||
description: Design, plan, implement, review, or document Harbor Gateway integrations with current and future companion devices. Use for LAN advertisement and discovery, Connect-Gateway pairing, trusted device identity, connected-client presence, ecosystem membership in the Gateway device list, multi-Gateway selection, capability or protocol negotiation, and related API, persistence, migration, or UI contracts. Do not use for traffic-only LAN inventory or visual polish that does not change ecosystem behavior.
|
||||
description: "Use when changing or reviewing Harbor companion-device discovery, pairing, trust, presence, routing handoff, or their API and persistence contracts. Not for traffic-only inventory or visual polish."
|
||||
---
|
||||
|
||||
# Design Harbor Device Ecosystem
|
||||
@@ -18,7 +18,7 @@ Keep discovery, trust, application presence, routing, and LAN observation separa
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Read `PRODUCT.md`, `workpack/PRODUCT_PRIORITIES.md`, `workpack/DATA_CONSISTENCY_MODEL.md`, `workpack/DESIGN_OWNER_POLICY.md`, `workpack/STATUS.md`, and the selected workpack task.
|
||||
1. Start with the selected workpack task when one exists. Read `PRODUCT.md` and `workpack/PRODUCT_PRIORITIES.md` for product scope, `workpack/DATA_CONSISTENCY_MODEL.md` for persistence or projection changes, and `workpack/STATUS.md` for active roadmap/cutover work. Any visible UI decision requires `workpack/DESIGN_OWNER_POLICY.md`; reuse an exact owner decision already recorded for this scope.
|
||||
2. Read [device-ecosystem-contract.md](references/device-ecosystem-contract.md) before changing discovery, pairing, identity, presence, routing handoff, or the Gateway device projection.
|
||||
3. Trace the current producer -> transport -> persistence -> canonical snapshot -> UI path. Confirm the owning service and every caller before editing.
|
||||
4. Classify each proposed field and state as one of: discovery candidate, persisted trust relationship, authenticated presence lease, route state, network observation, or derived binding. Reject fields that mix categories.
|
||||
@@ -44,7 +44,7 @@ Keep discovery, trust, application presence, routing, and LAN observation separa
|
||||
|
||||
## Acceptance pass
|
||||
|
||||
Before handing off an ecosystem change, verify:
|
||||
Verify the affected contracts below. Protocol, authentication, shared projection, or migration changes require coverage across the impacted lifecycle; a documentation-only correction uses consistency/link checks. Do not operate live devices without the exact authorization described above:
|
||||
|
||||
- A supported client can discover more than one Gateway and survives address changes without changing Gateway identity.
|
||||
- Spoofed discovery cannot create trust, change the active route, or appear as a paired ecosystem member.
|
||||
|
||||
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user