@rulemetric/local 0.12.3 → 0.12.5

package/dist/supabase/migrations/00206_reconcile_attribution_producer.sql

@@ -0,0 +1,156 @@
+-- A routine that looks for sessions nobody counted.
+--
+-- THE DEFECT CLASS. The proxy auto-bootstraps a session from LLM traffic before
+-- any hook has run, so it has the wire id but no cwd, and the row lands with
+-- project_path and project_id NULL. Events keep flowing. Nothing errors. But
+-- BOTH insights consumers filter on attribution --
+-- `regenerate_insights_jobs()` selects `where s.project_id is not null`, and
+-- routes/insights/jobs.ts requires it too -- so the session is never counted.
+--
+-- The only symptom is silence: a project simply has no insights. Measured
+-- 2026-08-26 on the cloud DB, 354 sessions / 39,193 events were orphaned this
+-- way, one repo having lost every session it ever had across four days of work,
+-- and it surfaced only because a human asked why that project looked empty.
+-- `create.ts:repairAttribution` stops new sessions from orphaning; this
+-- producer is what finds the ones already on the books, and anything a future
+-- gap lets through.
+--
+-- WHY A WORKER JOB AND NOT A SQL BACKFILL. This function deliberately does no
+-- repairing itself. Repair needs a git remote or root commit, and only 6 of
+-- those 354 rows carried ANY git metadata -- the server has nothing to match
+-- on. Matching on project_path alone is precisely the cwd-only fallback Phase
+-- 12 removed for causing misassignment, and a routine running unattended every
+-- hour must not reintroduce it. The evidence lives on the machine that ran the
+-- session: the checkout is still on disk and `git remote get-url origin` still
+-- answers. So the handler reads the anchors there and POSTs them to
+-- POST /api/sessions, which routes into the same `repairAttribution` the live
+-- hook uses -- one implementation of the match order, two callers.
+--
+-- SCHEDULE. Hourly at :20, off the nightly loop slots (04:30 suggestions ->
+-- 05:00 auto-accept -> 05:30 refine -> 05:45 retire -> 06:10 autorun -> 07:30
+-- evolution). Attribution repair is cheap, reads no LLM, and wants to happen
+-- BEFORE the 6-hourly insights producer at 00/06/12/18 so a session repaired
+-- this hour is counted in the next insights pass rather than waiting a day.
+-- ---------------------------------------------------------------------------
+
+create or replace function public.enqueue_reconcile_attribution()
+returns integer
+language plpgsql
+security definer
+set search_path = public
+as $$
+declare
+  queued integer;
+begin
+  with eligible as (
+    select s.user_id
+    from public.sessions s
+    -- INVISIBLE TO INSIGHTS is wider than project_id IS NULL. This function
+    -- INNER JOINs project_canonical_checkouts, which is built from
+    -- project_checkouts -- so a project with no checkout row is skipped no
+    -- matter how well its sessions are attributed, and a project whose every
+    -- session was orphaned has never had one recorded (the insert path only
+    -- upserts on a match). Chasing only the NULL half is how the first real
+    -- reconcile pass attributed Thrakopontia and left it exactly as unable to
+    -- produce insights as before.
+    where (
+        s.project_id is null
+        or not exists (
+          select 1 from public.project_checkouts pc where pc.project_id = s.project_id
+        )
+      )
+      -- Only chase orphans a worker could plausibly still repair. A session
+      -- whose checkout was deleted years ago is permanently unrepairable, and
+      -- re-walking it every hour forever is pure noise. 90 days is well past
+      -- Claude Code's transcript retention, which is the recovery source for
+      -- the pathless shape.
+      and s.started_at > now() - interval '90 days'
+      -- Sessions with no external id cannot be addressed through
+      -- POST /api/sessions at all (it matches on external_session_id), so the
+      -- handler would only count them as unrepairable. Do not enqueue for a
+      -- user who has nothing BUT those.
+      and s.external_session_id is not null
+      -- Temp fixtures and home directories are orphaned CORRECTLY. The handler
+      -- refuses them; not enqueuing on their account keeps a guaranteed refusal
+      -- out of the hourly feed.
+      and (
+        s.project_path is null
+        or (
+          s.project_path !~ '^/(private/)?(tmp|var/folders)'
+          and s.project_path !~ '^/(Users|home)/[^/]+/?$'
+        )
+      )
+    group by s.user_id
+  ), fresh as (
+    select e.user_id
+    from eligible e
+    -- One in flight at a time, per the 00083/00086 pattern.
+    where not exists (
+      select 1 from public.agent_jobs j
+      where j.task_kind = 'cron_reconcile_attribution'
+        and j.status in ('pending', 'claimed', 'running')
+        and j.user_id = e.user_id
+    )
+    -- Do not re-run within the hour for a user whose last pass just completed.
+    -- The orphan set only changes when new sessions land or a checkout appears.
+    and not exists (
+      select 1 from public.agent_jobs j
+      where j.task_kind = 'cron_reconcile_attribution'
+        and j.user_id = e.user_id
+        and j.status = 'completed'
+        and j.completed_at > now() - interval '50 minutes'
+    )
+  ), ins as (
+    insert into agent_jobs (user_id, task_kind, status, payload, dedupe_key)
+    select f.user_id,
+           'cron_reconcile_attribution',
+           'pending',
+           jsonb_build_object('limit', 200),
+           'reconcile-attribution:' || f.user_id
+    from fresh f
+    returning 1
+  )
+  select count(*)::int into queued from ins;
+
+  return queued;
+end;
+$$;
+
+comment on function public.enqueue_reconcile_attribution() is
+  'Hourly producer for cron_reconcile_attribution (:20). Enqueues one run per user holding sessions with project_id NULL that a worker could still repair (under 90 days old, has an external_session_id, not a temp/home path). Does NOT repair anything itself: attribution needs git anchors that live on the machine that ran the session, and matching on project_path alone is the cwd-only fallback Phase 12 removed. The handler reads those anchors from disk and POSTs them to POST /api/sessions, where repairAttribution performs the write.';
+
+-- Observability: the residual count, so a rising floor of unrepairable orphans
+-- is visible instead of being smoothed away. `repairable_recent` is what the
+-- producer actually chases; `total` is every orphan on the books.
+create or replace view public.session_attribution_health as
+select
+  s.user_id,
+  count(*)::int as total_unattributed,
+  count(*) filter (
+    where s.started_at > now() - interval '90 days'
+      and s.external_session_id is not null
+      and (
+        s.project_path is null
+        or (
+          s.project_path !~ '^/(private/)?(tmp|var/folders)'
+          and s.project_path !~ '^/(Users|home)/[^/]+/?$'
+        )
+      )
+  )::int as repairable_recent,
+  sum(s.event_count)::bigint as orphaned_events,
+  max(s.started_at) as newest_orphan
+from public.sessions s
+where s.project_id is null
+   or not exists (
+     select 1 from public.project_checkouts pc where pc.project_id = s.project_id
+   )
+group by s.user_id;
+
+comment on view public.session_attribution_health is
+  'Per-user count of sessions invisible to the insights pipeline (project_id IS NULL). repairable_recent is the subset cron_reconcile_attribution will attempt; a total that keeps climbing while repairable_recent stays near zero means the orphans are structurally unrepairable, not that the reconciler is failing.';
+
+select cron.schedule(
+  'enqueue_reconcile_attribution',
+  '20 * * * *',
+  $$select public.enqueue_reconcile_attribution();$$
+);

