@neikyun/ciel 6.2.4 → 6.4.0

package/assets/platforms/opencode/.opencode/agents/ciel-researcher.md

@@ -1,6 +1,7 @@
 ---
 description: Isolated-context researcher subagent for Ciel. Dispatch for RECHERCHE step (Standard + Critical tasks) — official docs, anti-patterns, framework philosophy, version changelog, source credibility. Also owns doc-validator-official (anti-hallucination API check). WebFetch + WebSearch enabled, no write/edit/bash.
 mode: subagent
+model: anthropic/claude-haiku-4-5-20251001
 temperature: 0.2
 tools:
   write: false
@@ -116,9 +117,11 @@ Internal skills can produce more; `synthesize-findings` compresses.
 
 # research-web-sources — Official docs + best practices
 
-Meta-research skill #1 of 6. Fetches the primary source (official docs) + best-practice blog posts / maintainer articles for a specific library+version.
+## What this covers
+Meta-research skill #1 of 6. Fetches the primary source (official docs) + best-practice articles for a specific library+version. This is the highest-credibility research step — if official docs answer the question, stop here.
 
----
+## Core principle
+**Official docs are the source of truth.** If docs exist and answer the question, don't search further. Escalate to GitHub issues and forums only when docs are silent.
 
 ## Inputs
 
@@ -129,13 +132,11 @@ VERSION: [exact installed version — from avec-quoi-versioner]
 QUESTION: [specific question]
 ```
 
----
-
 ## Process
 
 ### 1. Fetch official documentation
 
-- Primary: WebFetch the official docs URL (from `ciel-overlay.md` or derived)
+- Primary: WebFetch the official docs URL
 - If docs for the exact version aren't available, fetch the latest + note the version gap
 - Focus on the specific API/feature in question — don't fetch whole doc site
 
@@ -144,15 +145,11 @@ QUESTION: [specific question]
 Queries (run at least 2):
 - `[feature] [lib] [version] best practices`
 - `[feature] [lib] idiomatic way`
-- Quote multiple sources if available
 
 ### 3. Identify framework philosophy
 
 From docs: how does this framework WANT this problem solved? Not just what the API is — the intended approach.
 
-- "In Ktor 3, pagination is handled via query params on routes, leveraging the built-in `call.parameters` API. The framework prefers explicit over magic."
-- "In React 19, state updates are co-located with components via hooks; global state via Context or external stores like Zustand is reserved for truly cross-cutting concerns."
-
 ### 4. Extract anti-patterns (MANDATORY — at least 1)
 
 Queries:
@@ -161,42 +158,52 @@ Queries:
 
 Cite at least one documented anti-pattern with source URL.
 
----
+## Common patterns
 
-## Output format
+### Good research output
 
 ```
-## RESEARCH — <tech> <version>
+## RESEARCH — React 19
 
 ### FINDINGS
-- <finding — specific, with version>
-- <finding — include source URL>
+- Server Components are the default in React 19 — no "use client" needed for static rendering
+- `use()` hook replaces useEffect for data fetching in client components
+- Source: https://react.dev/reference/rsc/server-components (React 19.0)
 
 ### ANTI-PATTERNS À ÉVITER
-- <anti-pattern> — <source URL or "official docs">
+- useEffect + fetch waterfall — use Server Components instead — official docs
+- "use server" on components — this directive is for Server Functions, not components — react.dev
 
 ### PHILOSOPHY DU FRAMEWORK
