@neikyun/ciel 6.11.0 → 6.11.1

package/assets/skills/workflow/ask-window/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: ask-window
+description: How to use the ASK window in Ciel v5 — before coding, clarify ambiguities using the question tool (OpenCode) or plan mode (Claude Code). Covers etapes 3 (ASK) and 10 (ASK2) of the pipeline. Prevents coding on assumptions.
+---
+
+# ASK Window — Clarify Before You Code (Ciel v5)
+
+## What this covers
+
+How to use the ASK window in the Ciel v5 pipeline. Before coding, the agent must ask clarifying questions rather than assuming. This skill covers etapes 3 (ASK after QUOI) and 10 (ASK2 after EVALUER).
+
+## Core principle
+
+**Do not code on assumptions.** When requirements are ambiguous, parameters undefined, or choices implicit -> ask. Use the question tool (OpenCode) or plan mode (Claude Code).
+
+## Two modes — when to use which
+
+```
+MODE ASK  (step 3)   → "What should I build?"     → after QUOI, before research
+MODE ASK2 (step 10)  → "Should I build this way?"  → after EVALUER, before coding
+```
+
+ASK is about **requirements** — clarify what to build. ASK2 is about **the plan** — validate how to build it.
+
+### ASK (step 3) — clarify requirements
+
+After QUOI, before any research or coding. Questions are about the **what**, not the **how**:
+
+- Requirements: "Is the email field required?"
+- Ambiguities: "Session cookie or JWT?"
+- Assumptions: "I assume the database is PostgreSQL, correct?"
+- Missing info: "What is the expected throughput?"
+- Scope boundaries: "Does this include the admin panel?"
+
+### ASK2 (step 10) — validate the plan
+
+After EVALUER, before FAIRE. Questions are about the **approach**, not the **requirements**:
+
+- Approach validation: "I'm going with approach A because X. OK?"
+- Trade-off validation: "Approach A is simpler but B is more flexible. OK with A?"
+- Risk confirmation: "The main risk is X. Acceptable?"
+- Effort check: "This will take ~2 hours. OK?"
+
+## How to ask
+
+### OpenCode: use the `question` tool
+
+The `question` tool is a built-in OpenCode tool. Each question includes:
+1. A header (category of question)
+2. The question text
+3. A list of options (at least 2)
+4. A custom answer option
+
+Example:
+```
+Tool: question
+Parameters:
+  header: "Database choice"
+  question: "Which database should we use for the new feature?"
+  options: ["PostgreSQL (existing)", "SQLite (simpler)", "MySQL (new)"]
+```
+
+### Claude Code: use plan mode
+
+In Claude Code, switch to plan mode (Tab key), then:
+1. List your assumptions explicitly
+2. Ask questions one at a time
+3. Wait for answers before proceeding
+4. Update the plan based on responses
+
+## Structure of a good question
+
+```
+QUESTION CATEGORY: <requirement | assumption | tradeoff | risk | scope>
+
+Context: <1-2 sentences explaining why you're asking>
+
+Question: <clear, specific question>
+
+Options:
+  A: <option>
+  B: <option>
+  C: <other> (if relevant)
+```
+
+## What NOT to ask
+
+- Things you can discover yourself (read the code, check package.json)
+- Trivial preferences that don't affect the design (naming, formatting)
+- The same question twice (check your previous answers)
+- Questions you already have the answer to (check .ciel/memory.json, overlay)
+
+## Output format
+
+After the ASK phase, include in the plan:
+
+```
+## Questions asked (ASK)
+
+1. <question> -> <answer selected>
+2. <question> -> <custom answer>
+```
+
+## Common rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "I'll just assume and fix it later" | Later is when it's in production and costs 10x to fix. Asking now costs 30 seconds. |
+| "The user would have told me if it mattered" | Users don't know what they don't specify. Assumptions are silent bugs waiting to surface. |
+| "I can figure it out from the code" | Code tells you WHAT, not WHY. If there are two valid approaches, code can't tell you which one the project prefers. |
+| "Asking makes me look uncertain" | Coding on wrong assumptions makes you look incompetent. Asking is what senior engineers do. |
+
+## How to verify
+
+- [ ] All unclear requirements have been asked about?
+- [ ] Assumptions have been validated (not silently filled)?
+- [ ] Trade-offs have been offered to the user?
+- [ ] Questions are specific, not vague ("what do you think?")
+- [ ] Answers are captured in the plan?

