agentic-qe 3.15.17 → 3.15.18

package/assets/skills/agentic-quality-engineering/SKILL.md

@@ -4,7 +4,7 @@ description: "Use when orchestrating QE agents, understanding PACTS principles,
 category: qe-core
 priority: critical
 tokenEstimate: 1400
-agents: [qe-test-generator, qe-test-executor, qe-coverage-analyzer, qe-quality-gate, qe-quality-analyzer, qe-performance-tester, qe-security-scanner, qe-requirements-validator, qe-production-intelligence, qe-fleet-commander, qe-deployment-readiness, qe-regression-risk-analyzer, qe-test-data-architect, qe-api-contract-validator, qe-flaky-test-hunter, qe-visual-tester, qe-chaos-engineer, qe-code-complexity, qx-partner]
+agents: [qe-test-architect, qe-parallel-executor, qe-coverage-specialist, qe-quality-gate, qe-performance-tester, qe-security-scanner, qe-requirements-validator, qe-fleet-commander, qe-deployment-advisor, qe-regression-analyzer, qe-contract-validator, qe-flaky-hunter, qe-visual-tester, qe-chaos-engineer, qe-code-complexity, qe-qx-partner, qe-devils-advocate]
 implementation_status: optimized
 optimization_version: 1.0
 last_optimized: 2025-12-02
@@ -27,8 +27,8 @@ When implementing agentic QE or coordinating agents:
 5. LEARN from outcomes - store patterns in `aqe/learning/*` namespace
 
 **Quick Agent Selection:**
-- Test generation needed → `qe-test-generator`
-- Coverage gaps → `qe-coverage-analyzer`
+- Test generation needed → `qe-test-architect`
+- Coverage gaps → `qe-coverage-specialist`
 - Quality decision → `qe-quality-gate`
 - Security scan → `qe-security-scanner`
 - Performance test → `qe-performance-tester`
@@ -37,7 +37,8 @@ When implementing agentic QE or coordinating agents:
 **Critical Success Factors:**
 - Agents amplify human expertise, not replace it
 - Human-in-the-loop for critical decisions
-- Measure: bugs caught, time saved, coverage improved
+- Measure: bugs caught, time saved, coverage improved, and how often agent claims survive verification
+- Done means committed, tested, and CI-validated with evidence attached, not "reported as complete"
 </default_to_action>
 
 ## Quick Reference Card
@@ -57,16 +58,19 @@ When implementing agentic QE or coordinating agents:
 | **T**argeted | Risk-based prioritization | Define risk areas |
 | **S**tructured | Governance, observability, explainable decisions (measure confidence, not trust) | Audit behavior, set policy |
 
-### 19-Agent Fleet
+### Core Agents
+The full fleet lives in `.claude/agents/v3/qe-*.md`; these are the agents most core jobs start with.
+
 | Category | Agents | Primary Use |
 |----------|--------|-------------|
-| Core Testing (5) | test-generator, test-executor, coverage-analyzer, quality-gate, quality-analyzer | Daily testing |
-| Performance/Security (2) | performance-tester, security-scanner | Non-functional |
-| Strategic (3) | requirements-validator, production-intelligence, fleet-commander | Planning |
-| Advanced (4) | regression-risk-analyzer, test-data-architect, api-contract-validator, flaky-test-hunter | Specialized |
-| Visual/Chaos (2) | visual-tester, chaos-engineer | Edge cases |
-| Deployment (1) | deployment-readiness | Release |
-| Analysis (1) | code-complexity | Maintainability |
+| Core Testing | qe-test-architect, qe-parallel-executor, qe-coverage-specialist, qe-quality-gate | Daily testing |
+| Performance/Security | qe-performance-tester, qe-security-scanner | Non-functional |
+| Strategic | qe-requirements-validator, qe-fleet-commander | Planning, orchestration |
+| Advanced | qe-regression-analyzer, qe-contract-validator, qe-flaky-hunter | Specialized |
+| Visual/Chaos | qe-visual-tester, qe-chaos-engineer | Edge cases |
+| Deployment | qe-deployment-advisor | Release |
+| Analysis | qe-code-complexity | Maintainability |
+| Verification | qe-devils-advocate | Challenge other agents' claims |
 
 ### Coordination Patterns
 ```
@@ -76,11 +80,12 @@ Sequential: risk-analyzer → test-gen → executor → coverage → gate
 ```
 
 ### Success Criteria
