feat(variables): Add external secrets tabs and reworked design of the variables tabs

.agents/skills/qovery-ui/SKILL.md

@@ -0,0 +1,143 @@
+---
+name: qovery-ui
+description: Design review and implementation guidance for the Qovery Console. Use for auditing UI components, refining spacing and color, selecting the right shared component, writing microcopy, and designing new surfaces from scratch.
+---
+
+# Qovery UI Skill
+
+Design review and implementation guidance for the Qovery Console. Read `.claude/design.md` first for orientation.
+
+---
+
+## Core Design Principles
+
+`.claude/design.md` is the source of truth — read it first. These are quick-reference reminders for agents running without that context.
+
+**Colors:** Tailwind tokens only, never hardcoded. Status colors are semantic, never decorative. Brand violet on actionable controls only.
+**Typography:** `text-sm` is the default. Two weights: 400 body, 500 anchors. Roboto Mono for tabular data. Max 3 sizes per surface.
+**Spacing:** 4px grid. Variety creates hierarchy. Cards for distinct actionable content only — never nested.
+**Components:** Shared component first, always. `<StatusChip>` for all system states. `<Button>` not `<ButtonPrimitive>`. `<Badge>` not `<Tag>`.
+**Copy:** Technical but human. Button copy 1–3 words. Modal titles name the action. Address the user as "you."
+**Motion:** Default is no motion. High-frequency actions never animate. Every animation needs a reason beyond aesthetics.
+**Accessibility:** No color-only state. Focus rings never suppressed. Interactive icon-only controls always have `aria-label`.
+
+---
+
+## Commands
+
+| Command                | When to use                                    |
+| ---------------------- | ---------------------------------------------- |
+| `/qovery-ui audit`     | Full design review of a component or page      |
+| `/qovery-ui polish`    | Targeted spacing, color, and rhythm refinement |
+| `/qovery-ui component` | Find the right component or scaffold a new one |
+| `/qovery-ui copy`      | Review or write microcopy                      |
+| `/qovery-ui motion`    | Audit or add animation                         |
+| `/qovery-ui craft`     | Design something new from scratch              |
+
+---
+
+## /audit
+
+**Load:** `references/colors.md`, `references/spacing-layout.md`, `references/anti-patterns.md`, `references/accessibility.md`
+
+Four-phase review. Label every finding:
+
+- `[blocking]` — ships broken, violates semantic rules, or breaks accessibility
+- `[important]` — degrades experience, likely to cause design review rejection
+- `[nit]` — minor inconsistency, low impact
+
+**Phase 1 — Token hygiene:** hardcoded values, legacy tokens, raw Tailwind palette classes used semantically.
+**Phase 2 — Semantic color:** status colors used decoratively, color-only state, brand as page wash.
+**Phase 3 — Spacing & density:** off-grid values, whitespace inflation, button height overrides.
+**Phase 4 — Accessibility:** missing `aria-label`, suppressed focus ring, color-only status.
+
+Output format — a single markdown table, one row per issue:
+
+| Location            | Severity      | Issue                                   | Fix                                           |
+| ------------------- | ------------- | --------------------------------------- | --------------------------------------------- |
+| `ServiceRow.tsx:42` | `[blocking]`  | `text-green-500` used for running state | Replace with `text-positive`                  |
+| `Modal.tsx:18`      | `[important]` | Modal title is "Settings"               | Rename to the action: "Configure autoscaling" |
+| `Card.tsx:9`        | `[nit]`       | `gap-5` off the 4px grid                | Use `gap-4` or `gap-6`                        |
+
+Finish with: total issues by severity.
+
+---
+
+## /polish
+
+**Load:** `references/spacing-layout.md`, `references/colors.md`, `references/typography.md`, `references/anti-patterns.md`
+
+Fix without changing functionality. Output a Before / After / Why table, one row per change:
+
+| Before                | After                             | Why                                      |
+| --------------------- | --------------------------------- | ---------------------------------------- |
+| `p-5`                 | `p-4`                             | Off the 4px grid                         |
+| `text-neutral-600`    | `text-neutral-subtle`             | Legacy token                             |
+| No hover state on row | `hover:bg-surface-neutral-subtle` | Interactive elements need hover feedback |
+
+---
+
+## /component
+
+**Load:** `references/components.md`
+
+1. Identify if a shared component already exists — always prefer it
+2. Return the import path and correct usage with props
+3. If nothing fits, explain why before scaffolding new
+
+---
+
+## /copy
+
+**Load:** `references/copy.md`
+
+Review or generate microcopy. Output findings as a Before / After / Why table:
+
+| Before              | After                                        | Why                                 |
+| ------------------- | -------------------------------------------- | ----------------------------------- |
+| "An error occurred" | "Deploy failed. Check the logs for details." | States what happened + what to do   |
+| "ENVIRONMENT NAME"  | "Environment name"                           | Sentence case                       |
+| "Confirm"           | "Delete environment"                         | Destructive buttons name the object |
+
+---
+
+## /motion
+
+**Load:** `references/motion.md`
+
+Ask first: how often will users see this? If the answer is "constantly," remove the animation. Otherwise, check easing and duration against the guide and output a Before / After / Why table.
+
+---
+
+## /craft
+
+**Load:** `references/typography.md`, `references/spacing-layout.md`, `references/colors.md`, `references/components.md`, `references/copy.md`
+
+Generative command — use when designing something new from scratch rather than reviewing existing work.
+
+**Input:** describe what you're building. Include the user goal, the data or content being shown, and any known constraints (compact, read-heavy, action-dense).
+
+**Output:** a structured design proposal with:
+
+1. **Layout skeleton** — which primitives to reach for (card, table, modal, inline), rough visual hierarchy
+2. **Component choices** — which shared components satisfy each UI need and why
+3. **Typography** — size and weight choices per content level
+4. **Color decisions** — which semantic tokens to use for each surface and state
+5. **Copy suggestions** — headings, labels, CTAs, empty state
+
+Output structured prose and a table for component choices. Do not output code. Flag any working memory concerns (>4 simultaneous choices) and suggest grouping or progressive disclosure where needed.
+
+---
+
+## Reference Files
+
+| File                           | Contents                                                                             |
+| ------------------------------ | ------------------------------------------------------------------------------------ |
+| `references/colors.md`         | Token system, semantic rules, contrast, tonal scale                                  |
+| `references/typography.md`     | Type scale, weights, Roboto Mono, typographic characters                             |
+| `references/spacing-layout.md` | 4px grid, visual rhythm, layout compositions, optical alignment, working memory rule |
+| `references/components.md`     | Which component to use when                                                          |
+| `references/copy.md`           | Tone, microcopy patterns, modal titles, button copy rules                            |
+| `references/motion.md`         | Animation decision framework, easing, duration guide                                 |
+| `references/anti-patterns.md`  | Match-and-refuse design bans                                                         |
+| `references/accessibility.md`  | Non-negotiables, ARIA, focus management                                              |

