Audit cross-doc/code, batch tech : architecture, backend, frontend,
dev-setup. Corrige les claims qui pouvaient induire un dev en erreur
(noms de services K3s, hostnames Traefik, Tuyau, queue wrapper,
seeders, env vars, polices).
architecture.md
- Composants : status « À écrire » → « ✅ Déployé » (apps/web,
apps/api, packages/shared) ; ajout Redis Deployment K3s ; OCR =
Mistral choisi ; mail = Resend (sortant) + OVH MX (entrant)
validés
- §7.5 Pods K3s : noms réels (rubis-api / rubis-web / rubis-landing
/ rubis-redis, pas de *-svc) ; pas d'IngressRoute api.rubis.pro
(l'API est servie via app.rubis.pro/api/* proxifié par nginx du
pod web) ; PG/MinIO en URL directe dans la ConfigMap, pas de
Service ExternalName
- §10 Décisions en attente : ADRs 019-024 mises à jour
(tranchées / obsolètes), suppression du wording « à venir » pour
les choix déjà figés dans le code
backend.md
- Note de cohérence en tête : pointe vers start/routes.ts comme
source de vérité de la surface API (~80 routes — Stripe,
Demo, AI, Microsoft SSO, admin blog, posts publics, KPIs
timeseries) que cette doc n'inventorie pas exhaustivement
- §1 Vue d'ensemble : Tuyau marqué « non utilisé en pratique »
(présent en deps mais zéro import côté SPA), partage de types
via packages/shared. OCR Mistral choisi. Mail Resend choisi.
BullMQ direct (workers inline pod API). Sentry ADR-024.
- §2 Stack : queue = BullMQ direct (pas @rlanz/bull-queue, qui
n'est pas installé) ; type-sharing = packages/shared
- §2 Dépendances : remplacé la todo-list pré-livraison par la
liste réelle des packages dans apps/api/package.json
- §3 Repo layout : `database/factories/` (dossier) → `factories.ts`
(mono-fichier) ; `database/seeders/{default_plans,demo_data}` →
inexistants, services à la place
- §13.2 Jobs : ProcessOcrJob + RecomputeKpisJob retirés
(n'existent pas — OCR synchrone via services/import_batch.ts,
KPIs calculés on-the-fly). Liste des jobs réels :
send_relance, send_checkin, send_payment_thanks
- env vars : MINIO_* → S3_* (cf. .env.example + manifest k3s) ;
bucket prod = rubis-prod-invoices
frontend.md
- Note de cohérence en tête : Tuyau pas utilisé, tokens dans
packages/ui (pas inline), polices @fontsource-variable (pas
Google Fonts via <link>)
- §1 Vue d'ensemble : client API = fetch minimaliste dans
apps/web/src/lib/api.ts ; périmètre livré = ~15 routes _app/
- §3 Polices : section Google Fonts → @fontsource-variable
(avec note preload woff2 critique sur la landing Astro)
- §4 Routes : arbo `_onboarding/` (faux) → `onboarding/`
(réel, segment URL) + ajout admin.blog*, clients_.$id, insights,
parametres_.abonnement, plans_.nouveau, factures_.import
- §6 Tuyau : section marquée « historique, non utilisé en V1 »
avec note explicative en tête
- §10 env vars : VITE_API_URL=https://api.rubis.pro → vide
(proxifié same-origin par nginx) + ajout VITE_USE_MOCKS,
VITE_SENTRY_DSN_WEB, VITE_APP_VERSION
dev-setup.md
- Mailhog → Mailpit (3 occurrences) — c'est ce qui tourne dans
docker-compose.dev.yml
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- CGV B2B SaaS (16 sections, conforme avec Stripe en place)
- Mentions légales allégées au strict minimum LCEN
- Politique de confidentialité resserrée :
- retrait des détails infra (Proxmox, K3s, etc.)
- sous-traitants par catégorie (Stripe / Resend / Mistral AI)
- section sécurité standardisée
- cookies simplifiés
- Période d'essai harmonisée à 30 jours partout (landing + CGV)
- Insistance sur l'hébergement et les données en France
Documentation post-migration du setup email :
- /docs/tech/backend.md §12.5 : architecture des 2 flux
(Resend pour le sortant transactionnel via send.rubis.pro,
OVH MX Plan pour l'entrant humain via @ rubis.pro)
- /CLAUDE.md : tableau récap email infra + maj domaine principal
rubis.pro / app.rubis.pro, suppression de la question ouverte
"domaine définitif" (résolue) et "endpoint waitlist" (remplacé
par CTA app)
- /.claude/deploy-memory.md : section migration rubis.pro marquée
✅ avec checklist décommissionnement legacy
- /landing/confidentialite.html : remplace privacy@rubis.pro
par contact@rubis.pro (alignement avec les boîtes OVH créées)
Adresses opérationnelles :
- contact@rubis.pro (général + RGPD)
- dev@rubis.pro (notifs techniques)
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Bascule du domaine principal vers rubis.pro / app.rubis.pro :
- K3s ConfigMaps (api.yml, web.yml) : APP_URL, WEB_URL,
COOKIE_DOMAIN, OAUTH callbacks pointent vers app.rubis.pro
- Dockerfile.web : ARG VITE_API_URL et VITE_PUBLIC_LANDING_URL
- Workflows Gitea : commentaires + build args web → rubis.pro
- Code API (mail_dispatcher, send_test_email, config/mail) :
defaults env LANDING_URL et MAIL_FROM_ADDRESS migrés
- Templates env (.env.example) idem
- Docs (architecture, backend, frontend, brand-identity) idem
- AGENTS.md / CLAUDE.md / deploy-memory : pointeurs domaine MAJ
Note : MAIL_FROM_ADDRESS dans le secret K3s reste sur
rubis@arthurbarre.fr tant que le domaine rubis.pro n'est pas
Verified dans Resend. À switcher manuellement après vérif Resend.
Compat : un 301 Traefik redirige rubis.arthurbarre.fr → rubis.pro
(et app.X aussi) — config Ansible dans le repo proxmox.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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).
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>
