@rulemetric/local 0.11.0 → 0.12.1

package/dist/supabase/migrations/00194_refine_cases_producer.sql

@@ -0,0 +1,91 @@
+-- An actuator for the refusal the loop had been printing every night.
+--
+-- `cron_instruction_evolution` has been ending in `{"skipped":"not-adequate"}`
+-- with the reason "3/5 cases do not discriminate with vs without — cull or
+-- replace them before adding runs; more runs of a non-discriminating case
+-- cannot lower the MDE; MDE ±49pp exceeds the ±20pp target effect" on every
+-- night measured (2026-08-16, -17, -18). The remedy shipped in 2026-07 as
+-- `rulemetric evals refine-cases <id> --yes` — a command a human types. So the
+-- nightly loop diagnosed its own blocker correctly, spent a two-arm replay
+-- proving it, and had no way to act.
+--
+-- Slot: 05:30, inside the existing nightly chain and deliberately BEFORE the
+-- 06:10 autorun batch, so replacements generated tonight start collecting depth
+-- tonight rather than waiting a day:
+--
+--     04:30 suggestions -> 04:45 training -> 05:00 auto-accept
+--       -> 05:30 REFINE  -> 06:10 autorun  -> 07:30 evolution
+--
+-- Opt-in per target (metadata.autoRefineCases), matching autoEvolveEnabled:
+-- refinement rewrites what a target MEASURES, and a measurement apparatus that
+-- reshapes itself without consent cannot then be trusted to report on itself.
+-- The handler re-reads consent when it claims the job, so revoking it stops an
+-- already-queued run.
+-- ---------------------------------------------------------------------------
+
+create or replace function public.enqueue_refine_cases()
+returns integer
+language plpgsql
+security definer
+set search_path = public
+as $$
+declare
+  queued integer;
+begin
+  with eligible as (
+    select t.id, t.user_id
+    from eval_targets t
+    where coalesce(t.metadata->>'autoRefineCases', 'false') = 'true'
+      -- Discrimination is a CROSS-COHORT quantity: without runs in both arms
+      -- there is nothing to diagnose, and the handler would spend an API round
+      -- trip to say so. Cheap pre-filter, same answer.
+      and exists (
+        select 1 from eval_runs r
+        where r.eval_target_id = t.id
+          and r.status = 'completed'
+          and r.configuration = 'with_target'
+      )
+      and exists (
+        select 1 from eval_runs r
+        where r.eval_target_id = t.id
+          and r.status = 'completed'
+          and r.configuration = 'without_target'
+      )
+      -- There must be something left to measure with. A target already at the
+      -- floor cannot afford a retirement, and the handler refuses anyway —
+      -- but not enqueuing it keeps the refusal out of the nightly feed.
+      and (
+        select count(*) from evals ev
+        where ev.eval_target_id = t.id and ev.retired_at is null
+      ) >= 1
+      -- One in flight at a time, per the 00083/00086 pattern.
+      and not exists (
+        select 1 from agent_jobs j
+        where j.task_kind = 'cron_refine_cases'
+          and j.status in ('pending', 'claimed', 'running')
+          and j.payload->>'evalTargetId' = t.id::text
+      )
+  ), ins as (
+    insert into agent_jobs (user_id, task_kind, status, payload, dedupe_key)
+    select e.user_id,
+           'cron_refine_cases',
+           'pending',
+           jsonb_build_object('evalTargetId', e.id::text),
+           'refine-cases:' || e.id::text
+    from eligible e
+    returning 1
+  )
+  select count(*)::int into queued from ins;
+
+  return queued;
+end;
+$$;
+
+comment on function public.enqueue_refine_cases() is
+  'Nightly producer for cron_refine_cases (§6e). Enqueues one refinement per OPTED-IN target (metadata.autoRefineCases=true) that has completed runs in BOTH cohorts and at least one live case. Retires cases carrying no treatment signal and regenerates replacements — the actuator for the "N/M cases do not discriminate" refusal the evolution loop printed nightly with no way to act on it. Runs at 05:30, before the 06:10 autorun slot, so tonight''s replacements collect depth tonight. Opt in with: update eval_targets set metadata = coalesce(metadata, ''{}''::jsonb) || ''{"autoRefineCases":true}''::jsonb where id = ...';
+
+select cron.schedule(
+  'enqueue_refine_cases',
+  '30 5 * * *',
+  $$select public.enqueue_refine_cases();$$
+);

package/dist/supabase/migrations/00195_skill_usage_views.sql

