Deploy AIOS web (React glide grid + FastAPI slice)

RELEASES.json

@@ -1,5 +1,5 @@
 {
- "current": "e09d5b9",
+ "current": "9a6a561",
  "releases": [
   {
    "version": "v29",

VERSION

@@ -1 +1 @@
-e09d5b9
+9a6a561

platform/aios_grid_fields.json

@@ -464,12 +464,19 @@
         "source": "odoo",
         "description": "Units sold in the last twelve months. Consolidated; absent for a BU-scoped caller."
       },
+      {
+        "key": "incoming",
+        "label": "Inbound units",
+        "type": "int",
+        "source": "odoo",
+        "description": "Units already on order and not yet received, from Odoo's own incoming quantity on the product. In the product's STOCK unit of measure, the same unit as On hand, so the two can be added. Both cover gap columns count this as stock."
+      },
       {
         "key": "dos",
         "label": "Days of supply",
         "type": "int",
         "source": "odoo",
-        "description": "Days of supply at the LTM rate; null means it never sells through. Consolidated; absent for a BU-scoped caller."
+        "description": "Days of supply at the LTM rate, from ON-HAND stock only; null means it never sells through. It deliberately IGNORES inbound units, because dead stock and overstock are questions about what is on the shelf. The cover gap columns are the ones that count inbound. Consolidated; absent for a BU-scoped caller."
       },
       {
         "key": "cover_gap_d",
@@ -477,7 +484,15 @@
         "type": "int",
         "source": "odoo",
         "default": false,
-        "description": "Days of supply minus lead time. Negative means it runs out before a reorder lands."
+        "description": "Days of cover minus supplier lead time. Negative means it runs out before a reorder lands. Counts INBOUND units as stock (owner, 2026-08-19), so this reads longer than Days of supply on any SKU with an open purchase order."
+      },
+      {
+        "key": "cover_gap_units",
+        "label": "Cover gap (units)",
+        "type": "int",
+        "source": "odoo",
+        "default": false,
+        "description": "The recommended reorder quantity: units of demand over the lead time that on-hand plus inbound does not cover. POSITIVE means buy this many; negative is surplus units; blank means we cannot say, because the SKU has no lead time on file or never sells through. Rounded AWAY from zero, so a real shortfall never rounds down to nothing."
       },
       {
         "key": "stock_bucket",
@@ -486,6 +501,17 @@
         "source": "odoo",
         "description": "Dead / excess / healthy bucket from the inventory module. Consolidated; absent for a BU-scoped caller."
       },
+      {
+        "key": "discontinued",
+        "label": "Discontinued",
+        "type": "select",
+        "source": "odoo",
+        "options": [
+          "Yes",
+          "No"
+        ],
+        "description": "Whether Odoo carries the Discontinued product tag on this SKU. Every row gets an explicit Yes or No rather than a blank, because a blank reads as an inactive condition in the filter engine and would silently WIDEN any view that filtered on it."
+      },
       {
         "key": "needs_pricing",
         "label": "Needs pricing",

platform/modules/product_data.py

@@ -53,6 +53,7 @@ template and this deliberately mirrors its signature and its row shape.
 """
 import datetime as _dt
 import json
+import math as _math
 import zlib
 from pathlib import Path
 
@@ -422,6 +423,12 @@ def pool(team_id=None, t=None):
             # SKU that is not re-SKUed. `directory()` derives the category identically.
             "product": meta.get("product") or code,
             "category": meta.get("category") or "(uncategorized)",
+            # ⭐⭐ OWNER 2026-08-19 — the Odoo Discontinued tag, surfaced so the buy list can drop
+            # them. ⛔ ALWAYS "Yes" OR "No", NEVER BLANK: an unknown value is an INACTIVE condition
+            # in the tri-state filter engine, so a view filtering on a blank column IGNORES the
+            # leaf and WIDENS to the whole catalogue. That is the exact failure `_seed_wave17`'s
+            # buy-list comment was written about, and a blank here would reintroduce it.
+            "discontinued": meta.get("discontinued") or "No",
             # ⭐⭐ W33-T43 (R2 / amendment A2) — ODOO'S OWN PRODUCT ID, beside the hashed `pid`.
             # R2 retires `ut_odoo_products` onto this key and keeps every data column it had; this
             # is that column. ⛔ NOT DERIVABLE DOWNSTREAM: `pid` is `crc32(default_code)` here,
@@ -509,11 +516,51 @@ def pool(team_id=None, t=None):
         # "does the shelf outlast a reorder AT FISCH'S RATE" — reading the consolidated figure
         # here would print a buy signal computed from both units' velocity beside a days-of-supply
         # computed from one, and the two columns would disagree on the same row.
+        # ⭐⭐ OWNER 2026-08-19 — INBOUND COUNTS AS STOCK FOR THE COVER GAP. Verbatim: *"Cover gap
+        # day also should INCLUDE the incoming SKUs so it assumes those as stock even though its
+        # inbound"*, and *"we need the 'Cover gap (units)' basically tell us how much to buy"*.
+        #
+        # ⛔ `dos` AND `stock_bucket` DELIBERATELY DO NOT MOVE. They answer "what is on the shelf",
+        # which is the question dead-stock, excess and overstock are built on; folding inbound into
+        # them would change the Inventory module's meaning from a buy-list request. So a row can
+        # honestly read `dos 5, lead 30, cover gap +12` when 900 units are on the water, and the
+        # two columns' own descriptions say which is which.
+        #
+        # ⚠ THE VELOCITY BASIS IS UNCHANGED AND IS **TRAILING** TWELVE MONTHS, not a forward
+        # projection. `daily` here is the same `qty_ltm / 365` that produced `dos` upstream, so the
+        # new columns cannot disagree with the old one about how fast the SKU moves. The owner
+        # described the existing column as "based on the next 8 months Unit sales"; it is not, and
+        # that is REPORTED rather than quietly repaired — changing the basis in the same edit that
+        # adds inbound would make it impossible to tell which change moved which number.
         lead = s.get("lead_days")
-        if isinstance(dos, (int, float)) and isinstance(lead, (int, float)) and lead > 0:
-            row["cover_gap_d"] = int(round(dos - lead))
-            row["buy_now"] = "Buy now" if dos < lead else "OK"
+        # ⚠ FROM THE CATALOGUE ROW (`meta`), NOT THE INVENTORY ROW (`e`). Both live on this SKU
+        # and only one of them was read from Odoo's product record.
+        incoming = meta.get("incoming")
+        row["incoming"] = incoming
+        daily = (qty_ltm / 365.0) if isinstance(qty_ltm, (int, float)) and qty_ltm > 0 else None
+        on_shelf = row["on_hand"]
+        effective = ((on_shelf or 0.0) + (incoming or 0.0)
+                     if isinstance(on_shelf, (int, float)) else None)
+        if daily and isinstance(effective, (int, float)) and isinstance(lead, (int, float)) \
+                and lead > 0:
+            # Units of demand the lead time will consume, less everything we already hold or have
+            # bought. POSITIVE is a shortfall to buy; negative is surplus. Signed on purpose: a
+            # floor at zero would make the buy-list filter depend on the floor rather than on the
+            # measurement, and would flatten "covered by 2 units" into "covered by 400".
+            short = daily * lead - effective
+            # ⛔ AWAY FROM ZERO, NEVER `round()`. `cover_gap_d` is `int(round(...))` and the seed's
+            # own comment records why that makes it unsafe to SELECT on: a real gap of -0.4 days
+            # rounds to 0 and the SKU drops off a list it belongs on. A shortfall of 0.4 units is
+            # still a shortfall, so it must land on 1, not 0. `validate()` holds this on the
+            # boundary rather than trusting the expression.
+            row["cover_gap_units"] = int(_math.ceil(short) if short > 0 else _math.floor(short))
+            row["cover_gap_d"] = int(round(effective / daily - lead))
+            # ⭐ THE SIGNAL IS NOW A FUNCTION OF THE SAME NUMBER THE COLUMN SHOWS, so the words and
+            # the quantity on one row can no longer disagree — which they would have the moment
+            # the gap started counting inbound and the signal did not.
+            row["buy_now"] = "Buy now" if row["cover_gap_units"] > 0 else "OK"
         else:
+            row["cover_gap_units"] = None
             row["cover_gap_d"] = None
             row["buy_now"] = None
         rows.append(row)
@@ -546,7 +593,19 @@ def pool(team_id=None, t=None):
 #:     which is the difference between this and a filter engine's `toNum(null) === 0`;
 #:   · `IF` with a non-boolean condition returns BLANK ("no truthiness"), so a blank comparison
 #:     propagates out as a blank cell rather than taking the false branch.
-BUY_SIGNAL_FORMULA = 'IF({lead_days} > 0, IF({dos} < {lead_days}, "Buy now", "OK"), "")'
+#: ⭐⭐ REPOINTED 2026-08-19 ONTO `cover_gap_units`, AND THE REASON IS THE OWNER'S OWN INSTRUCTION.
+#: The old formula was `IF({lead_days} > 0, IF({dos} < {lead_days}, "Buy now", "OK"), "")`. Once
+#: the cover gap counts inbound stock, `{dos} < {lead_days}` is no longer the same question: it
+#: would keep saying "Buy now" for a SKU whose replenishment is already on the water, which is the
+#: shape of confusion the owner opened this work with. `cover_gap_units` already carries the whole
+#: rule — lead time present and positive, velocity known, inbound counted, rounded away from zero
+#: — so one reference replaces three and the words cannot disagree with the number beside them.
+#:
+#: ⚠ ONE ENGINE BEHAVIOUR CARRIES THE BLANK CASE, and it is why no `isNotEmpty` guard is needed:
+#: `cmp` returns BLANK unless BOTH sides read as numbers, and `IF` with a non-boolean condition
+#: returns BLANK. So a SKU with no lead time or no sell-through has `cover_gap_units = null`, the
+#: comparison is blank, and the cell is blank — never the false branch, and never a coerced 0.
+BUY_SIGNAL_FORMULA = 'IF({cover_gap_units} > 0, "Buy now", "OK")'
 
 
 def _buy_signal_formula(row):
@@ -558,14 +617,10 @@ def _buy_signal_formula(row):
             return None
         return v if v == v and v not in (float('inf'), float('-inf')) else None
 
-    lead, dos = num(row.get("lead_days")), num(row.get("dos"))
-    if lead is None:                 # `{lead_days} > 0` is blank -> IF(blank, …) is blank
-        return ""
-    if not lead > 0:
-        return ""                    # the formula's own else-branch
-    if dos is None:                  # `{dos} < {lead_days}` is blank -> IF(blank, …) is blank
+    gap = num(row.get("cover_gap_units"))
+    if gap is None:              # `{cover_gap_units} > 0` is blank -> IF(blank, …) is blank
         return ""
-    return "Buy now" if dos < lead else "OK"
+    return "Buy now" if gap > 0 else "OK"
 
 
 def validate(team_id=None, t=None):
@@ -760,12 +815,14 @@ def validate(team_id=None, t=None):
         buy = [r for r in rows if r.get("buy_now") == "Buy now"]
         ok_rows = [r for r in rows if r.get("buy_now") == "OK"]
         blank = [r for r in rows if r.get("buy_now") is None]
-        mis = sum(1 for r in buy if not (r["dos"] < r["lead_days"]))
-        mis += sum(1 for r in ok_rows if not (r["dos"] >= r["lead_days"]))
+        # ⚠ RE-DERIVED FROM `cover_gap_units`, NOT FROM `dos < lead_days`, SINCE 2026-08-19. The
+        # signal counts inbound stock now; the old predicate does not, so leaving it here made the
+        # check disagree with the column on **796 rows** — every SKU with an open purchase order.
+        # It was the check that was stale, and it caught the definition move exactly as intended.
+        mis = sum(1 for r in buy if not (r["cover_gap_units"] > 0))
+        mis += sum(1 for r in ok_rows if not (r["cover_gap_units"] <= 0))
         # A blank must be UNKNOWN — never a row we could have answered and quietly did not.
-        mis += sum(1 for r in blank
-                   if isinstance(r.get("dos"), (int, float))
-                   and isinstance(r.get("lead_days"), (int, float)) and r["lead_days"] > 0)
+        mis += sum(1 for r in blank if isinstance(r.get("cover_gap_units"), (int, float)))
         checks.append({
             "check": "Buy signal partitions the catalogue (buy + ok + unknown == rows, none "
                      "misclassified)",
@@ -794,37 +851,110 @@ def validate(team_id=None, t=None):
                           if (r.get("buy_now") or "") != _buy_signal_formula(r))
         checks.append({
             "check": 'Buy signal as a FORMULA field == the retired preset column, per SKU '
-                     '(IF({lead_days} > 0, IF({dos} < {lead_days}, "Buy now", "OK"), ""))',
+                     '(' + BUY_SIGNAL_FORMULA + ')',
             "ours": len(rows) - len(disagree), "theirs": len(rows),
             "ok": not disagree,
             "detail": {"disagreeing_skus": disagree[:10], "n_disagree": len(disagree)},
         })
-        # The other half of "the same figures": the SHARED Buy list view can no longer filter on
-        # the retired column, and its replacement conditions must select the same SKUs. They are
-        # `dos isNotEmpty AND lead_days isNotEmpty AND lead_days > 0 AND dos < lead_days`
+        # The other half of "the same figures": the SHARED Buy list view's conditions must select
+        # exactly the Buy-now SKUs. They are `discontinued neq Yes AND cover_gap_units gt 0`
         # (_seed_wave17.views), so this reproduces exactly that conjunction.
         #
-        # ⛔ THE NEGATIVE CONTROL IS WHY THIS IS NOT `cover_gap_d < 0`, which reads like the
-        # obvious filter and is WRONG: `cover_gap_d` is `int(round(dos - lead))`, so a genuine
-        # gap of -0.4 days rounds to 0 and that SKU drops off a buy list it belongs on.
+        # ⭐⭐ THE FOUR-LEAF CONJUNCTION COLLAPSED TO TWO ON 2026-08-19, and the guard the old
+        # leaves provided is now STRUCTURAL rather than spelled out. The two `isNotEmpty` leaves
+        # existed because the client filter engine's `toNum(null)` is **0**, so a bare
+        # `dos < lead_days` read a SKU with no days-of-supply as `0 < 30` = TRUE and put every
+        # never-selling product on the buy list. `cover_gap_units > 0` inverts that accident into
+        # a safety: a blank reads as 0, and `0 > 0` is FALSE, so an unknown SKU is EXCLUDED. The
+        # filter now fails CLOSED on exactly the rows the old one failed OPEN on.
+        #
+        # ⛔ AND THE ROUNDING TRAP IS THE REASON IT IS NOT `cover_gap_d < 0`. That column is
+        # `int(round(...))`, so a real gap of -0.4 days rounds to 0 and the SKU silently drops off
+        # a list it belongs on. `cover_gap_units` rounds AWAY from zero for that reason, and the
+        # boundary control below proves it on the rows where the two disagree.
         view_rows = {r["code"] for r in rows
-                     if isinstance(r.get("dos"), (int, float))
-                     and isinstance(r.get("lead_days"), (int, float))
-                     and r["lead_days"] > 0 and r["dos"] < r["lead_days"]}
-        signal_rows = {r["code"] for r in buy}
-        rounding_would_miss = sorted(
-            c for c in signal_rows
-            if next((r for r in rows if r["code"] == c), {}).get("cover_gap_d") == 0)
+                     if (r.get("discontinued") or "") != "Yes"
+                     and isinstance(r.get("cover_gap_units"), (int, float))
+                     and r["cover_gap_units"] > 0}
+        signal_rows = {r["code"] for r in buy if (r.get("discontinued") or "") != "Yes"}
         checks.append({
-            "check": "Buy list view conditions (dos/lead_days, no retired column) select "
-                     "exactly the Buy-now SKUs",
+            "check": "Buy list view conditions (discontinued neq Yes AND cover_gap_units gt 0) "
+                     "select exactly the Buy-now SKUs that are not discontinued",
             "ours": len(view_rows), "theirs": len(signal_rows),
             "ok": view_rows == signal_rows,
             "detail": {"only_in_view": sorted(view_rows - signal_rows)[:10],
-                       "only_in_signal": sorted(signal_rows - view_rows)[:10],
-                       # Reported, not asserted: how many SKUs a `cover_gap_d < 0` filter would
-                       # have silently dropped. 0 today does not make that filter correct.
-                       "cover_gap_rounds_to_zero": len(rounding_would_miss)},
+                       "only_in_signal": sorted(signal_rows - view_rows)[:10]},
+        })
+
+        # ⛔⛔ THE BOUNDARY CONTROL, and it is the single check that proves the collapse above did
+        # not silently SHRINK the list. It re-derives the rows where `cover_gap_d` rounds to 0 but
+        # the true gap is negative — precisely the SKUs the old comment warned a `cover_gap_d < 0`
+        # filter would lose — and asserts every one of them is still selected by the new predicate.
+        # A SKU short by 0.4 days of demand must produce `cover_gap_units >= 1`, not 0.
+        # ⚠ DISCONTINUED ROWS ARE OUT OF THIS POPULATION, and finding that out is why the control
+        # is written as a control. Its first run went RED naming SKU `15001`, which is a genuine
+        # sub-one-day shortfall AND carries Odoo's Discontinued tag: correctly absent from the buy
+        # list, for the other reason. Counting it as "dropped by rounding" would have made a
+        # working exclusion look like a rounding defect on every future run.
+        boundary = [r for r in rows
+                    if r.get("cover_gap_d") == 0
+                    and (r.get("discontinued") or "") != "Yes"
+                    and isinstance(r.get("cover_gap_units"), (int, float))
+                    and r["cover_gap_units"] > 0]
+        missed = sorted(r["code"] for r in boundary if r["code"] not in view_rows)
+        checks.append({
+            "check": "Rounding boundary: every SKU whose cover gap rounds to 0 DAYS but is a real "
+                     "shortfall in UNITS is still on the buy list",
+            "ours": len(boundary) - len(missed), "theirs": len(boundary),
+            "ok": not missed,
+            "detail": {"dropped_by_rounding": missed[:10],
+                       # Reported, not asserted: these are the rows a `cover_gap_d < 0` filter
+                       # would have lost. A 0 here does not make that filter correct.
+                       "n_saved_by_rounding_away_from_zero": len(boundary)},
+        })
+
+        # ⭐ RULE 8 — the Discontinued column against an INDEPENDENT Odoo aggregate.
+        # ⛔ IT RE-RESOLVES THE TAG BY NAME rather than reusing the id the column was built from.
+        # Sharing that binding would let the check and the column carry the same bug and agree
+        # about it ([[gate-and-nc-must-not-share-a-binding]]).
+        tag_id = products.discontinued_tag_id.__wrapped__()
+        ours_disc = len([r for r in rows if (r.get("discontinued") or "") == "Yes"])
+        theirs_disc = O.get_odoo().search_count(
+            'product.product',
+            [('active', '=', True), ('product_tag_ids', 'in', [tag_id])]) if tag_id else -1
+        checks.append({
+            "check": f"Discontinued SKUs == Odoo products carrying the {products.DISCONTINUED_TAG}"
+                     f" tag (resolved by name, id {tag_id})",
+            "ours": ours_disc, "theirs": theirs_disc,
+            # Codes merge variants, so ours may be <= theirs; a tag that resolved to nothing is a
+            # hard red, because the column would read "nobody is discontinued" and look fine.
+            "ok": tag_id is not None and 0 < ours_disc <= theirs_disc,
+            "detail": {"tag_resolved": tag_id is not None,
+                       "note": "ours counts SKU CODES, theirs counts product RECORDS; variants "
+                               "sharing a code merge into one row, so ours <= theirs."},
+        })
+
+        # ⭐ RULE 8 — inbound units against a SECOND, INDEPENDENTLY DERIVED source (open purchase
+        # order lines). ⛔ SHAPE AND DIRECTION, NOT EQUALITY: the two are in different units of
+        # measure on ~107 codes and asserting equality would go red forever on a correct
+        # difference. `products.incoming_from_po` documents the measurement.
+        po_units, po_report = products.incoming_from_po()
+        ours_inc = sum(float(r.get("incoming") or 0.0) for r in rows)
+        theirs_inc = sum(po_units.values())
+        with_inbound = {r["code"] for r in rows if float(r.get("incoming") or 0.0) > 0}
+        po_codes = {c for c, v in po_units.items() if v > 0}
+        checks.append({
+            "check": "Inbound units (Odoo incoming_qty) reconcile to open purchase order lines",
+            "ours": round(ours_inc, 1), "theirs": round(theirs_inc, 1),
+            # A truncated PO read makes the oracle itself untrustworthy, so it is a red.
+            "ok": (not po_report["truncated"]) and theirs_inc > 0
+                  and abs(ours_inc - theirs_inc) <= 0.10 * max(ours_inc, theirs_inc)
+                  and len(with_inbound & po_codes) >= 0.85 * len(po_codes),
+            "detail": {"skus_with_inbound_ours": len(with_inbound),
+                       "skus_with_inbound_po": len(po_codes),
+                       "in_both": len(with_inbound & po_codes),
+                       "po_lines": po_report, "uom_note": "purchase uom vs stock uom; the shipped "
+                       "column is in the STOCK uom so it can be added to On hand."},
         })
     checks.extend(validate_measures(t=t, team_id=team_id,
                                     pool_codes={r["code"] for r in rows}))

platform/modules/products.py

@@ -167,7 +167,8 @@ def directory(t=None, team_id=None):
 
 
 def catalogue():
-    """`{sku_code: {'product', 'category', 'id'}}` — EVERY ACTIVE product, sold or not.
+    """`{sku_code: {'product', 'category', 'id', 'discontinued', 'incoming'}}` — EVERY ACTIVE
+    product, sold or not.
 
     ⛔ THIS IS THE CATALOGUE UNIVERSE, AND IT IS DELIBERATELY NOT `directory()`. `directory()`'s
     row set IS the union of two revenue `read_group`s over `sale.order.line` (`:155`), so a SKU
@@ -193,7 +194,16 @@ def catalogue():
     `modules/backorders.py:161` already uses).
     """
     dom = [('active', '=', True)]
-    prods = O.search_read('product.product', dom, ['id', 'default_code', 'display_name', 'name'],
+    # ⭐ `product_tag_ids` and `incoming_qty` RIDE THIS READ rather than paying for their own.
+    # This function already pulls every active product once; a second full pull for either column
+    # costs ~6 s on somebody's first page load for data that is already in flight.
+    # ⚠ `incoming_qty` is an UNSTORED computed field. It reads fine per record, but Odoo refuses
+    # to aggregate it (`Fault 2: Cannot aggregate field 'incoming_qty'`), so nothing downstream
+    # may push a filter or a read_group on it back to Odoo. It is materialised into the pool here
+    # and summed on our side; `validate()` reconciles that sum against purchase-order lines.
+    prods = O.search_read('product.product', dom,
+                          ['id', 'default_code', 'display_name', 'name',
+                           'product_tag_ids', 'incoming_qty'],
                           limit=50000)
     n = O.get_odoo().search_count('product.product', dom)
     if len(prods) != n:
@@ -202,11 +212,19 @@ def catalogue():
             f"a search_count of {n}. A short catalogue renders as a plausible smaller grid with "
             f"nothing reporting it; raise the limit before shipping this.")
     code_cat = _code_category()
+    disc_tag = discontinued_tag_id()
     out = {}
     for p in prods:
         code = (str(p['default_code']).strip() if p.get('default_code') else f"pid:{p['id']}")
-        # First record wins, matching `_code_category`'s own convention. MEASURED 2026-08-11: zero
-        # active products share a code, so this branch is a guard, not a merge policy.
+        # First record wins, matching `_code_category`'s own convention.
+        # ⛔ THE 2026-08-11 MEASUREMENT ("zero active products share a code, so this branch is a
+        # guard, not a merge policy") HAS EXPIRED. RE-MEASURED 2026-08-19: **5,873 active products
+        # carry 5,872 distinct codes** because `2112-12` is now on two records. So this IS a merge
+        # policy today, and it is the standing reason `validate()`'s row-count leg reads 5872
+        # against an Odoo `search_count` of 5873, along with all three pricelist legs being short
+        # by exactly one. Those reds are this duplicate, not a truncated read.
+        # ⚠ Which is also why `incoming` ACCUMULATES below instead of taking the first record's
+        # value: a merge policy that keeps one record's name must still sum the other's stock.
         # ⭐⭐ W33-T43 (R2 / amendment A2) — `id` RIDES THE ROW. Odoo's `product.product` id is
         # already in hand (the `pid:{id}` fallback above uses it and then threw it away), and it is
         # the ONE column `ut_odoo_products` had that `product_data` lacked. R2 merges onto the
@@ -215,12 +233,90 @@ def catalogue():
         # ⚠ A product's grid pid is `crc32(default_code)`, NOT the Odoo id — unlike a CUSTOMER row,
         # whose pid IS the partner id. That asymmetry is exactly why this cannot be derived
         # downstream in `aios_grid.py` and has to be carried from the source read.
-        out.setdefault(code, {'product': p.get('display_name') or p.get('name') or code,
-                              'category': code_cat.get(code, '(uncategorized)'),
-                              'id': p['id']})
+        row = out.setdefault(code, {'product': p.get('display_name') or p.get('name') or code,
+                                    'category': code_cat.get(code, '(uncategorized)'),
+                                    'id': p['id'],
+                                    'discontinued': 'No', 'incoming': 0.0})
+        # ⛔ ACROSS EVERY RECORD SHARING THE CODE, not just the first one that won above. A SKU
+        # whose variants are separate records carries its inbound on whichever record the PO named,
+        # and 'first record wins' would drop the rest — a buy list that under-counts what is
+        # already on the water tells you to re-order stock you have already bought.
+        row['incoming'] += float(p.get('incoming_qty') or 0.0)
+        if disc_tag is not None and disc_tag in (p.get('product_tag_ids') or ()):
+            row['discontinued'] = 'Yes'
     return out
 
 
+#: ⭐ The Odoo product tag that marks a SKU withdrawn from the line. Owner, 2026-08-19: *"we have
+#: a status Field called discontinued from Odoo. Surface it right now so we can filter correctly."*
+#: MEASURED that day: it is not a FIELD at all — `product.product` has no `discontinued` column and
+#: no selection carrying the word. It is `product.tag`, on **497 of 5,873 active products**, every
+#: one of them `active=True` and `sale_ok=True`, so nothing else in Odoo distinguishes them and the
+#: buy list was quoting them as live SKUs.
+DISCONTINUED_TAG = 'Discontinued'
+
+
+@lru_cache(maxsize=1)
+def discontinued_tag_id():
+    """The `product.tag` id for `DISCONTINUED_TAG`, or `None` if the tag is not there.
+
+    ⚠ RESOLVED BY NAME, NOT BY ID, for the reason `PRICELIST_COLUMNS` gives: an id hard-coded here
+    keeps pointing at whatever inherits it if the tag is deleted and re-made, and every product
+    would be silently mislabelled. A missing tag yields `None`, which marks the whole catalogue
+    `No` — so `validate()` reconciles the count against Odoo rather than trusting this, and goes
+    RED on the difference instead of shipping a column that quietly says nobody is discontinued.
+    """
+    rows = O.search_read('product.tag', [('name', '=ilike', DISCONTINUED_TAG)], ['id'], limit=2)
+    return rows[0]['id'] if rows else None
+
+
+def incoming_from_po(prods=None):
+    """`({code: open_po_units}, report)` — inbound derived from PURCHASE ORDER LINES.
+
+    ⛔ THIS IS THE ORACLE, NOT THE SOURCE. The shipped `incoming` column comes from
+    `product.product.incoming_qty` (see `catalogue()`); this derives the same quantity a second,
+    independent way so `validate()` can hold them against each other rather than reconciling a
+    number with itself — the self-sealing failure `product_data.validate` already carries a scar
+    for ([[gate-and-nc-must-not-share-a-binding]]).
+
+    ⛔⛔ AND THE TWO ARE NOT EXPECTED TO BE EQUAL, WHICH IS WHY THE SOURCE IS THE ONE IT IS.
+    MEASURED 2026-08-19: totals 179,979 vs 173,775 units, differing on **107 of ~490 codes**, and
+    the differences are a UNIT OF MEASURE gap, not an error. `purchase.order.line.product_qty` is
+    in the line's PURCHASE uom while `incoming_qty` is in the product's STOCK uom, so the `SP-*`
+    family reads exactly 4x apart (400 vs 100, 320 vs 80, 240 vs 60). `on_hand` and `qty_ltm` are
+    both in the STOCK uom, so `incoming_qty` is the only one of the two that can be ADDED to a
+    shelf quantity. A buy list built on the purchase uom would over-count inbound fourfold on
+    those SKUs and tell the team not to re-order stock that is not coming.
+
+    So the check this feeds asserts SHAPE and DIRECTION (same SKUs carry inbound, totals within a
+    stated band) and REPORTS the per-code gap. Asserting equality would go red forever on a
+    difference that is correct.
+    """
+    lines = O.search_read('purchase.order.line', [('state', '=', 'purchase')],
+                          ['product_id', 'product_qty', 'qty_received'], limit=50000)
+    n = O.get_odoo().search_count('purchase.order.line', [('state', '=', 'purchase')])
+    by_id = {p['id']: p for p in (prods if prods is not None else [])}
+    if not by_id:
+        for p in O.search_read('product.product', [('active', '=', True)],
+                               ['id', 'default_code'], limit=50000):
+            by_id[p['id']] = p
+    out, off_catalogue = {}, 0.0
+    for line in lines:
+        pid = (line.get('product_id') or [None])[0]
+        open_q = float(line.get('product_qty') or 0.0) - float(line.get('qty_received') or 0.0)
+        if open_q <= 0:
+            continue
+        rec = by_id.get(pid)
+        if rec is None:                 # ordered against an ARCHIVED product: real, but off-grid
+            off_catalogue += open_q
+            continue
+        code = (str(rec['default_code']).strip() if rec.get('default_code') else f"pid:{pid}")
+        out[code] = out.get(code, 0.0) + open_q
+    return out, {'lines_read': len(lines), 'lines_total': n,
+                 'truncated': len(lines) != n,
+                 'units_on_archived_products': round(off_catalogue, 1)}
+
+
 #: ⭐⭐ WAVE 30 / W30-T34 (the carried W29-T52) — THE PRICELIST STRATUM, PER LIST.
 #:
 #: MEASURED LIVE 2026-08-12, and every one of these numbers shaped the design rather than

web/src/customer-grid/CustomerGrid.tsx

@@ -65,7 +65,8 @@ import type { GridChatAnswer, GridChatEdit, GridChatField, GridChatRunResult,
   GridChatViewSpec } from "./GridChat.tsx";
 import { ViewAgentPanel, seedName, seedScript } from "./ViewAgentPanel";
 import {
-  createScriptView, listScriptViews, readScriptView, runScriptView, saveScriptView,
+  createScriptView, listScriptViews, readScriptView, revertScriptView, runScriptView,
+  saveScriptView,
 } from "./scriptViews";
 import type { ScriptRun, ScriptView as ScriptViewRecord, ScriptViewRow } from "./scriptViews";
 import { defaultViewConfig, useGridColumns } from "./useGridColumns";
@@ -157,7 +158,7 @@ import { ALL_VIEW_ID, MAX_CALENDAR_METRICS, allViewName,
   MAX_FROZEN, choiceOptions, choiceVocabulary, clampFrozenCount, cleanDisplay, formulaOf,
   topicForScope,
   isDateFamilyType, isFilterGroup, isGroupableField, isMachineOwned,
-  isDerivedLink, isUserSchemaField, TOTAL_GROUP_KEY,
+  isDerivedLink, isUserSchemaField, isBlankValue, TOTAL_GROUP_KEY,
   isNumericFieldType,
   machineFoundRows, reFindConsequences,
   isPickType, mayEditField,
@@ -2384,7 +2385,11 @@ function CustomerGridSurface({
   const activeScriptId = scriptRows.some((row) => row.id === activeViewId) ? activeViewId : null;
   const [scriptDoc, setScriptDoc] = useState<ScriptViewRecord | null>(null);
   const [scriptRun, setScriptRun] = useState<ScriptRun | null>(null);
-  const [scriptBusy, setScriptBusy] = useState<"" | "run" | "save">("");
+  /* ⚠ W37-T46 — "revert" JOINS THIS UNION rather than getting a `reverting` boolean of its own.
+     One busy value can only be in one state, which is what stops a roll-back landing while a save
+     is in flight; two independent booleans would let both controls arm at once and the later
+     response would silently win. */
+  const [scriptBusy, setScriptBusy] = useState<"" | "run" | "save" | "revert">("");
   useEffect(() => {
     if (activeScriptId === null) {
       setScriptDoc(null);
@@ -2452,6 +2457,31 @@ function CustomerGridSurface({
       setScriptBusy("");
     });
   }, [activeScriptId]);
+  /**
+   * ⭐⭐ W37-T46 / D-338 — ROLL THE CUSTOM VIEW BACK TO AN EARLIER VERSION.
+   *
+   * ⛔ THE RESPONSE'S VIEW IS WHAT LANDS IN `scriptDoc`, and that is the whole clause rather than
+   * a refresh nicety. The panel header reads `v${view.version}` and `restored from v${restoredFrom}`
+   * off this document, so a revert that writes the store and leaves `scriptDoc` stale would roll
+   * the view back correctly and then LIE about which version is open. The server records the
+   * roll-back as a NEW version (v2 + v1 becomes v3, `restoredFrom: 1`), so the number always moves
+   * forward and a stale header is visible as a wrong number rather than as nothing at all.
+   * ⚠ `setScriptBump` for the same reason `onScriptSave` calls it: the rail row carries the
+   * version, so it goes stale on exactly the same event.
+   */
+  const onScriptRevert = useCallback((version: number) => {
+    if (activeScriptId === null) return;
+    setScriptBusy("revert");
+    void revertScriptView(activeScriptId, version).then((answer) => {
+      if (answer.view) {
+        setScriptDoc(answer.view);
+        setScriptBump((b) => b + 1);
+      } else if (answer.error) {
+        signal(TOAST_EVENT, answer.error);
+      }
+      setScriptBusy("");
+    });
+  }, [activeScriptId]);
   const lockedNote = useMemo(
     // ⚠ The label is the ARTEFACT's source name when there is one, and otherwise nothing: the
     // payload carries no database name, and "This database" is unambiguous on a surface whose
@@ -2702,10 +2732,13 @@ function CustomerGridSurface({
           unanswerable: true,
         };
       }
-      const blank = computedRows.filter((r) => {
-        const v = r[named.key];
-        return v === null || v === undefined || String(v).trim() === "";
-      }).length;
+      /* ⭐⭐ D-394 — THE ONE PREDICATE, and the fix is which QUESTION is asked rather than how the
+         count is taken. This tested null / undefined / whitespace only, so on a column the
+         connector back-fills with `"(none)"` it reported PERFECT coverage: "0 of 5872 records
+         have no Supplier" over 2,291 rows that visibly read "(none)" on the same screen. The
+         sentinel is named once in `types.ts`; see the note there for why the filter's `isEmpty`
+         deliberately answers differently. */
+      const blank = computedRows.filter((r) => isBlankValue(r[named.key])).length;
       return {
         text: `${blank} of ${total} records have no ${named.label}, so ${total - blank} do. ` +
           `Counted over the records this view is showing.`,
@@ -4070,6 +4103,43 @@ function CustomerGridSurface({
           signal(TOAST_EVENT, routed.refusal?.message ?? "This Query binding cannot create a source view.");
         return;
       }
+      /**
+       * ⭐⭐ W37-T41 (owner item 10 / R2) — PICKING "Custom" MINTS A SCRIPT VIEW, NOT A WORKSPACE ONE.
+       *
+       * ⛔ THIS BRANCH IS THE HOP THE HOLD DID NOT NAME, and without it the whole release is
+       * cosmetic. `icons.test.ts::HELD_MODES` listed three release conditions (join
+       * `CREATABLE_MODES`, add the `displayMode === "script"` branch, delete the entry) and every
+       * one of them is about a REGISTRY. None of them reaches the create path, so all three could
+       * land, `mode_parity` could go green, and picking Custom would persist an ordinary workspace
+       * view carrying `config.display.mode = "script"`: `activeScriptId` stays null because no row
+       * in E's store has that id, `<ScriptView>` never mounts, and the person gets a chip reading
+       * "Custom" over a grid. That is wave 27's `swipe` defect arriving through the door nobody
+       * gated ([[gate-can-report-green-on-nothing]]).
+       *
+       * ⚠ A SCRIPT VIEW IS NOT A WORKSPACE VIEW. Its identity, source and version history live in
+       * E's per-database store (`/api/v1/script-views`, contract C3), which is what makes R3's
+       * "unlimited versions per database" expressible at all. So `permissions` is deliberately
+       * unused here: a script view has no `personal` / `collaborative` split to carry, and
+       * pretending otherwise would invent a wall the server does not enforce.
+       * ⚠ The name is deduped against the RAIL, not `views`, because the rail is where a collision
+       * would actually be visible: script projections sit beside stored views there.
+       * ⚠ EMPTY SOURCE IS THE NORMAL FIRST STATE, not a slip. `routes_script_views._clean_source`
+       * takes `allow_empty=True` on CREATE alone, precisely so this pick cannot 400.
+       */
+      if (mode === "script") {
+        const scriptName = uniqueDisplayName(name, railViews.map((view) => view.name));
+        void createScriptView(scope, "", scriptName).then((answer) => {
+          if (!answer.view) {
+            signal(TOAST_EVENT, answer.error ?? "That Custom View could not be created.");
+            return;
+          }
+          setScriptRows((rows) => [...rows, answer.view as ScriptViewRow]);
+          openScriptView(answer.view);
+          setScriptDoc(answer.view);
+          setScriptRun(null);
+        });
+        return;
+      }
       const acceptedName = uniqueDisplayName(name, views.map((view) => view.name));
       /**
        * ⭐⭐ WAVE 27 · OWNER ITEM 9 / RULING R4 — **A NEW VIEW IS BLANK. ALL OF IT.**
@@ -4127,7 +4197,8 @@ function CustomerGridSurface({
     },
     // `fields`, not `config` (R4): the blank is derived from the COLUMNS, and reading the live
     // config here at all is what item 9 deletes.
-    [fields, persistView, views, queryBinding, scope]
+    // ⚠ `railViews` and `openScriptView` join for W37-T41's mint-on-pick branch above.
+    [fields, persistView, views, queryBinding, scope, railViews, openScriptView]
   );
   const renameView = useCallback(
     (id: string, name: string) => {
@@ -6316,6 +6387,11 @@ function CustomerGridSurface({
             saveState={saveState}
             onSelect={selectView}
             onCreate={createView}
+            /* ⭐ W37-T41 — the SAME predicate that decides whether script views are listed at all
+               (`scriptRows`' effect), so the offer and the rail can never disagree. Passing a
+               literal `true` here would offer a Custom View on a pool scope, where the created
+               view is real on the server and appears in no rail. */
+            scriptable={hostWorkspace && isUserTable}
             onRename={renameView}
             onNote={setViewNote}
             onDuplicate={duplicateView}
@@ -6968,8 +7044,33 @@ function CustomerGridSurface({
               run={scriptRun}
               onRun={onScriptRun}
               onSave={onScriptSave}
+              /* ⭐⭐ W37-T46 / D-338 — THE PROP THAT WAS NEVER PASSED. `revertScriptView` shipped,
+                 `ScriptViewPanel` accepted `onRevert`, and the server recorded a roll-back as a
+                 NEW version, all correctly; this mount forwarded six props and not this one, so
+                 the "Earlier | v1" pill rendered permanently `disabled` and D-338 stayed open
+                 behind three green tickets. A whole feature reached by nothing is this wave's
+                 dominant shape ([[reachable-is-not-the-same-as-built]]). */
+              reverting={scriptBusy === "revert"}
+              onRevert={onScriptRevert}
             />
           )}
+          {/* ⭐⭐ W37-T41 — A VIEW SET TO "Custom" WITH NO CUSTOM VIEW UNDER IT.
+              ⛔ THIS IS A REAL STATE, not a gate-shaped formality. W37-T20 taught the host to STORE
+              `mode: "script"`, so a workspace view can now carry the mode while `activeScriptId`
+              is null (nothing in E's store answers to a workspace view's id). Before this branch
+              that view painted a GRID under a chip reading "Custom", which is exactly the
+              silently-wrong render `mode_parity`'s law D exists to forbid.
+              ⚠ `activeScriptId !== null` above stays the mount for the real panel: a script view
+              is a rail PROJECTION, so its identity is the row in E's store. This branch handles
+              the other direction and says so rather than guessing. */}
+          {displayMode === "script" && activeScriptId === null && (
+            <div className="cg-script">
+              <p className="cg-script-empty cg-script-empty--pad">
+                This view is set to Custom and no Custom View is stored under it. Pick one from the
+                rail, or create a new Custom View.
+              </p>
+            </div>
+          )}
           {displayMode === "form" && (
             <FormInterface
               /* ⚠ THE TABLE KEY, not the `TopicConfig` object. C's hand-off wrote

web/src/customer-grid/ScriptViewPanel.tsx

@@ -282,7 +282,14 @@ export const ScriptView = memo(function ScriptView({
               ⚠ `trimmed` is PRINTED when it is non-zero. A history capped at 40 that silently
               showed 40 would let a reader conclude the view was only ever saved 40 times; saying
               how many were dropped is the difference between a partial record and a wrong one. */}
-          {(view.history?.length ?? 0) > 0 ? (
+          {/* ⛔ W37-T46 — THE STRIP IS ABSENT WHEN THE CALLER CANNOT REVERT, which is what the
+              prop's own doc twelve lines up already prescribed ("The control is not rendered at
+              all when it is absent, rather than rendered and refused"). Line 293 shipped
+              `onRevert === undefined` folded into `disabled` instead, so the one mount in the
+              product rendered a permanently dead "Earlier | v1" pill and the comment disowned the
+              code beside it. Two facts, two shapes: NOTHING TO GO BACK TO is an absent strip, and
+              BUSY is a disabled button. */}
+          {onRevert !== undefined && (view.history?.length ?? 0) > 0 ? (
             <div className="cg-script-history" aria-label="Earlier versions">
               <span className="cg-script-history-lead">Earlier</span>
               {[...(view.history ?? [])].map((h) => (
@@ -290,7 +297,7 @@ export const ScriptView = memo(function ScriptView({
                   type="button"
                   key={h.version}
                   className="cg-script-history-item"
-                  disabled={readOnly || reverting || onRevert === undefined}
+                  disabled={readOnly || reverting}
                   title={`Go back to version ${h.version}, saved by ${h.author || "somebody"}`}
                   onClick={() => onRevert?.(h.version)}
                 >

web/src/customer-grid/ViewSidebar.tsx

@@ -135,6 +135,19 @@ interface ViewSidebarProps {
    *  creation carries both. `permissions` is always explicit (C4: absent on create means
    *  personal, so an omission would silently contradict the form). */
   onCreate: (name: string, mode: DisplayMode, permissions: ViewPermissions) => void;
+  /**
+   * ⭐⭐ W37-T41 — may this surface hold a CUSTOM VIEW? The row is dropped when it cannot.
+   *
+   * ⛔ REQUIRED, NOT OPTIONAL, and that is the difference between this and a default. Script
+   * views are listed and resolved only on `ut_*` databases: `CustomerGrid`'s `scriptRows` effect
+   * gates on `hostWorkspace && isUserTable`, so a Custom View minted on a pool scope or a Query
+   * preview would be real on the server and invisible in every rail
+   * ([[permitted-is-not-answerable]]). An optional prop would let a new mount forget the question
+   * and quietly get the answer that ships the broken case.
+   * ⚠ It hides the CREATE ROW, never the mode: a stored `script` view still renders, still
+   * carries its icon and label, and still reads back as itself.
+   */
+  scriptable: boolean;
   onRename: (id: string, name: string) => void;
   /** Persist a view's description. "" is a real value — it clears it. */
   onNote: (id: string, note: string) => void;
@@ -317,6 +330,7 @@ export default function ViewSidebar({
   saveState,
   onSelect,
   onCreate,
+  scriptable,
   onRename,
   onNote,
   onDuplicate,
@@ -1152,7 +1166,9 @@ export default function ViewSidebar({
             </div>
           ) : (
             <>
-              {CREATABLE_MODES.map((mode) => (
+              {/* ⚠ W37-T41 — FILTERED, not a second list. `CREATABLE_MODES` stays the one roster
+                  every gate reads; this drops the one row this surface cannot honour. */}
+              {CREATABLE_MODES.filter((mode) => mode !== "script" || scriptable).map((mode) => (
                 <button
                   key={mode}
                   type="button"

web/src/customer-grid/iconShapes.ts

@@ -1,776 +1,812 @@
-// ---------------------------------------------------------------------------
-// customer-grid / iconShapes.ts
-// Wave-8 items I18 + I20 — ONE geometry source for the grid's icon vocabulary,
-// rendered by TWO very different painters:
-//
-//   - React  <FieldTypeIcon> / <ModeIcon>  — DOM svg in panels, popovers, menus
-//   - glide  headerIcons sprites           — canvas, drawn from an SVG *string*
-//
-// Glide's sprite API takes a function returning SVG SOURCE, so a header icon can
-// never be a React component. Keeping the paths as DATA (IconShape[]) and giving
-// each painter its own thin renderer is what stops the two from drifting — the
-// alternative (hand-copying every path into a template literal) guarantees the
-// header and the panel eventually disagree about what a "date" looks like.
-//
-// Geometry rules: 16x16 viewBox, stroke-based, 1.35 stroke, round caps/joins,
-// currentColor. Vector paths only — NEVER emoji (owner constant).
-// ---------------------------------------------------------------------------
-
-import type { AggName, DisplayMode, FieldType, FolderShape, FolderTone } from "./types";
-import {
-  LP_BLUE,
-  LP_BLUE_DEEP,
-  LP_GREEN,
-  LP_GREEN_DEEP,
-  LP_LINE,
-  LP_MUTED,
-  LP_RED,
-  LP_RED_DEEP,
-  LP_YELLOW,
-  LP_YELLOW_DEEP,
-} from "./theme";
-
-/** One drawing primitive. `fill: true` fills the path instead of stroking it
- *  (the rating star is the only shape that reads better solid). */
-export type IconShape = { d: string; fill?: boolean };
-
-/** A circle as a path — two half-arcs. Sprites are SVG *source*, so every shape
- *  has to survive being serialized into a string; paths do, <circle> elements
- *  would need a second serializer branch for no benefit. */
-const circle = (cx: number, cy: number, r: number): string =>
-  `M${cx - r} ${cy}a${r} ${r} 0 1 0 ${r * 2} 0a${r} ${r} 0 1 0 ${-r * 2} 0`;
-
-const CALENDAR: IconShape[] = [
-  { d: "M3.2 4.6h9.6v8.2H3.2z" },
-  { d: "M3.2 7.2h9.6" },
-  { d: "M5.8 3v3.2" },
-  { d: "M10.2 3v3.2" },
-];
-
-/**
- * Field type → icon geometry. A TOTAL record on purpose: adding a FieldType
- * without an icon is a compile error, not a silently blank header.
- */
-export const TYPE_SHAPES: Record<FieldType, IconShape[]> = {
-  text: [{ d: "M3 5h10M3 8h10M3 11h6" }],
-  status: [{ d: "M4 13V3.5h7.6L10.1 6l1.5 2.5H4" }],
-  currency: [
-    { d: "M8 2.8v10.4" },
-    { d: "M10.6 5.4A2.6 2.6 0 0 0 8.2 4.2H7.4a2 2 0 0 0 0 4h1.2a2 2 0 0 1 0 4H7.8a2.6 2.6 0 0 1-2.4-1.4" },
-  ],
-  int: [{ d: "M6.2 3L4.8 13M11.2 3l-1.4 10M3.4 6.2h9.2M2.9 9.8h9.2" }],
-  date: CALENDAR,
-  pct: [
-    { d: circle(4.6, 4.6, 1.6) },
-    { d: circle(11.4, 11.4, 1.6) },
-    { d: "M12.2 3.9L3.8 12.3" },
-  ],
-  select: [{ d: "M3.2 3.8h9.6v8.4H3.2z" }, { d: "M6.2 7.2l1.8 1.8 1.8-1.8" }],
-  user: [
-    { d: circle(8, 6, 2.4) },
-    { d: "M3.6 13c0-2.4 2-3.8 4.4-3.8s4.4 1.4 4.4 3.8" },
-  ],
-  multiselect: [
-    { d: "M3 4.6h2.2v2.2H3zM3 9.2h2.2v2.2H3z" },
-    { d: "M7.2 5.7h6M7.2 10.3h6" },
-  ],
-  checkbox: [{ d: "M3.4 3.4h9.2v9.2H3.4z" }, { d: "M5.8 8.1l1.8 1.9 3.4-3.9" }],
-  phone: [
-    { d: "M5.1 3.2L7 5.1 5.6 7a7.2 7.2 0 0 0 3.4 3.4l1.9-1.4 1.9 1.9-1.5 1.6c-3 .5-8.3-4.8-7.8-7.8z" },
-  ],
-  email: [{ d: "M3 4.4h10v7.2H3z" }, { d: "M3 4.9l5 3.9 5-3.9" }],
-  url: [
-    { d: "M7 5.4L8.4 4a2.6 2.6 0 0 1 3.7 3.7L10.7 9" },
-    { d: "M9 10.6L7.6 12a2.6 2.6 0 0 1-3.7-3.7L5.3 7" },
-    { d: "M6.2 9.8l3.6-3.6" },
-  ],
-  rating: [
-    {
-      d: "M8 2.9l1.63 3.3 3.64.53-2.63 2.57.62 3.63L8 11.24 4.74 12.93l.62-3.63L2.73 6.73l3.64-.53z",
-      fill: true,
-    },
-  ],
-  created_time: [{ d: circle(8, 8, 5.2) }, { d: "M8 4.9v3.4l2.3 1.4" }],
-  formula: [
-    { d: "M5.6 12.8V5.4a2 2 0 0 1 3.2-1.6" },
-    { d: "M4.2 7.6h4.6" },
-    { d: "M10.2 8.4l3 3.4M13.2 8.4l-3 3.4" },
-  ],
-  // Wave-18 C5-AUTOFIELD (D's spec, applied by C as client-vocab registrar). A 290° cycle ring
-  // with an arrowhead, wrapped around a solid run-triangle: a job that runs, repeatedly.
-  // Deliberately NOT a bolt (`FOLDER_SHAPE_PATHS.bolt` already means "Priority") and not a clock
-  // (`created_time` owns the closed rim + hands).
-  automation: [
-    { d: "M10.8 4.1A4.8 4.8 0 1 1 5.3 4.1" },
-    { d: "M4.2 6L5.3 4.1 3.1 4.5" },
-    { d: "M6.9 6.1L9.8 8 6.9 9.9z", fill: true },
-  ],
-  // Wave-22 C7 (added by C as client-vocab registrar, the W18 automation precedent). A rising
-  // series on an axis: a measure OVER TIME, which is what a metric field is. Deliberately not
-  // the formula fx (that computes over the ROW) and not a bare number (int owns ##).
-  metric: [
-    { d: "M3.2 3.2v9.6h9.6" },
-    { d: "M5 10.4l2.4-2.6 1.9 1.5 3.1-3.9" },
-  ],
-  // Wave-23 C7 — TWO BRACES facing each other with a dot between them: the universal mark for
-  // "a structured document", and the one glyph in this table that draws its own SYNTAX rather
-  // than a picture of what the value means. Deliberately not a document page (nothing here owns
-  // that yet, but a page reads as a file/attachment, which a json cell is not) and not a tree
-  // of nodes (too fine to survive 16px). The centre dot is what keeps the two braces from
-  // reading as parentheses at small sizes.
-  json: [
-    { d: "M6.4 3.2c-1.5 0-1.5 3.4-1.5 3.4S4.8 8 3.4 8s1.5 1.4 1.5 1.4 0 3.4 1.5 3.4" },
-    { d: "M9.6 3.2c1.5 0 1.5 3.4 1.5 3.4s.1 1.4 1.5 1.4-1.5 1.4-1.5 1.4 0 3.4-1.5 3.4" },
-    { d: circle(8, 8, 0.85), fill: true },
-  ],
-  // ⭐ Wave-27 item 13 (R13) — THE ANGLE BRACKETS, the mark every editor on earth uses for
-  // "this is source". Drawn as two chevrons with a slash leaning between them, which is what
-  // separates it from `json` two entries up: json draws BRACES (a document's own syntax), code
-  // draws BRACKETS (a snippet's). Deliberately not a terminal prompt (that reads as "run this",
-  // and R13 is explicit there is no execution engine) and not a page of lines (`list` mode and
-  // `text` already trade on that reading).
-  code: [
-    { d: "M5.6 4.9 2.6 8l3 3.1" },
-    { d: "M10.4 4.9 13.4 8l-3 3.1" },
-    { d: "M9.1 3.6 6.9 12.4" },
-  ],
-  // Wave-19 R7 — a framed picture: the mount, a sun, and the hill line every photo glyph
-  // resolves to at 16px. Drawn on the same 16-unit grid as its neighbours.
-  image: [
-    { d: "M2.6 3.4h10.8v9.2H2.6z" },
-    { d: circle(6, 6.3, 1.1) },
-    { d: "M2.6 10.6L6.1 7.6l2.5 2.1 2.2-1.8 2.6 2.2" },
-  ],
-  // ⭐ 2026-08-07 — TWO INTERLOCKING CHAIN LINKS, the one glyph everybody already reads as
-  // "this points at something else". Drawn as two rounded rectangles overlapping at the centre
-  // rather than as an arrow into a box: an arrow would mean navigation, and a link column is a
-  // relation that exists in both directions whether or not you follow it.
-  link: [
-    { d: "M6.6 5.2H4.9a2.8 2.8 0 000 5.6h1.7" },
-    { d: "M9.4 5.2h1.7a2.8 2.8 0 010 5.6H9.4" },
-    { d: "M5.6 8h4.8" },
-  ],
-  // ⭐ 2026-08-07 — THREE BARS FOLDING INTO ONE, read top-to-bottom: many linked values
-  // collapsing to a single aggregate. Deliberately not a sigma (too fine at 16px, and it would
-  // claim SUM when the function is chosen per column) and not a funnel (that is filtering,
-  // which is what `limit` does — a different half of the same field).
-  rollup: [
-    { d: "M3.2 4.4h9.6" },
-    { d: "M4.8 8h6.4" },
-    { d: "M6.6 11.6h2.8" },
-  ],
-  // ⭐ WAVE 34 · T53 (R13), drawn by C on F's ask (`F-2`) — AI ENRICHMENT.
-  // The SPARKLE, because it is the product's own AI mark already: `Shell.tsx::SparkIcon` wears it
-  // on the Assistant rail row, so a column the AI fills reads as the same family rather than as a
-  // second vocabulary for one idea. Deliberately NOT the `automation` cycle-ring two entries up
-  // (that means "a job that runs, repeatedly", and an enrichment can be manual) and not a robot
-  // head (`Shell.tsx::RobotIcon` claims that for the Agents MODULE; a field is not a module).
-  // ⚠ TWO stars, not one: a lone four-point star at 16px with a 1.35 stroke reads as a plus sign.
-  // The small companion is what makes the mark say "sparkle".
-  ai_enrich: [
-    { d: "M6.6 2.6l1.3 3.1 3.1 1.3-3.1 1.3-1.3 3.1-1.3-3.1L2.2 7l3.1-1.3z" },
-    { d: "M11.9 9.8l.7 1.6 1.6.7-1.6.7-.7 1.6-.7-1.6-1.6-.7 1.6-.7z" },
-  ],
-};
-
-/**
- * Display mode → icon geometry (I18). Also total: the wave-8 Dashboard mode
- * cannot land in DISPLAY_MODES without the compiler demanding its icon here.
- */
-export const MODE_SHAPES: Record<DisplayMode, IconShape[]> = {
-  grid: [
-    { d: "M2.6 3.4h10.8v9.2H2.6z" },
-    { d: "M2.6 6.5h10.8M2.6 9.5h10.8M6.4 3.4v9.2M10 3.4v9.2" },
-  ],
-  list: [{ d: "M3 4.6h1.4M6.4 4.6h6.6M3 8h1.4M6.4 8h6.6M3 11.4h1.4M6.4 11.4h6.6" }],
-  // I19c — a framed set of bars: "several charts", not "one chart".
-  chart: [
-    { d: "M2.6 3.4h10.8v9.2H2.6z" },
-    { d: "M5.4 10.6V7.2M8 10.6V5.4M10.6 10.6V8.6" },
-  ],
-  // I10 (C2) — the LEGACY key. Kept so this record stays total over DisplayMode, which is
-  // what makes "accept 'dashboard' on read forever" a compile-time guarantee rather than a
-  // promise. Same drawing: a stored 'dashboard' IS a chart.
-  dashboard: [
-    { d: "M2.6 3.4h10.8v9.2H2.6z" },
-    { d: "M5.4 10.6V7.2M8 10.6V5.4M10.6 10.6V8.6" },
-  ],
-  calendar: CALENDAR,
-  kanban: [{ d: "M2.8 3.4h3.1v9.2H2.8zM6.5 3.4h3.1v6.2H6.5zM10.2 3.4h3.1v7.6h-3.1z" }],
-  map: [
-    { d: "M8 2.6a3.6 3.6 0 0 1 3.6 3.6c0 2.7-3.6 7.2-3.6 7.2S4.4 8.9 4.4 6.2A3.6 3.6 0 0 1 8 2.6z" },
-    { d: circle(8, 6.1, 1.3) },
-  ],
-  // 2026-08-02 item 7 — the time-series view. Drawn as a framed grid with a trend running
-  // through it, because that is literally what the panel is: metric ROWS x bucket COLUMNS with
-  // a per-row line toggle. Deliberately not the plain `line` chart mark — a chart view and a
-  // time-series table must not be the same picture in the same rail.
-  timeseries: [
-    { d: "M2.6 3.4h10.8v9.2H2.6z" },
-    { d: "M2.6 6.6h10.8M6.2 3.4v9.2" },
-    { d: "M7.2 10.8l2-2.4 1.6 1.2 1.8-2.6" },
-  ],
-  // Wave-18 C6-CATALOG — an OPEN BOOK: two facing leaves with a spine between them, and a
-  // product block sitting on the left one. Every other mode in this table draws a way of
-  // arranging RECORDS; this one has to read as a printed artifact, so it is the only mark here
-  // with a spine and a gutter. Deliberately not a page-with-lines (`list` owns that reading) and
-  // not a framed grid (`grid`/`chart`/`timeseries` share the frame).
-  catalog: [
-    { d: "M2.4 4.2h4.6a1.6 1.6 0 0 1 1 .4l0 8a1.6 1.6 0 0 0-1-.4H2.4z" },
-    { d: "M13.6 4.2H9a1.6 1.6 0 0 0-1 .4l0 8a1.6 1.6 0 0 1 1-.4h4.6z" },
-    { d: "M3.9 6.4h2.3v2.8H3.9z" },
-  ],
-  // Wave-23 C9 — a SHEET WITH A WRITING LINE: two filled answer bars and an empty rule beneath
-  // them. Every other mode here draws a way of ARRANGING records that already exist; this one
-  // has to read as a record being MADE, so it is the only mark whose bottom line is open.
-  // Deliberately not a clipboard (nothing else here has a frame with a tab) and not a pencil
-  // (an edit affordance means something else app-wide).
-  // ⭐ Wave-27 C3 (owner item 8) — a CARD WITH TWO ARROWS LEAVING IT, left and right. Every
-  // other mark here draws an arrangement of many records; this one has to read as ONE record
-  // with two exits, because that is exactly what the deck is. Deliberately not a stack of cards
-  // (that is a lane, and `kanban` owns it) and not a hand or a gesture glyph (nothing else in
-  // this vocabulary draws a body part, and it would read as "drag" rather than "decide").
-  swipe: [
-    { d: "M5.4 3.4h5.2v9.2H5.4z" },
-    { d: "M3.6 8H1.4M2.8 6.8 1.4 8l1.4 1.2" },
-    { d: "M12.4 8h2.2M13.2 6.8 14.6 8l-1.4 1.2" },
-  ],
-  form: [
-    { d: "M3.4 2.8h9.2v10.4H3.4z" },
-    { d: "M5.6 5.6h4.8" },
-    { d: "M5.6 8h4.8" },
-    { d: "M5.6 10.6h2.6" },
-  ],
-  // W36-T04 — angle brackets over a baseline: the universal mark for "this is code", and the one
-  // shape in this table that is about the AUTHORING rather than about the arrangement of rows.
-  script: [
-    { d: "M6 5.4 3.2 8l2.8 2.6M10 5.4 12.8 8 10 10.6" },
-    { d: "M2.6 3.4h10.8v9.2H2.6z" },
-  ],
-};
-
-/**
- * Wave-9 I16 — one mark per CHART KIND. Total over `ChartKind`, so a kind added to C2's
- * vocabulary cannot ship without a drawing.
- *
- * ⚠ The owner asked for an icon on every chart-type option, and the wave-8 ruling stands:
- * an `<option>` cannot render SVG and unicode glyphs are gate-banned, so the chart-type
- * picker is NOT a native `<select>` — it is a radio-row list like the mode switcher, which
- * is the only shape that can carry a real mark.
- *
- * The key type is a string union declared here rather than imported from chartData.ts: this
- * module is a leaf (types + theme only) and chartData imports IT, not the reverse.
- */
-export type ChartKindKey = "bar" | "line" | "area" | "donut" | "kpi" | "table";
-export const CHART_KIND_SHAPES: Record<ChartKindKey, IconShape[]> = {
-  bar: [{ d: "M3.2 12.8V7.4M6.4 12.8V4.2M9.6 12.8V8.8M12.8 12.8V5.8" }],
-  line: [
-    { d: "M2.6 11.2l3.2-3.4 2.6 2 4.9-5.2" },
-    { d: circle(5.8, 7.8, 0.9) },
-    { d: circle(8.4, 9.8, 0.9) },
-  ],
-  area: [
-    { d: "M2.6 12.4V9.2l3.2-3.2 2.6 2 4.9-4.6v9z" },
-    { d: "M2.6 9.2l3.2-3.2 2.6 2 4.9-4.6" },
-  ],
-  donut: [{ d: circle(8, 8, 5) }, { d: circle(8, 8, 2.1) }],
-  // A single big number: the KPI card. Drawn as a framed value rather than a glyph, so it
-  // reads as "one number" beside four marks that all read as "a distribution".
-  kpi: [{ d: "M2.6 3.8h10.8v8.4H2.6z" }, { d: "M5.4 9.6V6.4l1.9 3.2V6.4M9.4 6.4v3.2h1.8" }],
-  // Wave-16 C-CHARTCAP: a group-by aggregate table. Framed like the KPI (it is a card of
-  // values, not a distribution), with a header band and a column rule.
-  table: [
-    { d: "M2.6 3.4h10.8v9.2H2.6z" },
-    { d: "M2.6 6.2h10.8M7.2 6.2v6.4M2.6 9.4h10.8" },
-  ],
-};
-
-export const CHART_KIND_LABELS: Record<ChartKindKey, string> = {
-  bar: "Bar",
-  line: "Line",
-  area: "Area",
-  donut: "Donut",
-  kpi: "Single value",
-  table: "Table",
-};
-
-/** I16 — the pastel each chart kind wears, same family rule as MODE_TONE. */
-export const CHART_KIND_TONE: Record<ChartKindKey, FolderTone> = {
-  bar: "blue",
-  line: "green",
-  area: "green",
-  donut: "yellow",
-  kpi: "neutral",
-  table: "neutral",
-};
-
-/**
- * Wave-9 contract C5 (I15) — folder icon geometry. TOTAL over `FolderShape`, so a shape key
- * added to the wire contract in types.ts cannot ship without a drawing.
- *
- * Same 16x16 stroke vocabulary as everything above: these have to sit beside a mode icon in
- * the same rail and read as one family. `folder` is first because it is the default every
- * pre-wave-9 folder falls back to (I14: "existing folders get the folder icon").
- */
-export const FOLDER_SHAPE_PATHS: Record<FolderShape, IconShape[]> = {
-  folder: [{ d: "M2.4 12.6V4.2a.6.6 0 0 1 .6-.6h3.2l1.5 1.7h5.3a.6.6 0 0 1 .6.6v6.7a.6.6 0 0 1-.6.6H3a.6.6 0 0 1-.6-.6z" }],
-  star: [
-    { d: "M8 2.9l1.63 3.3 3.64.53-2.63 2.57.62 3.63L8 11.24 4.74 12.93l.62-3.63L2.73 6.73l3.64-.53z" },
-  ],
-  flag: [
-    { d: "M4.2 13.4V2.9" },
-    { d: "M4.2 3.4h7.6l-1.5 2.6 1.5 2.6H4.2z" },
-  ],
-  tag: [
-    { d: "M2.9 8.2V3.5a.6.6 0 0 1 .6-.6h4.7l5 5-5.3 5.3z" },
-    { d: circle(5.6, 5.6, 1) },
-  ],
-  bookmark: [{ d: "M4.4 2.9h7.2v10.4L8 10.7l-3.6 2.6z" }],
-  // Four of the host's shapes ALREADY exist in this file as a mode or a field-type mark.
-  // Reusing the geometry rather than drawing a second "chart" is the whole point of the
-  // one-source rule: a folder labelled Chart and the Chart view must not be two pictures.
-  grid: MODE_SHAPES.grid,
-  chart: MODE_SHAPES.dashboard,
-  map: MODE_SHAPES.map,
-  users: TYPE_SHAPES.user,
-  clock: TYPE_SHAPES.created_time,
-  heart: [{ d: "M8 13.1S2.7 9.8 2.7 6.4a2.9 2.9 0 0 1 5.3-1.6 2.9 2.9 0 0 1 5.3 1.6c0 3.4-5.3 6.7-5.3 6.7z" }],
-  bolt: [{ d: "M9.1 2.4L4.2 9.1h3.3l-.6 4.5 4.9-6.7H8.5z" }],
-};
-
-/**
- * Tone key → the pastel it FILLS with, and the -d weight it STROKES with.
- *
- * Both, not one: a folder mark is a ~14px glyph, and [[loopable-brand-palette]] is explicit
- * that a base pastel at that size smudges — LP_BLUE measures 1.88:1 on white. So the pastel
- * is the fill (a tinted body reads as "coloured") and the measured -deep variant carries the
- * outline (an outline that reads at all).
- *
- * The default tone is `neutral` — HOST's C5 key, not "grey". The whitelist is SHARED between
- * the two ends, so the name matters more than the word: a tone the host does not recognise
- * degrades to the default and the user's choice silently disappears on reload.
- */
-export const FOLDER_TONE_PAINT: Record<FolderTone, { fill: string; stroke: string }> = {
-  neutral: { fill: LP_LINE, stroke: LP_MUTED },
-  blue: { fill: LP_BLUE, stroke: LP_BLUE_DEEP },
-  green: { fill: LP_GREEN, stroke: LP_GREEN_DEEP },
-  yellow: { fill: LP_YELLOW, stroke: LP_YELLOW_DEEP },
-  red: { fill: LP_RED, stroke: LP_RED_DEEP },
-};
-
-export const FOLDER_TONE_LABELS: Record<FolderTone, string> = {
-  neutral: "Neutral",
-  blue: "Blue",
-  green: "Green",
-  yellow: "Yellow",
-  red: "Red",
-};
-
-export const FOLDER_SHAPE_LABELS: Record<FolderShape, string> = {
-  folder: "Folder",
-  star: "Star",
-  flag: "Flag",
-  tag: "Tag",
-  bookmark: "Bookmark",
-  grid: "Table",
-  chart: "Chart",
-  map: "Map",
-  users: "People",
-  clock: "Clock",
-  heart: "Heart",
-  bolt: "Priority",
-};
-
-/**
- * Wave-9 I14 — the tone each CREATABLE view type wears in the "+ Create new…" flyout.
- *
- * The owner asked for "pastel-coloured icons", and a flyout where every row is the same grey
- * is a list you read rather than scan. Assigned by family, not by rotation: the two
- * record-shaped modes (grid/list) share blue, the two time-shaped ones (calendar/kanban)
- * share yellow, chart is green because it is the analytical one, map is red because it is
- * the geographic one. Folder is grey — it is not a view, and the flyout's last row should
- * not compete with the six above it.
- */
-/**
- * Human labels for every display mode. Moved here from viewModes.tsx in wave 9 so the label
- * sits beside the geometry, the way TYPE_LABELS does — the mode switcher, the create flyout
- * and the create prompt now read ONE table instead of three. C2's "Dashboard" → "Chart"
- * rename is a single line here as a direct result.
- */
-export const MODE_LABELS: Record<DisplayMode, string> = {
-  grid: "Grid",
-  chart: "Chart",
-  // Legacy: never OFFERED (it is not in CREATABLE_MODES) but still labelled, because a view
-  // read before normalisation must never render a blank switcher chip.
-  dashboard: "Chart",
-  list: "List",
-  calendar: "Calendar",
-  kanban: "Kanban",
-  map: "Map",
-  timeseries: "Time series",
-  catalog: "Catalog",
-  // Wave-23 C9 — the mode that COLLECTS records. "Form", the word the whole product uses for
-  // it (the public page, the share panel, the `form_submitted` trigger); a synonym here would
-  // be the one surface calling it something else.
-  form: "Form",
-  // ⭐ Wave-27 C3 (item 8) — the owner's own word for it. Not "Triage" or "Review": the gesture
-  // IS the name here, and the two candidates both collide with vocabulary this product already
-  // spends elsewhere (a `review` automation decision, the retired review lanes).
-  swipe: "Swipe",
-  // W36-T04 — the owner's own words are "code script"; "Script" is the half that is not implied
-  // by the icon, and the product has no other surface competing for the noun.
-  script: "Script",
-};
-
-/**
- * I14 — the view types the "+ Create new…" flyout OFFERS, in the order it lists them.
- *
- * Deliberately NOT `DISPLAY_MODES`, and deliberately here rather than inside ViewSidebar.tsx:
- * C2 makes `'dashboard'` a mode that stays READABLE forever (every view saved before the
- * rename sits in it) while ceasing to be OFFERABLE once `'chart'` exists — one list cannot
- * express both. Living in this pure data module means the gate can assert the offered set
- * without importing a React component, and I10 becomes a one-line edit in one file.
- */
-// 2026-08-02 item 7 — `timeseries` was deliberately held OUT of this list until the host
-// accepted the name, because a mode may be READABLE before it is OFFERABLE (the same split C2
-// wrote for 'dashboard', running forwards): `aios_grid._clean_display` drops a mode it does
-// not know, so offering it early would let a user create a view that silently reverts to a
-// grid on the next read with nothing going red. HOST posted "ACCEPTANCE LANDED" with
-// `DISPLAY_MODES += timeseries`, so it is offerable now.
-//
-// wave17 GRID, owner item 10 — THE ORDER BELOW IS THE OWNER'S, stated verbatim:
-// Grid · Chart · Calendar · Kanban · Time series · Map · List.
-//
-// ⚠ It supersedes the two orderings this list has carried before it, and the reasoning that
-// produced them is now WRONG rather than merely outranked, so it is not left here to be
-// re-applied: `timeseries` was "listed last… it belongs beside Chart", and `list` sat second
-// as the other record-shaped mode. The owner put Time series FIFTH and List LAST. An order is
-// a product decision, so it is asserted in `verify_icons` rather than left to a comment —
-// nothing else on screen would go red if a future edit re-sorted it "sensibly".
-// Wave-18 C6-CATALOG — `catalog` was held out of this list until `aios_grid.DISPLAY_MODES`
-// accepted the name, the same hold `timeseries` and `chart` served before it. SESSION A posted
-// "C6 HOST MIRROR APPLIED — you may flip CREATABLE_MODES now" (2026-08-03), so it is offerable.
-// It lands LAST by contract: the owner's seven-mode order above is a product decision and the
-// new mode joins the end of it rather than being sorted into it.
-// ⭐ Wave-27 C3 (owner item 8) — `swipe` is HELD OUT of this list, and the reason corrects a
-// mistake this file made an hour earlier.
-//
-// ⛔ THE HOLD WAS NEVER ONLY ABOUT THE TWO REGISTRIES. It was first written as "do not offer a
-// mode the HOST has not accepted", and one session owning both registries this wave genuinely
-// does close that half — which is what made it tempting to skip. But the rule the hold really
-// encodes is broader and this wave proved it: **do not offer a mode whose CONSUMER does not
-// exist.** `swipe` was briefly listed here while `CustomerGrid`'s mode dispatch had no branch
-// for it, so picking "Swipe" wrote a mode the host now happily PERSISTS, and the body rendered
-// a grid under a chip reading "View · Swipe" — surviving reload, with the agreement leg green
-// because it only ever compared two lists.
-//
-// So the hold stood until `SwipeView` was mounted (contract C3), and it was not a mailbox
-// handshake: `verify_icons` DERIVES the condition — either `swipe` is absent here, or
-// `CustomerGrid.tsx` mounts `SwipeView`. `form` (wave-23) is the same defect from the other
-// direction, sitting unoffered because its host mirror never landed (DEBT D-90).
-//
-// ⛔ THE HOLD OUTLIVED THE WAVE, AND THAT IS THE LESSON WORTH MORE THAN THE FEATURE.
-// Wave 27 closed with the mount NEVER LANDING. `SwipeView.tsx` shipped, the server accepted
-// `swipe`, all four maps above carried it, 50 gates were green, the wave-27 mailbox recorded
-// "RESOLVED BY C (swipe mounted)", the close-out booked D-102 — a negative control FOR the
-// swipe carry — and the owner could not find the view because **nothing imported the file.**
-// The derived gate could not catch it: its condition is a DISJUNCTION and **absence satisfies
-// it**, so the unshipped state was permanently green ([[gate-can-report-green-on-nothing]]).
-// A hold that is safe to leave in place is a hold nothing forces you to lift.
-// The audit query that found it, after the battery did not: for each artifact a wave adds, grep
-// for its CONSUMER — who imports/mounts/registers it — excluding the file itself, `_test/`, css
-// and comments. `SwipeView` had four hits and three were prose.
-// Mounted 2026-08-09 (`CustomerGrid.tsx`, `displayMode === "swipe"`), so `swipe` is offerable.
-// It lands LAST, by `catalog`'s rule: the owner's mode order is a product decision and a new
-// mode joins the end of it rather than being sorted into it.
-export const CREATABLE_MODES: DisplayMode[] = [
-  "grid",
-  "chart",
-  "calendar",
-  "kanban",
-  "timeseries",
-  "map",
-  "list",
-  "catalog",
-  "swipe",
-  // Mounted 2026-08-11 (`CustomerGrid.tsx`, `displayMode === "form"` renders `FormInterface`), so
-  // `form` is offerable and its `HELD_MODES` entry came out in the same edit — the hold's own text
-  // named this mount as its release condition. ⚠ Found by `verify_icons.py::mode_parity` law E
-  // during /validate-wave, NOT by the lane that mounted it: T29 mounted the component and T41 built
-  // the Interface group, and between them the DOOR was never opened — the wave's biggest new
-  // surface was unreachable behind two green tickets.
-  "form",
-];
-
-/**
- * ⭐ WAVE-29 R6 (owner item 10) — the kind dropdown splits under TWO headers, and the strings are
- * the owner's own: exactly `View` and `Interface`. Not "View as" (what the popover said before),
- * not "Custom interface".
- *
- * The line the two groups draw: a **View** ARRANGES the records — the same rows, re-shaped (a
- * grid, a board, a chart). An **Interface** is a SURFACE BUILT OVER them: a map is a picture of the
- * world with records placed on it, a catalog is a published artifact, a form is a door records come
- * IN through and shows no records at all.
- *
- * ⭐ WAVE-33 item 9 AMENDED THAT LINE, and the owner drew it one notch differently than R6 did:
- * `swipe` and `timeseries` moved from View to Interface. The reading that makes both rulings one
- * rule — and the one the next mode should be grouped by — is **what the surface is FOR**, not how
- * many rows it shows. A deck triages records one at a time and WRITES to them; a trend answers a
- * question about a measure over time; neither hands you the row set re-shaped, which is what every
- * remaining View does. ⚠ Do NOT re-derive the split from `MODE_TONE` below: the tones still say
- * `catalog`/`form` are neutral because they arrange nothing, and `swipe`/`timeseries` are toned,
- * so tone and group are no longer the same cut. Group membership lives HERE and only here.
- *
- * ⚠ TOTAL over `DisplayMode`, so tsc refuses a new mode with no group rather than letting it
- * vanish from the dropdown: membership is derived by FILTERING `CREATABLE_MODES` through this
- * map, and a mode whose group label matched nothing would silently stop being offered while
- * every existing check (paintable, labelled, toned, unique, ordered) stayed green.
- * `dashboard` is grouped like the `chart` it is the legacy spelling of — it is never offered, and
- * a partial map is a worse answer than an unused entry.
- */
-export const MODE_GROUP_LABELS = ["View", "Interface"] as const;
-export type ModeGroup = (typeof MODE_GROUP_LABELS)[number];
-
-export const MODE_GROUP: Record<DisplayMode, ModeGroup> = {
-  grid: "View",
-  list: "View",
-  kanban: "View",
-  calendar: "View",
-  chart: "View",
-  dashboard: "View",
-  // ⭐ WAVE-33 item 9 (owner, verbatim): "Let's move Swipe and Time-series under Interface instead
-  // of under View, when a user toggle it." See the amended taxonomy note above — a deck and a
-  // trend are both surfaces a person WORKS IN, not re-shapings of the row set.
-  timeseries: "Interface",
-  swipe: "Interface",
-  map: "Interface",
-  catalog: "Interface",
-  form: "Interface",
-  // W36-T04 — "Interface", by the W33 item-9 taxonomy: a script view is a surface somebody WORKS
-  // IN (writes, runs, reads an answer), not a re-shaping of the row set.
-  script: "Interface",
-};
-
-/**
- * The offered modes, split into R6's two groups — DERIVED, never a third hand-written list.
- *
- * ⚠ ORDER: R6 names each group's MEMBERS; the order inside a group stays `CREATABLE_MODES`', which
- * is the wave-17 owner ruling ("Grid · Chart · Calendar · Kanban · Time series · Map · List") and
- * is separately asserted. The two rulings are compatible read this way and only this way: R6 moved
- * `map` out of the run of views, so wave-17's single sequence can no longer exist as one list, but
- * every pair it ordered is still in that relative order here.
- */
-export const CREATABLE_GROUPS: readonly { label: ModeGroup; modes: DisplayMode[] }[] =
-  MODE_GROUP_LABELS.map((label) => ({
-    label,
-    modes: CREATABLE_MODES.filter((m) => MODE_GROUP[m] === label),
-  }));
-
-export const MODE_TONE: Record<DisplayMode, FolderTone> = {
-  grid: "blue",
-  list: "blue",
-  chart: "green",
-  dashboard: "green",
-  calendar: "yellow",
-  kanban: "yellow",
-  map: "red",
-  // Green with `chart`: it is the other analytical mode, and the two belong to one family.
-  timeseries: "green",
-  // Wave-18 C6-CATALOG — NEUTRAL, and it is the honest pick rather than the leftover one. The
-  // four colour tones each name a family of ways to arrange records (blue = tabular, green =
-  // analytical, yellow = board/date, red = spatial); a catalog arranges nothing — it is a
-  // published artifact. Giving it a colour would file it under a family it is not in.
-  catalog: "neutral",
-  // Wave-23 C9 — NEUTRAL, and for `catalog`'s reason rather than by elimination: the four tones
-  // name families of ways to ARRANGE records (blue tabular, green analytical, yellow
-  // board/date, red spatial). A form arranges nothing — it is a door records come in through —
-  // so giving it a colour would file it under a family it is not in.
-  form: "neutral",
-  // ⭐ Wave-27 C3 — YELLOW, with `kanban`, and this is a family claim rather than a leftover:
-  // a swipe deck writes the SAME single-select a kanban stacks by (R2 binds it to one), so the
-  // two are one family seen at two zooms — all the lanes at once, or one card at a time. Filing
-  // it neutral (the `catalog`/`form` reasoning) would be wrong for the opposite reason those
-  // two are neutral: this mode does arrange records, and it arranges them by the board's field.
-  swipe: "yellow",
-  // W36-T04 — NEUTRAL, by `catalog`'s and `form`'s rule rather than by elimination: the four
-  // tones name families of ways to ARRANGE records (blue tabular, green analytical, yellow
-  // board/date, red spatial). A script arranges nothing; it emits whatever it computes.
-  script: "neutral",
-};
-
-/**
- * Human labels for every field type. Lives here beside the icons so the two
- * halves of "how a field type presents itself" stay in one file (ColumnMenu
- * imports it rather than keeping a second copy).
- */
-export const TYPE_LABELS: Record<FieldType, string> = {
-  // ⭐ WAVE-29 item 3 — the owner's own words: "Change 'Single line text' to 'Text', keep it
-  // simple for the Field type". Airtable's phrase described the column's SHAPE (one line, versus
-  // its long-text sibling); this product has no multi-line text kind, so the qualifier
-  // distinguished the type from nothing and only made the commonest row in the menu the longest.
-  // ✅ The STORED key is `"text"` and always was — the old string was never persisted anywhere,
-  // client or server, so this is a label change with no migration behind it.
-  text: "Text",
-  select: "Single select",
-  multiselect: "Multi select",
-  user: "Assignee",
-  int: "Number",
-  currency: "Currency",
-  pct: "Percent",
-  date: "Date",
-  checkbox: "Checkbox",
-  phone: "Phone number",
-  email: "Email",
-  url: "URL",
-  rating: "Rating",
-  created_time: "Created time",
-  formula: "Formula",
-  // Wave-18 C5-AUTOFIELD (D's spec, applied by C).
-  automation: "Automation",
-  // Wave-22 C7 — spawned by automations (not in CREATABLE_TYPES), so this label mostly shows
-  // on headers and the field gear, not the create menu.
-  metric: "Metric",
-  // Wave-19 R7 — the picture column.
-  image: "Image",
-  // Wave-23 C7 — the structured-document column. "JSON" rather than "Structured data": it is
-  // the word on the wire, in the viewer's raw tab and in every error the server can return, and
-  // a friendlier synonym would be the only place in the product using a different one.
-  json: "JSON",
-  // ⭐ 2026-08-07 — Airtable's own wording, deliberately. "Link to another record" is what a
-  // person migrating from Airtable searches this menu for, and inventing a synonym ("Relation",
-  // "Reference") would make the feature they came for look absent.
-  link: "Link to another record",
-  rollup: "Rollup",
-  // ⭐ Wave-27 item 13 (R13) — "Code", not "Snippet" or "Source": it is the word the field kind
-  // is called everywhere else in this wave (the ruling, the language picker, the viewer header),
-  // and it says what the column holds without implying the product will run it.
-  code: "Code",
-  // ⭐ WAVE 34 · T53 (R13), on F's ask (`F-2`) — the owner's own noun for the kind: "a field kind
-  // called AI enrichment". Not "AI field" (every field in an AI-built view would qualify) and not
-  // "Generate" (that names the verb, and the column's value is the point, not the act).
-  ai_enrich: "AI enrichment",
-  status: "Lifecycle status (Odoo)", // never creatable; present so the map stays total
-};
-
-/**
- * ⭐ WAVE-29 C7 (item 17) — THE COLUMN-SUMMARY vocabulary: what a field's `agg` may be, which is
- * what the totals row and the per-group subtotals compute. Server twin:
- * `platform/aios_grid.py::FIELD_AGGS`, and `verify_icons.py::agg_parity` reads BOTH FILES and
- * compares them name-for-name in order — the cross-language boundary is the one a type cannot
- * police, so it gets a gate.
- *
- * ⛔ ONE CLIENT LIST, IMPORTED — never re-declared. `aggregations.ts` and the field editor import
- * from here rather than keeping their own copy, which is why this lives in the pure data module
- * beside `TYPE_LABELS` and `CREATABLE_MODES`: a second client list would need a second gate, and
- * the two would drift in the direction nobody is watching. C7 says "C publishes, E mirrors"; a
- * mirror that is an import cannot fall out of step at all.
- *
- * ⛔ NOT the chart vocabulary. `CHART_AGGS` (`aios_grid.py`, `viz/chartData.ts`) spells it `avg`
- * and gatekeeps a STORED value — renaming it would silently turn saved charts into sums. This
- * list spells it `average`, matching `ROLLUP_FNS` (16 names, live in production), so a column
- * summary and a rollup fold say the same word for the same operation.
- *
- * ⚠ `median` is net-new — in neither `CHART_AGGS` nor `ROLLUP_FNS`.
- * ⚠ `count` counts ROWS in the scope, not non-blank cells.
- * ⚠ Which types may carry which: `sum/average/median/min/max` are numeric-only and the evaluator
- * for that is ALREADY `isNumericFieldType` (types.ts) — do not write a second one. `count` is
- * legal on any type.
- */
-// ⭐ W29-T74 — an ALIAS of `types.AggName`, not a fifth copy of the union. `Field.agg` is typed
-// `AggName`, so a second literal here would be a type that has to be kept in step by eye with a
-// type the compiler already owns — the same defect as the array below, one level up.
-export type FieldAgg = AggName;
-
-/** ORDERED — the order is the picker's order, on both engines. */
-export const FIELD_AGGS: readonly FieldAgg[] = [
-  "sum",
-  "average",
-  "median",
-  "min",
-  "max",
-  "count",
-];
-
-/**
- * Human labels, in the summary bar's own compact register (Airtable's wording).
- *
- * ⚠ `FIELD_AGG_LABELS`, not `AGG_LABELS`, and the prefix is load-bearing: `viewModes.tsx` already
- * has a module-local `AGG_LABELS` for the CALENDAR summary picker over `CHART_AGGS`, where the
- * same five names wear different words ("Total", "Lowest", "Highest") for a day cell. Two tables
- * called `AGG_LABELS` describing two vocabularies is how a future import lands on the wrong one.
- */
-export const FIELD_AGG_LABELS: Record<FieldAgg, string> = {
-  sum: "Sum",
-  average: "Average",
-  median: "Median",
-  min: "Min",
-  max: "Max",
-  count: "Count",
-};
-
-
-// ------------------------------------------------------------ glide sprites
-
-/** Serialize one shape to SVG source in an explicit colour (canvas sprites get
- *  no `currentColor` — glide hands the painter the theme colours directly). */
-function shapeSource(s: IconShape, color: string): string {
-  return s.fill
-    ? `<path d="${s.d}" fill="${color}"/>`
-    : `<path d="${s.d}" fill="none" stroke="${color}" stroke-width="1.35" ` +
-        `stroke-linecap="round" stroke-linejoin="round"/>`;
-}
-
-function sprite(shapes: IconShape[]) {
-  return ({ fgColor }: { fgColor: string }) =>
-    `<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16">` +
-    shapes.map((s) => shapeSource(s, fgColor)).join("") +
-    `</svg>`;
-}
-
-/** Glide header-icon NAME for a field type — the `icon` a GridColumn asks for. */
-export function typeIconName(type: FieldType): string {
-  return `t_${type}`;
-}
-
-/**
- * The sprite map handed to <DataEditor headerIcons>. One entry per field type
- * (I20 draws the type mark in every column header), built from the same shapes
- * the React icons use.
- *
- * Colour: glide's "normal" variant paints with `theme.fgIconHeader`, which is
- * why theme.ts must set it — the library default is #FFFFFF, i.e. invisible on
- * our header (that was I21's actual bug, not a too-pale hex of ours).
- */
-export const TYPE_SPRITES: Record<string, ({ fgColor }: { fgColor: string }) => string> =
-  Object.fromEntries(
-    (Object.keys(TYPE_SHAPES) as FieldType[]).map((t) => [typeIconName(t), sprite(TYPE_SHAPES[t])])
-  );
-
-/**
- * The header sprite map handed to <DataEditor headerIcons>. Two families:
- *
- *   t_<type>   wave-8 I20 - the field-TYPE mark, drawn in EVERY column header,
- *              from the same shapes the React icons use. Painted by glide in
- *              `theme.fgIconHeader`.
- *   aiosInfo   wave-5 item 6, restyled by wave-9 I3 - the description (i).
- *              OUTLINE ONLY: a dark-grey ring with a transparent interior, per
- *              the owner. It still deliberately IGNORES the colours glide hands
- *              it, for the reason wave-8 recorded - glide's "special" variant is
- *              accentColor behind bgHeader, which under the C1 pastels is a pale
- *              glyph on a pale disc, i.e. I21 in a new costume.
- *              ⚠ It is NO LONGER a column `overlayIcon`. Glide draws an overlay
- *              at a hard-coded offset from the TYPE mark on the far LEFT of the
- *              header (drawHeaderInner: `drawX + 9`), and I3 wants it RIGHT-
- *              aligned. It is now painted by CustomerGrid's `drawHeader`
- *              callback at `infoMarkRect()` - see overlayPlacement.ts.
- */
-export const HEADER_ICONS: Record<string, (c: { fgColor: string; bgColor: string }) => string> = {
-  ...TYPE_SPRITES,
-  aiosInfo: () =>
-    `<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16">` +
-    `<circle cx="8" cy="8" r="6.1" fill="none" stroke="${LP_MUTED}" stroke-width="1.25"/>` +
-    `<path d="M8 7.4v3.5" fill="none" stroke="${LP_MUTED}" stroke-width="1.4" ` +
-    `stroke-linecap="round"/>` +
-    `<circle cx="8" cy="5.1" r="0.85" fill="${LP_MUTED}"/>` +
-    `</svg>`,
-};
+// ---------------------------------------------------------------------------
+// customer-grid / iconShapes.ts
+// Wave-8 items I18 + I20 — ONE geometry source for the grid's icon vocabulary,
+// rendered by TWO very different painters:
+//
+//   - React  <FieldTypeIcon> / <ModeIcon>  — DOM svg in panels, popovers, menus
+//   - glide  headerIcons sprites           — canvas, drawn from an SVG *string*
+//
+// Glide's sprite API takes a function returning SVG SOURCE, so a header icon can
+// never be a React component. Keeping the paths as DATA (IconShape[]) and giving
+// each painter its own thin renderer is what stops the two from drifting — the
+// alternative (hand-copying every path into a template literal) guarantees the
+// header and the panel eventually disagree about what a "date" looks like.
+//
+// Geometry rules: 16x16 viewBox, stroke-based, 1.35 stroke, round caps/joins,
+// currentColor. Vector paths only — NEVER emoji (owner constant).
+// ---------------------------------------------------------------------------
+
+import type { AggName, DisplayMode, FieldType, FolderShape, FolderTone } from "./types";
+import {
+  LP_BLUE,
+  LP_BLUE_DEEP,
+  LP_GREEN,
+  LP_GREEN_DEEP,
+  LP_LINE,
+  LP_MUTED,
+  LP_RED,
+  LP_RED_DEEP,
+  LP_YELLOW,
+  LP_YELLOW_DEEP,
+} from "./theme";
+
+/** One drawing primitive. `fill: true` fills the path instead of stroking it
+ *  (the rating star is the only shape that reads better solid). */
+export type IconShape = { d: string; fill?: boolean };
+
+/** A circle as a path — two half-arcs. Sprites are SVG *source*, so every shape
+ *  has to survive being serialized into a string; paths do, <circle> elements
+ *  would need a second serializer branch for no benefit. */
+const circle = (cx: number, cy: number, r: number): string =>
+  `M${cx - r} ${cy}a${r} ${r} 0 1 0 ${r * 2} 0a${r} ${r} 0 1 0 ${-r * 2} 0`;
+
+const CALENDAR: IconShape[] = [
+  { d: "M3.2 4.6h9.6v8.2H3.2z" },
+  { d: "M3.2 7.2h9.6" },
+  { d: "M5.8 3v3.2" },
+  { d: "M10.2 3v3.2" },
+];
+
+/**
+ * Field type → icon geometry. A TOTAL record on purpose: adding a FieldType
+ * without an icon is a compile error, not a silently blank header.
+ */
+export const TYPE_SHAPES: Record<FieldType, IconShape[]> = {
+  text: [{ d: "M3 5h10M3 8h10M3 11h6" }],
+  status: [{ d: "M4 13V3.5h7.6L10.1 6l1.5 2.5H4" }],
+  currency: [
+    { d: "M8 2.8v10.4" },
+    { d: "M10.6 5.4A2.6 2.6 0 0 0 8.2 4.2H7.4a2 2 0 0 0 0 4h1.2a2 2 0 0 1 0 4H7.8a2.6 2.6 0 0 1-2.4-1.4" },
+  ],
+  int: [{ d: "M6.2 3L4.8 13M11.2 3l-1.4 10M3.4 6.2h9.2M2.9 9.8h9.2" }],
+  date: CALENDAR,
+  pct: [
+    { d: circle(4.6, 4.6, 1.6) },
+    { d: circle(11.4, 11.4, 1.6) },
+    { d: "M12.2 3.9L3.8 12.3" },
+  ],
+  select: [{ d: "M3.2 3.8h9.6v8.4H3.2z" }, { d: "M6.2 7.2l1.8 1.8 1.8-1.8" }],
+  user: [
+    { d: circle(8, 6, 2.4) },
+    { d: "M3.6 13c0-2.4 2-3.8 4.4-3.8s4.4 1.4 4.4 3.8" },
+  ],
+  multiselect: [
+    { d: "M3 4.6h2.2v2.2H3zM3 9.2h2.2v2.2H3z" },
+    { d: "M7.2 5.7h6M7.2 10.3h6" },
+  ],
+  checkbox: [{ d: "M3.4 3.4h9.2v9.2H3.4z" }, { d: "M5.8 8.1l1.8 1.9 3.4-3.9" }],
+  phone: [
+    { d: "M5.1 3.2L7 5.1 5.6 7a7.2 7.2 0 0 0 3.4 3.4l1.9-1.4 1.9 1.9-1.5 1.6c-3 .5-8.3-4.8-7.8-7.8z" },
+  ],
+  email: [{ d: "M3 4.4h10v7.2H3z" }, { d: "M3 4.9l5 3.9 5-3.9" }],
+  url: [
+    { d: "M7 5.4L8.4 4a2.6 2.6 0 0 1 3.7 3.7L10.7 9" },
+    { d: "M9 10.6L7.6 12a2.6 2.6 0 0 1-3.7-3.7L5.3 7" },
+    { d: "M6.2 9.8l3.6-3.6" },
+  ],
+  rating: [
+    {
+      d: "M8 2.9l1.63 3.3 3.64.53-2.63 2.57.62 3.63L8 11.24 4.74 12.93l.62-3.63L2.73 6.73l3.64-.53z",
+      fill: true,
+    },
+  ],
+  created_time: [{ d: circle(8, 8, 5.2) }, { d: "M8 4.9v3.4l2.3 1.4" }],
+  formula: [
+    { d: "M5.6 12.8V5.4a2 2 0 0 1 3.2-1.6" },
+    { d: "M4.2 7.6h4.6" },
+    { d: "M10.2 8.4l3 3.4M13.2 8.4l-3 3.4" },
+  ],
+  // Wave-18 C5-AUTOFIELD (D's spec, applied by C as client-vocab registrar). A 290° cycle ring
+  // with an arrowhead, wrapped around a solid run-triangle: a job that runs, repeatedly.
+  // Deliberately NOT a bolt (`FOLDER_SHAPE_PATHS.bolt` already means "Priority") and not a clock
+  // (`created_time` owns the closed rim + hands).
+  automation: [
+    { d: "M10.8 4.1A4.8 4.8 0 1 1 5.3 4.1" },
+    { d: "M4.2 6L5.3 4.1 3.1 4.5" },
+    { d: "M6.9 6.1L9.8 8 6.9 9.9z", fill: true },
+  ],
+  // Wave-22 C7 (added by C as client-vocab registrar, the W18 automation precedent). A rising
+  // series on an axis: a measure OVER TIME, which is what a metric field is. Deliberately not
+  // the formula fx (that computes over the ROW) and not a bare number (int owns ##).
+  metric: [
+    { d: "M3.2 3.2v9.6h9.6" },
+    { d: "M5 10.4l2.4-2.6 1.9 1.5 3.1-3.9" },
+  ],
+  // Wave-23 C7 — TWO BRACES facing each other with a dot between them: the universal mark for
+  // "a structured document", and the one glyph in this table that draws its own SYNTAX rather
+  // than a picture of what the value means. Deliberately not a document page (nothing here owns
+  // that yet, but a page reads as a file/attachment, which a json cell is not) and not a tree
+  // of nodes (too fine to survive 16px). The centre dot is what keeps the two braces from
+  // reading as parentheses at small sizes.
+  json: [
+    { d: "M6.4 3.2c-1.5 0-1.5 3.4-1.5 3.4S4.8 8 3.4 8s1.5 1.4 1.5 1.4 0 3.4 1.5 3.4" },
+    { d: "M9.6 3.2c1.5 0 1.5 3.4 1.5 3.4s.1 1.4 1.5 1.4-1.5 1.4-1.5 1.4 0 3.4-1.5 3.4" },
+    { d: circle(8, 8, 0.85), fill: true },
+  ],
+  // ⭐ Wave-27 item 13 (R13) — THE ANGLE BRACKETS, the mark every editor on earth uses for
+  // "this is source". Drawn as two chevrons with a slash leaning between them, which is what
+  // separates it from `json` two entries up: json draws BRACES (a document's own syntax), code
+  // draws BRACKETS (a snippet's). Deliberately not a terminal prompt (that reads as "run this",
+  // and R13 is explicit there is no execution engine) and not a page of lines (`list` mode and
+  // `text` already trade on that reading).
+  code: [
+    { d: "M5.6 4.9 2.6 8l3 3.1" },
+    { d: "M10.4 4.9 13.4 8l-3 3.1" },
+    { d: "M9.1 3.6 6.9 12.4" },
+  ],
+  // Wave-19 R7 — a framed picture: the mount, a sun, and the hill line every photo glyph
+  // resolves to at 16px. Drawn on the same 16-unit grid as its neighbours.
+  image: [
+    { d: "M2.6 3.4h10.8v9.2H2.6z" },
+    { d: circle(6, 6.3, 1.1) },
+    { d: "M2.6 10.6L6.1 7.6l2.5 2.1 2.2-1.8 2.6 2.2" },
+  ],
+  // ⭐ 2026-08-07 — TWO INTERLOCKING CHAIN LINKS, the one glyph everybody already reads as
+  // "this points at something else". Drawn as two rounded rectangles overlapping at the centre
+  // rather than as an arrow into a box: an arrow would mean navigation, and a link column is a
+  // relation that exists in both directions whether or not you follow it.
+  link: [
+    { d: "M6.6 5.2H4.9a2.8 2.8 0 000 5.6h1.7" },
+    { d: "M9.4 5.2h1.7a2.8 2.8 0 010 5.6H9.4" },
+    { d: "M5.6 8h4.8" },
+  ],
+  // ⭐ 2026-08-07 — THREE BARS FOLDING INTO ONE, read top-to-bottom: many linked values
+  // collapsing to a single aggregate. Deliberately not a sigma (too fine at 16px, and it would
+  // claim SUM when the function is chosen per column) and not a funnel (that is filtering,
+  // which is what `limit` does — a different half of the same field).
+  rollup: [
+    { d: "M3.2 4.4h9.6" },
+    { d: "M4.8 8h6.4" },
+    { d: "M6.6 11.6h2.8" },
+  ],
+  // ⭐ WAVE 34 · T53 (R13), drawn by C on F's ask (`F-2`) — AI ENRICHMENT.
+  // The SPARKLE, because it is the product's own AI mark already: `Shell.tsx::SparkIcon` wears it
+  // on the Assistant rail row, so a column the AI fills reads as the same family rather than as a
+  // second vocabulary for one idea. Deliberately NOT the `automation` cycle-ring two entries up
+  // (that means "a job that runs, repeatedly", and an enrichment can be manual) and not a robot
+  // head (`Shell.tsx::RobotIcon` claims that for the Agents MODULE; a field is not a module).
+  // ⚠ TWO stars, not one: a lone four-point star at 16px with a 1.35 stroke reads as a plus sign.
+  // The small companion is what makes the mark say "sparkle".
+  ai_enrich: [
+    { d: "M6.6 2.6l1.3 3.1 3.1 1.3-3.1 1.3-1.3 3.1-1.3-3.1L2.2 7l3.1-1.3z" },
+    { d: "M11.9 9.8l.7 1.6 1.6.7-1.6.7-.7 1.6-.7-1.6-1.6-.7 1.6-.7z" },
+  ],
+};
+
+/**
+ * Display mode → icon geometry (I18). Also total: the wave-8 Dashboard mode
+ * cannot land in DISPLAY_MODES without the compiler demanding its icon here.
+ */
+export const MODE_SHAPES: Record<DisplayMode, IconShape[]> = {
+  grid: [
+    { d: "M2.6 3.4h10.8v9.2H2.6z" },
+    { d: "M2.6 6.5h10.8M2.6 9.5h10.8M6.4 3.4v9.2M10 3.4v9.2" },
+  ],
+  list: [{ d: "M3 4.6h1.4M6.4 4.6h6.6M3 8h1.4M6.4 8h6.6M3 11.4h1.4M6.4 11.4h6.6" }],
+  // I19c — a framed set of bars: "several charts", not "one chart".
+  chart: [
+    { d: "M2.6 3.4h10.8v9.2H2.6z" },
+    { d: "M5.4 10.6V7.2M8 10.6V5.4M10.6 10.6V8.6" },
+  ],
+  // I10 (C2) — the LEGACY key. Kept so this record stays total over DisplayMode, which is
+  // what makes "accept 'dashboard' on read forever" a compile-time guarantee rather than a
+  // promise. Same drawing: a stored 'dashboard' IS a chart.
+  dashboard: [
+    { d: "M2.6 3.4h10.8v9.2H2.6z" },
+    { d: "M5.4 10.6V7.2M8 10.6V5.4M10.6 10.6V8.6" },
+  ],
+  calendar: CALENDAR,
+  kanban: [{ d: "M2.8 3.4h3.1v9.2H2.8zM6.5 3.4h3.1v6.2H6.5zM10.2 3.4h3.1v7.6h-3.1z" }],
+  map: [
+    { d: "M8 2.6a3.6 3.6 0 0 1 3.6 3.6c0 2.7-3.6 7.2-3.6 7.2S4.4 8.9 4.4 6.2A3.6 3.6 0 0 1 8 2.6z" },
+    { d: circle(8, 6.1, 1.3) },
+  ],
+  // 2026-08-02 item 7 — the time-series view. Drawn as a framed grid with a trend running
+  // through it, because that is literally what the panel is: metric ROWS x bucket COLUMNS with
+  // a per-row line toggle. Deliberately not the plain `line` chart mark — a chart view and a
+  // time-series table must not be the same picture in the same rail.
+  timeseries: [
+    { d: "M2.6 3.4h10.8v9.2H2.6z" },
+    { d: "M2.6 6.6h10.8M6.2 3.4v9.2" },
+    { d: "M7.2 10.8l2-2.4 1.6 1.2 1.8-2.6" },
+  ],
+  // Wave-18 C6-CATALOG — an OPEN BOOK: two facing leaves with a spine between them, and a
+  // product block sitting on the left one. Every other mode in this table draws a way of
+  // arranging RECORDS; this one has to read as a printed artifact, so it is the only mark here
+  // with a spine and a gutter. Deliberately not a page-with-lines (`list` owns that reading) and
+  // not a framed grid (`grid`/`chart`/`timeseries` share the frame).
+  catalog: [
+    { d: "M2.4 4.2h4.6a1.6 1.6 0 0 1 1 .4l0 8a1.6 1.6 0 0 0-1-.4H2.4z" },
+    { d: "M13.6 4.2H9a1.6 1.6 0 0 0-1 .4l0 8a1.6 1.6 0 0 1 1-.4h4.6z" },
+    { d: "M3.9 6.4h2.3v2.8H3.9z" },
+  ],
+  // Wave-23 C9 — a SHEET WITH A WRITING LINE: two filled answer bars and an empty rule beneath
+  // them. Every other mode here draws a way of ARRANGING records that already exist; this one
+  // has to read as a record being MADE, so it is the only mark whose bottom line is open.
+  // Deliberately not a clipboard (nothing else here has a frame with a tab) and not a pencil
+  // (an edit affordance means something else app-wide).
+  // ⭐ Wave-27 C3 (owner item 8) — a CARD WITH TWO ARROWS LEAVING IT, left and right. Every
+  // other mark here draws an arrangement of many records; this one has to read as ONE record
+  // with two exits, because that is exactly what the deck is. Deliberately not a stack of cards
+  // (that is a lane, and `kanban` owns it) and not a hand or a gesture glyph (nothing else in
+  // this vocabulary draws a body part, and it would read as "drag" rather than "decide").
+  swipe: [
+    { d: "M5.4 3.4h5.2v9.2H5.4z" },
+    { d: "M3.6 8H1.4M2.8 6.8 1.4 8l1.4 1.2" },
+    { d: "M12.4 8h2.2M13.2 6.8 14.6 8l-1.4 1.2" },
+  ],
+  form: [
+    { d: "M3.4 2.8h9.2v10.4H3.4z" },
+    { d: "M5.6 5.6h4.8" },
+    { d: "M5.6 8h4.8" },
+    { d: "M5.6 10.6h2.6" },
+  ],
+  // W36-T04 — angle brackets over a baseline: the universal mark for "this is code", and the one
+  // shape in this table that is about the AUTHORING rather than about the arrangement of rows.
+  script: [
+    { d: "M6 5.4 3.2 8l2.8 2.6M10 5.4 12.8 8 10 10.6" },
+    { d: "M2.6 3.4h10.8v9.2H2.6z" },
+  ],
+};
+
+/**
+ * Wave-9 I16 — one mark per CHART KIND. Total over `ChartKind`, so a kind added to C2's
+ * vocabulary cannot ship without a drawing.
+ *
+ * ⚠ The owner asked for an icon on every chart-type option, and the wave-8 ruling stands:
+ * an `<option>` cannot render SVG and unicode glyphs are gate-banned, so the chart-type
+ * picker is NOT a native `<select>` — it is a radio-row list like the mode switcher, which
+ * is the only shape that can carry a real mark.
+ *
+ * The key type is a string union declared here rather than imported from chartData.ts: this
+ * module is a leaf (types + theme only) and chartData imports IT, not the reverse.
+ */
+export type ChartKindKey = "bar" | "line" | "area" | "donut" | "kpi" | "table";
+export const CHART_KIND_SHAPES: Record<ChartKindKey, IconShape[]> = {
+  bar: [{ d: "M3.2 12.8V7.4M6.4 12.8V4.2M9.6 12.8V8.8M12.8 12.8V5.8" }],
+  line: [
+    { d: "M2.6 11.2l3.2-3.4 2.6 2 4.9-5.2" },
+    { d: circle(5.8, 7.8, 0.9) },
+    { d: circle(8.4, 9.8, 0.9) },
+  ],
+  area: [
+    { d: "M2.6 12.4V9.2l3.2-3.2 2.6 2 4.9-4.6v9z" },
+    { d: "M2.6 9.2l3.2-3.2 2.6 2 4.9-4.6" },
+  ],
+  donut: [{ d: circle(8, 8, 5) }, { d: circle(8, 8, 2.1) }],
+  // A single big number: the KPI card. Drawn as a framed value rather than a glyph, so it
+  // reads as "one number" beside four marks that all read as "a distribution".
+  kpi: [{ d: "M2.6 3.8h10.8v8.4H2.6z" }, { d: "M5.4 9.6V6.4l1.9 3.2V6.4M9.4 6.4v3.2h1.8" }],
+  // Wave-16 C-CHARTCAP: a group-by aggregate table. Framed like the KPI (it is a card of
+  // values, not a distribution), with a header band and a column rule.
+  table: [
+    { d: "M2.6 3.4h10.8v9.2H2.6z" },
+    { d: "M2.6 6.2h10.8M7.2 6.2v6.4M2.6 9.4h10.8" },
+  ],
+};
+
+export const CHART_KIND_LABELS: Record<ChartKindKey, string> = {
+  bar: "Bar",
+  line: "Line",
+  area: "Area",
+  donut: "Donut",
+  kpi: "Single value",
+  table: "Table",
+};
+
+/** I16 — the pastel each chart kind wears, same family rule as MODE_TONE. */
+export const CHART_KIND_TONE: Record<ChartKindKey, FolderTone> = {
+  bar: "blue",
+  line: "green",
+  area: "green",
+  donut: "yellow",
+  kpi: "neutral",
+  table: "neutral",
+};
+
+/**
+ * Wave-9 contract C5 (I15) — folder icon geometry. TOTAL over `FolderShape`, so a shape key
+ * added to the wire contract in types.ts cannot ship without a drawing.
+ *
+ * Same 16x16 stroke vocabulary as everything above: these have to sit beside a mode icon in
+ * the same rail and read as one family. `folder` is first because it is the default every
+ * pre-wave-9 folder falls back to (I14: "existing folders get the folder icon").
+ */
+export const FOLDER_SHAPE_PATHS: Record<FolderShape, IconShape[]> = {
+  folder: [{ d: "M2.4 12.6V4.2a.6.6 0 0 1 .6-.6h3.2l1.5 1.7h5.3a.6.6 0 0 1 .6.6v6.7a.6.6 0 0 1-.6.6H3a.6.6 0 0 1-.6-.6z" }],
+  star: [
+    { d: "M8 2.9l1.63 3.3 3.64.53-2.63 2.57.62 3.63L8 11.24 4.74 12.93l.62-3.63L2.73 6.73l3.64-.53z" },
+  ],
+  flag: [
+    { d: "M4.2 13.4V2.9" },
+    { d: "M4.2 3.4h7.6l-1.5 2.6 1.5 2.6H4.2z" },
+  ],
+  tag: [
+    { d: "M2.9 8.2V3.5a.6.6 0 0 1 .6-.6h4.7l5 5-5.3 5.3z" },
+    { d: circle(5.6, 5.6, 1) },
+  ],
+  bookmark: [{ d: "M4.4 2.9h7.2v10.4L8 10.7l-3.6 2.6z" }],
+  // Four of the host's shapes ALREADY exist in this file as a mode or a field-type mark.
+  // Reusing the geometry rather than drawing a second "chart" is the whole point of the
+  // one-source rule: a folder labelled Chart and the Chart view must not be two pictures.
+  grid: MODE_SHAPES.grid,
+  chart: MODE_SHAPES.dashboard,
+  map: MODE_SHAPES.map,
+  users: TYPE_SHAPES.user,
+  clock: TYPE_SHAPES.created_time,
+  heart: [{ d: "M8 13.1S2.7 9.8 2.7 6.4a2.9 2.9 0 0 1 5.3-1.6 2.9 2.9 0 0 1 5.3 1.6c0 3.4-5.3 6.7-5.3 6.7z" }],
+  bolt: [{ d: "M9.1 2.4L4.2 9.1h3.3l-.6 4.5 4.9-6.7H8.5z" }],
+};
+
+/**
+ * Tone key → the pastel it FILLS with, and the -d weight it STROKES with.
+ *
+ * Both, not one: a folder mark is a ~14px glyph, and [[loopable-brand-palette]] is explicit
+ * that a base pastel at that size smudges — LP_BLUE measures 1.88:1 on white. So the pastel
+ * is the fill (a tinted body reads as "coloured") and the measured -deep variant carries the
+ * outline (an outline that reads at all).
+ *
+ * The default tone is `neutral` — HOST's C5 key, not "grey". The whitelist is SHARED between
+ * the two ends, so the name matters more than the word: a tone the host does not recognise
+ * degrades to the default and the user's choice silently disappears on reload.
+ */
+export const FOLDER_TONE_PAINT: Record<FolderTone, { fill: string; stroke: string }> = {
+  neutral: { fill: LP_LINE, stroke: LP_MUTED },
+  blue: { fill: LP_BLUE, stroke: LP_BLUE_DEEP },
+  green: { fill: LP_GREEN, stroke: LP_GREEN_DEEP },
+  yellow: { fill: LP_YELLOW, stroke: LP_YELLOW_DEEP },
+  red: { fill: LP_RED, stroke: LP_RED_DEEP },
+};
+
+export const FOLDER_TONE_LABELS: Record<FolderTone, string> = {
+  neutral: "Neutral",
+  blue: "Blue",
+  green: "Green",
+  yellow: "Yellow",
+  red: "Red",
+};
+
+export const FOLDER_SHAPE_LABELS: Record<FolderShape, string> = {
+  folder: "Folder",
+  star: "Star",
+  flag: "Flag",
+  tag: "Tag",
+  bookmark: "Bookmark",
+  grid: "Table",
+  chart: "Chart",
+  map: "Map",
+  users: "People",
+  clock: "Clock",
+  heart: "Heart",
+  bolt: "Priority",
+};
+
+/**
+ * Wave-9 I14 — the tone each CREATABLE view type wears in the "+ Create new…" flyout.
+ *
+ * The owner asked for "pastel-coloured icons", and a flyout where every row is the same grey
+ * is a list you read rather than scan. Assigned by family, not by rotation: the two
+ * record-shaped modes (grid/list) share blue, the two time-shaped ones (calendar/kanban)
+ * share yellow, chart is green because it is the analytical one, map is red because it is
+ * the geographic one. Folder is grey — it is not a view, and the flyout's last row should
+ * not compete with the six above it.
+ */
+/**
+ * Human labels for every display mode. Moved here from viewModes.tsx in wave 9 so the label
+ * sits beside the geometry, the way TYPE_LABELS does — the mode switcher, the create flyout
+ * and the create prompt now read ONE table instead of three. C2's "Dashboard" → "Chart"
+ * rename is a single line here as a direct result.
+ */
+export const MODE_LABELS: Record<DisplayMode, string> = {
+  grid: "Grid",
+  chart: "Chart",
+  // Legacy: never OFFERED (it is not in CREATABLE_MODES) but still labelled, because a view
+  // read before normalisation must never render a blank switcher chip.
+  dashboard: "Chart",
+  list: "List",
+  calendar: "Calendar",
+  kanban: "Kanban",
+  map: "Map",
+  timeseries: "Time series",
+  catalog: "Catalog",
+  // Wave-23 C9 — the mode that COLLECTS records. "Form", the word the whole product uses for
+  // it (the public page, the share panel, the `form_submitted` trigger); a synonym here would
+  // be the one surface calling it something else.
+  form: "Form",
+  // ⭐ Wave-27 C3 (item 8) — the owner's own word for it. Not "Triage" or "Review": the gesture
+  // IS the name here, and the two candidates both collide with vocabulary this product already
+  // spends elsewhere (a `review` automation decision, the retired review lanes).
+  swipe: "Swipe",
+  // W36-T04 — the owner's own words are "code script"; "Script" is the half that is not implied
+  // by the icon, and the product has no other surface competing for the noun.
+  //
+  // ⭐⭐ W37-T41 (owner ruling, 2026-08-19) — RENAMED TO "Custom", and the one-word form is the
+  // ruling rather than a shortening of it. Every wave-37 governing text calls this surface the
+  // "Custom View": PRD items 10 / R2, T41's own `done-when`, D-391, and `ScriptViewPanel`'s
+  // shipped copy ("Picking Custom View mints a view with an EMPTY source"). "Script" was the
+  // product calling one thing two names, which is the defect `swipe`'s label note warns about
+  // one table up.
+  //
+  // ⛔ IT IS NOT SPELLED "Custom View" HERE, and the reason is this table's job rather than a
+  // preference. Every value is a KIND NOUN that four call sites COMPOSE into a phrase:
+  // `ViewSidebar` renders `New ${MODE_LABELS[creating].toLowerCase()} view` (:1060), the same
+  // string as the flyout's aria-label (:1045), `${MODE_LABELS[mode]} view, locked` (:1619) and
+  // `It also stays a ${MODE_LABELS[mode].toLowerCase()}.` (:1626). A label already carrying the
+  // noun reads "New custom view view" at two of them. One word keeps the create prompt reading
+  // "New custom view", the locked aria-label reading "Custom view, locked", and the picker row
+  // reading "Custom" beside Grid, Chart and Map, which are kind nouns too.
+  script: "Custom",
+};
+
+/**
+ * I14 — the view types the "+ Create new…" flyout OFFERS, in the order it lists them.
+ *
+ * Deliberately NOT `DISPLAY_MODES`, and deliberately here rather than inside ViewSidebar.tsx:
+ * C2 makes `'dashboard'` a mode that stays READABLE forever (every view saved before the
+ * rename sits in it) while ceasing to be OFFERABLE once `'chart'` exists — one list cannot
+ * express both. Living in this pure data module means the gate can assert the offered set
+ * without importing a React component, and I10 becomes a one-line edit in one file.
+ */
+// 2026-08-02 item 7 — `timeseries` was deliberately held OUT of this list until the host
+// accepted the name, because a mode may be READABLE before it is OFFERABLE (the same split C2
+// wrote for 'dashboard', running forwards): `aios_grid._clean_display` drops a mode it does
+// not know, so offering it early would let a user create a view that silently reverts to a
+// grid on the next read with nothing going red. HOST posted "ACCEPTANCE LANDED" with
+// `DISPLAY_MODES += timeseries`, so it is offerable now.
+//
+// wave17 GRID, owner item 10 — THE ORDER BELOW IS THE OWNER'S, stated verbatim:
+// Grid · Chart · Calendar · Kanban · Time series · Map · List.
+//
+// ⚠ It supersedes the two orderings this list has carried before it, and the reasoning that
+// produced them is now WRONG rather than merely outranked, so it is not left here to be
+// re-applied: `timeseries` was "listed last… it belongs beside Chart", and `list` sat second
+// as the other record-shaped mode. The owner put Time series FIFTH and List LAST. An order is
+// a product decision, so it is asserted in `verify_icons` rather than left to a comment —
+// nothing else on screen would go red if a future edit re-sorted it "sensibly".
+// Wave-18 C6-CATALOG — `catalog` was held out of this list until `aios_grid.DISPLAY_MODES`
+// accepted the name, the same hold `timeseries` and `chart` served before it. SESSION A posted
+// "C6 HOST MIRROR APPLIED — you may flip CREATABLE_MODES now" (2026-08-03), so it is offerable.
+// It lands LAST by contract: the owner's seven-mode order above is a product decision and the
+// new mode joins the end of it rather than being sorted into it.
+// ⭐ Wave-27 C3 (owner item 8) — `swipe` is HELD OUT of this list, and the reason corrects a
+// mistake this file made an hour earlier.
+//
+// ⛔ THE HOLD WAS NEVER ONLY ABOUT THE TWO REGISTRIES. It was first written as "do not offer a
+// mode the HOST has not accepted", and one session owning both registries this wave genuinely
+// does close that half — which is what made it tempting to skip. But the rule the hold really
+// encodes is broader and this wave proved it: **do not offer a mode whose CONSUMER does not
+// exist.** `swipe` was briefly listed here while `CustomerGrid`'s mode dispatch had no branch
+// for it, so picking "Swipe" wrote a mode the host now happily PERSISTS, and the body rendered
+// a grid under a chip reading "View · Swipe" — surviving reload, with the agreement leg green
+// because it only ever compared two lists.
+//
+// So the hold stood until `SwipeView` was mounted (contract C3), and it was not a mailbox
+// handshake: `verify_icons` DERIVES the condition — either `swipe` is absent here, or
+// `CustomerGrid.tsx` mounts `SwipeView`. `form` (wave-23) is the same defect from the other
+// direction, sitting unoffered because its host mirror never landed (DEBT D-90).
+//
+// ⛔ THE HOLD OUTLIVED THE WAVE, AND THAT IS THE LESSON WORTH MORE THAN THE FEATURE.
+// Wave 27 closed with the mount NEVER LANDING. `SwipeView.tsx` shipped, the server accepted
+// `swipe`, all four maps above carried it, 50 gates were green, the wave-27 mailbox recorded
+// "RESOLVED BY C (swipe mounted)", the close-out booked D-102 — a negative control FOR the
+// swipe carry — and the owner could not find the view because **nothing imported the file.**
+// The derived gate could not catch it: its condition is a DISJUNCTION and **absence satisfies
+// it**, so the unshipped state was permanently green ([[gate-can-report-green-on-nothing]]).
+// A hold that is safe to leave in place is a hold nothing forces you to lift.
+// The audit query that found it, after the battery did not: for each artifact a wave adds, grep
+// for its CONSUMER — who imports/mounts/registers it — excluding the file itself, `_test/`, css
+// and comments. `SwipeView` had four hits and three were prose.
+// Mounted 2026-08-09 (`CustomerGrid.tsx`, `displayMode === "swipe"`), so `swipe` is offerable.
+// It lands LAST, by `catalog`'s rule: the owner's mode order is a product decision and a new
+// mode joins the end of it rather than being sorted into it.
+export const CREATABLE_MODES: DisplayMode[] = [
+  "grid",
+  "chart",
+  "calendar",
+  "kanban",
+  "timeseries",
+  "map",
+  "list",
+  "catalog",
+  "swipe",
+  // Mounted 2026-08-11 (`CustomerGrid.tsx`, `displayMode === "form"` renders `FormInterface`), so
+  // `form` is offerable and its `HELD_MODES` entry came out in the same edit — the hold's own text
+  // named this mount as its release condition. ⚠ Found by `verify_icons.py::mode_parity` law E
+  // during /validate-wave, NOT by the lane that mounted it: T29 mounted the component and T41 built
+  // the Interface group, and between them the DOOR was never opened — the wave's biggest new
+  // surface was unreachable behind two green tickets.
+  "form",
+  // ⭐⭐ W37-T41 (owner item 10 / R2) — `script` JOINS THE OFFER, and this is the release of the
+  // longest-held entry in this file. The hold's own release condition, written into
+  // `icons.test.ts::HELD_MODES`, named THREE things that had to land in one change: the name
+  // joins this list, `CustomerGrid.tsx` gains a `displayMode === "script"` branch, and the
+  // HELD_MODES entry comes out. All three are in this change.
+  //
+  // ⛔ AND A FOURTH THAT THE HOLD DID NOT NAME, which is the one that decides whether the
+  // feature works: `CustomerGrid.tsx::createView` had to learn that picking this mode mints a
+  // SCRIPT VIEW through `createScriptView` rather than persisting a workspace view. A script
+  // view is not a workspace view (it is its source and its version history, in E's own
+  // per-database store), so the three hops above alone would have offered the mode, written
+  // `config.display.mode = "script"` into a stored view, left `activeScriptId` null and drawn
+  // nothing, with `mode_parity` GREEN. That is wave 27's `swipe` defect exactly, reached
+  // through a different door.
+  // ⚠ OFFERED ONLY WHERE IT CAN EXIST. `ViewSidebar` takes `scriptable` and drops this row
+  // when it is false: script views are listed and resolved only on `ut_*` databases
+  // (`CustomerGrid`'s `scriptRows` effect gates on `hostWorkspace && isUserTable`), so offering
+  // it on a pool scope would mint a view the rail can never show
+  // ([[permitted-is-not-answerable]]). It lands LAST by `catalog`'s rule.
+  "script",
+];
+
+/**
+ * ⭐ WAVE-29 R6 (owner item 10) — the kind dropdown splits under TWO headers, and the strings are
+ * the owner's own: exactly `View` and `Interface`. Not "View as" (what the popover said before),
+ * not "Custom interface".
+ *
+ * The line the two groups draw: a **View** ARRANGES the records — the same rows, re-shaped (a
+ * grid, a board, a chart). An **Interface** is a SURFACE BUILT OVER them: a map is a picture of the
+ * world with records placed on it, a catalog is a published artifact, a form is a door records come
+ * IN through and shows no records at all.
+ *
+ * ⭐ WAVE-33 item 9 AMENDED THAT LINE, and the owner drew it one notch differently than R6 did:
+ * `swipe` and `timeseries` moved from View to Interface. The reading that makes both rulings one
+ * rule — and the one the next mode should be grouped by — is **what the surface is FOR**, not how
+ * many rows it shows. A deck triages records one at a time and WRITES to them; a trend answers a
+ * question about a measure over time; neither hands you the row set re-shaped, which is what every
+ * remaining View does. ⚠ Do NOT re-derive the split from `MODE_TONE` below: the tones still say
+ * `catalog`/`form` are neutral because they arrange nothing, and `swipe`/`timeseries` are toned,
+ * so tone and group are no longer the same cut. Group membership lives HERE and only here.
+ *
+ * ⚠ TOTAL over `DisplayMode`, so tsc refuses a new mode with no group rather than letting it
+ * vanish from the dropdown: membership is derived by FILTERING `CREATABLE_MODES` through this
+ * map, and a mode whose group label matched nothing would silently stop being offered while
+ * every existing check (paintable, labelled, toned, unique, ordered) stayed green.
+ * `dashboard` is grouped like the `chart` it is the legacy spelling of — it is never offered, and
+ * a partial map is a worse answer than an unused entry.
+ */
+export const MODE_GROUP_LABELS = ["View", "Interface"] as const;
+export type ModeGroup = (typeof MODE_GROUP_LABELS)[number];
+
+export const MODE_GROUP: Record<DisplayMode, ModeGroup> = {
+  grid: "View",
+  list: "View",
+  kanban: "View",
+  calendar: "View",
+  chart: "View",
+  dashboard: "View",
+  // ⭐ WAVE-33 item 9 (owner, verbatim): "Let's move Swipe and Time-series under Interface instead
+  // of under View, when a user toggle it." See the amended taxonomy note above — a deck and a
+  // trend are both surfaces a person WORKS IN, not re-shapings of the row set.
+  timeseries: "Interface",
+  swipe: "Interface",
+  map: "Interface",
+  catalog: "Interface",
+  form: "Interface",
+  // W36-T04 — "Interface", by the W33 item-9 taxonomy: a script view is a surface somebody WORKS
+  // IN (writes, runs, reads an answer), not a re-shaping of the row set.
+  script: "Interface",
+};
+
+/**
+ * The offered modes, split into R6's two groups — DERIVED, never a third hand-written list.
+ *
+ * ⚠ ORDER: R6 names each group's MEMBERS; the order inside a group stays `CREATABLE_MODES`', which
+ * is the wave-17 owner ruling ("Grid · Chart · Calendar · Kanban · Time series · Map · List") and
+ * is separately asserted. The two rulings are compatible read this way and only this way: R6 moved
+ * `map` out of the run of views, so wave-17's single sequence can no longer exist as one list, but
+ * every pair it ordered is still in that relative order here.
+ */
+export const CREATABLE_GROUPS: readonly { label: ModeGroup; modes: DisplayMode[] }[] =
+  MODE_GROUP_LABELS.map((label) => ({
+    label,
+    modes: CREATABLE_MODES.filter((m) => MODE_GROUP[m] === label),
+  }));
+
+export const MODE_TONE: Record<DisplayMode, FolderTone> = {
+  grid: "blue",
+  list: "blue",
+  chart: "green",
+  dashboard: "green",
+  calendar: "yellow",
+  kanban: "yellow",
+  map: "red",
+  // Green with `chart`: it is the other analytical mode, and the two belong to one family.
+  timeseries: "green",
+  // Wave-18 C6-CATALOG — NEUTRAL, and it is the honest pick rather than the leftover one. The
+  // four colour tones each name a family of ways to arrange records (blue = tabular, green =
+  // analytical, yellow = board/date, red = spatial); a catalog arranges nothing — it is a
+  // published artifact. Giving it a colour would file it under a family it is not in.
+  catalog: "neutral",
+  // Wave-23 C9 — NEUTRAL, and for `catalog`'s reason rather than by elimination: the four tones
+  // name families of ways to ARRANGE records (blue tabular, green analytical, yellow
+  // board/date, red spatial). A form arranges nothing — it is a door records come in through —
+  // so giving it a colour would file it under a family it is not in.
+  form: "neutral",
+  // ⭐ Wave-27 C3 — YELLOW, with `kanban`, and this is a family claim rather than a leftover:
+  // a swipe deck writes the SAME single-select a kanban stacks by (R2 binds it to one), so the
+  // two are one family seen at two zooms — all the lanes at once, or one card at a time. Filing
+  // it neutral (the `catalog`/`form` reasoning) would be wrong for the opposite reason those
+  // two are neutral: this mode does arrange records, and it arranges them by the board's field.
+  swipe: "yellow",
+  // W36-T04 — NEUTRAL, by `catalog`'s and `form`'s rule rather than by elimination: the four
+  // tones name families of ways to ARRANGE records (blue tabular, green analytical, yellow
+  // board/date, red spatial). A script arranges nothing; it emits whatever it computes.
+  script: "neutral",
+};
+
+/**
+ * Human labels for every field type. Lives here beside the icons so the two
+ * halves of "how a field type presents itself" stay in one file (ColumnMenu
+ * imports it rather than keeping a second copy).
+ */
+export const TYPE_LABELS: Record<FieldType, string> = {
+  // ⭐ WAVE-29 item 3 — the owner's own words: "Change 'Single line text' to 'Text', keep it
+  // simple for the Field type". Airtable's phrase described the column's SHAPE (one line, versus
+  // its long-text sibling); this product has no multi-line text kind, so the qualifier
+  // distinguished the type from nothing and only made the commonest row in the menu the longest.
+  // ✅ The STORED key is `"text"` and always was — the old string was never persisted anywhere,
+  // client or server, so this is a label change with no migration behind it.
+  text: "Text",
+  select: "Single select",
+  multiselect: "Multi select",
+  user: "Assignee",
+  int: "Number",
+  currency: "Currency",
+  pct: "Percent",
+  date: "Date",
+  checkbox: "Checkbox",
+  phone: "Phone number",
+  email: "Email",
+  url: "URL",
+  rating: "Rating",
+  created_time: "Created time",
+  formula: "Formula",
+  // Wave-18 C5-AUTOFIELD (D's spec, applied by C).
+  automation: "Automation",
+  // Wave-22 C7 — spawned by automations (not in CREATABLE_TYPES), so this label mostly shows
+  // on headers and the field gear, not the create menu.
+  metric: "Metric",
+  // Wave-19 R7 — the picture column.
+  image: "Image",
+  // Wave-23 C7 — the structured-document column. "JSON" rather than "Structured data": it is
+  // the word on the wire, in the viewer's raw tab and in every error the server can return, and
+  // a friendlier synonym would be the only place in the product using a different one.
+  json: "JSON",
+  // ⭐ 2026-08-07 — Airtable's own wording, deliberately. "Link to another record" is what a
+  // person migrating from Airtable searches this menu for, and inventing a synonym ("Relation",
+  // "Reference") would make the feature they came for look absent.
+  link: "Link to another record",
+  rollup: "Rollup",
+  // ⭐ Wave-27 item 13 (R13) — "Code", not "Snippet" or "Source": it is the word the field kind
+  // is called everywhere else in this wave (the ruling, the language picker, the viewer header),
+  // and it says what the column holds without implying the product will run it.
+  code: "Code",
+  // ⭐ WAVE 34 · T53 (R13), on F's ask (`F-2`) — the owner's own noun for the kind: "a field kind
+  // called AI enrichment". Not "AI field" (every field in an AI-built view would qualify) and not
+  // "Generate" (that names the verb, and the column's value is the point, not the act).
+  ai_enrich: "AI enrichment",
+  status: "Lifecycle status (Odoo)", // never creatable; present so the map stays total
+};
+
+/**
+ * ⭐ WAVE-29 C7 (item 17) — THE COLUMN-SUMMARY vocabulary: what a field's `agg` may be, which is
+ * what the totals row and the per-group subtotals compute. Server twin:
+ * `platform/aios_grid.py::FIELD_AGGS`, and `verify_icons.py::agg_parity` reads BOTH FILES and
+ * compares them name-for-name in order — the cross-language boundary is the one a type cannot
+ * police, so it gets a gate.
+ *
+ * ⛔ ONE CLIENT LIST, IMPORTED — never re-declared. `aggregations.ts` and the field editor import
+ * from here rather than keeping their own copy, which is why this lives in the pure data module
+ * beside `TYPE_LABELS` and `CREATABLE_MODES`: a second client list would need a second gate, and
+ * the two would drift in the direction nobody is watching. C7 says "C publishes, E mirrors"; a
+ * mirror that is an import cannot fall out of step at all.
+ *
+ * ⛔ NOT the chart vocabulary. `CHART_AGGS` (`aios_grid.py`, `viz/chartData.ts`) spells it `avg`
+ * and gatekeeps a STORED value — renaming it would silently turn saved charts into sums. This
+ * list spells it `average`, matching `ROLLUP_FNS` (16 names, live in production), so a column
+ * summary and a rollup fold say the same word for the same operation.
+ *
+ * ⚠ `median` is net-new — in neither `CHART_AGGS` nor `ROLLUP_FNS`.
+ * ⚠ `count` counts ROWS in the scope, not non-blank cells.
+ * ⚠ Which types may carry which: `sum/average/median/min/max` are numeric-only and the evaluator
+ * for that is ALREADY `isNumericFieldType` (types.ts) — do not write a second one. `count` is
+ * legal on any type.
+ */
+// ⭐ W29-T74 — an ALIAS of `types.AggName`, not a fifth copy of the union. `Field.agg` is typed
+// `AggName`, so a second literal here would be a type that has to be kept in step by eye with a
+// type the compiler already owns — the same defect as the array below, one level up.
+export type FieldAgg = AggName;
+
+/** ORDERED — the order is the picker's order, on both engines. */
+export const FIELD_AGGS: readonly FieldAgg[] = [
+  "sum",
+  "average",
+  "median",
+  "min",
+  "max",
+  "count",
+];
+
+/**
+ * Human labels, in the summary bar's own compact register (Airtable's wording).
+ *
+ * ⚠ `FIELD_AGG_LABELS`, not `AGG_LABELS`, and the prefix is load-bearing: `viewModes.tsx` already
+ * has a module-local `AGG_LABELS` for the CALENDAR summary picker over `CHART_AGGS`, where the
+ * same five names wear different words ("Total", "Lowest", "Highest") for a day cell. Two tables
+ * called `AGG_LABELS` describing two vocabularies is how a future import lands on the wrong one.
+ */
+export const FIELD_AGG_LABELS: Record<FieldAgg, string> = {
+  sum: "Sum",
+  average: "Average",
+  median: "Median",
+  min: "Min",
+  max: "Max",
+  count: "Count",
+};
+
+
+// ------------------------------------------------------------ glide sprites
+
+/** Serialize one shape to SVG source in an explicit colour (canvas sprites get
+ *  no `currentColor` — glide hands the painter the theme colours directly). */
+function shapeSource(s: IconShape, color: string): string {
+  return s.fill
+    ? `<path d="${s.d}" fill="${color}"/>`
+    : `<path d="${s.d}" fill="none" stroke="${color}" stroke-width="1.35" ` +
+        `stroke-linecap="round" stroke-linejoin="round"/>`;
+}
+
+function sprite(shapes: IconShape[]) {
+  return ({ fgColor }: { fgColor: string }) =>
+    `<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16">` +
+    shapes.map((s) => shapeSource(s, fgColor)).join("") +
+    `</svg>`;
+}
+
+/** Glide header-icon NAME for a field type — the `icon` a GridColumn asks for. */
+export function typeIconName(type: FieldType): string {
+  return `t_${type}`;
+}
+
+/**
+ * The sprite map handed to <DataEditor headerIcons>. One entry per field type
+ * (I20 draws the type mark in every column header), built from the same shapes
+ * the React icons use.
+ *
+ * Colour: glide's "normal" variant paints with `theme.fgIconHeader`, which is
+ * why theme.ts must set it — the library default is #FFFFFF, i.e. invisible on
+ * our header (that was I21's actual bug, not a too-pale hex of ours).
+ */
+export const TYPE_SPRITES: Record<string, ({ fgColor }: { fgColor: string }) => string> =
+  Object.fromEntries(
+    (Object.keys(TYPE_SHAPES) as FieldType[]).map((t) => [typeIconName(t), sprite(TYPE_SHAPES[t])])
+  );
+
+/**
+ * The header sprite map handed to <DataEditor headerIcons>. Two families:
+ *
+ *   t_<type>   wave-8 I20 - the field-TYPE mark, drawn in EVERY column header,
+ *              from the same shapes the React icons use. Painted by glide in
+ *              `theme.fgIconHeader`.
+ *   aiosInfo   wave-5 item 6, restyled by wave-9 I3 - the description (i).
+ *              OUTLINE ONLY: a dark-grey ring with a transparent interior, per
+ *              the owner. It still deliberately IGNORES the colours glide hands
+ *              it, for the reason wave-8 recorded - glide's "special" variant is
+ *              accentColor behind bgHeader, which under the C1 pastels is a pale
+ *              glyph on a pale disc, i.e. I21 in a new costume.
+ *              ⚠ It is NO LONGER a column `overlayIcon`. Glide draws an overlay
+ *              at a hard-coded offset from the TYPE mark on the far LEFT of the
+ *              header (drawHeaderInner: `drawX + 9`), and I3 wants it RIGHT-
+ *              aligned. It is now painted by CustomerGrid's `drawHeader`
+ *              callback at `infoMarkRect()` - see overlayPlacement.ts.
+ */
+export const HEADER_ICONS: Record<string, (c: { fgColor: string; bgColor: string }) => string> = {
+  ...TYPE_SPRITES,
+  aiosInfo: () =>
+    `<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16">` +
+    `<circle cx="8" cy="8" r="6.1" fill="none" stroke="${LP_MUTED}" stroke-width="1.25"/>` +
+    `<path d="M8 7.4v3.5" fill="none" stroke="${LP_MUTED}" stroke-width="1.4" ` +
+    `stroke-linecap="round"/>` +
+    `<circle cx="8" cy="5.1" r="0.85" fill="${LP_MUTED}"/>` +
+    `</svg>`,
+};