2b3 — Routine de Fin de Session

Philosophie : Petit, rapide, non-interactif. Travaille uniquement sur git diff HEAD — jamais sur tout le codebase. Pour un audit complet, utiliser code-auditor (05) ou blackemperor (18). Références : _shared/cli-tools-protocol.md · _shared/memory-protocol.md · _shared/apfel-protocol.md

Outils CLI

gh : gestion GitHub (commits, PR) — vérifier avec command -v gh
apfel : LLM local Apple Intelligence (macOS 26+) — deleguer extraction TODOs, detection secrets, commit message. Vérifier avec command -v apfel

Schedule Tasks — Checkpoint Automatique

2b3 peut être planifié via /schedule pour un checkpoint automatique en fin de session.

# Checkpoint automatique en fin de journée
/schedule "Lancer 2b3 — checkpoint de fin de session" --cron "0 18 * * *"

# Checkpoint avant chaque push
/schedule "Lancer 2b3 avant de push" --trigger "pre_push"

Attention : Le checkpoint planifié est non-interactif — il ne demandera pas de confirmation. S’assurer que la suite de tests est robuste avant d’activer.

Phase 0 : Reconnaissance

0.0 — Détection apfel

APFEL=$(command -v apfel >/dev/null 2>&1 && echo "yes" || echo "no")
[ "$APFEL" = "no" ] && echo "ℹ️ Apfel non disponible — analyses effectuées par Claude"

0.1 — État du working tree

git status --short
git diff HEAD --stat

Si le working tree est propre (aucun fichier modifié, aucun fichier non tracké pertinent) :

✅ Working tree propre — rien à faire.
Dernier commit : [hash court] [message]

→ STOP. Ne pas continuer.

0.2 — Inventaire des fichiers modifiés

Récupérer la liste des fichiers modifiés/ajoutés :

git diff HEAD --name-only
git ls-files --others --exclude-standard

Stocker cette liste — elle sera le scope de toutes les phases suivantes.

Afficher :

🔍 2b3 — Fin de session
Fichiers dans le scope : [N] fichiers
  • [liste des fichiers modifiés]

Démarrage des 5 étapes...

Phase 1 : Vérification du Code

Scope : fichiers modifiés uniquement (liste Phase 0).

1.1 — Détection des outils disponibles

# Vérifier les outils disponibles dans le projet
ls package.json pyproject.toml Cargo.toml go.mod 2>/dev/null
cat package.json 2>/dev/null | grep -E '"scripts"' -A 20 | grep -E "typecheck|type-check|tsc|lint|test|check" | head -10

1.2 — Typecheck / Lint

Si TypeScript détecté :

npx tsc --noEmit 2>&1 | head -30

Si ESLint détecté :

npx eslint [fichiers modifiés] 2>&1 | head -30

Si Biome détecté :

npx biome check [fichiers modifiés] 2>&1 | head -20

Si erreurs bloquantes (erreurs de compilation, erreurs ESLint/error) :

❌ Phase 1 BLOQUÉE — Erreurs à corriger d'abord :
[liste des erreurs]

→ Correction requise avant de continuer.
  Conseil : lance `robocop` pour un diagnostic approfondi.

→ STOP. Ne pas continuer.

Corrections mineures auto (warnings simples, style) :

Corriger directement si la fix est évidente et non-risquée (ex : import inutilisé détecté par lint avec fix auto)
Signaler mais ne pas bloquer pour les warnings

1.3 — Tests existants

# Détecter le runner
ls vitest.config.* jest.config.* pytest.ini pyproject.toml Cargo.toml 2>/dev/null

# Lancer (timeout 60s)
npm test -- --run 2>&1 | tail -20      # Vitest/Jest
npx vitest run 2>&1 | tail -20         # Vitest explicite
cargo test 2>&1 | tail -20             # Rust
pytest -x -q 2>&1 | tail -20          # Python

Si tests échouent → même comportement : STOP + signalement.

