================================================================================
GATE 6 — DESIGN CONSISTENCY AUDIT (node W15_gate_design_consistency_audit)
Repo:    oms-web (Next.js 14 / Tailwind 3 / Prisma+Postgres, standalone)
Branch:  feat/3250-oms-ui-bug-fixes-chips-s
HEAD:    2fa4249  "4. Dead Code (oms-bug-fixes)"
Gate:    gates/nextjs-tailwind-standalone/design-consistency-audit-gate.md
Ticket:  #3250
Result:  FAIL — 3 unresolved P1 findings (all [accessibility]; WCAG blockers)
         4 findings auto-fixed and re-verified (see "AUTO-FIXES APPLIED")
================================================================================

FEATURE FILES AUDITED (12)
  app/(app)/admin/items/page.tsx
  app/(app)/admin/projects/page.tsx
  app/(app)/admin/suppliers/page.tsx
  app/(app)/admin/uom/page.tsx
  app/(app)/admin/users/page.tsx
  app/(app)/expense-summary/[project]/page.tsx
  app/(app)/expense-summary/page.tsx
  app/(app)/expense-summary/ExpenseSummaryRowActions.tsx
  app/(app)/expenses/page.tsx
  app/(app)/orders/page.tsx
  components/forms/ExpenseForm.tsx
  components/forms/ResetPasswordForm.tsx

Shared components the feature files render through, read as supporting evidence
and cited where a finding's root cause lives there (three of them are also
where an auto-fix landed): tailwind.config.ts, app/globals.css,
components/ui/{DataTable,StatusBadge,RowActions,RepeaterTable,Toast,table}.tsx,
components/ui/icons/SortIcon.tsx,
components/ui/fields/{DatePicker,Listbox,TextField,SelectField}.tsx,
components/ui/FilterBar.tsx, app/(app)/expenses/ExpenseRowActions.tsx.

--------------------------------------------------------------------------------
SKILL RESOLUTION (gate file "Resolution order", per-skill, as required)
--------------------------------------------------------------------------------
No slash-command layer was available for either skill, so resolution-order
steps 1 and 2 were both unavailable. Both skills resolved via step 3 — read as
FILES, and followed directly. Neither was skipped or degraded.

As already recorded by Gate 5 (W14), the gate file's stated skill path
(.claude/skills/nextjs-tailwind-<name>/SKILL.md) does not exist in this
checkout; the real location is one level up, outside the repo:

  1. nextjs-tailwind-design-system-audit .... step 3 (file)  OK, fully readable
     /opt/drcarrot-deploy/cross-repo-orchestration/skills/
       nextjs-tailwind-design-system-audit/SKILL.md
  2. nextjs-tailwind-accessibility-audit .... step 3 (file)  OK, fully readable
     /opt/drcarrot-deploy/cross-repo-orchestration/skills/
       nextjs-tailwind-accessibility-audit/SKILL.md

--------------------------------------------------------------------------------
DESIGN-SPEC INPUT — RESOLVED, WITH A CAVEAT
--------------------------------------------------------------------------------
The node input names the design spec as `docs/specs/ticket-3250-design.md`.
That file DOES NOT EXIST in this checkout — `docs/specs/` contains only
ticket-3239-design.md and ticket-3248-design.md, and `grep -rn 3250 --include=*.md`
over the whole repo returns nothing. (Gate 5 recorded the same absence.)

The audit was NOT run blind: the design_spec node input carried the spec's full
substance inline (views, form fields, unmapped tokens, R1–R6 findings), and the
underlying design bundle it was decoded from is present on disk
(/tmp/design_template.html, 128767 bytes, and the /tmp/dev-hub-spec-*.html
family). Token claims below were checked against tailwind.config.ts, which
itself carries per-token provenance comments back to those bundles.

Consequence: this gate could verify "does the code use the tokens the spec
says exist" and "are the same visual concepts implemented consistently". It
could NOT re-derive measured pixel values from the design, because there is no
committed spec artifact to diff against. That is a process gap worth closing
before Gate 7 (responsive), not a defect in this branch's code.

--------------------------------------------------------------------------------
COMMANDS ACTUALLY RUN (real output, not predicted)
--------------------------------------------------------------------------------
1. Repo's own lint, before any change:
     npx next lint --dir app --dir components
     -> "✔ No ESLint warnings or errors"

2. Which a11y rules that lint actually enforces (the reason 1. proves little):
     npx eslint --print-config components/forms/ExpenseForm.tsx
     -> jsx-a11y rules enabled: 6 of ~35
        alt-text, aria-props, aria-proptypes, aria-unsupported-elements,
        role-has-required-aria-props, role-supports-aria-props
     eslint-plugin-jsx-a11y 6.10.2 is installed (via eslint-config-next), so
     the remaining rules are available but off under next/core-web-vitals.

