@rulemetric/local 0.10.0 → 0.12.0

package/dist/supabase/migrations/00197_auto_accept_producer_admits_skills.sql

@@ -0,0 +1,115 @@
+-- 00197 — the auto-accept producer admits skills, and the loop can promote again.
+--
+-- #372 ("Skills become adoptable") opened two gates and said two was all there
+-- were: `isAutoAdoptable()` and the operator-facing eligibility count in
+-- `promotion-paths.ts`. There were FOUR. The two it did not touch are the two
+-- that actually decide anything:
+--
+--   3. GET /api/instruction-suggestions/auto-acceptable — the endpoint the
+--      worker asks for candidates. Opened in the same change as this file.
+--   4. THIS producer, which decides whether a job is created at all.
+--
+-- Measured 2026-08-19, on the owner's own account:
+--
+--   * Last applied instruction promotion: 2026-08-01. Last auto-accept
+--     adoption: 2026-08-15. Nothing since.
+--   * Every `add` proposal generated from 08-16 onward was type `skill` or
+--     `feature`. Not one `instruction`. On 08-19 alone: 20 skills, 13 of them
+--     at or above the 0.8 score gate, top score 0.95.
+--   * So this function's `eligible` CTE matched zero rows on 08-17, 08-18 and
+--     08-19. The cron fired and succeeded all three mornings and enqueued
+--     NOTHING — no job, no log line, no refusal anyone could read. The loop
+--     did not report that it was blocked, because from its own point of view
+--     there was nothing to do.
+--
+-- The gate's original comment said "a skill pasted into CLAUDE.md is a category
+-- error". It was right, and it no longer describes the actuator: `acceptSkill`
+-- writes a file under `.claude/skills/` and `.agents/skills/` and never touches
+-- CLAUDE.md. The rule this enforced outlived the behaviour it was protecting
+-- against by exactly as long as it took someone to check.
+--
+-- ── Why no skill budget check here ──────────────────────────────────────────
+--
+-- 00184's comment warns that "queueing a job that can only refuse is how the
+-- loop reported nothing eligible for three days", so it is fair to ask why the
+-- skill window budget is not also checked here. Because the two failure modes
+-- are not the same kind:
+--
+--   * A TYPE ban can never pass. A project whose only proposals are skills is
+--     permanently unreachable, and that is what this migration fixes.
+--   * A BUDGET is transient and self-resetting. A run that refuses on budget
+--     still writes its refusals to the job log with the numbers in them, which
+--     is a stage saying why it did nothing — the thing that was missing above.
+--
+-- Same cheap-gates-only contract as 00170 and 00184: this decides whether to
+-- ASK. The authoritative check, including both window budgets, stays in
+-- GET /api/instruction-suggestions/auto-acceptable.
+
+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'
+      -- Score OR provenance. Insights nominations are filed at 0.5 by
+      -- POST /api/insights/recommendations/nominate and exempted from the
+      -- score gate by the authoritative endpoint; requiring 0.8 here made
+      -- that exemption unreachable in any project without a high-scoring
+      -- catalog proposal. The per-window budget still bounds what a run may
+      -- take, so a permissive trigger cannot become a permissive adoption.
+      and (s.score >= 0.8 or i.frontmatter->>'source' = 'insights')
+      -- The two auto-adoptable types, mirroring `isAutoAdoptable()` and the
+      -- endpoint. Executable artifacts (hook, mcp, subagent) and advisory ones
+      -- (feature) are deliberately absent: installing those runs code or edits
+      -- tool configuration, which always requires a human, and the actuator
+      -- refuses them anyway. Widening this must never widen that.
+      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
+      -- Consent: per-project override wins, else the user default (true).
+      and coalesce(
+            proj.metadata->>'autoAcceptSuggestions',
+            p.auto_accept_suggestions::text
+          ) = 'true'
+      -- One in flight per (user, project), per the 00083/00086 pattern.
+      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
+  'Nightly 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, and whose instruction is a non-archived instruction body OR skill (00197 — skills joined the auto-adoptable set in #372; this producer and the auto-acceptable endpoint were the two gates that change missed, and the loop adopted nothing from 2026-08-16 to 2026-08-19 as a result). Cheap gates only — the authoritative eligibility check is GET /api/instruction-suggestions/auto-acceptable, which applies BOTH window budgets: maxPerWindow for rules (CLAUDE.md bloat) and maxSkillsPerWindow for skills (directory sprawl). Budget overrides: profiles.auto_accept_max_per_window (account) and projects.metadata.autoAcceptLimits (project). Turn it off for one repo: update projects set metadata = coalesce(metadata,''{}''::jsonb) || ''{"autoAcceptSuggestions":false}''::jsonb where id = ...; or globally: update profiles set auto_accept_suggestions = false where id = ...';