@@ -0,0 +1,109 @@
+-- Skills were being USED and the product could not see it.
+--
+-- Measured 2026-08-18: `session_events` holds 158 `Skill` tool invocations over
+-- 30 days, most recent that day, with the skill name sitting in plain sight at
+-- `tool_input->>'skill'`. Meanwhile `session_instructions` held 0 rows for any
+-- skill, `treatment_exposures` had no `skill` type at all, and of 6,086 skill
+-- instructions 0 had ever been accepted and 0 archived. The signal was captured
+-- and dropped on the floor.
+--
+-- That gap is why the loop has never proposed retiring a skill: grooming
+-- reasons over measured effect, and there was no measurement to reason over.
+--
+-- ## Views, not a table
+--
+-- The obvious shape is a `skill_invocations` table written at ingest. It is the
+-- wrong one here: the event side-effects already exist in TWO mirrored copies
+-- (`routes/sessions/ingest/events.ts` and `lib/ingest-batcher.ts`), and a third
+-- dual-write would be a third thing to keep in sync — plus a backfill to get
+-- wrong. A view over the events cannot drift from its source, needs no
+-- backfill, and is correct for all history the moment it exists.
+--
+-- ## Why this is a stronger signal than anything already recorded
+--
+-- Every existing `session_instructions.link_method` — project_match,
+-- context_file, auto_capture, manual — means the instruction was PRESENT in
+-- context. A Skill invocation means it was USED. §12 spends its length on the
+-- gap between exposure and effect; this is the first record on the right side
+-- of that gap, and it is worth keeping distinct from presence rather than
+-- folding into it.
+-- ---------------------------------------------------------------------------
+
+-- Skill events are a rounding error in session_events (158 of ~30k), so a
+-- partial index keeps the scan proportional to what is actually read.
+create index if not exists idx_session_events_skill_tool
+  on public.session_events (session_id, timestamp)
+  where tool_name = 'Skill';
+
+-- Catalog skills are named `<source-repo>--<skill>`; invocations carry either
+-- the bare `<skill>` or `<plugin>:<skill>`. Matching on the leaf therefore
+-- needs the leaf to be indexable — a `like '%--' || name` predicate cannot use
+-- an index at all, and there are 6,086 skill rows to scan without one.
+create index if not exists idx_instructions_skill_leaf
+  on public.instructions ((split_part(name, '--', 2)))
+  where type = 'skill';
+
+-- ---------------------------------------------------------------------------
+-- Raw invocations, parsed.
+-- ---------------------------------------------------------------------------
+create or replace view public.skill_invocations as
+select
+  e.session_id,
+  e.timestamp                                   as invoked_at,
+  e.tool_input->>'skill'                        as raw_name,
+  -- `plugin:skill` is one namespace form Claude Code emits; a bare name is the
+  -- other. Splitting rather than storing the raw string keeps the join below
+  -- honest about which half is the identity.
+  nullif(split_part(e.tool_input->>'skill', ':', 1), e.tool_input->>'skill')
+                                                as plugin,
+  case
+    when position(':' in e.tool_input->>'skill') > 0
+      then split_part(e.tool_input->>'skill', ':', 2)
+    else e.tool_input->>'skill'
+  end                                           as skill_name
+from public.session_events e
+where e.tool_name = 'Skill'
+  and e.tool_input->>'skill' is not null
+  and e.tool_input->>'skill' <> '';
+
+comment on view public.skill_invocations is
+  'Every Skill tool invocation, parsed out of session_events. A view rather than a table: the event side-effects already exist in two mirrored copies and a third dual-write would be a third thing to keep in sync. Names arrive as `<skill>` or `<plugin>:<skill>`.';
+
+-- ---------------------------------------------------------------------------
+-- Invocations resolved to the catalog, WITHOUT discarding the unresolved ones.
+--
+-- Measured 2026-08-18: only 11 of 81 distinct invoked skills exist in the
+-- instructions catalog. The other 70 are the user's own local skills
+-- (`git-ship`, `commit`, `publish`, `auto-deploy`) — the ones actually used
+-- every day, and the ones a catalog-only join would silently drop. An inner
+-- join here would have reported 14% of reality and looked complete.
+--
+-- `instruction_id` is therefore NULLABLE and null means "used but not in the
+-- catalog", which is a finding, not a failure.
+-- ---------------------------------------------------------------------------
+create or replace view public.skill_usage as
+select
+  si.session_id,
+  si.invoked_at,
+  si.raw_name,
+  si.plugin,
+  si.skill_name,
+  s.user_id,
+  s.project_id,
+  s.project_path,
+  m.instruction_id
+from public.skill_invocations si
+join public.sessions s on s.id = si.session_id
+left join lateral (
+  select i.id as instruction_id
+  from public.instructions i
+  where i.type = 'skill'
+    and (i.name = si.skill_name or split_part(i.name, '--', 2) = si.skill_name)
+  -- Exact name beats a leaf match, so a skill whose full name happens to equal
+  -- another's leaf cannot steal the attribution.
+  order by (i.name = si.skill_name) desc, i.id
+  limit 1
+) m on true;
+
+comment on view public.skill_usage is
+  'Skill invocations joined to the session that ran them and, where one exists, the catalog instruction. instruction_id is NULL for skills used but not catalogued — measured 2026-08-18, that was 70 of 81 distinct skills, so an inner join here would report 14% of reality.';

package/dist/supabase/migrations/00196_retire_unused_skills_producer.sql