.agents/skills/qovery-ui/references/accessibility.md

@@ -0,0 +1,82 @@
+# Accessibility — Qovery Console
+
+## Non-Negotiables
+
+These are blocking issues in design review. Every component must pass them.
+
+1. **No color-only state.** Status, errors, and interactive states must combine color with an icon, text, or shape change.
+2. **Visible focus ring on every interactive element.** The design system provides this via `focus-visible:outline-2`. Never suppress it.
+3. **Icon-only controls have text alternatives.** The requirement depends on whether the element is interactive: **interactive controls** (buttons, links) always require `aria-label` — a tooltip alone is not sufficient because it doesn't provide an accessible name. **Non-interactive status icons** (decorative or informational): tooltip is sufficient as the text alternative.
+4. **Keyboard navigation works without a mouse.** All interactive elements are reachable and operable via keyboard.
+
+---
+
+## Color-Only State — The Rule and Its Fixes
+
+Users with color vision deficiencies can't distinguish red from green from gray. Every status signal must pair color with at least one other cue: an icon, a text label, or — when space is too tight for either — a tooltip.
+
+**When space allows:** prefer icon + color, or text + color. Both are fully sufficient.  
+**When space is constrained** (e.g., a status column in a dense table): icon + color + tooltip is acceptable. The tooltip becomes the text alternative and must be present on both hover and keyboard focus.
+
+| Pattern                                         | Fix                                                                                        |
+| ----------------------------------------------- | ------------------------------------------------------------------------------------------ |
+| Red text error below a field                    | Keep the text — it's sufficient on its own.                                                |
+| A colored dot indicating running / stopped      | Use `<StatusChip>` — it includes an icon SVG and has a built-in tooltip.                   |
+| A green badge for "healthy"                     | `<Badge color="green">Healthy</Badge>` — the text carries meaning, color reinforces it.    |
+| A yellow border on a form to indicate "warning" | Add a `<Callout>` or a text hint — the border alone is invisible to some users.            |
+| An icon-only status in a tight table cell       | Wrap in `<Tooltip>` with the status name as content — the tooltip is the accessible label. |
+
+```tsx
+// When you only have room for an icon, add a tooltip
+<Tooltip content="Deployment failed">
+  <Icon iconStyle="solid" iconName="circle-xmark" className="text-negative" />
+</Tooltip>
+```
+
+**StatusChip is the system's single source of truth for status.** It already bundles the icon, color, and tooltip — never create a custom colored indicator for deployment, build, or cluster state.
+
+---
+
+## Focus Management
+
+| Situation                     | How to handle                                                                                                 |
+| ----------------------------- | ------------------------------------------------------------------------------------------------------------- |
+| Button or interactive control | `ButtonPrimitive` provides `focus-visible:outline-2` automatically. Never override with `focus:outline-none`. |
+| Custom interactive element    | Add `focus-visible:outline-2 focus-visible:outline-brand-strong` via Tailwind directly.                       |
+| Modal or drawer               | `<Modal>` traps focus via Radix Dialog. Don't build custom modals — they'll miss this.                        |
+| Route change                  | TanStack Router handles scroll and focus reset. Don't suppress it.                                            |
+
+---
+
+## ARIA
+
+| Situation                   | What to do                                                                     |
+| --------------------------- | ------------------------------------------------------------------------------ |
+| Icon-only button            | `aria-label="Action name"` on the button                                       |
+| Button with tooltip         | `<Tooltip>` handles `aria-describedby` — no manual wiring needed               |
+| Loading state               | `aria-busy="true"` on the region being loaded                                  |
+| Error message below a field | `<InputText>` handles `aria-describedby` linking to the hint — don't bypass it |
+| Expandable row or section   | `aria-expanded={isExpanded}` on the trigger                                    |
+| Live status chip            | `role="status"` if the value updates dynamically                               |
+| Selectable list             | Use Radix components — don't build custom `role="listbox"`                     |
+| `<button>` element          | No `role="button"` — it's redundant                                            |
+| Element with visible text   | No `aria-label` — the text is sufficient                                       |
+| Interactive element         | Never `aria-hidden="true"` — it removes it from keyboard navigation            |
+
+---
+
+## Keyboard Navigation
+
+### Minimum requirement
+
+Every interactive element reachable by `Tab` key. Tab order follows visual order (left-to-right, top-to-bottom). No keyboard traps outside of intentional modal overlays.
+
+### Dropdowns and menus
+
+Use `<DropdownMenu>` — it inherits Radix's keyboard nav (arrows, Enter, Escape). Don't build custom dropdown menus; they won't handle keyboard correctly.
+
+---
+
+## Motion and Reduced Motion
+
+Any decorative animation must include a `prefers-reduced-motion: reduce` fallback. See `references/motion.md` for patterns. Functional motion (e.g., focus indicator appearance) is exempt.