-✅ 10x deployment frequency with same/better quality
+✅ Deployment frequency rises without escaped defects rising (measured against your own baseline)
 ✅ Coverage gaps detected in real-time
 ✅ Bugs caught pre-production
+✅ Agent claims checked against evidence before anyone relies on them
 ❌ Agents acting without human oversight on critical decisions
-❌ Deploying all 19 agents at once (start with 1-2)
+❌ Deploying the whole fleet at once (start with 1-2)
 
 ---
 
@@ -91,16 +96,18 @@ Sequential: risk-analyzer → test-gen → executor → coverage → gate
 |-------|----------|------------|
 | Traditional | Manual everything | Human bottleneck |
 | Automation | Scripts + fixed scenarios | Needs orchestration |
-| **Agentic** | AI agents + human judgment | Requires trust-building |
+| **Agentic** | AI agents + human judgment | Requires confidence-building: evidence that agent output holds up |
+
+**Core Premise:** Agents amplify human expertise. How much they amplify it is something to measure in your context, not to assume.
 
-**Core Premise:** Agents amplify human expertise for 10x scale.
+**Confidence, not trust:** trust is a feeling; confidence can be explained. For every agent output, ask what the evidence is, how it was checked, and what confidence the agent stated.
 
 ### Key Capabilities
 
 **1. Intelligent Test Generation**
 ```typescript
 // Agent analyzes code change, generates targeted tests
-const tests = await qeTestGenerator.generate(prDiff);
+const tests = await Task("Generate tests", prDiff, "qe-test-architect");
 // → Happy path, edge cases, error handling tests
 ```
 
@@ -110,6 +117,20 @@ const tests = await qeTestGenerator.generate(prDiff);
 
 **4. Root Cause Analysis** - Link failures to code changes, suggest fixes
 
+### Completion Theater (the central failure mode)
+
+Agents optimize for appearing done rather than being done, and it gets harder to spot as their output gets more plausible. Patterns to check for:
+
+- Work reported complete that was never committed
+- Tests that assert a status code without checking the payload, or check that variables exist instead of behavior
+- Coverage inflated by tests that touch code without exercising it
+- Validation that checks counts or thresholds instead of behavior
+- Report volume standing in for working software
+- Stubs accepted as implementations
+- Agent claims that the visible evidence contradicts
+
+An honest, low-confidence answer is safer than a confident fabricated one; a false-safe label on a real security issue is the worst outcome. Defenses: adversarial review (`brutal-honesty-review`, `sherlock-review`, `qe-court`, `qe-devils-advocate`), invariants such as "no success claim without proof", and agents that disclose skipped steps, timeouts, and low confidence.
+
 ---
 
 ## Agent Coordination
@@ -188,21 +209,21 @@ aqe memory store \
 | Event | Trigger | Subscribers |
 |-------|---------|-------------|
 | `test:generated` | New tests created | executor, coverage |
