- docker/app.Dockerfile : une image Rust + Svelte, la construction rejoue toute la boucle (fmt, clippy -D warnings, tests, svelte-check, vitest) ; utilisateur non-root, volume /data. docker/app-compose.yml pour sonic (fabio). - .woodpecker/app.yml : produit sur decision.librodrome.org, attend la maquette, écarte tout conteneur qui revendique encore la racine, healthcheck du commit. - .woodpecker/maquette.yml (ex .woodpecker.yml) : la maquette v2 telle quelle, sur maquette.decision.librodrome.org, mêmes volumes. - .env.example de la maquette rangé dans maquette/ ; celui de la v3 à la racine. - Docs : README, CONTRIBUTING (travail à deux), CLAUDE.md v3, HANDOFF, docs/chantiers (feuille de route, fiche, contrôles, onboarding de Chiara, demande à poka), docs/adr 0001–0006. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1.1 KiB
1.1 KiB
0001 — Rust + Svelte, une image, SQLite
Contexte. La v2 (Nuxt local-first + FastAPI) a servi de maquette. Yvv veut « un dev rust - svelte pour la longue durée, la performance, la modularité et la compilation de haute qualité ». Le premier chantier a besoin d'un serveur (votes partagés, publication), pas d'un stockage navigateur.
Décision.
- Serveur en Rust :
ld-engine(règles pures, sans I/O),trustin-access(accès),ld-server(axum + sqlx). Toolchain épinglée,clippy -D warnings,unsafeinterdit. - Interface SvelteKit / Svelte 5 en SPA statique, compilée et servie par le même binaire.
- SQLite (WAL) dans un volume nommé : une instance, des milliers de votants, aucune base à administrer. Migrations additives seulement.
- Une seule image ; sa construction rejoue toute la boucle.
- La maquette v2 reste dans
maquette/, intacte, déployée à part.
Coût. Deux langages dans le dépôt ; une instance unique (pas de réplication). Si la synchronisation entre instances devient nécessaire, elle passera par le dépôt des textes et une API, pas par la base.