3. Expanded jsx-a11y sweep over the 12 feature files (15 additional rules:
   label-has-associated-control, control-has-associated-label,
   click-events-have-key-events, no-static-element-interactions,
   no-noninteractive-element-interactions, interactive-supports-focus,
   anchor-is-valid, anchor-has-content, heading-has-content,
   no-redundant-roles, tabindex-no-positive, mouse-events-have-key-events,
   no-noninteractive-tabindex, scope, aria-activedescendant-has-tabindex):

     components/forms/ExpenseForm.tsx:135  control-has-associated-label
     components/forms/ExpenseForm.tsx:177  control-has-associated-label
     components/forms/ExpenseForm.tsx:269  control-has-associated-label
     components/forms/ResetPasswordForm.tsx:55  control-has-associated-label
     4 problems

   Triaged by hand against the source:
     :135 TRUE POSITIVE  -> finding A11Y-6 below.
     :177 false positive -> the <input type="file"> is WRAPPED by the <label>
                            at :174 whose text is "Upload"/"Uploading…"; the
                            rule does not see through the wrap.
     :269 false positive -> <textarea id="remarks"> + <label htmlFor="remarks">
                            at :266.
     RPF:55 false positive -> <input id={name}> + <label htmlFor={name}> at :51.

4. Arbitrary-colour sweep over the 12 feature files:
     grep -nE '\[#[0-9a-fA-F]{3,8}\]|\[rgb\(|\[hsl\(' <each feature file>
     -> 11 of 12 files: CLEAN, zero arbitrary colour values.
     -> components/forms/ResetPasswordForm.tsx only: lines 154, 160, 176, 183.
     (Repo-wide across app/ + components/ the same pattern hits 21 lines, so
     the branch is not an outlier — but 4 of them are in a feature file.)

5. outline-none sweep:
     grep -rn "outline-none" app components --include=*.tsx
     -> 6 hits, EVERY ONE paired with a replacement focus style
        (focus-visible:ring-* or focus-visible:bg-*) or on a non-focusable
        element. No bare focus-suppression anywhere. Checked-and-clean.

6. Clickable-non-interactive sweep:
     grep -rnE '<(div|span|li|td|tr)[^>]*onClick' app components --include=*.tsx
     -> 1 hit: components/ui/Modal.tsx:35, the backdrop, which is correctly
        aria-hidden="true" and duplicated by a real Escape handler.
        Checked-and-clean.

7. WCAG contrast computed (not eyeballed) with the WCAG 2.x relative-luminance
   formula over the exact token hexes in tailwind.config.ts:

        2.25:1  rgb(163,163,163) 13px on accent.subtle #f7f1e9   FAIL (need 4.5)
        3.09:1  status.success #229e4b 13px on #f7f1e9           FAIL (need 4.5)
        3.47:1  status.success #229e4b 12px on surface #ffffff   FAIL (need 4.5)
        4.19:1  text.muted on accent.subtle (DISABLED control)   exempt, 1.4.3
        4.55:1  status.danger .field-error on surface            pass
        4.70:1  text.muted placeholder on surface                pass
        7.34:1  text.subtle #565656 on surface                   pass
       11.79:1  accent on accent.subtle (table header/sort link) pass
       16.69:1  text.DEFAULT on accent.subtle (row hover)        pass
       18.73:1  text.DEFAULT on surface                          pass
   Non-text (WCAG 1.4.11, 3:1) — every StatusBadge dot tone and every row-action
   icon: success 3.47, warning 3.34, neutral 4.83, info 3.55, danger 4.55.
   ALL PASS. The dots are additionally aria-hidden with adjacent text, so they
   never carry meaning by colour alone.

8. Post-fix re-verification (see AUTO-FIXES APPLIED):
     npx tsc --noEmit                              -> exit 0, no output
     npx next lint --dir app --dir components      -> "✔ No ESLint warnings or errors"
     npx vitest run                                -> 94 passed / 6 failed files
                                                      732 passed / 8 failed tests
   The 8 failures were then proven PRE-EXISTING, not caused by these fixes:
   the 4 touched files were `git stash`ed and the same 6 test files re-run at
   the untouched HEAD — identical result, 8 failed / 57 passed. The stash was
   then popped. Failing tests (all pre-existing, Gate-9 territory, not design):
     expense-form.test.tsx      "selects an expense type via the row's Listbox"
     expense-summary-page.test.tsx "…a View Details link"  <- asserts the OLD
        text link that #3250 deliberately replaced with the Eye icon action
     expenses-page.test.tsx     "…total, and status"  <- asserts the Status
        column that #3250 deliberately removed (see DS-5)
     item-form.test.tsx         "pre-populates fields from the given item"
     order-form.test.tsx        "renders the Add Supplier trigger…"
     user-form.test.tsx         3 tests, all Listbox getByLabelText
   Two of those six are stale assertions against #3250's own intended changes
   and should be updated by the unit-test gate, not by this one.

================================================================================
MERGED FINDING LIST — 16 findings
  [design-system]  9  (P1 0 / P2 4 / P3 5)
  [accessibility]  7  (P1 3 / P2 4 / P3 0)
  totals              (P1 3 / P2 8 / P3 5)
  auto-fixed       3 findings (DS-1, A11Y-5, A11Y-6) via 4 code edits —
                   A11Y-6 needed two (ExpenseForm + RepeaterTable) and is
                   fixed only in part; its Listbox half stays reported
  unresolved P1    3  (all accessibility)