package/dist/supabase/migrations/00198_unstale_non_catalog_suggestions.sql

@@ -0,0 +1,51 @@
+-- Clear the is_stale flags the blanket mark-stale sweep should never have set.
+--
+-- `POST /api/instruction-suggestions/mark-stale` fires when the LOCAL skills
+-- registry (`~/.config/rulemetric/skills-registry.json`) is older than 48h, or
+-- simply unreadable — `checkSkillsRegistryStale()` catches to `true`. Until
+-- today it ran as `UPDATE instruction_suggestions SET is_stale = true WHERE
+-- user_id = ?`, with no second predicate: the age of one JSON file on the
+-- operator's laptop invalidated every proposal the system had ever made for
+-- that user, of every type and from every producer.
+--
+-- That would be recoverable if anything cleared the flag. Nothing does. The
+-- only writers of `is_stale = false` are the two nomination upserts, and they
+-- clear it for the ONE instruction being re-proposed. Insights nomination
+-- identifies items by content hash, so a re-worded finding files a NEW row
+-- rather than reviving the flagged one. So the sweep was a one-way drain, and
+-- `is_stale = false` is a hard clause in the auto-accept eligibility gate.
+--
+-- Measured 2026-08-20 on the production database, trailing 30 days:
+--
+--     type          stale / total
+--     instruction    49 / 49     (100%)
+--     skill         198 / 214     (93%)
+--     feature        43 / 55      (78%)
+--     context_file   26 / 35      (74%)
+--
+-- and the 05:00 auto-accept run reported `{"skipped": "nothing-eligible"}` —
+-- the same shape it reports on a genuinely quiet night. Nothing anywhere said
+-- the pool had been emptied by a file-age check.
+--
+-- The route is now scoped to catalog-backed skill proposals (the only thing the
+-- registry is evidence about); this clears the backlog it left behind.
+--
+-- Deliberately NOT cleared:
+--   * catalog skills — the registry really may be stale, and the scoped sweep
+--     will re-flag them on the next run if it is.
+--   * anything with `dismissed_at` set — the other two `is_stale` writers
+--     (`retire-placeholder-nominations`, the instruction-delete path) always
+--     stamp `dismissed_at` alongside it, so that column separates a deliberate
+--     retirement from collateral damage.
+--   * anything already accepted or declined — those rows have an answer, and
+--     `is_stale` is not what is holding them.
+
+UPDATE instruction_suggestions s
+   SET is_stale = false
+  FROM instructions i
+ WHERE i.id = s.instruction_id
+   AND s.is_stale = true
+   AND s.dismissed_at IS NULL
+   AND s.accepted_at IS NULL
+   AND s.declined_at IS NULL
+   AND NOT (i.type = 'skill' AND coalesce(i.frontmatter->>'source', '') <> 'insights');

package/dist/supabase/migrations/00199_auto_accept_runs_every_two_hours.sql

