@saasicat/ui-vue 0.24.0 → 0.24.2

package/dist/{chunk-VYMTWCTT.js → chunk-D74FFCCP.js}

@@ -665,10 +665,11 @@ var WELL_KNOWN = {
 function identityAccentFor(key, overrides = {}, index = -1) {
   return overrides[key] ?? WELL_KNOWN[key] ?? identityAccentAt(index);
 }
+var READABLE_ACCENT_SHARE = 50;
 function identityChipStyle(accent) {
   return {
     background: `color-mix(in srgb, ${accent} 8%, transparent)`,
-    color: accent,
+    color: `color-mix(in srgb, ${accent} ${READABLE_ACCENT_SHARE}%, var(--sa-color-fg-heading))`,
     borderColor: `color-mix(in srgb, ${accent} 20%, transparent)`
   };
 }

package/dist/client/index.cjs

@@ -3899,10 +3899,11 @@ var WELL_KNOWN = {
 function identityAccentFor(key, overrides = {}, index = -1) {
   return overrides[key] ?? WELL_KNOWN[key] ?? identityAccentAt(index);
 }
+var READABLE_ACCENT_SHARE = 50;
 function identityChipStyle(accent) {
   return {
     background: `color-mix(in srgb, ${accent} 8%, transparent)`,
-    color: accent,
+    color: `color-mix(in srgb, ${accent} ${READABLE_ACCENT_SHARE}%, var(--sa-color-fg-heading))`,
     borderColor: `color-mix(in srgb, ${accent} 20%, transparent)`
   };
 }

package/dist/client/index.d.cts

@@ -436,13 +436,25 @@ declare function identityAccentAt(index: number): string;
 declare function identityAccentFor(key: string, overrides?: Readonly<Record<string, string>>, index?: number): string;
 /**
  * The three-part chip style every one of these sites was hand-rolling: a wash
- * of the accent, the accent as text, a firmer edge of it.
+ * of the accent, a readable rendering of the accent as text, a firmer edge.
  *
  * `color-mix()` rather than the `accent + '15'` string concatenation it
  * replaces. That trick only worked on a six-digit hex — it silently produced
  * garbage for `rgb()`, for a named colour and for anything a consumer might
  * reasonably pass — and it could never have worked for a `var()`, which is why
  * these palettes could not follow the theme in the first place.
+ *
+ * The text is a mix rather than the accent itself. A `var(--sa-color-identity-N)`
+ * would not need that — the ramp has a value per theme, so it already suits both
+ * surfaces. A concrete hex has one value for both, and a concrete hex is what
+ * reaches here from a stored plan colour or from a consumer's `planAccents`; on
+ * whichever theme it lands nearest the surface it fades into its own wash.
+ *
+ * Callers may still override any of the three. `PromoCodeDialogFields` replaces
+ * the border with the plan's undiluted colour, and `PlanDiffCard` takes only the
+ * wash and the edge — an inline style beats the class beneath it, which is how
+ * the chip kept its own unreadable foreground through a fix applied to the
+ * selected-state rules around it.
  */
 declare function identityChipStyle(accent: string): Record<string, string>;
 

package/dist/client/index.d.ts

@@ -436,13 +436,25 @@ declare function identityAccentAt(index: number): string;
 declare function identityAccentFor(key: string, overrides?: Readonly<Record<string, string>>, index?: number): string;
 /**
  * The three-part chip style every one of these sites was hand-rolling: a wash
- * of the accent, the accent as text, a firmer edge of it.
+ * of the accent, a readable rendering of the accent as text, a firmer edge.
  *
  * `color-mix()` rather than the `accent + '15'` string concatenation it
  * replaces. That trick only worked on a six-digit hex — it silently produced
  * garbage for `rgb()`, for a named colour and for anything a consumer might
  * reasonably pass — and it could never have worked for a `var()`, which is why
  * these palettes could not follow the theme in the first place.
+ *
+ * The text is a mix rather than the accent itself. A `var(--sa-color-identity-N)`
+ * would not need that — the ramp has a value per theme, so it already suits both
+ * surfaces. A concrete hex has one value for both, and a concrete hex is what
+ * reaches here from a stored plan colour or from a consumer's `planAccents`; on
+ * whichever theme it lands nearest the surface it fades into its own wash.
+ *
+ * Callers may still override any of the three. `PromoCodeDialogFields` replaces
+ * the border with the plan's undiluted colour, and `PlanDiffCard` takes only the
+ * wash and the edge — an inline style beats the class beneath it, which is how
+ * the chip kept its own unreadable foreground through a fix applied to the
+ * selected-state rules around it.
  */
 declare function identityChipStyle(accent: string): Record<string, string>;
 

package/dist/client/index.js

@@ -34,7 +34,7 @@ import {
   resolvePlans,
   todayIsoDate,
   trimTrailingSlashes
-} from "../chunk-VYMTWCTT.js";
+} from "../chunk-D74FFCCP.js";
 import {
   DEFAULT_SA_LOCALE,
   SA_INTL_LOCALES,

package/dist/index.cjs

@@ -3984,10 +3984,11 @@ var WELL_KNOWN = {
 function identityAccentFor(key, overrides = {}, index = -1) {
   return overrides[key] ?? WELL_KNOWN[key] ?? identityAccentAt(index);
 }
+var READABLE_ACCENT_SHARE = 50;
 function identityChipStyle(accent) {
   return {
     background: `color-mix(in srgb, ${accent} 8%, transparent)`,
-    color: accent,
+    color: `color-mix(in srgb, ${accent} ${READABLE_ACCENT_SHARE}%, var(--sa-color-fg-heading))`,
     borderColor: `color-mix(in srgb, ${accent} 20%, transparent)`
   };
 }

package/dist/index.js

@@ -34,7 +34,7 @@ import {
   resolvePlans,
   todayIsoDate,
   trimTrailingSlashes
-} from "./chunk-VYMTWCTT.js";
+} from "./chunk-D74FFCCP.js";
 import {
   SA_LOCALE_STORAGE_KEY,
   SA_THEME_KEY,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@saasicat/ui-vue",
-  "version": "0.24.0",
+  "version": "0.24.2",
   "description": "Vue 3 components, resource clients and composables for the SuperAdmin UI shell. Provides boot and manifest loaders, navigation, actions and standard pages.",
   "type": "module",
   "main": "./dist/index.cjs",
@@ -61,7 +61,7 @@
     "src"
   ],
   "dependencies": {
-    "@saasicat/types": "^0.24.0"
+    "@saasicat/types": "^0.24.2"
   },
   "peerDependencies": {
     "pinia": "^2.0.0 || ^3.0.0",

package/src/client/identity-accents.ts

@@ -110,20 +110,58 @@ export function identityAccentFor(
     return overrides[key] ?? WELL_KNOWN[key] ?? identityAccentAt(index);
 }
 
+/**
+ * How much of the accent survives when the accent becomes TEXT.
+ *
+ * The remainder comes from `--sa-color-fg-heading`, which is near-black in the
+ * light theme and near-white in the dark one. So a single expression darkens
+ * the accent in one theme and lightens it in the other, which is the same move
+ * `--sa-color-accent-strong` makes for the brand.
+ *
+ * It is not the brand's 82 %, and the difference is the point. The brand is one
+ * curated colour, checked by a person against both surfaces. This helper's
+ * input is uncontrolled: a plan's stored hex, a consumer's `planAccents`, a
+ * colour an operator picked out of a swatch. A share tuned for one colour is
+ * not a bound over all of them, and 82 % measurably is not one — three of the
+ * six colours the promotion editor itself stores stay under 3:1 on a raised
+ * dark card (2.81 to 2.98), and a light brand pick such as lime-400 only
+ * reaches 2.03:1 on a raised light one.
+ *
+ * At half, every colour in sRGB stays at or above 3.3:1 in light and 3.7:1 in
+ * dark, both extremes being the degenerate accents — an accent that already IS
+ * the theme's own extreme cannot be pushed further from the surface, so pure
+ * white decides the light bound and pure black the dark one. That is a bound
+ * over the whole cube rather than over a sample, which is what an uncontrolled
+ * input needs. `theme-role-contrast` measures it and fails if this share rises.
+ */
+const READABLE_ACCENT_SHARE = 50;
+
 /**
  * The three-part chip style every one of these sites was hand-rolling: a wash
- * of the accent, the accent as text, a firmer edge of it.
+ * of the accent, a readable rendering of the accent as text, a firmer edge.
  *
  * `color-mix()` rather than the `accent + '15'` string concatenation it
  * replaces. That trick only worked on a six-digit hex — it silently produced
  * garbage for `rgb()`, for a named colour and for anything a consumer might
  * reasonably pass — and it could never have worked for a `var()`, which is why
  * these palettes could not follow the theme in the first place.
+ *
+ * The text is a mix rather than the accent itself. A `var(--sa-color-identity-N)`
+ * would not need that — the ramp has a value per theme, so it already suits both
+ * surfaces. A concrete hex has one value for both, and a concrete hex is what
+ * reaches here from a stored plan colour or from a consumer's `planAccents`; on
+ * whichever theme it lands nearest the surface it fades into its own wash.
+ *
+ * Callers may still override any of the three. `PromoCodeDialogFields` replaces
+ * the border with the plan's undiluted colour, and `PlanDiffCard` takes only the
+ * wash and the edge — an inline style beats the class beneath it, which is how
+ * the chip kept its own unreadable foreground through a fix applied to the
+ * selected-state rules around it.
  */
 export function identityChipStyle(accent: string): Record<string, string> {
     return {
         background: `color-mix(in srgb, ${accent} 8%, transparent)`,
-        color: accent,
+        color: `color-mix(in srgb, ${accent} ${READABLE_ACCENT_SHARE}%, var(--sa-color-fg-heading))`,
         borderColor: `color-mix(in srgb, ${accent} 20%, transparent)`,
     };
 }

package/src/components/bundle-editor/BundleFeaturesEditor.vue

@@ -208,7 +208,12 @@ function onToggle(featureKey: string): void {
     margin-left: 4px;
 }
 .bd-feature-pill.on .bd-feature-key {
-    color: var(--sa-color-accent);
+    /* `-strong`, not the bare accent: the pill's `on` surface is a 24 % tint of
+     * blue over the dark card, and the brand does not change between themes —
+     * 2.92:1 there. The selected states around this one were moved to
+     * `-strong` already; this descendant was missed because it sets a colour
+     * and no background, which is a shape no contrast check reads. */
+    color: var(--sa-color-accent-strong);
 }
 .bd-feature-pill.overlap .bd-feature-key {
     color: var(--sa-color-negative-fg);

package/src/components/dialogs/PilotCreateDialog.vue

@@ -170,7 +170,7 @@
                                 >
                                     <span
                                         class="pl-plan-opt__dot"
-                                        :style="{ background: p.color ?? '#94a3b8' }"
+                                        :style="{ background: p.color ?? IDENTITY_NEUTRAL }"
                                     />
                                     <div class="pl-plan-opt__text">
                                         <span class="pl-plan-opt__key">{{ p.value }}</span>
@@ -263,6 +263,7 @@
 <script setup lang="ts">
 import { computed, reactive, ref, watch } from 'vue';
 import MfaPromptDialog from '../MfaPromptDialog.vue';
+import { IDENTITY_NEUTRAL } from '../../client/identity-accents.js';
 import { formatMessage } from '../../client/i18n/format.js';
 import { useSaMessages } from '../../vue/use-super-admin-i18n.js';
 import type { PilotCopy, PilotCreatePayload, PilotCreateResult } from './types.js';

package/src/components/dialogs/PilotEditDialog.vue

@@ -46,7 +46,7 @@
                         >
                             <span
                                 class="pl-plan-opt__dot"
-                                :style="{ background: p.color ?? '#94a3b8' }"
+                                :style="{ background: p.color ?? IDENTITY_NEUTRAL }"
                             />
                             <div class="pl-plan-opt__text">
                                 <span class="pl-plan-opt__key">{{ p.value }}</span>
@@ -148,6 +148,7 @@
 <script setup lang="ts">
 import { computed, reactive, ref, watch } from 'vue';
 import MfaPromptDialog from '../MfaPromptDialog.vue';
+import { IDENTITY_NEUTRAL } from '../../client/identity-accents.js';
 import { formatMessage } from '../../client/i18n/format.js';
 import { useSaMessages } from '../../vue/use-super-admin-i18n.js';
 import type { PilotRow } from '../../pages-standard/PilotsPage.vue';

package/src/components/dialogs/PromoCodeDialogFields.vue

@@ -85,7 +85,10 @@
                     :style="planChipStyle(p)"
                     @click="togglePlan(p.key)"
                 >
-                    <span class="pc-plan-opt__mark" :style="{ background: p.color ?? '#64748b' }" />
+                    <span
+                        class="pc-plan-opt__mark"
+                        :style="{ background: p.color ?? IDENTITY_NEUTRAL }"
+                    />
                     {{ p.label }}
                 </button>
             </div>
@@ -101,13 +104,13 @@
         <div class="pc-grid pc-grid--2">
             <div class="pc-field">
                 <div class="pc-field__label">{{ msg.form.durationLabel }}</div>
-                <div class="pc-dur">
+                <div class="pc-seg pc-seg--fill">
                     <button
                         v-for="o in durationOptions"
                         :key="o.k"
                         type="button"
-                        class="pc-dur-opt"
-                        :class="{ 'pc-dur-opt--active': form.durationType === o.k }"
+                        class="pc-seg-opt"
+                        :class="{ 'pc-seg-opt--active': form.durationType === o.k }"
                         @click="form.durationType = o.k"
                     >
                         {{ o.label }}
@@ -161,13 +164,13 @@
         <div v-if="mode === 'edit'" class="pc-grid pc-grid--2">
             <div class="pc-field">
                 <div class="pc-field__label">{{ common.status }}</div>
-                <div class="pc-status">
+                <div class="pc-seg pc-status">
                     <button
                         v-for="o in statusOptions"
                         :key="o.k"
                         type="button"
-                        class="pc-status-opt"
-                        :class="{ 'pc-status-opt--active': form.status === o.k }"
+                        class="pc-seg-opt"
+                        :class="{ 'pc-seg-opt--active': form.status === o.k }"
                         @click="form.status = o.k"
                     >
                         <q-icon :name="o.icon" size="14px" />
@@ -265,7 +268,7 @@
 
 <script setup lang="ts">
 import { computed } from 'vue';
-import { identityChipStyle } from '../../client/identity-accents.js';
+import { IDENTITY_NEUTRAL, identityChipStyle } from '../../client/identity-accents.js';
 import { formatMessage } from '../../client/i18n/format.js';
 import { useSaMessages } from '../../vue/use-super-admin-i18n.js';
 import type { PromoCodeDurationType, PromoCodePlanOption, PromoCodeValueType } from './types.js';
@@ -595,8 +598,8 @@ textarea.pc-input {
 
 .pc-plan-opt--on {
     border-color: var(--sa-color-accent);
-    background: var(--sa-color-accent-surface);
-    color: var(--sa-color-accent);
+    background: var(--sa-color-accent-surface-strong);
+    color: var(--sa-color-accent-strong);
 }
 
 .pc-plan-opt__mark {
@@ -605,13 +608,25 @@ textarea.pc-input {
     border-radius: 50%;
 }
 
-.pc-dur {
+/* One segmented control for both the duration and the status row. They are the
+ * same thing — a row of buttons of which one is chosen — and the status row had
+ * NO rules at all, so it rendered as raw browser buttons: white boxes on a dark
+ * dialog. Sharing the recipe is what makes the two look alike without either
+ * restating it. */
+.pc-seg {
     display: flex;
     gap: 4px;
 }
-
-.pc-dur-opt {
+/* The duration options divide the row; the status options size to their label. */
+.pc-seg--fill .pc-seg-opt {
     flex: 1;
+}
+
+.pc-seg-opt {
+    display: inline-flex;
+    align-items: center;
+    justify-content: center;
+    gap: var(--sa-gap-inline);
     border: 1px solid var(--sa-color-border);
     background: var(--sa-color-bg-surface);
     border-radius: 7px;
@@ -621,10 +636,19 @@ textarea.pc-input {
     color: var(--sa-color-fg-secondary);
 }
 
-.pc-dur-opt--active {
+.pc-seg-opt:hover {
+    border-color: var(--sa-color-border-strong);
+}
+
+/* `-accent-strong` on `-surface-strong`, which is what the design guide
+ * prescribes for accent text on a tint. The chosen option used to pair plain
+ * `--sa-color-accent` with the 8 % wash of itself: in dark mode that is the
+ * brand blue on a near-black blue, and the selected state was the one you could
+ * read least — the opposite of what selecting something should do. */
+.pc-seg-opt--active {
     border-color: var(--sa-color-accent);
-    background: var(--sa-color-accent-surface);
-    color: var(--sa-color-accent);
+    background: var(--sa-color-accent-surface-strong);
+    color: var(--sa-color-accent-strong);
 }
 
 .pc-check {

package/src/components/plan/PromoCodeInput.vue

@@ -107,7 +107,7 @@ function remove(): void {
     border: 1px dashed var(--sa-color-accent-border);
     background: var(--sa-color-accent-surface-soft);
     border-radius: 10px;
-    color: var(--sa-color-accent);
+    color: var(--sa-color-accent-strong);
     font-weight: 700;
     font-size: var(--sa-text-sm);
     cursor: pointer;

package/src/components/plan-detail/PlanDetail.vue

@@ -825,23 +825,61 @@ async function executeTerminate(): Promise<void> {
     );
     border-color: var(--sa-color-border);
 }
+/* The marker block at the head of a diff row.
+ *
+ * Every rule below carries BOTH halves of its pair, and that is deliberate:
+ * the geometry used to live here and the background one rule further down,
+ * which made neither rule judgeable on its own. `theme-role-contrast` needs a
+ * background and a colour in the same body to measure anything, so the split
+ * hid `--sa-color-fg-on-accent` on `--sa-color-positive-strong` — white on
+ * green-500, 2.54:1, in BOTH themes — for as long as the component existed.
+ *
+ * A tint plus the tone's `-fg`, not a solid plus white: `-strong` is the rung
+ * chosen to read as a COLOUR against its theme's surface, which puts it in the
+ * middle of the lightness range — and nothing reads on the middle. That is
+ * what `<tone>-fg` and `-surface-strong` are for. */
 .pd-diff-icon {
     width: 32px;
     align-self: stretch;
     display: grid;
     place-items: center;
     flex: 0 0 32px;
-    color: var(--sa-color-fg-on-accent);
+    background: var(--sa-color-bg-sunken);
+    color: var(--sa-color-fg-body);
     font: 700 var(--sa-text-lg) var(--sa-font-body);
 }
 .pd-diff-row.add .pd-diff-icon {
-    background: var(--sa-color-positive-strong);
+    background: var(--sa-color-positive-surface-strong);
+    color: var(--sa-color-positive-fg);
 }
 .pd-diff-row.rm .pd-diff-icon {
-    background: var(--sa-color-negative-strong);
+    background: var(--sa-color-negative-surface-strong);
+    color: var(--sa-color-negative-fg);
 }
+/* Unchanged, and deliberately not brought into line with the two above: it was
+ * already readable (14.6:1) and `--sa-color-bg-sunken` is what the `mod` row
+ * itself starts its gradient with, so a neutral tint here would leave the
+ * marker with almost nothing to stand against in the light theme. It only
+ * gains the foreground it was already inheriting, so the rule can be read. */
 .pd-diff-row.mod .pd-diff-icon {
     background: var(--sa-color-inverse-surface);
+    color: var(--sa-color-inverse-fg);
+}
+/* The single-version listing marks WHAT a row is rather than what changed, so
+ * it reads the catalogue-entity roles. These three were the last colour
+ * literals in a template: `style="background: #f59e0b"` and friends, painted
+ * white by the base rule above at 2.15:1, 2.77:1 and 4.23:1. */
+.pd-diff-row.plain .pd-diff-icon.feature {
+    background: var(--sa-color-feature-surface);
+    color: var(--sa-color-feature-fg);
+}
+.pd-diff-row.plain .pd-diff-icon.quota {
+    background: var(--sa-color-quota-surface);
+    color: var(--sa-color-quota-fg);
+}
+.pd-diff-row.plain .pd-diff-icon.bundle {
+    background: var(--sa-color-bundle-surface);
+    color: var(--sa-color-bundle-fg);
 }
 .pd-diff-body {
     flex: 1;

package/src/components/plan-detail/PlanVersionDiffPanel.vue

@@ -66,7 +66,7 @@
                     :key="'cf-' + f"
                     class="pd-diff-row plain"
                 >
-                    <div class="pd-diff-icon" style="background: #8b5cf6">·</div>
+                    <div class="pd-diff-icon feature">·</div>
                     <div class="pd-diff-body">
                         <span class="pd-diff-label">{{ featureLabel(f) }}</span>
                         <code class="pd-diff-key">{{ f }}</code>
@@ -88,7 +88,7 @@
                     :key="'cq-' + k"
                     class="pd-diff-row plain"
                 >
-                    <div class="pd-diff-icon" style="background: #0ea5e9">·</div>
+                    <div class="pd-diff-icon quota">·</div>
                     <div class="pd-diff-body">
                         <span class="pd-diff-label">{{ quotaLabel(k) }}</span>
                         <code class="pd-diff-key">{{ k }}</code>
@@ -111,7 +111,7 @@
                     :key="'cb-' + b"
                     class="pd-diff-row plain"
                 >
-                    <div class="pd-diff-icon" style="background: #f59e0b">·</div>
+                    <div class="pd-diff-icon bundle">·</div>
                     <div class="pd-diff-body">
                         <span class="pd-diff-label">{{ bundleLabel(b) }}</span>
                         <code class="pd-diff-key">{{ b }}</code>

package/src/components/plan-matrix/PlanMatrix.vue

@@ -811,7 +811,7 @@ function formatQuota(v: number | undefined): string {
     height: 30px;
     border-radius: 50%;
     background: var(--sa-color-accent-surface-strong);
-    color: var(--sa-color-accent);
+    color: var(--sa-color-accent-strong);
     margin: 0 auto 6px;
 }
 .pm-add-title {

package/src/components/plan-version-editor/PlanCatalogPreview.vue

@@ -25,9 +25,13 @@
 
         <div class="pve-prev-window" :class="`pve-prev-window--${previewMode}`">
             <div class="pve-prev-chrome">
-                <span class="pve-prev-dot" style="background: #ef4444" />
-                <span class="pve-prev-dot" style="background: #f59e0b" />
-                <span class="pve-prev-dot" style="background: #10b981" />
+                <!-- The same window controls as MarketingCatalogPreview, drawn
+                     a second time, and the same reason for the `-strong`
+                     rungs. The chrome itself is duplicated markup and belongs
+                     in one component; that is a Phase 4 job, not a colour one. -->
+                <span class="pve-prev-dot" style="background: var(--sa-color-negative-strong)" />
+                <span class="pve-prev-dot" style="background: var(--sa-color-warning-strong)" />
+                <span class="pve-prev-dot" style="background: var(--sa-color-positive-strong)" />
                 <div class="pve-prev-url">{{ catalogUrl }}</div>
             </div>
             <div class="pve-prev-body">

package/src/pages-standard/AdminManifestErrorPage.vue

@@ -1,5 +1,5 @@
 <template>
-    <div class="sa-manifest-error">
+    <div class="sa-page sa-manifest-error">
         <q-card class="sa-manifest-error__card">
             <q-card-section class="sa-manifest-error__head">
                 <q-icon name="cloud_off" size="32px" color="negative" />
@@ -112,6 +112,9 @@ function logout(): void | Promise<void> {
     padding: 32px;
     display: flex;
     justify-content: center;
+    /* The page frame is a full viewport tall, and a stretched flex item would
+     * make this card as tall as the screen for four lines of text. */
+    align-items: flex-start;
 }
 .sa-manifest-error__card {
     max-width: 640px;

package/src/pages-standard/DashboardPage.vue

@@ -405,7 +405,7 @@ function barWidth(value: number, max?: number): number {
 /* Header look comes from the global .sa-page-head — only a margin tweak here. */
 
 .sa-kpi__icon :deep(.q-icon) {
-    color: var(--sa-color-accent);
+    color: var(--sa-color-accent-strong);
 }
 
 .sa-dashboard__rows {
@@ -423,7 +423,7 @@ function barWidth(value: number, max?: number): number {
 
 .sa-dashboard__count {
     background: var(--sa-color-accent-surface);
-    color: var(--sa-color-accent);
+    color: var(--sa-color-accent-strong);
     font-size: var(--sa-text-xs);
     font-weight: 700;
     padding: 2px 7px;
@@ -492,7 +492,7 @@ function barWidth(value: number, max?: number): number {
     border-color: var(--sa-color-accent-border);
 }
 .sa-dashboard__shortcut :deep(.q-icon) {
-    color: var(--sa-color-accent);
+    color: var(--sa-color-accent-strong);
     flex-shrink: 0;
 }
 .sa-dashboard__shortcut-title {

package/src/pages-standard/DiscoveryPage.vue

@@ -228,25 +228,59 @@ const statusFilterOptions = computed<Array<{ label: string; value: DiscoveryStat
     ],
 );
 
-const appKey = computed(() => props.snapshot?.app.key ?? '—');
+// `?.app?.` rather than `?.app.` — the optional chain has to survive the whole
+// path, not just its first step. `useDiscovery` assigns the response body with
+// an unchecked `as DiscoverySnapshot`, so a 200 whose body is not a snapshot
+// (an older backend, a proxy's JSON error page, a partial response) reaches
+// here as a non-null value without `app`. The guard then stopped one step short
+// and the page threw during a computed — which white-screens the route rather
+// than showing the dash these fallbacks exist for.
+// Narrowed to a string, not merely to "present". The type says `key` is a
+// string; the runtime value is whatever the server sent, because `useDiscovery`
+// assigns the body with an unchecked `as DiscoverySnapshot`. A truthy non-string
+// — `{"app":{"key":1}}` — passes an existence check and then throws on
+// `.charAt`, which is the same white-screen one step further in. Guarding
+// presence without guarding type only moves the crash.
+const appKeyText = computed(() => {
+    const key = props.snapshot?.app?.key;
+    return typeof key === 'string' ? key : '';
+});
+const appKey = computed(() => appKeyText.value || '—');
 const appLabel = computed(() => {
-    const k = props.snapshot?.app.key ?? '';
+    const k = appKeyText.value;
     return k ? k.charAt(0).toUpperCase() + k.slice(1) : 'Discovery';
 });
-const appVersion = computed(() => props.snapshot?.app.version ?? '0.0.0');
+const appVersion = computed(() => {
+    const version = props.snapshot?.app?.version;
+    return typeof version === 'string' && version ? version : '0.0.0';
+});
 const scanLabel = computed(() => {
-    if (!props.snapshot?.scannedAt) return msg.value.notScannedYet;
+    const scannedAt = props.snapshot?.scannedAt;
+    // Same reasoning: the catch below covers a bad DATE, not a bad type — the
+    // fallback `return scannedAt` would hand the template a non-string.
+    if (typeof scannedAt !== 'string' || !scannedAt) return msg.value.notScannedYet;
     try {
-        return new Date(props.snapshot.scannedAt).toLocaleString(intlLocale.value);
+        return new Date(scannedAt).toLocaleString(intlLocale.value);
     } catch {
-        return props.snapshot.scannedAt;
+        return scannedAt;
     }
 });
 
 const declaredAtByKey = computed<Record<string, string>>(() => {
     const map: Record<string, string> = {};
-    for (const c of props.snapshot?.capabilities ?? []) {
-        map[c.capabilityKey] = c.declaredAt;
+    // `Array.isArray`, not `?? []`. The nullish fallback only covers `null` and
+    // `undefined`; anything else present goes straight into `for…of`, and a
+    // JSON object or a number is not iterable — `for (const c of {})` throws,
+    // which takes the route down exactly like the string methods above did.
+    //
+    // A string would have slipped through both: it IS iterable, so the loop
+    // walks its characters and silently builds nonsense. That is why the case
+    // covering this in the test suite had to be an object rather than a string —
+    // the first version used a string and passed without exercising anything.
+    const capabilities = props.snapshot?.capabilities;
+    if (!Array.isArray(capabilities)) return map;
+    for (const c of capabilities) {
+        if (c && typeof c.capabilityKey === 'string') map[c.capabilityKey] = c.declaredAt;
     }
     return map;
 });

package/src/pages-standard/MarketingCatalogPage.vue

@@ -1529,14 +1529,22 @@ async function onLocaleChange(loc: string): Promise<void> {
     transform: rotate(90deg);
 }
 
+/* The open editor is a WELL under its row, not another row.
+ *
+ * It used to end on a gradient whose last stop was `--sa-color-bg-surface` —
+ * exactly the colour of the next row — closed by the same soft hairline that
+ * separates any two rows. Nothing then said where the editor stopped, so the
+ * following plan read as part of the plan being edited.
+ *
+ * Three things say it now, and each carries a different half of the message:
+ * the surface is recessed (`bg-sunken`, which is what a well is for), an accent
+ * edge on the left ties the panel to the row it belongs to, and a real border
+ * closes it at the bottom instead of a hairline that means "next row". */
 .sa-marketing-admin-expand {
     grid-column: 1 / -1;
-    background: linear-gradient(
-        180deg,
-        var(--sa-color-bg-surface-raised) 0%,
-        var(--sa-color-bg-surface) 100%
-    );
-    border-bottom: 1px solid var(--sa-color-border-soft);
+    background: var(--sa-color-bg-sunken);
+    border-left: 2px solid var(--sa-color-accent);
+    border-bottom: 2px solid var(--sa-color-border-strong);
     padding: 18px 20px 22px;
 }
 .sa-marketing-expand-grid {
@@ -1716,8 +1724,13 @@ async function onLocaleChange(loc: string): Promise<void> {
         color 0.12s;
 }
 .sa-marketing-tf-chip em {
+    /* No colour of its own — the mono face and the smaller step already set it
+     * apart from the chip's label, and a colour here does not follow the chip.
+     * `--sa-color-fg-subtle` stayed put when :hover moved the chip's surface to
+     * a 22 % accent tint, which measured 2.92:1 in the dark theme: a foreground
+     * declared without the background it will end up on is a pair nothing can
+     * check, and this one was wrong in exactly the state nobody screenshots. */
     font-style: normal;
-    color: var(--sa-color-fg-subtle);
     font: 500 var(--sa-text-xs) var(--sa-font-mono);
 }
 .sa-marketing-tf-chip:hover:not(:disabled) {

package/src/pages-standard/SuperAdminLoginPage.vue

@@ -5,7 +5,7 @@
         :icon="iconText"
         @done="needsSetup = false"
     />
-    <div v-else class="sa-login-wrap">
+    <div v-else class="sa-page sa-login-wrap">
         <div class="sa-login-card">
             <div class="sa-login-brand">
                 <div v-if="logoUrl" class="sa-login-logo sa-login-logo--img">
@@ -285,7 +285,12 @@ async function handleSubmit(): Promise<void> {
     line-height: 1.5;
 }
 
+/* The heading block is one unit, and the form sits the same distance below it
+ * whether or not the optional subtitle is there. Without this the gap was the
+ * title's 6px on a login that passes no subtitle — which nobody saw, because
+ * Quasar's element-level `h1` line-height was padding it out to 96px. */
 .sa-login-form {
+    margin-top: var(--sa-space-6);
     display: flex;
     flex-direction: column;
 }

package/src/pages-standard/SuperAdminSetupWizard.vue

@@ -1,5 +1,5 @@
 <template>
-    <div class="sa-setup-wrap">
+    <div class="sa-page sa-setup-wrap">
         <div class="sa-setup-card">
             <div class="sa-setup-head">
                 <div class="sa-setup-badge">{{ iconText }}</div>

package/src/pages-standard/marketing-catalog/MarketingCatalogPreview.vue

@@ -1,9 +1,23 @@
 <template>
     <div class="sa-marketing-window">
         <div class="sa-marketing-chrome">
-            <span class="sa-marketing-chrome-dot" style="background: #ef4444" />
-            <span class="sa-marketing-chrome-dot" style="background: #f59e0b" />
-            <span class="sa-marketing-chrome-dot" style="background: #10b981" />
+            <!-- The window controls of the browser this mock-up draws. Their hue
+                 is fixed by what they depict rather than by what they mean, and
+                 the `-strong` rungs are exactly that hue — the three replaced
+                 the same three literals byte for byte. Only the amber differs
+                 between themes, and it lifts one rung in the dark one. -->
+            <span
+                class="sa-marketing-chrome-dot"
+                style="background: var(--sa-color-negative-strong)"
+            />
+            <span
+                class="sa-marketing-chrome-dot"
+                style="background: var(--sa-color-warning-strong)"
+            />
+            <span
+                class="sa-marketing-chrome-dot"
+                style="background: var(--sa-color-positive-strong)"
+            />
             <div class="sa-marketing-chrome-url">{{ previewUrl }}</div>
         </div>
         <div class="sa-marketing-canvas">

package/src/pages-standard/tenants/StatusPill.vue

@@ -53,7 +53,7 @@ defineProps<{
 }
 .sa-pill--primary {
     background: var(--sa-color-accent-surface);
-    color: var(--sa-color-accent);
+    color: var(--sa-color-accent-strong);
 }
 .sa-pill--accent {
     background: var(--sa-color-warning-surface-strong);

package/src/pages-tenant/OnboardingConfigurator.vue

@@ -305,7 +305,7 @@ defineExpose({ draft });
     font-size: var(--sa-text-xs);
     letter-spacing: 0.1em;
     text-transform: uppercase;
-    color: var(--sa-color-accent);
+    color: var(--sa-color-accent-strong);
     background: var(--sa-color-accent-surface);
     padding: 6px 11px;
     border-radius: 999px;

package/src/ui/theme/base.css

@@ -22,7 +22,19 @@
  * The font and text colour belong here because the hosting app's stylesheet
  * loads after this one: without a rule on the page itself, admin pages would
  * inherit whatever the consumer sets. Two full-page views used to pin both on
- * their own root, which is exactly the divergence this prevents. */
+ * their own root, which is exactly the divergence this prevents.
+ *
+ * `.sa-page` is also the theme's REACH MARKER, and that is the larger job: it
+ * and `.sa-portal` are the only two prefixes through which the component layer
+ * corrects Quasar's own DOM. A screen without one of them gets Quasar's look —
+ * its 4px radii, its transparent outlined control, its neutral #1d1d1d card in
+ * dark mode — and nothing announces it. The login and setup screens rendered
+ * that way for their whole existence, and they are the first thing a user sees.
+ *
+ * Which is why the screens OUTSIDE the shell carry it too, even though they
+ * bring their own frame: their own root class is more specific than this one,
+ * so the min-height and padding below stay theirs and only the reach is shared.
+ * `tests/theme-reaches-every-page.test.js` holds every page to it. */
 .sa-page {
     min-height: calc(100vh - 56px);
     padding: 20px 28px 28px;

package/src/ui/theme/components/field.css

@@ -36,3 +36,47 @@
     flex: 1;
     min-width: 200px;
 }
+
+/* Quasar's own accent-coloured text, painted from the role that is safe on a
+ * dark surface.
+ *
+ * Quasar colours the focused field's floating label and the selected menu item
+ * with `--q-primary` — the brand itself, which does not change between themes.
+ * On a light card that is fine; on the dark theme's slate surfaces the brand
+ * blue lands around 3.4:1 and the shrunk label is small text, so it reads as
+ * decoration rather than as the name of the field you are typing in.
+ *
+ * `--sa-color-accent-strong` is the same brand mixed toward the theme's own
+ * extreme — darker in light, lighter in dark — which is exactly what the guide
+ * prescribes for accent text. The colour still follows the host's `$primary`,
+ * so nothing about branding changes.
+ *
+ * `q-field--highlighted` is the whole story and `q-field--focused` would be
+ * noise: Quasar's only label-colour rule is
+ * `.q-field--highlighted .q-field__label { color: currentColor }`, and it sets
+ * that class whenever the field is focused OR invalid.
+ *
+ * Which is why the invalid half has to be carved back out. Quasar paints an
+ * invalid field's red by putting `text-negative` on the CONTROL and letting the
+ * label inherit it through that `currentColor`. Naming any colour on the label
+ * cuts the inheritance, and `!important` on `.text-negative` cannot defend it,
+ * because that declaration sits on a different element. Without the `:not()` a
+ * field with `rules` or `:error` — the login, setup and confirm forms — would
+ * announce its failure in every indicator except the one naming the field.
+ *
+ * `.sa-portal` alongside `.sa-page` for the usual reason: Quasar teleports every
+ * menu to `<body>`, so a `.sa-page`-prefixed rule never reaches a dropdown. */
+.sa-page .q-field--highlighted:not(.q-field--error) .q-field__label,
+.sa-portal .q-field--highlighted:not(.q-field--error) .q-field__label {
+    color: var(--sa-color-accent-strong);
+}
+
+/* The chosen entry in an open select. Quasar marks it `q-item--active` and
+ * colours it with the brand; on the dark menu surface that is the same 3.4:1,
+ * and it is the one line in the list that has to be legible. */
+.sa-page .q-item--active,
+.sa-portal .q-item--active,
+.sa-page .q-item.q-manual-focusable--focused,
+.sa-portal .q-item.q-manual-focusable--focused {
+    color: var(--sa-color-accent-strong);
+}

package/src/ui/theme/components/statistics.css

@@ -83,7 +83,7 @@
     flex: none;
     border-radius: var(--sa-radius-tile);
     background: var(--sa-color-accent-surface-strong);
-    color: var(--sa-color-accent);
+    color: var(--sa-color-accent-strong);
 }
 .sa-kpi--inline .sa-kpi__label {
     order: 1;

package/src/ui/theme/tokens.semantic.dark.css

@@ -120,9 +120,11 @@ body.body--dark {
     --sa-color-feature-fg: var(--sa-violet-200);
     --sa-color-feature-surface: color-mix(in srgb, var(--sa-violet-500) 16%, transparent);
     --sa-color-quota: var(--sa-sky-500);
+    --sa-color-quota-fg: var(--sa-sky-200);
     --sa-color-quota-surface: color-mix(in srgb, var(--sa-sky-500) 16%, transparent);
     --sa-color-quota-border: color-mix(in srgb, var(--sa-sky-500) 36%, transparent);
     --sa-color-bundle: var(--sa-amber-500);
+    --sa-color-bundle-fg: var(--sa-amber-200);
     --sa-color-bundle-surface: color-mix(in srgb, var(--sa-amber-500) 16%, transparent);
 
     /* The identity ramp, one rung lighter throughout — see the light file for

package/src/ui/theme/tokens.semantic.light.css

@@ -141,16 +141,25 @@
     --sa-color-scheduled-surface-strong: var(--sa-indigo-100);
     --sa-color-scheduled-border: var(--sa-indigo-200);
 
-    /* ── Catalogue entities. Not statuses: these two say WHAT a row is, and
+    /* ── Catalogue entities. Not statuses: these three say WHAT a row is, and
      * the plan editor, the matrix, the review and the discovery page all need
-     * to agree, or the same dot means two things on two screens. ────────── */
+     * to agree, or the same dot means two things on two screens.
+     *
+     * Each one has the same three slots a status tone has: the colour itself,
+     * a tinted SURFACE, and an `-fg` that is readable on that surface. Only
+     * `feature` had the third, and the two that were missing are why a diff
+     * marker painted white on `--sa-sky-500` (2.77:1) and on `--sa-amber-500`
+     * (2.15:1): with no role to point at, the panel reached past the layer for
+     * the primitive and wrote it into the template. ───────────────────────── */
     --sa-color-feature: var(--sa-violet-500);
     --sa-color-feature-fg: var(--sa-violet-700);
     --sa-color-feature-surface: var(--sa-violet-50);
     --sa-color-quota: var(--sa-sky-500);
+    --sa-color-quota-fg: var(--sa-sky-700);
     --sa-color-quota-surface: var(--sa-sky-50);
     --sa-color-quota-border: var(--sa-sky-200);
     --sa-color-bundle: var(--sa-amber-500);
+    --sa-color-bundle-fg: var(--sa-amber-700);
     --sa-color-bundle-surface: var(--sa-amber-100);
 
     /* ── Identity. A CATEGORICAL ramp: the only job of these seven is to be