Ordered per the accessibility skill's rule: barrier severity first, then
design-system domain groups.
================================================================================

--------------------------------------------------------------------------------
[accessibility] A11Y-1 — P1 — CONTRAST — UNRESOLVED
--------------------------------------------------------------------------------
File:      components/forms/ResetPasswordForm.tsx:176, 183
Component: PASSWORD POLICY card, unmet-rule labels
Category:  contrast
Problem:   The five policy rules and the static "Not last 3 passwords" row
           render at text-[13px] in text-[rgb(163,163,163)] on the card's
           bg-accent-subtle (#f7f1e9). Measured 2.25:1 — WCAG 2.1 AA 1.4.3
           requires 4.5:1 for text under 18.66px. This is roughly HALF the
           required ratio, not a borderline miss.
Evidence:  computed via the WCAG relative-luminance formula, command 7 above.
           :176  className={clsx("text-[13px]", rulesMet[i] ? … : "text-[rgb(163,163,163)]")}
           :183  className="text-[13px] text-[rgb(163,163,163)]"
Why it matters: low-vision users cannot read the password rules — which on this
           screen ARE the instructions. The unmet state is precisely the state
           a user needs to read; once a rule passes it turns green and the user
           no longer needs it. The contrast is worst exactly when the content
           matters most.
Recommended fix: darken the unmet-rule grey to at least #6b6b6b on #f7f1e9
           (4.5:1) and give it a real token. NOT auto-fixed: the design_spec
           input lists rgb(163,163,163) as an explicitly Unmapped Token with no
           source in either bundle, so picking a replacement is a design
           decision, not a token swap. Needs the same operator call as R1.
Risk of change: low technically, but it visibly changes the card, so it needs
           design sign-off rather than a silent gate edit.

--------------------------------------------------------------------------------
[accessibility] A11Y-2 — P1 — CONTRAST — UNRESOLVED
--------------------------------------------------------------------------------
File:      components/forms/ResetPasswordForm.tsx:164, 176
Component: strength label + met-rule labels
Category:  contrast
Problem:   status.success (#229e4b) is used as small TEXT in two places and
           fails 1.4.3 in both:
             :176 text-[13px] text-status-success on #f7f1e9  = 3.09:1
             :164 text-xs (12px) text-status-success on #fcfcfd = 3.47:1
           Both need 4.5:1.
Evidence:  command 7 above. tailwind.config.ts:77 sources #229e4b from the
           design bundle as a STATUS DOT / pill-fill colour — where the 3:1
           non-text threshold applies and it passes comfortably. The failure is
           caused by reusing a non-text colour as body text, not by the token
           being wrong.
Why it matters: the "Strong"/"Weak" strength word and the satisfied-rule labels
           are unreadable for low-vision users on the exact screen where a user
           must judge whether their new password is acceptable.
Recommended fix: add a text-weight companion token (e.g. status.successText
           ≈ #1a7a39, 4.6:1 on #f7f1e9) and use it wherever #229e4b is TEXT,
           leaving #229e4b for dots/fills. NOT auto-fixed: inventing a new
           colour value is exactly the fabrication the design_spec's R1 finding
           refuses to do — same operator decision.
Risk of change: low; scoped to two spans, no layout impact.

--------------------------------------------------------------------------------
[accessibility] A11Y-3 — P1 — FORMS / ARIA — UNRESOLVED — REGRESSION FROM #3250
--------------------------------------------------------------------------------
File:      components/forms/ExpenseForm.tsx:203-212
           root cause components/ui/fields/DatePicker.tsx:194-206, 169, 180-182
Component: Expense Date field (ticket requirement R3)
Category:  forms / aria
Problem:   R3 rewired the Date field from display-only to user-editable and
           added `<label className="field-label" htmlFor="expenseDate">Date</label>`
           + `<DatePicker id="expenseDate" …>`. But DatePicker puts the `id` on
           its CALENDAR TRIGGER BUTTON (DatePicker.tsx:197), and that button
           already carries `aria-label="Open calendar"` (:198). Per the ARIA
           accessible-name computation, aria-label OUTRANKS a host-language
           <label>, so the button announces as "Open calendar, button" and the
           word "Date" is never spoken. The htmlFor association is inert.
           Worse, the field's CURRENT VALUE is rendered only in a
           non-focusable <span> (:180-182) plus a hidden input (:169) — so a
           screen-reader user has no labelled control that exposes either the
           field's name or its value.
Evidence:  DatePicker.tsx:194-206
             <button ref={triggerRef} type="button" id={id}
                     aria-label="Open calendar" aria-haspopup="dialog" …>
           ExpenseForm.tsx:203-212 (the new label + id wiring)
           jsx-a11y could not catch this: label-has-associated-control passed,
           because it only checks that htmlFor EXISTS, never that the target's
           computed name matches. Confirmed by command 3 returning no warning
           for these lines.
Why it matters: screen-reader users filling the expense form hit an unnamed
           control on a REQUIRED field. This is not a cosmetic gap — the field
           is unidentifiable and its value unreadable. Before #3250 the field
           was disabled and auto-filled, so it was inert; making it editable is
           what turned a dormant defect into a live barrier. That is why this is
           P1 and attributed to this branch.
           Same defect exists at components/ui/FilterBar.tsx:140-159, which uses
           the identical htmlFor -> DatePicker id pattern. ExpenseForm is the
           second adopter, so this is now the established pattern and will
           propagate.
Recommended fix: in DatePicker, stop putting the caller's `id` on the trigger.
           Give the control a real accessible name and value — e.g. render the
           trigger as role="combobox" with aria-haspopup="dialog", move `id` to
           it, DROP the hard-coded aria-label so the <label> wins, and expose
           the current value as the control's content instead of a sibling span.
           NOT auto-fixed: this changes DatePicker's public contract and the
           announced name of every date field in the app (ExpenseForm,
           OrderForm:147, FilterBar:155). Needs a deliberate change plus a
           re-run of the DatePicker/FilterBar tests, not a gate-time patch.
Risk of change: medium — three call sites, and OrderForm:147 passes no id at
           all, so the fallback naming path must be handled too.

--------------------------------------------------------------------------------
[accessibility] A11Y-4 — P2 — FORMS / ARIA — UNRESOLVED
--------------------------------------------------------------------------------
File:      components/forms/ExpenseForm.tsx:213
           root cause components/ui/fields/DatePicker.tsx:171-178
Component: Expense Date validation error
Category:  forms / aria
Problem:   #3250 added per-field error rendering for the date
           (`{state?.fieldErrors?.expenseDate && <p className="field-error">…}`)
           and an `invalid` prop on DatePicker. But `invalid` only applies a
           `border-status-danger` CLASS (DatePicker.tsx:176) — it sets no
           `aria-invalid` — and the error <p> has no `id`, so nothing is
           connected to the control via `aria-describedby`.
           Net effect: the error state is conveyed by BORDER COLOUR ALONE
           (WCAG 1.4.1) and the message is never announced (WCAG 3.3.1).
Evidence:  grep -rn "aria-describedby|aria-invalid" app components --include=*.tsx
           -> exactly ONE hit in the entire app:
              components/ui/fields/Listbox.tsx:209  aria-invalid={invalid || undefined}
           So Listbox handles invalid correctly and its sibling DatePicker does
           not — an inconsistency between two custom controls used side by side
           in the same form row. aria-describedby is used nowhere at all;
           TextField.tsx:58 and SelectField.tsx:54 render the same unassociated
           `<p className="field-error">`.
Why it matters: a screen-reader user submitting an invalid date gets no
           indication of which field failed or why; they are returned to a form
           that looks unchanged to them.
Recommended fix: add `describedById`/`aria-invalid` support to DatePicker
           (mirroring Listbox:209), give the error <p> an id, and wire
           aria-describedby. Then lift the same pattern into TextField/
           SelectField so the app has one error-association convention.
           NOT auto-fixed: app-wide pattern change across four field components.
Risk of change: low per component, but it is a cross-cutting edit that belongs
           in a dedicated change with test coverage.

--------------------------------------------------------------------------------
[accessibility] A11Y-5 — P2 — ARIA — AUTO-FIXED
--------------------------------------------------------------------------------
File:      components/ui/DataTable.tsx:51-63  (the component all 9 list screens
           render through; exercised by 8 of the 12 feature files)
Component: sortable column header
Category:  aria
Problem:   #3250's headline change makes ~14 previously-static columns sortable
           across 9 screens (items, projects, suppliers, uom, users, orders,
           expenses, expense-summary, expense-summary/[project]). The sort
           STATE, however, was rendered only as a glyph: SortIcon.tsx:12 wraps
           the whole thing in `aria-hidden="true"`, and the <th> carried no
           `aria-sort`. A screen-reader user could therefore activate sorting
           but never perceive which column was sorted or in which direction —
           a state conveyed purely visually (WCAG 1.3.1 / 4.1.2).
Evidence:  grep -rn "aria-sort" app components --include=*.tsx -> zero hits
           before this fix. SortIcon.tsx:12  <span … aria-hidden="true">
Why it matters: sorting is the ticket's primary new capability. Shipping it
           announced-to-nobody would mean the feature that #3250 exists to add
           is the feature assistive-tech users cannot use.
Fix applied: additive `aria-sort` on the <th> — "ascending"/"descending" on the
           active column, "none" on other sortable columns, absent on
           non-sortable ones. Zero visual change, zero API change, no new
           element. This is the "unambiguous ARIA addition" case the gate's
           Step 3 authorises.
Residual (NOT fixed, reported): the sort link's accessible name is still the
           bare header text ("Mobile", "Address") with no indication it sorts.
           Adding "Sort by X" changes the announced name of every header in the
           app and interacts with WCAG 2.5.3 label-in-name, so it is a design
           decision rather than a safe patch.
Risk of change: none observed — tsc clean, lint clean, no test delta
           (command 8).

--------------------------------------------------------------------------------
[accessibility] A11Y-6 — P2 — FORMS — AUTO-FIXED (partially)
--------------------------------------------------------------------------------
File:      components/forms/ExpenseForm.tsx:135 (Amount input),
           :127 (Type Listbox); root cause components/ui/RepeaterTable.tsx:60
Component: Expense Items repeater row controls
Category:  forms
Problem:   Repeater cells contain bare form controls with no <label> and no
           aria-label. The only name a sighted user gets is the column header,
           and that association was weak even implicitly: RepeaterTable.tsx:60
           rendered its <th> WITHOUT `scope="col"` (unlike DataTable.tsx:53,
           which sets it). Screen-reader users navigating the Expense Items
           table hit unnamed number/select controls repeated once per row.
Evidence:  real eslint run, command 3:
             components/forms/ExpenseForm.tsx:135  A control must be associated
             with a text label.  [jsx-a11y/control-has-associated-label]
           The Type Listbox at :127 has the same defect; the rule cannot see it
           because Listbox is a custom component, not a host element.
Fix applied (2 of 3):
           (a) ExpenseForm.tsx:135 — added `aria-label="Amount"`, mirroring the
               column header verbatim. Unambiguous accessible name; the gate's
               Step 3 names this exact case.
           (b) RepeaterTable.tsx:60 — added `scope="col"` to the header cell,
               matching DataTable.tsx:53. Additive, no visual change, and it
               strengthens implicit column-header association for every control
               in the table (Order Items as well as Expense Items).
Residual (NOT fixed, reported): the Type Listbox at ExpenseForm.tsx:127 still
           has no accessible name. components/ui/fields/Listbox.tsx:38-51 has NO
           `aria-label` prop, so naming it requires widening Listbox's public
           API — beyond "clearly safe", and it would also affect OrderForm's
           repeater. Same applies to the CreatableSelect cells.
Risk of change: none observed — tsc clean, lint clean, no test delta
           (command 8).

--------------------------------------------------------------------------------
[accessibility] A11Y-7 — P2 — SEMANTIC / CONTRAST — UNRESOLVED (BY OPERATOR
                                                                DECISION)
--------------------------------------------------------------------------------
File:      app/globals.css:48-50; used at app/(app)/orders/page.tsx:31
Component: .link
Category:  semantic-html / contrast
Problem:   `.link { @apply text-text hover:text-text; }` — a link with the same
           colour as body text, no underline, and no hover change. Inside a
           table cell the Order No link is visually indistinguishable from the
           plain text in neighbouring cells (WCAG 1.4.1: no non-colour cue, and
           here not even a colour cue).
Evidence:  globals.css:48-50; orders/page.tsx:31 renders the Order No through it.
           #3250 REMOVED the app's other `.link` usage —
           expense-summary/page.tsx dropped its "View Details" text link in
           favour of the Eye icon action (R5) — so orders/page.tsx:31 is now
           essentially the last consumer.
Why it matters: sighted users cannot tell the cell is actionable; the underlying
           element is a real <a>, so keyboard and screen-reader users are fine.
           This is a sighted-discoverability defect, not an AT barrier — hence
           P2 not P1.
Recommended fix: give .link a non-colour affordance (hover:underline at minimum).
           DELIBERATELY NOT FIXED: globals.css:42-47 documents that the blue+
           underlined treatment was previously added to fix a "rows don't look
           clickable" report and then "reverted on explicit request". Re-applying
           it at gate time would silently undo a recorded operator decision.
           Escalating, not patching.
Risk of change: none technically; the risk is process — it contradicts a
           standing instruction.

--------------------------------------------------------------------------------
[design-system] DS-1 — P2 — COLOURS — AUTO-FIXED
--------------------------------------------------------------------------------
File:      components/forms/ResetPasswordForm.tsx:154
Component: strength-meter "Strength" caption
Problem:   `text-[rgb(86,86,86)]` is an arbitrary value that EXACTLY duplicates
           an existing theme token: tailwind.config.ts:28 defines
           text.subtle = #565656 = rgb(86,86,86). Same colour, two spellings.
Why it matters: the whole point of tailwind.config.ts:23-29's provenance
           comments is that text.subtle is a named, sourced design decision
           (filter-row labels, info-card labels). An arbitrary duplicate means
           a future retune of text.subtle silently misses this caption.
Fix applied: `text-[rgb(86,86,86)]` -> `text-text-subtle`. Byte-identical
           rendered colour; this is the gate's canonical "swap a raw value for
           the matching token" case.
Expected impact: zero visual change; one fewer arbitrary value in the codebase.
Risk of change: none — tsc clean, lint clean, no test delta (command 8).

--------------------------------------------------------------------------------
[design-system] DS-2 — P2 — COLOURS — UNRESOLVED
--------------------------------------------------------------------------------
File:      components/forms/ResetPasswordForm.tsx:173, 180
Component: PASSWORD POLICY tick icons
Problem:   The inline SVGs hard-code `stroke="rgb(34,158,75)"` — which is
           EXACTLY status.success (#229e4b, tailwind.config.ts:77) — and
           `stroke="rgb(163,163,163)"`. The sibling <span> on line 176 styles
           the very same met/unmet state with `text-status-success` vs
           `text-[rgb(163,163,163)]`. One visual concept, two implementations,
           three lines apart.
Why it matters: exactly the drift this skill exists to catch — if
           status.success is retuned, the label changes colour and the tick
           beside it does not.
Recommended fix: drop the `stroke` attribute and drive the icon from the text
           colour (`stroke="currentColor"` + the existing conditional text
           class), or move to `className={clsx(rulesMet[i] ? "stroke-status-success" : …)}`.
           NOT auto-fixed: it is a markup restructure (attribute -> conditional
           className), not a literal token swap, and the unmet branch has no
           token to swap TO (see DS-3 / A11Y-1).
Expected impact: none visually today; removes a future drift source.
Risk of change: low, but touches the same lines A11Y-1/A11Y-2 must change —
           best done in one pass once the operator settles the grey.

--------------------------------------------------------------------------------
[design-system] DS-3 — P2 — COLOURS / UNMAPPED TOKENS — UNRESOLVED
--------------------------------------------------------------------------------
File:      components/forms/ResetPasswordForm.tsx:160, 173, 176, 180, 183
Component: PASSWORD POLICY card + strength meter
Problem:   rgb(163,163,163) appears 4x and rgb(230,230,230) 1x with no token
           behind either. These are not one-off decorative values: 163,163,163
           IS the "unmet policy rule" state — a recurring design decision
           applied to six rows and their six icons.
Evidence:  grep sweep, command 4 — these five lines are the ONLY arbitrary
           colours in all 12 feature files.
Why it matters: the design_spec input names these two values explicitly under
           "Unmapped tokens" and defers them ("pre-existing, out of #3250's
           scope, flagged for a future pass"). This gate CONFIRMS that call is
           still accurate — and records that the deferral now also carries a
           WCAG P1 (A11Y-1), which raises its priority above "future pass".
Recommended fix: resolve together with A11Y-1 — one operator decision produces
           both the accessible value and the token name (e.g. text.disabled +
           border.track).
Expected impact: n/a until decided.
Risk of change: n/a.

--------------------------------------------------------------------------------
[design-system] DS-4 — P2 — COMPONENTS — UNRESOLVED (KNOWN BLOCKER, CORRECTLY
                                                     NOT PAPERED OVER)
--------------------------------------------------------------------------------
File:      components/ui/StatusBadge.tsx (unchanged on this branch)
Component: StatusBadge — ticket requirement R1
Problem:   R1 asks for a bordered/padded status CHIP with per-tone backgrounds.
           It is NOT implemented. Verified: StatusBadge.tsx is not in
           feature_files, does not appear in `git diff 4e6b259..HEAD`, and
           still renders the 6px dot + text treatment (a 1.5x1.5 rounded-full
           span + label).
Why it matters: the design_spec input and implementation_plan.F2 both classify
           R1 as BLOCKED — only status.successSubtle (#e6f7ec) is a measured
           tint; warning/danger/neutral/info subtles have no source in either
           bundle, so building the chip means inventing 4 colours.
           From a pure design-CONSISTENCY standpoint the branch is CORRECT: the
           dot+text treatment is applied uniformly by all 9 list screens and 1
           detail screen, and the audit confirms no screen has quietly
           hand-rolled a chip with ad-hoc utility classes to satisfy R1. This is
           recorded as an open requirement, not as inconsistency in what shipped.
Recommended fix: operator decision — either source the 4 missing tints or
           formally descope R1. Nothing for this gate to fix.
Expected impact: n/a.
Risk of change: fabricating the 4 tones would be exactly the failure mode the
           design_spec refused; do not let a later gate "helpfully" do it.

--------------------------------------------------------------------------------
[design-system] DS-5 — P3 — COMPONENTS — UNRESOLVED (NEEDS A PRODUCT CALL)
--------------------------------------------------------------------------------
File:      app/(app)/expenses/page.tsx:23-28 (column set) vs :55-63 (filters)
Component: Expenses list
Problem:   #3250 deleted the Status column and the StatusBadge import from the
           Expenses list, but LEFT the Status filter in the toolbar. A user can
           filter expenses to "Rejected" and then see no indication anywhere in
           the resulting table that the rows are rejected. Every other list
           screen (Orders + all 5 admin masters) still renders a Status column.
Evidence:  git diff 4e6b259..HEAD shows both the `{ key: "status", … StatusBadge }`
           column and the `import { StatusBadge }` line removed; the
           `{ name: "status", label: "Status", type: "select", options: [PENDING,
           APPROVED, …] }` filter entry is untouched.
           tests/expenses-page.test.tsx still asserts the removed column and
           fails as a result (command 8) — evidence the removal was intentional
           in the code but not carried through the rest of the change.
Why it matters: a filter control whose effect is invisible is a UX dead end, and
           Expenses is now the only list that hides a status it can filter on.
Recommended fix: either restore the Status column or remove the Status filter —
           whichever matches the ticket's actual intent. NOT auto-fixed: the
           design_spec lists R1–R6 and none of them covers this removal, so the
           intent cannot be read off the spec.
Expected impact: restores cross-screen consistency.
Risk of change: low, but it is a product decision either way.

--------------------------------------------------------------------------------
[design-system] DS-6 — P3 — COMPONENTS — UNRESOLVED (LOW VALUE)
--------------------------------------------------------------------------------
File:      app/(app)/expense-summary/ExpenseSummaryRowActions.tsx:9
           vs components/ui/RowActions.tsx:33 vs
           app/(app)/expenses/ExpenseRowActions.tsx:12
Component: row icon-action link — three variants of one pattern
Problem:   The same "icon-only row action" concept is spelled three ways:
             new (this ticket): "inline-flex p-1.5 -m-1.5 text-text"
             RowActions view:   "p-1.5 -m-1.5 text-text"        (no inline-flex)
             ExpenseRowActions: "inline-flex p-1.5 -m-1.5 text-status-info"
           Colour differences are intentional and sourced (view=text,
           edit=status.info, delete=status.danger, per the #3248 spec comments).
           The `inline-flex` presence/absence is not.
Why it matters: marginal — the new file otherwise reuses the exact documented
           pattern, the correct token, and the same lucide Eye icon, which is
           precisely what the design_spec asked R5 to do.
Recommended fix: add `inline-flex` to RowActions.tsx:33 for uniformity, or
           extract the shared class string. Genuinely optional.
Expected impact: cosmetic consistency only.
Risk of change: `inline-flex` alters the anchor's box model slightly; not worth
           churning three files at gate time.

--------------------------------------------------------------------------------
[design-system] DS-7 — P3 — TYPOGRAPHY — UNRESOLVED
--------------------------------------------------------------------------------
File:      components/forms/ResetPasswordForm.tsx:51
Component: PasswordField label
Problem:   The label is hand-rolled as `text-sm font-semibold text-text` inside
           a `gap-1.5` flex column, instead of the shared `.field-label`
           (globals.css:34-36: `text-sm font-medium text-text mb-1`) that every
           other form label in the app uses — including ExpenseForm.tsx:203 and
           :266 in this same feature-file set. Same UI role, two weights
           (semibold vs medium) and two spacing mechanisms (gap vs mb).
Why it matters: form labels are the highest-frequency repeated element in the
           app; a second variant is how a type scale starts to drift.
Recommended fix: use `.field-label`, OR — if the design reference genuinely
           specifies semibold for this screen — add a documented
           `.field-label-strong` rather than an inline one-off.
           NOT auto-fixed: the file header comment (:79-83) says the layout was
           matched against the design reference's "RESET PASSWORD" block, so the
           semibold may be deliberate and sourced. Cannot confirm without the
           missing docs/specs/ticket-3250-design.md.
Expected impact: one fewer label variant.
Risk of change: low, but it is a visible weight change if the design did
           specify semibold.

--------------------------------------------------------------------------------
[design-system] DS-8 — P3 — TYPOGRAPHY — UNRESOLVED
--------------------------------------------------------------------------------
File:      components/forms/ResetPasswordForm.tsx:154, 170, 176, 183;
           also components/forms/ExpenseForm.tsx:174
Component: 13px body/caption text
Problem:   `text-[13px]` is an arbitrary size used 5x in one file and again in
           ExpenseForm's attachment empty state. Tailwind's scale has no 13px
           step and tailwind.config.ts extends colours only — there is no
           fontSize extension at all.
Why it matters: 13px is clearly a recurring design decision here (card body
           copy, captions), not a one-off tweak, which is the skill's own test
           for when a token is warranted.
Recommended fix: add a `fontSize` extension, e.g. `xs2: ["13px", "18px"]`, and
           replace the arbitrary values. NOT auto-fixed: adding a scale step is
           a design-system change with app-wide reach, and it needs a line-height
           decision that no available source specifies.
Expected impact: makes the 13px step retunable in one place.
Risk of change: low if the line-height matches what the arbitrary value
           currently inherits; needs a visual check.

--------------------------------------------------------------------------------
[design-system] DS-9 — P3 — COMPONENTS — NO ACTION (INFORMATIONAL)
--------------------------------------------------------------------------------
File:      app/(app)/expense-summary/page.tsx:21;
           app/(app)/expenses/page.tsx:29
Component: sortable-column coverage
Problem:   #3250 made essentially every data column sortable, with two
           exceptions: "Total Expenses" on Expense Summary and "Total Amount"
           on Expenses. Within a single table this reads as an inconsistent
           affordance (most headers show a sort glyph, one does not).
Assessment: both exceptions are computed aggregates
           (`r.total.toFixed(2)` / `r.totalAmount.toFixed(2)`) derived in the
           query layer, not sortable DB columns, so the omission is coherent
           and the two screens agree with each other. Reported for completeness,
           NOT flagged as a defect — the alternative (a sort link that silently
           does nothing) would be strictly worse.
Recommended fix: none. If aggregate sorting is wanted later it is a data-layer
           change, not a design one.
Expected impact: n/a.
Risk of change: n/a.

================================================================================
CHECKED AND CLEAN (recorded per both skills' "note what was handled correctly")
================================================================================
- COLOURS: 11 of the 12 feature files contain ZERO arbitrary colour values
  (command 4). All status tones, borders, accents and text greys resolve to
  named tokens in tailwind.config.ts, each carrying a provenance comment back
  to a measured design source. This is a genuinely well-tokenised codebase; the
  colour findings above are confined to one file.
- FOCUS: all 6 `outline-none` occurrences are paired with a replacement
  focus-visible style (command 5). DatePicker.tsx:272 in particular pairs
  `focus:outline-none` with `focus-visible:ring-2 focus-visible:ring-accent`.
  The new ExpenseSummaryRowActions link removes no outline, so it keeps the UA
  default focus ring. No focus-suppression defects.
- KEYBOARD: exactly one onClick on a non-interactive element (Modal backdrop),
  correctly aria-hidden and duplicated by an Escape handler (command 6).
  DatePicker implements full roving-tabindex grid navigation, Escape-to-close
  and focus-return-to-trigger (DatePicker.tsx:98-151) — well above the usual bar.
- NON-TEXT CONTRAST: every StatusBadge dot tone and every row-action icon meets
  WCAG 1.4.11 3:1 (command 7). The dots are additionally aria-hidden with an
  adjacent text label, so status is never colour-only.
- DISABLED STATES: DatePicker sets a real `disabled` attribute on the trigger
  (:201) rather than only styling it, so it leaves the tab order correctly.
  Its 4.19:1 disabled-state text contrast is exempt under WCAG 1.4.3's
  inactive-component exception.
- LIVE REGIONS: Toast.tsx:28-30 correctly uses role="status" + aria-live="polite"
  with a properly labelled dismiss button. #3250's ResetPasswordForm change
  removed only the SUCCESS toast path, which is correct — success now redirects
  to /login server-side, so no announcement is lost.
- ICON-ONLY CONTROLS: every icon button/link in the audited paths has an
  accessible name (aria-label) and an aria-hidden icon —
  ExpenseSummaryRowActions.tsx:9, RowActions.tsx:33/38/44,
  ExpenseRowActions.tsx:12, RepeaterTable.tsx:98, Toast.tsx:38,
  ResetPasswordForm.tsx:68, DatePicker.tsx:186/198/221/229.
- TABLE SEMANTICS: DataTable renders real <table>/<th scope="col"> markup
  (DataTable.tsx:51-53); RepeaterTable now matches after the DS/A11Y-6 fix.
- DARK MODE: not applicable. `dark:` appears nowhere in app/ or components/ and
  there is no theme toggle, so the absence of dark-mode token variants is not a
  gap.

================================================================================
AUTO-FIXES APPLIED (gate Step 3) — 4
================================================================================
  1. components/forms/ResetPasswordForm.tsx:154   [design-system DS-1]
       text-[rgb(86,86,86)]  ->  text-text-subtle
  2. components/ui/DataTable.tsx:51-63            [accessibility A11Y-5]
       + aria-sort={isActive ? (currentDir === "desc" ? "descending"
                                                     : "ascending")
                             : col.sortable ? "none" : undefined}
  3. components/forms/ExpenseForm.tsx:135         [accessibility A11Y-6a]
       + aria-label="Amount"
  4. components/ui/RepeaterTable.tsx:60           [accessibility A11Y-6b]
       + scope="col"

All four are additive or value-identical: zero rendered-pixel change, zero
public-API change, zero behaviour change.

Verification after the fixes (command 8):
  npx tsc --noEmit                          exit 0, clean
  npx next lint --dir app --dir components  "✔ No ESLint warnings or errors"
  npx vitest run                            732 passed / 8 failed (100 files)
  stash-and-rerun control at untouched HEAD  same 8 failures
  => the 8 failures are pre-existing on this branch and unrelated to this gate.

Everything else was left as a reported finding, per Step 3, because it needs a
design judgment (a colour value that does not exist yet: A11Y-1, A11Y-2, DS-3),
a component API change (A11Y-3, A11Y-4, A11Y-6 residual), a product decision
(DS-5), or contradicts a recorded operator instruction (A11Y-7).

================================================================================
VERDICT
================================================================================
gate_status = FAIL.

Per the gate's rule, PASS requires zero unresolved P1 findings across BOTH
audits, and any unresolved accessibility P1 blocks regardless of the
design-system result. Three remain:

  A11Y-1  2.25:1 contrast on the password-policy rules   (WCAG 2.1 AA 1.4.3)
  A11Y-2  3.09:1 / 3.47:1 contrast on success-state text (WCAG 2.1 AA 1.4.3)
  A11Y-3  Expense Date field has no accessible name      (WCAG 4.1.2) —
          a regression this branch introduced by making the field editable

The design-system audit on its own would PASS: zero P1s, the token system is
clean and consistently applied across 11 of 12 feature files, R5 reuses the
documented pattern exactly, and R1 was correctly left blocked rather than
satisfied with invented colours. It is the accessibility half that fails —
which is the reason the gate keeps the two audits merged but forbids
downgrading contrast/ARIA findings on visual-match grounds.

A11Y-3 is the finding to action first: it is the only P1 caused by this
branch's own change, and it makes a required field on the Expense form
unnameable to screen readers.