@jhizzard/termdeck 0.9.0 → 0.10.2

package/packages/server/src/setup/mnestra-migrations/009_memory_relationship_metadata.sql

@@ -0,0 +1,126 @@
+-- 009_memory_relationship_metadata.sql
+--
+-- Sprint 38 (T1) — Knowledge graph substrate.
+-- Adds graph-edge metadata columns to memory_relationships, expands the
+-- relationship_type vocabulary from 5 to 8 values, and ships a recursive-CTE
+-- traversal function (expand_memory_neighborhood) for N-hop neighborhood
+-- queries.
+--
+-- Idempotent: safe to re-run.
+--
+-- Pre-existing state (verified against petvetbid 2026-04-27 17:25 ET):
+--   memory_relationships has 749 live edges. The migration adds nullable
+--   columns and a wider CHECK; no existing row violates the new constraint.
+--
+-- The original CHECK on relationship_type is anonymous (defined inline in
+-- migration 001), so its name is auto-generated (e.g., memory_relationships_check1).
+-- We can't rely on a known name for DROP CONSTRAINT; the DO block below
+-- introspects pg_constraint and drops any CHECK on this table whose
+-- definition references "relationship_type IN" — preserving the separate
+-- (source_id <> target_id) CHECK.
+
+-- ── 1. Metadata columns ──────────────────────────────────────────────────
+
+alter table memory_relationships
+  add column if not exists weight       float,
+  add column if not exists inferred_at  timestamptz,
+  add column if not exists inferred_by  text;
+
+-- ── 2. Expand relationship_type CHECK vocabulary ─────────────────────────
+
+do $$
+declare
+  c record;
+begin
+  for c in
+    select con.conname
+    from pg_constraint con
+    join pg_class cls on cls.oid = con.conrelid
+    where cls.relname = 'memory_relationships'
+      and con.contype = 'c'
+      and pg_get_constraintdef(con.oid) ilike '%relationship_type%'
+  loop
+    execute format('alter table memory_relationships drop constraint %I', c.conname);
+  end loop;
+end
+$$;
+
+alter table memory_relationships
+  add constraint memory_relationships_relationship_type_check
+  check (relationship_type in (
+    'supersedes',
+    'relates_to',
+    'contradicts',
+    'elaborates',
+    'caused_by',
+    'blocks',
+    'inspired_by',
+    'cross_project_link'
+  ));
+
+-- ── 3. Indexes for graph traversal ───────────────────────────────────────
+
+create index if not exists memory_relationships_weight_idx
+  on memory_relationships(weight)
+  where weight is not null;
+
+create index if not exists memory_relationships_inferred_at_idx
+  on memory_relationships(inferred_at)
+  where inferred_at is not null;
+
+-- ── 4. expand_memory_neighborhood — recursive-CTE N-hop traversal ────────
+--
+-- Returns one row per (memory_id, depth) reachable from start_id within
+-- max_depth hops. Edges are undirected for traversal purposes (source_id
+-- and target_id treated symmetrically) — agents linking memories don't
+-- always think directionally, and graph-aware recall benefits from
+-- bidirectional reachability.
+--
+-- Cycle-safe: the path[] array tracks visited nodes; we only follow an
+-- edge if its other endpoint is not already in path. Without this check,
+-- the CTE would loop indefinitely on any cycle in the graph.
+--
+-- edge_kinds[] mirrors path: position i in edge_kinds is the relationship_type
+-- of the edge that brought us to position i+1 in path. Caller can filter
+-- downstream by inspecting edge_kinds (e.g., drop rows whose path traversed
+-- a 'contradicts' edge).
+--
+-- Performance note: with ~5K memory_items and ~750 edges (current scale),
+-- recursive expansion to depth 2 returns in <50ms unsharded. At >50K edges
+-- consider materializing precomputed neighborhoods.
+
+create or replace function expand_memory_neighborhood(
+  start_id  uuid,
+  max_depth int default 2
+)
+returns table (
+  memory_id  uuid,
+  depth      int,
+  path       uuid[],
+  edge_kinds text[]
+)
+language sql stable
+as $$
+  with recursive neighborhood as (
+    select
+      start_id                  as memory_id,
+      0                         as depth,
+      array[start_id]           as path,
+      array[]::text[]           as edge_kinds
+    union all
+    select
+      case when r.source_id = n.memory_id then r.target_id else r.source_id end,
+      n.depth + 1,
+      n.path || (case when r.source_id = n.memory_id then r.target_id else r.source_id end),
+      n.edge_kinds || r.relationship_type
+    from neighborhood n
+    join memory_relationships r
+      on (r.source_id = n.memory_id or r.target_id = n.memory_id)
+    where n.depth < max_depth
+      and not (
+        case when r.source_id = n.memory_id then r.target_id else r.source_id end
+        = any (n.path)
+      )
+  )
+  select memory_id, depth, path, edge_kinds from neighborhood;
+$$;