1.4 — Scan qualité

Pour chaque fichier modifié (scope Phase 0) :

Si APFEL=yes et fichier < 200 lignes :

result=$(apfel -q -f "$file" "list TODO, FIXME, hardcoded passwords, API keys, tokens. Format: LINE:TYPE:TEXT")
# Ajouter à APFEL_LOG : "TODOs/secrets|$file|~400"

Sinon : lire le fichier avec Read et scanner les patterns directement.

Lire chaque fichier modifié et scanner pour :

Pattern	Sévérité	Action
`console.log(` / `console.debug(`	⚠️ Warning	Signaler
`debugger;`	❌ Bloquant	Retirer automatiquement
`TODO:` / `FIXME:`	📝 Note	Collecter pour Phase 3
Secrets hardcodés (`password =`, `api_key =`, `secret =`, token en dur)	🚨 Critique	Signaler + STOP
Code commenté (blocs `//` ou `/* */` suspects)	⚠️ Warning	Signaler

Rapport Phase 1 :

✅ Phase 1 terminée
  Typecheck : OK / [N erreurs]
  Lint : OK / [N warnings]
  Tests : OK / SKIP (pas de tests) / [N failures]
  Scan qualité : [résumé des trouvailles]
  TODOs/FIXMEs trouvés : [liste pour Phase 3]

Phase 1.5 : Conformité CLAUDE.md

Vérifie que les fichiers modifiés respectent les règles définies dans CLAUDE.md du projet.

1.5.1 — Charger les règles

# Chercher CLAUDE.md à la racine et dans les sous-dossiers pertinents
cat CLAUDE.md 2>/dev/null
ls */CLAUDE.md 2>/dev/null

Si aucun CLAUDE.md n’existe → afficher ℹ️ Pas de CLAUDE.md — Phase 1.5 sautée. Conseil : lancer /claude-md-improver ou claude-md-optimizer (42) pour en créer un. → passer Phase 2.

1.5.2 — Extraire les règles applicables

Lire CLAUDE.md et identifier toutes les règles, conventions et contraintes documentées :

Catégorie	Exemples de règles à détecter
Architecture	Structure des dossiers, séparation des responsabilités, patterns imposés (MVVM, etc.)
Nommage	Conventions de nommage (fichiers, fonctions, variables, classes, composants)
Fichiers interdits	Fichiers à ne jamais éditer manuellement (générés, lockfiles)
Stack & outils	Versions imposées, outils à utiliser ou éviter
Commandes	Commandes de build/test/lint à respecter
Patterns obligatoires	Types stricts, exports, imports, format de commit
Patterns interdits	Anti-patterns mentionnés, dépendances bannies
Documentation	Format de documentation, sections requises

1.5.3 — Vérifier la conformité des fichiers modifiés

Pour chaque fichier du scope (Phase 0), vérifier contre les règles extraites :

Le fichier est-il dans le bon dossier selon l’architecture définie ?
Le nommage respecte-t-il les conventions ?
Le code suit-il les patterns imposés ?
Aucun pattern interdit n’est utilisé ?
Les imports respectent-ils les layers définis ?
Le fichier n’est-il pas dans la liste des fichiers à ne jamais modifier ?

Vérification nommage via apfel : Si APFEL=yes et fichier < 200 lignes :

apfel -q -f "$file" "do function and variable names follow camelCase? List violations. Format: LINE:NAME:ISSUE"
# Ajouter à APFEL_LOG : "nommage|$file|~300"

1.5.4 — Rapport de conformité

✅ Phase 1.5 terminée — Conformité CLAUDE.md
  Règles vérifiées : [N]
  Conformes : [N] ✅
  Violations : [N] ⚠️/❌

Si violations détectées :

⚠️ Violations CLAUDE.md détectées :

  1. ❌ [fichier] — [règle violée] — [détail]
     Attendu : [ce que dit CLAUDE.md]
     Trouvé  : [ce qui est dans le code]

  2. ⚠️ [fichier] — [règle violée] — [détail]
     ...

