@rulemetric/local 0.7.41 → 0.7.43

package/dist/supabase/migrations/00161_instruction_suggestion_kind.sql

@@ -0,0 +1,52 @@
+-- Subtractive suggestions: give instruction_suggestions a direction.
+--
+-- The pipeline has only ever been able to say "add this". The removal engine
+-- already exists (apps/api/src/routes/insights/grooming.ts: never-used +
+-- measured-harmful, behind the capture-health gate and the insurance-rule
+-- allowlist) but it terminates in a web-only endpoint. Meanwhile the additive
+-- feed owns the high-traffic channel — the SessionStart hook injects it into
+-- every session — and sits at 0 accepted out of 335.
+--
+-- `kind` lets both directions share one row shape, one accept/dismiss
+-- lifecycle, and one events funnel, so acceptance rate becomes comparable
+-- across directions. That comparison is the point: it tells us whether 0/335
+-- is a suggestion-quality problem or an add-vs-remove problem.
+--
+--   add    — adopt a catalog/personal instruction not currently used here
+--   remove — retire an own instruction (never-used, or measured-harmful)
+--   trim   — keep it, but it costs tokens and measures neutral (slice 4)
+
+ALTER TABLE instruction_suggestions
+  ADD COLUMN IF NOT EXISTS kind text NOT NULL DEFAULT 'add';
+
+ALTER TABLE instruction_suggestions
+  DROP CONSTRAINT IF EXISTS instruction_suggestions_kind_check;
+
+ALTER TABLE instruction_suggestions
+  ADD CONSTRAINT instruction_suggestions_kind_check
+  CHECK (kind IN ('add', 'remove', 'trim'));
+
+-- The unique index MUST carry `kind`, and this is not cosmetic. The upsert
+-- conflict target is (user_id, project_path, instruction_id). Without `kind`,
+-- a later remove-suggestion for an instruction the user had already ACCEPTED
+-- as an add would collide with that accepted row and overwrite its score and
+-- reason in place — silently converting an accepted adoption into a retirement
+-- proposal, and corrupting the very acceptance funnel this column exists to
+-- measure. Widening the index makes the two directions independent rows.
+-- Create the wider index BEFORE dropping the narrower one. The reverse order
+-- leaves a window with no uniqueness guarantee at all, and the suggestion worker
+-- upserts on a cron — a concurrent batch landing in that window could insert the
+-- duplicate the index exists to prevent.
+CREATE UNIQUE INDEX IF NOT EXISTS idx_instruction_suggestions_user_project_instruction_kind
+  ON instruction_suggestions (user_id, project_path, instruction_id, kind);
+
+DROP INDEX IF EXISTS idx_instruction_suggestions_user_project_instruction;
+
+-- Pending-by-direction reads (the feed filters on kind, and the funnel groups
+-- by it) would otherwise fall back to the (user_id, project_path) index and
+-- re-filter in the heap.
+CREATE INDEX IF NOT EXISTS idx_instruction_suggestions_user_kind
+  ON instruction_suggestions (user_id, kind);
+
+COMMENT ON COLUMN instruction_suggestions.kind IS
+  'Direction of the proposal: add (adopt), remove (retire), trim (reduce). Default add — every pre-existing row is an adoption proposal.';