14 Commits (bb21f026bf4d7b8d769dcd224a5740c8a61b963d)

Author	SHA1	Message	Date
dev	312c8740ca	refactor(date-picker): rename kind 'date' to 'day' for trio consistency ... Audit caught `data-kind="date"` violation — the date-picker / date-range-picker morfos declare `data-kind ∈ [day, month, year]` but the public `kind` prop accepted `'date' | 'month' | 'year'` and defaulted to `'date'`. Rename prop value `'date' → 'day'` so the trio is consistent (all named after the grid cell granularity). **Rationale (book-pure)**: - The trio `day` / `month` / `year` is internally consistent — all three name the granularity of the grid cell the calendar view shows. - `'date'` was awkward in the trio: month and year pickers also pick "dates", just at coarser granularities. - The morfo enum was already canonical (`['day', 'month', 'year']`); this aligns the prop with the contract. **Surface touched** (all `'date' → 'day'` for the kind value): soma components: - date-picker / date-range-picker / date-field / date-range-field: provider type (DatePickerKind / DateRangePickerKind), default value, test fixtures, types.ts JSDoc. demos (web/routes/uix/components/): - date-picker / date-range-picker / date-range-field: kind state, selector chips, doc table. `'date'` literals that DON'T refer to kind (kept untouched): - ValueProfile = 'date' | 'datetime' | 'zoned' (different concept). - SegmentLock = 'none' | 'year' | 'monthYear' | 'date'. - CSS `input[type='date']` (HTML attribute). **Result**: - `npm run morfo:check`: 1 issue / 1 component → **0 issues**. All 107 routed morfos validate against their demo DOM ✓ - `npm run check`: 0 errors ✓ Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	5 months ago
dev	afb09c2254	feat(picker-shell): extend to Root + Header + Body + Footer layout ... Promote PickerShell from action-row-only to a canonical 4-zone shell (Root → Header / Body / Footer) shared by every composite picker so date/time/color popovers get the same visual contract for free. - Add `<PickerShell.Root>` flex-column wrapper (emits data-picker-shell, data-mode) plus `<PickerShell.Header>` and `<PickerShell.Body>` zones matching the existing Footer's spacing + border tokens. - Auto-wrap all 5 *-content.svelte popovers (date / date-range / time / time-range / color) in `<PickerShell.Root>` so consumers only compose Body + Footer. - Refresh all 5 demos to use `<PickerShell.Body>` around picker content; date-picker demo gains a `showShellHeader` toggle showcasing the new Header zone. - CSS scales section gap + header spacing across xs/sm/md/lg picker sizes via [data-popover-content][data-picker-size] scopes, in sync with the existing Footer scale. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	5 months ago
dev	fd3a0b00c9	feat(calendar, date-picker, date-range-picker): add xs size + fix duplicate footer ... xs propagation - Add [data-size='xs'] blocks to calendar.css, date-picker.css, date-range-picker.css (root + inline range calendar). - Extend CalendarSize union with 'xs'; DatePicker / DateRangePicker inherit it through their type re-exports. - date-picker-content + date-range-picker-content clamp xs to sm when forwarding to PopoverContent (PopoverSize starts at sm; the calendar inside still receives xs via data-size). - size chip groups in calendar / date-picker / date-range-picker demos now list xs / sm / md / lg. date-picker demo: fix duplicate footer - The `calendarBody` snippet had a hardcoded <DatePicker.Footer> that rendered alongside the controllable `pickerFooter` snippet, producing two footer rows when showFooter=true. Removed the hardcoded one. Verified in browser: - date-picker size='xs' -> data-date-field-input height 26px (control-height-xs), padding 8px (space-2), font-size 12px. - date-picker popover now shows a single footer. - svelte-check --threshold error -> 0 errors / 0 warnings / 4572 files. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	5 months ago
dev	05a432afc0	date-range-picker: YearRangeView + MonthRangeView (kind grids) ... Completes the kind contract for the range picker. The popover used to render the day-grid range calendar regardless of kind; now it switches to a year-grid or month-grid view that handles range selection on the appropriate granularity. New Eidos parts: - <DateRangePicker.YearView>: 3×4 decade grid with prev/next decade buttons. Selection state machine (mirrors the day-grid range selection): * empty → click sets startValue (and clears endValue) * pending (start set, no end) → click sets endValue. Swap if the clicked year is before the existing start. * complete (both set) → click resets to a fresh start + clears end. Year endpoints normalise to Jan 1 (start) / Dec 31 (end). - <DateRangePicker.MonthView>: 3×4 month grid for the placeholder's year, with prev/next year navigation. Same state machine using `year*12 + month` as the comparison key, so ranges span multi-year boundaries cleanly. Start = day 1; end = last day of the month (computed via Date(y, m, 0).getDate()). - Localised month names via DateFormatter(locale, { month: 'short' }). Index + CSS: - index.ts: registers YearView + MonthView on the DateRangePicker namespace. - date-range-picker.css: shared grid layout (3 columns, gap-2), hover surface-overlay, selected cells get primary-solid + content-on-solid, in-range cells get color-mix(primary-solid 22%, transparent) as a stripe with border-radius:0 (start/end keep their outer corner radius). Reduced-motion respected. Demo: - {#if kind === 'year'} → <YearView>; {:else if 'month'} → <MonthView>; {:else} → existing day calendar. - pickerFooter snippet rendered once at the Content level (removed the inline render at the end of calendarBody to avoid duplication). Verified in browser: 1. kind='year' chip → popover shows year grid '2020 – 2031'. 2. Click 2024 → cell marked start (purple solid). 3. Click 2027 → cell marked end, 2025-2026 marked in-range. trace shows 'range 2024-01-01 -> 2027-12-31'. Popover stays open (closeOnRangeSelect=false in the demo). 0 type errors, 67/67 component:audit PASS. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	5 months ago
dev	9baccecda9	picker demos: footer composition switches + popover closed by default ... Two follow-ups from user feedback: (1) User: 'en los demos no existen para definir las propiedades y visibilidad del pie y los botones' — after the previous refactor that moved visibility from props to composition, the demos lost their UI switches and there was no way to toggle the parts on/off. Restored toggles but with the correct semantics: the switches now decide whether each part is INCLUDED in the markup, not whether the part renders internally. Composition first, demo UX second. - Both demos: new state vars showFooter / showClear / showCancel / showClose (default all true). - New `{#snippet pickerFooter()}` snippet that renders <Footer><Clear/><Cancel/><Close/></Footer> with {#if show*} guards on each child. Rendered once via {@render pickerFooter()} at the end of every calendar branch (Calendar / MonthView / YearView for single; the rangeCalendar for range). - New 'footer' control row with 4 switches per demo, labelled with the structural intent ('compose parts inside <Footer>'). (2) User: 'el popover del calendar aparece, eso es un error' — the previous commit defaulted open=true on both demos so the new Footer was visible at first paint. That conflicted with the natural flow (user expects to click the trigger to open). Reverted to open=false by default. Also removed the auto-reopen $effect that re-opened the popover whenever `kind` changed. The chip click can close the popover via outside-click in inline mode; the user re-opens deliberately. No more magic. Verification: 0 type errors, 67/67 component:audit PASS. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	5 months ago
dev	4a866cf86a	date-range-picker: propagate kind to start/end inputs ... User: 'lo has trasladado da daterangepicker?' — only the Footer pure- composition refactor had landed in range; the `kind` prop (Chakra date/month/year variant) was still single-picker only. The range demo's input segments stayed MM/DD/YYYY regardless of the chip. This commit propagates `kind` end-to-end through the range stack. Calendar view-mode (year-grid / month-grid for ranges) is still pending — that's the next commit. soma: - DateRangePickerKind type exported alongside DateRangePickerMode. - DateRangePickerProvider opts gain `kind`. Root .svelte threads it through readableActive both to the picker context AND to the DateRangeFieldProvider it creates. - DateRangeFieldProvider opts gain `kind` (single value — there's no use case for kind='year' on start + kind='month' on end; the range picker enforces a uniform kind on both endpoints). - date-range-field-input forwards provider.opts.kind to each endpoint DateField it spawns. The constant `kind: 'date'` placeholder is gone. - types.ts (range-picker + range-field): JSDoc + prop declarations. - exports.ts: surface DateRangePickerKind alongside DateRangePickerMode. - Test fixtures (range-picker + range-field): extended with the new opt. demo: - `let kind = $state<'date' | 'month' | 'year'>('date')` + chip control next to the `mode` radio + prop pass-through to <DateRangePicker>. Browser confirmed: clicking 'year' chip collapses BOTH start and end inputs to a single `2026` segment. 'month' shows MM/YYYY on both. 'date' restores MM/DD/YYYY. What's still pending (next commit): - Year-grid and month-grid views for the range popover. Currently the day calendar still renders regardless of kind. The range picker's popover view-mode needs RangeCalendar to gain a `view` prop and the eidos surface to dispatch to YearRangeView / MonthRangeView components (range selection state machine: first click sets start, second click sets end). Verification: 0 type errors, 18/18 tests across the date-* soma suite, 67/67 component:audit PASS. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	5 months ago
dev	6299e6ebc6	pickers: Footer parts = pure composition (drop *Button props) ... User correctly pointed out: button visibility should not be exposed as properties on the picker root. It should be expressed via composition — if you include <DatePicker.Clear/> inside <DatePicker.Footer/>, it shows; if you omit it, it doesn't. Same as how Header parts work, and extensible to derivatives (date-range-picker follows the same rule). This commit removes the visibility props + visibility checks. Pure composition wins. soma: - DatePickerProvider opts: drop clearButton / cancelButton / closeButton. The root soma component drops the props + the readableActive passes. Same for DateRangePickerProvider. - types.ts: drop the prop declarations + JSDoc. - Test fixtures: drop the state() entries for the removed opts. eidos parts: - date-picker-clear / cancel / close: drop the `visible` $derived and the {#if visible} guard. Render unconditionally. - date-range-picker-clear / cancel / close: same. - date-picker-footer / date-range-picker-footer: also drop the combined `visible` $derived. The Footer container always renders whatever children are composed inside. Modal mode: previously the Close part forced itself visible whenever mode='modal'. That magic is gone too — the consumer is now responsible for including <Close/> if mode='modal'; otherwise the modal has no exit affordance (and that's documented in the Close part's comment). demos: - Drop clearButton/cancelButton/closeButton state vars. - Drop the prop pass-through on <DatePicker> / <DateRangePicker>. - Drop the 'footer buttons' switch group. - Drop snippet code refs to those props. - Keep the same <Footer><Clear/><Cancel/><Close/></Footer> markup inside the calendar branches — now visibility is purely structural. Verification: 0 type errors, 7/7 date-picker + date-range-picker soma tests, 67/67 component:audit PASS. The picker still renders with all three buttons by default (because the demos compose them). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	5 months ago
dev	3956a5d39e	picker demos: open by default + footer buttons enabled ... User report: 'no veo que haga nada nuevo en la demo' — the new canonical Footer/Clear/Cancel/Close parts existed but were invisible on first load because every *Button toggle defaulted to false and the popovers opened closed. The user reloaded, saw the same baseline as before, and concluded nothing had landed. Fix: - date-picker demo: open=true, closeOnDateSelect=false (so the user can pick a date without the popover collapsing while exploring), clearButton=true, cancelButton=true, closeButton=true. Result: on first load the calendar is visible with 'Borrar fecha · Cancelar · Cerrar' below it, in the active locale. - date-range-picker demo: same — open=true, clear/cancel/close all default to true. The comment claiming the popover should stay closed because 'segments are for keyboard entry' is replaced; the demo's purpose is to surface the API, and the segments are still reachable by Tab-focus even when the popover is open. These changes are demo-only — the actual provider defaults stay inline/false. Production consumers must opt in. 0 type errors. Browser verified: Footer renders with all three i18n-driven labels at the bottom of the calendar. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	5 months ago
dev	394aeaa476	pickers: promote Footer/Clear/Cancel/Close to canonical Eidos parts ... The footer affordances (Clear / Cancel / Close) lived inline in each demo as picker-actions.svelte. Promoted to canonical Eidos surface so the API is consistent and the contract is auditable. morfo: - date-picker + date-range-picker: added Footer (archetype 'footer'), Clear/Cancel/Close (archetype 'trigger', kind 'public', optional). Each part declares aria-label via idlangref and data-action="…". - types.ts: added 'footer' to ARCHETYPE_VOCABULARY array + the MorfoArchetype union (the type had it, the runtime list did not). - lang catalogs: added clear / cancel / close idlangref entries to date-picker.ts and date-range-picker.ts. eidos: - Created date-picker-footer/clear/cancel/close.svelte and the range mirrors. Each part: - Pulls the provider from context via DatePickerProvider.require() (analogous DateRangePickerProvider.require() for the range). - Renders nothing when the corresponding *Button opt is false; the Close part stays visible whenever mode === 'modal' (modal pickers need a way out — outside-click and Escape are blocked). - Emits data-{component}-{part} + data-action so the recipe selector matches the morfo declaration. - aria-label resolves via uix.langs.ts('#?components.X.{action}|…'). - onclick calls provider.clear() / cancel() / commit() then forwards any consumer-supplied onclick. - index.ts barrels: registered Footer/Clear/Cancel + replaced Close (was popover-close.svelte) with the new picker-aware Close. Soma popover-close still drives the old aria; date-picker's Close adds the modal-conditional visibility + commit semantics. - *.css: folded the inline picker-actions styles into the recipes — data-{name}-footer flex row + data-{name}-{clear,cancel,close} buttons (clear/cancel margin-inline-end: auto so close sits flush right). prefers-reduced-motion already covered. soma: - date-picker exports.ts: surfaces DatePickerProvider + DatePickerMode + datePickerAttrs so the Eidos parts can consume them (mirrors what date-range-picker already exposed). No new behavior — just plumbing. demo: - date-picker + date-range-picker demos: replaced <PickerActions /> with <DatePicker.Footer> <DatePicker.Clear /><DatePicker.Cancel /><DatePicker.Close /> </DatePicker.Footer>. The two picker-actions.svelte files are deleted. Verification: 0 type errors, morfo:check PASS (Footer parts not required in DOM; conditional visibility honored), component:audit 67/67 PASS. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	5 months ago
dev	383e2ff7f7	date-range-picker: mode prop + footer button props + revert group chrome ... User feedback batch from incidencia 2026-05-20: 1. Modal vs inline mode - New `mode: 'inline' | 'modal'` prop on the soma `DateRangePicker.Provider`. - Modal wires the popover `modal: true` → outside-click and Escape are ignored; user must commit via the footer Close button (or revert via Cancel). - Provider exposes helpers `clear()`, `cancel()`, `commit()` for the footer. `cancel()` restores the value snapshot taken on the OPEN edge (captured via a `watch` on `opts.open` true-edge transition). 2. Footer buttons as boolean props - `clearButton`, `cancelButton`, `closeButton` props on the picker. The footer renders only if at least one is true. In `mode='modal'` the closeButton is forced on (the user always needs an exit). - `picker-actions.svelte` in the demo reads the picker context via `DateRangePickerProvider.require()` and renders the enabled buttons against `provider.clear/cancel/commit`. 3. Range field shape (revert to Chakra-style two boxes) - Removed the `data-date-range-field-group` wrapper from the demo so the start and end inputs are rendered as two separate boxed fields with the icon embedded in the end box, matching Chakra's layout. - The recipe CSS rules for `data-date-range-field-group` stay available as an opt-in for consumers who prefer the unified pill. 4. Demo defaults - `open` starts at `false` so the picker exercises the real open/close flow when the user clicks the trigger — the segments are for direct keyboard entry, the popover is for visual exploration. - Mode toggle (inline / modal) + footer button switches surfaced as controls in the demo. 5. Plumbing - DateRangePickerOpts gains `mode`, `clearButton`, `cancelButton`, `closeButton` (StateProps for mode, ActiveProps for the booleans). - `DateRangePickerProvider` and `DateRangePickerMode` are now re- exported from the soma barrel for consumers that wire footer actions in the calendar tree. - Test factory updated to seed the new opts. Verified in browser: trigger opens; click-outside in modal mode is ignored; Close commits & closes; Cancel reverts to snapshot & closes; Clear empties the range & keeps open. Heading "May – June 2026" (year collapse) and centered per-calendar titles still working from the previous commit. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	5 months ago
dev	0d164b54de	date-range-picker: unify start + end into a single input chrome ... Closes incidencia point B (range field shouldn't show two separate boxes). New CSS contract: `[data-date-range-field-group]` on the wrapper element collapses the chrome around its descendants: - The group owns the border, background, focus ring, invalid state, variant/ghost treatment, and disabled opacity. - Each `[data-date-range-field-input]` inside loses its own border, background, and padding; it just contributes its segments to the shared row. - The "to" separator (.range-separator or `[data-range-separator]`) picks up the field's literal tone. - The embedded trigger from the previous commit sits flush at the trailing edge of the group, since `data-date-field-input` already detects the embedded case. Demo: add `data-date-range-field-group` to the `.range-field-row` wrapper. Visually now reads as one input pill: `05 / 20 / 2026 to 06 / 03 / 2026 📅`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	5 months ago
dev	3b464ee361	range-calendar: smart heading + per-calendar title in header ... Closes incidencia points D + E: - Heading collapses the shared year when both visible months are the same year: "May – June 2026" instead of "May 2026 – June 2026". Cross-year still renders both ends explicitly ("June 2025 – July 2026"). Implemented in `RangeCalendarProvider.headingValue`. - date-range-picker demo: drop the per-month title that previously rendered BELOW each grid (duplicate of the main heading). Instead, render one centered title per visible calendar INSIDE the header bar between the prev/next buttons. The grid below now shows just the weeks. A `range-header-titles` grid container splits the available header space equally across `month-count` titles, so each label sits centered over its calendar grid. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	5 months ago
dev	5f8adbeca6	date-picker + date-range-picker: trigger embedded inside the input ... The calendar icon now lives INSIDE the date input as a flush trailing affordance, not as a separate sibling button. The change is markup + recipe CSS only — no API change. - Demo (date-picker): drop the `.picker-control` grid wrapper; put `<DatePicker.Trigger />` as the last child of the Input snippet, after the segments. Codeblock snippets updated to match. - Demo (date-range-picker): keep the dual-input + separator layout but move `<DateRangePicker.Trigger />` into the END input, since the trigger represents the trailing affordance of the whole range. Both code snippets updated. - Recipe CSS (both): add nested rules that detect the embedded case (`[data-date-field-input] > [data-date-picker-trigger]`, `[data-date-range-field-input] > [data-date-range-picker-trigger]`). Embedded trigger drops its own border/background, matches the segment height, sits flush at the trailing edge with `margin-inline-start: auto`, and uses the segment focus ring on hover/focus instead of the standalone field ring. The standalone (sibling) treatment stays available for consumers who prefer the icon as a separate control. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	5 months ago
dev	39eb0eec86	uix: date-picker + date-range-picker components + component audit infra ... Two new Eidos components shipped end-to-end (wrapper + recipe + demo + Soma provider hardening) plus a checklist-driven audit pipeline that scores all 67 morfo components against doctrinal completion criteria. New components: - date-picker: full popover-anchored picker over date-field + calendar, with calendar/content/trigger parts and demo route. - date-range-picker: standalone wrapper with own calendar/grid/segment surface, demo route, and recipe CSS. - Both wrappers follow Option C disciplined (root + parts attached via explicit assignment, no Object.assign). Supporting Soma changes: - range-calendar provider tightened (211 LOC of behavior, 167 LOC of tests), README brought up to component doctrine. - date-field, date-picker, date-range-field, date-range-picker Soma providers + READMEs updated for new wrappers. - popover provider/close gain props needed by the picker wrappers. Morfo updates: - date-picker / date-range-picker / range-calendar morfos refined for the new APIs (parts, events, ARIA). Audit infrastructure (new): - src/uix/COMPONENT_COMPLETION_CHECKLIST.md — 81 doctrinal rules across morfo / eidos wrapper / recipe CSS / demo / README / cross-layer scripts. Each rule keyed to active_architecture.md, GUIA_IMPLEMENTACION and DEMO_AUTHORING_GUIDE. - scripts/component-audit.ts + `npm run component:audit` — regex parser over all 67 components, emits tmp/component-audit.md with summary scoreboard + per-component findings. Validates against canonical SEMA_FAMILIES / SEMA_VERBS / ARCHETYPE_VOCABULARY / INTENTS. - Initial baseline: 1 PASS, 64 NEEDS-WORK, 2 BROKEN (tooltip, date-range-picker). Top systemic gaps: translations.label (49), README Gaps/Comparativa/Baseline sections (87 combined), keyboard /event ratio under-declaration (15), apg URL absent (19). Misc: - src/uix/kimi-audit-eidos.md — supplementary audit notes. - .gitignore: ignore .codex-* agent scratch artifacts at repo root. - continue.md + READMEs updated through the migration. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	5 months ago