gate-l3-evidence-truth

Files (17)

• SKILL.md
• .gitkeep · evals/
• evals.json · evals/
• .gitkeep · metrics/
• rich-gate-scorecard.md · metrics/
• .gitkeep · references/
• adopted-patterns.md · references/
• anti-patterns.md · references/
• cross-skill-routing-detail.md · references/
• evaluation-checklist.md · references/
• evaluation-workflow-detail.md · references/
• harness-verification-trees.md · references/
• perspective-rubrics.md · references/
• .gitkeep · scripts/
• run-evidence-check.sh · scripts/
• .gitkeep · templates/
• evidence-report.md · templates/

SKILL.md (first lines)

## The Iron Law

```
No gate passes on documentation alone. Evidence must be classified, honest, and runtime-verified.
```

# Gate Evidence Truth

Terminal gate in the quality-gate triad. Receives from `gate-spec-compliance` after spec alignment clears. If evidence truth PASSES, all three gates (spec, lifecycle, evidence) are satisfied and work may proceed to merge/release.

## On Load

1. Read `references/evaluation-checklist.md` — per-dimension audit criteria
2. Read `references/anti-patterns.md` — known evidence anti-patterns and detection
3. Read `references/harness-verification-trees.md` — module-specific verification protocols

## Do NOT Load

Skip this skill when:

- Performing spec alignment checks — use `gate-spec-compliance` instead
- Checking lifecycle coverage — use `gate-lifecycle-integration` instead
- Running research or exploration workflows (not gate verification)
- The calling workflow has not passed `gate-spec-compliance` yet
- No implementation artifacts exist to evaluate

## Evidence Hierarchy

Classify every evidence artifact into exactly one level:

| Level | Source | Example |
|-------|--------|---------|
| **L1** | Live OpenCode runtime session | Feature exercised in actual OpenCode instance |
| **L2** | Continuity record from live run | Delegation/session record captured from real execution |
| **L3** | Integration test passing | Tests hitting real SDK boundaries (not mocked) |
| **L4** | Unit test passing | Tests that mock SDK boundaries |
| **L5** | Documentation/historical summary | Specs, design docs, conversation summaries |

**L5 alone never passes any gate.**

## Gate Type → Minimum Evidence Level

| Gate Type | Minimum Level | Required Evidence |
|-----------|---------------|-------------------|
| PR review | L3 | At least integration tests hitting real boundaries |
| Phase completion | L2 | Continuity record from real run |
| Merge | L2 | Continuity record from real run |
| Milestone completion | L2 + one L1 | Continuity record plus at least one live session proof |
| Release/deployment | L1 | Live runtime proof required |

## Contextual Perspective Activation

Determine the current context, then activate the appropriate evaluation lens:

| Context | Primary Lens | Secondary Lens | Emphasis |
|---------|-------------|----------------|---------|
| Code review | Dev | Architect | Test integrity, mock coverage |
| Phase audit | Architect | PM | Evidence hierarchy compliance, regression |
| Milestone verification | PM | Architect | Runtime proof, completion honesty |
| Integration check | Architect | Dev | Live verification, cross-boundary testing |
| Deployment readiness | All three | — | Full evidence verification across all dimensions |

Load `references/perspective-rubrics.md` for per-lens evaluation criteria.

## Core Evaluation Workflow

Follow this checklist in order:

```
- [ ] STEP 1: GATHER — Collect all evidence artifacts for the claim
- [ ] STEP 2: CLASSIFY — Assign L1–L5 to each artifact using evidence hierarchy
- [ ] STEP 3: CHECK MINIMUM — Does highest evidence level meet gate-type minimum?
- [ ] STEP 4: DETECT MOCKS — Any mock-only claims for integration surfaces?
- [ ] STEP 5: CHECK COMPLETION HONESTY — Any completion claims without backing evidence?
- [ ] STEP 6: REGRESSION CHECK — Any cross-phase regression risk from dependency graph?
- [ ] STEP 7: ANTI-PATTERN SCAN — Match evidence against anti-pattern catalog
- [ ] STEP 8: VERDICT — Render PASS or FAIL with remediation plan
```

See `references/evaluation-workflow-detail.md` for detailed step procedures, mock detection commands, and classification guidance.

## Cross-Skill Routing

### Triad Flow (lifecycle → spec → evidence)

```
gate-lifecycle-integration (ENTRY — checks lifecycle correctness)
    ↓ PASS
gate-spec-compliance (MIDDLE — checks spec alignment)
    ↓ PASS
gate-evidence-truth ← YOU ARE HERE (TERMINAL)
    ↓
    ├─ PASS → ALL 3 GATES CLEAR → proceed to merge/release
    └─ FAIL → STOP → produce remediation plan → route to appropriate fix skill
```

Triad backward references, evidence collection handoff from `hm-production-readiness`, and full remediation routing are in `references/cross-skill-routing-detail.md`.

### Related Skills

| Related Skill | Role | Interaction |
|---------------|------|-------------|
| `gate-lifecycle-integration` | Entry gate | Must pass before spec compliance runs |
| `gate-spec-compliance` | Middle gate | Routes to this gate on PASS |
| `hm-production-readiness` | Evidence collector | Feeds structured L1-L5 evidence into this gate |
| `hm-cross-cutting-change` | Mock honesty | Remediation target for mock-only failures |
| `hm-debug` | Root-cause investigation | Remediation for insufficient evidence level |
| `hm-completion-looping` | Loop-back control | Uses this gate's verdict for loop-back decisions |
| `hm-coordinating-loop` | Orchestration re-dispatch | Re-dispatches when evidence or regression gaps found |
| `hm-gate-orchestrator` | Triad lifecycle manager | Orchestrates triad sequencing, state persistence, cross-gate handoff |

## Adopted Patterns

Synthesizes three proven methodologies: **Anthropic Gather→Act→Verify**, **Google Testing Pyramid (70-20-10)**, **GRADE Evidence Framework**. See `references/adopted-patterns.md` for full synthesis.

## Self-Correction

### Mode 1: When No Evidence Exists

From shynlee04/hivemind-plugin, MIT.

More from shynlee04/hivemind-plugin