Comportement selon sévérité :

Sévérité	Condition	Action
❌ Bloquant	Fichier interdit modifié, architecture violée	Signaler + STOP
⚠️ Warning	Convention de nommage, pattern non optimal	Signaler, corriger si fix triviale, continuer
📝 Note	Suggestion d’amélioration	Mentionner dans le rapport final

Tip : Si > 3 violations détectées ou si CLAUDE.md > 200 lignes → recommander /claude-md-improver (plugin officiel) ou claude-md-optimizer (42) dans le rapport final.

Critères qualité de référence (plugin officiel /claude-md-improver) : Commands (20pts) · Architecture (20pts) · Non-obvious patterns (15pts) · Conciseness (15pts) · Currency (15pts) · Actionability (15pts). Un CLAUDE.md conforme ne devrait contenir que des instructions spécifiques et actionnables — pas de prose générique.

Phase 2 : Documentation

Mettre à jour la documentation LOCALE uniquement — incrémentalement. Référence : _shared/update-protocol.md

2.1 — Identifier l’impact documentaire

Pour chaque fichier modifié, déterminer si les changements :

Ajoutent/modifient des fonctionnalités → impacte docs/spec.md
Modifient la structure, config, ou setup → impacte CLAUDE.md
Changent l’API publique ou les instructions d’usage → impacte README.md

Si aucun fichier doc n’est impacté → sauter Phase 2.

2.2 — Mise à jour incrémentale

Règles strictes :

Ne modifier que les sections directement impactées
Ne jamais réécrire un document en entier
Ne pas inventer de contenu — s’appuyer uniquement sur le diff réel
Ajouter la date si le document a un header de dernière mise à jour

Pour docs/spec.md (si impacté) :

Mettre à jour la section fonctionnalité concernée
Ajouter une entrée dans le changelog si présent

Pour CLAUDE.md (si impacté) :

Mettre à jour la section architecture ou commandes si changée
Ne pas modifier les instructions Bruce/agents

Pour README.md (si impacté) :

Mettre à jour les exemples ou instructions d’usage

Rapport Phase 2 :

✅ Phase 2 terminée
  Docs mises à jour : [liste ou "aucune mise à jour requise"]

Phase 3 : Todo

Lire docs/todo.md et le mettre à jour selon ce qui a réellement été fait.

3.1 — Vérifier l’existence

ls docs/todo.md 2>/dev/null

Si pas de docs/todo.md → afficher ℹ️ Pas de todo.md — Phase 3 sautée. → passer Phase 4.

3.2 — Cocher les tâches complétées

Analyser les fichiers modifiés (Phase 0) et comparer avec les tâches [ ] dans docs/todo.md.

Pour chaque tâche dont le travail correspondant est clairement visible dans le diff :

Changer [ ] → [x] avec la date du jour
Ne cocher que ce qui est certainement terminé

Règle : En cas de doute, ne pas cocher.

3.3 — Ajouter les TODOs/FIXMEs

Les TODOs/FIXMEs collectés en Phase 1.4 → ajouter comme nouvelles tâches [ ] dans la section appropriée (P2 ou P3 selon criticité).

Format :

- [ ] [TODO trouvé dans code] `fichier.ts:42` <!--added:YYYY-MM-DD-->

Rapport Phase 3 :

✅ Phase 3 terminée
  Tâches cochées : [N]
  TODOs/FIXMEs ajoutés : [N]

Phase 4 : Simplification Légère

Passe rapide sur les fichiers modifiés uniquement via /simplify natif. Pas d’audit global. En cas de doute (tests fragiles, logique complexe), sauter cette phase.

Principes applicables : voir _shared/simplify-principles.md — notamment principe 5 (scope to what changed) et red flags (tests qui cassent = comportement modifié). (Adapté de addyosmani/agent-skills MIT, ULK-048)

4.1 — Invoquer /simplify

/simplify

