svelte-kit-vice/docs/next-features.md

title	type	audience	authority	status	created
Next features — initiative registry	registry	human + agent	backlog of user-decided future initiatives — records scope, sequencing and dependencies; it does NOT record verdicts (those live in the RFCs / changelog / book-deviations when executed)	living — items enter by explicit user decision during audits and sessions; remove an item when it ships (and link where it landed)	2026-07-06

Next features — initiative registry

Rules of this file: one entry per initiative, dated, with its origin (which audit/session raised it), its scope in one paragraph, and its dependencies. Entries are registered, not started — starting one is a session decision. Detail lives in the linked doc, never copied here.

1. Tonal-ramp contrast parity (measure, then construct) — 2026-07-06

Origin: A.7 follow-up (theming audit F). The on-solid pair is now computed at generation with a single criterion (rfcs/rfc-color-engine.md §8, eidos/lib/on-solid.ts). M3 still guarantees more: contrast by construction across its whole tonal ramp (container/on-container pairs at fixed tone deltas — ΔT 40 ≈ 3:1, ΔT 50 ≈ 4.5:1). Our equivalent promises (text-11 on bg-2/element-3, border-7 vs bg-2 at the 3:1 non-text floor, text over composited soft surfaces a2/a3) rest on Radix-style curation, unmeasured.

Stage 1 — pair-contract verification (the A.7 pattern generalized): a canonical table of slot pairs + floors (a user-decided doctrine session), a measurement pass over pairs × 33 scales × 2 modes at generation (on-solid.ts generalizes; the compositing math exists in $color), and the resulting drift list goes to user verdicts (retune vs annotated exception). Infrastructure is small; the fallout is the unknown.

Stage 2 — by-construction generator: generateScale solves each step's luminance to satisfy Stage 1's pair table for ANY seed (given bg-2's Y, solve text-11's minimum Y; invert to OKLCH at the step's chroma/hue). Only protects seed-generated themes — covering the BASE theme requires the base→seeds migration already planned in rfcs/rfc-color-engine.md §9, which is the expensive, visually-sensitive part and this stage's gate.

Sequence: Stage 1 first (it is the spec for Stage 2). No M3-style on-* vocabulary expansion — our slots already encode the pairs; the table formalizes them without inflating the namespace.

2. Per-theme palette-contrast cascade emission — 2026-07-06

Origin: A.7 execution. The per-instance palette-contrast cascade lives in the STATIC foundation — one polarity for all themes. Today polarity is computed per configured theme and unanimous (33/33 scales agree across base-light/base-dark); on disagreement the *-light theme wins (computeLightSolidScales, documented in rfcs/rfc-color-engine.md §8). Trigger: the day a real configured theme disagrees on a scale's polarity, emit the cascade per-theme instead of statically. Not before — no speculative machinery.

3. Component audit (post-system) — 2026-07-06

Origin: user decision during the theming audit — "de momento no tocamos los componentes, merecen una auditoría adicional una vez que se haya resuelto estas". Gate: the system-level audit (F/G) closes first. Registered items so far, to seed its scope:

• Named-styles adoption by controls (from A.3): controls/recipes that hand-declare typography instead of consuming --style-* / size-bundle typography — likely by error, to be confirmed per component.
• Letter-spacing bundle adoption: ~34 recipes consume font-size / line-height from the size bundle but not letter-spacing; plus ~7 raw letter-spacing literals in component CSS.
• Tier-A data-depth stamping coverage: overlays that should stamp their plane (dialog / drawer / tooltip / menubar / combobox) per rfcs/rfc-depth.md §5.
• Calendar family → shared layer/archetype (user design verdict, 2026-07-07): the calendar-grid vocabulary (accent set, day geometry, the holiday/event marks fixed in audit B.2) becomes a FIRST-CLASS shared layer — today the family borrows it informally (measured: range-calendar consumes 79 --calendar-* tokens, month-grid 65, year-grid 65, date-range-picker 38, date-picker 4 — ~250 cross-component borrows), and chronos will draw from it too when its track lands. Materialization to decide at execution: a morfo part-archetype for the day cell (the 26-set grows) and/or a calendar-surface shared recipe à la list-surface (--list-item-* precedent). This supersedes "per-component composition repairs" for the B.2 borrowers: the marks reach the whole family through the shared layer instead.
• Field family composition — segments under [data-field] (user design verdict, 2026-07-07, audit B.1): segment height derives from the SIZE axis at the FIELD family level — field recipe declares segment-height with size-scoped declarations (calc(var(--field-control-height-{k}) - var(--space-2)); the TSC size: scope axis exists, unused so far), and the per-component copies die (each x-field today re-declares the whole height-{xs..xl} family the field recipe already has). MANDATED by the B.1-(i) verdict: date/time/color-field MUST incorporate the Field wrapper (segments under [data-field][data-size] — probed live: today they don't) as part of the component audit; the three broken per-component segment-height tokens and their consumers were removed (they had computed auto since birth — zero visual change).
• Whatever F/G registers as "component-level adoption gap" in docs/audit/theming-audit.md when that report lands (deliverable G of the 2026-07 theming audit).

4. architecture/sema.md hold-sync — 2026-07-06

Origin: A.4/A.5 execution (holds single-source). SEMA_HOLDS_BY_INTENT (src/uix/sema/holds.ts) is now THE only hold table (resolver + visual channel consume it; sema-map.ts's per-family hold column died). The chapter architecture/sema.md still narrates per-family holds in ~34 places. Blocked: the file is the author's WIP (uncommitted edits) — sync it when the author's pass lands, not before.

6. THM-2 rollout — per-instance palette to all surfaces — SHIPPED 2026-07-12

Shipped in 05f0031c (media-player Batch-4 + 14 surfaces + vocab + 4 props) and cc7e9a16 (avatar root). Every per-component palette cascade now collapses into the shared --palette-* layer (size win, behavior-preserving for roles); the vocabulary gained the alpha surface/surface-hover + hover slots. The color prop was widened to ComponentColor (roles + 33 scales) where arbitrary color is meaningful (badge, tag-group, tags-input, toggle-group; button/toggle/ card already had it); semantic controls (checkbox/radio/stepper/editable/select/ file-upload) stay role-restricted by design. Full detail + the per-component verification: the plan's §THM-2 block.

Deliberate scope boundary — Avatar.Badge is OUT of the per-instance scale palette, by design (aligned with the ecosystem): a status badge takes a role/intent (online→affirm, alert→threat) or a direct CSS color — MUI/Spectrum/ Bootstrap use semantic status colors, Chakra/Mantine/Ant use a direct color; NO framework routes an avatar's status badge through a brand-scale palette. So the badge keeps its role palette + custom-CSS; migrating it (per-part forward + ~36 orphan prunes) would exceed the convention. Not debt — a design decision.

5. Book editorial note — "el hold es suelo, no tijera" — 2026-07-06

Origin: A.4/A.5 verdict. The mechanism (hold = floor for the expression, never a scissor; expression waits animation-finish after the hold, capped by an absolute MAX_EXPRESSION_WAIT_MS, never derived from the hold) is recorded in decisions/book-deviations.md D.12 as a candidate editorial appendix for the book (Diseñando lo que ocurre, HOMOGENEIZADO edition) — the book gives qualitative regions and this is the materialization doctrine worth feeding back to the source.