-<1-2 sentences: how the framework wants this solved>
+React 19 pushes data fetching to the server. Client components handle interactivity only.
+```
 
-### API SURFACE (verified)
-- <import/function verified at: URL or file:line>
-- <response format verified from: source>
+### Bad research output
 
-### INCERTITUDES
-- <unknown — flagged for main session>
+```
+FINDINGS:
+- React is good for UI
+- You can use hooks
 ```
 
----
+Problems: no version, no specific API, no source URLs, no anti-patterns.
 
-## Guardrails
+## Anti-patterns
 
-- **Minimum output**: ≥ 1 WebSearch result + ≥ 1 documented finding. Zero output = step not done.
-- **Version stamp required**: every finding includes the version it applies to
-- **Docs contradict memory → trust docs**
-- **Docs unavailable**: state it explicitly, don't fill gaps with assumptions
-- **No preamble**: return only the structured report, no "I found that..."
+- **No version stamp** — every finding must include the version it applies to
+- **Filling gaps with assumptions** — if docs don't cover it, say so explicitly
+- **Preamble** — return only the structured report, no "I found that..."
+- **Fetching entire doc site** — focus on the specific API/feature in question
+- **Minimum output not met** — ≥ 1 WebSearch result + ≥ 1 documented finding required
 
----
+## How to verify
+
+- [ ] ≥ 1 WebSearch performed?
+- [ ] ≥ 1 finding with version stamp?
+- [ ] ≥ 1 anti-pattern cited?
+- [ ] Source URLs present?
+- [ ] Framework philosophy stated (1-2 sentences)?
+- [ ] No preamble (structured report only)?
 
 ## When triggered
 
@@ -204,6 +211,11 @@ Cite at least one documented anti-pattern with source URL.
 - User explicit request: "research <lib> <feature>"
 - When task mentions a library that's not fully understood
 
+## References
+
+- Tier-1 source credibility — validate-source-credibility skill
+- Ciel waterfall: research-web-sources → research-github-issues → research-forums → synthesize-findings
+
 ---
 
 ### Skill: `research-github-issues`
@@ -211,9 +223,11 @@ Cite at least one documented anti-pattern with source URL.
 
 # research-github-issues — GitHub issues prior art
 
+## What this covers
 Meta-research skill #2 of 6. When official docs don't cover an edge case, GitHub issues often have the answer — someone else hit the same problem.
 
----
+## Core principle
+**Every bug you encounter, someone else encountered first.** GitHub issues are the world's largest debugging knowledge base. Check before investigating from scratch.
 
 ## Inputs
 
@@ -223,36 +237,24 @@ VERSION: [exact installed version]
 SYMPTOM: [error message OR unexpected behavior description]
 ```
 
----
-
 ## Process
 
 ### 1. Identify the repo
 
-From the lib name, resolve to the GitHub repo:
-- `ktor` → `ktorio/ktor`
-- `react` → `facebook/react`
-- `tanstack-query` → `TanStack/query`
-
-Check `package.json` `repository` field or docs for canonical repo URL.
+From the lib name, resolve to the GitHub repo. Check `package.json` `repository` field for canonical URL.
 
 ### 2. Search issues
 
-Queries (via WebSearch or WebFetch on `https://github.com/<repo>/issues?q=`):
-
-- `site:github.com/<repo>/issues <symptom>` 
+Queries (via WebSearch or WebFetch):
+- `site:github.com/<repo>/issues <symptom>`
 - `site:github.com/<repo>/issues <feature> <version>`
 
-Include both:
-- `is:open` — active, not yet resolved
-- `is:closed` — resolved (read how!)
+Include both `is:open` and `is:closed`.
 
 ### 3. Classify each relevant issue
 
-For each issue found:
-
 - **Open + active** → known problem, official fix pending → workaround needed now
-- **Closed + merged fix** → version N included fix; check if our version is ≥ N
+- **Closed + merged fix** → version N included fix; check if our version ≥ N
 - **Closed with workaround** → apply workaround (cite link)
 - **Closed as "not a bug"** → our usage is wrong (read the comment)
 - **Closed as duplicate** → follow to the parent issue
@@ -264,45 +266,49 @@ If an issue references a PR, check the PR:
 - Draft → fix is in progress
 - Closed unmerged → fix abandoned, need workaround
 
----
+## Common patterns
 
-## Output format
+### Good GitHub issues research
 
 ```
-## GITHUB ISSUES RESEARCH — <tech>
+## GITHUB ISSUES RESEARCH — @auth/core
 
 ### Relevant issues
 | # | Title | Status | Our impact |
 |---|-------|--------|-----------|
-| #1234 | <title> | closed in v3.0.0 | Our version is 3.0.1 — fix included ✓ |
-| #5678 | <title> | open | Matches our symptom — apply workaround from comment |
-| #9012 | <title> | closed (not a bug) | Our usage is non-idiomatic — refactor needed |
+| #1234 | useSession throws on expired tokens | closed in v4.0.1 | Our version is 4.0.0 — upgrade needed |
+| #5678 | OAuth callback fails with PKCE | open | Matches our symptom — apply workaround |
 
 ### Workarounds applicable
-- <workaround> — source: <issue URL + comment permalink>
+- Add `skipCSRFCheck: true` to OAuth config — source: #5678 comment by maintainer
 
 ### Fix version ranges
-- <feature> fixed in <version> — our version: <v>
-- If our version < fix version: <suggest upgrade if safe>
+- useSession fix in v4.0.1 — our version: v4.0.0 — suggest upgrade
+```
 
