@rulemetric/local 0.12.0 → 0.12.2

package/dist/supabase/migrations/00201_canonical_checkout_total_order.sql

@@ -0,0 +1,102 @@
+-- 00201 — the canonical checkout stops depending on the query plan.
+--
+-- THE DEFECT (measured against production 2026-08-24).
+--
+-- 00186 replaced five hand-copied `ORDER BY is_worktree ASC, last_seen DESC`
+-- with one view, on the recorded grounds that "the copies disagree in the
+-- silent direction". The view fixed the disagreement between call sites and
+-- introduced a worse one: its ORDER BY is not TOTAL, so when two checkouts of
+-- a project tie on every sort key, `DISTINCT ON` returns whichever row the
+-- executor happens to emit — and that differs by the CALLER's query plan.
+--
+-- Live, same second, same rows, project bbf29181 (local-ai-packaged):
+--
+--   SELECT ... WHERE project_id = $1        -- canonical-checkout.ts:43, :54
+--     -> Sort -> Limit 1
+--     -> /Users/nickyeager/Code/agents/local-ai-packaged            (on disk)
+--
+--   LEFT JOIN ... ON c.project_id = p.project_id   -- routes/loop.ts:244, :256
+--     -> Incremental Sort (Presorted Key: project_id) -> Unique
+--     -> /Users/.../local-ai-packaged/localai-admin-dashboard       (deleted)
+--
+-- Both plans sort on a key set that does not identify a row: the two checkouts
+-- carry the same is_worktree and the same last_seen TO THE MICROSECOND, because
+-- a single backfill statement wrote both. Postgres sorts are not stable and the
+-- two plans use different sort implementations, so each is deterministic on its
+-- own and they disagree with each other.
+--
+-- So `/api/loop/status` renders one path to the operator while the enqueue
+-- sites aim jobs at the other. This is strictly worse than the five copies it
+-- replaced: those were consistently wrong and could be found by diffing them.
+-- This cannot be found by reading the SQL at all.
+--
+-- THE FIX, in two parts.
+--
+-- 1. A TOTAL order. `path` is appended last and `project_checkouts.path` is
+--    globally UNIQUE (00052), so the sort key now identifies exactly one row
+--    and no plan has anything left to decide. This is the load-bearing half:
+--    every rule below it is a preference, this is what makes the view a
+--    function of its inputs.
+--
+-- 2. An ancestor preference, ranked directly under the staleness tier. A
+--    checkout that sits strictly INSIDE another checkout of the SAME project is
+--    a subdirectory somebody opened a session in, not a second checkout of the
+--    repo. Both ties in the entire table are exactly this shape:
+--
+--      /Users/.../local-ai-packaged   +   /Users/.../local-ai-packaged/localai-admin-dashboard
+--      /tmp/budget-1786799685058      +   /tmp/budget-1786799685058/apps/cli
+--
+--    and it is the same shape as the ORIGINAL 00186 defect, whose crown went to
+--    `…/momento-mori/apps/cli`. Preferring the ancestor states the rule that
+--    accident has been standing in for.
+--
+-- Deliberately NOT part of this migration: whether the elected path still
+-- EXISTS. The database cannot see a filesystem, and 6 of the 10 paths this view
+-- currently elects are absent from the operator's machine. That is 00202's job,
+-- and it is a separate defect — fixing this one does not stop a single one of
+-- the no-op jobs, because `enqueue_auto_accept_suggestions` never consulted
+-- this view in the first place.
+--
+-- `left(a, length(b) + 1) = b || '/'` rather than `a LIKE b || '/%'`: an
+-- underscore is a legal character in a path and a wildcard in LIKE, so the
+-- pattern form would rank unrelated siblings as descendants.
+
+create or replace view public.project_canonical_checkouts as
+select distinct on (project_id)
+       project_id,
+       path,
+       is_worktree,
+       last_seen,
+       -- Exposed so callers can SAY the path is stale rather than silently
+       -- acting on it. /api/loop/status renders this; a canonical path that
+       -- has gone quiet while the project has not is how 00186's defect hid.
+       (last_seen < freshest - interval '30 days') as is_stale,
+       freshest as project_last_seen
+  from (
+    select pc.project_id,
+           pc.path,
+           pc.is_worktree,
+           pc.last_seen,
+           max(pc.last_seen) over (partition by pc.project_id) as freshest,
+           exists (
+             select 1
+               from public.project_checkouts anc
+              where anc.project_id = pc.project_id
+                and anc.path <> pc.path
+                and left(pc.path, length(anc.path) + 1) = anc.path || '/'
+           ) as is_inside_another_checkout
+      from public.project_checkouts pc
+     where pc.path is not null
+       and pc.path <> ''
+  ) q
+ order by project_id,
+          (last_seen < freshest - interval '30 days') asc,  -- live before stale
+          is_inside_another_checkout asc,                   -- repo before subdirectory
+          is_worktree asc,                                  -- checkout before worktree
+          last_seen desc,                                   -- then most recent
+          path asc;                                         -- TOTAL: never let the plan decide
+
+comment on view public.project_canonical_checkouts is
+  'The single authority for a project''s canonical checkout path. Ranks live paths above ones more than 30 days staler than the project''s freshest, THEN a repo above its own subdirectories, THEN non-worktree, THEN most-recently-seen, THEN path as a TOTAL tiebreak. The final key is not cosmetic: without it (00186) two checkouts tied on every key and DISTINCT ON returned a different winner per caller query plan, so routes/loop.ts read a deleted subdirectory while canonical-checkout.ts read the live repo, for the same project in the same second. See 00201. Says nothing about whether the path exists on disk — see 00202.';
+
+grant select on public.project_canonical_checkouts to authenticated, service_role;