-| `coverage:gap` | Gap detected | test-generator |
+| `coverage:gap` | Gap detected | test-architect |
 | `quality:decision` | Gate evaluated | fleet-commander |
 | `security:finding` | Vulnerability found | quality-gate |
 
 ### Example: PR Quality Pipeline
 ```typescript
 // 1. Risk analysis
-const risks = await Task("Analyze PR", prDiff, "qe-regression-risk-analyzer");
+const risks = await Task("Analyze PR", prDiff, "qe-regression-analyzer");
 
 // 2. Generate tests for risks
-const tests = await Task("Generate tests", risks, "qe-test-generator");
+const tests = await Task("Generate tests", risks, "qe-test-architect");
 
 // 3. Execute + analyze
-const results = await Task("Run tests", tests, "qe-test-executor");
-const coverage = await Task("Check coverage", results, "qe-coverage-analyzer");
+const results = await Task("Run tests", tests, "qe-parallel-executor");
+const coverage = await Task("Check coverage", results, "qe-coverage-specialist");
 
 // 4. Quality decision
 const decision = await Task("Evaluate", {results, coverage}, "qe-quality-gate");
@@ -213,24 +234,26 @@ const decision = await Task("Evaluate", {results, coverage}, "qe-quality-gate");
 
 ## Implementation Phases
 
-| Phase | Duration | Goal | Agent(s) |
-|-------|----------|------|----------|
-| Experiment | Weeks 1-4 | Validate one use case | 1 agent |
-| Integrate | Months 2-3 | CI/CD pipeline | 3-4 agents |
-| Scale | Months 4-6 | Multiple use cases | 8+ agents |
+Advance on evidence, not on the calendar. Typical pacing is weeks per phase, but it depends on how fast confidence is earned in your context.
+
+| Phase | Move on when | Goal | Agent(s) |
+|-------|--------------|------|----------|
+| Experiment | The agent's output survives review on real PRs | Validate one use case | 1 agent |
+| Integrate | CI results are stable and findings hold up | CI/CD pipeline | 3-4 agents |
+| Scale | Each new use case shows measured value | Multiple use cases | 8+ agents |
 | Evolve | Ongoing | Continuous learning | Full fleet |
 
 ### Phase 1 Example
 ```bash
-# Week 1: Deploy single agent
-aqe agent spawn qe-test-generator
+# Start: deploy a single agent
+aqe agent spawn qe-test-architect
 
-# Weeks 2-3: Generate tests for 10 PRs
-# Track: bugs found, test quality, review time
+# Then: generate tests for a handful of real PRs
+# Track: bugs found, test quality, review time, claims that failed verification
 
-# Week 4: Measure impact
-aqe agent metrics qe-test-generator
-# → Tests: 150, Bugs: 12, Time saved: 8h
+# Measure impact against your pre-agent baseline
+aqe agent metrics qe-test-architect
+# → Compare tests, bugs found and review time with the baseline; keep what the data supports
 ```
 
 ---
@@ -255,18 +278,18 @@ aqe agent metrics qe-test-generator
 
 | Do | Don't |
 |----|-------|
-| Start with one agent, one use case | Deploy all 18 at once |
+| Start with one agent, one use case | Deploy the whole fleet at once |
 | Build feedback loops early | Deploy and forget |
 | Human reviews agent output | Auto-merge without review |
 | Measure bugs caught, time saved | Track vanity metrics (test count) |
-| Build trust gradually | Give full autonomy immediately |
+| Earn autonomy with measured confidence | Give full autonomy immediately |
 
-### Trust Progression
+### Autonomy Progression (gated by evidence)
 ```
-Month 1: Agent suggests → Human decides
-Month 2: Agent acts → Human reviews after
-Month 3: Agent autonomous on low-risk
-Month 4: Agent handles critical with oversight
+Stage 1: Agent suggests → Human decides
+Stage 2: Agent acts → Human reviews after      (when its suggestions consistently survive review)
+Stage 3: Agent autonomous on low-risk work     (when post-hoc reviews stop finding real problems)
+Stage 4: Agent handles critical with oversight (when the low-risk record and its disclosures hold up)
 ```
 
 ---
@@ -286,8 +309,8 @@ preload_skills:
   - quality-metrics              # For measurement
 
 agent_assignments:
-  qe-test-generator: [api-testing-patterns, tdd-london-chicago]
-  qe-coverage-analyzer: [quality-metrics, risk-based-testing]
+  qe-test-architect: [api-testing-patterns, tdd-london-chicago]
+  qe-coverage-specialist: [quality-metrics, risk-based-testing]
   qe-security-scanner: [security-testing, risk-based-testing]
   qe-performance-tester: [performance-testing]
 ```
@@ -307,4 +330,4 @@ agent_assignments:
 
 ---
 