/simplify cible automatiquement les fichiers récemment modifiés (le scope de Phase 0) et spawn 3 agents en parallèle : code reuse, code quality, efficiency. Il applique les corrections directement.

Règles :

Si les fichiers modifiés sont peu nombreux (<3) et contiennent de la logique critique → sauter Phase 4
Ne jamais forcer /simplify sur du code avec une suite de tests fragile ou < 60% coverage
Si un bloc est marqué simplify-ignore-start (voir hook opt-in .claude/hooks-examples/simplify-ignore.json), il est automatiquement protégé

4.2 — Revalider après simplification

npm test -- --run 2>&1 | tail -10
# ou l'équivalent selon le runner détecté

Si les tests cassent après simplification :

⚠️ Simplification annulée — les tests ont cassé.
Rollback des modifications de Phase 4.

→ git checkout sur les fichiers touchés par /simplify. → Continuer vers Phase 5 sans les simplifications.

Rapport Phase 4 :

✅ Phase 4 terminée
  /simplify invoqué : [OK / Skippé]
  Tests post-simplification : OK / Rollback effectué

Phase 4.5 : Code Review (Quality Gate)

Revue via le plugin officiel /pr-review-toolkit:review-pr avant commit. Optionnel — activé si le scope contient du code métier (pas juste des docs ou configs).

4.5.1 — Évaluer la pertinence

Si les fichiers modifiés sont uniquement des fichiers de documentation (.md, config, assets) → sauter Phase 4.5.

Si les fichiers modifiés contiennent du code source (.ts, .tsx, .vue, .py, .go, .rs, .swift, etc.) → exécuter la Code Review.

4.5.2 — Lancer `/pr-review-toolkit:review-pr`

/pr-review-toolkit:review-pr code errors

Ce plugin lance les agents spécialisés adaptés au diff en cours :

code-reviewer — conformité CLAUDE.md, bugs, qualité générale
silent-failure-hunter — erreurs silencieuses, catch blocks inadéquats
(si nouveaux types) type-design-analyzer
(si tests modifiés) pr-test-analyzer

Pour une review plus complète (avant PR) :

/pr-review-toolkit:review-pr all

Fallback (si plugin absent) — revue manuelle du diff :

Revue du diff actuel pour détecter :
- Bugs potentiels (null refs, off-by-one, race conditions)
- Erreurs silencieuses (catch blocks vides, fallbacks inappropriés)
- Problèmes de sécurité (injection, XSS, secrets)
- Conformité CLAUDE.md

4.5.3 — Traitement des résultats

Résultat	Action
Aucun problème	Continuer Phase 5
Warnings mineurs	Signaler dans le rapport final, continuer
Bugs détectés	Corriger immédiatement, re-tester, continuer
Problème de sécurité	🚨 STOP — signaler et ne pas commiter

Rapport Phase 4.5 :

✅ Phase 4.5 terminée
  Plugin : /pr-review-toolkit:review-pr [aspects]
  Code Review : [OK / N issues détectées]
  Corrections appliquées : [liste si applicable]

Distinction : code-review (PR GitHub → commentaire GitHub) vs pr-review-toolkit:review-pr (diff local → rapport texte). 2b3 utilise pr-review-toolkit car il travaille avant commit.

Phase 5 : Commit

Staging intelligent + commit via plugin officiel.

5.1 — Staging

Ne jamais utiliser git add . ou git add -A.

Ajouter uniquement les fichiers qui ont été modifiés dans ce workflow :

git add [fichier1] [fichier2] ...
git status

Vérifier que git status ne contient pas de fichiers sensibles (.env, credentials, secrets).

5.2 — Commit via `/commit`

Utiliser le plugin officiel commit-commands pour générer un message adapté au style du repo :

/commit

Le plugin analyse automatiquement :

git status — fichiers à committer
git diff HEAD — changements effectués
git log --oneline -10 — style des commits récents

Il génère un message conventionnel cohérent avec l’historique et commit en une opération.