package/dist/supabase/migrations/00202_producers_skip_paths_observed_missing.sql

@@ -0,0 +1,136 @@
+-- 00202 — a producer stops re-enqueueing work against a path the worker has
+-- already told it is not on disk.
+--
+-- THE DEFECT (measured against production 2026-08-24).
+--
+-- `cron_auto_accept_suggestions` stats its target directory before writing
+-- anything — a deliberate guard, so an unattended writer can never recreate a
+-- CLAUDE.md inside a deleted repo. When the directory is gone it returns
+-- `{"skipped":"project-path-missing"}` and the job is marked COMPLETED.
+--
+-- Nothing consumes that observation. So the producer enqueues the same job
+-- again an hour later (00200), the worker stats the same absent directory, and
+-- the job completes clean. Every health view that counts failures sees a
+-- healthy queue while the work never happens — the shape CLAUDE.md already
+-- records for the producers: "a producer matching zero rows looks exactly like
+-- a quiet night."
+--
+-- Live: `/Users/nickyeager/Code/agents/local-ai-packaged/localai-admin-dashboard`
+-- is absent from disk and burned 17 no-op jobs in 24h. There are exactly TWO
+-- paths in the whole system that this producer can enqueue, so half of all
+-- auto-accept jobs were no-ops. The path is carried by ONE open suggestion row
+-- (994feff0, insights-authored, score 0.5, generated 2026-08-08) which can
+-- never be accepted, declined or staled, so this would have run forever.
+--
+-- WHY THIS IS NOT FIXED UPSTREAM. It is tempting to call this a canonical-path
+-- defect, and 00201 does fix the election that first aimed at a subdirectory.
+-- But this producer never consulted `project_canonical_checkouts` at all — it
+-- groups by `instruction_suggestions.project_path` verbatim. Repairing the
+-- election stops zero of these jobs. The two defects share a symptom and
+-- nothing else.
+--
+-- THE RULE: RATE-LIMIT, NEVER BLOCK.
+--
+-- The obvious fix — suppress the path once a missing observation exists — is
+-- the bug this repo keeps shipping. `is_stale` has no inverse. `declined_at` is
+-- permanent for the machine. Both are one-way flags whose owners intended
+-- "not now" and delivered "not ever". A hard skip here is worse than either,
+-- because it is self-sealing: if no job is ever enqueued, no worker ever stats
+-- the directory, so nothing can ever observe that it came back. The flag would
+-- have no inverse BY CONSTRUCTION.
+--
+-- So the observation suppresses for 24 hours and then lets exactly one job
+-- through. Cost: one no-op job a day instead of twenty-four. Recovery: the
+-- directory reappears, the next probe does real work, emits no missing result,
+-- and the path is never suppressed again. No flag, no backfill, no inverse to
+-- forget — the suppression expires on its own because it is a statement about
+-- an observation's age, not a bit somebody has to remember to clear.
+
+create or replace function public.project_path_recently_missing(
+  p_user_id uuid,
+  p_path text,
+  p_window interval default interval '24 hours'
+)
+returns boolean
+language sql
+stable
+security definer
+set search_path = public
+as $$
+  select exists (
+    select 1
+      from agent_jobs j
+     where j.user_id = p_user_id
+       and j.status = 'completed'
+       and j.result->>'skipped' = 'project-path-missing'
+       and j.payload->>'projectPath' = p_path
+       and j.completed_at > now() - p_window
+  );
+$$;
+
+comment on function public.project_path_recently_missing(uuid, text, interval) is
+  'Has a worker reported, within p_window, that this path is not on its disk? The database cannot see a filesystem; the worker is the only thing that can, and it already records the answer in agent_jobs.result. Deliberately a WINDOW and not a flag: a hard skip would stop the probes that are the only way to learn the directory came back, making it a one-way flag by construction — the defect shape of is_stale and declined_at. See 00202.';
+
+-- ── The auto-accept producer ────────────────────────────────────────────────
+-- Body unchanged from 00197 except for the `project_path_recently_missing`
+-- clause. Every comment there still applies and is not restated.
+
+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 s.user_id, s.project_path
+    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'
+      and (s.score >= 0.8 or i.frontmatter->>'source' = 'insights')
+      and i.type in ('instruction', 'skill')
+      and i.archived = false
+      and s.accepted_at is null
+      and s.dismissed_at is null
+      and s.declined_at is null
+      and s.is_stale = false
+      and coalesce(
+            proj.metadata->>'autoAcceptSuggestions',
+            p.auto_accept_suggestions::text
+          ) = 'true'
+      -- The worker said this directory is not there. Ask again tomorrow, not
+      -- in an hour. See the function's comment for why this expires rather
+      -- than latching.
+      and not public.project_path_recently_missing(s.user_id, s.project_path)
+      and 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' = s.project_path
+          and j.user_id = s.user_id
+      )
+    group by s.user_id, s.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. One row per (user, project) holding at least one consented ADD proposal that is either high-confidence (>= 0.8) or insights-authored, whose instruction is a non-archived instruction body OR skill (00197), and whose path a worker has not reported missing from disk in the last 24h (00202 — one dead path burned 17 no-op COMPLETED jobs in 24h, half of every auto-accept job in the system, with nothing reporting a problem). Cheap gates only — the authoritative eligibility check is GET /api/instruction-suggestions/auto-acceptable.';