package/dist/supabase/migrations/00207_repair_project_paths.sql

@@ -0,0 +1,183 @@
+-- Repair the two data shapes that leave a correctly-attributed project unable
+-- to produce insights.
+--
+-- Both are consequences of the same root cause fixed in code on 2026-08-26: the
+-- subdir-consolidation normalizer in POST /sessions collapsed any path under a
+-- known session path to that parent, treated `/Users/<user>` as a valid parent,
+-- and picked an ARBITRARY first match. So sessions landed with the HOME
+-- DIRECTORY as their project_path, and `upsertProjectCheckout` (rightly)
+-- refuses to record a home dir as a checkout. The project_id was correct the
+-- whole time -- it comes from the git remote at capture -- but with no row in
+-- project_checkouts, `project_canonical_checkouts` is empty for that project
+-- and `regenerate_insights_jobs()` INNER JOINs that view. Attributed, and
+-- invisible.
+--
+-- Measured on prod 2026-08-26:
+--   * kc-content-workspace: 191 sessions, 181 of them at `/Users/kylechalmers`,
+--     ZERO checkouts. Same for kc-ops-workspace (41 sessions, 28 at home).
+--     This is also what 00205's canonical-checkout gate blocks: that user's
+--     auto-accept lane is dead until his checkouts are registered. Registering
+--     them is the fix; widening the gate is not.
+--   * context-engineering-intro exists TWICE -- one row with a git remote and
+--     root commit (4 sessions, no checkout) and one anchorless legacy row (no
+--     remote, no root commit, 1 session) that HOLDS the checkout for the path.
+--     Because project_checkouts has a GLOBAL unique index on `path` while the
+--     upsert conflicts on the (project_id, path) primary key, the real project
+--     could never record its own checkout: 23505, swallowed, forever.
+--
+-- Both halves are written as idempotent FUNCTIONS rather than one-shot DO
+-- blocks so they can be tested, re-run, and called again if the shape recurs.
+-- ---------------------------------------------------------------------------
+
+-- ── 1. Merge anchorless duplicate project rows ──────────────────────────────
+--
+-- A project row with NEITHER a git_remote_url NOR a git_root_commit has no
+-- identity anchor at all -- it predates git-context-as-identity and can never
+-- be matched again by capture. When such a row shares a name with a project
+-- that DOES have an anchor, it is the same repo, and everything hanging off it
+-- belongs to the anchored row.
+--
+-- STRICT: only merges when exactly ONE candidate keeper exists for the name.
+-- Two anchored rows for one name is a different problem (a real fork, or a
+-- rename) and must not be resolved by guessing.
+create or replace function public.merge_anchorless_duplicate_projects()
+returns integer
+language plpgsql
+security definer
+set search_path = public
+as $$
+declare
+  merged integer := 0;
+  r record;
+begin
+  for r in
+    select dud.id as dud_id, keeper.id as keeper_id
+    from public.projects dud
+    join lateral (
+      select k.id
+      from public.projects k
+      where k.name = dud.name
+        and k.id <> dud.id
+        and (k.git_remote_url is not null or k.git_root_commit is not null)
+      limit 2
+    ) keeper on true
+    where dud.git_remote_url is null
+      and dud.git_root_commit is null
+      -- Exactly one keeper, or we are guessing.
+      and (
+        select count(*) from public.projects k2
+        where k2.name = dud.name and k2.id <> dud.id
+          and (k2.git_remote_url is not null or k2.git_root_commit is not null)
+      ) = 1
+  loop
+    -- project_checkouts carries a GLOBAL unique index on `path`, so a straight
+    -- repoint collides whenever the keeper already knows the path. Drop the
+    -- dud's row in that case; otherwise move it.
+    delete from public.project_checkouts c
+    where c.project_id = r.dud_id
+      and exists (
+        select 1 from public.project_checkouts k
+        where k.path = c.path and k.project_id = r.keeper_id
+      );
+    update public.project_checkouts set project_id = r.keeper_id where project_id = r.dud_id;
+
+    update public.sessions                     set project_id = r.keeper_id where project_id = r.dud_id;
+    update public.insights_jobs                set project_id = r.keeper_id where project_id = r.dud_id;
+    update public.instruction_suggestions      set project_id = r.keeper_id where project_id = r.dud_id;
+    update public.agent_runs                   set project_id = r.keeper_id where project_id = r.dud_id;
+    update public.treatment_assignments        set project_id = r.keeper_id where project_id = r.dud_id;
+    update public.memories                     set project_id = r.keeper_id where project_id = r.dud_id;
+    update public.pending_treatment_exposures  set project_id = r.keeper_id where project_id = r.dud_id;
+    update public.recommendation_applications  set project_id = r.keeper_id where project_id = r.dud_id;
+
+    -- project_instructions is UNIQUE on (project_id, instruction_id) and
+    -- CASCADE-deletes, so drop links the keeper already holds before moving.
+    delete from public.project_instructions pi
+    where pi.project_id = r.dud_id
+      and exists (
+        select 1 from public.project_instructions k
+        where k.project_id = r.keeper_id and k.instruction_id = pi.instruction_id
+      );
+    update public.project_instructions set project_id = r.keeper_id where project_id = r.dud_id;
+
+    delete from public.projects where id = r.dud_id;
+    merged := merged + 1;
+  end loop;
+
+  return merged;
+end;
+$$;
+
+comment on function public.merge_anchorless_duplicate_projects() is
+  'Merges a projects row that has NEITHER git_remote_url NOR git_root_commit into the single same-named row that does have an anchor, repointing every referencing table first. Such a row predates git-context-as-identity and can never be matched by capture again, but it can still HOLD a project_checkouts row that the real project then cannot record (project_checkouts has a global unique index on path while the upsert conflicts on the (project_id, path) PK) -- which is how context-engineering-intro had two rows, one owning the path and the other owning the sessions. Refuses to act when more than one anchored candidate shares the name.';
+
+-- ── 2. Register the checkout an attributed project already demonstrates ─────
+--
+-- NOT attribution inference. `sessions.project_id` is already set here, decided
+-- at capture time by a git remote or root commit; this only records WHICH
+-- DIRECTORY those already-attributed sessions ran in. That distinction is why
+-- this is safe and why the cwd-only fallback removed in Phase 12 is not being
+-- reintroduced: nothing here decides which project a session belongs to.
+--
+-- Refuses: home directories and temp paths (never checkouts), worktree paths
+-- (a worktree is not the canonical root -- 00186/00201 exist because electing
+-- one aims the whole loop at a path nobody works in), and any path already
+-- claimed by another project (the global unique index).
+create or replace function public.backfill_project_checkouts_from_sessions()
+returns integer
+language plpgsql
+security definer
+set search_path = public
+as $$
+declare
+  inserted integer;
+begin
+  with candidate as (
+    select
+      s.project_id,
+      s.project_path,
+      count(*) as sessions,
+      row_number() over (
+        partition by s.project_id
+        -- Most-used real path wins; shallower breaks ties, so a repo root is
+        -- preferred over a subdirectory of it.
+        order by count(*) desc, length(s.project_path) asc, s.project_path asc
+      ) as rank
+    from public.sessions s
+    where s.project_id is not null
+      and s.project_path is not null
+      and s.project_path !~ '^/(Users|home)/[^/]+/?$'
+      and s.project_path !~ '^/(private/)?(tmp|var/folders)'
+      and s.project_path not like '%/.claude/worktrees/%'
+      and s.project_path not like '%/.worktrees/%'
+      -- Only projects that have NO checkout at all. Never second-guess a
+      -- project whose checkouts are already known.
+      and not exists (
+        select 1 from public.project_checkouts c where c.project_id = s.project_id
+      )
+      -- Global unique on path: skip anything another project already owns.
+      and not exists (
+        select 1 from public.project_checkouts c2 where c2.path = s.project_path
+      )
+    group by s.project_id, s.project_path
+  ), ins as (
+    insert into public.project_checkouts (project_id, path, is_worktree)
+    select c.project_id, c.project_path, false
+    from candidate c
+    where c.rank = 1
+    on conflict do nothing
+    returning 1
+  )
+  select count(*)::int into inserted from ins;
+
+  return inserted;
+end;
+$$;
+
+comment on function public.backfill_project_checkouts_from_sessions() is
+  'Registers one canonical checkout for each ALREADY-ATTRIBUTED project that has none, using the most-used real directory its own sessions ran in. Not attribution inference: sessions.project_id is already set from a git anchor, and this only records which directory those sessions used. Skips home dirs, temp paths, worktree paths, and any path another project already claims. Exists because the POST /sessions path normalizer used to collapse session paths onto the home directory, which upsertProjectCheckout then rightly refused to record -- leaving projects correctly attributed and still invisible to regenerate_insights_jobs(), which INNER JOINs project_canonical_checkouts.';
+
+-- Run both once, now. Order matters: merging frees a path that the keeper can
+-- then be given, and the backfill skips projects that already have a checkout.
+select public.merge_anchorless_duplicate_projects();
+select public.backfill_project_checkouts_from_sessions();

