@7365admin1/layer-common 3.2.2-staging.154 → 3.2.2-staging.155

package/components/DashboardMain.vue

@@ -357,6 +357,29 @@
         </h2>
       </div>
 
+      <!--
+        THE TWO SERIES COLOURS STAY LITERAL, AND HERE IS WHY.
+
+        Everything else in this chart already follows the theme - the gridlines,
+        the axis labels and the ring around each dot are all Vuetify theme vars.
+        The two series are not, and they are the only chart colours in the file
+        that are still hexes.
+
+        They are left that way deliberately. The handoff names no chart palette
+        at all (searched: no "chart", no "legend", no "graph", and neither hex
+        appears anywhere in it), so the fallback rule is "use the token the
+        literal was already imitating". `#e53935` is plainly `--err`. `#ff9b9b`
+        is a second, softer red, and the palette has no second red - the only
+        other red token is `--err-bg`, a 10%-alpha FILL that would be invisible
+        as a 3px line. Re-pointing just one of them would collapse the pair in
+        dark mode, where `--err` is `rgb(229,115,115)` and would sit almost on
+        top of `#ff9b9b`'s `rgb(255,155,155)` - two lines the reader could no
+        longer tell apart. That is the same "do not merge two series into one
+        colour" trap as the Work Order Status bars below.
+
+        So: a two-series chart palette is missing from the design system, and
+        that is a designer question, not something to invent here.
+      -->
       <div v-if="hasChartData" class="mt-4" ref="chartContainerRef">
         <svg
           :viewBox="`0 0 ${chartWidth} 260`"
@@ -2473,6 +2496,29 @@ const todayAttentions = computed(() =>
   normalizeListItems(["todayAttentions", "attentions"])
 );
 
+/**
+ * THE WORK ORDER STATUS BARS.
+ *
+ * Was three hand-picked hexes - `#2fb84d` green, `#f12d2d` red, `#ff8900`
+ * orange - and blind to the theme: the SAME three bars in light and in dark,
+ * because a literal cannot follow a theme. Each is re-pointed at the token
+ * whose hue it was already imitating, which is the same treatment the KPI
+ * tiles got, and which keeps all three bars distinguishable.
+ *
+ * ONE OF THEM DOES NOT AGREE WITH `utils/status.ts`, ON PURPOSE.
+ * That file maps `completed -> ok` and `pending -> warn` (both honoured here),
+ * but it also maps `in progress -> warn` - the SAME tone as `pending`. Applying
+ * it literally would paint two of these three bars the same amber and make the
+ * chart unreadable, which is a regression, not a fix. So "In Progress" keeps
+ * the tone it is drawn in today (`--err`, the token `#f12d2d` was imitating)
+ * and this stays a colour change with no behaviour change.
+ *
+ * That leaves a real inconsistency to settle: on this very page the "In
+ * Progress" feedback CHIP is amber (`warn`) while this bar is red. Resolving it
+ * means either giving `in progress` its own tone in `utils/status.ts` - which
+ * is shared by every chip in the estate - or ruling that a chart series is not
+ * a status chip. Both are design decisions, so neither is taken here.
+ */
 const workOrderStatus = computed(() => {
   const summary = finalDashboardData.value?.workOrderStatusSummary;
   const metric = getMetric(["openWorkOrder", "workOrders", "workOrder"]);
@@ -2493,19 +2539,19 @@ const workOrderStatus = computed(() => {
       label: "Completed",
       value: completed,
       percent: (completed / max) * 100,
-      color: "#2fb84d",
+      color: "var(--ok)",
     },
     {
       label: "In Progress",
       value: inProgress,
       percent: (inProgress / max) * 100,
-      color: "#f12d2d",
+      color: "var(--err)",
     },
     {
       label: "Pending",
       value: pending,
       percent: (pending / max) * 100,
-      color: "#ff8900",
+      color: "var(--warn)",
     },
   ];
 });
@@ -3945,32 +3991,53 @@ function formatDashboardTime(value?: string) {
   text-transform: capitalize;
 }
 
-/* Was five pairs of literal pastels - the same pale green on the dark page,
-   and none of them the tones the rest of the product uses. */
+/* THESE FIVE ARE LITERAL ON PURPOSE - THE PRINT VIEW IS PAPER.
+ *
+ * `.print-dashboard-view` above pins its surface to `#ffffff` and its ink to
+ * `#1e293b` in BOTH themes, because a printed page is white however the app is
+ * themed. Putting the status tokens on these badges therefore did the opposite
+ * of what tokenising usually does: it let the SCREEN theme reach a surface that
+ * does not follow it. Measured on the print branch at 1440:
+ *
+ *   light  In Progress  rgb(59,111,212)  on rgb(235,241,251)  4.20:1
+ *   light  Completed    rgb(15,138,98)   on rgb(231,243,239)  3.82:1
+ *   dark   In Progress  rgb(125,166,236) on rgb(239,244,253)  2.23:1
+ *   dark   Completed    rgb(65,199,149)  on rgb(232,248,242)  1.93:1
+ *
+ * The dark rows are the defect: the dark-theme INK composited over the white
+ * paper the print view forces, so anyone who exports the dashboard while the
+ * app is in dark mode gets washed-out badges - 1.93:1, the lowest reading taken
+ * on this component. So these go back to fixed pastels, and specifically to the
+ * SAME five pairs the Word export writes into its own stylesheet further up, so
+ * the on-page print view and the exported document finally match.
+ *
+ * Same rule as the signature pad: a surface that does not follow the theme must
+ * not be painted with tokens that do.
+ */
 .badge-success {
-  background-color: var(--ok-bg);
-  color: var(--ok);
+  background-color: #d1fae5;
+  color: #065f46;
 }
 
 .badge-info {
-  background-color: var(--info-bg);
-  color: var(--info);
+  background-color: #e0f2fe;
+  color: #075985;
 }
 
 .badge-danger,
 .badge-error {
-  background-color: var(--err-bg);
-  color: var(--err);
+  background-color: #fee2e2;
+  color: #991b1b;
 }
 
 .badge-warning {
-  background-color: var(--warn-bg);
-  color: var(--warn);
+  background-color: #fef3c7;
+  color: #92400e;
 }
 
 .badge-neutral {
-  background-color: var(--hover);
-  color: var(--text2);
+  background-color: #f1f5f9;
+  color: #475569;
 }
 
 /* ------------------------------------------------------------------ */

package/package.json

@@ -2,7 +2,7 @@
   "name": "@7365admin1/layer-common",
   "license": "MIT",
   "type": "module",
-  "version": "3.2.2-staging.154",
+  "version": "3.2.2-staging.155",
   "author": "7365admin1",
   "main": "./nuxt.config.ts",
   "//files": "What a consumer extending this layer actually loads. Without this npm ships the whole working tree - the changesets, the CI workflows, the render harness in tools/ and any scratch directory that happened to exist at publish time. Nuxt resolves a layer by directory, so every runtime directory below has to stay listed; adding a new top-level runtime directory means adding it here too.",