@rulemetric/local 0.12.8 → 0.13.0

package/dist/supabase/migrations/00213_vendor_guidance_snapshots.sql

@@ -0,0 +1,52 @@
+-- 00213 — vendor guidance snapshots.
+--
+-- One row per DISTINCT extracted text of a registered guidance source
+-- (GUIDANCE_SOURCES in apps/api/src/lib/guidance/sources.ts): Claude Code /
+-- Codex changelogs, docs pages and best-practice posts. Identity is the hash
+-- of the extracted TEXT, not the HTML — blog pages carry per-request nonces
+-- and build ids, and hashing the raw page would file a "new guidance" pitch
+-- every six hours.
+--
+-- `previous_snapshot_id` links a change to what it changed from so the pitch
+-- can carry the added lines; NULL means first sight of the source.
+-- `pitched_at` records that the producer has DEALT with this snapshot — either
+-- materialised it as a pitch (`pitch_instruction_id` names the public
+-- `instructions` row) or deliberately recorded it as a baseline (a changelog's
+-- first snapshot is never pitched; `pitch_instruction_id` stays NULL). The two
+-- are distinguishable on purpose: "nothing to pitch" and "not yet processed"
+-- have repeatedly been reported identically by this pipeline.
+--
+-- Plan: docs/plans/2026-08-29-vendor-guidance-ingestion-plan.md.
+create table if not exists vendor_guidance_snapshots (
+  id                    uuid primary key default gen_random_uuid(),
+  fetched_at            timestamptz not null default now(),
+  source_id             text not null,
+  harness               text not null,
+  vendor                text not null,
+  kind                  text not null check (kind in ('blog', 'docs', 'changelog')),
+  url                   text not null,
+  title                 text not null,
+  content_hash          text not null,
+  text                  text not null,
+  previous_snapshot_id  uuid references vendor_guidance_snapshots(id) on delete set null,
+  pitched_at            timestamptz,
+  pitch_instruction_id  uuid references instructions(id) on delete set null
+);
+
+create unique index if not exists idx_vendor_guidance_dedup
+  on vendor_guidance_snapshots (source_id, content_hash);
+create index if not exists idx_vendor_guidance_source_fetched
+  on vendor_guidance_snapshots (source_id, fetched_at desc);
+
+alter table vendor_guidance_snapshots enable row level security;
+
+drop policy if exists "service role manages vendor guidance" on vendor_guidance_snapshots;
+create policy "service role manages vendor guidance"
+  on vendor_guidance_snapshots for all to service_role using (true) with check (true);
+
+drop policy if exists "authenticated read vendor guidance" on vendor_guidance_snapshots;
+create policy "authenticated read vendor guidance"
+  on vendor_guidance_snapshots for select to authenticated using (true);
+
+comment on table vendor_guidance_snapshots is
+  'Distinct extracted texts of registered vendor guidance pages (changelogs, docs, blog posts). Producer: apps/api/src/lib/guidance/sync.ts. Each pitched snapshot becomes one public feature instruction + per-(user,project) suggestions at score 0.4 — never auto-adopted (type feature is refused by isAutoAdoptable unconditionally).';

package/dist/supabase/migrations/00214_host_suspend_recoveries.sql

