# Visual language

## Character

Design for a Windows user opening a small control surface to check routing, recover a service, or apply one deliberate configuration change. The UI should feel soft, precise, dependable, and slightly terminal-like, not like a network administration dashboard.

## Composition

- Make current system state and the next safe action dominant.
- Keep the summary power control visually centered and pair it with a compact vertical route chain.
- Use open space, typography, subtle surface shifts, localized light, and state color before frames or dividers.
- Keep service rows compact: status, human-readable detail, one primary action, then secondary actions.
- Preserve the existing tabs and operational grouping; visual consistency does not justify moving ownership or hiding actions.

## Typography and geometry

- Use JetBrains Mono with uppercase tracked micro-labels only for metadata.
- Use weight and color before large size jumps. Use tabular numerals for changing values.
- Reserve equal space for mutually exclusive labels and feedback.
- Use 8px controls, 10px surfaces, and pills only for status tokens.
- Keep icon-only hit areas at least 40px and align icons in flex/grid rather than guessed offsets.

## Color and light

- Base dark surfaces on green-tinted OKLCH neutrals around hue 145.
- Use blue-green `oklch(0.68 0.11 185)` as the primary active/focus accent.
- Use orange `oklch(0.71 0.12 72)` for direct/local-route distinction, never as general decoration.
- Keep warning/error colors semantic. Do not recolor destructive actions with the route accent.
- Prefer localized `drop-shadow`, text glow, or a soft radial light layer over filled accent containers.
- Keep inactive power neutral even on hover; color communicates state, not clickability alone.

## Surfaces and controls

- Use quiet translucent cloud surfaces for tooltips and transient overlays.
- Inputs are inset and slightly darker than surrounding surfaces.
- Avoid nested cards. Group related controls with spacing and one subtle surface shift.
- Keep persistent work surfaces borderless by default. Use a border only when it communicates input focus, destructive confirmation, or another essential state.
- Render statuses and counters as a glowing dot or quiet value plus text, not as bordered badge capsules.
- Let service rows, route nodes, app rows, and server rows float on the shared canvas; reveal their surface only on hover, focus, selection, or active work.
- Prefer a short luminous underline or localized glow for selection and keyboard focus over a rectangular focus frame.
- Use shared `src/ui` primitives and preserve their default, hover, active, focus, disabled, loading, empty, and error states.

## Emphasis and border budget

- Give each compact surface one dominant accent at most. A transient warning action must not outshine the primary system state or its trigger.
- Do not stack borders on the container, trigger, and action. Start with tonal background, spacing, and text hierarchy; keep persistent outlines for keyboard focus, destructive confirmation, or an otherwise ambiguous hit target.
- Treat warm warning color as a restrained semantic tint, not decorative fill or a large glow. Adapt a shared `primary` button locally when its default emphasis conflicts with the surrounding prompt.
- Validate the complete component, not isolated controls: resting, hover, focus, active, disabled, loading, open, and closed states must share one radius and emphasis language.

## Route checks

- Keep the route description, endpoint, and check action in a stable three-part row. Reserve the action width so mode changes and endpoint length never move the button.
- Present the endpoint as the named route target, not as a detached badge or a second result.
- Reveal a borderless result surface only while a check is running or after it completes. Show every returned probe in a structured table with separate status, external IP, and latency columns; do not compress unlike values into mixed badges or hardcode a fixed probe count.
- Keep the summary short. Put verbose URLs, request methods, status codes, and errors in a calm structured detail cloud opened by hovering or focusing the result surface.
- Animate result arrival and status light, while preserving the same geometry and honoring reduced motion.

## Route chain semantics

- Show only stages with distinct user-facing responsibilities. Never render both `Выход` and `SOCKS5 endpoint` when they describe the same destination.
- Use `Приложения → ProxiFyre → SOCKS5` for the external-proxy route. End a direct route with `Интернет: напрямую` instead of an implementation-stage label.
- Explain each stage in plain Russian for a non-technical user. Omit filesystem paths, ports, service names, and generated-config details unless the user explicitly asks for diagnostics.
- Reserve the final chain height before revealing nodes. Progressive arrival may change opacity, blur, or transform, but must not reflow neighboring content.
- Treat progressive arrival as a presentation sequence over reserved slots. Do not serialize independent backend probes just to match the animation; if the API returns one aggregate snapshot, show calm `checking` placeholders and replace them in place.
- Reveal the initial chain in a short, legible sequence and do not replay it for background polling or quiet status refreshes.

## Admin elevation prompt

- Render the prompt as a fixed bottom-right overlay that never changes shell height or shifts the workspace. Offset it above persistent bottom docks instead of covering them.
- Keep the collapsed trigger as a stationary 44px warm shield. Show a concise hint once per application session after admin status is known, then dismiss it automatically.
- On click, expand the surface leftward from the shield while the shield stays in the same screen position. Keep the full row height tied to the trigger.
- Reveal background, copy, and action from the same origin and timeline. Use a roughly 520-560ms slow-start opening and a visible 380-420ms reverse close; never delay the background until the end.
- Keep any light pass subtle, local, and optional. It must not replace the actual surface/content motion.
- Use the concise title `Нужны права администратора`, the reason `Для управления ProxiFyre и правилами Windows.`, and the action `Перезапустить`. Do not show paths or elevation internals.
- Keep the surface and action borderless by default. Use a muted warm tint; the action must remain quieter than the shield and main system state.
- Verify the Russian copy, `Открываю UAC`, hover, focus, repeated toggle, narrow width, and Windows text scaling without clipping or layout movement.

## Route modes and managed lists

- Present external and local proxy routes as two peer choices above the content they replace. Keep the chooser mounted while the mode body crossfades in from the selected direction.
- Reserve the same configuration-stage height for both routes and place it before route diagnostics, so mode-specific labels and controls remain aligned even when check results expand.
- Use the blue-green accent for the external route and the warm route accent for Local sing-box. A small status light and quiet surface shift are enough; do not add a long selection rule.
- A green service light means running, not merely installed. Installed-without-service, stopped, and missing states remain warning-colored.
- Hovering service and application rows reveals a neutral side marker and slight positional response. Do not place a green radial wash behind the entire row.
- Application grouping is display-only. Preserve saved order as the default, provide explicit Processes, EXE files, and Folders sections with counts, and keep alphabetical sorting as a separate option. Remount only the visible list surface so changes can fade into place.