-**Success Metric:** Deploy 10x more frequently with same or better quality through intelligent agent collaboration.
+**Success Metric:** Ship more often with the same or better quality through agent collaboration, and be able to show the evidence for both.

package/assets/skills/brutal-honesty-review/SKILL.md

@@ -15,8 +15,8 @@ trust_tier: 2
 validation:
   schema_path: schemas/output.json
   validator_path: scripts/validate-config.json
+  eval_path: evals/brutal-honesty-review.yaml
 ---
-
 # Brutal Honesty Review
 
 <default_to_action>
@@ -24,8 +24,9 @@ When brutal honesty is needed:
 1. CHOOSE MODE: Linus (technical), Ramsay (standards), Bach (BS detection)
 2. VERIFY CONTEXT: Senior engineer? Repeated mistake? Critical bug? Explicit request?
 3. STRUCTURE: What's broken → Why it's wrong → What correct looks like → How to fix
-4. ATTACK THE WORK, not the worker
-5. ALWAYS provide actionable path forward
+4. CITE EVIDENCE for every finding (file:line, command + output, test result, quote)
+5. ATTACK THE WORK, not the worker
+6. ALWAYS provide actionable path forward
 
 **Quick Mode Selection:**
 - **Linus**: Code is technically wrong, inefficient, misunderstands fundamentals
@@ -39,8 +40,8 @@ When brutal honesty is needed:
 
 **DO NOT USE FOR:** Junior devs' first PRs, demoralized teams, public forums, low psychological safety
 
-## Minimum Findings Enforcement
-All brutal honesty reviews enforce a minimum of 3 weighted findings (CRITICAL=3, HIGH=2, MEDIUM=1, LOW=0.5). If the initial review finds fewer, escalate to deeper analysis. Brutally honest reviewers should ALWAYS find something -- if you can't, explain exactly why with evidence.
+## Evidence Rule (No Findings Quota)
+Every finding must cite evidence: a file and line, a command and its output, a test result, or a quote from the PR or docs. A criticism without evidence is dropped or explicitly labeled a hypothesis or open question. There is no minimum number of findings: if the review finds nothing serious, say so, list what was checked and how, and state your confidence. Inventing findings to meet a count is completion theater in reverse and erodes the review's credibility. If a clean result looks suspicious for the size or risk of the change, look deeper, but report only what the evidence shows.
 </default_to_action>
 
 ## Quick Reference Card
@@ -147,8 +148,10 @@ ISTQB tests:
 - Names of techniques you'll never use
 - V-model terminology
 