@@ -0,0 +1,54 @@
+-- Two recovery budgets were reading one counter, so the generous one silently
+-- spent the strict one.
+--
+-- 00155 added `lease_recoveries`: a budget for "the process hosting the handler
+-- went away", kept apart from `attempts` ("the handler tried and failed") so a
+-- wedge cannot kill a MAX_ATTEMPTS=1 job. Since then TWO independent paths have
+-- come to spend it, with deliberately different caps:
+--
+--   * the reconciler's lease sweep — the worker VANISHED and the lease lapsed.
+--     MAX_HOST_ABSENT_RECOVERIES = 12 when the presence heartbeat was already
+--     gone at expiry (a suspended laptop), MAX_LEASE_RECOVERIES = 1 otherwise.
+--     Generous, because the handler usually never started: a recovery is free.
+--
+--   * POST /api/work/:id/fail with hostSuspended — the worker SURVIVED the
+--     suspend, unwound, and reported the failure itself, so the reconciler
+--     never sees the row. MAX_HOST_SUSPEND_RECOVERIES = 3. Strict on purpose:
+--     the handler ran and may have spent tokens, so each recovery costs a
+--     partial redo.
+--
+-- Both read `lease_recoveries`, so the strict cap never acted as a per-path
+-- budget. It acted as a gate on the total the OTHER path had already spent: a
+-- row with 3+ reconciler-spent recoveries could never receive a self-report
+-- recovery again, however few self-reported suspends it had had.
+--
+-- Reproduced 2026-08-31 against the real endpoints, two rows identical but for
+-- the counter the reconciler had filled:
+--
+--   prior lease_recoveries = 4  ->  hostSuspendRecovery false, status FAILED
+--   prior lease_recoveries = 0  ->  requeued, status pending
+--
+-- Four is a third of the reconciler's own budget. So a row it was still happily
+-- carrying died permanently on its FIRST self-reported suspend — the friendlier
+-- signal producing the harsher outcome, at MAX_ATTEMPTS = 1, on exactly the two
+-- kinds the census shows failing this way (cron_auto_accept_suggestions,
+-- cron_reconcile_attribution).
+--
+-- The fix is a second column, not a bigger number: raising
+-- MAX_HOST_SUSPEND_RECOVERIES to 12 would discard the cost distinction that
+-- justifies it, and provenance cannot be recovered from a single counter after
+-- the fact. `lease_recoveries` keeps its meaning and its owner (the reconciler);
+-- the self-report path gets its own.
+
+ALTER TABLE eval_jobs         ADD COLUMN IF NOT EXISTS host_suspend_recoveries integer NOT NULL DEFAULT 0;
+ALTER TABLE insights_jobs     ADD COLUMN IF NOT EXISTS host_suspend_recoveries integer NOT NULL DEFAULT 0;
+ALTER TABLE launch_jobs       ADD COLUMN IF NOT EXISTS host_suspend_recoveries integer NOT NULL DEFAULT 0;
+ALTER TABLE session_send_jobs ADD COLUMN IF NOT EXISTS host_suspend_recoveries integer NOT NULL DEFAULT 0;
+ALTER TABLE agent_jobs        ADD COLUMN IF NOT EXISTS host_suspend_recoveries integer NOT NULL DEFAULT 0;
+
+COMMENT ON COLUMN agent_jobs.host_suspend_recoveries IS
+  'Times this row was excused because the worker reported the MACHINE was suspended mid-run (POST /api/work/:id/fail with hostSuspended). Separate from `lease_recoveries`, which the reconciler owns for rows whose lease lapsed: the two budgets have different caps for different reasons, and sharing one counter let the generous one exhaust the strict one. See apps/api/src/routes/work-result.ts.';
+
+-- Existing rows start at 0. That is deliberate and safe in the forgiving
+-- direction: a row carrying reconciler-spent recoveries today gets its
+-- self-report budget back, which is precisely the behaviour this restores.

package/dist/supabase/migrations/00215_worker_presence_gap.sql

@@ -0,0 +1,29 @@
+-- 00215: record the presence heartbeat's OUTAGES, not just its last beat.
+--
+-- `worker_connections.last_heartbeat` is a single upserted column. It answers
+-- "when did this worker last speak", which is a question about NOW. The
+-- reconciler (00155, and the host-absent split of 2026-08-29) needs a question
+-- about the PAST: was the host there when this lease lapsed ten minutes ago?
+--
+-- Comparing the current `last_heartbeat` against a past `lease_expires_at`
+-- cannot answer it. A laptop that suspends, misses the expiry and WAKES before
+-- the reconciler's 5-minute sweep reports a heartbeat newer than the expiry, so
+-- it reads as "alive right through it" — the crash budget (1), not the
+-- host-absent budget (12). The census's own suspends are 2–9 minutes long,
+-- which is exactly the window where the wake lands first.
+--
+-- These two columns are the evidence recorded at the time: the beat before a
+-- silence and the beat that ended it. Only the most recent silence is kept —
+-- the reconciler sweeps within five minutes of an expiry, so the newest outage
+-- is the one that can bracket it. NULL means "no outage observed", which is
+-- what every existing row gets: the reconciler then falls back to exactly the
+-- comparison it makes today, so this migration changes no behaviour on its own.
+
+ALTER TABLE public.worker_connections
+  ADD COLUMN IF NOT EXISTS presence_gap_started_at timestamptz,
+  ADD COLUMN IF NOT EXISTS presence_gap_ended_at   timestamptz;
+
+COMMENT ON COLUMN public.worker_connections.presence_gap_started_at IS
+  'Last presence heartbeat before the most recent observed silence (NULL if none). With presence_gap_ended_at this brackets an outage, so the reconciler can ask whether a lease expiry fell inside it instead of comparing against a heartbeat that has since moved on.';
+COMMENT ON COLUMN public.worker_connections.presence_gap_ended_at IS
+  'The heartbeat that ended the most recent observed silence (NULL if none).';

