Brief produit vers stack et architecture avec Tony

Contexte

Tony est l’ingénieur en chef ulk. Il prend un brief produit textuel et propose une recommandation concrète : stack recommandée, architecture schématisée, timing MVP vs V1. Utile au démarrage d’un projet neuf ou pour auditer une stack existante. Accès mémoire persistante pour mémoriser tes préférences tech.

Prérequis

• Brief produit écrit (même incomplet)
• Ou code source existant pour audit
• Intention claire (SaaS, App, Marketplace, etc.)

Étapes

1. Préparer le brief

Crée docs/brief.md :

# Brief Produit

## Nom
Dashboard Analytics pour PME

## Vision
Plate-forme SaaS permettant aux PME de centraliser leurs données
(Google Analytics, Stripe, email) et générer des rapports custom.

## MVP
- Import Google Analytics + Stripe
- Dashboards simples (bar, pie charts)
- Export PDF
- 100 utilisateurs max

## V1 (mois 2-3)
- Custom dashboards (drag-drop)
- Alertes (email, Slack)
- Webhook integrations
- Multi-workspace

## Contraintes
- Équipe : 2 devs, 0 backend
- Budget : gratuit jusqu'à V1
- TTM : 6 semaines pour MVP
- Utilisateurs : PME françaises

## Choix déjà faits
- Frontend: React (connu de l'équipe)
- Déploiement: Vercel (gratuit)

2. Invoquer Tony

/ulk:tony

Ou directement :

/ulk:tony "Lire docs/brief.md et recommander une stack + archi"

3. Tony pose ses questions

Tony utilisera un questionnaire pour affiner :

1. Performance requise ?
   - Temps réel (<100ms)
   - Semi-temps réel (< 1s)
   - Batch (rafraîchissement quotidien)

2. Complexité données ?
   - Simple (OLTP)
   - Analytique (OLAP/data warehouse)
   - Mixte

3. Équipe expérience ?
   - Junior
   - Mid-level
   - Senior

4. Priorités ?
   - Vitesse de déploiement
   - Maintenabilité
   - Performance
   - Scaling

4. Tony retourne une recommandation

Exemple output :

🏗️ ENGINEERING REPORT — Dashboard Analytics MVP

## Stack Recommandée

### Frontend
- Framework: Next.js (React + routing + SSR)
- UI: Shadcn/ui (headless, tailwind)
- Charts: Recharts (simple, léger)
- Auth: NextAuth.js (OAuth Google/GitHub)

### Backend
- Runtime: Node.js (Fastify)
- DB: PostgreSQL (Neon serverless)
- Cache: Redis (Upstash gratuit)
- Jobs: Bull + Redis

### Infrastructure
- Deploy: Vercel (frontend) + Railway (backend)
- Monitoring: Sentry + LogRocket
- Email: Resend
- Webhooks: Stripe CLI local, production via ngrok

## Architecture Diagram

[Browser] → Next.js + NextAuth → Fastify API → PostgreSQL → Redis → Stripe SDK → Google Analytics API → Slack API

## Timing

| Tâche | Durée | Ordre |
|-------|-------|-------|
| Setup (repo, DB, auth) | 3j | 1 |
| Import GA + Stripe API | 4j | 2 |
| Dashboard simple | 5j | 3 |
| Export PDF | 2j | 4 |
| Tests + QA | 3j | 5 |
| Deploy MVP | 1j | 6 |

**Total MVP: 5-6 semaines** ✓

## Alternatives (tradeoffs)

**Option 1 (Recommandée): Next.js + Fastify**
- ✅ Scalable, maintenable
- ✅ Équipe connaît React
- ❌ Plus complexe que option 2

**Option 2 (Rapide): Supabase + SvelteKit**
- ✅ Backend zéro code (Supabase = DB + Auth + API)
- ✅ Plus rapide à déployer
- ❌ Moins flexible pour complexité future

**Option 3 (Overkill): Kubernetes + Microservices**
- ✅ Scalabilité extrême
- ❌ Trop complexe pour MVP

5. Handoff vers Shuri

Tony va proposer de déléguer vers Shuri (01) pour générer la spec détaillée :

/ulk:shuri mode=spec
# Shuri va créer docs/spec.md detaillé avec 
# - Tous les endpoints API
# - Schéma DB
# - Dépendances
# - Flux utilisateur

Audit mode (stack existante)

Si tu as déjà du code :

/ulk:tony audit

Tony analysera le code existant et proposera :

• Points forts
• Zones d’amélioration
• Recommandations de refactoring/migration

Memory - Continuité inter-sessions

Tony se souvient de tes préférences :

## tony_user_preferences
- preferred_stacks:
  - web: [Next.js, Nuxt, SvelteKit]
  - backend: [Fastify, Hono]
  - db: [PostgreSQL, Neon]
- preferred_cloud: [Vercel, Railway]
- avoided_tech: [WordPress, Shopify (non-code)]

À la prochaine invocation, Tony proposera ces techs en priorité.

Troubleshooting

Symptôme	Cause probable	Résolution
Recommandation trop complexe	Brief trop vague	Détailler les contraintes
Stack mal adaptée	Questions mal répondies	Relancer Tony avec clarifications
Timing impossible	Estimation optimiste	Ajouter marge (multiplier par 1.5x)

Voir aussi

• 28-task-runner-feature.md — Implémenter les features planifiées
• 25-godspeed-diagnostic.md — État du projet après recommendation