@neikyun/ciel 6.10.1 → 6.11.1

package/assets/skills/workflow/critiquer-auditor/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: critiquer-auditor
+description: How to audit code comprehensively — 7-dimension review methodology covering expected behavior, assumptions, scope, code-vs-model comparison, STRIDE security, pattern consistency, and findings with severity. For PR reviews, retrospective audits, and "is this code correct?" questions.
+allowed-tools: Read, Grep, Glob, Bash, WebSearch
+---
+
+# Code Audit — 7-Dimension Review Methodology
+
+## What this covers
+
+How to do a thorough code audit. Distinct from quick self-review (relire-critic) — this is the comprehensive methodology for PR reviews, retrospective audits, and quality checks.
+
+## Core principle
+
+**Read the diff/changed files FIRST.** All dimensions operate on actual code, never on assumptions. Description lies; code doesn't.
+
+## Dimension 1: Expected behavior model
+
+From issue/spec/PR description: "what was this SUPPOSED to do?"
+
+- Build a bypass signal checklist for this change type BEFORE scanning code
+- If external lib involved: search `[lib] [version] anti-patterns common mistakes`
+
+Output: 1-2 sentence behavior model + min 3 bypass signals to look for.
+
+## Dimension 2: Assumptions
+
+- Git blame: why was the original code written this way?
+- Surface 3 assumptions, verify each (grep / blame / read)
+
+Output: 3 assumptions + verification status each.
+
+## Dimension 3: Scope
+
+- "What if we do nothing?" considered?
+- Scope of change proportional to the problem?
+
+Output: counterfactual + proportionality judgment.
+
+## Dimension 4: Code vs model + STRIDE + OPS
+
+- Code matches expected behavior model? (grep-backed)
+- All bypass signals checked from dimension 1's list?
+- **STRIDE all 6 categories**: S / T / R / I / D / E — mark N/A explicitly, never skip silently
+- OPS lens: unclosed connections, memory leaks, locks, 100x volume
+
+### STRIDE reference
+
+| Category | What to check |
+|----------|--------------|
+| **S**poofing | Authentication bypass, identity assumption |
+| **T**ampering | Data integrity, unauthorized modification |
+| **R**epudiation | Audit trail, logging completeness |
+| **I**nformation disclosure | Data exposure, error messages, logs |
+| **D**enial of service | Resource exhaustion, infinite loops, missing limits |
+| **E**levation of privilege | Authorization bypass, role escalation |
+
+## Dimension 5: Consistency
+
+- Grep: pattern used consistently elsewhere in the codebase?
+- Layer boundaries respected (no business logic in routes, no DB in controllers)?
+- Health thresholds from overlay met (complexity, coverage)?
+
+## Dimension 6: Findings with severity
+
+Format: `RISQUE: X parce que Y — IMPACT: Z`
+
+Severity levels:
+- **BLOCKING** — must fix before merge (correctness, security, data loss). Requires specific FIX.
+- **IMPORTANT** — should fix (degraded behavior, tech debt with near-term risk)
+- **MINOR** — nice to fix (style, naming, low-risk improvement)
+- **VALIDATED** — explicitly checked and confirmed correct
+
+Every finding: RISQUE format. Every BLOCKING: specific FIX + NOT-X (what solution must NOT do).
+
+## Dimension 7: Close the loop
+
+- New anti-pattern found? → add to Guards or project overlay
+- New failure mode? → add Guard immediately
+- Capture learnings for future reference
+
+## Output format
+
+```
+## AUDIT
+
+### Expected behavior
+<1-2 sentences + bypass signals>
+
+### Assumptions
+1. <assumption> — verified: <yes/no, evidence>
+2. ...
+3. ...
+
+### Scope
+- Nothing-counterfactual: <consequence if no change>
+- Scope proportional: <yes/no, reason>
+
+### Code vs model + STRIDE
+- Code vs model: <matches | deviates at file:line>
+- Bypass signals: <N/3 flagged>
+- STRIDE:
+  - S: <N/A because X | RISQUE: ...>
+  - T/R/I/D/E: ...
+
+### Consistency
+- Pattern: <grep evidence>
+- Layers: <clean | violation at file:line>
+- Thresholds: <met | violation>
+
+### Findings
+BLOCKING: <RISQUE + FIX>
+IMPORTANT: <RISQUE + FIX/ACCEPT>
+MINOR: <note>
+VALIDATED: <what was verified>
+
+### Learnings
+- New Guard: <yes/no>
+- Overlay update: <yes/no>
+```
+
+## How to verify
+
+- [ ] All 7 dimensions completed (Expected behavior, Assumptions, Scope, Code vs model + STRIDE, Consistency, Findings, Learnings)?
+- [ ] All 6 STRIDE categories present (even if N/A)?
+- [ ] Findings have severity (BLOCKING/IMPORTANT/MINOR)?
+- [ ] VALIDATED section identifies what code got right?
+- [ ] Learnings captured?
+
+## Common mistakes
+
+- **Operating from PR description alone**: always read the actual code
+- **Skipping STRIDE categories**: all 6 must be explicit, even if N/A
+- **BLOCKING without FIX**: if you can't name the fix, it's not actionable enough for BLOCKING
+- **No VALIDATED section**: reviews that only report problems miss what the code got right

