.gitea/workflows/deploy.yml

@@ -100,6 +100,28 @@ jobs:
           # Update compose files + mosquitto config
           git pull origin main
 
+          # server-26#51: Firestore rules + composite indexes had no deploy
+          # path and regressed silently after every fix (the alert_events and
+          # calls(org_id,started_at) indexes among them). The VM runs as the
+          # project service account, so firebase-tools authenticates via ADC
+          # with no key file, and infra/firestore/firebase.json pins database
+          # c2-server. Indexes go on additively -- no --force -- so a stray
+          # edit to firestore.indexes.json can never delete a live index;
+          # rules are a full replace, which is the intent. --non-interactive
+          # means the FIRST run after a drift still needs a one-time manual
+          # `firebase deploy` on the VM to clear pending deletions (it aborts
+          # rather than guess). A failure here warns but does NOT fail the
+          # deploy: a transient Firebase API error must not roll back a good
+          # app build.
+          if command -v firebase >/dev/null 2>&1; then
+            ( cd /opt/drb/infra/firestore \
+              && firebase deploy --only firestore:rules,firestore:indexes \
+                   --project ${{ secrets.FIREBASE_PROJECT_ID }} --non-interactive ) \
+              || echo "WARNING: firestore deploy failed (server-26#51) -- rules/indexes may be stale"
+          else
+            echo "WARNING: firebase CLI not on the VM -- skipped firestore deploy (server-26#51); install once with: npm i -g firebase-tools"
+          fi
+
           # server-26#65: capture what is actually live BEFORE switching, so
           # a bad deploy has something concrete to fall back to. This reads
           # from a state file rather than re-deriving it from git log,

infra/firestore/firestore.indexes.json

