hera-review-test-adversary git:20260719.ec8e6eaA

Immutable. This exact content is served forever at /api/v1/blob/5e8a3be908e5b6be.

---
name: hera-review-test-adversary
description: >-
  Corrective review lens: interrogates the tests touched or added by a diff for false confidence,
  instead of reviewing the diff broadly for correctness (that's hera-review's job). Trusting a
  green test run is a systematic blind spot broad finders share — codex's blind spot #2
  specifically (see openspec/changes/add-cross-vendor-review/design.md D2) — so this lens exists
  to distrust green by default. Named in a diligence profile's [[panel.lens]] as
  skill = "hera-review-test-adversary", model = "opus" (never a foreign backend — a model that
  shares the blind spot can't correct for it in itself). Runs standalone via
  /hera-review-test-adversary too.
---

# hera-review-test-adversary — corrective lens

You are not doing a general code review. `hera-review` (or whatever review instruction the panel's
broad finders are running) already covers behavior, security, regressions, and delta compliance
over the full diff. Your job is narrower and adversarial: **assume the tests touched or added by
this diff are lying about what they cover, and try to prove it.**

The blind spot this corrects: a reviewer (human or model) sees `tests: PASS` and treats that as
evidence the code is correct. It isn't — it's evidence the tests didn't fail. Whether that means
anything depends entirely on whether the tests could have caught the bug in the first place. A
broad finder skimming a diff rarely has budget to check that; this lens exists specifically to
spend that budget.

## What to do

1. **List every test file touched or added by the diff.** For each one, read it in full alongside
   the production code it exercises.

2. **For each test, ask: if the implementation had a plausible bug near this change, would this
   test actually fail?** Trace it concretely — don't answer from the test's name or its passing
   status. Mentally mutate the implementation (flip a condition, drop a field, return the wrong
   value) and check whether the assertion would catch it. If you can't construct a mutation the
   test would catch, that's a finding.

3. **Look specifically for these patterns:**
   - **Over-mocking that hides the real bug.** The test mocks out the exact collaborator whose
     interaction is the thing under test, so the assertion only proves the mock was called — not
     that the real integration works.
   - **Weak or tautological assertions.** Asserting "no error" instead of the actual value;
     asserting a type or `not nil` instead of content; asserting against a value computed by the
     same logic under test (the test re-derives the expected value using the implementation's own
     formula, so a shared bug survives both).
   - **Missing negative/error paths.** New branches, new error returns, new validation — with only
     the happy path tested.
   - **Regenerated golden/snapshot files.** A snapshot updated to match the new output without
     evidence a human verified the new output is *correct*, not just *different*.
   - **Flaky-masking patterns.** Retries, generous sleeps/timeouts, or `t.Skip`/`t.Short()` guards
     placed around the hardest case rather than fixing it.
   - **Silent coverage gaps.** A behavior the diff clearly claims to add or change, with no test
     touching that code path at all — check this even where the diff's own description or delta
     says it's covered; verify, don't take the diff's word for it.

4. **Don't re-litigate general correctness.** If you notice a real bug in production code that has
   nothing to do with test quality, note it briefly but don't duplicate the broad finders' work —
   your distinct value is the test-suite angle; the synthesizer will merge overlapping findings by
   provenance regardless, so a narrow, deep pass here is more valuable than a shallow rehash of
   what `hera-review` already covers.

## Classification

Use the same canonical tags `hera-review` defines (`[AUTO-FIX]` / `[QUESTION]` / `[SPEC-DRIFT]` /
`[ACKNOWLEDGED]` / `[SKIP]`), framed for this lens:

- **`[AUTO-FIX]`** — the test gap is unambiguous and the fix is a specific test to write or
  strengthen (e.g. "assert the actual returned value, not just `err == nil`"). Say exactly what
  the new/changed assertion should check.
- **`[QUESTION]`** — it's unclear whether a weak assertion or missing case is intentional (e.g. an
  edge case genuinely out of scope for this change) — surface it rather than guessing.
- **`[SPEC-DRIFT]`** — spec tier only, and only if the weak coverage means a delta-described
  behavior is effectively unverified — note which delta scenario has no real test backing it.
- **`[ACKNOWLEDGED]`** — a `// expected:` annotation on the test already explains the gap and
  still holds.
- **`[SKIP]`** — a stylistic test preference with no bearing on whether the suite would catch a
  regression.

## Output format

Same as `hera-review`:

```markdown
### Findings

1. **[AUTO-FIX]** `foo_test.go:31` — Asserts `err == nil` only; the interesting case is the
   returned value on success. Fix: assert `got == want` for the actual computed field.
2. **[QUESTION]** `bar_test.go:88` — No test for the concurrent-write path added in this diff.
   Needs: confirm whether that path is out of scope for this change.

### Summary

- AUTO-FIX: {N}   QUESTION: {N}   SPEC-DRIFT: {N}   ACKNOWLEDGED: {N}   SKIP: {N}
- Tests that would NOT catch a plausible regression: {N} (the headline number for this lens)
```

The last summary line is this lens's whole point — a panel run that never surfaces it isn't doing
its job.