@@ -0,0 +1,102 @@
+-- The loop's first unattended REMOVAL.
+--
+-- Everything the loop has actuated until now has added: a rule appended to
+-- CLAUDE.md, a skill installed, a hook registered, an instruction promoted.
+-- Grooming's stated contract was that removals are surfaced for human review
+-- and NEVER auto-archived, and this producer deliberately changes that for one
+-- narrow case (owner's decision, 2026-08-18). Recording the change here so the
+-- next reader finds the departure rather than inferring it.
+--
+-- What makes it narrow:
+--
+--   * ONLY skills, and only ones with ZERO recorded invocations since install.
+--     "Invoked but measures unhelpful" is an observational estimate and stays a
+--     proposal, exactly as measured-harmful rules do. An absence of use is a
+--     fact; an absence of benefit is an inference.
+--   * ONLY skills the loop itself installed, evidenced by a
+--     `recommendation_applications` row with status='applied'. The handler
+--     re-checks this; the API is the authority.
+--   * ONLY while skill capture is demonstrably live. A dark Skill channel makes
+--     every skill look unused, and the first quiet fortnight would otherwise
+--     read as "retire everything". Judged by `loadUnusedSkillCandidates`.
+--   * A per-run cap in the handler, and a backup written before every delete
+--     (`applyRetraction`) because an untracked skill file has no other copy and
+--     git cannot restore it.
+--
+-- Slot: 05:45, after auto-accept (05:00) and refine (05:30), before the autorun
+-- batch (06:10). Adding and removing in the same nightly pass, in that order,
+-- means a skill adopted tonight is never a retirement candidate tonight — it
+-- has to survive the unused window first.
+--
+--     04:30 suggestions -> 04:45 training -> 05:00 auto-accept
+--       -> 05:30 refine -> 05:45 RETIRE   -> 06:10 autorun -> 07:30 evolution
+--
+-- Opt-in per project (metadata.autoRetireSkills). Nothing is retired for a user
+-- who has not asked for it, and the handler cannot be reached without a job.
+-- ---------------------------------------------------------------------------
+
+create or replace function public.enqueue_retire_unused_skills()
+returns integer
+language plpgsql
+security definer
+set search_path = public
+as $$
+declare
+  queued integer;
+begin
+  with eligible as (
+    -- The canonical checkout comes from the VIEW, never re-derived: is_worktree
+    -- is rewritten from each session's own metadata on every ingest, so a
+    -- hand-rolled ranking elects a path nobody works in (00186).
+    select pr.created_by as user_id, p.path as canonical_path
+    from public.project_canonical_checkouts p
+    join public.projects pr on pr.id = p.project_id
+    where coalesce(pr.metadata->'autoRetireSkills'->>'enabled', 'false') = 'true'
+      -- Cheap pre-filter: a user with no skill invocations captured at all has
+      -- a dark channel, and the handler would refuse anyway. Not enqueuing it
+      -- keeps a guaranteed refusal out of the nightly feed.
+      and exists (
+        select 1 from public.skill_usage su
+        where su.user_id = pr.created_by
+          and su.invoked_at > now() - interval '14 days'
+      )
+      -- There must be something that could plausibly be retired: at least one
+      -- of the user's own skills old enough to have had a fair chance.
+      and exists (
+        select 1 from public.instructions i
+        where i.created_by = pr.created_by
+          and i.type = 'skill'
+          and i.archived = false
+          and i.created_at < now() - interval '30 days'
+      )
+      -- One in flight at a time, per the 00083/00086 pattern.
+      and not exists (
+        select 1 from public.agent_jobs j
+        where j.task_kind = 'cron_retire_unused_skills'
+          and j.status in ('pending', 'claimed', 'running')
+          and j.payload->>'projectPath' = p.path
+      )
+  ), ins as (
+    insert into agent_jobs (user_id, task_kind, status, payload, dedupe_key)
+    select e.user_id,
+           'cron_retire_unused_skills',
+           'pending',
+           jsonb_build_object('projectPath', e.canonical_path),
+           'retire-unused-skills:' || e.canonical_path
+    from eligible e
+    returning 1
+  )
+  select count(*)::int into queued from ins;
+
+  return queued;
+end;
+$$;
+
+comment on function public.enqueue_retire_unused_skills() is
+  'Nightly producer for cron_retire_unused_skills (05:45). Enqueues one run per OPTED-IN project (projects.metadata.autoRetireSkills.enabled=true) whose user has live skill capture and at least one own skill older than the unused window. The loop''s first unattended REMOVAL: only skills, only never-invoked ones, only ones the loop itself installed, only while skill capture is live, capped per run, and with a backup written before every delete. Used-but-unhelpful skills remain proposals. Opt in with: update projects set metadata = coalesce(metadata, ''{}''::jsonb) || ''{"autoRetireSkills":{"enabled":true}}''::jsonb where id = ...';
+
+select cron.schedule(
+  'enqueue_retire_unused_skills',
+  '45 5 * * *',
+  $$select public.enqueue_retire_unused_skills();$$
+);

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 * * * *'
+);