@@ -1,15 +1,15 @@
 {
   "//": "Composite indexes for the c2-server database. Firestore auto-indexes single-field lookups and equality-only compound queries; an equality filter combined with an inequality, an orderBy on a different field, or array-contains needs an explicit composite index or the query fails at runtime with FAILED_PRECONDITION. Deploy with: firebase deploy --only firestore:indexes --project <project-id> (firebase.json pins database c2-server — without that key the CLI targets (default) and changes nothing the app can see).",
-  "//direction": "Every index here is declared ASCENDING. Firestore scans an index in either direction, so org_id+started_at ASC serves orderBy(started_at, 'desc') as well — which is what every frontend hook actually asks for. Declaring only the ASC form keeps one index per query shape instead of a matched pair.",
-  "//drift-2026-08-23": "Reconciled against `gcloud firestore indexes composite list --database=c2-server` (server-26#33). The file had drifted four indexes behind the live database, and a deploy against the stale file then added ASC copies of indexes that already existed as DESC. The next deploy will offer to delete three live indexes that are deliberately not declared here — answer YES to all three: calls(org_id ASC, started_at DESC) and incidents(org_id ASC, started_at DESC) are duplicates of the ASC entries below, and alert_events(acknowledged ASC, triggered_at DESC) predates tenancy and is superseded by the org-scoped entry below. Nothing else may be deleted.",
+  "//direction": "The sort field's ORDER here must match the query's orderBy direction. The old note claimed 'Firestore scans either direction so ASC serves orderBy(desc)' — that is WRONG for these query shapes and cost us three broken pages (server-26 #33/#51/#110-followup, 2026-09-08): useCalls/useIncidents/useAlerts and c2-core search_calls all orderBy(x,'desc') and each got FAILED_PRECONDITION until an explicit DESCENDING index existed. A range/inequality filter with no orderBy (the backend status/ended_at, system_id/started_at, system_id/ended_at entries) is genuinely direction-agnostic and stays ASCENDING.",
+  "//drift-2026-09-08": "Reconciled against the live c2-server via `gcloud firestore indexes composite list` (server-26#33). Live already carries the three DESC indexes below (calls(org_id,started_at DESC), incidents(org_id,started_at DESC), alert_events(org_id,triggered_at DESC)) plus alert_events(acknowledged,org_id,triggered_at DESC) — created directly with gcloud on 2026-09-08 to unbreak Archive + Watch. This file now declares them so a `firebase deploy --only firestore:indexes` is a no-op, NOT a set of deletions. Do NOT delete calls(org_id,started_at DESC) or incidents(org_id,started_at DESC) — the pre-2026-09-08 note calling them deletable 'duplicates of the ASC entries' was the bug. The only genuinely dead index is the pre-tenancy alert_events(acknowledged,triggered_at) with no org_id, which may be deleted.",
   "indexes": [
     {
-      "//": "drb-frontend lib/useCalls.ts — org-scoped call list, orderBy started_at desc.",
+      "//": "drb-frontend lib/useCalls.ts + c2-core routers/calls.py search_calls — org-scoped call list, orderBy started_at DESC.",
       "collectionGroup": "calls",
       "queryScope": "COLLECTION",
       "fields": [
         { "fieldPath": "org_id", "order": "ASCENDING" },
-        { "fieldPath": "started_at", "order": "ASCENDING" }
+        { "fieldPath": "started_at", "order": "DESCENDING" }
       ]
     },
     {
@@ -22,7 +22,7 @@
       ]
     },
     {
-      "//": "c2-core internal/recorrelation_sweep.py:45 — status == 'ended' AND ended_at >= cutoff. Backend only; was live but undeclared until 2026-08-23.",
+      "//": "c2-core internal/recorrelation_sweep.py:45 — status == 'ended' AND ended_at >= cutoff. Range filter, no orderBy: direction-agnostic. Backend only.",
       "collectionGroup": "calls",
       "queryScope": "COLLECTION",
       "fields": [
@@ -31,7 +31,7 @@
       ]
     },
     {
-      "//": "c2-core internal/dedup.py:84 — system_id == X AND started_at within a +/- window. Was live-failing on essentially every inbound call (server-26#84): dedup caught the FAILED_PRECONDITION and degraded to \"not a duplicate\", so double-heard transmissions were stored twice and would have been transcribed and correlated twice the moment an AI window opened. Created directly on c2-server 2026-08-28.",
+      "//": "c2-core internal/dedup.py:84 — system_id == X AND started_at within a +/- window. Range filter, direction-agnostic. Was live-failing on essentially every inbound call (server-26#84): dedup caught the FAILED_PRECONDITION and degraded to \"not a duplicate\", so double-heard transmissions were stored twice. Created directly on c2-server 2026-08-28.",
       "collectionGroup": "calls",
       "queryScope": "COLLECTION",
       "fields": [
@@ -40,7 +40,7 @@
       ]
     },
     {
-      "//": "c2-core internal/vocabulary_learner.py:290 — system_id == X AND ended_at >= cutoff. Backend only; was live but undeclared until 2026-08-23.",
+      "//": "c2-core internal/vocabulary_learner.py:290 — system_id == X AND ended_at >= cutoff. Range filter, direction-agnostic. Backend only.",
       "collectionGroup": "calls",
       "queryScope": "COLLECTION",
       "fields": [
@@ -49,35 +49,25 @@
       ]
     },
     {
-      "//": "drb-frontend lib/useIncidents.ts — org-scoped incident browse, orderBy started_at desc.",
+      "//": "drb-frontend lib/useIncidents.ts — org-scoped incident browse, orderBy started_at DESC.",
       "collectionGroup": "incidents",
       "queryScope": "COLLECTION",
       "fields": [
         { "fieldPath": "org_id", "order": "ASCENDING" },
-        { "fieldPath": "started_at", "order": "ASCENDING" }
+        { "fieldPath": "started_at", "order": "DESCENDING" }
       ]
     },
     {
-      "//": "drb-frontend lib/useAlerts.ts — org-scoped alert feed, orderBy triggered_at desc.",
+      "//": "drb-frontend lib/useAlerts.ts — org-scoped alert feed, where(org_id ==) orderBy(triggered_at DESC).",
       "collectionGroup": "alert_events",
       "queryScope": "COLLECTION",
       "fields": [
         { "fieldPath": "org_id", "order": "ASCENDING" },
-        { "fieldPath": "triggered_at", "order": "ASCENDING" }
+        { "fieldPath": "triggered_at", "order": "DESCENDING" }
       ]
     },
     {
-      "//": "drb-frontend lib/useAlerts.ts useUnacknowledgedAlerts — the nav badge.",
-      "collectionGroup": "alert_events",
-      "queryScope": "COLLECTION",
-      "fields": [
-        { "fieldPath": "org_id", "order": "ASCENDING" },
-        { "fieldPath": "acknowledged", "order": "ASCENDING" },
-        { "fieldPath": "triggered_at", "order": "ASCENDING" }
-      ]
-    },
-    {
-      "//": "drb-frontend lib/useAlerts.ts useUnacknowledgedAlerts (nav badge) and the /watch \"Triggered Alerts\" tab — where(org_id ==) where(acknowledged == false) orderBy(triggered_at desc). Threw \"the query requires an index\" on every page until this was declared (server-26#51). Field tuple and triggered_at DESCENDING copy the console create_composite link in that issue verbatim, so a gcloud/console create and a firebase deploy converge on one index rather than the ASC-vs-DESC pair that caused server-26#33. Distinct from the (org_id, triggered_at) alert-feed index above (no acknowledged filter) and supersedes the pre-tenancy live alert_events(acknowledged, triggered_at) index #33 says to delete.",
+      "//": "drb-frontend lib/useAlerts.ts useUnacknowledgedAlerts (nav badge) and the /watch \"Triggered Alerts\" tab — where(org_id ==) where(acknowledged == false) orderBy(triggered_at DESC). Field tuple + triggered_at DESCENDING copy the console create_composite link verbatim (server-26#51). Distinct from the (org_id, triggered_at) feed index above (no acknowledged filter).",
       "collectionGroup": "alert_events",
       "queryScope": "COLLECTION",
       "fields": [