package/dist/supabase/migrations/00216_db_headroom_check_and_worker_connections_fk.sql

@@ -0,0 +1,142 @@
+-- 2026-09-01 — two "forever" fixes from the prod read-only incident.
+--
+-- INCIDENT. Prod went read-only twice in twelve hours (2026-08-31 ~19:55Z and
+-- 2026-09-01 ~03:53Z): Supabase's disk-threshold read-only mode while the
+-- database sat at 37 GB — 34 GB of it context_snapshots, 23 GB of that INLINE
+-- messages_delta (65,487 rows; 23,196 rows > 256 kB hold 20 GB). Nothing
+-- alarmed: the only readers of pg_database_size were humans running ad-hoc SQL.
+-- Every write in the window failed, including the onboarding cold-start
+-- harness's CLEANUP, which then left an orphan worker_connections row behind
+-- (the auth user was deleted, the row survived: worker_connections has NO
+-- foreign key to profiles at all — three such orphans were found).
+--
+-- FIX 1 — worker_connections gets the FK it always should have had (ON DELETE
+-- CASCADE to profiles), after sweeping the orphans it would reject. A deleted
+-- user can no longer leave a heartbeat row behind, so the cold-start harness's
+-- "cleanup INCOMPLETE — manual sweep needed" can never again be caused by this
+-- table.
+--
+-- FIX 2 — db_headroom_check(): a daily, notifying disk-headroom monitor in the
+-- 00147/00209 pattern (one consolidated notification per superadmin, deduped
+-- while unread). It records db/WAL size daily in db_headroom_metrics so growth
+-- is a queryable series, and fires when usage crosses warn_ratio of
+-- disk_limit_bytes (operator-set from the Supabase dashboard — SQL cannot see
+-- the disk ceiling) OR when 7-day growth exceeds growth_alarm_bytes (fires
+-- even while the limit is unset, so a misconfigured monitor is still a loud
+-- one). Per the conformance rule, apps/api/test/db-headroom.test.ts proves the
+-- check FIRES on a seeded low limit and stays QUIET on a healthy one.
+
+-- ───────────────────────── FIX 1: worker_connections FK ─────────────────────
+DELETE FROM worker_connections w
+WHERE NOT EXISTS (SELECT 1 FROM profiles p WHERE p.id = w.user_id);
+
+ALTER TABLE worker_connections
+  DROP CONSTRAINT IF EXISTS worker_connections_user_id_profiles_fk;
+ALTER TABLE worker_connections
+  ADD CONSTRAINT worker_connections_user_id_profiles_fk
+  FOREIGN KEY (user_id) REFERENCES profiles(id) ON DELETE CASCADE;
+
+-- ───────────────────────── FIX 2: headroom monitor ──────────────────────────
+CREATE TABLE IF NOT EXISTS db_headroom_config (
+  id                 boolean PRIMARY KEY DEFAULT true CHECK (id),   -- single row
+  disk_limit_bytes   bigint,            -- NULL until the operator reads the dashboard
+  warn_ratio         real NOT NULL DEFAULT 0.80,
+  growth_alarm_bytes bigint NOT NULL DEFAULT 2147483648,  -- 2 GiB per 7 days
+  updated_at         timestamptz NOT NULL DEFAULT now()
+);
+INSERT INTO db_headroom_config (id) VALUES (true) ON CONFLICT (id) DO NOTHING;
+COMMENT ON TABLE db_headroom_config IS
+  'Operator-set disk ceiling for db_headroom_check(). disk_limit_bytes comes from the Supabase dashboard (Database → Disk); SQL cannot observe it. NULL = ratio alarm disabled, growth alarm still active.';
+
+CREATE TABLE IF NOT EXISTS db_headroom_metrics (
+  measured_at timestamptz NOT NULL DEFAULT now(),
+  db_bytes    bigint NOT NULL,
+  wal_bytes   bigint,
+  PRIMARY KEY (measured_at)
+);
+COMMENT ON TABLE db_headroom_metrics IS
+  'Daily samples written by db_headroom_check() — the growth series behind the headroom alarm and the operator''s "how fast is it filling" question.';
+
+CREATE OR REPLACE FUNCTION public.db_headroom_check()
+RETURNS integer
+LANGUAGE plpgsql
+SECURITY DEFINER
+SET search_path TO 'public'
+AS $$
+DECLARE
+  cfg        db_headroom_config%ROWTYPE;
+  v_db       bigint;
+  v_wal      bigint;
+  v_prev     bigint;
+  v_growth   bigint;
+  v_ratio    real;
+  v_lines    text := '';
+  v_created  integer := 0;
+BEGIN
+  SELECT * INTO cfg FROM db_headroom_config WHERE id = true;
+
+  v_db := pg_database_size(current_database());
+  BEGIN
+    SELECT COALESCE(sum(size), 0)::bigint INTO v_wal FROM pg_ls_waldir();
+  EXCEPTION WHEN OTHERS THEN
+    v_wal := NULL;   -- not privileged on every host; the db size alone still alarms
+  END;
+
+  INSERT INTO db_headroom_metrics (measured_at, db_bytes, wal_bytes)
+  VALUES (now(), v_db, v_wal)
+  ON CONFLICT (measured_at) DO NOTHING;
+
+  -- 7-day growth: the oldest sample inside the window, else no growth signal yet.
+  SELECT db_bytes INTO v_prev
+  FROM db_headroom_metrics
+  WHERE measured_at >= now() - interval '7 days'
+    AND measured_at < now() - interval '6 days'
+  ORDER BY measured_at ASC LIMIT 1;
+  v_growth := CASE WHEN v_prev IS NULL THEN NULL ELSE v_db - v_prev END;
+
+  IF cfg.disk_limit_bytes IS NOT NULL AND cfg.disk_limit_bytes > 0 THEN
+    v_ratio := v_db::real / cfg.disk_limit_bytes::real;
+    IF v_ratio >= cfg.warn_ratio THEN
+      v_lines := v_lines || format(E'• database is %s of the %s disk ceiling (%s) — Supabase flips the project READ-ONLY near 95%%; every write then fails\n',
+        round((v_ratio * 100)::numeric, 1) || '%', pg_size_pretty(cfg.disk_limit_bytes), pg_size_pretty(v_db));
+    END IF;
+  END IF;
+
+  IF v_growth IS NOT NULL AND v_growth >= cfg.growth_alarm_bytes THEN
+    v_lines := v_lines || format(E'• database grew %s in 7 days (now %s) — check context_snapshots inline messages_delta and the delta offload\n',
+      pg_size_pretty(v_growth), pg_size_pretty(v_db));
+  END IF;
+
+  IF v_lines = '' THEN
+    RETURN 0;
+  END IF;
+
+  INSERT INTO notifications (user_id, type, title, body, url, metadata)
+  SELECT p.id,
+         'db_headroom',
+         'Database disk headroom needs attention',
+         v_lines || format('WAL: %s. Set db_headroom_config.disk_limit_bytes from the Supabase dashboard if unset.',
+                           COALESCE(pg_size_pretty(v_wal), 'n/a')),
+         '/loop',
+         jsonb_build_object('db_bytes', v_db, 'wal_bytes', v_wal, 'growth_7d_bytes', v_growth,
+                            'disk_limit_bytes', cfg.disk_limit_bytes)
+  FROM profiles p
+  WHERE p.is_superadmin = true
+    AND NOT EXISTS (
+      SELECT 1 FROM notifications n
+      WHERE n.user_id = p.id AND n.type = 'db_headroom' AND n.read_at IS NULL
+    );
+  GET DIAGNOSTICS v_created = ROW_COUNT;
+  RETURN v_created;
+END;
+$$;
+COMMENT ON FUNCTION public.db_headroom_check() IS
+  'Daily disk-headroom monitor (2026-09-01 read-only incident). Samples db/WAL size into db_headroom_metrics; notifies superadmins (deduped while unread) when usage >= warn_ratio of the operator-set disk ceiling or 7-day growth >= growth_alarm_bytes. Returns notifications created.';
+
+-- Daily at 05:40 UTC, after the other 05:xx health sweeps. Re-runnable.
+DO $$
+BEGIN
+  PERFORM cron.unschedule(jobid) FROM cron.job WHERE jobname = 'db_headroom_check';
+EXCEPTION WHEN OTHERS THEN NULL;
+END $$;
+SELECT cron.schedule('db_headroom_check', '40 5 * * *', $$select public.db_headroom_check();$$);

