# Component proposals — flagged for next DS iteration

While building the first 4 manager mock-screens, three visual patterns crystallised
that **don't belong in the page-layout patch** but **will repeat across many
manager screens** and deserve to live in the DS. Documenting them here so the
next DS iteration can pick them up.

> **None of these are in the page-layout patch.** They live as local components
> in the manager-mock project (`app/chrome.jsx`) until promoted to the DS.

---

## 1. `u-status-track` — multi-step status visualisation

**Where seen.** Bejelentés-adatlap top — a 4-step horizontal track showing
`Új → Kiosztva → Folyamatban → Lezárt` with current step highlighted.

**Why DS-worthy.** Every entity with a non-trivial state machine will want
the same vizualization. The spec rooflines it explicitly:

- `Ticket` state-machine (5 states, K-029) — *currently used*
- `WeeklyReport.generationStatus` (4 states) — riport-adatlap will want it
- `WeeklyReport.deliveryStatus` (4 states) — riport-adatlap will want it
- `News.contentStatus` / `Event.contentStatus` (Vázlat → Publikált) — short,
  but the visual idiom would still apply
- `User.status` / `UserStatus` (Invited → Active → Disabled) — felhasználó-adatlap

**Proposed API.**

```html
<ol class="u-status-track" data-current="2">
  <li class="u-status-track__step" data-state="done">
    <span class="u-status-track__dot"></span>
    <span class="u-status-track__label">Új</span>
    <time class="u-status-track__meta">2026.05.17.</time>
  </li>
  <li class="u-status-track__step" data-state="done">…</li>
  <li class="u-status-track__step" data-state="current">…</li>
  <li class="u-status-track__step" data-state="pending">…</li>
</ol>
```

The `data-state` attribute drives the dot color (status-token-based) and the
connector line between steps. Density-aware: in `[data-density="work"]` the
track is more compact; in `header` it's roomier.

**Notes.** The "Elutasítva" state is a **branch**, not a step on the track.
Don't try to embed it as a 5th step — it's shown via a different surface
(red banner + reason). Documented in `02_globalis_allapotgep.md`.

---

## 2. `u-kpi-card` — large-number summary card

**Where seen.** Dashboard "Ez a hét" row — 4 cards with a 13px label, a
44px tabular-numeric value, and a 12px hint with arrow affordance.

**Why DS-worthy.** Same shape will appear in:

- Riport-adatlap header (week numbers: 19 új / 12 lezárt / 3 késésben / ...)
- Felhasználó-adatlap (per-user stats)
- Tenant-szintű analytics (későbbi iteráció)
- Even a kategória-statisztika later

**Proposed API.**

```html
<article class="u-kpi-card">
  <header class="u-kpi-card__header">
    <span class="u-kpi-card__label">Nyitott ügyek</span>
    <!-- optional emphasis chip, e.g. "Figyelmet kér" for the overdue card -->
  </header>
  <div class="u-kpi-card__value">47</div>
  <footer class="u-kpi-card__hint">
    Mind a négy nyitott státusz
    <svg>…</svg>
  </footer>
</article>

<!-- tones for emphasis -->
<article class="u-kpi-card u-kpi-card--danger">…</article>
```

The value uses `font-feature-settings: "tnum"` (tabular-nums) so 9-digit and
4-digit numbers align vertically when cards sit in a row.

**Distinct from `u-card`.** A KPI card has an opinionated three-row internal
layout. Building it as a `u-card` variant would mean re-deciding the type scale
and spacing every time. Better as its own atom.

---

## 3. `u-tabs--underline` — variant of the existing tabs component

**Where seen.** Bejelentés-lista — the 5 tab-filters (Új / Hozzám rendelt /
Késésben / Lezárt / Mind) use a bottom-underline indicator, not a pill.

**Why DS-worthy.** The existing `components/tabs.css` provides `.u-tabs--pill`
*(rounded pill, filled-on-active)*. Spec-driven tab-szűrők on lists are
**always underline-style** (SD-30, list page-headers). The two variants
should co-exist; underline is the dominant choice for "page-level filters",
pill is for "view-switches inside a card".

**Proposed API.** Add to existing tabs.css:

```css
.u-tabs--underline { … }
.u-tabs--underline > .u-tab[aria-selected="true"] {
  border-bottom: 2px solid var(--u-primary);
  color: var(--u-fg-1);
  font-weight: 600;
}
```

Count badges inside tab labels: a small `.u-tab__count` pill, default
`--u-surface-alt` bg / `--u-fg-3` fg, becomes `--u-primary-soft` bg /
`--u-blue-700` fg when the parent is selected.

**Risk:** the existing pill-tabs and these underline-tabs share enough markup
that a single `.u-tab` element + parent-level variant is fine. Don't fork.

---

## Why this is a separate doc, not part of the page-layout patch

These are **atoms / molecules**, not page-layout primitives. Treating them as a
single patch would mix two concerns. The page-layout patch is purely additive
to the layout-token layer and unblocks immediate work; these three want a
proper design pass, a `docs/components/<name>.md` spec, and a
`preview/comp-<name>-system.html` specimen.

Sequence I'd suggest:

1. **Now:** ship the page-layout patch (`01..03`). It's a docs-vs-code
   alignment, has no design questions.
2. **Next sprint:** pick one of the three above. `u-status-track` has the
   most reuse (every entity state machine), so it's the highest-leverage.
3. **After that:** the other two.

Until then, these live in the manager-mock project's `app/chrome.jsx` and
`app/screen-*.jsx` files. When promoted, the local versions get removed in
the same commit.