-### PRs in progress
-- <PR #> — <title> — status: <draft | review | merged>
+### Bad research
 
-### UNCERTAINTIES
-- <unknown — flag for main session>
+```
+Found some issues. One was closed. Should be fine.
 ```
 
----
+Problems: no issue numbers, no status classification, no version check, no workarounds.
 
-## Guardrails
+## Anti-patterns
 
-- **Cite with links**: every issue reference needs a URL
-- **Check comment consensus**: a single comment doesn't make truth. Look for maintainer response + thumbs up count
-- **Version ranges matter**: "fixed in 3.x" could mean 3.0 or 3.5 — read the changelog
-- **Don't treat community workaround as gospel**: verify it actually works; prefer official fix
-- **Empty result valid**: if no relevant issues found, report "no matches" — don't fabricate
+- **No links** — every issue reference needs a URL
+- **Single comment as truth** — check for maintainer response + consensus
+- **Ignoring version ranges** — "fixed in 3.x" could mean 3.0 or 3.5 — read the changelog
+- **Treating community workaround as gospel** — verify it works; prefer official fix
+- **Empty result fabricated** — if no relevant issues found, report "no matches"
 
----
+## How to verify
+
+- [ ] ≥ 1 GitHub issue found and classified?
+- [ ] Each issue has URL, status, and impact assessment?
+- [ ] Version ranges checked (our version vs fix version)?
+- [ ] Workarounds documented with source links?
+- [ ] Linked PRs checked (merged/draft/closed)?
 
 ## When triggered
 
@@ -318,9 +324,11 @@ If an issue references a PR, check the PR:
 
 # research-forums — Community discussion fallback
 
+## What this covers
 Meta-research skill #3 of 6. When official docs + GitHub issues don't resolve the question, community forums often have the answer. But quality is uneven — `validate-source-credibility` is mandatory after this.
 
----
+## Core principle
+**Community knowledge supplements official docs, never replaces them.** If a forum answer contradicts official docs, trust docs.
 
 ## Inputs
 
@@ -330,94 +338,85 @@ VERSION: [version if relevant]
 QUESTION: [specific question]
 ```
 
----
-
 ## Process
 
 ### 1. StackOverflow
 
 Queries:
 - `site:stackoverflow.com <lib> <feature> <version>`
-- `site:stackoverflow.com [<lib>] <question>` (uses SO tag syntax)
+- `site:stackoverflow.com [<lib>] <question>`
 
 Priority signals:
 - Accepted answer (green checkmark)
 - Answer with > 50 upvotes
-- Answer from recognized maintainer (blue badge, lib author in profile)
+- Answer from recognized maintainer
 
 ### 2. Reddit
 
-Subs to check:
-- `r/programming` (general)
-- Stack-specific: `r/typescript`, `r/golang`, `r/rust`, `r/Kotlin`, `r/reactjs`, `r/node`, etc.
-
-Queries:
-- `site:reddit.com/r/<sub> <lib> <feature>`
+Subs: `r/programming`, stack-specific (`r/typescript`, `r/golang`, `r/reactjs`, etc.)
 
-Priority signals:
-- Upvote ratio > 0.9
-- Top comment explains tradeoffs (not just "use X")
-- Discussion includes both sides of the question
+Priority signals: upvote ratio > 0.9, top comment explains tradeoffs.
 
 ### 3. Hacker News
 
 - `site:news.ycombinator.com <lib> <feature>`
-- Check for recent (< 2 years) discussions on the library or problem
-
-Priority: submissions that got 100+ points + quality discussion in comments.
+- Priority: 100+ points + quality discussion
 
 ### 4. dev.to, medium, maintainer blogs
 
-- Search for maintainer-authored articles (look for author bio matching lib committer)
 - Recent posts (< 18 months) usually more reliable
+- Look for author bio matching lib committer
 
----
+## Common patterns
 
-## Output format
+### Good forum research
 
 ```
-## FORUMS RESEARCH — <tech>
+## FORUMS RESEARCH — Vitest 3
 
 ### StackOverflow
-- <answer URL> — <N upvotes, accepted?> — <summary>
+- https://stackoverflow.com/q/12345 — 89 upvotes, accepted — vi.hoisted() required for mock variables in Vitest 3
 
 ### Reddit