package/assets/skills/workflow/critiquer-auditor/reference.md

@@ -0,0 +1,134 @@
+# critiquer-auditor — Reference
+
+## STRIDE — audit probes (7-step audit context)
+
+Use these probes when running COMPARER on each STRIDE category. Mark N/A explicitly; never skip.
+
+### S — Spoofing
+- Can I impersonate another user/service in this code path?
+- Identity: client-supplied or server-resolved?
+- WebSocket / SSE / GraphQL subscription: same auth as REST?
+
+### T — Tampering
+- Input modified in transit? HTTPS? Signatures?
+- Idempotency keys present?
+- CSRF protection on state-changing endpoints?
+
+### R — Repudiation
+- Audit log coverage: who, what, when recorded?
+- Log integrity: append-only? remote-shipped?
+
+### I — Information Disclosure
+- Error messages: stack traces? SQL? paths?
+- Logs: PII? secrets?
+- Response bodies: over-fetching? unprojected columns?
+- Timing attacks: 404 vs 403 distinction?
+
+### D — Denial of Service
+- Rate limiting per IP/user/endpoint?
+- Resource bounds: payload size, query depth, file upload?
+- Algorithmic complexity on user-controlled input?
+- Regex catastrophic backtracking?
+
+### E — Elevation of Privilege
+- Permission check BEFORE action?
+- Horizontal escalation: user A read user B's data?
+- Vertical escalation: mass assignment setting `isAdmin`?
+
+## Severity rubric
+
+### BLOCKING
+- Correctness bug: code produces wrong result for some input
+- Security: any STRIDE finding that an attacker can exploit
+- Data loss: delete/overwrite without backup/confirm
+- Production crash: uncaught exception on common path
+
+### IMPORTANT
+- Degraded behavior: works but slow / intermittent
+- Tech debt with near-term risk: pattern that will break at 2x current load
+- Accessibility violation: keyboard/screen reader broken
+- Test debt: feature ships without meaningful test
+
+### MINOR
+- Naming / style inconsistency
+- Unused import
+- Todo comment for future work
+- Minor DRY violation (< 3 copies)
+
+### VALIDATED
+- Explicit callout of what was checked and confirmed correct
+- Useful because it shows the reviewer's mental map
+- Helps author understand what was covered vs skipped
+
+## Counterfactual analysis
+
+Questions to answer in QUESTIONNER step:
+
+- What if we merged without this change? What breaks?
+- Is there a 10% of this change that would solve 90% of the problem?
+- Is this fixing a symptom or a cause? If symptom: where's the cause?
+- Is this change reversible? If yes, risk is lower.
+
+## Bypass signal checklist (build in APPRENDRE)
+
+Common bypass signals to look for per framework:
+
+### React / frontend
+- `window.*` or `document.*` inside components
+- `useEffect` with no dependency array
+- Direct DOM manipulation via `refs.current`
+- `dangerouslySetInnerHTML` with non-sanitized input
+
+### Backend / JVM
+- Raw SQL string concatenation
+- `catch(Exception e) { }` or `catch → null`
+- `as` cast without type guard (Kotlin) or unchecked cast (Java)
+- Thread creation without pool
+
+### Async / concurrent
+- `async` function called without `await`
+- Promise created but not awaited
+- Race conditions on shared state
+- Timeout of 0 or infinite
+
+## Layer boundary violations
+
+- Business logic in routes / controllers → should be in services
+- DB calls in controllers → should be behind repository
+- UI logic in models → should be in view layer
+- Tests reaching across layers without mocks
+
+## Overlay thresholds
+
+If `ciel-overlay.md` exists under `## Santé du code`, check its thresholds:
+
+```
+### Santé du code
+- Complexité cyclomatique: < 15 par fonction
+- Profondeur d'imbrication: < 4
+- Taille de fonction: < 50 lignes
+- Couverture test: > 80% lignes modifiées
+```
+
+If any violation: IMPORTANT finding (can be demoted to MINOR if tiny exceedance).
+
+## Capitalization format
+
+When `learnings-capture` is invoked from CAPITALISER:
+
+```
+[YYYY-MM-DD] MISTAKE: <what happened, 1 line>
+  → RULE: <how to avoid in future, 1 line>
+  → Invoke: <which skill/guard catches this>
+  → Evidence: <file:line where it was found>
+```
+
+This format feeds into `ciel-overlay.md` under `## Leçons projet` (project-specific) or `.claude/learnings.md` (general).
+
+## Anti-patterns in audits
+
+- Reviewing without reading the diff first → operate on assumptions
+- STRIDE performed but all 6 "N/A" → didn't actually probe each category
+- Only finding problems (no VALIDATED) → unclear what was checked
+- BLOCKING without FIX → not actionable, author can't resolve
+- Copying PR description into audit → pure theater, no independent thought