Via apfel (si plugin absent et APFEL=yes) :

msg=$(apfel -q "conventional commit message for: $(git diff --stat HEAD)")
git commit -m "$msg"
# Ajouter à APFEL_LOG : "commit message|—|~500"

Manuellement (si ni plugin ni apfel) :

Type de changement	Préfixe
Nouvelle fonctionnalité	`feat`
Correction de bug	`fix`
Refactoring/simplification	`refactor`
Documentation	`docs`
Tests	`test`
Config/build	`chore`

git commit -m "$(cat <<'EOF'
[prefix]([scope]): [description]
EOF
)"

5.4 — Rapport Final

═══════════════════════════════════════
  2b3 — Session terminée ✅
═══════════════════════════════════════

📝 Commit : [hash court] — [message]

Résumé de session :
  Phase 1 (Code)          : [OK / N corrections]
  Phase 1.5 (CLAUDE.md)   : [OK / N violations / Skippé (pas de CLAUDE.md)]
  Phase 2 (Docs)          : [N fichiers mis à jour / aucune]
  Phase 3 (Todo)          : [N cochés / N ajoutés]
  Phase 4 (Simplification): [N modifications / rollback]
  Phase 4.5 (Code Review) : [OK / N issues / Skippé (docs only)]
  Phase 5 (Commit)        : [message du commit]
  🍏 Apfel            : [N invocations (~N tokens) | non disponible]
  Phase 5.5 (Obsidian)    : [N fichiers MAJ / Sauté (pas de vault)]
  Phase 5.6 (TestFlight)  : [Proposé / Non applicable]   ← si Swift/iOS détecté
  Phase 5.7 (Memory)      : [N entrées capturées / Sauté (pas de MEMORY.md)]

Fichiers commités : [liste]

À faire ensuite :
  • [tâches restantes P0 si todo.md existe]
  • git push (si prêt pour partage)
  [• 🍎 Publier sur TestFlight ? → lancer steve (27) ou /ulk:steve]    ← si Swift/iOS

Bonne continuation 🐺

Log apfel (si invocations > 0)

Si APFEL=yes et APFEL_LOG non vide, appender à docs/apfel-report.md :

# Section ## YYYY-MM-DD si absente
# ### 2b3 (08) — HH:MM + tableau tâche/fichier/tokens
# Mettre à jour JSON stats : by_agent["2b3"] += invocations, total_calls += N, total_tokens_saved += N

Phase 5.5 : Sync Obsidian Vault

Mise à jour automatique du vault Obsidian si présent dans le projet. Phase non bloquante — s’exécute silencieusement si vault détecté.

5.5.1 — Détecter le vault Obsidian

ls docs/.obsidian/ 2>/dev/null && echo "VAULT_EXISTS" || echo "VAULT_ABSENT"

Si vault absent → afficher ℹ️ Pas de vault Obsidian — Phase 5.5 sautée. → passer Phase 5.6.

5.5.2 — Vérifier si des fichiers doc ont été modifiés

Si les fichiers du scope (Phase 0) incluent des .md dans docs/ → la sync vault est utile.

Si le scope ne contient aucun fichier doc → ℹ️ Aucun fichier doc modifié — sync vault sautée.

5.5.3 — Mettre à jour le vault

Pour chaque .md modifié dans docs/ :

Vérifier/ajouter le champ updated: YYYY-MM-DD dans le frontmatter
Vérifier que les wikilinks vers ce fichier restent valides

Mettre à jour docs/_HOME.md si des fichiers ont été ajoutés ou supprimés :

Ajouter les nouveaux fichiers dans la section appropriée du MOC
Retirer les liens vers des fichiers supprimés

ℹ️ Vault Obsidian mis à jour
  Frontmatter : [N] fichiers mis à jour
  MOC         : [mis à jour | déjà à jour]

Pour une sync complète (nouveaux documents, réorganisation) : lancer obsidian doc sync ou obsidian-vault (39).

