svelte-kit-vice/audit/components/css-field.md

# Audit: css-field
audit-version: 1
audited-at: 2026-06-26
scope:   (SCOPE-DRIFT → SYS-1)
method: adversarially-verified workflow (analyze → refute); HIGH/CRITICAL lead-verified. Clean-check pseudo-findings dropped. B4 ground-truth: segmented date/time/color-field register inputId via $effect (SYS-A30-EFFECT, no loop); number-field is the direct-assignment reference.
provider: G:\dev\svelte\vicen\src\uix\soma\components\css-field\css-field-provider.svelte.ts

## Summary
Counts (post-verification): CRITICAL 0 · HIGH 0 · MEDIUM 1 · LOW 0.

## Findings
### MEDIUM: SCOPE-DRIFT: eidos recipe dir exists but morfo 'scope' omits 'eidos' — css-field-001   <!-- id: css-field-001 -->
- dimension: Frontier, SYS-1
- rule: SCOPE-DRIFT: eidos recipe dir exists but morfo 'scope' omits 'eidos'
- location: G:\dev\svelte\vicen\src\uix\morfo\components\css-field.ts:7
- evidence: scope: ['soma', 'sema'], — eidos/components/css-field/ exists with css-field.svelte, css-field-input.svelte, etc., but scope array does not include 'eidos'
- impact: Contract validator cannot check that eidos wrappers only import from morfo PARTS, risking cross-layer coupling over time as the component evolves
- proposed-fix: Add 'eidos' to morfo scope: scope: ['soma', 'sema', 'eidos']
- verify: [confirmed] Confirmed as a SYS-1 scope-drift instance. `css-field.ts:7` = `scope: ['soma', 'sema']` while an eidos dir exists with a wrapper + css (`eidos/components/css-field/css-field.svelte` imports `./css-field.css`, plus `types.ts`/`index.ts`). MEDIUM is correct per the SYS-1 catalog. Caveat for the orchestrator: this is SYSTEMIC across the whole field family, not a css-field anomaly — the project's REFERENCE baseline NumberField is identical (`number-field.ts:7` = `scope: ['soma', 'sema']` with its own eidos dir), as are time-field/color-field/date-field (all `scope: ['soma', 'sema']`). Note also css-field has no dedicated recipe: its eidos css (`css-field.css`) declares 'CssField has no visual of its own: it IS a spin-field' and styling comes from the shared `spin-field` recipe (`base.ts:1016`) via structural identity. The scope-validator gap still stands regardless.
- fix-status: fixed (212624e0)

## No-findings dimensions
Contract, DOM-selector, TSC, Tests, Redundancy, Behavior (keyboard), Behavior (A30), Behavior (A6), Behavior (TWO-MOMENTS)

## Theming facts (E-bis)
- magic z-index: none
- magic literals: 400 | 100 | 5
- undeclared parts: none
- roles clean: true · variants clean: true
- label-font (one step below input?): COMPLIANT: Field label font-size is derived as calc(var(--_field-control-font-size) - (var(--font-size-md) - var(--font-size-sm))) per field.css, which is one typographic step below the input. CssField uses shared spin-field visual, which inherits --_field-control-font-size from the recipe (e.g. field-control-font-size-md: var(--font-size-md) = 16px), making the label 14px (one step down). ✓

## Tests (F)
- exists: true · env: jsdom
- covers: commit on blur; increment/decrement with per-unit steps; bare number default unit; disallowed unit rejection (untilFix); keyword acceptance; clamping to min/max; sium schema delegation; scrubber scrubbing with unit preservation; spinbutton aria props
- untested: readonly-without-value warning; onbeforeinput paste/IME rejection; clearTarget(input) actually clears the warn signal; RTL scrubber mirroring; A30 inputId registration with parent Field

## Style observations (non-blocking)
- Default step-by-unit logic (rem/em: 0.1, else 1) is sensible and matches the UI pattern for CSS editing
- Scrubber sensitivity (5px per step default) is well-tuned for precise CSS values
- Bare-number regex parsing (line 39) handles leading dot correctly
- Comments throughout provider are clear and precise (Book §6.2 reference, untilFix signal flow)