package/dist/supabase/migrations/00208_auto_accept_candidate_view.sql

@@ -0,0 +1,131 @@
+-- 00208 — ONE candidate set for auto-accept, defined once, read everywhere.
+--
+-- THE PATTERN THIS ENDS. Nine separate gates have now been found between "a
+-- proposal exists" and "the actuator adopts it", and every one of them was
+-- found the same way: adoption looked stopped, somebody hand-wrote a query,
+-- found ONE gate, opened it, and declared the chain clear. #372's own commit
+-- message said "two gates had to open, not one" — there were four. Then five
+-- and six (00198/00199), seven and eight (00203/00204), and the 2026-08-27
+-- census. The mechanism is always the same: the eligibility predicate is
+-- HAND-COPIED (TS endpoint, TS operator count, SQL producer), the copies
+-- drift, and the stage that disagrees reports a number that reads identically
+-- to "there was nothing to do".
+--
+-- This view is the producer's candidate predicate extracted to a single named
+-- object. From now on:
+--
+--   * `enqueue_auto_accept_suggestions()` (below) SELECTS from it — no inline
+--     copy of the predicate survives in the producer.
+--   * `suggestion_pipeline_conformance()` (00209) counts it, so the monitor
+--     and the producer can never disagree about what "candidates exist" means.
+--   * Diagnostic queries (scripts/dev/suggestion-gate-census.sql) can read it
+--     instead of restating the ladder.
+--
+-- WHAT IT DELIBERATELY IS NOT. It is not the endpoint's predicate. The
+-- authority for "may this be written into a file" stays server-side in
+-- `GET /instruction-suggestions/auto-acceptable` (loop.ts), which additionally
+-- applies the SETTABLE score gate (`resolveAutoAcceptLimits`), per-run and
+-- window budgets, placeholder detection, the 30-day actuator-refusal window
+-- and the running-experiment guard. This view is the producer's CHEAP SUBSET —
+-- its job is to avoid queueing work that would refuse, and 0.8 here is the
+-- DEFAULT minScore, hardcoded exactly as 00205 had it. That asymmetry is
+-- recorded, intended, and now monitored: 00209's `endpoint_refuses_everything`
+-- check fires when jobs run against this candidate set and neither adopt nor
+-- log a refusal, which is the observable signature of the two predicates
+-- having drifted apart (the exact #372 failure, as an alarm instead of an
+-- archaeology session).
+--
+-- Grain: one row per candidate SUGGESTION. The producer groups to
+-- (user_id, project_path); the monitor counts rows and users. The in-flight
+-- agent_jobs dedupe stays in the producer — that is queue state, not
+-- eligibility, and a suggestion does not stop being a candidate because a job
+-- is already on its way.
+
+create or replace view public.auto_accept_candidate_suggestions as
+select s.id          as suggestion_id,
+       s.user_id,
+       s.project_path,
+       s.project_id,
+       s.instruction_id,
+       s.score,
+       i.type        as instruction_type,
+       s.generated_at
+from instruction_suggestions s
+join profiles p on p.id = s.user_id
+join instructions i on i.id = s.instruction_id
+left join projects proj on proj.id = s.project_id
+where s.kind = 'add'
+  -- Default-minScore or insights-authored (owner directive 2026-08-09; the
+  -- 0.5-vs-0.8 self-inflicted deadlock is documented in loop.ts:86-98).
+  and (s.score >= 0.8 or i.frontmatter->>'source' = 'insights')
+  -- The single auto-adoptable set. TS mirror: `isAutoAdoptable()` in
+  -- apps/api/src/lib/insights/artifacts/types.ts — the agreement between the
+  -- two is asserted by apps/api/test/auto-accept-drift.test.ts.
+  and i.type in ('instruction', 'skill')
+  and i.archived = false
+  and s.accepted_at is null
+  and s.dismissed_at is null
+  -- Nobody answering is not a refusal (00203); measurement declines still are.
+  and (s.declined_at is null or s.declined_reason = 'surface_budget')
+  and s.is_stale = false
+  -- Consent, project override first (00170 lineage).
+  and coalesce(
+        proj.metadata->>'autoAcceptSuggestions',
+        p.auto_accept_suggestions::text
+      ) = 'true'
+  -- WHERE an unattended writer may write: the canonical checkout, nowhere
+  -- else (00205). Read from the view, never re-derived (00186 invariant).
+  and exists (
+    select 1 from public.project_canonical_checkouts c
+     where c.path = s.project_path
+  )
+  -- The worker said this directory is not there (00202, 24h-expiring).
+  and not public.project_path_recently_missing(s.user_id, s.project_path);
+
+grant select on public.auto_accept_candidate_suggestions to authenticated, service_role;
+
+comment on view public.auto_accept_candidate_suggestions is
+  'The auto-accept producer''s candidate predicate, extracted so the producer (00208), the conformance monitor (00209) and diagnostics read ONE definition. Cheap subset only — the endpoint (loop.ts /auto-acceptable) remains the authority and adds settable limits, budgets, placeholder and experiment gates.';
+
+-- The producer, rewritten to read the view. Behaviour-identical to 00205 by
+-- construction: the predicate moved, the queue-state dedupe stayed. The nine
+-- tests in apps/api/test/auto-accept-producer.test.ts are the proof.
+create or replace function public.enqueue_auto_accept_suggestions()
+returns integer
+language plpgsql
+security definer
+set search_path = public
+as $$
+declare
+  queued integer;
+begin
+  with eligible as (
+    select v.user_id, v.project_path
+    from public.auto_accept_candidate_suggestions v
+    where not exists (
+      select 1 from agent_jobs j
+      where j.task_kind = 'cron_auto_accept_suggestions'
+        and j.status in ('pending', 'claimed', 'running')
+        and j.payload->>'projectPath' = v.project_path
+        and j.user_id = v.user_id
+    )
+    group by v.user_id, v.project_path
+  ),
+  ins as (
+    insert into agent_jobs (user_id, task_kind, status, payload, dedupe_key)
+    select e.user_id,
+           'cron_auto_accept_suggestions',
+           'pending',
+           jsonb_build_object('projectPath', e.project_path),
+           'auto-accept:' || e.user_id::text || ':' || e.project_path
+    from eligible e
+    returning 1
+  )
+  select count(*)::int into queued from ins;
+
+  return queued;
+end;
+$$;
+
+comment on function public.enqueue_auto_accept_suggestions() is
+  'Hourly producer for cron_auto_accept_suggestions. Candidate predicate lives in the auto_accept_candidate_suggestions view (00208) — one definition shared with the conformance monitor. History: 00197 (type gate), 00202 (missing paths), 00203 (silence declines), 00205 (canonical checkouts only).';