package/dist/supabase/migrations/00203_auto_accept_admits_silence_declines.sql

@@ -0,0 +1,120 @@
+-- 00203 — a proposal nobody answered stops blocking the lane that is not asking.
+--
+-- THE DEFECT (measured against production 2026-08-24).
+--
+-- `declined_at` answers two different questions with one column, and every
+-- reader treated them the same:
+--
+--   `surface_budget`  — nobody answered. `sweepDeclinedBySilence` stamps it
+--      after a proposal has been shown to 5 distinct sessions with no reply.
+--      A statement about the HUMAN channel: stop asking this person.
+--
+--   `trial_neutral`   — it WAS answered, by measurement. `settleExperiment`
+--      stamps it when a randomised trial found no effect. A verdict on the
+--      proposal itself.
+--
+-- The feed already knows the first kind is temporary and re-opens it after 90
+-- days (`notDeclinedBySilence`). The machine lane did not: this producer and
+-- GET /api/instruction-suggestions/auto-acceptable both required `declined_at
+-- IS NULL` strictly, and re-nomination deliberately never clears the column
+-- (00199), so a row that ran out of surface budget was machine-blocked FOREVER
+-- while looking freshly generated.
+--
+-- What that cost, counted: 33 open `add` proposals of an auto-adoptable type at
+-- score >= 0.8, average 0.87, top 0.95 (`antigravity--platform-mirrors`, on
+-- this repo). 27 of them were silence-declined BEFORE 2026-08-20 — that is,
+-- while the skill type-gate (00197) was still shut and the machine could not
+-- have adopted them however loudly it was asked. They spent their surface
+-- budget in an era with no actuator behind them and were locked out for it.
+--
+-- Every `declined_reason` in the entire table today is `surface_budget` (86 of
+-- 86), so on current data this is equivalent to a full amnesty. It is written
+-- as a predicate anyway, because the equivalence is an accident of history and
+-- the rule has to hold when `trial_neutral` rows exist.
+--
+-- WHY A PREDICATE AND NOT AN AMNESTY. `sweepDeclinedBySilence` recomputes
+-- surface units from the WHOLE event log on every feed read — explicitly never
+-- from a checkpoint, so the guard applies to historic proposals for free. Every
+-- one of these rows is therefore permanently over budget. `SET declined_at =
+-- NULL` would be undone by the next SessionStart, quite possibly before the
+-- hourly adoption pass ever saw the row. A predicate mutates nothing and has no
+-- such race.
+--
+-- WHAT STILL BLOCKS. `trial_neutral` (declined by measurement). `dismissed_at`
+-- (a human said no, including via undo) — a separate column, checked
+-- separately, and never touched here. And downstream, the actuator's own
+-- refusals: redundant, partial_overlap, unresolvable_reference, the 30-day
+-- re-offer block, `maxPerWindow` and `maxPerRun`. Opening this gate cannot
+-- flood a CLAUDE.md; it decides what may be ASKED about, not what is written.
+--
+-- The TRIAL lane is deliberately NOT changed (`/instruction-suggestions/
+-- trialable` keeps `declined_at IS NULL`). A trial spends real session capacity
+-- and a scarce slot, so "nobody engaged with this" is a fair reason to leave it
+-- alone there. Auto-accept spends a file write nobody has to read.
+--
+-- Three readers must agree or the operator is shown a different set than the
+-- loop adopts from. The other two are `notDeclinedForActuator` in
+-- routes/instruction-suggestions/shared.ts (used by the auto-acceptable
+-- endpoint) and the auto-accept eligibility count in lib/instructions/
+-- promotion-paths.ts. Both ship in the same change as this migration.
+
+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 s.user_id, s.project_path
+    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'
+      and (s.score >= 0.8 or i.frontmatter->>'source' = 'insights')
+      and i.type in ('instruction', 'skill')
+      and i.archived = false
+      and s.accepted_at is null
+      -- A human's refusal. Never relaxed.
+      and s.dismissed_at is null
+      -- Nobody answering is not a refusal, and this lane is not asking.
+      -- `trial_neutral` — declined by measurement — still blocks. See above.
+      and (s.declined_at is null or s.declined_reason = 'surface_budget')
+      and s.is_stale = false
+      and coalesce(
+            proj.metadata->>'autoAcceptSuggestions',
+            p.auto_accept_suggestions::text
+          ) = 'true'
+      -- The worker said this directory is not there (00202).
+      and not public.project_path_recently_missing(s.user_id, s.project_path)
+      and 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' = s.project_path
+          and j.user_id = s.user_id
+      )
+    group by s.user_id, s.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. One row per (user, project) holding at least one consented ADD proposal that is high-confidence (>= 0.8) or insights-authored, of an auto-adoptable type (00197), not declined BY MEASUREMENT (00203 — a surface_budget decline means nobody answered the human channel, which this lane is not using; 33 adoption-grade proposals, 27 of them declined while the skill gate was still shut, were machine-blocked forever by conflating the two), and whose path a worker has not reported missing from disk in 24h (00202). Cheap gates only — the authoritative check is GET /api/instruction-suggestions/auto-acceptable.';