package/assets/skills/workflow/avec-quoi-versioner/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: avec-quoi-versioner
+description: Reads actual installed library versions from package.json, build.gradle, go.mod, Cargo.toml, pyproject.toml, Gemfile.lock — never trusts memory or assumptions. Loads ciel-overlay.md if present for project-specific stack context. Invoked before research to ensure all subsequent docs lookups target the correct versions.
+allowed-tools: Read, Grep, Glob, Bash
+---
+
+# avec-quoi-versioner — Read real installed versions
+
+Step 2 of CRÉER. The research quality is bounded by version accuracy. A skill that looks up "Ktor 2.x docs" when the project runs Ktor 3.x produces anti-patterns.
+
+---
+
+## Process
+
+### 1. Detect package manager(s)
+
+Scan project root for the following files (in order):
+
+| File | Stack |
+|------|-------|
+| `package.json` + `package-lock.json` | npm / Node.js |
+| `package.json` + `yarn.lock` | yarn |
+| `package.json` + `pnpm-lock.yaml` | pnpm |
+| `package.json` + `bun.lockb` | bun |
+| `build.gradle.kts` / `build.gradle` | JVM / Gradle |
+| `pom.xml` | Maven |
+| `go.mod` + `go.sum` | Go |
+| `Cargo.toml` + `Cargo.lock` | Rust |
+| `pyproject.toml` + `poetry.lock` / `uv.lock` | Python |
+| `requirements.txt` | Python (pip) |
+| `Gemfile` + `Gemfile.lock` | Ruby |
+| `composer.json` | PHP |
+| `Package.swift` / `Package.resolved` | Swift |
+
+Multiple lockfiles may exist (monorepo). Read them all.
+
+### 2. Extract exact versions (not semver ranges)
+
+For each relevant dependency in the task scope:
+
+- Read the **lockfile** for the pinned version (not `package.json`'s range)
+- For Gradle, run `./gradlew dependencies` if needed, or read `gradle.properties`
+- For Go, `go.mod` already pins; verify with `go list -m all`
+- For Maven, effective POM: `mvn help:effective-pom`
+
+### 3. Load ciel-overlay.md
+
+If present at project root, extract:
+
+- `## Stack` section — project's declared stack
+- `## Versions` section — URLs to docs
+- Any project-specific rules in `## Règles projet-spécifiques`
+
+### 4. State assumptions explicitly
+
+For anything NOT verified from lockfile:
+
+- "Assuming build tool X because [reason]."
+- "Assuming PostgreSQL is running on default port because [reason]."
+
+These assumptions must be flagged for `researcher` to verify.
+
+---
+
+## Output format
+
+```
+## AVEC QUOI
+
+Stack detected:
+- Frontend: <framework> <version> (from <file>)
+- Backend: <framework> <version> (from <file>)
+- Database: <type> <version> (from <file or overlay>)
+- Test: <framework> <version> (from <file>)
+- Build: <tool> <version>
+
+Overlay:
+- [Loaded: yes/no]
+- [Relevant sections: Stack, Versions, Règles, Leçons]
+
+Assumptions (NOT from lockfile):
+- <assumption> — <reason>
+
+Docs URLs (from overlay):
+- <lib>: <url>
+```
+
+---
+
+## Guardrails
+
+- **Never assume a version** — if lockfile is absent, state "version unknown" and flag it
+- **Range vs pinned**: always report the pinned version from the lockfile, not the `^1.2.3` range from the manifest
+- **Monorepo caution**: multiple lockfiles may diverge across packages. Specify which package the version applies to.
+- **Don't guess URLs**: only report doc URLs from the overlay. Let `researcher` agent WebSearch for the rest.
+
+---
+
+## How to verify
+
+- [ ] Versions read from lock files (not package.json ranges)?
+- [ ] ciel-overlay.md consulted for project-specific versions?
+- [ ] Framework detected (React/Vue/Svelte/Ktor/Express/etc)?
+- [ ] Version gaps flagged (installed vs latest)?
+- [ ] Overlay updated if new versions discovered?
+
+## When triggered
+
+- Standard/Critical tasks, immediately after `quoi-framer`
+- Before dispatching `researcher` agent (research quality depends on version accuracy)
+- When user asks "what versions are we on?" or the task mentions a specific library

package/assets/skills/workflow/ci-watcher/SKILL.md

@@ -0,0 +1,194 @@
+---
+name: ci-watcher
+description: Streams GitHub Actions via `gh run watch`, classifies failures flaky (≥15% fail rate on main → auto-`gh run rerun --failed`) vs real (hand off to debug-reasoning-rca). Invoke after pr-opener, before pr-merger, or on "CI stuck" / "why is CI red" / "flaky test". Inline.
+allowed-tools: Bash, Read
+context: inline
+---
+
+# ci-watcher — Watch CI, distinguish flaky from broken, retry smart
+
+`prouver-verifier` takes a single-point snapshot of CI state. `ci-watcher` watches over time: streams the run, waits for completion, classifies failures as flaky vs real, retries only what's safe.
+
+---
+
+## Inputs
+
+```
+BRANCH: [current branch — from git rev-parse]
+PR_NUMBER: [optional — derived if branch has an open PR]
+WORKFLOW: [optional — filter to specific workflow name; default all]
+MODE: [watch | snapshot — default watch; snapshot = single poll + return]
+MAX_RETRIES: [default 1 — for flaky-detected failures only]
+FLAKY_THRESHOLD: [default 15 — % fail rate on main that classifies as flaky]
+```
+
+### Auto-inference sources
+
+- **BRANCH** → `git rev-parse --abbrev-ref HEAD`
+- **PR_NUMBER** → `gh pr view --json number --jq .number 2>/dev/null`
+- **WORKFLOW** → all workflows that ran on the branch
+
+---
+
+## Preflight
+
+```bash
+gh auth status 2>&1 | grep -q "Logged in" || exit 1
+BRANCH=${BRANCH:-$(git rev-parse --abbrev-ref HEAD)}
+
+# Confirm branch has at least one run
+LATEST=$(gh run list --branch="$BRANCH" --limit=1 --json databaseId,status,conclusion --jq '.[0] // empty')
+[ -z "$LATEST" ] && { echo "No runs found for branch $BRANCH — push first"; exit 1; }
+```
+
+---
+
+## Process
+
+### 1. Stream or snapshot
+
+**Watch mode (default)** — stream until completion:
+
+```bash
+RUN_ID=$(gh run list --branch="$BRANCH" --limit=1 --json databaseId --jq '.[0].databaseId')
+gh run watch "$RUN_ID" --exit-status
+RESULT=$?
+```
+
+`--exit-status` returns non-zero on run failure. `gh run watch` streams logs as they appear.
+
+**Snapshot mode** — single poll:
+
+```bash
+gh run list --branch="$BRANCH" --limit=5 --json databaseId,name,status,conclusion,url
+```
+
+### 2. On failure — classify flaky vs real
+
+```bash
+# Get failing jobs for this run
+FAILED_JOBS=$(gh run view "$RUN_ID" --json jobs --jq '.jobs[] | select(.conclusion == "failure") | .name')
+
+# For each failed job, check history on the base branch
+BASE=$(gh pr view "$PR_NUMBER" --json baseRefName --jq .baseRefName 2>/dev/null || echo "main")
+
+for JOB in $FAILED_JOBS; do
+  # Last 50 runs on base branch for same workflow
+  WORKFLOW=$(gh run view "$RUN_ID" --json workflowName --jq .workflowName)
+  FAIL_RATE=$(gh run list \
+    --branch="$BASE" \
+    --workflow="$WORKFLOW" \
+    --limit=50 \
+    --json conclusion \
+    --jq '[.[] | select(.conclusion == "failure")] | length')
+
+  FAIL_PCT=$((FAIL_RATE * 100 / 50))
+
+  if [ "$FAIL_PCT" -ge "$FLAKY_THRESHOLD" ]; then
+    echo "Job '$JOB' fails ${FAIL_PCT}% of the time on $BASE — CLASSIFIED FLAKY"
+    FLAKY_JOBS+=("$JOB")
+  else
+    echo "Job '$JOB' fails ${FAIL_PCT}% of the time on $BASE — CLASSIFIED REAL FAILURE"
+    REAL_FAILURES+=("$JOB")
+  fi
+done
+```
+
+**Flaky threshold rationale**: 15% = 7-8 failures in 50 runs. Below that, a single failure is likely the PR's fault. Above, it's environmental/test-harness instability.
+
+### 3. Retry flaky jobs (up to MAX_RETRIES)
+
+```bash
+if [ ${#FLAKY_JOBS[@]} -gt 0 ] && [ "$RETRY_COUNT" -lt "$MAX_RETRIES" ]; then
+  echo "Retrying flaky jobs (attempt $((RETRY_COUNT+1))/$MAX_RETRIES)"
+  gh run rerun "$RUN_ID" --failed
+  RETRY_COUNT=$((RETRY_COUNT+1))
+  # Re-enter step 1 (watch the rerun)
+fi
+```
+
+`--failed` only reruns failed jobs (saves CI minutes).
+
+### 4. Extract log excerpt for real failures
+
+For handoff to `debug-reasoning-rca`:
+
+```bash
+for JOB in $REAL_FAILURES; do
+  JOB_ID=$(gh run view "$RUN_ID" --json jobs --jq ".jobs[] | select(.name == \"$JOB\") | .databaseId")
+
+  # Last 50 lines of the failing step
+  gh run view --job="$JOB_ID" --log-failed | tail -50
+done
+```
+
+### 5. Emit output
+
+```
+[CI WATCHER]
+Run: <URL>
+Status: <success | failure | in_progress>
+Duration: <Xm Ys>
+
+Jobs:
+  [OK]   build
+  [OK]   lint
+  [WARN] integration-tests — FLAKY (fails 18% on main, retried — now green)
+  [FAIL] unit-tests — REAL FAILURE (fails 2% on main — investigate)
+
+Handoff (if real failures):
+  - debug-reasoning-rca with SYMPTOM=<failing test name> + LOG excerpt
+```
+
+---
+
+## Guardrails
+
+- **MAX_RETRIES=1 by default** — a flaky test that fails twice in a row is likely not flaky. Don't spam retries.
+- **Never retry real failures** — the retry mechanism is ONLY for jobs classified flaky. Real failures need a code fix.
+- **Never retry pre-merge checks on main** — only PR branches. Retrying on main risks hiding real regressions.
+- **Budget-aware**: large rerun loops burn CI minutes. Log estimated minutes cost before retry on repos with tight budgets.
+- **Respect timeouts**: `gh run watch` can hang if a job hangs. Wrap in `timeout 1800 gh run watch` for 30-min ceiling.
+- **Flaky classification is per-job, not per-run**: if 3 of 5 jobs are flaky but 1 is real, DO NOT retry — fix the real one first.
+- **Store flaky detections** — append to `.claude/flaky-tests.log` (optional, per-project) so patterns surface across sessions.
+
+---
+
+## When triggered
+
+- After `pr-opener` in Standard pipeline (step 11 post-insertion)
+- Before `pr-merger` as CI-green verification (replaces inline `gh run list` check)
+- User says: "watch CI", "is CI green?", "CI is flaky", "rerun failed jobs"
+- `prouver-verifier` detects a red CI and needs disambiguation
+
+---
+
+## Anti-pattern
+
+```
+❌ Failed → rerun blindly → rerun → rerun → real bug hidden, minutes wasted
+✅ Failed → classify (fail % on main) → retry only flaky → real fail → debug-reasoning-rca
+```
+
+```
+❌ sleep 300 && gh run list       # blocked by harness; also cache-cold
+✅ gh run watch --exit-status     # streams, no sleep
+```
+
+---
+
+## Handoff
+
+- **If all green** → `pr-merger` can proceed
+- **If real failure** → `debug-reasoning-rca` via `@ciel-critic` with log excerpt as SYMPTOM + failing job as SCOPE
+- **If flaky detected + retry succeeded** → proceed to `pr-merger`, log flaky for future `/ciel-improve` signal
+- **If flaky + retry failed** → escalate to user (flaky-turned-real or real-misclassified)
+
+---
+
+## References
+
+- `gh run watch` — cli.github.com/manual/gh_run_watch
+- `gh run rerun --failed` — cli.github.com/manual/gh_run_rerun
+- Flaky test classification — Google's 2020 paper "Taming Google-scale continuous testing" (15% threshold baseline)
+- Ciel pipeline: pr-opener → ci-watcher → (flaky? retry : debug-reasoning-rca) → pr-merger

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