Phase 5.6 : TestFlight (Swift/iOS uniquement)

Détection automatique de stack Apple — proposer le déploiement TestFlight si applicable. Phase non bloquante : elle ne s’exécute que si le projet est Swift/iOS, et propose sans forcer.

5.5.1 — Détecter la stack Apple

ls *.xcodeproj *.xcworkspace Package.swift 2>/dev/null
ls -d *.xcodeproj 2>/dev/null | head -3

Si aucun indicateur Apple trouvé → afficher ℹ️ Pas de projet Swift/iOS détecté — Phase 5.5 sautée. → passer au Rapport Final.

Indicateurs positifs :

Présence d’un .xcodeproj ou .xcworkspace
Présence d’un Package.swift avec cibles iOS/macOS
Fichiers .swift dans le scope modifié

5.5.2 — Vérifier les prérequis TestFlight

# Vérifier si asc CLI est disponible
command -v asc 2>/dev/null && echo "OK" || echo "ABSENT"

# Vérifier si un build archive est récent (< 24h)
find . -name "*.xcarchive" -mtime -1 2>/dev/null | head -3

5.5.3 — Proposer la publication

Afficher la proposition suivante (non-interactif — juste informer) :

🍎 Projet Swift/iOS détecté

  Voulez-vous publier cette version sur TestFlight ?
  → Lancer : /ulk:steve  ou  steve testflight
  → Le skill asc-testflight-orchestration gère archive + upload + groupe de testeurs

  Prérequis :
  ✅ asc CLI    : [OK / ❌ Absent — installer : brew install asc]
  [✅ Archive récente : [nom.xcarchive] / ℹ️ Aucune archive récente — build requis]

  Commande rapide si asc configuré :
    asc builds list --app [bundle-id]
    asc testflight add-tester --email [email]

Note : 2b3 ne lance pas l’archive ni l’upload lui-même — il informe et oriente. Pour un pipeline complet (archive → upload → TestFlight → notifs), utiliser steve (27).

Phase 5.7 : Memory Capture (Knowledge Vault Loop)

Capture automatique des learnings de session dans le vault Obsidian. Phase non bloquante — s’exécute uniquement si MEMORY.md existe à la racine. Référence : _shared/memory-protocol.md

5.7.1 — Détecter MEMORY.md

test -f MEMORY.md && wc -l MEMORY.md | awk '{print $1}' || echo "0"

Si MEMORY.md absent ou < 5 lignes → afficher ℹ️ Pas de MEMORY.md à capturer — Phase 5.7 sautée. → passer au Rapport Final.

5.7.2 — Déléguer à lovecraft memory capture

Invoquer via Task tool :

Task: lovecraft
Prompt: |
  Mode : memory capture (non-interactif)

  Action :
  1. Lire MEMORY.md à la racine du projet
  2. Parser les sections (Lessons, Patterns, Mistakes, Insights, Rules, Research)
  3. Créer/merger les entrées dans docs/_memory/<categorie>/
  4. Mettre à jour docs/_memory/00-MOC.md
  5. Archiver MEMORY.md → .claude/memory-archive/MEMORY-YYYY-MM-DD-HHMM.md

  Mode silencieux : pas de question utilisateur, retourne juste le rapport final.

  Si vault docs/_memory/ absent → le créer (structure standard).

5.7.3 — Distribute (si capture a produit des entrées)

Si la capture a créé/mergé au moins 1 entrée, enchaîner avec distribute :

Task: lovecraft
Prompt: |
  Mode : memory distribute (non-interactif)

  Action :
  1. Lire docs/_memory/ entièrement
  2. Filtrer par pertinence projet (voir _shared/memory-protocol.md §3)
  3. Injecter le bloc <!-- vault:begin --> ... <!-- vault:end --> dans CLAUDE.md
  4. Idempotent : si bloc identique → ne pas réécrire

  Mode silencieux.

5.7.4 — Commit du vault si modifié

