À la demande explicite de l'utilisateur (site jugé "trop moche"),
inspiration visuelle prise sur https://www.studiocart.co/ : grands
titres serif (Fraunces) avec italique, fond papier clair plutôt que le
coffre-fort sombre d'origine, un seul accent vif (citron vert) utilisé
avec parcimonie pour les surlignages, cartes blanches nettes à bordure
fine, petites touches dessinées à la main (squiggle, flèche) sur l'écran
de connexion.
- Jetons de thème (index.css, tailwind.config.js) : le thème clair
devient la palette par défaut. Le thème sombre existant reste
disponible via le bouton de bascule, inchangé.
- ThemeContext : thème par défaut passé à 'light'.
- Écran de connexion entièrement repensé (fond génératif pastel qui
dérive lentement, carte blanche, surlignage citron vert via la
nouvelle classe utilitaire .tc-highlight, doodles SVG).
- Reste de l'application : cascade automatique via les tokens CSS déjà
utilisés partout (bg-panel, text-ink, ...), sans avoir à toucher
chaque composant individuellement.
Inspiration de studiocart.co pour le ton visuel uniquement (typographie,
palette, motifs) - aucun contenu, logo ni image de ce site n'est repris.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Fond génératif beaucoup plus lumineux et coloré (base par scène,
taches plus grandes/saturées, scrim réduit à un dégradé directionnel
léger côté texte) - le premier essai était encore jugé trop sombre/
invisible par l'utilisateur.
- Cause réelle du "rien n'a changé" : le Caddyfile ne fixait aucun
Cache-Control, donc le navigateur appliquait sa propre heuristique et
gardait l'ancien index.html en cache après un déploiement. Corrigé
sur le serveur (Caddyfile) et documenté dans
tripoli-edge/deploy/Caddyfile.snippet : `no-cache` sur index.html
(revalidation à chaque chargement), cache long `immutable` sur
/assets/* (noms hachés par Vite, donc sans risque).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Le système de crossfade existait déjà mais avec 3 dégradés plats
placeholder (commentaire explicite : "à remplacer par de vraies
images"). Remplacé par un fond génératif plus riche, à la demande de
l'utilisateur (design jugé "moche", contraste douteux sur certains
postes) :
- 4 scènes (taches de couleur floutées, palette sourde) qui dérivent
lentement (@keyframes tc-drift, respecte prefers-reduced-motion) et
s'enchaînent en fondu toutes les 8s.
- Grain léger (SVG feTurbulence, mix-blend-overlay) contre l'effet
"dégradé plat".
- Scrim en deux passes (voile uniforme + dégradé directionnel) : le
texte reste lisible quelle que soit la scène ou la position, plutôt
que de dépendre d'un seul dégradé ancré à gauche.
Pas de photo tierce (droits, dépendance externe) - art génératif en
CSS/SVG, cohérent avec le ton "coffre-fort minimaliste" du reste de
l'interface.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
À la demande explicite de l'utilisateur après avoir constaté que
tripoli.cloud affichait un 404 vide (le frontend n'avait jamais été
déployé) : déploiement du frontend, puis remplacement complet des
mocks par de vraies données, des deux côtés.
Backend (tripoli-api) :
- users.name, files.category (file/photo/backup), table notifications
(migration 0002).
- POST /api/auth/guest : compte invité réel et réutilisé
(invite@tripoli.local), pas une identité simulée côté frontend.
- GET /api/files?category=... , GET /api/notifications (+ read-all/
{id}/read), GET /api/storage (used_bytes réel, available_bytes via
statvfs - jamais un quota inventé).
- Notifications émises réellement sur upload/suppression.
Frontend (app/) :
- src/api/*.ts appellent réellement tripoli-api (plus de mockFetch).
- Upload réel (XHR, vraie progression), suppression avec bouton dédié,
vraies miniatures photo (<img src="/api/files/:id">).
- Session restaurée au chargement (GET /api/auth/me), logout réel.
- Retiré plutôt que simulé : 2FA, clé de récupération, accès partagés,
albums, dossiers, "4 appareils sauvegardés", chiffres marketing et
claim AES-256 côté client sur la page de connexion (jamais vrai -
remplacé par le vrai : HTTPS + Argon2).
Déploiement :
- Frontend construit et déployé sur le serveur (le build local échouait
spécifiquement sur cette machine - rolldown/esbuild natif ne répondait
plus, cause non résolue ; contourné en buildant sur le serveur, comme
déjà fait pour les crates Rust).
- Caddy : /var/www/tripoli-cloud servi en statique pour tripoli.cloud,
/api/*, /healthz, /metrics toujours proxyés vers tripoli-edge.
- Pipeline CI étendu : le job deploy construit et déploie maintenant
aussi le frontend, via un script sudo dédié supplémentaire
(tripoli-deploy-frontend.sh) sur le compte deploy sans privilège.
- Vérifié en navigateur réel (Chrome) : inscription, connexion, invité,
upload avec progression, photos, sauvegardes, notifications,
suppression, déconnexion - tous testés en conditions réelles.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Livrable final du brief : diagramme ASCII du chemin de trafic réel
(Caddy -> tripoli-edge -> tripoli-api -> Postgres/blobs), les labos
volontairement hors de ce chemin (WireGuard admin, tripoli-netctl,
bird-lab), et une section limites assumées explicite (1 VPS, pas de
KVM, serveur partagé, OpenTofu écrit mais pas appliqué, alertes sans
notification, SSH public toujours ouvert).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- .forgejo/workflows/ci.yml : build + test cargo (workspace), build npm
(app/) sur toute PR/push ; déploiement (main uniquement) : build
release, scp + redémarrage systemd sur tripoli-edge et tripoli-api.
- Runner Forgejo Actions déployé en systemd (aucun n'existait avant) :
socket Docker de l'hôte partagé avec les conteneurs de job plutôt
qu'un docker:dind imbriqué et privilégié - plus léger sur une machine
déjà partagée.
- Déploiement via un compte système "deploy" sans privilège : peut
seulement déposer un binaire dans /opt/deploy-staging et lancer un
script sudo dédié qui n'accepte que "tripoli-edge" ou "tripoli-api"
comme argument. Aucune clé root dans le pipeline. Clé SSH de
déploiement générée sur le serveur, jamais passée par cette
conversation - stockée directement comme secret Forgejo Actions par
l'utilisateur.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Topologie en étoile : racine (AS 65000) en transit entre bird-a
(AS 65010) et bird-b (AS 65011), namespaces créés par tripoli-netctl
(Phase 4). Chaque feuille origine une route factice, jamais
installée dans la table de routage réelle (export none partout) -
labo pédagogique, ne pilote aucun trafic de production.
- Vérifié en conditions réelles : sessions BGP Established dans les
deux sens, route de bird-b vue par bird-a avec next-hop = racine
(transit confirmé, pas un peering direct), sessions BFD Up
(200ms/200ms), coupure de lien détectée en < 5ms.
- Découverte : les namespaces n'ont aucun pare-feu propre, mais ufw
côté racine bloquait le retour des paquets BFD (chaque bout envoie
indépendamment, conntrack ne le reconnaît pas comme un flux BGP/TCP
existant) - même schéma que Caddy -> tripoli-edge en Phase 2. Règle
ufw ajoutée par run.sh, retirée par teardown.sh : rien de permanent.
- Pas de service systemd : labo lancé, vérifié, puis proprement démonté
(processus Bird, namespaces et règle ufw temporaire tous supprimés).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Pas de stack dédiée : une instance Prometheus/Grafana existe déjà sur
ce serveur pour les 5 autres projets. En déployer une seconde aurait
dupliqué de la RAM sur une machine à 3.7 Go partagée, sans bénéfice -
même raisonnement que pour Caddy en Phase 2.
- Scrape job tripoli_edge (172.17.0.1:9000, même passerelle docker0 que
Caddy) ajouté à la config Prometheus existante.
- Règles d'alerte : TripoliEdgeDown (up == 0), HostDiskAlmostFull
(< 10% d'espace libre sur / - au niveau de la machine, pas seulement
de ce projet, puisqu'il n'y a qu'un disque pour tout le monde).
- Sonde blackbox externe ajoutée pour https://tripoli.cloud/healthz.
- Dashboard Grafana versionné (uid tripoli-cloud-edge), importé via
l'API (POST /api/dashboards/db) pour rester reproductible, pas
construit à la main dans l'UI.
- Vérifié : tous les targets Prometheus up (dont tripoli_edge et la
sonde tripoli.cloud), les deux règles d'alerte chargées et évaluées,
les requêtes du dashboard retournent de vraies valeurs.
- Limite assumée : les alertes se déclenchent dans Prometheus mais ne
sont pas encore routées par email (pas d'Alertmanager, pas de policy
de notification Grafana dédiée) - documenté comme prochain pas, pas
fait pour éviter de modifier la politique de notification globale de
l'instance partagée sans plus de tests.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- CLI (clap) : create/destroy/list. Network namespace créé via
rtnetlink::NetworkNamespace (fork + unshare(CLONE_NEWNET) + bind-mount,
équivalent de `ip netns add`), paire veth créée dans la racine, un
bout déplacé dans le namespace (setns_by_fd) et adressé depuis un
thread OS dédié qui fait setns() - jamais un thread du pool
spawn_blocking de tokio, qui serait réutilisé pour d'autres tâches et
resterait coincé dans le namespace.
- Journal d'audit JSON (stderr + /var/log/tripoli-netctl/audit.log) à
chaque opération.
- Documenté explicitement comme labo pédagogique un-seul-poste :
tripoli-edge et tripoli-api restent nativement sur l'hôte, ce projet
ne pilote aucun trafic de production.
- Testé en conditions réelles sur le serveur : création, adressage des
deux côtés (dont lo, down par défaut dans un netns neuf), ping
traversant effectivement la veth, puis destruction propre (veth +
namespace) vérifiée par absence des interfaces et du namespace.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- axum + sqlx (requêtes runtime, pas les macros query! à vérification
compile-time - évite d'exiger une base joignable à chaque build).
- Auth par session opaque côté serveur (cookie HttpOnly/Secure/SameSite,
pas de JWT - révocation = suppression de ligne). Mots de passe
Argon2.
- Fichiers : upload multipart streamé chunk par chunk vers le disque
(jamais accumulé en mémoire - condition réelle d'une progression
d'upload non simulée), download streamé, blobs nommés par UUID
(le nom d'origine ne vit qu'en métadonnée).
- Stockage disque pour cette v1 (pas Object Storage - pas de bénéfice
réel pour un unique VPS avec 55 Go libres, ajouté sans complexité
inutile).
- PostgreSQL dans un conteneur Docker dédié, séparé de celui
d'iot-alarm-system (pas de couplage entre projets sans rapport).
- Déployé en prod sous systemd (même utilisateur système que
tripoli-edge), branché sur son upstream par défaut. Vérifié
bout-en-bout via https://tripoli.cloud/api/... : inscription,
connexion, upload, download, suppression, et les cas d'erreur
(401 sans session, 409 email déjà pris, 401 mauvais mot de passe,
404 double suppression).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- tripoli-edge (hyper/tokio bas niveau, pas de framework type axum) :
/healthz, /metrics (Prometheus, compteurs à la main), reverse-proxy
vers tripoli-api avec vrais 502 tant que ce service n'existe pas
(Phase 3), logs JSON structurés par requête.
- Écoute sur 127.0.0.1 + 172.17.0.1 (passerelle docker0), jamais sur
l'interface publique - même pattern que le Nginx de VoltVision déjà
sur ce serveur.
- Déployé en prod : systemd (utilisateur système dédié, sans privilège),
bloc Caddy ajouté pour tripoli.cloud/www.tripoli.cloud, règle ufw
ajoutée (Ansible) pour que Caddy puisse joindre le port 9000 - sans
quoi le chemin INPUT de l'hôte bloque le trafic inter-bridges même
vers 172.17.0.1.
- Vérifié bout-en-bout via https://tripoli.cloud, sans régression sur
les 6 autres domaines déjà servis par ce Caddy.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Reconnaissance : le serveur héberge déjà 6 autres projets derrière un
Caddy partagé (80/443) ; tripoli-edge sera un service interne (décision
prise avec l'utilisateur), pas un second frontal.
- WireGuard : canal admin Mac <-> serveur (10.100.0.0/24, port 58212/udp
après avoir découvert que 51820 était filtré par le pare-feu Hetzner
Cloud, distinct de ufw).
- Ansible : rôle base (confirme fail2ban/unattended-upgrades/ufw déjà en
place, sans toucher aux règles des autres projets) + rôle wireguard
(clé privée générée sur la cible, jamais stockée dans ce dépôt).
- OpenTofu : serveur Hetzner référencé en data source lecture seule
(jamais recréé/détruit - serveur partagé et déjà en prod) ; DNS
tripoli.cloud géré via le provider OVH.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
React/TypeScript/Vite/Tailwind prototype from the design session (login,
dashboard, photos, backups, settings views with mocked API layer).
Infra work (Rust services, Ansible, OpenTofu) follows in subsequent commits.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
