@rune-kit/rune 2.2.4 → 2.2.6

package/skills/fix/SKILL.md

@@ -3,7 +3,7 @@ name: fix
 description: Apply code changes and fixes. Writes implementation code, applies bug fixes, and verifies changes with tests. Core action hub in the development mesh.
 metadata:
   author: runedev
-  version: "0.4.0"
+  version: "0.5.0"
   layer: L2
   model: sonnet
   group: development
@@ -97,6 +97,32 @@ Confirm the change works and nothing is broken.
 - If project has a type-check command, run it via `Bash`
 - If project has a lint command, run it via `Bash`
 
+### Step 4.5: Quality Decay Check (Self-Regulation)
+
+When fix is called repeatedly (e.g., by cook Phase 4, or iterative fix loops), track a **WTF-likelihood score** — the probability that continued fixing is making things worse.
+
+**Compute every 3 fix attempts** (or when called 5+ times in a single cook session):
+
+| Signal | Score Adjustment |
+|--------|-----------------|
+| A fix was reverted (any test that passed now fails) | +15% |
+| Fix touched >3 files (blast radius expanding) | +5% per extra file beyond 3 |
+| 15+ fixes already applied in this session | +1% per fix beyond 15 |
+| All remaining issues are LOW severity | +10% |
+| Fix touched files outside the original diagnosis scope | +20% |
+| Consecutive fixes without running tests between them | +10% |
+
+**Thresholds:**
+- **>20% WTF-likelihood**: STOP fixing. Report current state to cook/user with: "Quality decay detected — continued fixes risk introducing more bugs than they resolve. {N} fixes applied, {score}% risk. Recommend: commit current progress, re-assess remaining issues."
+- **Hard cap: 30 fixes per session** — regardless of score. After 30, STOP and report.
+
+**Reset conditions:** WTF-likelihood resets to 0% when:
+- User explicitly says "continue fixing"
+- A full test suite run shows zero regressions
+- Scope is narrowed to a single file
+
+> Source: garrytan/gstack v0.9.0 (qa skill) — prevents runaway fix loops where each fix introduces new risk.
+
 ### Step 5: Post-Fix Hardening (Defense-in-Depth)
 
 After the fix works, make the bug **structurally impossible** — not just "fixed this time."
@@ -207,6 +233,7 @@ Known failure modes for this skill. Check these before declaring done.
 | Fixing at crash site without tracing data origin | HIGH | Defense-in-depth: trace where bad data ORIGINATES, add validation at every layer it passes through |
 | Single-point validation (fix one spot, hope it holds) | MEDIUM | Step 5: add entry + business logic + environment + debug layers for data-flow bugs |
 | Removing debug instrumentation before fix is verified | MEDIUM | Step 5b: preserve `#region agent-debug` markers until all tests pass — premature cleanup erases failure history |
+| Runaway fix loop — 20+ fixes without checking quality decay | HIGH | Step 4.5: WTF-likelihood self-regulation. >20% risk = STOP. Hard cap 30 fixes/session. Each fix adds risk — diminishing returns after ~15 |
 
 ## Done When
 

package/skills/git/SKILL.md

@@ -3,7 +3,7 @@ name: git
 description: Specialized git operations — semantic commits, PR descriptions, branch management, conflict resolution guidance. Replaces ad-hoc git commands with a dedicated, convention-aware utility.
 metadata:
   author: runedev
-  version: "0.2.0"
+  version: "0.3.0"
   layer: L3
   model: haiku
   group: utility
@@ -27,6 +27,7 @@ Specialized git operations utility. Handles semantic commits, PR descriptions, b
 - `/rune git pr` — manual PR generation
 - `/rune git branch <description>` — generate branch name
 - `/rune git changelog` — generate changelog from commits
+- `/rune git release <version>` — create tagged release with changelog
 
 ## Calls (outbound)
 