-- <thread URL> — <upvotes / comments> — <summary>
-
-### Hacker News
-- <submission URL> — <points / date> — <summary>
+- https://reddit.com/r/vitest/comments/abc — 45 upvotes, 23 comments — consensus: vi.spyOn > vi.mock for most cases
 
-### Blogs / dev.to
-- <article URL> — <author + credibility signal> — <summary>
+### CONSENSUS
+- Use vi.hoisted() for variables referenced in vi.mock()
+- Prefer vi.spyOn over vi.mock for testing interactions
 
-### CONSENSUS (what multiple sources agree on)
-- <consensus point 1>
-- <consensus point 2>
+### DISAGREEMENTS
+- Whether to use global vs per-test setup: SO says global, Reddit says per-test — depends on test isolation needs
+```
 
-### DISAGREEMENTS (sources conflict — investigate)
-- <point>: <source A says X, source B says Y>
+### Bad forum research
 
-### UNCERTAINTIES
-- <unresolved question>
+```
+Found some stuff on StackOverflow. People say use vi.mock.
 ```
 
----
+Problems: no URLs, no upvote counts, no consensus analysis, no disagreement detection.
 
-## Guardrails
+## Anti-patterns
 
-- **Source credibility is MANDATORY**: follow-up with `validate-source-credibility` on any non-official finding before trusting
-- **Date everything**: stale forum answers are common. Reject if older than 2 years unless fundamentals haven't changed.
-- **Community vs official**: if forum answer contradicts official docs → trust docs
-- **Beware single-source**: if only one person on StackOverflow claims X works, it's a hypothesis, not an answer
-- **Cross-reference**: forum answer should corroborate with at least one other source (another SO answer, a doc snippet, a blog post) before being treated as fact
+- **Credibility not validated** — follow-up with `validate-source-credibility` on any non-official finding
+- **Stale answers accepted** — reject if older than 2 years unless fundamentals unchanged
+- **Forum > docs** — if forum answer contradicts official docs → trust docs
+- **Single-source treated as fact** — one SO answer is a hypothesis, not an answer
+- **No cross-reference** — corroborate with at least one other source before treating as fact
 
----
+## How to verify
+
+- [ ] ≥ 1 forum source found?
+- [ ] Each source has URL + upvote/engagement signal?
+- [ ] Staleness check performed (< 2 years)?
+- [ ] Consensus and disagreements identified?
+- [ ] validate-source-credibility will be invoked for non-official findings?
 
 ## When triggered
 
-- `researcher` agent when `research-web-sources` and `research-github-issues` didn't resolve the question
+- `researcher` agent when `research-web-sources` and `research-github-issues` didn't resolve
 - User asks for "community perspective" or "what do other people do"
-- When a task involves a niche library with sparse docs
+- Niche library with sparse docs
 
 ---
 
@@ -426,129 +425,97 @@ Priority: submissions that got 100+ points + quality discussion in comments.
 
 # validate-source-credibility — Rank sources by trust
 
-Meta-research skill #4 of 6. Not all sources are equal. Wrong information confidently presented causes downstream failures.
+## What this covers
+Meta-research skill #4 of 6. Not all sources are equal. Wrong information confidently presented causes downstream failures. This skill scores every finding before it influences code decisions.
 
----
+## Core principle
+**Credibility is tiered, not binary.** A Tier-1 source (official docs) needs no validation. A Tier-4 source (random blog) is a hypothesis until cross-referenced.
 
 ## Inputs
 
 ```
 SOURCE_URL: [URL of information source]