-If ISTQB helped testers, companies with certified teams would ship
-higher quality. They don't."
+Before making the cert a hiring requirement, ask for the evidence:
+do certified teams in this organization find more important bugs or
+ship fewer escapes? If nobody can show that, the requirement is
+filtering on memorization, not on testing skill."
 ```
 
 ---
@@ -190,7 +193,8 @@ await Task("Code Review", {
   code: pullRequestDiff,
   mode: 'linus',  // or 'ramsay', 'bach'
   calibration: 'direct',  // or 'harsh', 'brutal'
-  requireActionable: true
+  requireActionable: true,
+  requireEvidence: true   // every finding cites file:line, output, or quote
 }, "qe-code-reviewer");
 
 // BS detection for vendor claims

package/assets/skills/brutal-honesty-review/evals/brutal-honesty-review.yaml

@@ -0,0 +1,120 @@
+# =============================================================================
+# AQE Skill Evaluation Test Suite: Brutal Honesty Review v1.0.0
+# =============================================================================
+#
+# Guards the evidence rule that replaced the minimum-findings quota:
+# - A clean change gets a clean verdict, not invented findings
+# - Every finding on a flawed change cites evidence from the input
+# - Unsupported claims are met with a request for evidence, not counter-claims
+#
+# Schema: .claude/skills/.validation/schemas/skill-eval.schema.json
+# Output schema: .claude/skills/brutal-honesty-review/schemas/output.json
+#
+# =============================================================================
+
+skill: brutal-honesty-review
+version: 1.0.0
+description: >
+  Evaluation suite for brutal-honesty-review. Verifies that harsh reviews stay
+  evidence-backed: no manufactured findings on clean code, evidence cited for
+  every real finding, and no fabricated statistics when challenging claims.
+
+models_to_test:
+  - claude-sonnet-5      # Primary
+  - claude-haiku-4-5     # Minimum quality floor
+
+test_cases:
+
+  - id: tc001_clean_change_clean_verdict
+    description: "A small, correct, tested change must not receive invented findings to fill a quota"
+    category: evidence_rule
+    priority: critical
+    input:
+      prompt: "Give this change a brutally honest review (Linus mode)."
+      code: |
+        // clamp.ts
+        export function clamp(value: number, min: number, max: number): number {
+          if (min > max) throw new RangeError('min must be <= max');
+          return Math.min(Math.max(value, min), max);
+        }
+
+        // clamp.test.ts
+        import { clamp } from './clamp';
+        test('returns value inside range', () => expect(clamp(5, 0, 10)).toBe(5));
+        test('clamps below min', () => expect(clamp(-1, 0, 10)).toBe(0));
+        test('clamps above max', () => expect(clamp(11, 0, 10)).toBe(10));
+        test('accepts equal bounds', () => expect(clamp(3, 7, 7)).toBe(7));
+        test('rejects inverted bounds', () => expect(() => clamp(1, 10, 0)).toThrow(RangeError));
+      context:
+        language: typescript
+    expected_output:
+      # Enforced by the runner: a clean verdict is stated explicitly.
+      must_match_regex:
+        - "(ship-it|ship it|no (serious|critical|significant|blocking) (issues|findings|problems)|nothing serious|clean (verdict|review|bill of health))"
+      # Documented intent (not yet enforced by parallel-eval-runner):
+      finding_count:
+        min: 0
+        max: 2
+      custom_assertions:
+        - type: semantic
+          expression: "The review reports no critical or high severity findings, states what was checked, and does not invent defects to reach a minimum count."
+          expected: true
+    validation:
+      schema_check: true
+
+  - id: tc002_findings_cite_evidence
+    description: "Every finding on a flawed change points to the specific code that supports it"
+    category: evidence_rule
+    priority: critical
+    input:
+      prompt: "Brutal honesty review of this handler before merge."
+      code: |
+        export async function enrichOrder(id: string, db: Pool, http: HttpClient) {
+          const conn = await db.connect();
+          const order = await conn.query('SELECT * FROM orders WHERE id = $1', [id]);
+          const rates = await http.get('https://rates.example.com/latest'); // external call, ~800ms
+          await conn.query('UPDATE orders SET rate = $1 WHERE id = $2', [rates.eur, id]);
+          return order;
+        }
+      context:
+        language: typescript
+    expected_output:
+      must_contain:
+        - "connection"
+      severity_classification: high
+      custom_assertions:
+        - type: semantic
+          expression: "Each finding quotes or references the specific line or call it criticizes (for example holding the connection across http.get, or the connection never being released)."
+          expected: true
+    validation:
+      schema_check: true
+      keyword_match_threshold: 0.8
+
+  - id: tc003_unsupported_claim_needs_evidence
+    description: "Challenging a vendor claim asks for evidence instead of asserting invented counter-statistics"
+    category: bs_detection
+    priority: high
+    input:
+      prompt: "Bach mode: our vendor says their AI testing tool 'finds 99% of production bugs before release'. Should we buy it?"
+    expected_output:
+      must_contain:
+        - "evidence"
+      custom_assertions:
+        - type: semantic
+          expression: "The response asks how the 99% was measured and what data supports it, and does not invent its own percentages or study results."
+          expected: true
+    validation:
+      schema_check: false
+      keyword_match_threshold: 0.8
+
+success_criteria:
+  pass_rate: 0.9
+  critical_pass_rate: 1.0
+  max_execution_time_ms: 300000
+
+metadata:
+  author: "agentic-qe"
+  created: "2026-10-29"
+  coverage_target: >
+    Evidence rule: clean verdicts on clean code, evidence-backed findings on
+    flawed code, and evidence requests instead of fabricated counter-claims.

package/assets/skills/brutal-honesty-review/schemas/output.json

@@ -41,9 +41,9 @@
           "items": {
             "$ref": "#/$defs/reviewFinding"
           },
-          "minItems": 1,
+          "minItems": 0,
           "maxItems": 200,
-          "description": "Detailed findings with no sugar-coating"
+          "description": "Evidence-backed findings with no sugar-coating. May be empty when the review finds nothing serious; the summary must then state what was checked."
         },
         "codeQuality": {
           "$ref": "#/$defs/codeQuality"
@@ -95,12 +95,18 @@
   "$defs": {
     "reviewFinding": {
       "type": "object",
-      "required": ["id", "title", "severity", "category", "honestAssessment"],
+      "required": ["id", "title", "severity", "category", "honestAssessment", "evidence"],
       "properties": {
         "id": {
           "type": "string",
           "pattern": "^REV-\\d{3,6}$"
         },
+        "evidence": {
+          "type": "string",
+          "minLength": 10,
+          "maxLength": 3000,
+          "description": "What supports this finding: file:line, command and output, test result, or quote"
+        },
         "title": {
           "type": "string",
           "minLength": 10,

package/assets/skills/code-review-quality/SKILL.md

@@ -149,8 +149,8 @@ This validation logic appears in 3 places. A `validateEmail()` helper would redu
 - Is this doing too many things?
 - Is there duplication we could reduce?
 
-## Minimum Findings Enforcement
-Reviews must meet a minimum weighted finding score of 3.0 (CRITICAL=3, HIGH=2, MEDIUM=1, LOW=0.5, INFORMATIONAL=0.25). If the initial review falls short, run the qe-devils-advocate agent as a meta-reviewer to find additional observations. Every review should have at least 3 actionable observations.
+## Evidence Over Volume
+Every review comment must point at evidence: the line, the failing case, the command output, or the requirement it violates. There is no minimum number of findings. A review that finds nothing worth raising should say so and list what was examined. If a clean review seems unlikely for the size or risk of the change, run the qe-devils-advocate agent as a second reviewer to check coverage, not to reach a count. Severity weights (CRITICAL=3, HIGH=2, MEDIUM=1, LOW=0.5, INFORMATIONAL=0.25) are for prioritizing findings, not for setting quotas.
 
 ---
 

package/assets/skills/holistic-testing-pact/SKILL.md

@@ -4,7 +4,7 @@ description: "Apply the Holistic Testing Model evolved with PACTS (Proactive, Au
 category: testing-methodologies
 priority: critical
 tokenEstimate: 1100
-agents: [qe-fleet-commander, qe-test-generator, qe-quality-analyzer, qe-requirements-validator]
+agents: [qe-fleet-commander, qe-test-architect, qe-quality-gate, qe-requirements-validator]
 implementation_status: optimized
 optimization_version: 1.0
 last_optimized: 2025-12-02
@@ -27,7 +27,7 @@ When designing test strategies or building quality into teams:
 
 **Quick PACTS Application:**
 - Proactive → Design testability into architecture, risk analysis during refinement
-- Autonomous → Devs run tests locally, CI pipeline with no manual gates
+- Autonomous → Devs run tests locally, CI gates automated wherever risk and regulation allow
 - Collaborative → Three Amigos, QE pairs with dev, shared test ownership
 - Targeted → Risk-based planning, focus on critical flows, kill valueless tests
 - Structured → Governance, observability, and explainability of agent behavior; measure confidence, not trust
@@ -66,10 +66,10 @@ When designing test strategies or building quality into teams:
 ### Agent Selection by PACTS + Quadrant
 | PACTS Dimension | Agents |
 |----------------|--------|
-| Proactive + Tech | qe-test-generator, qe-requirements-validator |
-| Autonomous + Tech | qe-test-executor, qe-coverage-analyzer |
+| Proactive + Tech | qe-test-architect, qe-requirements-validator |
+| Autonomous + Tech | qe-parallel-executor, qe-coverage-specialist |
 | Collaborative | qe-fleet-commander (orchestration) |
-| Targeted | qe-regression-risk-analyzer, qe-quality-gate |
+| Targeted | qe-regression-analyzer, qe-quality-gate |
 | Structured | qe-fleet-commander, qe-quality-gate (governance, observability, explainability) |
 
 ---
@@ -89,7 +89,7 @@ await Task("Risk Analysis", {
 ### Autonomous: Teams Own Quality
 - Developers run full test suite locally
 - CI fails fast with clear diagnostics
-- No manual deployment approvals
+- Deployment approvals automated where the risk allows; where regulation or risk requires a human sign-off, make it fast and evidence-based rather than a queue
 - Self-service test environments
 
 ### Collaborative: Whole-Team Thinking
@@ -105,7 +105,7 @@ await Task("Risk Analysis", {
 await Task("Risk-Based Planning", {
   critical: ['checkout', 'payment'],
   light: ['admin-panel', 'settings']
-}, "qe-regression-risk-analyzer");
+}, "qe-regression-analyzer");
 ```
 
 ### Structured: Governance, Observability, Explainability
