veza/docs/ROADMAP_V1.0_LAUNCH.md

# ROADMAP — Veza v1.0 Public Launch (4-6 semaines)

> **Cible** : ouverture publique grand-public en 4-6 semaines, positionnée
> comme alternative sérieuse à SoundCloud, sur infra self-hosted Incus
> (R720 + débordement Hetzner si nécessaire).
>
> **Auteur** : architecte principal Veza + Claude Code Opus 4.7
> **Dernière mise à jour** : 2026-04-26
> **État de départ** : v1.0.8 + sprint 1 v1.0.9 partiellement livré
> (Item G subscription en cours, items 1.2/1.3/1.4/1.5/1.6 commit-prêts)

---

## 0. Cadrage honnête

**Compression** : le plan original (`/home/senke/.claude/plans/quelles-sont-les-prochaines-playful-beaver.md`)
visait 24 semaines pour atteindre une vraie maturité opérationnelle. On
compresse 4× ici. Ça implique de **trancher** sur ce qui rentre et ce
qui n'y rentre pas — la liste explicite est en §2. Si tu doutes pendant
les 6 semaines, reviens à §2 : tout ce qui n'y est pas listé comme IN
attend post-launch.

**Réalité** :
- Solo dev, ~50h/semaine, pas de marges pour rattraper du retard
- 30 jours ouvrés disponibles, dont ~20% absorbés par l'imprévu (CI
  rouge, dette qui remonte, decisions externes)
- Effort réel = 24 jours productifs sur 30
- Budget temps perdu sur la légal/pentest/ops externes : 0 (ces tâches
  doivent tourner en parallèle, JAMAIS sur le critical path code)

**Verdict honnête** :
- 4 semaines = irréaliste sauf à accepter risques élevés (pas de pentest
  externe, ToS template non-revu, infra single-instance)
- **6 semaines = atteignable si discipline scope-control + démarrage
  immédiat des tâches externes**
- 8 semaines = confortable

Je rédige pour 6 semaines avec marge à droite.

---

## 1. À démarrer AUJOURD'HUI en parallèle (externe au code)

Ces actions ont des cycles longs incompressibles. Elles doivent partir
**maintenant** sinon le lancement glisse de 2-4 semaines.