package/assets/skills/workflow/debug-reasoning-rca/SKILL.md

@@ -0,0 +1,174 @@
+---
+name: debug-reasoning-rca
+description: How to debug systematically — hypothesis-driven root cause analysis methodology. 3 parallel hypotheses, fault-type taxonomy (model/context/orchestration/environment), semantic diff between expected and actual behavior. For bugs, incidents, flaky tests, regressions, production failures.
+allowed-tools: Read, Grep, Glob, Bash
+---
+
+# Systematic Debugging — Root Cause Analysis Methodology
+
+## What this covers
+
+How to find the real cause of a bug, not just patch the symptom. Default LLM failure: jump to the first plausible fix. Proper debugging is hypothesis-driven (Hunt & Thomas) and catches 75% more recurrences (STRATUS 2025).
+
+## Core principle
+
+**Never propose a fix before a hypothesis is SUPPORTED by evidence.** "It might be this, let me fix it" is forbidden.
+
+## Step 1: Gather context
+
+Before hypothesizing, understand the failure:
+
+- **Read the error literally** — stack trace, log line, exit code. What does the system actually say?
+- **Read the failing code** at the exact `file:line` from the trace
+- **Check recent changes** — `git log -p --since="7 days ago" -- <scope>`. A recent bug usually has a recent cause.
+- **Run the repro** once and capture full output
+
+Skip this step = hypotheses based on vibes.
+
+## Step 2: Generate 3 hypotheses
+
+Generate EXACTLY 3 **causally distinct** hypotheses. Not 3 variants of the same theory.
+
+Format:
+```
+H<n>: <cause> → <mechanism> → <observable effect>
+  Evidence for: <what would be true if correct>
+  Evidence against: <what would be true if wrong>
+  Fault-type: [MODEL | CONTEXT | ORCHESTRATION | ENVIRONMENT]
+```
+
+### Fault-type taxonomy
+
+| Type | What it means | Example |
+|------|--------------|---------|
+| **MODEL** | Code logic wrong | Off-by-one, wrong algorithm, wrong assumption |
+| **CONTEXT** | Missing/stale input | Wrong config, race window, state leak |
+| **ORCHESTRATION** | Infrastructure misconfigured | Retry/timeout wrong, queue backlog |
+| **ENVIRONMENT** | External change | Dependency drift, OS change, infra outage |
+
+**Distribution rule**: hypotheses must span AT LEAST 2 fault-types. Three MODEL hypotheses = tunnel vision.
+
+## Step 3: Validate (targeted checks)
+
+For each hypothesis, run ONE targeted check (not fix):
+
+- MODEL → add a log line or unit test asserting the expected invariant
+- CONTEXT → dump actual input/config at failure point; diff vs expected
+- ORCHESTRATION → check retry count, timeout, queue depth at failure time
+- ENVIRONMENT → `<pkg-mgr> list | grep <dep>` vs lockfile; `uname -a`
+
+Record: evidence collected, hypothesis supported/refuted/inconclusive.
+
+## Step 4: Semantic diff
+
+Once supported, write the diff between expected and actual:
+
+```
+EXPECTED: <behavior that should happen>
+ACTUAL:   <behavior that happens>
+GAP:      <precise mechanism>
+ROOT:     <why the gap exists — not "because of the bug", the underlying why>
+```
+
+If ROOT reads like "because the code is buggy" — you've only found the symptom. Ask "why" again.
+
+## Step 5: Fix (two layers)
+
+- **Direct fix** — address the supported hypothesis (the bug itself)
+- **Systemic fix** — address why the bug was possible (missing test, missing alert, missing type)
+
+Systemic fix is the 75% MTTR-reduction lever. Don't skip it on Critical bugs.
+
+## Output format
+
+```
+## RCA VERDICT
+
+### Symptom
+<1 sentence>
+
+### Repro
+<exact command or "flaky — triggers ~1/N runs">
+
+### Hypotheses explored
+H1 [MODEL]: <cause> — <supported|refuted|inconclusive> — <evidence>
+H2 [CONTEXT]: <cause> — <supported|refuted|inconclusive> — <evidence>
+H3 [ORCHESTRATION]: <cause> — <supported|refuted|inconclusive> — <evidence>
+
+### Root cause
+<hypothesis number>: <cause>
+
+### Semantic diff
+EXPECTED/ACTUAL/GAP/ROOT
+
+### Fix
+- Direct: <exact code change>
+- Systemic: <test/alert/process to add>
+
+### Confidence
+HIGH | MEDIUM | LOW — <why>
+```
+
+## Auto-inference (before asking the user)
+
+Exhaust these sources before flagging input as unknown:
+
+- **SYMPTOM** → grep last error in user's prompt; tail service logs; check recent PR descriptions
+- **REPRO** → read `package.json` scripts, `Makefile`, `README.md`, test files, CI workflow
+- **SCOPE** → `git diff HEAD~10 --stat` then rank by overlap with symptom keywords
+- **RECENT_CHANGES** → `git log --since="7 days ago" --oneline -- <scope>`
+
+State inferred values as `[ASSUMED from <source>]`. Only flag as `[UNKNOWN]` if truly blocking.
+
+## How to verify
+
+- [ ] ≥ 3 hypotheses generated (not just 1)?
+- [ ] Each hypothesis has a fault type from the taxonomy?
+- [ ] Semantic diff completed (EXPECTED vs ACTUAL vs GAP)?
+- [ ] Root cause identified with evidence (file:line)?
+- [ ] Fix addresses root cause, not symptom?
+- [ ] Confidence level stated (HIGH/MEDIUM/LOW)?
+
+## Anti-patterns
+
+- **Patch-the-symptom**: add try/catch without understanding WHY it failed
+- **Fix-the-test**: modify assertion to match wrong behavior instead of fixing code
+- **Guess-and-check**: 5 commits titled "try fix" — no hypothesis discipline
+- **First-hypothesis-wins**: commit first theory without validating alternatives
+- **No repro, no RCA**: chasing intermittent bugs without deterministic repro burns hours
+
+## Structured RCA methods (complementary)
+
+The 3-hypothesis method above is the default — fast, hypothesis-driven, good for most bugs. For complex, recurrent, or systemic problems, these structured RCA methods add depth.
+
+### Decision guide
+
+| Problem type | Method | Why |
+|-------------|--------|-----|
+| Linear, single-symptom | **3 hypotheses** (default) | Fastest — parallel hypotheses, minimal overhead |
+| Recurrent incident, process failure | **5 Whys** | Iterative questioning reaches systemic root cause |
+| Multi-factor, need exhaustive exploration | **Ishikawa (Fishbone)** | 6M families (Method/Machine/Manpower/Material/Milieu/Measurement) guide complete coverage |
+| Multi-layer, complex system | **Drill Down / Tree Diagram** | Decompose recursively (build → deploy → runtime → data) into atomic sub-causes; visualize as tree |
+| Interacting causes, feedback loops | **Relations Diagram** | Map causal links, count outbound/inbound arrows to find drivers vs effects |
+
+**When to use the full sequence**: if the problem involves ≥ 3 interacting factors across distinct system layers, use the full chain: Ishikawa (explore) → Relations Diagram (map interactions) → 5 Whys on each promising node → Tree Diagram (document). For simpler problems, pick one method from the guide.
+
+### 5 Whys
+
+Ask "why?" iteratively (5× typical) on the symptom. Each answer becomes the next question. Stop when the cause is systemic/process-level, not technical. **Anti-pattern**: stopping at "error 500" — the real cause may be "no integration test catches this path."
+
+### Ishikawa (Fishbone)
+
+Draw a horizontal spine ending at the problem (fish head). Add diagonal bones for 6 families: Method, Machine, Manpower, Material, Milieu, Measurement (adapt to software: Technology, Data/API). Branch sub-causes off each family. **Anti-pattern**: filling every family superficially — depth > breadth.
+
+### Drill Down / Tree Diagram
+
+Decompose the problem into 2-4 MECE sub-causes at each level, recursing until atomic (directly fixable). Visualize the result as a hierarchical tree with AND/OR logic per branch. These are the same analytical process — decomposition (Drill Down) and visualization (Tree Diagram). **Anti-pattern**: stopping at shallow levels — "module X crashes" isn't actionable, "method Y throws Z when condition W" is.
+
+### Relations Diagram
+
+List all discovered factors. For each pair, ask if causation exists and in which direction. Draw arrows. Count outbound (drivers) vs inbound (effects). Nodes with the most outbound arrows are root cause candidates. **Anti-pattern**: connecting everything — if most factors connect to most others, the diagram is not discriminating; focus on clear causal links only.
+
+## Key insight
+
+The hardest part of debugging is not finding the fix — it's resisting the urge to fix before understanding. The 3-hypothesis discipline forces you to consider alternatives before committing to one.

