Bug V1 documenté dans flow.md mais jamais corrigé : le job send_checkin_job
envoyait l'email + marquait la CheckinTask `sent`, mais ne touchait pas le
statut de la facture. Conséquence : l'user reçoit le mail check-in dans sa
boîte mais la modale in-app au refresh ne l'affiche pas (la modale liste
uniquement les `awaiting_user_confirmation` côté DB).
Fix : après l'envoi mail OK et le mark CheckinTask=sent, on bump
`Invoice.status = 'awaiting_user_confirmation'` SI elle est encore
en `pending`. Pas de bump si entre temps :
- mark-paid (status=paid)
- litigation/cancelled (transitions manuelles)
- in_relance (impossible mais safe)
Doc flow.md mise à jour pour refléter le nouveau comportement (effets
de la transition pending → awaiting + déprécation de la note "TODO V1.5").
Pour les factures existantes en prod qui ont déjà reçu le mail mais
restent en `pending` (cas pré-fix) : backfill manuel via SQL :
UPDATE invoices SET status = 'awaiting_user_confirmation'
WHERE status = 'pending'
AND id IN (
SELECT invoice_id FROM checkin_tasks WHERE status = 'sent'
);
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Nouvelle doc orientée comportement produit : explique précisément ce que
fait Rubis du point de vue user-lambda. Pour les arch/tech → architecture.md.
Pour la spec features → produit.md.
Sections :
1. Modèle mental
2. Glossaire (rubis, plan, étape, confirmation, mise en demeure, DSO, LME)
3. Cycle de vie d'une facture (6 statuts + diagramme transitions ASCII +
détails par transition avec effets en cascade)
4. Surfaces UI où l'user agit (modale check-in, email check-in, fiche
facture, slide-over démo) — avec différences mobile/desktop
5. Mécanique de confirmation deep-dive (le coeur du produit)
6. Plans de relance (structure, plans pré-fournis, wizard custom, vars)
7. Mode démo (flag, fork point unique, horloge virtuelle)
8. KPIs & calculs (rubis, encaissé, DSO, pipeline)
9. Edge cases & règles
10. Métriques produit à instrumenter
11. Ce que Rubis ne fait PAS
CLAUDE.md mis à jour pour pointer vers cette doc dans la liste des
documents associés.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Collection Bruno (.bru text files, comme Postman mais file-based versionable) qui couvre l'API V1 actuelle. Open Collection → bruno/ → sélectionner l'environnement "local".
Domaines couverts (22 requêtes) :
- 00-Auth : Signup, Login, Logout
- 01-Account : Get/Update profile
- 02-Organizations : Get/Update my org
- 03-Clients : List, List+stats, Search, Create, Create duplicate (409), Create without email (422), Get detail, Update
- 04-Plans : List, Get by slug, Update (steps remplacés)
- 05-Invoices : List, List+filters, Counts, Create, Get detail, Mark paid
Environnement local (bruno/environments/local.bru) :
- baseUrl, email/password/fullName en dur
- token, userId, organizationId, clientId, invoiceId remplis automatiquement par les script:post-response
Chaque requête a :
- assertions Chai (statut, shape de la réponse)
- bloc docs avec sémantique métier + erreurs typiques
- inheritance auth Bearer via folder.bru pour ne pas répéter le header
Mise à jour de docs/tech/dev-setup.md pour pointer vers la collection.
Le parcours recommandé Signup → Update org → Create client → Create invoice → Mark paid couvre le happy path et permet de checker rubisCount qui s'incrémente.
Convention dure : tous les identifiants applicatifs sont des UUID v4 générés par PG (default gen_random_uuid()), aucun increments/serial même pour les tables techniques.
- CLAUDE.md → "Conventions techniques" : règle énoncée explicitement (anti-énumération, multi-tenant, génération côté client, dumps propres).
- docs/tech/backend.md §4.0 : exemple de migration + raisons.
- 4 migrations existantes réécrites en uuid (users, auth_access_tokens, organizations, alter users.organization_id). Les access tokens d'Adonis acceptent un tokenable_id uuid sans changement côté provider.
- Transformers nettoyés : plus de String(id), les UUID sont déjà des string.
- DB régénérée from scratch (migrations sont éditées avant tout déploiement, pas un cas où un autre dev a une DB en prod).
mailhog n'est plus maintenu et ne ship qu'en amd64 — sur Apple Silicon ça déclenche un warning Rosetta. Mailpit est le successeur drop-in (mêmes ports SMTP 1025 / UI 8025), multi-arch, activement maintenu.
Miroir de docs/tech/frontend.md, ancré sur :
- Le scaffold Adonis 7 déjà en place (apps/api/)
- Le contrat exact que le SPA consomme (handlers MSW =
source de vérité du shape attendu)
- Les types/schemas dans packages/shared
- Les ADR 014 (stack), 015 (monorepo), 016 (PG), 017 (auth),
018 (storage)
20 sections : vue d'ensemble, stack interne, repo layout,
domain models (Lucid), routes API par domaine, conventions
de réponse, auth Bearer + refresh httpOnly custom, Tuyau,
validation Vine, storage MinIO, OCR pipeline, email outbound,
background jobs (BullMQ), tests Japa, migrations + seeders,
variables d'env, Dockerfile + K3s deployment, pointeurs
vers l'existant, ADRs encore à trancher (019 à 025),
évolutions V2+.
Règle d'or rappelée plusieurs fois : avant de coder un
endpoint, regarder le handler MSW correspondant — le SPA
est déjà branché à cette surface, c'est exactement ce que
l'API doit servir.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Monorepo Turborepo (pnpm workspaces) avec 3 packages :
- apps/web : SPA React 19 + Vite 8 + Tailwind v4 (CSS-first)
• TanStack Router (file-based, auto code-splitting), Query, Form
• Radix primitives bruts + CVA + clsx + tailwind-merge
• MSW pour mocker l'API tant qu'Adonis n'est pas branché
• Polices Bricolage Grotesque + Inter self-hostées via fontsource
• Tokens marque (rubis, cream, ink) exposés via @theme
• Primitives maison : Gem, Brand, Eyebrow, Button, Input, Field
• Route /login full flow : TanStack Form + Zod + mutation Query
- apps/api : Adonis 7 (kit api, scaffold via create-adonisjs)
• Auth access tokens (Bearer) — cf. ADR-017
• Tuyau core déjà câblé pour la génération de types
• Routes /api/v1/auth/{signup,login} + /api/v1/account/{profile,logout}
• Minimal — uniquement le pont front ↔ back
- packages/shared : types TS + schemas Zod + constantes
• Source unique de vérité partagée api ↔ web
• Domaines : User, Org, Auth, Client, Invoice, Plan
Tooling racine : Turbo, ESLint v9 flat, Prettier, husky, lint-staged.
CLAUDE.md et docs/decisions.md mis à jour avec ADR-014 à ADR-018
(stack, monorepo, PG existant, Bearer tokens, MinIO existant)
et le pointeur vers docs/tech/architecture.md.
Logo Rubis déplacé de landing/assets/ vers /assets/ (source unique
réutilisée par la landing et l'app).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
