merge: dev4 → master — indici UNIQUE totali per companies/highlights (mig 050) + backlog swipe-triage posizioni

Author: leopu00

BACKLOG.md

@@ -184,6 +184,17 @@ Versione: `package.json` `v0.1.17` (production ferma a `v0.1.12` dopo blocco Tur
 
 ---
 
+### 🃏 [JHT-POSITIONS-SWIPE-TRIAGE] Triage rapido posizioni — swipe destra/sinistra (NEW 2026-06-29)
+
+⬜ **Sezione/modalità "swipe" (stile Tinder) per fare un triage veloce delle posizioni e scartare subito quelle sicuramente da evitare.** Idea utente 2026-06-29 mentre lavoriamo al redesign delle pagine posizione (vedi memoria `[[project_position_page_content_redesign]]`). Da fare DOPO il perfezionamento delle pagine posizione.
+
+- **UX**: una card per posizione (titolo, azienda, score, sintesi JD breve); **swipe sinistra = scarta** (sicuramente da evitare), **swipe destra = tieni/interessa**; supporto anche frecce tastiera/bottoni per desktop. Pensata per smaltire in fretta il backlog di posizioni "ready"/"scored" senza aprirle una a una.
+- **Backend già pronto**: l'azione di esclusione utente esiste — la route `user-exclude` scrive `last_actor='user'` + `user_excluded_at` + transizione, e `pull-desired-state` la propaga NARROW cloud→VPS così il team smette di lavorarci (vedi `[JHT-DATA-SYNC]` "Follow-up categorizzazione azioni utente"). Lo swipe sarebbe un nuovo *front-end* su quell'azione, più un'azione "tieni/like" (`position_feedback`).
+- **Vincolo read-only/sicurezza**: la scrittura (escludi/tieni) deve passare da desktop/local (`requireLocalWrite`) **oppure** dalla corsia richieste async cloud — come like/ticket, che restano cloud (vedi `[[feedback_web_readonly_is_security]]`). Quindi lo swipe può vivere anche sul web cloud purché usi la corsia async, non la scrittura diretta.
+- **Aperto**: dove collocarlo (pagina dedicata `/positions/triage` vs modalità della lista); se filtrare per soglia score; se mostrare solo le non-ancora-triate; gesture mobile vs desktop.
+
+---
+
 ### 1️⃣ PHASE 1 — Web Platform Consolidation (current sprint)
 
 #### 🔴 HIGH PRIORITY

supabase/migrations/050_companies_highlights_full_unique_index.sql

@@ -0,0 +1,26 @@
+-- 050_companies_highlights_full_unique_index.sql
+-- Fix bug latente di mig 046: gli indici UNIQUE di `companies` e
+-- `position_highlights` erano PARZIALI (`WHERE legacy_id IS NOT NULL`).
+--
+-- Il route push usa `supabase-js .upsert(payload, { onConflict: "user_id,legacy_id" })`
+-- (web/app/api/cloud-sync/push/route.ts:433 companies, :743 highlights), che genera
+-- `INSERT ... ON CONFLICT (user_id, legacy_id)` SENZA la clausola `WHERE`. Postgres
+-- NON può inferire un indice PARZIALE da un ON CONFLICT senza lo stesso predicato →
+--   "there is no unique or exclusion constraint matching the ON CONFLICT specification"
+-- → il push falliva con HTTP 500 al PRIMO esercizio reale del path (companies/highlights
+-- non erano mai risaliti finché il route nuovo non è andato in production).
+--
+-- positions (mig 007 `positions_user_legacy_unique`) usa un indice TOTALE e funziona:
+-- allineiamo companies/highlights allo stesso schema. I NULL restano non-collidenti
+-- (UNIQUE tratta i NULL come distinti in Postgres), quindi le righe legacy senza
+-- legacy_id non violano il vincolo — esattamente come positions.
+
+-- ── COMPANIES ──────────────────────────────────────────────────
+DROP INDEX IF EXISTS idx_companies_user_legacy;
+CREATE UNIQUE INDEX IF NOT EXISTS idx_companies_user_legacy
+    ON companies(user_id, legacy_id);
+
+-- ── POSITION_HIGHLIGHTS ────────────────────────────────────────
+DROP INDEX IF EXISTS idx_highlights_user_legacy;
+CREATE UNIQUE INDEX IF NOT EXISTS idx_highlights_user_legacy
+    ON position_highlights(user_id, legacy_id);