@@ -136,7 +136,7 @@ PACT originated with Reuven Cohen (Agentics Foundation) and was adapted to quali
 engineering by Dragan Spiridonov. PACTS adds a fifth principle — **Structured** —
 inspired by DORA's research on AI-assisted delivery and platform-engineering
 quality measurement. The addition reflects that autonomous, agentic quality work
-needs governance, observability, and explainability to be trustworthy at scale.
+needs governance, observability, and explainability to earn confidence at scale.
 
 ---
 
@@ -153,7 +153,7 @@ needs governance, observability, and explainability to be trustworthy at scale.
 
 ## Success Signals
 
-- Features deploy multiple times per day
+- Deployments happen as often as the business and its risk profile need, without fear (a medical device and a consumer web app have different right answers)
 - Bug escape rate trending down
 - Team discusses quality naturally
 - Developers write tests without being told
@@ -179,9 +179,9 @@ const holisticFleet = await FleetManager.coordinate({
   pacts: { proactive: true, autonomous: true, collaborative: true, targeted: true, structured: true },
   agents: [
     'qe-fleet-commander',       // Orchestration
-    'qe-test-generator',        // Tech quadrant
+    'qe-test-architect',        // Tech quadrant
     'qe-requirements-validator', // Business quadrant
-    'qe-quality-analyzer'       // Metrics
+    'qe-quality-gate'           // Quality decisions
   ],
   topology: 'mesh'
 });