.agents/skills/qovery-ui/references/anti-patterns.md

@@ -0,0 +1,40 @@
+# Anti-Patterns — Qovery Console
+
+Match-and-refuse. If you're about to do any of these, stop and redesign the element.
+
+---
+
+## Absolute Bans
+
+**Side-stripe accent borders.**
+A `border-left` or `border-right` thicker than 1px used as a colored highlight on a card, list item, callout, or alert. It signals hierarchy without creating it. Replace with a full border, a background tint, or nothing.
+
+**Status colors used decoratively.**
+Green for a "Pro" badge. Red to make a destructive section feel edgy. Yellow on a marketing callout. The four semantic colors — `positive`, `warning`, `negative`, `info` — communicate system state. The moment they appear elsewhere, users lose the ability to trust them. Use `neutral` or `brand` for anything that isn't a live status.
+
+**Brand violet as a page wash.**
+Covering a section, panel, or header in brand color to create visual emphasis. Brand violet is earned by interactive affordances and active states, not applied as decoration. Emphasis comes from hierarchy, not hue.
+
+**Hardcoded color values.**
+Any `#hex`, `rgb()`, or `rgba()` that isn't a CSS token. Breaks light/dark parity automatically. There is always a semantic token for the intended color — find it.
+
+**Custom status indicators.**
+A colored dot, a manually colored icon, a bespoke badge to represent deployment, build, or cluster state. `StatusChip` is the single source of truth for every known state. Custom indicators will be wrong, inconsistent, and inaccessible.
+
+**Whitespace inflation.**
+Padding added to make a surface feel "clean" or "premium" in a tool where users are scanning dense data. Whitespace serves legibility and hierarchy, not aesthetics. If removing half the padding doesn't break readability, it shouldn't be there.
+
+**Modals as the first answer.**
+A modal for a confirmation, a setting, a form, a detail view. Modals are the lazy path. First ask: can this be inline, in a side panel, in a page of its own, or in a popover? Reach for a modal only after exhausting those options. Never nest modals.
+
+**Identical card grids.**
+A grid of same-sized cards each containing icon + heading + description. It is the default AI-generated dashboard layout. If the content can be expressed as a table, a list, or a richer layout — it should be.
+
+**The hero-metric block.**
+A large number, a small label, with optional supporting stats and a gradient accent underneath. It's the SaaS dashboard cliché. Acceptable only when the metric is the primary reason a user opens the page.
+
+**Emoji as icons.**
+Random emoji in place of real iconography. Mixed emoji styles (flat + 3D + skeuomorphic) in the same surface. Emoji carry platform-specific rendering, inconsistent sizing, and no semantic meaning in a design system context. Use `<Icon>` from the FA Pro kit.
+
+**Fake handwriting and forced authenticity.**
+Script fonts used to signal warmth or humanity. "Made with ❤" footers. Tilted cards, taped-on aesthetics, or deliberate imperfection at scale. These patterns read as AI-generated cosplay of human design, not actual craft. Qovery's character comes from precision and calm, not performative personality.