@@ -0,0 +1,54 @@
+-- 00199 — auto-accept stops running once a day and starts running every two hours.
+--
+-- This is a LATENCY fix, not a throughput one — for RULES. Rule adoption stays
+-- bounded by `maxPerWindow` (15 per project per 7 days) in
+-- GET /api/instruction-suggestions/auto-acceptable, so twelve runs a day cannot
+-- adopt more rules than one run a day could over a week; they can only adopt
+-- SOONER.
+--
+-- CORRECTION (2026-08-20, same PR): this comment originally also cited
+-- `maxSkillsPerWindow` (5), which that PR REMOVES — skills now return
+-- `skillsMax: null` and are bounded only by `maxPerRun` (3), counted per type.
+-- So for skills this cadence change IS a throughput change: 3 x 12 = up to 36 a
+-- day where the ceiling was 5 a week. The deliberate argument for uncapping is
+-- that skills load on demand and so do not carry the measured -22.1% cost of an
+-- over-large CLAUDE.md, which is what `maxPerWindow` exists to bound. What holds
+-- the line instead is the duplicate gate in `readInstalledSkills` /
+-- `assessSkillDuplication` — which means that gate must see the WHOLE disk, both
+-- `.agents/skills` and `.claude/skills`. It did not when this migration was
+-- written; that is fixed in the same PR.
+--
+-- Sooner is the entire problem. A proposal is permanently declined once it has
+-- been surfaced in 5 distinct session-hours (`SURFACE_BUDGET`, the
+-- `declined_by_silence` sweep in instruction-suggestions/shared.ts), and
+-- `declined_at` is deliberately never cleared by re-nomination. The owner opens
+-- ~12 substantial sessions a day, so a proposal burns its budget well inside one
+-- working day — while the only pass that could adopt it ran at 05:00 and took at
+-- most 3.
+--
+-- The two clocks were incompatible, and the scoreboard says so: 59 proposals
+-- declined by silence against 34 ever accepted. Measured 2026-08-20, this repo
+-- had FIVE skills at or above the score gate and adopted none — four already
+-- carried `declined_at` from the sweep, stamped before 05:00 ever came round.
+--
+-- Safe to run this often for two independent reasons:
+--   * The producer's `not exists (... status in ('pending','claimed','running'))`
+--     clause admits one job per (user, project) at a time, so runs cannot pile
+--     up. `idx_agent_jobs_dedupe` is a plain lookup index, not a unique one, so
+--     a COMPLETED job correctly does not block the next run.
+--   * A run with nothing to do costs one producer query and enqueues nothing.
+--
+-- Cadence chosen over hourly deliberately: two hours is comfortably inside the
+-- window in which a proposal burns 5 session-hours, and leaves the nightly
+-- ordering (generate 04:30 → adopt) intact rather than interleaving with it
+-- twenty-four times.
+--
+-- SUPERSEDED the same day by 00200, which goes hourly: "comfortably inside the
+-- window" held for the average day and not for a morning burst, which is where
+-- proposals were being lost. Read 00200 for the reasoning that replaced this
+-- paragraph — this file is left as it ran.
+
+select cron.alter_job(
+  (select jobid from cron.job where jobname = 'enqueue_auto_accept_suggestions'),
+  schedule => '0 */2 * * *'
+);

package/dist/supabase/migrations/00200_auto_accept_runs_hourly.sql

@@ -0,0 +1,42 @@
+-- 00200 — auto-accept goes from every two hours to hourly.
+--
+-- This REVERSES the cadence choice 00199 made eight hours earlier, deliberately
+-- and with the owner's decision on 2026-08-20. 00199's reasoning was:
+--
+--   "Cadence chosen over hourly deliberately: two hours is comfortably inside
+--    the window in which a proposal burns 5 session-hours, and leaves the
+--    nightly ordering (generate 04:30 → adopt) intact rather than interleaving
+--    with it twenty-four times."
+--
+-- Two hours is *inside* that window on an average day, which is the weakest
+-- form of the claim: it depends on the owner opening ~12 substantial sessions a
+-- day spread evenly, and they are not spread evenly. A morning burst of five
+-- sessions exhausts `SURFACE_BUDGET` before a two-hourly pass ever looks, and
+-- the proposal is `declined_by_silence` without a human having declined
+-- anything. Hourly halves the worst case rather than the average one, which is
+-- the case that was actually losing proposals.
+--
+-- The interleaving objection stands and is accepted rather than answered: the
+-- 04:30 generate → adopt ordering now has an adoption pass inside it. That is
+-- safe for the same reason 00199 gave for running at all — a pass with nothing
+-- eligible costs one producer query and enqueues nothing — and the producer's
+-- `not exists (... status in ('pending','claimed','running'))` clause still
+-- admits one job per (user, project) at a time, so a slow run cannot pile up
+-- behind a fast schedule.
+--
+-- THROUGHPUT, stated plainly because 00199's original comment got this wrong:
+-- rules stay bounded by `maxPerWindow` (15 per project per 7 days), so hourly
+-- changes only WHEN a rule is adopted, never how many. Skills have no window
+-- cap since `maxSkillsPerWindow` was removed, so for skills this is a real
+-- throughput increase: `maxPerRun` (3) × 24 = up to 72 a day, from 36. What
+-- bounds skills instead is the duplicate gate (`readInstalledSkills` +
+-- `assessSkillDuplication`), which as of the same PR reads BOTH `.agents/skills`
+-- and `.claude/skills` — on the owner's checkout that is 19 installed skills
+-- visible where the gate previously saw 2. A ceiling that depends on a gate is
+-- only as good as the gate's coverage, so if that regresses, this cadence is
+-- the first thing to walk back.
+
+select cron.alter_job(
+  (select jobid from cron.job where jobname = 'enqueue_auto_accept_suggestions'),
+  schedule => '0 * * * *'
+);