Débuter avec Ralph Wiggum Partie 4 : Patterns avancés et dépannage

Tu as appris les fondamentaux et maîtrisé la méthodologie. Maintenant, plongeons dans les techniques avancées qui séparent les amateurs des professionnels.

Voici ton playbook avancé — des techniques pour les scénarios complexes, un dépannage complet et des patterns de niveau entreprise qui feront de toi un expert Ralph.

Ingénierie de prompts avancée

Le pattern Constraint Sandwich

L'un des patterns les plus efficaces pour les prompts Ralph structure les contraintes autour de la tâche :

# BUILDING MODE

## Pre-Constraints (What to consider first)
- Read IMPLEMENTATION_PLAN.md
- Check progress.txt for prior learnings
- Study existing patterns in the codebase
- Verify dependencies are installed

## Core Task
[Your main instruction here]

## Quality Gates (Must pass before proceeding)
- All tests pass: npm test
- Type check passes: npm run type-check
- Linter passes: npm run lint
- No console.logs or debugger statements remain

## Post-Task Actions
- Commit with semantic message
- Update IMPLEMENTATION_PLAN.md
- Append learning to progress.txt

Ce pattern fonctionne parce qu'il guide la réflexion de Ralph dans le bon ordre, comme documenté dans 11 Tips for AI Coding with Ralph Wiggum.

Voir des exemples concrets : Parcours des fichiers de prompts en production issus de la communauté :

• snarktank/ralph — Un prompt.md complet avec structure de contraintes
• ClaytonFarr/ralph-playbook — Templates PROMPT_plan.md et PROMPT_build.md
• Le gist de peteristhegreat — Configuration d'agent de codage Ralph

La technique du prompting socratique

Au lieu de dire exactement à Ralph quoi faire, pose-lui des questions qui mènent à de meilleures solutions :

Prompt faible :

Implement caching for the API.

Prompt fort (socratique) :

We need to improve API performance. Before implementing:

1. What are the slowest endpoints currently? (Analyze with profiler)
2. Which data changes frequently vs rarely?
3. What caching strategy best fits this access pattern?
4. Where should the cache layer live (app, Redis, CDN)?

After analysis, implement the most appropriate solution with tests.

Cela force Ralph à réfléchir au problème de manière systématique, comme souligné dans The Ralph Playbook.

Le pattern Escape Hatch

Donne toujours à Ralph une porte de sortie quand il est bloqué :

## If You Encounter a Blocker

1. Document the issue in progress.txt
2. Create a TODO.md file with:
   - What you tried
   - Why it didn't work
   - What needs human decision
3. Mark the current task as "blocked" in IMPLEMENTATION_PLAN.md
4. Move to the next independent task

DO NOT spin indefinitely on unsolvable problems.

Le pattern d'accumulation des apprentissages

Structure progress.txt pour accumuler les connaissances :

After completing each task, append:

## [TIMESTAMP] [TASK-ID]: [Task Title]

### What Was Built
- Feature/change summary

### Technical Decisions
- Why this approach over alternatives

### Challenges & Solutions
- What went wrong and how it was fixed

### Learnings for Next Tasks
- Patterns to reuse
- Pitfalls to avoid

### Dependencies/Prerequisites for Related Tasks
- What's now available for other tasks

Cela crée une base de connaissances que Ralph consulte, évitant ainsi de répéter les mêmes erreurs.

Organisation de fichiers avancée

Structure de projet multi-modes

Pour les projets complexes utilisant les trois phases :

project-root/
├── ralph/                    # Ralph-specific files
│   ├── phases/
│   │   ├── PROMPT_plan.md
│   │   ├── PROMPT_build.md
│   │   └── PROMPT_refactor.md  # Optional: separate refactor mode
│   ├── IMPLEMENTATION_PLAN.md
│   ├── progress.txt
│   ├── blockers.md             # Current blockers needing human input
│   └── loop.sh                 # Orchestrator script
├── specs/                    # Requirements
│   ├── architecture.md
│   ├── features/
│   │   ├── auth.md
│   │   └── api.md
│   └── non-functional.md     # Performance, security, etc.
├── docs/                     # Generated documentation
├── src/                      # Application code
└── tests/                    # Test suite

