#1273 extension push: issue-verdict review is indistinguishable from missing/stale

Summary

swamp extension push re-emits the adversarial-review-report reviewRuleWarnings entry — carrying a .file path — for a review that is present and content-hash-matching but whose only "problem" is that a dimension honestly recorded "verdict": "issue". The warning is emitted with the same ruleId and the same .file field used for the genuinely actionable "review missing / stale" case, so a downstream gate cannot tell the two states apart.

Concretely: a completed review with an issue verdict is reported identically to no review at all, and its remediation .file points at a file that already exists and is already correct — following the documented "write the report to .file" remediation can never clear it.

Environment

• swamp 20260718.233837.0-sha.f5bb6b99 (macOS)
• SWAMP_EXTENSION_REVIEW_DIR set to a committed .swamp-reviews/ dir
• Extension: @jentz/aws-stackset-audit v2026.07.04.1

Repro

1. Have a committed, hash-matching adversarial review for an extension, all dimensions pass/na. Set SWAMP_EXTENSION_REVIEW_DIR to its directory.
2. Baseline: swamp extension push <manifest> --dry-run --json --yes → no adversarial-review-report warning; reviewRuleWarnings absent. (Gate clean.)
3. In that same committed review JSON, flip exactly one dimension from "verdict": "pass" to "verdict": "issue" (the file name / content hash is unchanged — the hash is over extension source + manifest, not the review body). swamp accepts the edited body without any tamper/integrity complaint.
4. Re-run the same dry-run push. Now the output carries:

{
  "ruleId": "adversarial-review-report",
  "dimension": "Adversarial review",
  "severity": "medium",
  "file": ".../_jentz_aws-stackset-audit-590d4...json",
  "message": "Dimension <id> flagged ISSUE: <the dimension's note>."
}

The .file points at the already-committed, already-correct review.

Expected

A present, hash-matching, completed review should be distinguishable from a missing/stale one. Options that would fix the ambiguity:

• Use a distinct ruleId (or a status field) for "review complete, a dimension recorded an issue" vs "review missing/stale", and/or
• Omit .file in the issue-verdict case (there is no file action that clears it), and/or
• Document explicitly whether an issue verdict is meant to be gate-blocking.

Why it matters

Because the two states are indistinguishable in the warning payload, any CI gate built on reviewRuleWarnings[].ruleId == "adversarial-review-report" (the pattern in swamp's own CI-artifact docs) treats an honest issue verdict as a failure. That structurally pressures reviewers to launder real issue findings into pass-with-a-disclosure-note — we observed exactly this: every committed review in our repo uses only pass/na, never issue, to keep the gate green. The feature that records honest issues ends up unused.

Note

Possibly working-as-intended (an issue verdict should draw attention). If so, the ask reduces to: give consumers a way to distinguish "review owed" from "review done, issue noted" — e.g. a separate ruleId or an explicit verdict/status field on the warning — so a gate can pass a completed review regardless of verdict while still surfacing the note.