-CLAIM: [what the source says — specific claim being evaluated]
+CLAIM: [what the source says]
 TECHNOLOGY: [lib name]
 VERSION: [version the claim is about]
 ```
 
----
-
 ## Credibility tiers
 
-### Tier 1 — Official / primary source
-- Official library documentation at `<lib>.org` / `<lib>.dev`
-- Official GitHub release notes
-- Library source code (reading the implementation)
-- **Trust: high. Always prefer.**
-
-### Tier 2 — Maintainer-authored
-- Maintainer blog post / dev.to / medium article (author is a committer on the repo)
-- Official library GitHub discussion with maintainer response
-- Conference talk by a maintainer (recent)
-- **Trust: high for the claim's scope; may have maintainer bias toward their preferred approach.**
-
-### Tier 3 — Well-engaged community
-- StackOverflow answer: accepted + > 50 upvotes + recent
-- GitHub issue with maintainer comment confirming approach
-- Reddit thread with clear consensus (high upvote ratio)
-- **Trust: medium. Cross-reference with Tier 1/2.**
-
-### Tier 4 — Individual community contributors
-- Random blog post by non-maintainer
-- Medium / dev.to article without maintainer credential
-- Low-upvoted SO answer
-- **Trust: low. Treat as hypothesis, verify against Tier 1/2.**
-
-### Tier 5 — Unverified
-- AI-generated content (detected via boilerplate patterns)
-- Old tutorials / screencasts without clear authorship
-- **Trust: zero. Flag, do not follow.**
-
----
+| Tier | Source | Trust |
+|------|--------|-------|
+| **1** | Official docs, GitHub release notes, source code | High — always prefer |
+| **2** | Maintainer blog, maintainer GitHub discussion, conference talk | High for scope; possible bias |
+| **3** | SO accepted (50+ upvotes), GitHub issue with maintainer comment, Reddit consensus | Medium — cross-reference |
+| **4** | Random blog, low-upvoted SO, Medium article without credentials | Low — verify against Tier 1/2 |
+| **5** | AI-generated content, old tutorials without authorship | Zero — flag, do not follow |
 
 ## Freshness thresholds
 
-| Library evolution pace | Max age acceptable |
-|------------------------|--------------------|
-| Fast-moving (React, Next.js, Ktor, Tailwind, TanStack) | 12 months |
+| Library pace | Max age |
+|-------------|---------|
+| Fast (React, Next.js, Ktor, Tailwind) | 12 months |
 | Medium (Rails, Django, Spring) | 18 months |
 | Slow (C, SQL, git) | 36 months |
-| Stable fundamentals (algorithms, data structures) | 5+ years |
-
-Older sources: flag but don't auto-reject — sometimes fundamentals don't change.
-
----
+| Stable fundamentals | 5+ years |
 
 ## Process
 
-### 1. Identify tier from URL
+### 1. Identify tier from URL + content
 
-Parse URL + optional page content:
-- Domain `<lib>.org` → Tier 1
-- `github.com/<lib-org>/<lib>/issues` → Tier 3 (maintainer comment = Tier 2)
-- `stackoverflow.com` → Tier 3 or 4 (check upvotes)
-- Random blog → Tier 4 or 5
+### 2. Extract publication date
 
-### 2. Extract date
+### 3. Compute freshness (fresh / aging / stale)
 
-Find the publication date (HTML `datePublished` meta tag, visible byline, or "Last updated" footer).
+### 4. Score: Tier + Freshness → FULL / VERIFY / REJECT
 
-### 3. Compute freshness
+## Common patterns
 
-Compare date vs current date vs library pace. Return: fresh / aging / stale.
+### Good credibility assessment
 
-### 4. Score
+```
+## SOURCE CREDIBILITY — https://blog.example.com/react-19-patterns
 
-Combined score:
-- Tier 1/2 + fresh → full trust
-- Tier 1/2 + stale → verify current version still behaves this way
-- Tier 3 + fresh → cross-reference with Tier 1/2
-- Tier 3 + stale → hypothesis, verify
-- Tier 4/5 → reject or verify against higher tier
+Tier: 4 (personal blog, no maintainer credential)
+Freshness: aging — published 2025-11-08, 5 months old
+Library pace: fast (React)
 
----
+Credibility signals:
+- Author unknown in React contributor list
+- No upvote/engagement data available
 
-## Output format
+Trust assessment: VERIFY — cross-reference with official docs before using
 
