ADR 0004 : Circuit de validation des tâches appliqué par trigger PostgreSQL

• Statut : Accepté
• Décideurs : Marco (Commanditaire), Julien (Commanditaire), Seer (Développeur)
• Date : 8 juillet 2026

Contexte et Problème

Le métier impose un circuit de validation des tâches :

• une tâche créée par un collaborateur démarre en pending_validation (elle ne peut pas partir directement en todo) ;
• seul un manager/admin du projet peut la valider ;
• quand un collaborateur veut passer une tâche en done, elle repasse en validation ;
• une tâche créée par un manager démarre directement en todo.

Ces règles touchent à l'intégrité des données. Les appliquer uniquement dans l'interface React laisse la porte ouverte à tout contournement (appel direct à l'API Supabase avec la clé anon, qui est publique côté client).

Facteurs de Décision

• Intégrité : les transitions de statut interdites doivent être impossibles, pas seulement masquées dans l'UI.
• Cohérence : une même règle quel que soit le point d'entrée (UI, script, appel direct).
• Alignement RLS : le contrôle doit s'appuyer sur l'identité auth.uid() et l'appartenance projet.

Options Envisagées

Option A : Contrôle applicatif uniquement (React)

Coder les règles de transition dans les composants (TaskDetail, dashboards).

• Avantage : simple, aucune logique en base.
• Inconvénient : contournable (la clé anon est publique) ; règle dupliquée à chaque écran ; aucune garantie d'intégrité.

Option B : Trigger PostgreSQL enforce_task_workflow (Recommandée)

Un trigger BEFORE INSERT/UPDATE sur public.task (docs/features/sql/07_task_workflow.sql) impose les transitions autorisées selon le rôle et l'appartenance au projet. L'UI reste un confort, mais la base a le dernier mot.

• Avantage : règle inviolable et centralisée ; cohérente avec la RLS ; testable (npm run test:workflow).
• Inconvénient : logique métier en SQL (moins familière), à maintenir en parallèle de l'UI.

Décision Retenue

L'Option B : trigger PostgreSQL a été retenue.

Justification

La clé anon étant publique côté client, seul un contrôle en base garantit l'intégrité du circuit. Le trigger enforce_task_workflow rend les transitions interdites réellement impossibles ; l'UI se contente de refléter et guider. Le comportement est couvert par scripts/test-workflow.js.

Conséquences

Positives

• Circuit de validation inviolable, même en cas d'appel direct à l'API.
• Une source de vérité unique pour les règles de statut.
• Testé de bout en bout (création collab → validation manager → done).

Négatives

• Une partie de la logique métier vit en SQL (double maintenance UI/DB).
• Les messages d'erreur du trigger doivent être traduits/affichés proprement côté client.