package/assets/skills/workflow/depth-classifier/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: depth-classifier
+description: Classifies a coding task as Trivial, Standard, or Critical based on mechanical signals (auth paths, security code, DB tables, diff size, route handlers). Use at the start of every Ciel workflow to determine which downstream skills to invoke. Returns a one-word depth + rationale + pipeline recommendation.
+allowed-tools: Read, Grep, Glob
+---
+
+# depth-classifier — Classify task depth
+
+Gatekeeper skill at the entry of every Ciel workflow. Wrong classification = wrong depth = either waste (over-processing trivial) or risk (under-processing critical).
+
+---
+
+## Inputs
+
+- **task**: the task description in natural language (from `/ciel <task>` or user message)
+- **project-root** (optional): absolute path, defaults to CWD
+- **overlay** (optional): `ciel-overlay.md` content if available
+
+---
+
+## Classification signals
+
+### Critical if ANY match:
+
+- Path patterns: `auth/`, `security/`, `Token`, `Password`, `Secret`, `Session`, `Crypto`
+- DB table names: `users`, `sessions`, `tokens`, `accounts`, `credentials`, `2fa`, `api_keys`
+- Code patterns: `.executeQuery`, `.executeUpdate`, raw SQL, `userId` (server-provided vs client-provided), `role`, `permission`
+- Task keywords: "authentication", "authorization", "payment", "migration (DB schema)", "JWT", "OAuth", "encryption", "2FA", "session"
+- Scope: touches user data, money, audit trails
+
+### Standard if ANY match (and not Critical):
+
+- Path patterns: `routes/`, `controllers/`, `services/`, `components/`, `hooks/`
+- **CI/CD & pipeline files**: `.github/workflows/*.yml`, `.gitlab-ci.yml`, `.circleci/`, `Dockerfile`, `docker-compose*.yml`, `Jenkinsfile`, `.buildkite/`, `.drone.yml`
+- **PR-review signals**:
+  - Prompt contains a PR number (`#\d+`, `PR \d+`, `pull request \d+`) OR phrases "open PR", "review PR", "fix PR", "merge PR"
+  - Planned tool calls include `gh pr list`, `gh pr view`, `gh pr checks`, `gh pr review`, `gh pr merge` (any variant: `--auto`, `--squash`, `--merge`, `--rebase`)
+  - Planned edits touch any CI/CD pipeline file (see row above)
+- Diff scope (estimated): > 1 file OR > 50 lines change
+- Code patterns: `validate`, `sanitize`, `rateLimit`, route handlers, state management
+- Task keywords: "add endpoint", "new component", "refactor", "extract helper", "feature", "integration"
+
+**Floor rule**: if ANY PR-review signal OR any CI/CD-file signal is present, depth is **at minimum Standard** — Trivial is disqualified even if the diff is small. PR review plus CI fix is never "just a one-line change".
+
+### Trivial otherwise:
+
+- Rename, typo, 1-line fix, copyright update, README edit
+- Single-file localized change ≤ 10 lines
+- No business logic change
+
+### Default rule
+
+If unsure → **Standard**. If touching user data or auth → **Critical**.
+
+---
+
+## Pipeline recommendations
+
+Return pipeline for each depth:
+
+### Trivial
+`quoi-framer` → `pattern-fitness-check` → `faire-gatekeeper` → `relire-critic` (inline) → push → `meta-critiquer`
+
+### Standard
+`quoi-framer` → `avec-quoi-versioner` → [researcher agent + explorer agent IN PARALLEL] → `evaluer-sizer` → `faire-gatekeeper` → `critic` agent MODE=RELIRE → `prouver-verifier` → `meta-critiquer`
+
+### Critical
+All of Standard + `stride-analyzer` (after `avec-quoi-versioner`) + `security-regression-check` (between FAIRE and RELIRE) + critic agent MANDATORY
+
+---
+
+## Output format
+
+```
+## DEPTH CLASSIFICATION
+
+Depth: **Trivial | Standard | Critical**
+
+Signals detected:
+- [signal 1 with source — e.g. "path matches /auth/"]
+- [signal 2]
+
+Rationale: [1-2 sentences]
+
+Pipeline:
+1. <skill>
+2. <skill>
+...
+
+Agents required:
+- [researcher: yes/no]
+- [explorer: yes/no]
+- [critic: yes/no]
+```
+
+---
+
+## Guardrails
+
+- **Asymmetric bias**: when borderline between Trivial/Standard → Standard wins. When borderline between Standard/Critical → Critical wins. Missing a Critical is worse than over-processing a Standard.
+- **Auth/security override**: any mention of auth, credentials, tokens, or user identity → Critical regardless of diff size
+- **Single-line fix can still be Critical**: e.g. a 1-char fix in an auth check is Critical
+- **Don't infer from filename alone**: `UserService.kt` could be Trivial if the change is a rename. Look at the actual code change being proposed.
+
+---
+
+## How to verify
+
+- [ ] Classification signals checked (Critical, Standard, Trivial)?
+- [ ] Pipeline recommendation provided?
+- [ ] Default rule applied (Unsure → Standard)?
+- [ ] Auth/security files → Critical?
+
+## When triggered
+
+- Automatically at start of `/ciel <task>` via the `ciel` orchestrator
+- By `UserPromptSubmit` hook (light classification hint injected into context)
+- Explicitly when depth is ambiguous after initial assessment