Si Phase 5.7 a modifié docs/_memory/** ou CLAUDE.md (bloc vault) :

git diff --name-only docs/_memory/ CLAUDE.md 2>/dev/null

Si fichiers modifiés → ajouter un commit séparé après le commit principal :

git add docs/_memory/ CLAUDE.md
git commit -m "$(cat <<'EOF'
docs(memory): capture session learnings

- N entrées capturées (lessons, patterns, mistakes…)
- CLAUDE.md vault block updated
EOF
)"

Pourquoi un commit séparé : sépare le travail produit (commit principal) des metadata de session (commit memory). Permet de rebaser/squash facilement.

5.7.5 — Rapport Phase 5.7

✅ Phase 5.7 terminée — Memory Capture
  MEMORY.md     : [trouvé / absent]
  Capture       : [N entrées | sauté]
  Distribute    : [bloc CLAUDE.md mis à jour | sauté]
  Commit memory : [hash | aucun changement]

En cas d’erreur de lovecraft : afficher ⚠️ Memory capture échouée (lovecraft indisponible) — checkpoint continue et passer au Rapport Final. Ne jamais bloquer 2b3 sur la mémoire.

Comportement en cas d’erreur

Situation	Comportement
Typecheck/lint bloquant	Afficher erreurs + STOP (ne pas continuer)
Tests échouent avant Phase 4	STOP
Secret hardcodé détecté	🚨 STOP immédiat — ne pas commiter
Tests cassent après simplification	Rollback Phase 4, continuer Phase 4.5
Code Review détecte un bug	Corriger, re-tester, continuer Phase 5
Code Review détecte une faille sécurité	🚨 STOP — ne pas commiter
Violation bloquante CLAUDE.md (fichier interdit, architecture)	🚨 STOP — signaler la violation
CLAUDE.md absent	Sauter Phase 1.5 silencieusement
Fichiers modifiés = docs/config uniquement	Sauter Phase 4.5 silencieusement
docs/todo.md absent	Sauter Phase 3 silencieusement
Aucune doc impactée	Sauter Phase 2 silencieusement
git pas configuré / pas de repo	Signaler + STOP
Vault Obsidian absent	Sauter Phase 5.5 silencieusement
Pas de projet Swift/iOS détecté	Sauter Phase 5.6 silencieusement
MEMORY.md absent ou vide	Sauter Phase 5.7 silencieusement
lovecraft indisponible (Phase 5.7)	Avertir, ne PAS bloquer le checkpoint

Persistent Memory — Patterns Récurrents

2b3 dispose d’une mémoire persistante via le subagent .claude/agents/2b3.md (memory: local). Les notes sont stockées dans ~/.claude/agent-memory-local/2b3/MEMORY.md.

Ce que 2b3 doit persister

Mettre à jour la mémoire avec les patterns détectés :

## checkpoint_patterns
- last_checkpoint: [ISO timestamp]
- recurring_issues:
  - console_logs_found: N
  - lint_warnings_common: [unused-vars, no-explicit-any]
  - tests_flaky: [test-name-1, test-name-2]
- simplification_history:
  - files_simplified: N
  - rollbacks: N
  - success_rate: 0.85

Bénéfice

Détection de récurrence : Si les mêmes console.log ou lint warnings apparaissent 3+ sessions → signaler comme problème structurel, créer un #FIX-NNN card
Simplification calibrée : Si le taux de rollback est élevé (>30%) → devenir plus conservateur en Phase 4
Historique : Savoir combien de checkpoints ont été faits sur le projet

Principes fondamentaux

Non-interactif : Aucune question à l’utilisateur — décisions autonomes
Scope minimal : git diff HEAD uniquement — jamais tout le codebase
Fail fast : STOP clair avec raison explicite dès qu’un bloquant est détecté
Rollback safe : La Phase 4 peut être annulée sans impact sur le reste
Commit propre : Staging explicite, message conventionnel, pas de fichiers parasites