package/dist/supabase/migrations/00204_unstale_catalog_skills_on_request.sql

@@ -0,0 +1,115 @@
+-- 00204 — the catalog-skill staleness backlog is released ON REQUEST, one
+-- project at a time. Applying this migration moves ZERO rows.
+--
+-- 00198 cleared the collateral damage from the blanket mark-stale sweep and
+-- explicitly declined to clear catalog skills, reasoning:
+--
+--     "catalog skills — the registry really may be stale, and the scoped sweep
+--      will re-flag them on the next run if it is."
+--
+-- Sound, and wrong by one word: *re*-flag implies the flag can come off, and
+-- nothing could take it off. The only writers of `is_stale = false` were the two
+-- nomination upserts, which clear it for the ONE instruction being re-proposed.
+-- So "the sweep will sort it out" described a sweep that could only ever add.
+--
+-- Measured 2026-08-24, open `add` proposals of type skill at score >= 0.8:
+-- 51 flagged across 12 projects, against exactly ONE that was not. The flag was
+-- not skewing that population, it WAS the population — and the operator's
+-- registry file had been regenerated 17 hours earlier, so every one of those
+-- rows was held out of the adoptable pool by an observation that had stopped
+-- being true. `is_stale = false` is a hard clause in the auto-accept gate.
+--
+-- ── WHY A FUNCTION AND NOT AN UPDATE ────────────────────────────────────────
+--
+-- The inverse shipped alongside this (POST /api/instruction-suggestions/
+-- mark-stale takes `{stale:boolean}`) is the real fix, and it is also a release
+-- valve with no throttle: it clears the WHOLE catalog-skill scope for a user in
+-- one statement. Counted against production, the auto-accept eligible pool moves
+--
+--     today                          3 rules,  0 skills
+--     with the decline predicate     3 rules,  8 skills   (00203)
+--     with staleness cleared         3 rules, 85 skills
+--
+-- and skills have had no window budget since `maxSkillsPerWindow` was removed on
+-- 2026-08-20 — `windowRemaining` is literally Infinity for a skill at
+-- routes/instruction-suggestions/loop.ts, so the only ceiling left is
+-- `maxPerRun` (3) at an hourly cadence: up to 72 adoptions a day. 00200 accepted
+-- that uncap explicitly and said the duplicate gate was the thing holding the
+-- line, and that if it regressed the cadence was "the first thing to walk back".
+-- An 85-row backlog arriving in a day and a half is exactly the case it meant.
+--
+-- Two further reasons a burst is worse than a trickle, neither of which is about
+-- CLAUDE.md bloat:
+--
+--   * The undo path is per-instruction. Reviewable at 3/day; not at 72/day.
+--   * `skill_usage` (00195) and `retire_unused_skills` (00196) can only tell you
+--     which adoptions earned their place if tranches land far enough apart for
+--     usage to accrue between them. Draining in one burst converts "measured
+--     adoption" back into "bulk install", which is the thing this pipeline
+--     exists to be better than.
+--
+-- So the backlog is released deliberately, per project, by an operator who is
+-- watching:
+--
+--     select public.unstale_catalog_skill_suggestions(
+--              '<user-id>'::uuid, '/Users/me/Code/some-project');
+--
+--     -- or, for every project that user has, in one go:
+--     select public.unstale_catalog_skill_suggestions('<user-id>'::uuid);
+--
+-- ⚠️ The function is NOT the only thing that can release these rows, and that is
+-- worth knowing before relying on it as a brake. A worker running a CLI new
+-- enough to report `{stale:false}` clears the same scope on its next run against
+-- a fresh registry. Until that CLI is published, the pool stays at 11 rows; once
+-- it is, the backlog releases whether or not this function is ever called.
+-- Pacing therefore means pacing the CLI publish too — this function exists so
+-- the release can happen EARLIER and NARROWER than that, not so it can be
+-- prevented.
+--
+-- NOT CLEARED, following 00198:
+--   * anything with `dismissed_at` set — the other `is_stale` writers stamp that
+--     column alongside, so it separates a deliberate retirement from collateral
+--     damage.
+--   * anything accepted, or declined by MEASUREMENT (`trial_neutral`). A
+--     `surface_budget` decline is not an answer and IS cleared, matching the
+--     actuator predicate in 00203 — leaving it out would half-open two gates and
+--     adopt nothing, the exact shape #372 shipped when it opened two of four.
+
+create or replace function public.unstale_catalog_skill_suggestions(
+  p_user_id uuid,
+  p_project_path text default null
+)
+returns integer
+language plpgsql
+security definer
+set search_path = public
+as $$
+declare
+  cleared integer;
+begin
+  with released as (
+    update instruction_suggestions s
+       set is_stale = false
+      from instructions i
+     where i.id = s.instruction_id
+       and s.user_id = p_user_id
+       and (p_project_path is null or s.project_path = p_project_path)
+       and s.is_stale = true
+       and i.type = 'skill'
+       and coalesce(i.frontmatter->>'source', '') <> 'insights'
+       and i.archived = false
+       and s.accepted_at is null
+       and s.dismissed_at is null
+       and (s.declined_at is null or s.declined_reason = 'surface_budget')
+    returning 1
+  )
+  select count(*)::int into cleared from released;
+
+  return cleared;
+end;
+$$;
+
+comment on function public.unstale_catalog_skill_suggestions(uuid, text) is
+  'Release the catalog-skill staleness backlog for one user, optionally scoped to one project. Returns how many rows were cleared. Applying 00204 moves zero rows BY DESIGN: 00198 left 51 of these flagged on the reasoning that the sweep would re-flag them, which assumed an inverse that did not exist until 2026-08-24, and clearing them all at once takes the auto-accept eligible pool from 11 to 88 with no window budget on skills to absorb it (maxSkillsPerWindow was removed 2026-08-20; maxPerRun 3 at hourly cadence is up to 72 adoptions/day). Release per project, watching. See 00204.';
+
+grant execute on function public.unstale_catalog_skill_suggestions(uuid, text) to service_role;