| # | Action | Cycle | Owner | Statut |
|---|--------|-------|-------|--------|
| EX-1 | Contacter avocat pour ToS / Privacy / DMCA / DSA | 2-4 sem | toi | ⏳ |
| EX-2 | Demander devis pentest externe (ouvert sur surface v1.0.9) | 1 sem devis + 2 sem exec | toi | ⏳ |
| EX-3 | Enregistrer agent DMCA US Copyright Office (~120 USD, 2-3 sem traitement) | 2-3 sem | toi | ⏳ |
| EX-4 | Désigner point de contact DSA (UE) — soit toi soit représentant local | 1 sem | toi | ⏳ |
| EX-5 | DNS production : `veza.fr`, `api.veza.fr`, `cdn.veza.fr`, `turn.veza.fr`, `embed.veza.fr` | 1 j | toi | ⏳ |
| EX-6 | TLS certs (Let's Encrypt) pour tous les sous-domaines | 1 j | toi | ⏳ |
| EX-7 | Compte CDN edge (Cloudflare R2 + Workers ou Bunny.net) | 1 j | toi | ⏳ |
| EX-8 | Rotation OAuth secrets prod (Google, GitHub, Discord, Spotify) | 0.5 j | toi | ⏳ |
| EX-9 | Stripe / Hyperswitch live mode setup + KYC marketplace | 2-3 sem | toi | ⏳ |
| EX-10 | Email transactionnel : domaine custom + SPF/DKIM/DMARC (Mailjet/Postmark/Brevo) | 1 sem | toi | ⏳ |
| EX-11 | Status page (statuspage.io free OU Cachet self-hosted) | 1 j | toi | ⏳ |
| EX-12 | Coturn déploiement Incus (cf. `infra/coturn/README.md`) | 1 j | toi | ⏳ |

**Critical path externe** : EX-1 (légal) et EX-2 (pentest) sont les deux
contraintes majeures. Si tu démarres EX-1 le lundi semaine 1, tu auras
les drafts ToS/Privacy semaine 3 et la version finale signée semaine 5.
EX-2 même calendrier : devis semaine 1, exécution semaines 4-5, rapport
semaine 6. Sans ces deux-là on ne tag pas v2.0.0-public.

---

## 2. Scope contract — ce qui rentre vs sort

### IN (livré avant le tag v2.0.0-public)

**Code applicatif**
- Sprint 1 v1.0.9 (subscription Item G + items 1.2/1.3/1.4/1.5/1.6 + 1.7 flake stab)
- DMCA notice workflow (formulaire + admin queue + take-down handler)
- Embed widget `/embed/track/:id` + oEmbed
- Track sharing tokens privés (parité avec playlist share)
- Service worker offline track cache (Workbox CacheFirst)
- HLS streaming activé par défaut + ABR validé
- Faceted search UI sur `/search` et `/discover`
- Open Graph tags dynamiques sur les pages tracks/playlists
- Status page côté ops + endpoint `/api/v1/status` public

**Infrastructure**
- IaC Ansible playbooks (Postgres, Redis, MinIO, RabbitMQ, coturn, HAProxy, backend-api, stream-server)
- Postgres streaming replica + pg_auto_failover (RTO < 60s)
- pgBackRest WAL archive + restore drill cron hebdo
- PgBouncer transaction-mode pool
- Redis Sentinel 3-node
- MinIO erasure-coded 4-node EC4+2
- HAProxy frontal + 2 backend-api containers actif/actif (sticky WS)
- CDN edge externe (Cloudflare R2 + Workers OU Bunny.net) câblé
- OpenTelemetry collector → Tempo (traces visibles)
- Loki HA 3 réplicas + S3 backend (sur ton MinIO)
- SLO burn-rate alerts (remplacement seuils statiques)
- Backup restore drill automatisé hebdo
- Synthetic monitoring (blackbox exporter rejouant les 6 parcours)
- Game day #1 réalisé + runbooks testés
- Canary release script

**Légal**
- Terms of Service (avocat-revu)
- Privacy Policy RGPD + CCPA + DPA template processeurs
- DMCA notice + agent enregistré
- DSA point de contact + transparency report template
- CGV vendeur marketplace
- Mentions légales + politique cookies + bannière consentement

**Sécurité**
- Pentest externe rapport reçu, 0 critique/haut ouvert
- Secrets hors git (Vault sur conteneur Incus OU sops/age versionné)
- Rotation OAuth secrets effectuée
- JWT RS256 prod (déjà en place — vérifier rotation key)

**Business**
- Stripe live mode actif + KYC créateurs testé E2E avec vrais fonds
- Hyperswitch live mode actif + flux paiement E2E réel
- Email transactionnel sur domaine custom (SPF/DKIM/DMARC OK)
- 5-10 testeurs beta privée semaines 5-6 avec retours documentés

### OUT (deferred post-launch v1.1+)

- **Native mobile (iOS/Android)** — Capacitor wrap après launch (~3 semaines)
- **Audio fingerprinting (Chromaprint)** — DMCA workflow MANUEL au launch ; fingerprinting v1.1
- **Public API SDK** (`@veza/sdk-js`, `@veza/sdk-py`) + dev portal v2 — v1.1
- **OAuth2 client credentials** + rate limit tiers per-app — v1.1
- **Multi-region failover** — single region (R720 + Hetzner debordement) au launch
- **Tipping / fan support** — décision business post-launch
- **Distribution intégrale DSP** (TuneCore, CD Baby, etc.) — v1.1
- **Subscription per-creator (Patreon-style)** — v1.1+
- **CarPlay / Android Auto** — nécessite app native d'abord
- **Lossless tier FLAC subscriber** — codec déjà supporté, exposer post-launch
- **"Fresh from your follows" tab discovery** — déferred (chronologique du feed suffit au launch)
- **Editorial collections admin UI** — défferred (curation manuelle DB au launch)
- **Faceted search saved searches** — UI faceted suffit, "saved" v1.1

### COMPRESSED (livré mais minimum viable, à durcir post-launch)

- **MinIO erasure-coded** : 4 nœuds EC4+2 mais sur la même machine R720 (pas vraiment HA matériel — ajoute Hetzner storage post-launch)
- **HAProxy sticky WS** : 2 backend-api sur la même machine R720 (pas N+1 hardware HA)
- **Loki HA** : 3 réplicas en conteneurs Incus mais sur le même hôte (single-host failure mode, accepté pour launch)
- **DMCA workflow** : workflow complet + agent enregistré, MAIS audit fingerprinting reporté → take-down purement humain
- **Pentest** : externe mais light scope (auth + paiement + DMCA + uploads), pas full deep dive
- **Game day** : 1 game day cycle complet, pas 3 cycles répétés

---

## 3. Critical path & dépendances

```
    EX-1 légal ──────────────────────────────▶ EX week 5 signature ──▶
    EX-2 pentest ────────────────────▶ EX week 4 exec ──▶ rapport week 6
    EX-9 stripe live ────────▶ KYC ──▶ test E2E vrais fonds week 5
    EX-10 email custom ──────▶ DKIM/SPF prop ────▶ délivrabilité week 4

    Code:
    W1 finir v1.0.9 + IaC ──▶ W2 Postgres HA + obs ──▶ W3 stockage + features ──▶
    W4 PWA + search + load test ──▶ W5 game day + canary ──▶ W6 go-live
```

**Top-3 risques de glissement** :
1. **Légal** : si EX-1 traîne, on tag mais on ne lance pas. Démarre lundi.
2. **Pentest findings critiques** : si le pentest revèle un finding HIGH semaine 6, on rétrograde de tag et on patch — peut décaler 1-2 semaines. Mitigation : faire un pentest interne semaine 4 (ZAP + nuclei + manual audit) pour pré-filtrer.
3. **Postgres HA failover en game day rouge** : si le failover n'atteint pas RTO < 60s on doit ré-architecturer. Mitigation : tester pg_auto_failover en lab Incus dès semaine 1.

---

## 4. Sprint breakdown — jour par jour

> **Convention** : chaque jour = ~6-8h productives. Acceptance criteria
> mesurables. Si un jour déborde, le suivant glisse — pas de "je
> rattraperai le week-end" autorisé sinon le burn-out garantit le slip
> de 2 semaines fin de roadmap.

### Semaine 1 — Closer v1.0.9 + amorçage IaC

**Objectif** : tag v1.0.9, scaffolding Ansible posé, Postgres HA en lab.

#### Jour 1 — Lundi : Démarrer les externes + commit sprint 1
- **AM** : Envoyer EX-1 (avocat), EX-2 (devis pentest), EX-3 (DMCA agent), EX-9 (Stripe KYC), EX-10 (email transactionnel). Ces 5 emails partent avant midi.
- **PM** : Commit + push les 4 commits préparés (`/tmp/v1.0.9-commit-messages.md`). Vérifier CI Forgejo verte. Si rouge → debug avant de continuer.
- **Acceptance** : 5 emails envoyés, 4 commits pushés, CI verte sur main.
- **Files** : `/tmp/v1.0.9-commit-messages.md`

#### Jour 2 — Mardi : Item G subscription Phase 2
- Webhook handler `subscription.payment_succeeded` / `payment_failed` dans `internal/services/hyperswitch/webhook_subscription.go`
- Dispatcher dans `ProcessPaymentWebhook` qui détecte le type subscription et route
- Reuse `webhook_raw_payloads` table (item E v1.0.7) pour persistence
- Tests : webhook arrive → row pending_payment → active. Webhook payment_failed → expired.
- **Acceptance** : 4 tests unitaires verts (success, failed, replay idempotent, unknown event)
- **Files** : `internal/services/hyperswitch/webhook_subscription.go` (nouveau), `internal/services/hyperswitch/webhook_subscription_test.go` (nouveau)

#### Jour 3 — Mercredi : Item G subscription Phase 3 + E2E
- Endpoint recovery `POST /api/v1/subscriptions/complete/:id` qui retourne le `client_secret` Hyperswitch pour reprendre un paiement stalled
- Distribution gate : `distribution.checkEligibility` traite `pending_payment` comme ineligible
- E2E `@critical` `tests/e2e/subscription-pending-payment.spec.ts` : subscribe paid plan → distribution submit retourne 403 → simuler webhook → distribution OK
- Remove `TODO(v1.0.7-item-G)` annotation dans `subscription/service.go`
- **Acceptance** : E2E vert + grep TODO Item G = 0 hit
- **Files** : `internal/handlers/subscription_handler.go`, `internal/api/routes_subscription.go`, `internal/core/distribution/service.go`, `tests/e2e/28-subscription-pending-payment.spec.ts`

#### Jour 4 — Jeudi : Item 1.7 flake stab + tag v1.0.9
- Lire les rapports CI Forgejo des 5 derniers runs E2E sur main
- Identifier flakes : tests qui ont failé puis passé sans changement code
- Stabiliser : remplacer `waitForTimeout` par `waitFor` ciblés, ajouter retry-on-flake helpers, augmenter `expect.timeout` ciblé
- 3 cycles E2E nightly verts consécutifs avant tag
- **Acceptance** : 3 nightly E2E verts, `git tag v1.0.9` poussé
- **Files** : `tests/e2e/*.spec.ts` (stabilisations ciblées), `tests/e2e/playwright.config.ts` (timeout ciblé si nécessaire)

#### Jour 5 — Vendredi : IaC scaffolding Ansible
- Créer `infra/ansible/` avec layout standard : `inventory/`, `group_vars/`, `host_vars/`, `roles/`, `playbooks/`
- Inventaire : 1 host R720 prod + 1 host Hetzner staging + 1 host R720 lab
- Rôle `common` : SSH hardening, fail2ban, unattended-upgrades, monitoring agent
- Rôle `incus_host` : install Incus + configuration networking
- Test : déployer le rôle common sur le host lab
- **Acceptance** : `ansible-playbook -i inventory/lab playbooks/site.yml --check` passe sans erreur
- **Files** : `infra/ansible/inventory/{lab,staging,prod}.yml`, `infra/ansible/playbooks/site.yml`, `infra/ansible/roles/common/tasks/main.yml`, `infra/ansible/roles/incus_host/tasks/main.yml`, `infra/ansible/README.md`

**Verification gate W1** : tag v1.0.9 poussé, Ansible scaffolding fonctionne en lab, externes EX-1 à EX-10 démarrés.

---

### Semaine 2 — Postgres HA + observabilité

**Objectif** : Postgres failover automatique testé, OpenTelemetry collector wired, SLO alerts définies.

#### Jour 6 — Lundi : Postgres HA — pg_auto_failover lab
- Rôle Ansible `postgres_ha` : 2 conteneurs Incus (primary + replica), pg_auto_failover monitor
- Configuration : sync replication, HOT_STANDBY, max_wal_senders, etc.
- Test : kill primary, vérifier failover automatique en < 60s, vérifier replica devient primary
- **Acceptance** : failover test scripté `infra/ansible/tests/test_pg_failover.sh` rouge avant fix, vert après. RTO mesuré < 60s.
- **Files** : `infra/ansible/roles/postgres_ha/{tasks,templates,defaults}/`, `infra/ansible/tests/test_pg_failover.sh`

#### Jour 7 — Mardi : PgBouncer + connection pool
- Rôle Ansible `pgbouncer` : conteneur Incus avec PgBouncer en transaction mode
- Pool size : 50 server connections × 1000 client connections capacity
- Backend-api config : `DATABASE_URL` pointe vers PgBouncer, pas direct Postgres
- Load test : 500 connexions concurrentes simulées via `pgbench`, vérifier pas d'épuisement
- **Acceptance** : pgbench 500 clients × 30s sans erreur de connexion
- **Files** : `infra/ansible/roles/pgbouncer/{tasks,templates}/`, `veza-backend-api/internal/config/config.go` (URL pointe PgBouncer en prod)

#### Jour 8 — Mercredi : pgBackRest + restore drill
- Rôle Ansible `pgbackrest` : install + configuration WAL archive vers MinIO bucket dédié
- Backup full hebdo + différentiels quotidiens + WAL continu
- Script `scripts/dr-drill.sh` : restore le dernier full+WAL dans un conteneur éphémère, lance `cmd/tools/seed --ci` partial check, assertion `SELECT count(*) FROM users > 0`
- Cron hebdo qui execute le script + alerte Prometheus si fail
- **Acceptance** : `bash scripts/dr-drill.sh` passe vert localement
- **Files** : `infra/ansible/roles/pgbackrest/{tasks,templates}/`, `scripts/dr-drill.sh`, `config/prometheus/alert_rules.yml` (ajout `BackupRestoreDrillFailed`)

#### Jour 9 — Jeudi : OpenTelemetry collector + Tempo
- Rôle Ansible `otel_collector` : conteneur OpenTelemetry collector (config receivers + processors + exporters)
- Conteneur Tempo (Grafana stack) pour stocker les traces
- Backend-api : exporter OTLP vers le collector (déjà câblé en émetteur, juste activer le wire)
- Instrumenter 4 hot paths : auth login, track upload (chunked init/chunk/complete), payment webhook, search
- Dashboard Grafana basique avec service map + p99 par endpoint
- **Acceptance** : tracer une requête login → voir le span dans Tempo UI
- **Files** : `infra/ansible/roles/otel_collector/`, `config/otel/collector-config.yaml`, `veza-backend-api/internal/tracing/otlp_exporter.go` (nouveau ou extension), `config/grafana/dashboards/service-map.json`

#### Jour 10 — Vendredi : SLO burn-rate alerts + runbooks
- Définir 3 SLO dans `config/prometheus/slo.yml` :
  - `SLO_API_AVAILABILITY` : 99.5% sur `/api/v1/health` + endpoints lecture
  - `SLO_API_LATENCY` : 99% p95 < 500ms sur endpoints écriture
  - `SLO_PAYMENT_SUCCESS` : 99.5% des `/api/v1/orders` POST → 201
- Multi-window burn-rate alerts (fast 1h burn 14.4× → page, slow 6h burn 6× → ticket)
- Annotations `runbook_url` sur chaque alert pointant `docs/runbooks/<alert-name>.md`
- Squelette runbooks pour les 6 alerts les plus probables
- **Acceptance** : `promtool check rules config/prometheus/slo.yml` vert, dashboard Grafana SLO visible avec error budget tracking
- **Files** : `config/prometheus/slo.yml`, `config/alertmanager/routes.yml` (acheminement page vs ticket), `docs/runbooks/{api-availability-slo-burn,payment-success-slo-burn,db-failover,redis-down,disk-full,cert-expiring-soon}.md`

**Verification gate W2** : `pg_auto_failover` test rouge → vert, `pgbench` 500 connections OK, traces visibles dans Tempo, SLO burn-rate alerts définies + runbooks indexés.

---

### Semaine 3 — Stockage HA + features signature

**Objectif** : MinIO erasure-coded, CDN edge wired, embed widget + DMCA workflow + track sharing.

#### Jour 11 — Lundi : Redis Sentinel HA + cache metrics
- Rôle Ansible `redis_sentinel` : 3 conteneurs Incus (1 master + 2 replicas + 3 sentinels colocated)
- Backend-api : `RedisClient` switch vers `NewFailoverClient` avec MasterName + SentinelAddrs
- Cache hit rate metrics : ajouter compteurs Prometheus dans rate limiter, chat pubsub, presence
- Test : kill Redis master, vérifier promotion automatique d'un replica en < 30s
- **Acceptance** : failover Redis test rouge → vert, dashboard Grafana avec hit rate par service
- **Files** : `infra/ansible/roles/redis_sentinel/`, `veza-backend-api/internal/config/config.go` (Sentinel config), `veza-backend-api/internal/metrics/cache_hit_rate.go` (nouveau)

#### Jour 12 — Mardi : MinIO distribué + migration
- Rôle Ansible `minio_distributed` : 4 conteneurs Incus en pool EC4+2 (résiste perte 2 conteneurs sans data loss)
- Configuration : bucket `veza-prod-tracks`, lifecycle policy (versioning 30j, Glacier après 90j)
- Migration depuis le single-node actuel via `mc mirror veza-current/ veza-distributed/`
- Backend-api : pas de changement code (interface S3 reste identique)
- Smoke test : upload 100MB via `mc cp`, kill 2 nœuds, vérifier read OK, restart nœuds, vérifier rebuild
- **Acceptance** : EC4+2 résiste à 2 nœud kills, dashboard MinIO healthcheck vert
- **Files** : `infra/ansible/roles/minio_distributed/{tasks,templates}/`

#### Jour 13 — Mercredi : CDN edge externe (Cloudflare R2 ou Bunny.net)
- Choisir : Cloudflare R2 (gratuit 10GB, $0.015/GB stockage, $0/GB egress) OU Bunny.net Stream ($0.005/GB egress audio)
- Configurer compte + bucket + cache rules + signed URL
- Câbler `internal/services/cdn_service.go` (déjà existant) pour générer URLs CDN au lieu de MinIO direct
- Trackservice `GetStorageURL` : retourner CDN signed URL pour les routes publiques (stream, download)
- Cache headers backend-api : Cache-Control: public, max-age=86400, immutable pour les segments HLS
- Test : upload track, lire via /tracks/:id/stream → assert URL = `cdn.veza.fr/...`
- **Acceptance** : 1 track lue via CDN edge, latence first byte < 200ms depuis 3 PoPs
- **Files** : `veza-backend-api/internal/services/cdn_service.go` (extend), `veza-backend-api/internal/core/track/service.go` (GetStorageURL hook CDN), `infra/ansible/roles/backend_api/templates/.env.j2` (env vars CDN)

#### Jour 14 — Jeudi : DMCA notice handler + workflow
- Migration `987_dmca_notices.sql` : table `dmca_notices` (id, status, claimant_email, claimant_name, claimant_address, work_description, infringing_track_id, sworn_statement_at, status, takedown_at, counter_notice_at, restored_at, audit_log)
- Handler `internal/handlers/dmca_handler.go` :
  - `POST /api/v1/dmca/notice` : public, rate-limited (5/IP/h), validate fields, enregistre `pending`
  - `GET /api/v1/admin/dmca/notices` : admin-only, queue + pagination
  - `POST /api/v1/admin/dmca/notices/:id/takedown` : admin action → set `status=takedown`, set `takedown_at=NOW()`, mark track `is_public=false` + `dmca_blocked=true`
  - `POST /api/v1/admin/dmca/notices/:id/dismiss` : admin action → set `status=rejected`
- Page publique frontend `/legal/dmca` avec formulaire + agent désigné info
- Audit log dans `audit_logs` (existing v0.803 SEC2)
- **Acceptance** : E2E `tests/e2e/29-dmca-notice.spec.ts` vert (notice → admin queue → takedown → track plus accessible)
- **Files** : `veza-backend-api/migrations/987_dmca_notices.sql` + rollback, `veza-backend-api/internal/handlers/dmca_handler.go` (nouveau), `veza-backend-api/internal/api/routes_legal.go` (nouveau), `apps/web/src/features/legal/pages/DmcaNoticePage.tsx` (nouveau), `tests/e2e/29-dmca-notice.spec.ts`

#### Jour 15 — Vendredi : Embed widget + oEmbed + track share tokens
- Route backend `GET /embed/track/:id` : retourne page HTML standalone (pas le SPA, page minimaliste avec player + waveform SVG)
- Route backend `GET /oembed?url=<track_url>&format=json` : réponse oEmbed standard (type=rich, html=`<iframe src="...">`)
- Open Graph tags dynamiques sur `/tracks/:id` (SSR mini ou meta runtime)
- Migration `988_track_share_tokens.sql` : table `track_share_tokens` (id, track_id, token UUID, expires_at NULLABLE, created_by_user_id)
- Handler `POST /api/v1/tracks/:id/share-tokens` (création) + `GET /api/v1/tracks/share/:token` (lecture)
- Test : créer share token → fetch via token → assert track lisible même si is_public=false
- **Acceptance** : embed iframe Twitter card preview OK, oEmbed JSON valide, share token E2E vert
- **Files** : `veza-backend-api/internal/handlers/embed_handler.go` (nouveau), `veza-backend-api/internal/handlers/oembed_handler.go` (nouveau), `veza-backend-api/migrations/988_track_share_tokens.sql` + rollback, `apps/web/embed/track.html` (template standalone), `tests/e2e/30-embed-and-share.spec.ts`

**Verification gate W3** : Redis HA failover OK, MinIO EC4+2 résiste 2 kills, 1 track lue via CDN, DMCA notice E2E vert, embed widget Twitter card preview verte, share token fonctionne.

---

### Semaine 4 — PWA mobile + HLS default + faceted search + load test

**Objectif** : expérience mobile aboutie, HLS ABR par défaut, recherche faceted, capacité validée 1k VU.

#### Jour 16 — Lundi : Service worker offline track cache (Workbox)
- Activer service worker en prod (déjà câblé `pwa.ts:48-56`)
- Workbox stratégies :
  - Static assets : `StaleWhileRevalidate`
  - HLS segments : `CacheFirst` avec max-age 7j, max 50 entries
  - API calls : `NetworkFirst` avec timeout 5s
- Cache offline track : intercepter les fetch `/api/v1/tracks/:id/stream` redirigés vers CDN, cacher les segments HLS du track en cours + les 50 derniers favoris
- Background sync API pour les actions hors-ligne (like, comment) qui rejouent au retour réseau
- Test : devtools network offline mode, jouer un track déjà écouté, doit fonctionner
- **Acceptance** : test manuel offline OK, Lighthouse PWA score ≥ 90
- **Files** : `apps/web/src/sw.ts` (extend Workbox config), `apps/web/src/services/offlineQueue.ts` (extend pour background sync)

#### Jour 17 — Mardi : HLS par défaut + lossless tier preview
- Flip `HLS_STREAMING=true` dans `.env.production`
- Smoke test : upload track, vérifier que le transcode HLS s'execute, vérifier ABR sur le frontend (`useHLSPlayer` hook)
- Pre-listen 30s public sur les produits marketplace : extend `marketplace.go:258-298` pour les tracks publics si créateur opt-in
- FLAC tier preview : ajouter une checkbox "FLAC available" sur la page upload pour les Premium subscribers (visible mais reporté post-launch pour la consommation effective)
- **Acceptance** : nouveau track uploadé sert HLS ABR (3 niveaux 128/256/320), Network panel devtools confirme switch ABR sur réseau dégradé
- **Files** : `infra/ansible/roles/backend_api/templates/.env.j2` (HLS_STREAMING=true), `apps/web/src/features/upload/components/UploadForm.tsx` (FLAC checkbox)

#### Jour 18 — Mercredi : Faceted search UI
- Composant `apps/web/src/features/search/components/FacetSidebar.tsx` : sidebar avec filtres genre / BPM range / musical_key / year / type (track/playlist/user)
- Wire avec orval-generated `useGetSearch` hook : passer `params.type[]`, query params custom pour bpm_min/max
- Backend : étendre `search_handlers.go:Search` pour accepter `bpm_min`, `bpm_max`, `musical_key`, `year_from`, `year_to` (déjà partiellement supportés via SearchService)
- Test : recherche "rock" + filtre BPM 120-130 → résultats restreints
- **Acceptance** : E2E `tests/e2e/31-faceted-search.spec.ts` vert
- **Files** : `apps/web/src/features/search/components/FacetSidebar.tsx` (nouveau), `apps/web/src/features/search/pages/search-page/SearchPage.tsx` (intégration), `veza-backend-api/internal/handlers/search_handlers.go` (extend params), `veza-backend-api/internal/services/search_service.go` (extend filter SQL), `tests/e2e/31-faceted-search.spec.ts`

#### Jour 19 — Jeudi : HAProxy sticky WS + 2 backend-api actif/actif
- Rôle Ansible `haproxy` : conteneur HAProxy avec config `frontend tls / backend api_pool` + sticky cookie sur les routes WS
- Backend-api : déployer 2 conteneurs Incus actif/actif derrière HAProxy. Stateless OK (sessions Redis-backed déjà câblé).
- Health check `/api/v1/health` toutes les 5s, drain 30s avant remove
- Test : kill backend-api 1, vérifier HAProxy bascule, vérifier sessions WS reconnectent au backend-api 2 sans perte de message
- Stream-server : 2 conteneurs avec affinité sticky par `track_id` hash (HLS cache local optimisé)
- **Acceptance** : test scripté `infra/ansible/tests/test_backend_failover.sh` vert
- **Files** : `infra/ansible/roles/haproxy/{tasks,templates}/`, `infra/ansible/roles/backend_api/tasks/main.yml` (multi-instance), `infra/ansible/tests/test_backend_failover.sh`

#### Jour 20 — Vendredi : Load test k6 nightly + capacity validation
- Compléter `scripts/loadtest/k6_load_test.js` avec scénarios mix réalistes :
  - 100 VU upload concurrent (10MB tracks)
  - 500 VU streaming HLS (segments fetch)
  - 1000 VU search + browse mixte
  - 50 VU checkout marketplace
  - Threshold p95 < 500ms global, error rate < 0.5%
- Workflow CI nightly `.github/workflows/loadtest.yml` qui lance k6 sur staging
- Profiling pprof endpoints lents identifiés
- Capacité validée : 1k users concurrents tenus sur 1 R720 sans saturation
- **Acceptance** : nightly load test passe vert pendant 3 nuits consécutives, dashboard Grafana avec p95/p99 par endpoint
- **Files** : `scripts/loadtest/k6_*.js`, `.github/workflows/loadtest.yml` (nouveau), `docs/PERFORMANCE_BASELINE.md` (update avec chiffres réels)

**Verification gate W4** : Lighthouse PWA ≥ 90, HLS ABR par défaut OK, faceted search E2E vert, HAProxy failover OK, k6 nightly 1k VU green 3 nuits.

---

### Semaine 5 — Pentest + game day + canary + status page

**Objectif** : pentest exécuté, game day rejoué et runbooks validés, canary release process automatisé, status page publique.

#### Jour 21 — Lundi : Pré-flight pentest interne (avant le pentest externe)
- Lancer ZAP automated scan sur staging : `docker run -v $(pwd):/zap/wrk owasp/zap2docker-stable zap-baseline.py -t https://staging.veza.fr`
- Lancer nuclei : `nuclei -u https://staging.veza.fr -t cves/ -t vulnerabilities/ -t exposures/`
- Manual audit OWASP Top 10 sur les nouveaux endpoints v1.0.9 :
  - `/api/v1/dmca/notice` : XSS via work_description, SSRF via URLs, CSRF
  - `/embed/track/:id` : XSS via track metadata
  - `/api/v1/config/webrtc` : disclosure (rappel : volontairement public)
  - `/api/v1/tracks/share/:token` : enumeration timing
- Fix les findings HIGH internes avant l'externe
- **Acceptance** : 0 finding HIGH dans le rapport ZAP/nuclei, manual audit issues fixées ou justifiées
- **Files** : `docs/SECURITY_PRELAUNCH_AUDIT.md` (nouveau, avec findings + résolutions)

#### Jour 22 — Mardi : Game day #1 — failures simulées
- Scénario A : kill primary Postgres pendant 5min, vérifier failover < 60s + apps reconnectent
- Scénario B : kill HAProxy backend-api 1, vérifier autres backends servent + WS clients reconnect
- Scénario C : kill Redis sentinel master, vérifier promotion replica + chat continue
- Scénario D : saturate disque MinIO 95%, vérifier alertes + degraded write mode
- Scénario E : RabbitMQ down 30min, vérifier event bus log error loud + queue mémoire fallback
- Documenter chaque incident dans `docs/runbooks/game-days/2026-W5-game-day-1.md` : timestamp, action, observation, runbook utilisé, gap découvert
- **Acceptance** : aucun silent fail, aucune 5xx > 30s post-incident, chaque alert Prometheus déclenchée < 1min
- **Files** : `docs/runbooks/game-days/2026-W5-game-day-1.md` (nouveau), `docs/runbooks/<alert-name>.md` (mises à jour selon gaps trouvés)

#### Jour 23 — Mercredi : Canary release process
- Script `scripts/deploy-canary.sh` :
  1. Pull nouvelle image backend-api
  2. Désactiver backend-api 2 dans HAProxy (drain mode)
  3. Déployer nouvelle image sur backend-api 2
  4. Health check : `curl https://api.veza.fr/api/v1/health` doit return 200
  5. Re-enable backend-api 2 dans HAProxy
  6. Monitor pendant 1h : SLI doivent rester verts (p95 < 500ms, err rate < 0.5%)
  7. Si SLI vert : repeat sur backend-api 1 (full deploy)
  8. Si SLI rouge : rollback automatique (re-déployer ancienne image)
- Pre-deploy hook : check migrations DB sont backward-compatible (nouveau schema doit fonctionner avec ancienne version code)
- Documentation `docs/CANARY_RELEASE.md`
- Test : faire 3 canary deploys sur staging avec rollback simulé
- **Acceptance** : 3 canary deploys réussis (2 normaux + 1 avec rollback simulé volontaire)
- **Files** : `scripts/deploy-canary.sh` (nouveau), `docs/CANARY_RELEASE.md` (nouveau), `Makefile` (target `deploy-canary`)

#### Jour 24 — Jeudi : Status page + synthetic monitoring
- Setup status page : Cachet (self-hosted) sur conteneur Incus OU statuspage.io free tier
- Composants à monitor : API, Stream, Chat, Marketplace, Live, CDN
- Endpoint `GET /api/v1/status` public qui retourne `{status: "operational"|"degraded"|"down", components: {...}}` (utilisé par la status page + supervision)
- Synthetic monitoring : Blackbox exporter Prometheus rejouant 6 parcours toutes les 5min depuis un Incus externe (hors-réseau prod) :
  - Register → verify → login
  - Login → search "test" → play first result
  - Login → upload tiny audio → poll status
  - Login → browse marketplace → add to cart
  - WebSocket chat connect + send message
  - Live stream metadata fetch
- Alert Prometheus si parcours fail 2 fois consécutives
- **Acceptance** : status page accessible sur `status.veza.fr`, synthetic monitoring vert sur 6 parcours pendant 24h
- **Files** : `infra/ansible/roles/cachet/` (si self-hosted), `veza-backend-api/internal/handlers/status_handler.go` (nouveau), `infra/ansible/roles/blackbox_exporter/`, `config/prometheus/blackbox_targets.yml`

#### Jour 25 — Vendredi : Pentest externe kick-off + buffer
- Briefer le pentester (selon EX-2) : scope auth + paiement + DMCA + uploads + WebRTC + embed widget. Donner accès staging dédié avec données pré-seed.
- Le pentest s'exécute en async semaine 5 et début semaine 6.
- Buffer day pour rattraper les retards des jours 21-24 + tester le canary process une fois encore.
- Si tout est en avance : commencer 2.7 (rate limit tiers per-app) en avance sur la semaine 6.
- **Acceptance** : pentester actif, staging accessible, runbooks à jour
- **Files** : `docs/PENTEST_SCOPE_2026.md` (nouveau, brief technique pour le pentester)

**Verification gate W5** : pentest interne 0 HIGH, game day documenté avec 0 silent fail, 3 canary deploys verts, status page publique, synthetic monitoring vert 24h.

---

### Semaine 6 — GO/NO-GO + go-live

**Objectif** : tout le checklist GO/NO-GO vert, soft launch beta privée, public launch.

#### Jour 26 — Lundi : GO/NO-GO checklist final pass
- Réutiliser et faire passer en vert `docs/GO_NO_GO_CHECKLIST_v1.0.0.md` mais cible **v2.0.0-public** :
  - **Sécurité** : pentest 0 critique/haut, JWT RS256 prod ✓, secrets hors git ✓
  - **Stabilité** : uptime ≥ 99.9% staging 30j (vérifier dashboards), taux 5xx < 0.1%, 0 incident P0 ouvert
  - **Performance** : p95 API < 100ms, Lighthouse perf ≥ 85, a11y ≥ 90, PWA ≥ 90
  - **Qualité** : coverage ≥ 70%, 0 lint, CI verte 2 sem
  - **Éthique** : audit anti-dark-pattern (relire `ORIGIN_UI_UX_SYSTEM.md` §13), 0 ML reco, feed chronologique, algo découverte documenté
  - **Business** : flow paiement E2E réel testé (jour 27), KYC vendeur testé E2E, support accessible
- Documenter chaque ligne avec preuve (lien dashboard, commit, test passing)
- Lister les RED items avec plan de remédiation jour 27-28
- **Acceptance** : checklist exhaustive, RED items < 3 et tous remédiables d'ici jour 28
- **Files** : `docs/GO_NO_GO_CHECKLIST_v2.0.0_PUBLIC.md` (nouveau, dérivé du v1.0.0)

#### Jour 27 — Mardi : Test E2E paiement réel + remediation RED items
- AM : Stripe live mode + Hyperswitch live actifs (selon EX-9), faire un vrai achat marketplace (5€ produit test) avec ta propre carte. Vérifier : webhook reçu, license attribuée, vendeur Connect crédité, payout planifié, refund possible.
- PM : remediation RED items du checklist GO/NO-GO. Si > 5 RED items, escalade : décaler le launch d'1 semaine.
- **Acceptance** : 1 achat E2E réel avec vrais fonds, refund testé, RED items 0
- **Files** : `docs/PAYMENT_E2E_LIVE_REPORT.md` (nouveau, traces de la transaction live)

#### Jour 28 — Mercredi : Game day #2 + canary deploy prod
- Game day #2 : rejouer les 5 scénarios du jour 22 sur prod (avec maintenance window 1h annoncée). Cible : tout vert sans intervention manuelle, runbooks validés.
- Canary deploy prod : déployer la version v2.0.0-rc1 sur le R720 prod via le script du jour 23. Soak test 4h, vérifier SLI verts.
- Annonce interne (Discord/Slack équipe) que prod est sur v2.0.0-rc1.
- **Acceptance** : game day prod vert, canary deploy v2.0.0-rc1 vert, soak 4h vert
- **Files** : `docs/runbooks/game-days/2026-W6-game-day-2.md`, `docs/RELEASE_NOTES_V2.0.0_RC1.md`

#### Jour 29 — Jeudi : Soft launch beta privée
- Inviter 50-100 testeurs (mailing list pré-launch, contacts perso, communautés musicales sélectives)
- Email d'invitation avec lien d'inscription + code beta + form Typeform de feedback
- Monitor en temps réel : status page, Grafana dashboards, Sentry frontend errors, support inbox
- Documenter chaque issue rapportée → triage HIGH/MED/LOW
- HIGH issues fixées le jour même, MED le lendemain, LOW backlog post-launch
- **Acceptance** : 50+ testeurs onboardés, < 3 HIGH issues, monitoring vert
- **Files** : `docs/SOFT_LAUNCH_BETA_2026.md` (rapport feedback consolidé)

#### Jour 30 — Vendredi : Public launch
- AM : final pre-launch checklist :
  - Status page tout vert
  - Game day #2 runbook signed off
  - Pentest report reçu, 0 critique/haut ouvert (ou risques accepted documentés)
  - Légal signé : ToS, Privacy, DMCA agent enregistré
  - Soft launch beta : 0 HIGH issue ouverte
- PM : `git tag v2.0.0` + push, annonce publique (réseaux sociaux, Hacker News, communautés musicales, Product Hunt prep)
- DNS : couper la maintenance page, ouvrir le trafic public
- War room ouvert (Discord/Slack) pour les 48h post-launch
- **Acceptance** : v2.0.0 tagué, publication publique, monitoring actif 24h
- **Files** : `CHANGELOG.md` (entry v2.0.0), `docs/RELEASE_NOTES_V2.0.0.md`, `docs/POST_LAUNCH_RUNBOOK.md`

**Verification gate W6 = LAUNCH** : tag v2.0.0 poussé, trafic public ouvert, monitoring vert 24h, war room actif.

---

## 5. Post-launch immédiat (D+1 à D+7)

| Jour | Action | Owner |
|------|--------|-------|
| D+1 | War room actif, monitor toutes les 30min, daily standup interne | toi |
| D+2 | Premier patch release v2.0.1 si HIGH issues remontées | toi |
| D+3 | Post-mortem du launch : ce qui a bien marché, ce qui a cassé | toi |
| D+5 | Annonce status : "X users, Y tracks, Z transactions, uptime A%" | toi |
| D+7 | Démarrer v2.1 — backlog post-launch (Capacitor mobile, fingerprinting, distribution DSP) | toi |

---

## 6. Risk register

| # | Risque | Proba | Impact | Mitigation | Owner |
|---|--------|-------|--------|------------|-------|
| R-1 | Légal traîne au-delà de semaine 5 | M | HIGH | Démarrer EX-1 jour 1, relancer chaque semaine, ToS template open-source en backup (`commonsclause-style`) | toi |
| R-2 | Pentest finding CRITICAL semaine 6 | M | CRITICAL | Pentest interne semaine 5 jour 21 pour pré-filtrer, budget 3-5j patch reserve semaine 6 | toi |
| R-3 | Postgres failover ne tient pas RTO < 60s | L | HIGH | Tester en lab dès jour 6, fallback : monitor + alert + manual failover documenté (RTO ~5min) | toi |
| R-4 | Item G subscription bug en prod (paiement réel) | L | CRITICAL | E2E `@critical` + manual smoke jour 27 + reconciliation worker (déjà v1.0.7) catch les drifts | toi |
| R-5 | Coturn deploy raté (NAT/UDP forwarding) | M | MED | Tester en sandbox semaine 1-2 (lab Incus), fallback : STUN seul pour launch + advisory UI | toi |
| R-6 | CDN coûts explosent au launch (audio bandwidth) | M | MED | Bunny.net (~5 €/TB) plus prévisible que Cloudflare R2 ($/GB), monitoring bandwidth daily | toi |
| R-7 | Soft launch beta trouve un vrai bug bloquant | H | HIGH | Buffer jour 27 PM + jour 28, max 3 HIGH issues acceptables | toi |
| R-8 | DDoS / abuse au launch | M | MED | Rate limits déjà en place v0.803, Cloudflare proxy en option pour absorption L7 | toi |
| R-9 | Dette technique remonte (CI rouge, flake) | H | LOW | Buffer 20% dans chaque journée, git revert prêt si une feature sabote l'ensemble | toi |
| R-10 | Burnout / décrochage perso | M | CRITICAL | Pas de week-end de "rattrapage", buffer ½ journée par sem, scope-creep refusé | toi |

---

## 7. Defended scope — ce qu'on REFUSE pendant les 6 semaines

Si pendant les 6 semaines tu te poses la question "devrais-je rajouter
X au scope launch", la réponse par défaut est **non, post-launch**.

Liste explicite des refus pré-approuvés :

- **Native mobile (iOS/Android)** — REFUS. Capacitor wrap post-launch, ~3 sem.
- **Audio fingerprinting** — REFUS. DMCA workflow manuel suffit. Chromaprint v1.1.
- **Public API SDK** — REFUS. API key + webhooks v0.803 restent. SDK v1.1.
- **OAuth2 client credentials** — REFUS. v1.1.
- **Multi-region failover** — REFUS. R720 + Hetzner standby suffit. v1.2.
- **Tipping / fan support** — REFUS. Décision business post-launch.
- **Distribution DSP** (TuneCore/CD Baby) — REFUS. v1.1.
- **Subscription per-creator** (Patreon-style) — REFUS. v1.1+.
- **CarPlay / Android Auto** — REFUS. Nécessite app native.
- **Lossless tier FLAC consommation** — REFUS UI complète. Codec exposé en upload form, consommation v1.1.
- **"Fresh from your follows" tab** — REFUS. Filtre chronologique simple suffit.
- **Editorial collections admin UI** — REFUS. Curation manuelle DB suffit.
- **Saved searches** — REFUS. Faceted search UI suffit.
- **PWA push notifications custom** — REFUS extends. Le push existant v0.302 N1 suffit.
- **Light/dark theme switcher avancé** — REFUS. Le `prefers-color-scheme` actuel suffit.
- **Internationalisation full** — REFUS extends. FR + EN au launch (déjà v0.12.7).
- **Accessibility AAA** — REFUS. AA suffit (déjà v0.12.6).
- **GraphQL API** — REFUS jamais (pas dans la stack).
- **Migration vers cloud managed** — REFUS. Self-hosted Incus est le choix.

Si quelqu'un te pousse à ajouter du scope, refer ce document.

---

## 8. Definition of "Production Ready" — critères absolus

Au tag v2.0.0 le **8 juin 2026** (jour 30 = vendredi semaine 6), Veza
DOIT remplir tous les critères suivants :

### Sécurité (5 critères)
- [ ] JWT RS256 prod, clés rotées récemment (< 90j)
- [ ] Secrets hors git (Vault ou sops/age)
- [ ] Pentest externe rapport reçu, 0 finding critique/haut ouvert (HAUT moyens acceptés documentés)
- [ ] Rate limits prod actifs (1000/s global, 100/IP/s)
- [ ] HTTPS partout, HSTS preload submitted, certs auto-renouvellement

### Stabilité (5 critères)
- [ ] Postgres HA failover testé (RTO < 60s) sur staging ET prod
- [ ] Redis Sentinel failover testé
- [ ] Backup restore drill cron passe vert depuis 7j consécutifs
- [ ] Game day #1 + #2 documentés, runbooks signés
- [ ] Canary release process testé 3 fois, rollback automatique vérifié

### Performance (4 critères)
- [ ] p95 API < 500ms sur 1k VU mixed load (k6 nightly green)
- [ ] Lighthouse Performance ≥ 85, Accessibility ≥ 90, PWA ≥ 90
- [ ] CDN edge actif, latence first byte < 200ms depuis 3 PoPs
- [ ] HLS ABR fonctionne (3 niveaux 128/256/320)

### Observabilité (5 critères)
- [ ] Grafana dashboards : API overview, Chat, Commerce, Stream, Live, Ledger health
- [ ] OpenTelemetry collector vivant, traces visibles dans Tempo
- [ ] Loki HA 3 réplicas, logs application centralisés
- [ ] SLO burn-rate alerts définies (3 SLO), runbooks indexés
- [ ] Status page publique sur `status.veza.fr`, synthetic monitoring vert 7j

### Légal (5 critères)
- [ ] Terms of Service publié sur `/legal/terms`, avocat-validé
- [ ] Privacy Policy publié sur `/legal/privacy`, RGPD + CCPA conformes
- [ ] DMCA notice formulaire actif sur `/legal/dmca`, agent enregistré US Copyright Office
- [ ] DSA point de contact UE désigné, transparency report template prêt
- [ ] CGV vendeur marketplace publiées

### Business (4 critères)
- [ ] Stripe Connect live mode actif, KYC créateur testé E2E
- [ ] Hyperswitch live mode actif, paiement E2E vrai fonds testé (5+€)
- [ ] Refund E2E vrai fonds testé
- [ ] Email transactionnel sur domaine custom (SPF/DKIM/DMARC vert)

### Qualité (4 critères)
- [ ] Coverage tests ≥ 70% (Go + Rust + TS)
- [ ] 0 lint error (golangci-lint, ESLint, clippy)
- [ ] CI verte sur main depuis 2 semaines consécutives
- [ ] E2E `@critical` vert sur les 5 derniers nightly

### Éthique (5 critères absolus, non-négociables)
- [ ] Aucun code AI/ML recommandation (grep `tensorflow|pytorch|sklearn` = 0 hit)
- [ ] Aucune métrique popularité publique (likes/plays cachés des vues publiques)
- [ ] Feed chronologique (`ORIGIN_REVISION_SUMMARY.md` rule 7)
- [ ] Algorithme découverte documenté + auditable (`docs/DISCOVERY_ALGORITHM.md`)
- [ ] Audit UX anti-dark-pattern signed off

**Total : 37 critères. Si > 3 sont rouges au matin du jour 30, le launch décale d'1 semaine.**

---

## 9. Communication & external comms

### Pré-launch (semaines 1-5)
- Lundi semaine 1 : annonce interne (Discord équipe / proches) "lancement public début juin 2026"
- Semaine 3 : ouvrir un compte X/Mastodon Veza, premiers posts teaser
- Semaine 4 : open la mailing list pré-launch (formulaire `veza.fr`)
- Semaine 5 : envoi soft launch invitations 50-100 testeurs

### Launch jour 30
- Annonce simultanée : Twitter/X, Mastodon, Hacker News (Show HN), Reddit /r/musicians, /r/Wearethemusicmakers, Product Hunt préparé pour J+1
- Email à la mailing list pré-launch
- Communiqué de presse short (3 paragraphes) à musique-tech press (TechCrunch, ResidentAdvisor, Music Ally)

### Post-launch (D+1 à D+30)
- Daily monitoring stats sur le compte X/Mastodon
- Weekly product update blog
- Office hours hebdo Discord (Q&A créateurs)

---

## 10. Annexes — références rapides

- **État de départ** : `docs/PROJECT_STATE.md`, `docs/FEATURE_STATUS.md`, `FUNCTIONAL_AUDIT.md`
- **Audit complet** : `AUDIT_REPORT.md`, `docs/audit-2026-04/`
- **Plan original 24 semaines** : `/home/senke/.claude/plans/quelles-sont-les-prochaines-playful-beaver.md`
- **Sprint 1 v1.0.9 commit messages** : `/tmp/v1.0.9-commit-messages.md`
- **Configurations infra** : `infra/coturn/`, `infra/ansible/` (à créer semaine 1)
- **Runbooks** : `docs/runbooks/` + `k8s/disaster-recovery/runbooks/`
- **Règles immuables** : `CLAUDE.md` §🚫 + `veza-docs/ORIGIN/`
- **GO/NO-GO précédent (v1.0.0-rc1)** : `docs/GO_NO_GO_CHECKLIST_v1.0.0.md`

---

## 11. Cadence quotidienne suggérée

```
08:00-08:30  Café + revue plan (ce doc) + vérif notif Forgejo nightly
08:30-09:00  Revue inbox externe (légal/pentest/ops emails)
09:00-12:30  Bloc focus matin — la tâche du jour (~3.5h)
12:30-13:30  Pause déjeuner OBLIGATOIRE
13:30-17:00  Bloc focus après-midi — finir tâche du jour + tests + commit (~3.5h)
17:00-17:30  Update du checklist + push final + setup demain
17:30        Stop. Pas de "juste un dernier truc".
```

Si une journée glisse de > 4h, **ne pas** rattraper le soir/week-end —
re-prioriser la suite. Le burnout au jour 20 = launch raté.

---

*Document vivant. Mettre à jour le statut des tâches en cochant directement dans ce fichier (`[ ]` → `[x]`). Commit chaque mise à jour avec `docs: roadmap launch — <jour X> done` pour traçabilité.*