+Recommendation: Do not trust alone. Verify claim "use() replaces useEffect" against react.dev.
 ```
-## SOURCE CREDIBILITY — <URL>
-
-Tier: <1 / 2 / 3 / 4 / 5>
-Freshness: <fresh | aging | stale> — <publication date, age>
-Library pace: <fast | medium | slow>
-
-Credibility signals:
-- <signal: e.g. "maintainer-authored per GitHub profile"> 
-- <signal: e.g. "accepted answer with 200 upvotes">
 
-Trust assessment: <FULL | VERIFY | REJECT>
+### Bad credibility assessment
 
-Recommendation: <how main session should treat this source>
+```
+Source looks reliable. Use it.
 ```
 
----
+Problems: no tier, no freshness check, no trust assessment.
 
-## Guardrails
+## Anti-patterns
 
-- **Never trust a Tier 4/5 source alone** — always cross-reference against Tier 1/2
-- **Tier 1 doesn't override common sense**: if official docs say something that contradicts repository source code for the installed version, flag the conflict
-- **AI-generated content detection**: boilerplate patterns, generic structure, recent publication without author credentials → suspect
-- **Don't penalize age when appropriate**: for stable fundamentals, a 2017 article on TCP sockets is still correct
-- **Freshness ≠ correctness**: a brand-new blog post can be wrong; an old maintainer article on stable API can be right
+- **Tier 4/5 trusted alone** — always cross-reference against Tier 1/2
+- **Tier 1 overrides common sense** — if docs contradict source code for installed version, flag conflict
+- **Age penalized unfairly** — stable fundamentals don't age. A 2017 article on TCP sockets is still correct.
+- **Freshness = correctness** — a brand-new blog post can be wrong; an old maintainer article on stable API can be right
+- **AI-generated content not detected** — boilerplate patterns, generic structure, no author credentials → suspect
 
----
+## How to verify
+
+- [ ] Tier assigned (1-5)?
+- [ ] Publication date extracted?
+- [ ] Freshness assessed against library pace?
+- [ ] Trust assessment given (FULL / VERIFY / REJECT)?
+- [ ] Recommendation states how main session should treat this source?
 
 ## When triggered
 
-- By `synthesize-findings` skill when merging multi-source research
+- By `synthesize-findings` when merging multi-source research
 - On any finding from Tier 3/4/5 before it influences code decisions
 - User request: "how reliable is this source?"
 
@@ -559,9 +526,11 @@ Recommendation: <how main session should treat this source>
 
 # synthesize-findings — Merge research into one report
 
+## What this covers
 Meta-research skill #5 of 6. After parallel research skills have produced raw findings, this skill merges them into the single canonical format that the `researcher` agent returns.
 
----
+## Core principle
+**Conflicts are signals, not noise.** When two sources disagree, that disagreement is the most valuable finding. Surface it, don't hide it.
 
 ## Inputs
 
@@ -572,8 +541,6 @@ FORUM_RESULTS: [output of research-forums — or "none"]
 CREDIBILITY_SCORES: [output of validate-source-credibility for low-tier sources]
 ```
 
----
-
 ## Process
 
 ### 1. Deduplicate
@@ -583,23 +550,22 @@ Same claim from multiple sources → merge, cite all sources ordered by credibil
 ### 2. Resolve conflicts
 
 When two sources disagree:
-
 - Higher credibility tier wins (official docs > forum)
 - Newer wins among same tier
-- If both are recent Tier 1 but disagree: flag as uncertainty
-- If version-specific: align to installed version
+- Both recent Tier 1 but disagree → flag as uncertainty
+- Version-specific → align to installed version
 
 ### 3. Populate canonical sections
 
 - **FINDINGS**: positive statements with version + source
 - **ANTI-PATTERNS À ÉVITER**: what NOT to do, with reason + source
 - **PHILOSOPHY DU FRAMEWORK**: how the framework wants this solved (1-2 sentences)
-- **API SURFACE**: verified imports / signatures / DB columns / response shapes
-- **INCERTITUDES**: unresolved questions, flagged conflicts, version gaps
+- **API SURFACE**: verified imports / signatures / response shapes
+- **INCERTITUDES**: unresolved questions, conflicts, version gaps
 
 ### 4. Apply credibility filter
 
-Any finding sourced only from Tier 4/5 without Tier 1/2 cross-reference → demote to UNCERTAINTY (with source annotation).
+Any finding sourced only from Tier 4/5 without Tier 1/2 cross-reference → demote to INCERTITUDE.
 
 ### 5. Enforce minimum gate
 
@@ -609,45 +575,57 @@ Output is incomplete if ANY of:
 - No philosophy statement
 - No version stamp on any finding
 
-Report incomplete → return warning to researcher agent.
+## Common patterns
 