package/assets/skills/workflow/diverge/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: diverge
+description: How to explore 2-3 radically different approaches before choosing one (Ciel v5 etape 5). Used after AVEC QUOI, before RECHERCHE. Prevents single-approach bias and premature convergence. Use when the task is non-trivial and there are multiple valid approaches.
+---
+
+# Divergent Exploration — 2-3 Approaches Before Choosing (Ciel v5)
+
+## What this covers
+
+How to explore multiple approaches before committing to one. In Ciel v5, this is etape 5 (DIVERGE). The goal is to avoid premature convergence on the first viable approach that comes to mind.
+
+## Core principle
+
+**Generate 2-3 approaches before evaluating any of them.** The first approach that works is rarely the best. In v5, DIVERGE happens after AVEC QUOI (versions checked) and before RECHERCHE (external research).
+
+## When to use
+
+- Non-trivial tasks with multiple valid solutions
+- Architectural decisions
+- Library/framework choices
+- Design patterns
+- Database schema design
+- API design
+
+**When NOT to use**: 1-line fix, rename, trivial config change, obvious solution.
+
+## The process
+
+### Step 1: Generate at least 2 approaches
+
+For each approach, describe:
+- What it does (1-2 sentences)
+- Key trade-offs (not "it's better" -- specific pros/cons)
+- Implementation effort (rough estimate)
+- Risk level (low/medium/high)
+
+Approaches should be GENUINELY different. Not "use React vs use React with hooks" -- same approach. Bad:
+- "Use PostgreSQL vs MySQL" (trivial database choice)
+- "Use REST vs GraphQL" (genuinely different)
+
+### Step 2: Let them compete (not you decide)
+
+Generate approaches WITHOUT evaluating them. Evaluation happens in EVALUER (etape 9), after RECHERCHE has gathered external data about each approach.
+
+Common trap: generating 2 approaches but immediately choosing the first one without research.
+
+### Step 3: Document for EVALUER
+
+Pass both approaches (with their trade-offs, effort, risk) to the EVALUER phase. The researcher should check documentation for BOTH approaches.
+
+## Output format
+
+```
+## DIVERGE
+
+### Approach A: <name>
+What: <1-2 sentences>
+Trade-offs:
+  + <pro>
+  - <con>
+Effort: <XS/S/M/L/XL>
+Risk: <low/medium/high>
+
+### Approach B: <name>
+What: <1-2 sentences>
+Trade-offs:
+  + <pro>
+  - <con>
+Effort: <XS/S/M/L/XL>
+Risk: <low/medium/high>
+
+### (Optional) Approach C: <name>
+...
+```
+
+## Common rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "I already know the best approach" | You know the first approach that came to mind. That's not the same as the best approach. Generate 2-3 then compare. |
+| "Diverging takes too long" | It takes 5 minutes. Committing to the wrong approach costs days. The math is clear. |
+| "There's only one valid way to do this" | There are almost always 2+ valid approaches. If you can't think of alternatives, you don't understand the problem well enough. |
+
+## How to verify
+
+- [ ] >= 2 genuinely different approaches generated?
+- [ ] Approaches are different in kind, not degree?
+- [ ] Trade-offs documented for each?
+- [ ] Effort estimated?
+- [ ] Risk assessed?
+- [ ] Evaluation deferred to next phase (EVALUER)?