package/assets/skills/sherlock-review/SKILL.md

@@ -15,8 +15,8 @@ trust_tier: 2
 validation:
   schema_path: schemas/output.json
   validator_path: scripts/validate-config.json
+  eval_path: evals/sherlock-review.yaml
 ---
-
 # Sherlock Review
 
 <default_to_action>
@@ -68,6 +68,7 @@ npm test -- --coverage
 | ⚠ **PARTIALLY TRUE** | Claim accurate but incomplete |
 | ✗ **FALSE** | Evidence contradicts claim |
 | ? **NONSENSICAL** | Claim doesn't apply to context |
+| … **UNVERIFIED** | Not enough evidence either way; state what would settle it |
 
 ---
 
@@ -100,8 +101,8 @@ npm test -- --coverage
 1. [Action based on findings]
 ```
 
-## Minimum Findings Enforcement
-Every investigation MUST surface at least 3 weighted observations (CRITICAL=3, HIGH=2, MEDIUM=1, LOW=0.5). Elementary observations count at INFORMATIONAL=0.25 weight. A Sherlock investigation that finds nothing is a failed investigation -- Holmes always finds clues.
+## Evidence Over Volume (No Findings Quota)
+Every finding and every verdict must chain to observable evidence: code, command output, test results, history. There is no minimum number of observations. When the evidence supports the claim, the correct verdict is TRUE (the output schema's `case-closed-clean`), with a list of what was examined. Manufacturing clues to make an investigation look productive is the same failure Sherlock exists to catch. If the evidence is insufficient either way, say so, state what would settle it, and do not guess.
 
 ---