----
-
-## Output format
+### Good synthesis
 
 ```
 ## FINDINGS
-- <finding with version + source URL>
-- <finding>
+- React 19 Server Components are the default — no "use client" needed for static rendering [v19.0]
+  Source: https://react.dev/reference/rsc/server-components (Tier 1)
+- `use()` hook replaces useEffect for data fetching [v19.0]
+  Source: react.dev (Tier 1) + SO #12345 89 upvotes (Tier 3)
 
 ## ANTI-PATTERNS À ÉVITER
-- <anti-pattern> — <reason> — <source URL>
+- useEffect + fetch waterfall — use Server Components instead — react.dev
+- "use server" on components — directive is for Server Functions — react.dev
 
 ## PHILOSOPHY DU FRAMEWORK
-<1-2 sentences>
+React 19 pushes data fetching to the server. Client components handle interactivity only.
 
 ## API SURFACE (verified)
-- <import/function verified at: URL or file:line>
-- <DB columns verified: migration:line or pg_attribute>
-- <response format verified: source>
+- `use()` — react.dev/reference/react/use
+- Server Components — `async function Component()` without "use client"
 
 ## INCERTITUDES
-- <unresolved question>
-- <version gap: docs are for v3.0, installed is v3.1 — unclear if X still applies>
-- <conflict: docs say X, GitHub issue #123 says Y — investigate>
+- Migration path from useEffect-based data fetching: docs show examples but no automated codemod exists
 ```
 
----
+### Bad synthesis
 
-## Guardrails
+```
+React is good. Use Server Components. Don't use useEffect.
+```
 
-- **Never invent findings**: if research skills didn't produce a finding for a category, leave it empty; don't fabricate
-- **Always cite**: every finding, anti-pattern, API surface claim has a URL or file:line
-- **Uncertainties are valuable**: empty UNCERTAINTIES section is suspicious — research rarely resolves everything
-- **Output budget**: ≤ 500 tokens (the researcher agent returns this to main session — stay compact)
-- **No preamble, no conclusion**: structured report only
+Problems: no version, no sources, no anti-patterns, no uncertainties.
 
----
+## Anti-patterns
+
+- **Inventing findings** — if research didn't produce a finding, leave it empty
+- **No citations** — every finding has a URL or file:line
+- **Empty INCERTITUDES** — suspicious. Research rarely resolves everything.
+- **Conflicts hidden** — when sources disagree, surface it as INCERTITUDE
+- **Output too long** — ≤ 500 tokens (researcher returns this to main session)
+
+## How to verify
+
+- [ ] All 3 research inputs consumed (or marked "none")?
+- [ ] FINDINGS have version stamps + source URLs?
+- [ ] ≥ 1 anti-pattern documented?
+- [ ] PHILOSOPHY stated (1-2 sentences)?
+- [ ] Conflicts surfaced as INCERTITUDES?
+- [ ] Output ≤ 500 tokens?
+- [ ] Minimum gate passed (findings + anti-patterns + philosophy + versions)?
 
 ## When triggered
 
@@ -661,92 +639,94 @@ Report incomplete → return warning to researcher agent.
 
 # fact-check-claims — Verify before asserting
 
+## What this covers
 Meta-research skill #6 of 6. The guard against false confidence. LLMs routinely state confidently wrong things — DB column names, function signatures, response shapes. This skill demands proof.
 
----
+## Core principle
+**VERIFIED or not. There is no "probably true."** If you can't point to evidence (file:line or URL), mark it UNVERIFIED.
 
 ## Inputs
 
 ```
-CLAIM: [the specific assertion to verify — e.g. "The users table has a 'last_login' column"]
+CLAIM: [the specific assertion to verify]
 CONTEXT: [what's being built that relies on this claim]
 SOURCES_TO_CHECK: [optional list of files/URLs to verify against]
 ```
 
----
-
 ## Process
 
 ### 1. Classify the claim type
 
-- **Code claim**: function signature, import path, type definition → verify in source
-- **DB claim**: table exists, column exists, index exists → verify in migrations or schema
-- **API claim**: response shape, HTTP status, header → verify in real response or docs
-- **Version claim**: "In Ktor 3.0.0, X behaves like Y" → verify in changelog or release notes
-- **Environment claim**: "CI uses Node 20" → verify in workflow file
+| Type | Verify against |
+|------|----------------|
+| Code (function signature, import) | `Read` + `Grep` on actual source |
+| DB (table/column exists) | Migration files or `pg_attribute` |
+| API (response shape, status) | `curl` real endpoint or fixtures |
+| Version behavior | WebFetch official changelog |
+| Environment (Node version, etc.) | Workflow / Dockerfile / CI config |
 
 ### 2. Verify from authoritative source
 