@@ -187,6 +188,49 @@ Group commits by conventional commit type. Format as [Keep a Changelog](https://
 
 Link to PRs/issues when references found in commit messages.
 
+### Release Mode
+
+Create a version tag with release artifacts.
+
+**Triggers:**
+- `/rune git release <version>` — create release for specified version
+- Called by `launch` (L1) during release pipeline
+- Called by `deploy` (L2) after successful production deploy
+
+#### Step 1 — Validate Version
+
+Parse version string. Must follow semver (`major.minor.patch`):
+- Breaking changes → major bump
+- New features → minor bump
+- Bug fixes → patch bump
+
+Check `git tag -l` to ensure version doesn't already exist.
+
+#### Step 2 — Generate Release Artifacts
+
+1. **Changelog**: Run Changelog Mode to generate entries since last tag
+2. **Version bump**: Update version in `package.json`, `pyproject.toml`, `Cargo.toml`, or equivalent
+3. **Release notes**: Summarize changes for GitHub Release body
+
+#### Step 3 — Tag and Push
+
+```bash
+git add <version-files>
+git commit -m "chore: bump version to v<version>"
+git tag -a v<version> -m "Release v<version>"
+git push origin master --tags
+```
+
+#### Step 4 — Create GitHub Release
+
+```bash
+gh release create v<version> --title "v<version>" --notes "<release-notes>"
+```
+
+#### Step 5 — Notify
+
+If deploy reports customer email list available (via rune-pay `/admin/emails`), flag for notification.
+
 ## Output Format
 
 ### Commit Mode
@@ -235,6 +279,16 @@ Examples: `feat/jwt-refresh`, `fix/123-login-crash`, `refactor/auth-module`
 - Change description (#PR)
 ```
 
+### Release Mode
+```
+## Release: v<version>
+- **Tag**: v<version>
+- **Commits**: [count] since last release
+- **Changelog**: [path to CHANGELOG.md]
+- **GitHub Release**: [URL]
+- **Artifacts**: version bump, changelog, tag, release
+```
+
 ## Constraints
 
 1. MUST use conventional commit format — no freeform messages

package/skills/journal/SKILL.md

@@ -3,7 +3,7 @@ name: journal
 description: Persistent state tracking and Architecture Decision Records across sessions. Manages progress state, module health, dependency graphs, and ADRs for any workflow.
 metadata:
   author: runedev
-  version: "0.2.0"
+  version: "0.3.0"
   layer: L3
   model: haiku
   group: state
@@ -43,6 +43,7 @@ None — pure L3 state management utility.
 .rune/module-status.json   — Machine-readable module states
 .rune/dependency-graph.mmd — Mermaid diagram, color-coded by health
 .rune/adr/                 — Architecture Decision Records (one per decision)
+.rune/risks/               — Risk Register entries (one per identified risk)
 ```
 
 ## Execution
@@ -111,6 +112,50 @@ For each architectural decision or trade-off made during this session (applies t
 - **[Alternative B]**: Rejected because [specific reason]. May reconsider if [condition changes].
 ```
 
+### Step 3.5 — Record risks
+
+For each risk identified during the session (technical, schedule, dependency, security):
+
+1. Generate a risk filename: `.rune/risks/RISK-[NNN]-[slug].md` where NNN is next sequential number
+2. Use `Write` to create the risk file:
+
+```markdown
+# RISK-[NNN]: [Risk Title]
+
+**Date Identified**: [YYYY-MM-DD]
+**Identified By**: [workflow — cook | plan | deploy | audit | adversary]
+**Severity**: Critical | High | Medium | Low
+**Likelihood**: High | Medium | Low
+**Status**: Open | Mitigated | Accepted | Closed
+
+## Description
+[What could go wrong — specific scenario, not vague "things might break"]
+
+## Impact
+[What happens if this risk materializes — quantify if possible]
+
+## Mitigation
+[Actions to reduce likelihood or impact]
+- [ ] [Action 1 — owner, deadline]
+- [ ] [Action 2]
+
+## Trigger Conditions
+[How to detect this risk is materializing — monitoring, alerts, symptoms]
+
+## Contingency
+[What to do if risk materializes despite mitigation — the Plan B]
+```
+
+3. **Risk classification matrix**:
+
+| Likelihood \ Severity | Critical | High | Medium | Low |
+|----------------------|----------|------|--------|-----|
+| **High** | 🔴 Immediate action | 🔴 This sprint | 🟡 This quarter | ⚪ Backlog |
+| **Medium** | 🔴 This sprint | 🟡 This quarter | ⚪ Backlog | ⚪ Accept |
+| **Low** | 🟡 This quarter | ⚪ Backlog | ⚪ Accept | ⚪ Accept |
+
+4. Risks marked 🔴 MUST have mitigation actions with deadlines. ⚪ Accept = documented acknowledgment, no action required.
+
 ### Step 4 — Update dependency graph
 
 If any module dependencies changed during this session (new imports, removed dependencies, refactored interfaces):
@@ -145,6 +190,7 @@ Emit the journal update summary to the calling skill.
 - **Module**: [current module]
 - **Health**: [before] → [after]
 - **ADRs Written**: [count]
+- **Risks Logged**: [count] ([severity breakdown])
 - **Files Updated**: [list of .rune/ files modified]
 - **Next Module**: [next in queue, or "rescue complete"]
 ```
@@ -154,8 +200,9 @@ Emit the journal update summary to the calling skill.
 ```
 1. Read .rune/RESCUE-STATE.md   → full rescue history
 2. Read .rune/module-status.json → module states and health scores
-3. Read git log                  → latest changes since last session
-4. Read CLAUDE.md               → project conventions
+3. Read .rune/risks/             → open risks and their status
+4. Read git log                  → latest changes since last session
+5. Read CLAUDE.md               → project conventions
 → Result: Zero context loss across rescue sessions
 ```
 
@@ -180,6 +227,7 @@ Known failure modes for this skill. Check these before declaring done.
 ## Done When
 
 - All decisions from the session recorded as ADR files with rationale
+- All identified risks recorded as RISK files with severity, mitigation, and trigger conditions
 - Progress state updated (module status, phase, or deploy event as appropriate)
 - Dependency graph updated if module relationships changed
 - Journal Update summary emitted to calling skill

package/skills/plan/SKILL.md

@@ -3,7 +3,7 @@ name: plan
 description: Create structured implementation plans from requirements. Produces master plan + phase files for enterprise-scale project management. Master plan = overview (<80 lines). Phase files = execution detail (<150 lines each). Each session handles 1 phase. Uses opus for deep reasoning.
 metadata:
   author: runedev
-  version: "0.6.0"
+  version: "0.9.0"
   layer: L2
   model: opus
   group: creation
@@ -101,10 +101,25 @@ High-level multi-feature planning — organize features into milestones.
 - `skill-forge` (L2): plan structure for new skill
 - User: `/rune plan` direct invocation
 
-## Cross-Hub Connections
+## Data Flow
+
+### Feeds Into →
+
+- `cook` (L1): master plan + phase files → cook's Phase 2-4 execution roadmap
+- `team` (L1): task decomposition + wave grouping → team's parallel workstream dispatch
+- `fix` (L2): phase file tasks → fix's implementation targets
+- `test` (L2): phase file test tasks → test's RED phase targets
+
+### Fed By ←
+
+- `ba` (L2): Requirements Document → plan's primary input (locked decisions, user stories)
+- `scout` (L2): codebase analysis → plan's convention/pattern awareness
+- `neural-memory` (external): past architectural decisions → plan's precedent context
 
-- `plan` ↔ `brainstorm` — bidirectional: plan asks brainstorm for options, brainstorm asks plan for structure
-- `ba` → `plan` — BA produces Requirements Document, plan consumes it as primary input
+### Feedback Loops ↻
+
+- `plan` ↔ `brainstorm`: plan requests options when multiple approaches exist → brainstorm generates options → plan selects and structures the chosen approach
+- `plan` ↔ `cook`: cook discovers plan gaps during implementation → plan updates phase files → cook resumes with corrected tasks
 
 ## Executable Steps (Implementation Mode)
 
@@ -321,6 +336,7 @@ function validateInput(raw: unknown): TradeEntry[];  // throws ValidationError
 Each task MUST include: **File** (exact path), **Test** (test file or N/A), **Verify** (shell command), **Commit** (semantic message). Granularity: 2-5 min per task. If >10min, decompose.
 
 - [ ] Task 1 — Create calculateProfit function
+  - Req: REQ-001 (P&L calculation)
   - File: `src/foo/bar.ts` (new)
   - Test: `tests/foo/bar.test.ts` (new)
   - Verify: `npm test -- --grep "calculateProfit"`
@@ -328,12 +344,14 @@ Each task MUST include: **File** (exact path), **Test** (test file or N/A), **Ve
   - Logic: sum entries by side, apply fees (0.1% per trade), return net P&L
   - Edge: empty array → return { netPnL: 0, totalFees: 0, winRate: 0 }
 - [ ] Task 2 — Add input validation
+  - Req: REQ-002 (input validation)
   - File: `src/foo/baz.ts` (modify)
   - Test: `tests/foo/baz.test.ts` (new)
   - Verify: `npm test -- --grep "validateInput"`
   - Commit: `feat(trading): add input validation for trade entries`
   - Logic: check side is 'long'|'short', prices > 0, quantity > 0
 - [ ] Task 3 — Write integration tests
+  - Req: REQ-001, REQ-002 (integration coverage)
   - File: `tests/foo/bar.test.ts` (modify)
   - Test: N/A — this IS the test task
   - Verify: `npm test -- --grep "trading" && npx tsc --noEmit`
@@ -382,6 +400,14 @@ Each task MUST include: **File** (exact path), **Test** (test file or N/A), **Ve
 - [ ] Performance: calculateProfit(10K entries) < 100ms
 - [ ] No `any` types, no mutation, no `toFixed()` for money
 
+## Traceability Matrix
+| Req ID | Requirement | Task(s) | Test(s) | Status |
+|--------|-------------|---------|---------|--------|
+| REQ-001 | P&L calculation with fees | Task 1 | `tests/foo/bar.test.ts` | ⬚ |
+| REQ-002 | Input validation | Task 2 | `tests/foo/baz.test.ts` | ⬚ |
+
+Every requirement from BA's Requirements Document MUST appear in this matrix. Missing requirement = incomplete phase. `completion-gate` checks this matrix during verification.
+
 ## Files Touched
 - `src/foo/bar.ts` — new
 - `src/foo/baz.ts` — modify
@@ -400,17 +426,36 @@ Every phase file MUST include ALL of these sections (Amateur-Proof Checklist):
 6. ✅ Cross-Phase Context — what's assumed from prior phases, what's exported for future phases
 7. ✅ Acceptance Criteria — testable, includes performance if applicable
 8. ✅ Test tasks — every code task has corresponding tests
+9. ✅ Traceability Matrix — every BA requirement mapped to tasks and tests (skip if no BA requirements exist)
 
 A phase missing ANY of sections 1-7 is INCOMPLETE — the weakest coder will guess wrong.
 Performance Constraints section is optional (only when NFRs apply).
 </HARD-GATE>
 
+### Step 5.5 — Completeness Scoring (Alternatives)
+
+When presenting alternative approaches (from brainstorm or Step 3 decisions), rate each with **Completeness X/10**:
+
+| Score | Meaning |
+|-------|---------|
+| 9-10 | Complete — all edge cases, full coverage, production-ready |
+| 7-8 | Happy path covered, some edges skipped |
+| 4-6 | Shortcut — defers significant work |
+| 1-3 | Minimal viable, debt guaranteed |
+
+**Always recommend higher-completeness option.** With AI-assisted coding, the marginal cost of completeness is near-zero. Show dual effort estimates for each approach: `(human: ~X / AI: ~Y)`.
+
+**Anti-pattern**: "Option B saves 70 LOC" → 70 LOC delta is meaningless with AI. Choose complete. The last 10% of coverage is where production bugs hide.
+
+> Source: garrytan/gstack v0.9.0 — "Boil the Lake" principle.
+
 ### Step 6 — Present and Get Approval
 
 Present the **master plan** to user (NOT all phase files). User reviews:
 - Phase breakdown
 - Key decisions
 - Risks
+- Completeness scores for chosen approach (from Step 5.5)
 
 Wait for explicit approval ("go", "proceed", "yes") before writing phase files.
 
@@ -609,6 +654,19 @@ Max 200 lines. Self-contained — coder needs ONLY this file.
 | Tasks without `depends_on` in Wave 2+ | MEDIUM | Implicit dependencies break parallel dispatch. Every Wave 2+ task MUST declare `depends_on` |
 | Plan ignores locked Decisions from BA | CRITICAL | Decision Compliance section cross-checks requirements.md — locked decisions are non-negotiable |
 | Complex feature missing Workflow Registry — components planned but never wired | HIGH | Step 4.5: 4-view registry catches orphaned components, unphased workflows, and missing state transitions before phase files are written |
+| Recommending shortcut approach without Completeness Score | MEDIUM | Step 5.5: every alternative needs X/10 Completeness score + dual effort estimate (human vs AI). "Saves 70 LOC" is not a reason when AI makes the delta cost minutes |
+
+## Self-Validation
+
+```
+SELF-VALIDATION (run before presenting plan to user):
+- [ ] Every task has a clear file path — no "update relevant files" vagueness
+- [ ] Wave dependencies are acyclic — no task depends on a task in the same or later wave
+- [ ] Every code-producing phase has at least one test task
+- [ ] Phase files have ALL Amateur-Proof sections (data flow, code contracts, failure scenarios, rejection criteria)
+- [ ] Locked decisions from BA are reflected in plan — none contradicted or ignored
+- [ ] Every BA requirement has a corresponding Req ID in at least one phase's Traceability Matrix
+```
 
 ## Done When
 
@@ -623,6 +681,7 @@ Max 200 lines. Self-contained — coder needs ONLY this file.
 - Every code-producing phase has test tasks
 - Master plan presented to user with "Awaiting Approval"
 - User has explicitly approved
+- Self-Validation: all checks passed
 
 ## Cost Profile
 

package/skills/preflight/SKILL.md

@@ -3,7 +3,7 @@ name: preflight
 description: Pre-commit quality gate that catches "almost right" code. Goes beyond linting — checks logic correctness, error handling, regressions, and completeness.
 metadata:
   author: runedev
-  version: "0.2.0"
+  version: "0.3.0"
   layer: L2
   model: sonnet
   group: quality
@@ -158,6 +158,52 @@ Verify that new code ships complete:
 
 If any completeness item is missing, flag as **WARN** with: what is missing, which file needs it.
 
+### Step 4.5 — Domain Quality Hooks
+
+Apply domain-specific quality checks based on detected file types in the diff. These extend the generic completeness checks in Step 4 with deeper domain validation.
+
+<HARD-GATE>
+Domain hooks are additive — they add checks, never remove generic ones from Steps 1-4.
+If a domain hook flags BLOCK, the overall preflight verdict is BLOCK regardless of other steps.
+</HARD-GATE>
+
+#### Hook Selection (auto-detect from diff)
+
+| Detected Pattern | Domain Hook | Key Checks |
+|-----------------|-------------|------------|
+| `migrations/*.sql`, `*.migration.*` | Database | Rollback script present, no bare DROP/DELETE, migration tested |
+| `openapi.*`, `*.graphql`, `*.proto` | API Contract | Breaking changes flagged, version bumped, deprecated fields documented |
+| `docs/policies/*`, `PRIVACY*`, `TERMS*` | Legal/Compliance | No placeholder text, review date current, practice matches policy |
+| `**/billing*`, `**/payment*`, `**/invoice*` | Financial | Decimal precision correct, currency locale-aware, no hardcoded rates |
+| `skills/*/SKILL.md`, `extensions/*/PACK.md` | Rune Skill | Frontmatter valid, all required sections present, word count within layer budget |
+| `*.test.*`, `*.spec.*`, `__tests__/*` | Test Quality | No `.skip`/`.only` left in, assertions present (not empty tests), no hardcoded timeouts |
+
+#### Domain Hook Execution
+
+For each detected domain, run its checks on the relevant files in the diff:
+
+1. **Identify** which domain hooks apply based on changed file patterns
+2. **Load** domain-specific check rules (inline above, or from pack reference files if a pack is installed)
+3. **Scan** each relevant file for domain violations
+4. **Classify** findings: BLOCK (data loss risk, breaking contract) or WARN (best practice, incomplete)
+5. **Append** to preflight report under `### Domain Quality` section
+
+#### Pack Integration
+
+When a domain pack is installed (e.g., `@rune-pro/finance`, `@rune-pro/legal`), preflight checks the pack's **Hard-Stop Thresholds** table and applies matching rules to staged files. This means:
+- Installing `@rune-pro/finance` automatically adds financial quality gates to preflight
+- Installing `@rune-pro/legal` automatically adds compliance checks to preflight
+- No manual configuration needed — pack presence = hooks active
+
+#### Output Section
+
+```
+### Domain Quality
+- **Domains detected**: [Database, Financial]
+- `migrations/003-add-billing.sql` — BLOCK: DROP TABLE without rollback script
+- `src/billing/invoice.ts:42` — WARN: price calculation uses `toFixed(2)` instead of `Intl.NumberFormat`
+```
+
 ### Step 5 — Security Sub-Check
 Invoke `rune:sentinel` on the changed files. Attach sentinel's output verbatim under the "Security" section of the preflight report. If sentinel returns BLOCK, preflight verdict is also BLOCK.
 
@@ -216,6 +262,9 @@ WARN — 3 issues found (0 blocking, 3 must-acknowledge). Resolve before commit
 | Skipping sentinel sub-check because "this file doesn't look security-relevant" | HIGH | MUST invoke sentinel — security relevance is sentinel's job to determine, not preflight's |
 | Skipping Stage A (spec compliance) when plan is available | HIGH | If cook provides an approved plan, Stage A is mandatory — catches incomplete implementations |
 | Agent modified files not in plan without flagging | MEDIUM | Stage A flags unplanned file changes as WARN — scope creep detection |
+| Domain hooks not triggered when pack is installed | HIGH | Step 4.5 auto-detects file patterns — if pack is installed but hooks don't fire, check file pattern matching |
+| Domain hooks overriding generic checks | HIGH | HARD-GATE: domain hooks are ADDITIVE — they never replace Steps 1-4 |
+| Pack Hard-Stop Thresholds ignored in preflight | MEDIUM | Step 4.5 Pack Integration must read installed pack thresholds — test with each new pack |
 
 ## Done When
 

package/skills/research/SKILL.md

@@ -3,7 +3,7 @@ name: research
 description: Web search and external knowledge lookup. Gathers data on technologies, libraries, best practices, and competitor solutions.
 metadata:
   author: runedev
-  version: "0.2.0"
+  version: "0.3.0"
   layer: L3
   model: haiku
   group: knowledge
@@ -44,25 +44,51 @@ Generate 2-3 targeted search queries from the research question. Vary phrasing t
 - Secondary: "[topic] best practices 2026" or "[topic] vs alternatives"
 - Tertiary: "[topic] example" or "[topic] tutorial" if implementation detail needed
 
-### Step 2 — Search
+### Step 2 — Search (Minimum 3 Complementary Sources)
 
-Call `WebSearch` for each query. Collect result titles, URLs, and snippets. Identify the top 3-5 most relevant URLs based on:
-- Source authority (official docs, major blogs, GitHub repos)
+<HARD-GATE>
+Every research conclusion MUST be backed by at minimum 3 complementary sources from DIFFERENT source types.
+Single-source conclusions are flagged as `low` confidence regardless of source authority.
+</HARD-GATE>
+
+Call `WebSearch` for each query. Collect result titles, URLs, and snippets. Identify the top 3-5 most relevant URLs prioritizing **source diversity**:
+
+| Source Type | Examples | Why |
+|-------------|----------|-----|
+| **Official docs** | Framework docs, API reference, RFC | Authoritative but may lag behind reality |
+| **Community** | Stack Overflow, GitHub Issues, Reddit | Real-world pain points, edge cases |
+| **Technical blogs** | Dev.to, Medium engineering blogs, personal blogs | Practical experience, tutorials |
+| **Repositories** | GitHub repos, npm packages, example code | Working implementations |
+
+**Selection rules:**
+- Source authority (official docs > major blogs > personal blogs)
 - Recency (prefer 2025-2026)
 - Relevance to the query
+- **Diversity: never select 3+ URLs from the same domain** — spread across source types
+
+> Source: K-Dense claude-scientific-skills (literature-review "minimum 3 complementary databases" pattern), adapted for software research.
 
 ### Step 3 — Deep Dive
 
 Call `WebFetch` on the top 3-5 URLs identified in Step 2. Hard limit: **max 5 WebFetch calls** per research invocation. For each fetched page:
 - Extract key facts, API signatures, code examples
 - Note the source URL and publication date if visible
+- Tag the source type (official/community/blog/repo) for Step 4 triangulation
 
-### Step 4 — Synthesize
+### Step 4 — Synthesize (Triangulation)
 
-Across all fetched content:
-- Identify points of consensus across sources
+Across all fetched content, **triangulate** — don't just aggregate:
+- Identify points of consensus across sources (≥3 sources = strong signal)
 - Flag any conflicting information explicitly (e.g., "Source A says X, Source B says Y")
-- Assign confidence: `high` (3+ sources agree), `medium` (1-2 sources), `low` (single source or unclear)
+- Check if conflicts are temporal (old vs new info) or genuine disagreement
+- Assign confidence using source diversity:
+
+| Confidence | Criteria |
+|------------|----------|
+| `high` | 3+ sources from different types agree |
+| `medium` | 2 sources agree, or 3+ from same type |
+| `low` | Single source, or sources conflict without resolution |
+| `unverified` | No sources found — report this explicitly, NEVER fabricate |
 
 ### Step 5 — Report
 
@@ -108,6 +134,8 @@ Known failure modes for this skill. Check these before declaring done.
 | Reporting conflicting sources without flagging the conflict | HIGH | Constraint: flag conflicting information explicitly, never silently pick one side |
 | Assigning "high" confidence from a single source | MEDIUM | High = 3+ sources agree; 1-2 sources = medium confidence |
 | Exceeding 5 WebFetch calls per invocation | MEDIUM | Hard limit: prioritize top 3-5 URLs from search, fetch only the most relevant |
+| Single-source conclusions presented as fact | HIGH | HARD-GATE: minimum 3 complementary sources from different source types. Single source = `low` confidence |
+| All sources from same domain (e.g., 3 Stack Overflow links) | MEDIUM | Source diversity rule: never 3+ URLs from the same domain. Spread across official/community/blog/repo |
 
 ## Done When