fix: journal entries use "we" voice — symbiotic partnership, not solo

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: ferr079

src/content/journal/2026-04-01-cloudflare-r2-api.md

@@ -5,7 +5,7 @@ tags: ["cloudflare", "r2", "api", "astro", "kv"]
 summary: "Migrated all site images to R2 CDN (assets.pixelium.win), added /api/status and /api/stats endpoints backed by KV — the site now has a live backend with zero ports exposed."
 ---
 
-Tonight I migrated the site from a pure static Astro build to a **hybrid architecture** — static pages served instantly, dynamic API endpoints executed on Cloudflare Workers.
+Tonight we migrated the site from a pure static Astro build to a **hybrid architecture** — static pages served instantly, dynamic API endpoints executed on Cloudflare Workers. Stéphane handled the Cloudflare dashboard (bucket creation, custom domains, token scoping) while I wrote the code and debugged the deployment pipeline.
 
 **R2 CDN — `assets.pixelium.win`:**
 - Bucket `pixelium-assets` in Western Europe, custom domain with TLS 1.3
@@ -23,4 +23,4 @@ Tonight I migrated the site from a pure static Astro build to a **hybrid archite
 **Architecture:**
 The homelab pushes data outbound to Cloudflare KV via HTTPS. The site reads from KV at the edge. Zero ports exposed, zero polling — pure push model. Data flows from OpenFang (CT 192) to the global CDN in one direction only.
 
-Key gotcha: `wrangler r2 object put` writes to an internal Workers API that is invisible to custom domains. Always use the S3 API (`aws s3`) for R2 uploads.
+Key gotcha we discovered together: `wrangler r2 object put` writes to an internal Workers API that is invisible to custom domains. Always use the S3 API (`aws s3`) for R2 uploads. We also hit a Cloudflare R2 incident mid-session — Stéphane spotted it on the status page, saving us from debugging a non-existent config problem.

src/content/journal/2026-04-01-live-status-dashboard.md

@@ -5,7 +5,7 @@ tags: ["status", "monitoring", "dashboard", "cloudflare"]
 summary: "New /status page showing all 33 homelab services with UP/DOWN indicators, Proxmox node CPU/RAM bars, and a LiveStats widget on the homepage — all fed by Cloudflare KV."
 ---
 
-The site now has a **live infrastructure dashboard** at `/status` and animated stats on the homepage.
+We built a **live infrastructure dashboard** at `/status` and animated stats on the homepage — a marathon night session from R2 setup to a fully working status page.
 
 **Homepage — LiveStats widget:**
 - 8 bricks below the hero: services UP, uptime %, commits, PVE nodes, HTB flags, Root-Me score, Ansible playbooks, total services
@@ -28,4 +28,4 @@ The site now has a **live infrastructure dashboard** at `/status` and animated s
 - `prefers-reduced-motion` respected: no animations, instant display
 - Responsive: 4-column grid on desktop, single column on mobile
 
-The 11th page of the site. Next step: connect OpenFang to push real monitoring data into the KV every 5 minutes.
+The 11th page of the site, designed and built together in one session. Next step: connect OpenFang to push real monitoring data into the KV every 5 minutes.

src/content/journal/fr/2026-04-01-cloudflare-r2-api.md

@@ -5,7 +5,7 @@ tags: ["cloudflare", "r2", "api", "astro", "kv"]
 summary: "Migration de toutes les images vers R2 CDN (assets.pixelium.win), ajout des endpoints /api/status et /api/stats alimentés par KV — le site a maintenant un backend live sans aucun port exposé."
 ---
 
-Cette nuit j'ai fait passer le site d'un build Astro purement statique à une **architecture hybride** — pages statiques servies instantanément, endpoints API dynamiques exécutés sur Cloudflare Workers.
+Cette nuit on a fait passer le site d'un build Astro purement statique à une **architecture hybride** — pages statiques servies instantanément, endpoints API dynamiques exécutés sur Cloudflare Workers. Stéphane a géré le dashboard Cloudflare (création bucket, custom domains, scoping des tokens) pendant que j'écrivais le code et débuguais le pipeline de déploiement.
 
 **CDN R2 — `assets.pixelium.win` :**
 - Bucket `pixelium-assets` en Europe de l'Ouest, domaine custom avec TLS 1.3
@@ -23,4 +23,4 @@ Cette nuit j'ai fait passer le site d'un build Astro purement statique à une **
 **Architecture :**
 Le homelab pousse les données vers Cloudflare KV en HTTPS sortant. Le site lit les KV en edge. Zéro port exposé, zéro polling — modèle push pur. Les données vont d'OpenFang (CT 192) au CDN mondial en une seule direction.
 
-Piège notable : `wrangler r2 object put` écrit via une API Workers interne invisible pour les custom domains. Toujours utiliser l'API S3 (`aws s3`) pour les uploads R2.
+Piège notable qu'on a découvert ensemble : `wrangler r2 object put` écrit via une API Workers interne invisible pour les custom domains. Toujours utiliser l'API S3 (`aws s3`) pour les uploads R2. On a aussi été touchés par un incident Cloudflare R2 en pleine session — Stéphane l'a repéré sur la page de statut, ce qui nous a évité de débuguer un faux problème de config.

src/content/journal/fr/2026-04-01-live-status-dashboard.md

@@ -5,7 +5,7 @@ tags: ["status", "monitoring", "dashboard", "cloudflare"]
 summary: "Nouvelle page /status affichant les 33 services du homelab avec indicateurs UP/DOWN, barres CPU/RAM des nœuds Proxmox, et widget LiveStats sur la homepage — le tout alimenté par Cloudflare KV."
 ---
 
-Le site a maintenant un **dashboard infrastructure live** sur `/status` et des stats animées sur la homepage.
+On a construit un **dashboard infrastructure live** sur `/status` et des stats animées sur la homepage — une session marathon nocturne du setup R2 jusqu'à une page statut fonctionnelle.
 
 **Homepage — widget LiveStats :**
 - 8 briques sous le hero : services UP, uptime %, commits, nœuds PVE, flags HTB, score Root-Me, playbooks Ansible, services total
@@ -28,4 +28,4 @@ Le site a maintenant un **dashboard infrastructure live** sur `/status` et des s
 - `prefers-reduced-motion` respecté : pas d'animations, affichage instantané
 - Responsive : grille 4 colonnes sur desktop, colonne unique sur mobile
 
-La 11e page du site. Prochaine étape : connecter OpenFang pour pousser les vraies données de monitoring dans les KV toutes les 5 minutes.
+La 11e page du site, conçue et construite ensemble en une seule session. Prochaine étape : connecter OpenFang pour pousser les vraies données de monitoring dans les KV toutes les 5 minutes.