-| Claim type | Verify against |
-|-----------|----------------|
-| Code | `Read` + `Grep` on actual source file |
-| DB schema | `Read` migration files OR `pg_attribute` via Bash |
-| API response | `curl` real endpoint OR real response saved in repo fixtures |
-| Version behavior | WebFetch official changelog for that version |
-| Environment | `Read` workflow / Dockerfile / CI config |
+Run the appropriate verification command. Record the evidence.
 
 ### 3. Produce verification record
 
-For each claim, record:
-- VERIFIED with evidence (file:line or URL + quote)
-- UNVERIFIED — source not available, state explicitly
-- CONTRADICTED — evidence says otherwise, provide the contradicting finding
+```
+VERIFIED   — with evidence (file:line or URL + quote)
+UNVERIFIED — source not available, state explicitly
+CONTRADICTED — evidence says otherwise
+```
 
 Never mark as VERIFIED without evidence.
 
----
+## Common patterns
 
-## Output format
+### Good fact-check
 
 ```
 ## FACT CHECK
 
-Claim: "<exact claim>"
+Claim: "The users table has a 'last_login' column"
 
-Result: <VERIFIED | UNVERIFIED | CONTRADICTED>
+Result: VERIFIED
 
 Evidence:
-- <file:line with quote>
-- <URL with relevant excerpt>
+- migration/20260315_add_last_login.sql:3 — `ALTER TABLE users ADD COLUMN last_login TIMESTAMPTZ`
+- pg_attribute confirms: users.last_login exists (type: timestamptz, notnull: false)
+```
 
-[If UNVERIFIED]
-Missing sources: <what couldn't be checked and why>
-Recommendation: <how to proceed — don't assert until verified, or accept uncertainty>
+### Bad fact-check
 
-[If CONTRADICTED]
-Contradicting finding: <what source actually says>
-Correction: <the corrected claim>
+```
+The users table probably has a last_login column. I remember seeing it.
 ```
 
----
+Problems: no evidence, "probably" = UNVERIFIED, no file:line reference.
 
-## Guardrails
+## Anti-patterns
 
-- **No "probably true"**: VERIFIED or not. Assumed-true claims get UNVERIFIED status.
-- **Evidence granularity**: a URL alone is weak; include the specific quote/line
-- **Claim atomicity**: break compound claims into atomic parts — "The users table has columns `id`, `email`, `last_login`" → 3 claims to verify individually
-- **Version-sensitivity**: version-specific claims MUST include version verification
-- **Don't substitute memory**: if the source to verify against isn't accessible, mark UNVERIFIED — don't fill with "I think I remember this"
+- **"Probably true"** — VERIFIED or not. Assumed-true = UNVERIFIED.
+- **URL alone as evidence** — weak; include the specific quote/line
+- **Compound claims not broken down** — "users table has id, email, last_login" → 3 claims
+- **Version-specific without version check** — "In Ktor 3.0, X works" → verify in changelog
+- **Memory substitution** — if source isn't accessible, mark UNVERIFIED
 
----
+## How to verify
+
+- [ ] Claim classified (code/DB/API/version/environment)?
+- [ ] Verification command run (grep/read/curl/webfetch)?
+- [ ] Result is VERIFIED / UNVERIFIED / CONTRADICTED?
+- [ ] VERIFIED claims have file:line or URL + quote?
+- [ ] Compound claims broken into atomic parts?
+- [ ] Version-specific claims include version number?
 
 ## When triggered
 
 - Before `synthesize-findings` finalizes any assertion
-- Before code generation asserts behavior the researcher might have been wrong about
+- Before code generation asserts behavior the researcher might be wrong about
 - When user says "are you sure?"
-- When `relire-critic` produces a RISQUE that questions an assertion
-- Automatically on any assertion about DB schemas, import paths, response shapes
+- When `relire-critic` produces a RISQUE questioning an assertion
+- Automatically on assertions about DB schemas, imports, response shapes
 
 ---
 
@@ -918,6 +898,15 @@ BLOCKING: 1 INVALID, 1 AMBIGUOUS — cannot proceed until resolved
 
 ---
 
+## How to verify
+
+- [ ] Exact versions extracted from lock files?
+- [ ] Official docs located for each API call?
+- [ ] Each proposed API validated (function name, signature, params, return type)?
+- [ ] Citations enforced (file:line or URL for every API)?
+- [ ] Training-cutoff awareness applied (if lib updated after cutoff)?
+- [ ] VERDICT issued (VALID / INVALID / UNCERTAIN)?
+
 ## When triggered
 
 - RECHERCHE step for Standard/Critical tasks using external libs