package/dist/supabase/migrations/00217_harbor_ab_cadence.sql

@@ -0,0 +1,46 @@
+-- 00217: the external A/B harness's schedule, as a setting instead of an incantation.
+--
+-- The Harbor harness (scripts/harbor/) measures a rule's effect by running the
+-- same containerised task twice — with and without the instruction — and
+-- comparing pass rates and cost. Until now it ran only when a human typed
+-- `./run.sh`, and its results were written to /tmp, which a reboot deletes.
+--
+-- This column is the schedule. It is a single enum rather than a set of
+-- booleans because every prior scheduling opt-in in this system became a knob
+-- with no surface: the seven `autoEvolve*` flags governed a nightly job allowed
+-- to rewrite CLAUDE.md and `grep autoEvolve apps/web/src` returned nothing
+-- (2026-08-10), and the eval autorun opt-in is documented as a raw UPDATE in a
+-- migration comment. One named, constrained value is readable back to the user;
+-- a spread of booleans is not.
+--
+-- DEFAULT 'off' is load-bearing and is not merely conservative. A sweep spends
+-- the user's own subscription quota and their laptop's CPU spawning agent
+-- processes (~$2.50 and 10-15 minutes per task, measured 2026-09-02 at n=25 per
+-- arm). Nothing that spends a user's money may default to on.
+--
+-- The CHECK is the reason this is a column and not free text: an unrecognised
+-- cadence must fail at write time. A producer that reads a value it does not
+-- understand has two options, run or skip, and both are wrong — running spends
+-- money the user did not ask for, skipping is silent and looks exactly like a
+-- quiet night, which is the failure mode this whole area keeps rediscovering.
+--
+-- Values (see apps/api/src/lib/harbor-settings.ts for the spend and detection
+-- latency attached to each):
+--   off        no schedule; still runnable on demand. The default.
+--   weekly     one sweep a week over tasks proven to discriminate.
+--   nightly    one rotating task per night; buys latency, not statistical power.
+--   on_change  only when a measured rule is edited or promoted.
+--   two_speed  weekly proven + a monthly pass over measured negatives.
+
+ALTER TABLE public.profiles
+  ADD COLUMN IF NOT EXISTS harbor_ab_cadence text NOT NULL DEFAULT 'off';
+
+ALTER TABLE public.profiles
+  DROP CONSTRAINT IF EXISTS profiles_harbor_ab_cadence_check;
+
+ALTER TABLE public.profiles
+  ADD CONSTRAINT profiles_harbor_ab_cadence_check
+  CHECK (harbor_ab_cadence IN ('off', 'weekly', 'nightly', 'on_change', 'two_speed'));
+
+COMMENT ON COLUMN public.profiles.harbor_ab_cadence IS
+  'Schedule for the external Harbor A/B harness. Default off — a sweep spends the user''s subscription quota and laptop CPU. Enabling is gated on a worker having REPORTED Harbor readiness (docker + harbor + agent CLI); see harbor-settings.ts. Never gate this as a worker capability: that is how DB_REQUIRING_KINDS made features die invisibly for every user outside a repo checkout (#287).';