Overview — méta du playbook

Le sprint loop (v1 — subdomain pattern, S3 async)

                ┌──────────────────────────────┐
   IDÉE ───▶   │  S1 — Stress Test            │  → idea-score.md (GO/STOP)
                └─────────────┬────────────────┘
                              ▼
                ┌──────────────────────────────┐
                │  S2 — Market Intel           │  → competitive + positioning
                └─────────────┬────────────────┘
                              ▼
                ┌──────────────────────────────┐
                │  S4 — Spec & Design          │  → spec.md + tokens + wireframes
                └─────────────┬────────────────┘   📱 review-after (non-blocking)
                              ▼
                ┌──────────────────────────────┐
                │  S5 — Build → SHIP on        │  → repo + {slug}.atelier.com
                │       {slug}.atelier.com     │  → Stripe LIVE + Playwright CI
                └─────────────┬────────────────┘   📱 review-after
                              ▼
                ┌──────────────────────────────┐
                │  S6 — Launch & Outreach      │  → 100 emails + posts + PH
                └─────────────┬────────────────┘   📱 review-after
                              ▼
                ┌──────────────────────────────┐
                │  S7 — Iterate                │  → retro + verdict J30 GO/PIVOT/KILL
                └──────────────────────────────┘

   En parallèle async (ne bloque jamais) :
   ┌──────────────────────────────┐
   │  S3 — Naming & Brand (async) │  → 30 candidats → 5 finalistes → .com bought
   │                              │  → DNS swap → {final}.com (1-liner Vercel)
   └──────────────────────────────┘   📱 review-after — peut atterrir avant J30

Critical path : S1 → S2 → S4 → S5 → S6 → S7. Tout ship sur {sprint_slug}.atelier.com. Le rebrand vers .com final est un swap DNS quand S3 livre.

Les "gates Telegram" deviennent review-after (notifications, pas blockings) pour rester compétitif vélocité Polsia/Nanocorp. Martin peut rollback dans une fenêtre courte (ex: 15 min) après chaque station. Si pas de rollback, le sprint continue.

---

Le contrat data : startup.json

Source unique de vérité par sprint. Versionné, schéma strict (startup.schema.json). Chaque station lit l'état accumulé et écrit la section qui lui correspond.

{
  "atelier_version": "1.0",
  "sprint_id": "2026-05-16-prearrival",
  "input": { /* idea card raw, copié depuis saas-pipeline.json */ },
  "s1_stress_test": { "score": ..., "verdict": "GO|STOP", "doc": "01-stress-test.md", "completed_at": "..." },
  "s2_market_intel": { ... },
  "s3_brand":        { "final_name": "...", "domain_com": "...", ... },
  "s4_spec":         { "features": [...], "design_tokens": {...} },
  "s5_build":        { "repo_url": "...", "live_url": "...", "stripe_live": true, "e2e_passing": true },
  "s6_launch":       { "emails_sent": 100, "ph_scheduled": "...", "posts": [...] },
  "s7_iterate":      { "j30_verdict": "GO|PIVOT|KILL", "mrr": ..., "activation_rate": ... }
}

À côté du JSON, chaque station écrit aussi son Markdown narratif (0N-{station}.md). Le JSON = machine, le MD = humain.

---

Anti-patterns transverses (à pas faire dans aucune station)

1. Sauter une station parce que "j'ai une intuition forte". Le verrouillage existe pour neutraliser le biais du fondateur. Si tu sautes S1, tu te retrouves à coder pendant 5 jours pour découvrir que personne n'en veut.
2. Élargir le scope au milieu d'un sprint. Le scope est figé en S4. Toute nouvelle feature attend le sprint suivant. "If it's not in V1 it's V2."
3. Construire du custom alors qu'un template existe. La stack est figée. Pas de "et si on essayait Convex à la place de Supabase pour ce sprint" — c'est non.
4. Faire l'outreach après le launch. L'outreach DOIT démarrer la veille du launch (pré-tease + warm-up des prospects). Sinon S6 = vanity post.
5. Skipper le build in public. Le contenu se génère pendant le sprint. Pas après. Si t'as pas posté avant J7, tu shippes un produit dans le noir.
6. Demander "et si on faisait aussi X" à un agent. Les agents exécutent le playbook. Les décisions de scope se prennent en début de station, pas pendant.
7. Lancer un sprint sans bloquer 14 jours sur le calendrier. Sprint discontinu = sprint mort.

---

L'orchestration (v0 vs v1)

v0 (cette version) : manuelle. Martin (ou un humain assigné) lit chaque S{N}.md, exécute les prompts dans Claude/Codex, valide le livrable, met à jour startup.json, passe à la station suivante. Le playbook est une checklist auto-suffisante.

v1 (à coder une fois le v0 testé sur ≥ 2 sprints) : chaque station devient un agent Python. L'Orchestrator (Sonnet 4.6) arbitre les passages, refuse de passer à la suivante si le livrable ne passe pas le critère de verrouillage. Stack d'agents :

Orchestrator (Sonnet 4.6)
├── Validator       (S1) → idea-score.md
├── Market Analyst  (S2) → competitive-matrix.md + positioning.md
├── Brand Architect (S3) → names.json (avec dispo)
├── Product Designer (S4) → spec.md + design-tokens.json
├── Builder         (S5) → repo GitHub + Vercel deploy + Stripe
├── Launch Captain  (S6) → emails-sent.csv + posts-scheduled.md
└── Analyst         (S7) → weekly-recap.md + verdict J30

Les 4 gates Telegram (S3, S4, S5, S6) restent humaines en v1 — Martin valide à chaque verrou critique.

---

Le post-mortem obligatoire (à faire après chaque sprint)

Après chaque sprint, écrire runs/{date}-{slug}/POSTMORTEM.md :

1. Quel critère de verrouillage a été dur à atteindre ? → c'est le candidat #1 à l'automatisation.
2. Où ai-je triché ? → où le verrou a été contourné = trou dans la méthodologie.
3. Quel prompt a marché du premier coup ? → à canoniser dans le playbook.
4. Quel agent humain a été le bottleneck ? → à automatiser en v1.
5. MRR à J30 ? → vrai indicateur de qualité du sprint.

Ce post-mortem feed la v1 de chaque station.