Branche tes données

La mission est découpée en étapes progressives :

1. 1
   Étape 1 — Pense tes données avant d'écrire une ligne. Avant le moindre prompt, prends deux minutes pour répondre à ces trois questions, par écrit, dans ton JOURNAL : quelle est la chose que ta feature manipule (un item capté, une tâche, une note, une dépense) ? Quelles infos porte cette chose (un titre, une date, un statut, une source) ? Et surtout, qu'est-ce qui rend deux entrées identiques ? C'est ta clé de dédup. Dans Captage, deux flux RSS qui renvoient le même article ne doivent jamais créer deux rows : la clé, c'est l'URL. Cet inventaire AVANT d'agir, c'est la discipline vibecoding : une intention claire produit un schéma propre du premier coup ; une demande floue produit une table que tu retoucheras dix fois.
2. 2
   Étape 2 — Fais écrire le modèle à Claude Code. Donne-lui ton inventaire comme intention, en exigeant la contrainte d'unicité et en interdisant l'exécution immédiate :

Crée la table `items` pour stocker une chose captée. Colonnes :
- id (clé primaire UUID, généré automatiquement)
- title (texte, requis)
- source_url (texte) — c'est notre clé de dédup
- status (texte, défaut 'inbox')
- created_at (timestamp avec fuseau, défaut maintenant)

Ajoute une contrainte UNIQUE sur source_url pour qu'on ne puisse
jamais avoir deux fois la même source. Écris la migration SQL,
ne l'exécute pas encore, montre-la moi d'abord.

1. 1
   Étape 3 — Relis la migration AVANT de l'appliquer. Tu dois y voir la contrainte d'unicité écrite noir sur blanc. Quelque chose comme :

CREATE TABLE items (
  id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  title       TEXT NOT NULL,
  source_url  TEXT,
  status      TEXT NOT NULL DEFAULT 'inbox',
  created_at  TIMESTAMPTZ NOT NULL DEFAULT now(),
  UNIQUE (source_url)
);

Puis applique-la. Un seul changement à la fois : on crée la table, on vérifie qu'elle existe, et seulement après on branche la feature. Pour confirmer que la table est bien née, demande à Claude Code de lister sa structure, ou regarde-la dans ton dashboard de base :

La migration est appliquée ? Montre-moi la structure réelle de la
table `items` telle qu'elle existe maintenant en base (colonnes,
types, contraintes), pour que je vérifie que le UNIQUE est bien là.

1. 1
   Étape 4 — Bake la dédup dans l'écriture, pas après. La contrainte UNIQUE empêche le doublon, mais elle plante si tu réinsères la même source. La bonne réponse, c'est ON CONFLICT : tu dis à la base quoi faire quand le doublon arrive, au lieu de la laisser exploser. Demande à Claude Code que ta fonction d'insertion soit idempotente, et que la règle vive côté serveur :

Quand on insère un item dont la source_url existe déjà, ne crée pas
de doublon et ne plante pas : utilise ON CONFLICT (source_url)
DO NOTHING (ou DO UPDATE si on veut rafraîchir le titre).
Mets cette logique dans une fonction côté serveur, PAS dans le
composant d'affichage.

Voici les deux formes que peut prendre l'insertion idempotente :

-- On ignore le doublon : la première version gagne.
INSERT INTO items (title, source_url)
VALUES ('Mon item', 'https://exemple.com/a')
ON CONFLICT (source_url) DO NOTHING;

-- On rafraîchit le titre si la source existe déjà.
INSERT INTO items (title, source_url)
VALUES ('Titre mis à jour', 'https://exemple.com/a')
ON CONFLICT (source_url) DO UPDATE SET title = EXCLUDED.title;

Cette phrase compte, retiens-la : la logique d'écriture vit côté serveur, jamais dans l'UI. L'écran demande, le serveur décide. C'est la ligne rouge de Captage transposée au code : le front propose, la couche métier tranche.

1. 1
   Étape 5 — Livre la feature de bout en bout. Maintenant, le chemin complet. Une seule feature, mais entière :

Construis la première feature : ajouter un item.
- Dans l'UI : un champ titre + un champ source_url + un bouton « Ajouter ».
- Au clic : appelle la fonction serveur d'insertion (avec la dédup ON CONFLICT).
- Après l'insertion : recharge la liste depuis la base et affiche tous les
  items, du plus récent au plus ancien.
Fais le tour complet : action → persistance → réaffichage.

L'épreuve de vérité : ajoute un item, puis recharge la page (un vrai F5, pas un simple re-render). S'il est toujours là, la donnée a vraiment persisté. S'il disparaît, elle n'a jamais touché la base : tu affichais un état mémoire qui s'est volatilisé au rechargement.

1. 1
   Étape 6 — Teste la dédup pour de vrai. Ajoute deux fois exactement le même source_url. La deuxième fois ne doit créer aucun doublon. Vérifie le compte de rows :

-- Combien d'items au total ?
SELECT count(*) FROM items;

-- Y a-t-il une source présente plus d'une fois ?
SELECT source_url, count(*) AS occurrences
FROM items
GROUP BY source_url
HAVING count(*) > 1;

La deuxième requête doit renvoyer zéro ligne. Si elle en renvoie une, ta dédup est cosmétique, pas réelle : soit la contrainte n'existe pas, soit ton insertion la contourne. Tant que cette requête ne renvoie pas zéro, la mission n'est pas finie.