package/dist/supabase/migrations/00205_auto_accept_writes_only_to_canonical_checkouts.sql

@@ -0,0 +1,110 @@
+-- 00205 — an unattended file writer may only write to a project's canonical
+-- checkout.
+--
+-- THE DEFECT, found 2026-08-24 by releasing the staleness backlog and LOOKING at
+-- what became eligible rather than assuming.
+--
+-- `enqueue_auto_accept_suggestions` groups by `instruction_suggestions.project_path`
+-- verbatim. It has never asked whether that path is a checkout, let alone THE
+-- checkout. While the catalog-skill backlog was stale that was invisible: the
+-- pool held two paths. The moment the backlog was released, the producer's match
+-- set was 13 paths, of which exactly TWO are canonical checkouts:
+--
+--     /Users/nickyeager                                    14 skills   HOME DIRECTORY
+--     /private/var/folders/dn/.../T                         3 skills   temp directory
+--     /Users/nickyeager/Code/agents/momento-mori/apps/cli   7 skills   the dead path from 00186
+--     …/tinyworlds/.worktrees/image-blast-m4, -m6, -m7     13 skills   worktrees
+--     /Users/kylechalmers/Development                       2 skills   a parent of two workspaces
+--
+-- `/Users/nickyeager` is the one that matters most: `acceptSkill` writes under
+-- `<projectPath>/.claude/skills/`, so the home directory means `~/.claude/skills/`
+-- — the GLOBAL skills directory, loaded into every session of every project. An
+-- unattended loop would have installed 14 skills globally and reported success.
+--
+-- 00202 cannot catch any of these. Its question is "is this path on disk", and
+-- all of them are. This is the same defect as 00202's — a producer aiming at a
+-- path nobody validated — wearing a different hat.
+--
+-- THE RULE, and it is not new. `public.project_canonical_checkouts` (00186) is
+-- the single authority for which path IS a project, and CLAUDE.md's invariant is
+-- that it must never be re-derived. `enqueue_instruction_training` has been
+-- gated on it since 00188, whose comment records the identical failure: "the
+-- project-level activity join in 00174 let every subpath of an active repo
+-- through, and apps/cli collected 6 undead trials that way". Auto-accept — which
+-- writes FILES rather than nominating trials — was never given the same gate.
+-- It is the site that needed it most.
+--
+-- CONSEQUENCE, stated rather than buried: this blocks the external user
+-- entirely, because none of his three paths is a canonical checkout. That is the
+-- correct default for an unattended writer (better to write nowhere than into a
+-- directory holding two unrelated workspaces), but it means his skill lane moves
+-- from "dead via is_stale" to "dead via this gate", and the real fix is that his
+-- checkouts are not registered in `project_checkouts`. Tracked separately; do not
+-- widen this gate to paper over it.
+
+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 s.user_id, s.project_path
+    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'
+      and (s.score >= 0.8 or i.frontmatter->>'source' = 'insights')
+      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).
+      and (s.declined_at is null or s.declined_reason = 'surface_budget')
+      and s.is_stale = false
+      and coalesce(
+            proj.metadata->>'autoAcceptSuggestions',
+            p.auto_accept_suggestions::text
+          ) = 'true'
+      -- WHERE an unattended writer may write: the project's canonical checkout,
+      -- and nowhere else. Not a home directory, not a temp directory, not a
+      -- worktree, not a subdirectory somebody once opened a session in. Read
+      -- from the view, never re-derived (00186, and CLAUDE.md's 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).
+      and not public.project_path_recently_missing(s.user_id, s.project_path)
+      and 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' = s.project_path
+          and j.user_id = s.user_id
+      )
+    group by s.user_id, s.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. Requires a consented ADD proposal that is high-confidence or insights-authored, of an auto-adoptable type (00197), not declined by MEASUREMENT (00203), on a path that IS the project canonical checkout (00205 — releasing the staleness backlog revealed the match set was 13 paths of which 2 were checkouts; the others were a HOME directory, a temp directory, three worktrees and the dead apps/cli path, and acceptSkill would have written 14 skills into ~/.claude/skills/ globally), and that a worker has not reported missing from disk in 24h (00202).';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rulemetric/local",
-  "version": "0.12.0",
+  "version": "0.12.2",
   "description": "RuleMetric local-mode runtime: bundled API server, web dashboard, and database migrations for fully local (zero cloud contact) deployments. Installed on demand by `rulemetric local up` — not meant to be used directly.",
   "type": "module",
   "exports": {
@@ -28,7 +28,7 @@
     "postgres": "^3.4.0",
     "resend": "^4.0.0",
     "zod": "^3.24.0",
-    "@rulemetric/skills-registry": "0.12.0"
+    "@rulemetric/skills-registry": "0.12.2"
   },
   "devDependencies": {
     "esbuild": "^0.25.0",