Le système de checkpoints

Crée des checkpoints pour les projets de longue durée :

# ralph/checkpoints/checkpoint-YYYY-MM-DD-description.md

## Project State
- Branch: feature/user-management
- Commit: abc123
- Tasks completed: 15/30
- Blockers: None

## Ralph Configuration
- Mode: Building
- Max iterations: 100
- Completion promise: "MILESTONE COMPLETE"

## Next Steps
1. Complete user role management (TASK-016 to TASK-020)
2. Then regenerate plan for Phase 2 features
3. Consider splitting into separate Ralph session

## Learnings So Far
- Database schema changes require migration strategy
- Test data setup takes 2-3 iterations
- Auth patterns now stable and reusable

Configurer les PRD pour Ralph

Un PRD bien structuré est essentiel au succès de Ralph. C'est une alternative à l'approche specs/*.md + IMPLEMENTATION_PLAN.md — certaines équipes préfèrent le JSON pour sa lisibilité machine.

Outils utiles : Ralph TUI inclut /ralph-tui-prd pour créer des PRD de manière interactive et /ralph-tui-create-json pour les convertir en JSON. snarktank/ralph propose une gestion de tâches pilotée par PRD avec branching automatique et visualisation en diagramme de flux.

Template prd.json

{
  "project": "Todo API",
  "schema_version": "2.0",
  "final_tests": ["npm test", "npm run type-check", "npm run lint"],
  "stories": [
    {
      "id": "S001",
      "priority": 1,
      "title": "User Authentication",
      "category": "backend",
      "description": "Implement JWT-based authentication with login/logout",
      "acceptance": [
        "User can register with email/password",
        "User can login and receive JWT token",
        "Protected routes require valid JWT",
        "User can logout and invalidate token"
      ],
      "steps_to_verify": [
        "Run: npm test -- auth.test.ts",
        "Verify all 12 auth tests pass",
        "Check JWT is stored in httpOnly cookie",
        "Verify token expiry works correctly"
      ],
      "tests": ["npm test -- auth.test.ts"],
      "estimated_complexity": "medium",
      "depends_on": [],
      "passes": false
    },
    {
      "id": "S002",
      "priority": 2,
      "title": "Todo CRUD Endpoints",
      "category": "backend",
      "description": "Create POST, GET, PUT, DELETE endpoints for todos",
      "acceptance": [
        "POST /api/todos creates a todo",
        "GET /api/todos returns user's todos only",
        "PUT /api/todos/:id updates a todo",
        "DELETE /api/todos/:id deletes a todo"
      ],
      "steps_to_verify": [
        "Run: npm test -- todos.test.ts",
        "Test with Postman or curl",
        "Verify authorization works"
      ],
      "tests": ["npm test -- todos.test.ts"],
      "estimated_complexity": "medium",
      "depends_on": ["S001"],
      "passes": false
    }
  ]
}

Principes clés du PRD

Critères binaires réussite/échec : Chaque tâche a besoin d'une vérification automatisée. Comme le souligne The Ralph Playbook : « Make it better » n'est pas testable — « All tests pass with 80%+ coverage » l'est.

Tâches atomiques : Si une tâche nécessite plus de 500 lignes de code, découpe-la. Chaque story devrait se compléter en 2-3 itérations.

Le champ passes : Ralph le met à jour à true une fois terminé. La boucle continue jusqu'à ce que toutes les tâches passent.

Exigences de tests : Chaque story doit spécifier comment vérifier automatiquement sa complétion. Aucune étape de vérification manuelle.

Pièges courants et comment les éviter

Commencer trop ambitieux

Erreur : Lancer 50 itérations sur ton premier projet Ralph.

Correction : Commence avec 10-20 itérations pour comprendre les coûts et le comportement. Comme documenté dans les conseils de la communauté, une boucle de 50 itérations peut coûter 50 à 100 $+.

Critères de complétion vagues

Erreur : « Rendre l'app plus rapide » ou « Améliorer l'UI »

Correction : Utilise des critères spécifiques et testables :

• ✅ « Réduire le temps de réponse API à moins de 200ms (vérifié par des tests de charge) »
• ✅ « Tous les scores Lighthouse au-dessus de 90 »
• ✅ « Couverture de tests au-dessus de 80% sur tous les modules »

Pas de vérification automatisée

Erreur : Des tâches qui nécessitent un jugement humain comme « rendre ça joli »

Correction : Ralph a besoin de conditions binaires réussite/échec. Si tu ne peux pas écrire un test automatisé pour ça, Ralph ne peut pas le vérifier. Comme le dit The Ralph Playbook : « Backpressure beats direction. »

Tâches trop grandes

Erreur : « Construire tout le système d'authentification » en une seule tâche

Correction : Découpe en stories plus petites :

• S001 : Endpoint d'inscription utilisateur
• S002 : Endpoint de connexion avec JWT
• S003 : Mécanisme de rafraîchissement de token
• S004 : Flux de réinitialisation de mot de passe
• S005 : Vérification d'email

Ignorer les limites de contexte

Erreur : Laisser Ralph tourner indéfiniment sans contexte frais

Correction : Utilise la méthode de boucle Bash au lieu du plugin pour les projets de longue durée — chaque itération obtient une fenêtre de contexte fraîche. C'est un insight clé du guide de Geoffrey Huntley.

Quand utiliser quelle méthode :

• < 20 itérations : Le plugin (/ralph-loop) convient — configuration plus simple, le contexte reste gérable
• 20-40 itérations : Les deux fonctionnent ; la boucle bash est préférée pour la cohérence
• > 40 itérations : Boucle bash obligatoire — empêche la dégradation du contexte et les hallucinations

Le plugin exécute tout dans une seule fenêtre de contexte, qui se remplit au fil du temps. La méthode de boucle bash lance une instance Claude fraîche par itération, seul l'état du code persiste.

Pas de suivi des coûts

Erreur : Ne pas surveiller les dépenses API pendant le développement

Correction : Configure des alertes de facturation et commence avec un nombre d'itérations bas. Surveille les coûts par itération. Suis tes dépenses sur https://console.anthropic.com

Mauvais types de tâches

Bonnes tâches pour Ralph :

• Migrer les tests de Jest vers Vitest
• Ajouter des endpoints CRUD avec des tests
• Implémenter des fonctionnalités bien spécifiées
• Refactorer avec une couverture de tests existante

Mauvaises tâches pour Ralph :

• « Trouver pourquoi l'app est lente » (exploration)
• « Rendre l'UI plus jolie » (subjectif)
• « Corriger ce bug bizarre » (nécessite un contexte de débogage profond)
• Décisions UX nécessitant un jugement esthétique

Le problème du thrashing

Symptôme : Ralph tourne en boucle — même erreur, même tentative de correction, même échec.

Solutions :

• Définis --max-iterations pour limiter les dégâts
• Revois tes tests — sont-ils trop stricts ou peu clairs ?
• Découpe la tâche en morceaux plus petits et atomiques
• Ajoute des étapes de débogage explicites à ton prompt
• Vérifie que les dépendances sont correctement installées

Guide de dépannage complet

Problème : Ralph répète sans cesse la même erreur

Symptômes :

• Même erreur sur plusieurs itérations
• Les tests échouent avec un message identique
• Ralph essaie la même approche à répétition

Causes racines :

1. Le test est ambigu ou mal écrit
2. Le prompt n'inclut pas le retour d'erreur
3. Ralph manque de contexte sur pourquoi l'approche échoue

Solutions :

Correction 1 : Mettre à jour le test

// Bad: Vague assertion
expect(result).toBeTruthy();

// Good: Specific assertion
expect(result).toEqual({
  id: expect.any(String),
  email: 'test@example.com',
  createdAt: expect.any(Date)
});

Correction 2 : Ajouter le retour d'erreur au prompt

If tests fail:
1. Read the test output carefully
2. Identify the specific assertion that failed
3. Check if you're testing the wrong behavior
4. Try a different approach if current one fails twice

Correction 3 : Ajouter des étapes de débogage explicites

Before implementing:
1. Add console.log to see actual vs expected values
2. Run test in isolation: npm test -- --testNamePattern="specific test"
3. Verify mock data matches what code expects

Correction 4 : Utiliser le pattern Escape Hatch

Si Ralph continue d'échouer après plusieurs tentatives, utilise le pattern Escape Hatch pour documenter le blocage et passer à la tâche suivante au lieu de tourner indéfiniment.

Problème : Ralph génère du code non sécurisé

Symptômes :

• Mots de passe stockés en clair
• Vulnérabilités d'injection SQL
• Vérifications d'authentification manquantes
• CORS configuré sur « * »

Prévention :

Ajoute une checklist de sécurité au prompt :

## Security Checklist (MUST verify before committing)

Authentication:
- [ ] Passwords hashed with bcrypt (min 12 rounds)
- [ ] JWTs signed with secure secret (min 32 chars)
- [ ] httpOnly cookies for token storage
- [ ] No secrets in code (use env variables)

Authorization:
- [ ] All protected routes have auth middleware
- [ ] User can only access own resources
- [ ] Admin endpoints check role

Input Validation:
- [ ] All user input validated with Zod/Joi
- [ ] SQL/NoSQL injection prevented (use ORMs)
- [ ] XSS prevention (sanitize HTML)
- [ ] Rate limiting on sensitive endpoints

CORS:
- [ ] Specific origins only (not "*")
- [ ] Credentials: true only with specific origin

Problème : Épuisement de la fenêtre de contexte

Symptômes :

• Ralph commence à ignorer des parties des prompts
• La qualité se dégrade après l'itération 30-40
• Ralph arrête de suivre les contraintes

Comme le guide de JeredBlu l'explique, c'est pour cela que la méthode de boucle bash avec un contexte frais par itération est « fondamentalement meilleure pour les tâches de longue durée ».

Solutions :

Solution 1 : Utiliser la méthode de boucle Bash

# loop.sh - Fresh context each iteration
while true; do
  claude < PROMPT_build.md

  # Check if done
  if grep -q "ALL TASKS COMPLETE" progress.txt; then
    echo "Build complete!"
    break
  fi

  sleep 2
done

Solution 2 : Prompt de compression du contexte

À propos de /compact : La commande /compact compresse le contexte de ta conversation, te permettant de continuer à travailler sans perdre les détails importants. Utilise-la de manière proactive avant d'atteindre les limites de contexte. Voir Mastery Part 2 pour savoir quand utiliser /compact vs /clear.

Every 10 iterations, before continuing:

1. Run: /compact to compress context
2. Summarize current state:
   - Tasks completed
   - Current task in progress
   - Key patterns established
3. Continue with fresh focus

Solution 3 : Découper les longues sessions

# Session 1: Core features (Tasks 1-10)
/ralph-loop "$(cat PROMPT_build.md)" --max-iterations 30

# Review, commit, take a break

# Session 2: Advanced features (Tasks 11-20)
/ralph-loop "$(cat PROMPT_build.md)" --max-iterations 30

Problème : Ralph ne s'arrête pas (thrashing)

Symptômes :

• Atteint le max-iterations sans terminer
• Fait des changements, les annule, recommence
• progress.txt montre une logique circulaire

Pour une analyse plus approfondie de la prise de décision de Ralph quand il thrash, le guide de débogage de Braintrust montre comment utiliser des outils d'observabilité LLM pour comprendre ce qui se passe.

Diagnostic :

Cherche des patterns dans progress.txt :

[14:30] Trying approach A...
[14:35] Approach A failed, trying approach B...
[14:40] Approach B failed, trying approach A again...

Solutions :

Solution 1 : Ajouter un suivi des tentatives

Track attempts in progress.txt:

[Iteration X] TASK-005: Attempt #1 - Trying JWT with RSA
[Iteration Y] TASK-005: Attempt #2 - Trying JWT with HS256
[Iteration Z] TASK-005: Attempt #3 - Adding fallback

If task has 3 failed attempts:
1. Mark task as "blocked"
2. Document in blockers.md
3. Move to next task

Solution 2 : Simplifier les critères d'acceptation

# Too complex (causes thrashing)
- API must be performant, secure, and scalable

# Specific (Ralph can verify)
- API responds in <200ms (verified by tests)
- All endpoints require authentication (verified by tests)
- Can handle 100 concurrent requests (load test passes)

Problème : La couverture de tests diminue avec le temps

Symptômes :

• Les premières tâches ont d'excellents tests
• Les tâches suivantes ont des tests minimaux
• La couverture est en dessous de la cible

Cause racine : Ralph priorise la livraison par rapport aux tests quand ce n'est pas imposé.

Solution : Ajoute un seuil de couverture de tests au prompt :

## Test Requirements (STRICT)

Every commit MUST include tests for:
1. Happy path (success case)
2. Error cases (4xx, 5xx)
3. Edge cases (empty input, missing fields)
4. Authorization (access control)

Before committing, run: npm test -- --coverage

MINIMUM COVERAGE REQUIRED:
- Statements: 80%
- Branches: 75%
- Functions: 80%
- Lines: 80%

If coverage drops below threshold:
- DO NOT commit
- Add missing tests
- Re-run coverage

Problème : Ralph ignore les patterns existants

Symptômes :

• Le nouveau code utilise des patterns différents du code existant
• Structure de fichiers incohérente
• Plusieurs façons de faire la même chose

Solution : Ajoute de la documentation des patterns à ton prompt. Inclus la structure de fichiers réelle de ton projet et les conventions de nommage pour que Ralph les suive de manière cohérente :

## Codebase Patterns (MUST FOLLOW)

Before implementing any feature:
1. Study existing features as reference (e.g., the user module)
2. Follow the same directory structure and file organization
3. Reuse established naming conventions and code patterns
4. Only deviate if specs explicitly require it

If unsure about a pattern, check how similar features are implemented
in the codebase before writing new code.

Configuration avancée de Ralph-TUI

Ralph-TUI prend en charge la personnalisation via un fichier de configuration dans ~/.ralph-tui/config.json.

Priorités de tâches personnalisées

Remplace le tri par priorité par défaut :

{
  "taskPriority": {
    "TASK-001": 10,
    "TASK-005": 9,
    "TASK-002": 8
  }
}

Ralph-TUI affiche les tâches dans cet ordre, même si IMPLEMENTATION_PLAN.md les liste différemment.

Filtrage de la sortie

Filtre les lignes de log par mot-clé ou regex :

{
  "logFilters": {
    "exclude": ["Reading", "Skipping"],
    "include": ["✓", "✗", "completed", "failed"]
  }
}

Cela masque les lignes bruyantes (lectures de fichiers) et met en valeur les événements importants (résultats de tests, complétion de tâches).

Formats d'export

Choisis le format d'export des logs :

{
  "exportFormat": "markdown"
}

Options : txt, markdown, json, html

L'export Markdown génère :

# Ralph-TUI Log Export
**Project:** my-saas-app
**Duration:** 2h 15m
**Tasks Completed:** 12 / 15

## Iteration 1
[10:05:12] Reading specs...
...

Intégration avec d'autres outils

Envoie les événements Ralph-TUI vers des systèmes externes :

{
  "webhooks": {
    "taskComplete": "https://myapp.com/api/ralph-task-complete",
    "testFailure": "https://myapp.com/api/ralph-test-failed"
  }
}

Quand Ralph termine une tâche, Ralph-TUI fait un POST vers ton webhook :

{
  "event": "taskComplete",
  "taskId": "TASK-003",
  "timestamp": "2026-01-16T10:30:45Z",
  "iteration": 12
}

Cas d'utilisation :

• Mettre à jour les outils de gestion de projet (Linear, Jira)
• Envoyer des notifications Slack
• Déclencher des pipelines CI/CD à la complétion d'une tâche

Dépannage de Ralph-TUI

Ralph-TUI ne détecte pas la boucle Ralph

Symptôme : ralph-tui run affiche « Waiting for Ralph loop... » indéfiniment.

Cause : Ralph-TUI cherche un processus ralph en cours d'exécution dans le répertoire courant. Si tu as lancé Ralph dans un autre répertoire, Ralph-TUI ne le trouvera pas.

Solution :

1. Lance ps aux | grep ralph pour trouver le processus Ralph
2. Note le répertoire de travail avec lsof -p <pid>
3. Fais cd vers ce répertoire et relance ralph-tui run

Alternative : Spécifie explicitement le PID du processus Ralph :

ralph-tui run --pid 12345

Session perdue/corrompue

Symptôme : Ralph-TUI affiche « Session data corrupted » au démarrage.

Cause : Ralph-TUI stocke l'état de la session dans ~/.ralph-tui/sessions/<project-name>.json. Si Ralph plante en pleine itération, le fichier de session peut être incomplet.

Solution :

1. Supprime la session corrompue : rm ~/.ralph-tui/sessions/my-project.json
2. Redémarre Ralph-TUI : ralph-tui run

Ralph-TUI crée une nouvelle session, mais tu perds le contexte historique (les itérations précédentes n'apparaîtront pas dans les logs).

Prévention : Active les sauvegardes de session dans la config :

{
  "sessionBackups": {
    "enabled": true,
    "interval": 300
  }
}

Cela crée des sauvegardes toutes les 5 minutes dans ~/.ralph-tui/sessions/backups/.

Problèmes de performance avec les gros logs

Symptôme : Ralph-TUI devient lent ou ne répond plus après plusieurs heures de surveillance.

Cause : Le buffer de logs grossit à 100 000+ lignes, ralentissant le rendu.

Solution :

1. Exporte les logs régulièrement : appuie sur e toutes les heures
2. Active la rotation des logs dans la config :

{
  "logRotation": {
    "maxLines": 10000,
    "archiveOld": true
  }
}

Quand les logs atteignent 10 000 lignes, Ralph-TUI archive les anciens logs dans ~/.ralph-tui/archives/ et vide le buffer.

Alternative : Augmente la taille du buffer de ton terminal si celui-ci le permet (ex. : iTerm2 → Preferences → Profiles → Terminal → Scrollback lines).

Conflits de ports

Symptôme : ralph-tui run échoue avec « Port 9876 already in use ».

Cause : Ralph-TUI utilise le port 9876 pour la communication interne. Un autre processus l'utilise déjà.

Solution :

1. Trouve le processus en conflit : lsof -i :9876
2. Termine-le ou utilise un autre port :

ralph-tui run --port 9999

Correction permanente : Définis le port par défaut dans la config :

{
  "port": 9999
}

Retour visuel headless avec Playwright MCP

Pour les exécutions en boucle bash sans navigateur visible, JeredBlu recommande Playwright MCP pour la vérification visuelle.

Qu'est-ce que MCP ? Le Model Context Protocol (MCP) est un standard ouvert qui permet à Claude de se connecter à des services externes — bases de données, API, automatisation de navigateur, et plus encore. Les serveurs MCP étendent les capacités de Claude au-delà du traitement de texte. Voir Mastery Part 7: MCP Servers pour la configuration et le paramétrage.

Crée .mcp.json à la racine de ton projet :

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest", "--headless", "--output-dir", "screenshots"]
    }
  }
}

Puis référence-le dans ton PROMPT_build.md :

After implementing, use Playwright to:
1. Navigate to the local server URL
2. Take a screenshot: screenshots/[task-name].png

Include the screenshot filename in your progress.txt entry.

Cela te donne une vérification visuelle du travail de Ralph sans avoir besoin de Claude for Chrome ou d'une fenêtre de navigateur visible. Les captures d'écran s'accumulent dans ton dossier de projet, fournissant une piste d'audit visuelle de ce que Ralph a construit.

Quand utiliser Playwright MCP vs Ralph-TUI :

• Ralph-TUI : Surveillance des logs en temps réel, orchestration de tâches, contrôles au clavier
• Playwright MCP : Vérification visuelle headless, pistes d'audit par captures d'écran, intégration CI/CD

Les deux outils se complètent — utilise Ralph-TUI pour la surveillance en direct et Playwright MCP pour la vérification visuelle.

Patterns entreprise

Coordination Ralph multi-développeurs

Quand plusieurs développeurs utilisent Ralph sur le même projet, la coordination devient cruciale. Plusieurs outils existent pour ça :

• ralph-orchestrator — Prend en charge 7+ backends IA (Claude, Gemini, Copilot, etc.) avec un système de persona/rôle pour les tâches spécialisées
• multi-agent-ralph-loop — Orchestration de flux de travail parallèles pour exécuter plusieurs instances Ralph simultanément
• ralph-loop-agent — Le wrapper SDK TypeScript de Vercel pour le contrôle programmatique

Pattern 1 : Ralph par branche de fonctionnalité

# Developer A
git checkout -b feature/auth
# Run Ralph for auth tasks
./loop.sh build --tasks "TASK-001 to TASK-005"

# Developer B (different branch)
git checkout -b feature/payments
# Run Ralph for payment tasks
./loop.sh build --tasks "TASK-010 to TASK-015"

# Merge both when complete

Pattern 2 : Suivi de progression partagé

# team-progress.md

## Active Ralph Sessions

### Developer: Alice
- Branch: feature/auth
- Tasks: TASK-001 to TASK-005
- Status: In Progress (3/5 complete)
- ETA: 2 hours

### Developer: Bob
- Branch: feature/payments
- Tasks: TASK-010 to TASK-015
- Status: Complete
- Ready for: Code review

## Blocked Tasks Needing Team Discussion
- TASK-008: Payment provider API unclear
- TASK-014: Architecture decision needed

Intégration Ralph + CI/CD

Automatise les exécutions Ralph dans ton pipeline :

# .github/workflows/ralph-build.yml
name: Ralph Autonomous Build

on:
  workflow_dispatch:
    inputs:
      tasks:
        description: 'Task range (e.g., TASK-001 to TASK-005)'
        required: true

jobs:
  ralph-build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Setup Claude Code
        run: curl -fsSL https://claude.ai/install.sh | bash

      - name: Run Ralph Loop
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          ./loop.sh build \
            --tasks "${{ github.event.inputs.tasks }}" \
            --max-iterations 30

      - name: Create Pull Request
        uses: peter-evans/create-pull-request@v5
        with:
          title: "Ralph Build: ${{ github.event.inputs.tasks }}"
          body: |
            Autonomous build completed by Ralph Wiggum

            Tasks completed:
            ${{ github.event.inputs.tasks }}

            See progress.txt for details.

Choisir un forfait Claude pour Ralph

Ralph fonctionne avec les abonnements Claude ou l'accès API. Voici le guide rapide :

• Claude Pro (20 $/mois) — 10-30 itérations/session, idéal pour apprendre et les projets perso
• Claude Max 5x (100 $/mois) — 50-150 itérations/session, parfait pour le développement quotidien
• Claude Max 20x (200 $/mois) — 200-600+ itérations/session, boucles autonomes professionnelles de longue durée

Recommandation : Commence avec Pro pour apprendre le workflow. Passe à Max 5x une fois que tu utilises Ralph quotidiennement — c'est 5x la capacité pour 5x le prix, ce qui est honnête. Opte pour Max 20x si tu fais du travail client ou si tu as besoin de sessions autonomes prolongées.

Le calcul du ROI : À 200 $/mois pour Max 20x, si Ralph te fait gagner seulement 5 heures (à 40 $/h de facturation), il est déjà rentabilisé. La plupart des utilisateurs sérieux rapportent 20 à 40+ heures économisées par mois.

Conseils de gestion des coûts

• Définis toujours --max-iterations — C'est ton vrai filet de sécurité
• Commence petit — 10-20 itérations jusqu'à ce que tu comprennes les coûts
• Des prompts ciblés = moins d'itérations — Les prompts vagues brûlent des tokens
• Suis ton utilisation — Vérifie sur https://claude.ai/settings

Conclusion

Tu as maintenant couvert les techniques avancées qui t'aideront à tirer le meilleur parti de Ralph. Ces techniques te permettent de t'attaquer à des projets complexes de niveau production avec confiance. Tu sais comment prévenir les problèmes avant qu'ils ne surviennent et les corriger rapidement quand ils se produisent.

Pour des ressources supplémentaires, explore The Ralph Playbook pour une documentation complète de la méthodologie, le guide original de Geoffrey Huntley pour la philosophie derrière la technique, et le guide pratique de JeredBlu pour des configurations prêtes à copier-coller.