Deploy AIOS web (React glide grid + FastAPI slice)

RELEASES.json

@@ -1,6 +1,12 @@
 {
- "current": "2b8e675",
+ "current": "v27 (c05a794)",
  "releases": [
+  {
+   "version": "v27",
+   "sha": "c05a794",
+   "date": "2026-08-18",
+   "subject": "release v27"
+  },
   {
    "version": "v25",
    "sha": "bc24829",

VERSION

@@ -1 +1 @@
-2b8e675
+v27 (c05a794)

api/routes_feedback.py

@@ -157,7 +157,19 @@ def list_feedback(tenant: str = "", session: Session = Depends(require_session))
     if tenant:
         want = str(tenant).strip().lower()
         rows = [r for r in rows if str(r.get("tenant") or "").lower() == want]
-    rows = sorted(rows, key=lambda r: int(r.get("ts") or 0), reverse=True)
+    # ⛔ THE TIEBREAK IS THE STORE'S OWN ORDER, AND WITHOUT IT "NEWEST FIRST" IS FALSE FOR ANY TWO
+    # ROWS FILED IN THE SAME SECOND (wave-35 QA). `ts` is `int(time.time())` — SECOND resolution —
+    # and Python's sort is STABLE, so under `reverse=True` a tie keeps INSERTION order, which is
+    # oldest-first: the one direction this route promises never to return. It is not hypothetical
+    # and it is not a flake: `api_api`'s R8 row failed on it in the close-out battery, in the
+    # wave-35 QA battery and in a solo re-run, and the baseline recorded the true count anyway, so
+    # a REAL regression would have read as the known-flake line.
+    # ⚠ ENUMERATE OVER THE ALREADY-FILTERED LIST: `_rows()` appends, so a row's index IS its arrival
+    # order (the module docstring's "newest LAST in the store"), and `?tenant=` only drops rows, so
+    # the surviving indexes stay monotonic. Raising `ts` to sub-second resolution instead would
+    # break every id already minted as `fb_<ts>_…`.
+    rows = [r for _, r in sorted(enumerate(rows),
+                                 key=lambda p: (int(p[1].get("ts") or 0), p[0]), reverse=True)]
     out = {"rows": [dict(r) for r in rows], "total": len(rows), "capacity": MAX_ROWS,
            "tenants": sorted({str(r.get("tenant") or "") for r in _rows() if r.get("tenant")})}
     if len(_rows()) >= MAX_ROWS:

web/src/customer-grid/CustomerGrid.tsx

@@ -1591,10 +1591,26 @@ function CustomerGridSurface({
       // scope, which for a Query surface is the SOURCE database — so autosaving a resize would
       // have written a view into the source's own workspace under the artefact's id. The router
       // is what keeps "which store does this spec belong to" answered in one place.
+      // ⛔⛔ WAVE 35 QA — THE SUBJECT OF A QUERY WRITE IS THE ARTEFACT, AND STAMPING IT IS WHAT
+      // MAKES W35-T23 TRUE. This emitted `updated` unchanged, whose `id` is the SOURCE database's
+      // active view (the grid mounts on `gridScopeFor(active.source.database)`, so `views` are the
+      // source's). `routeQueryViewMutation` requires `view.id === binding.artifactId` and the
+      // server requires the same — so EVERY spec write on a Query surface was refused before it
+      // left the browser, and the person saw *"A Query view holds one saved answer…"*, the message
+      // written for a genuine duplicate-view attempt.
+      // ⚠ MEASURED, not deduced: resize, sort, group, hide and row height all failed identically
+      // on a pre-wave artefact AND a brand-new one — six for six, zero network writes, `edited`
+      // never flipping. The owner's item was *"I should be able to interact in each of the View
+      // under Query as well, exactly like how I would be able to interact with it under Database
+      // view"*, and the router's own docstring already says these are one thing to it.
+      // ⚠ ONLY the emitted subject is re-identified. `setViews` and the tombstone keep using
+      // `updated.id`, because the LOCAL row really is the source's view — the artefact id is who
+      // the WRITE is about, not who the grid is showing.
+      const subject = queryBinding ? { ...updated, id: queryBinding.artifactId } : updated;
       const routed = routeQueryViewMutation(queryBinding, scope, {
         id: eventId(queryBinding ? "query-view-update" : "view"),
         type: "view_upsert",
-        view: updated as unknown as Record<string, unknown>,
+        view: subject as unknown as Record<string, unknown>,
       }, { query: mutateQueryWorkspace, native: emitHostEvent });
       if (routed.channel === "refused")
         signal(TOAST_EVENT, routed.refusal?.message ?? "That view change could not be saved.");

web/src/customer-grid/useVisibleRows.ts

@@ -804,7 +804,20 @@ export function runPipeline(input: PipelineInput): VisibleRowsResult {
   // it client-side would rank the page and label the answer with the scope's count — the exact
   // "12 rows under 'showing 200 of 5,728'" failure this bypass exists to prevent. The refusal
   // belongs to `filter_sql`, which maps rank leaves to its UNANSWERABLE tri-state.
-  if (serverWindowed) return asRows(rawRows);
+  // ⛔⛔ WAVE 35 QA — A CURATED SET IS NOT A FILTER, AND THE BYPASS ABOVE DOES NOT COVER IT.
+  // `memberPids` is a list of pids the VIEW names; the SQL window never applied it (measured: the
+  // "Starred records" view on `ut_odoo_gl_lines` painted "showing 200 of 978,257" with exactly one
+  // record starred). So narrowing by membership here is not the double-narrowing this bypass
+  // exists to prevent — it is the ONLY narrowing, and skipping it renders a view that promises the
+  // starred rows and shows the whole table.
+  // ⚠ The honest limit, stated rather than hidden: the window is one PAGE the server chose, so a
+  // starred record outside it still will not appear. Showing the starred rows that ARE on the page
+  // is strictly better than showing 200 unrelated ones under a heading that says "Starred records",
+  // and the real fix is the server applying `memberPids` to the window.
+  const curated = memberPids.length ? new Set(memberPids) : null;
+  if (serverWindowed) {
+    return asRows(curated ? rawRows.filter((r) => curated.has(r.pid)) : rawRows);
+  }
 
   const fieldByKey = new Map<string, Field>();
   for (const f of fields) fieldByKey.set(f.key, f);
@@ -863,12 +876,24 @@ export function runPipeline(input: PipelineInput): VisibleRowsResult {
       ctx.rankSets = NO_RANKING.sets;
     }
 
-    const members = new Set(memberPids);
     out = out.filter(
       (r) =>
-        members.has(r.pid) ||
+        (curated ? curated.has(r.pid) : false) ||
         matchFilterTree(filters, filterConj, r, fieldByKey, ctx)
     );
+  } else if (curated) {
+    // ⛔⛔ WAVE 35 QA — THE WHOLE NARROWING USED TO LIVE INSIDE `if (filters.length)`, SO A VIEW
+    // THAT IS *ONLY* A CURATED SET SHOWED EVERY ROW IN THE TABLE. `memberPids` was designed as
+    // pinned rows that "ride the `||` below without matching anything" (the note above) — an
+    // ADDITION to a filter result — and nothing covered the case where the membership IS the view.
+    // W35-T40's "Starred records" is exactly that: `filters: []` with `memberPids` non-empty. The
+    // server was right every time (`GET /starred/records` returned `ids:[7745], count:1` and the
+    // view's own `config.memberPids` carried it); the client threw the answer away and painted
+    // "3,634 records". Reproduced three times, on a small database and on a 978k-row one.
+    // ⚠ It is an `else if`, not a second unconditional pass: with filters present, membership must
+    // stay a UNION (pinned rows ride along), and re-applying it here would turn that union into an
+    // intersection and hide every row the filters matched.
+    out = out.filter((r) => curated.has(r.pid));
   }
 
   const q = search.trim().toLowerCase();

web/src/index.css

@@ -3087,6 +3087,21 @@ body {
 .shell-nav-templates {
   margin: 0 8px 2px;
   width: calc(100% - 16px);
+  /* ⛔⛔ WAVE 35 QA — `margin-top: auto` IS WHAT MAKES THE ROW'S OWN `done-when` TRUE. It ships as a
+     SIBLING of `.shell-side-bottom` for a real behavioural reason (that band's `onClickCapture`
+     swallows a collapsed click and expands the rail instead, which a row with no popover must not
+     inherit) — but the band ALSO carries `margin-top: auto`, so the band went to the bottom and
+     this row stayed pinned under Connectors. MEASURED on the deployed build at 1600x1000: the row
+     at y=362, the account button at y=945, a **549 px** gap. The ticket says "the rail's bottom
+     band, directly above the account button" and the owner said "just above our User button".
+     Taking the auto-margin HERE makes this row absorb the free space instead, so it lands against
+     the band's top border and the band's own auto-margin becomes a no-op behind it.
+     ⚠ It must survive `.is-rail-hidden`: while `/nav` is in flight this row is `display: none`, the
+     free space falls back to the band's own `margin-top: auto`, and the account row stays pinned.
+     ⚠ The gate that was green over this compared SOURCE-STRING INDEXES (`verify_ui.py`:
+     `_shell_code.find("shell-nav-templates")` vs the account marker) — source order cannot see an
+     auto margin, so it read "above" for a row 549 px away. [[gate-pins-a-spelling-not-a-claim]] */
+  margin-top: auto;
 }
 /* ⛔ W33-T75's law reaches this row too. `.shell-nav.is-rail-loading > *` cannot select it — this
    button is a SIBLING of `.shell-nav`, not a child — so while `/nav` is in flight it would paint in
@@ -3097,6 +3112,10 @@ body {
   margin: 0 6px 2px;
   width: calc(100% - 12px);
   padding: 7px 10px;
+  /* The collapsed rule RE-SETS the whole margin shorthand, so it re-sets `margin-top` to 0 with it
+     — the fix above would hold expanded and silently revert the moment the rail folded. Restated
+     here rather than reordered, because the shorthand is what carries the collapsed gutters. */
+  margin-top: auto;
 }
 .shell-side.is-collapsed .shell-side-bottom { padding: 8px 2px 10px; }
 .shell-side.is-collapsed .shell-account {

web/src/shell/Shell.tsx

@@ -924,7 +924,18 @@ function ShellFrame() {
    */
   const VIEW_OPEN_RETRY_MS = [0, 250, 700, 1500, 2600, 5000, 9000, 14000, 21000] as const;
   const openViewInDatabase = useCallback((database: string, viewId: string) => {
-    window.location.hash = `#/db/${database}`;
+    // ⛔⛔ WAVE 35 QA — THIS WROTE `#/db/${database}` AND NOTHING IN THE APP READS A `db/` PREFIX,
+    // SO EVERY STARRED-VIEW TILE ON HOME AND ON STARRED WAS A DEAD CLICK. `routeKeyOf` strips only
+    // a leading `#/` (`nav.ts`), so the route became the literal `"db/ut_odoo_invoices"`;
+    // `resolveRoute` looks that up against entry keys that are BARE (`"ut_odoo_invoices"`), missed,
+    // and the shell fell back to Home — the URL changed, the screen did not. Reproduced on two
+    // different views, held for 30 s+, and confirmed structurally: `"db/"` appeared exactly ONCE
+    // in `Shell.tsx` + `nav.ts` + `dbFrame.tsx` combined — here, the writer, with no reader
+    // anywhere. Every other hash write in this file is `#/${key}` (`:1764`, `:2934`, …); this one
+    // invented a second vocabulary for the same thing. [[one-question-two-normalizers]]
+    // ⚠ The failure is silent by construction, which is why no gate saw it: a route that does not
+    // resolve is the SAME code path as "no route yet", and that path renders Home on purpose.
+    window.location.hash = `#/${database}`;
     viewEmitCancel.current?.();
     viewEmitCancel.current = retryEmit(
       () => {
@@ -2222,7 +2233,20 @@ function ShellFrame() {
           <button
             type="button"
             ref={dbButton}
-            className={"shell-nav-item shell-nav-db" + (dbAt ? " is-active" : "")}
+            // ⛔⛔ WAVE 35 QA — `dbAt` ALONE IS THE FLYOUT ANCHOR, NOT THE CURRENT SURFACE, AND
+            // THAT MADE W35-T03 FALSE ON THE ONE ROW A PERSON SPENDS MOST OF THEIR DAY IN.
+            // Measured on the deployed build: standing on "Odoo customers", `.shell-nav-db` read
+            // exactly `shell-nav-item shell-nav-db` — every rail row painted identically plain,
+            // nothing marking Database as current. It lit up only while the flyout was manually
+            // REOPENED, which is a click the ticket's "at a glance" does not allow for. Six of the
+            // seven rows in that clause were right; this one was gated on the wrong fact.
+            // ⭐ THE FLYOUT'S OWN ROWS ALREADY HAD THE RIGHT ANSWER (`active.key === item.key`,
+            // below) — the button was the only thing in the rail reading a different question.
+            // So this asks the SAME question the rows ask: is the resolved route one of the
+            // databases this flyout lists? [[one-evaluator-per-question]]
+            className={"shell-nav-item shell-nav-db"
+              + (dbAt || (!!active && dbEntries.some((e) => e.key === active.key))
+                 ? " is-active" : "")}
             aria-haspopup="dialog"
             aria-expanded={!!dbAt}
             onMouseEnter={navCollapsed ? tipEnter("Database") : undefined}