package/packages/server/src/setup/mnestra-migrations/010_memory_recall_graph.sql

@@ -0,0 +1,147 @@
+-- Mnestra v0.3 — memory_recall_graph (Sprint 38 / T3)
+--
+-- Graph-aware recall. Two-stage retrieval:
+--
+--   Stage 1: vector recall via match_memories() — top-K nearest neighbors
+--            in embedding space (existing RPC; tombstone filters inherited).
+--   Stage 2: graph expansion via expand_memory_neighborhood() — for each
+--            stage-1 seed, walk the relationship graph to max_depth.
+--
+-- Re-rank the union of (stage 1 ∪ stage 2) by a combined signal:
+--
+--   final_score = vector_score × edge_weight × recency_score
+--
+-- where:
+--   vector_score  = cosine similarity of seed memory to query (0..1)
+--   edge_weight   = mean of memory_relationships.weight along the path,
+--                   defaulting to 0.5 for edges T2 hasn't classified yet
+--                   (the 749 pre-T2 edges all start with weight = NULL).
+--   recency_score = exp(-age_seconds / (30 × 86400))  (30-day half-life)
+--
+-- Initial (depth=0) results are seeded with edge_weight = 1.0 (no path).
+--
+-- Hard dependencies:
+--   • migration 009 must have run (introduces memory_relationships.weight
+--     and the expand_memory_neighborhood function).
+--   • migration 001 (match_memories, memory_items, memory_relationships).
+--
+-- Rerun-safe: CREATE OR REPLACE.
+
+create or replace function memory_recall_graph (
+  query_embedding   vector(1536),
+  project_filter    text default null,
+  max_depth         int default 2,
+  k                 int default 10
+)
+returns table (
+  memory_id      uuid,
+  content        text,
+  project        text,
+  depth          int,
+  vector_score   float,
+  edge_weight    float,
+  recency_score  float,
+  final_score    float,
+  path           uuid[]
+)
+language sql stable
+as $$
+  with initial as (
+    -- Stage 1: top-K vector recall. match_memories already filters
+    -- is_active / archived / superseded_by / project, so depth-0 hits
+    -- are tombstone-clean. match_threshold=0.0 returns the full top-K
+    -- (we rank by combined signal, not by raw similarity threshold).
+    select
+      mm.id          as memory_id,
+      mm.content,
+      mm.project,
+      0              as depth,
+      mm.similarity  as vector_score,
+      mi.created_at,
+      array[mm.id]   as path
+    from match_memories(query_embedding, 0.0, k, project_filter) mm
+    join memory_items mi on mi.id = mm.id
+  ),
+  expanded as (
+    -- Stage 2: graph expansion. For each stage-1 seed, walk the graph to
+    -- max_depth via T1's expand_memory_neighborhood RPC. Carry the seed's
+    -- vector_score forward (we do NOT re-embed neighbors — the assumption
+    -- is "if A is relevant to the query and B is connected to A, then B
+    -- inherits some of A's relevance, attenuated by the path weight").
+    select
+      n.memory_id,
+      mi.content,
+      mi.project,
+      n.depth,
+      i.vector_score,
+      mi.created_at,
+      n.path,
+      coalesce(
+        (
+          -- Average of edge weights along the path (cycle-safe: T1's CTE
+          -- guarantees no repeats). Pairwise lookup over consecutive path
+          -- elements, treating the relationship as undirected so A→B and
+          -- B→A both count.
+          select avg(coalesce(r.weight, 0.5))
+          from generate_series(1, array_length(n.path, 1) - 1) as g
+          join memory_relationships r
+            on (r.source_id = n.path[g] and r.target_id = n.path[g + 1])
+            or (r.source_id = n.path[g + 1] and r.target_id = n.path[g])
+        ),
+        0.5
+      ) as edge_weight
+    from initial i
+    cross join lateral expand_memory_neighborhood(i.memory_id, max_depth) n
+    join memory_items mi
+      on mi.id = n.memory_id
+     and mi.is_active = true
+     and mi.archived = false
+     and mi.superseded_by is null
+    where n.depth > 0
+      and (project_filter is null or mi.project = project_filter)
+  ),
+  unioned as (
+    -- depth-0 seeds get edge_weight = 1.0 (no path traversed).
+    select memory_id, content, project, depth, vector_score,
+           1.0::float as edge_weight, created_at, path
+    from initial
+    union all
+    select memory_id, content, project, depth, vector_score,
+           edge_weight, created_at, path
+    from expanded
+  ),
+  scored as (
+    -- Same memory may be reached via multiple paths (vector seed AND graph
+    -- expansion, or two different seeds). Keep the strongest path: highest
+    -- final_score wins, with depth-0 (vector hit) preferred on ties.
+    select distinct on (memory_id)
+      memory_id,
+      content,
+      project,
+      depth,
+      vector_score,
+      edge_weight,
+      exp(-extract(epoch from (now() - created_at))::float / (30.0 * 86400.0))
+        as recency_score,
+      vector_score * edge_weight
+        * exp(-extract(epoch from (now() - created_at))::float / (30.0 * 86400.0))
+        as final_score,
+      path
+    from unioned
+    order by memory_id, final_score desc, depth asc
+  )
+  select
+    memory_id, content, project, depth, vector_score,
+    edge_weight, recency_score, final_score, path
+  from scored
+  order by final_score desc
+  limit 50;
+$$;
+
+-- Lightweight grant convention follows existing match_memories. Service-role
+-- and authenticated callers should already have execute by inheritance, but
+-- be explicit for the new function so PostgREST surfaces it without a manual
+-- dashboard step.
+
+grant execute on function memory_recall_graph(vector, text, int, int)
+  to authenticated, service_role, anon;

package/packages/server/src/setup/mnestra-migrations/011_project_tag_backfill.sql

@@ -0,0 +1,237 @@
+-- Sprint 39 T3 — chopin-nashville project-tag backfill.
+--
+-- Why this exists:
+--   memory_items rows tagged project='chopin-nashville' are ~96% polluted
+--   with content from other projects (termdeck, mnestra, rumen, podium, pvb,
+--   dor). Root cause is the harness session-end hook
+--   (~/.claude/hooks/memory-session-end.js, OUT OF THIS REPO): its
+--   PROJECT_MAP iteration tests /ChopinNashville/i first and there are no
+--   entries for termdeck/mnestra/rumen/podium/dor — so any session whose
+--   cwd lives under ~/Documents/Graciella/ChopinNashville/... falls into
+--   chopin-nashville, including the entire TermDeck checkout (which lives at
+--   ChopinNashville/SideHustles/TermDeck/termdeck) and Podium (which lives at
+--   ChopinNashville/2026/ChopinInBohemia/podium).
+--
+--   This migration heals the historical rows. The forward-fix to the harness
+--   hook is Joshua's responsibility (out-of-repo file) and is NOT covered
+--   here — without it, new mis-tagged rows will continue to be written until
+--   he extends PROJECT_MAP with the missing project entries.
+--
+-- What this migration does NOT do:
+--   - Does NOT touch mnestra_session_memory / mnestra_project_memory / etc.
+--     (legacy rag-events tables; different write path; separate cleanup).
+--   - Does NOT consolidate duplicate project tags like 'gorgias' vs
+--     'gorgias-ticket-monitor', 'pvb' vs 'PVB', or 'mnestra' vs 'engram'.
+--     Those are visible in `SELECT project, count(*) FROM memory_items GROUP
+--     BY project` but they're a separate cleanup pass.
+--   - Does NOT touch the ~898 "other/uncertain" chopin-nashville rows that
+--     don't carry an unambiguous project keyword. A future sprint can run an
+--     LLM-classification pass; for this migration, conservative wins.
+--
+-- Heuristic — content keyword bucketing:
+--   The migration runs UPDATEs sequentially. Earlier buckets claim ambiguous
+--   multi-project rows first; later buckets only see rows that no earlier
+--   bucket has already re-tagged. Order is by bucket size (largest first):
+--
+--     1. termdeck / mnestra      — keywords: termdeck, mnestra, "4+1 sprint"
+--     2. rumen                   — keyword:  rumen
+--     3. podium                  — keyword:  podium
+--     4. pvb                     — keywords: PVB, petvetbid, pet vet bid
+--     5. dor / openclaw          — TIGHTENED:
+--                                    word-boundary uppercase DOR  (rules out
+--                                    "dormant", "vendored", "indoor", etc.),
+--                                    plus path/identifier markers and
+--                                    openclaw substring.
+--
+-- Spot-check baseline (T3 audit, 2026-04-27):
+--   termdeck/mnestra: 130 rows, all 6 sampled were true positives (TermDeck
+--                     server code, Mnestra wizard, sprint orchestration).
+--   rumen:            92 rows, all 6 sampled were true positives.
+--   podium:           58 rows, all 6 sampled were true positives.
+--   pvb:               7 rows, 1 of those overlaps with mnestra ("Mnestra
+--                     repo … petvetbid project") and gets claimed by bucket 1.
+--   dor (tightened):   3 rows after tightening from 6 — the original
+--                     `%dor%` ILIKE pattern caught false positives like
+--                     "dormant", "vendored". Final 3 rows are all true
+--                     DOR/OpenClaw mentions.
+--   chopin-nashville total: 1,169 rows. Legitimate-signal baseline (rows
+--                     matching Acceptd / NICPC / Bohemia / laureate /
+--                     applicant / competition / repertoire keywords): 71.
+--
+-- Idempotence:
+--   Every UPDATE is gated by `WHERE project = 'chopin-nashville'`. After the
+--   first run, those rows have a different project tag, so re-running this
+--   migration is a no-op (zero rows updated per bucket). RAISE NOTICE on a
+--   re-run will print zeros, which is the expected idempotent signal.
+--
+-- Application:
+--   THIS MIGRATION IS NOT EXECUTED BY THE LANE THAT WROTE IT. Orchestrator
+--   reviews the RAISE NOTICE counts after applying. Apply via the bundled
+--   migration runner at packages/server/src/setup/migration-runner.js (which
+--   uses node-postgres client.query — psql metacommands like \gset are NOT
+--   available, so the count probes use GET DIAGNOSTICS ROW_COUNT inside DO
+--   blocks). Manual fallback: `psql "$DATABASE_URL" -f 011_project_tag_backfill.sql`.
+
+BEGIN;
+
+-- ============================================================
+-- AUDIT BEFORE
+-- ============================================================
+DO $$
+DECLARE
+  before_chopin    int;
+  before_termdeck  int;
+  before_rumen     int;
+  before_podium    int;
+  before_pvb       int;
+  before_dor       int;
+BEGIN
+  SELECT count(*) INTO before_chopin   FROM memory_items WHERE project = 'chopin-nashville';
+  SELECT count(*) INTO before_termdeck FROM memory_items WHERE project = 'termdeck';
+  SELECT count(*) INTO before_rumen    FROM memory_items WHERE project = 'rumen';
+  SELECT count(*) INTO before_podium   FROM memory_items WHERE project = 'podium';
+  SELECT count(*) INTO before_pvb      FROM memory_items WHERE project = 'pvb';
+  SELECT count(*) INTO before_dor      FROM memory_items WHERE project = 'dor';
+  RAISE NOTICE '[011-backfill] BEFORE  chopin-nashville=% termdeck=% rumen=% podium=% pvb=% dor=%',
+    before_chopin, before_termdeck, before_rumen, before_podium, before_pvb, before_dor;
+END $$;
+
+-- ============================================================
+-- BUCKET 1 — TermDeck / Mnestra (claims multi-project mentions first)
+-- ============================================================
+DO $$
+DECLARE
+  rows_updated int;
+BEGIN
+  UPDATE memory_items SET project = 'termdeck'
+   WHERE project = 'chopin-nashville'
+     AND (
+       content ILIKE '%termdeck%'
+       OR content ILIKE '%mnestra%'
+       OR content ILIKE '%4+1 sprint%'
+     );
+  GET DIAGNOSTICS rows_updated = ROW_COUNT;
+  RAISE NOTICE '[011-backfill] bucket 1 (termdeck/mnestra): % rows re-tagged', rows_updated;
+END $$;
+
+-- ============================================================
+-- BUCKET 2 — Rumen
+-- ============================================================
+DO $$
+DECLARE
+  rows_updated int;
+BEGIN
+  UPDATE memory_items SET project = 'rumen'
+   WHERE project = 'chopin-nashville'
+     AND content ILIKE '%rumen%';
+  GET DIAGNOSTICS rows_updated = ROW_COUNT;
+  RAISE NOTICE '[011-backfill] bucket 2 (rumen): % rows re-tagged', rows_updated;
+END $$;
+
+-- ============================================================
+-- BUCKET 3 — Podium
+-- ============================================================
+DO $$
+DECLARE
+  rows_updated int;
+BEGIN
+  UPDATE memory_items SET project = 'podium'
+   WHERE project = 'chopin-nashville'
+     AND content ILIKE '%podium%';
+  GET DIAGNOSTICS rows_updated = ROW_COUNT;
+  RAISE NOTICE '[011-backfill] bucket 3 (podium): % rows re-tagged', rows_updated;
+END $$;
+
+-- ============================================================
+-- BUCKET 4 — PVB (case-insensitive PVB / petvetbid markers)
+-- ============================================================
+DO $$
+DECLARE
+  rows_updated int;
+BEGIN
+  UPDATE memory_items SET project = 'pvb'
+   WHERE project = 'chopin-nashville'
+     AND (
+       content ILIKE '%PVB%'
+       OR content ILIKE '%petvetbid%'
+       OR content ILIKE '%pet vet bid%'
+     );
+  GET DIAGNOSTICS rows_updated = ROW_COUNT;
+  RAISE NOTICE '[011-backfill] bucket 4 (pvb): % rows re-tagged', rows_updated;
+END $$;
+
+-- ============================================================
+-- BUCKET 5 — DOR / OpenClaw (TIGHTENED — word boundary + identifiers)
+--
+-- Original briefing heuristic was `content ILIKE '%dor%'`, which produced a
+-- ~33% false-positive rate (matched "dormant", "vendored", "indoor", etc.).
+-- T3 audit tightened to:
+--   • POSIX word boundary `\mDOR\M` — case-sensitive uppercase only, so
+--     "dormant" / "DormHall" / "vendor" / "indoor" no longer match.
+--   • path/identifier markers: /DOR/, ~/Documents/DOR, dor.config,
+--     "Rust LLM gateway" (DOR's tagline).
+--   • openclaw substring (OpenClaw is the slack-channel automation product
+--     that lives next to DOR in Joshua's stack).
+-- ============================================================
+DO $$
+DECLARE
+  rows_updated int;
+BEGIN
+  UPDATE memory_items SET project = 'dor'
+   WHERE project = 'chopin-nashville'
+     AND (
+       content ~ '\mDOR\M'
+       OR content ILIKE '%/DOR/%'
+       OR content ILIKE '%~/Documents/DOR%'
+       OR content ILIKE '%dor.config%'
+       OR content ILIKE '%Rust LLM gateway%'
+       OR content ILIKE '%openclaw%'
+     );
+  GET DIAGNOSTICS rows_updated = ROW_COUNT;
+  RAISE NOTICE '[011-backfill] bucket 5 (dor): % rows re-tagged', rows_updated;
+END $$;
+
+-- ============================================================
+-- AUDIT AFTER
+-- ============================================================
+DO $$
+DECLARE
+  after_chopin    int;
+  after_termdeck  int;
+  after_rumen     int;
+  after_podium    int;
+  after_pvb       int;
+  after_dor       int;
+BEGIN
+  SELECT count(*) INTO after_chopin   FROM memory_items WHERE project = 'chopin-nashville';
+  SELECT count(*) INTO after_termdeck FROM memory_items WHERE project = 'termdeck';
+  SELECT count(*) INTO after_rumen    FROM memory_items WHERE project = 'rumen';
+  SELECT count(*) INTO after_podium   FROM memory_items WHERE project = 'podium';
+  SELECT count(*) INTO after_pvb      FROM memory_items WHERE project = 'pvb';
+  SELECT count(*) INTO after_dor      FROM memory_items WHERE project = 'dor';
+  RAISE NOTICE '[011-backfill] AFTER   chopin-nashville=% termdeck=% rumen=% podium=% pvb=% dor=%',
+    after_chopin, after_termdeck, after_rumen, after_podium, after_pvb, after_dor;
+  RAISE NOTICE '[011-backfill] If apply succeeds and chopin-nashville count is around the legitimate baseline (~71 rows match competition/laureate/applicant/Acceptd/NICPC/Bohemia/repertoire keywords as of T3 audit), the migration succeeded. The ~898 rows that remain under chopin-nashville without a clear keyword signal are deliberate — a future LLM-classification pass can address them if needed.';
+END $$;
+
+COMMIT;
+
+-- ============================================================
+-- POST-APPLY: optional verification queries (NOT part of the migration).
+-- Run separately to confirm Flashback against project='termdeck' now hits
+-- the re-tagged rows.
+-- ============================================================
+--
+-- 1. Tag distribution after migration:
+--    SELECT project, count(*) FROM memory_items GROUP BY project ORDER BY count(*) DESC LIMIT 20;
+--
+-- 2. Confirm no chopin-nashville rows match obvious termdeck/rumen keywords:
+--    SELECT count(*) FROM memory_items
+--     WHERE project='chopin-nashville'
+--       AND (content ILIKE '%termdeck%' OR content ILIKE '%rumen%' OR content ILIKE '%podium%');
+--    -- Expected: 0
+--
+-- 3. Confirm Flashback project-bound test corpus (>= 5 termdeck-tagged rows
+--    matching the canonical probe question):
+--    SELECT count(*) FROM memory_items
+--     WHERE project='termdeck' AND content ILIKE '%shell error%';

package/packages/server/src/setup/rumen/migrations/003_graph_inference_schedule.sql

@@ -0,0 +1,49 @@
+-- Sprint 38 T2 — Graph-inference cron schedule.
+-- Schedules the graph-inference Supabase Edge Function to run daily at
+-- 03:00 UTC (≈ 23:00 ET, after typical work hours). The Edge Function
+-- scans memory_items for pairs above GRAPH_INFERENCE_THRESHOLD (default
+-- 0.85 cosine similarity), inserts edges into memory_relationships with
+-- inferred_by = 'cron-YYYY-MM-DD' for audit trail, and optionally
+-- classifies edge types via Haiku 4.5 (gated by GRAPH_LLM_CLASSIFY=1).
+--
+-- Coexists with the existing rag-system MCP-side ingest classifier:
+-- this cron handles backfill + cross-project + stale-edge refresh; the
+-- ingest classifier handles fresh per-memory edges in the 0.75-0.92
+-- window.  See Sprint 38 T2 FINDING for the full coexistence design.
+--
+-- Before applying:
+--   1. The pg_cron and pg_net extensions must already be enabled
+--      (rumen migration 002 enables them; 003 assumes that prereq).
+--   2. Add a Vault secret named 'graph_inference_service_role_key'
+--      containing the project's service-role JWT.  Separate from
+--      'rumen_service_role_key' so a key rotation on one cron doesn't
+--      affect the other.
+--   3. Replace <project-ref> below with the project's Supabase ref
+--      (stack-installer substitutes this at apply-time, same as 002).
+--
+-- Apply with:
+--   psql "$DIRECT_URL" -f migrations/003_graph_inference_schedule.sql
+
+-- Idempotent unschedule.
+SELECT cron.unschedule('graph-inference-tick')
+  WHERE EXISTS (SELECT 1 FROM cron.job WHERE jobname = 'graph-inference-tick');
+
+-- Schedule daily at 03:00 UTC.
+SELECT cron.schedule(
+  'graph-inference-tick',
+  '0 3 * * *',
+  $$
+    SELECT net.http_post(
+      url     := 'https://<project-ref>.supabase.co/functions/v1/graph-inference',
+      headers := jsonb_build_object(
+        'Content-Type',  'application/json',
+        'Authorization', 'Bearer ' || (SELECT decrypted_secret FROM vault.decrypted_secrets WHERE name = 'graph_inference_service_role_key')
+      ),
+      body    := '{}'::jsonb
+    );
+  $$
+);
+
+-- Verify:
+-- SELECT jobname, schedule, active FROM cron.job WHERE jobname = 'graph-inference-tick';
+-- SELECT * FROM cron.job_run_details WHERE jobname = 'graph-inference-tick' ORDER BY start_time DESC LIMIT 5;