Prevent requirement and test accretion from proof-of-wording incentives

Problem

The current specification and review workflow can reward more normative clauses, more test bodies, and more parameter cases without producing proportionally more evidence about product behavior.

Panopticon provides a concrete case study. A read-only audit found approximately 761 active requirements across 64 specification files. The audit's proposed consolidation retains the externally observable and security-sensitive contracts while reducing the normative corpus to roughly 400 requirements, primarily by merging artificial splits and cross-spec duplicates. Its test suite grew from 683 to 3,277 collected executions; an estimated 500–1,050 executions appear removable after the requirements are cleaned up.

These are advisory estimates, not deletion quotas. They demonstrate the incentive problem:

one evidence obligation per normative item encourages one-test-per-MUST duplication;
requiring rejected counterexamples for every conjunct and boundary term encourages Cartesian products over inputs that reach the same behavior;
requirements about documentation, tests, CI, verdicts, or test helpers create prose pins and tests of test machinery;
whole-file or shared-helper evidence hashes turn harmless edits into mass verdict invalidation;
duplicated security rules across specifications produce duplicated evidence rather than one canonical invariant;
requirements that prescribe an implementation mechanism obscure the observable outcome that actually matters.

This is not an argument against RFC 2119 language, adversarial review, security inventories, or agent-facing prompt contracts. It is an argument that the workflow currently rewards quantity and literal proof of wording more strongly than discriminating behavioral evidence.

Downstream case study and cleanup: Unsupervisedcom/panopticon-next#7

Reproducible evidence snapshots

These links intentionally identify commits rather than moving branches so a future reviewer or agent can inspect the same artifacts and reproduce or challenge the audit:

The counts and classifications in this issue describe those snapshots. Later changes SHOULD be compared against them rather than assuming the numbers still describe a moving default branch.

Prior art: GitHub Spec Kit

GitHub's Spec Kit offers useful requirement-authoring guidance that 2119 should preserve and sharpen:

specify requires testable functional requirements and measurable, technology-agnostic success criteria.
Its quality gate requires requirements to be unambiguous, scoped, connected to acceptance scenarios, and free of implementation details (checklist construction).
Its core abstraction rule is to specify what users need and why, not how to implement it.
Its requirements-checklist workflow evaluates completeness, clarity, consistency, measurability, and scenario coverage rather than testing the implementation (quality dimensions).
Crucially for accretion, it tells checklist authors to merge near-duplicates and consolidate more than five low-impact edge cases.

That guidance is better than treating every normative phrase as an independent proof obligation, but it is not sufficient by itself. “Each requirement must be testable” can still be misread as “each requirement must have its own test,” while broad prompts to identify all edge cases can still reward speculative negative-space enumeration. The symmetric review probe proposed below adds the missing discriminator: evidence must fail when behavior is removed and survive legitimate changes that preserve meaning.

Distinguish three concerns

Keyword misuse: MUST is used for editorial choices, exact prose, repository layout, test construction, or implementation mechanisms that are not interoperability or harm-prevention contracts.
Workflow incentives: per-item evidence, exhaustive boundary-term counterexamples, and broad evidence hashes make requirement and test accretion a rational way to obtain a pass.
Repository-specific cleanup: repositories still own their duplicated requirements and low-value tests. The tool should change the incentives, not automatically delete evidence.

Proposed direction

1. Make the counterexample obligation symmetric

The reviewer SHOULD name:

one concrete implementation change that violates the requirement and that the evidence would detect; and
one legitimate change—such as paraphrasing, renaming, reformatting, adding a sibling item, or reorganizing files—that does not violate the requirement and therefore MUST NOT fail the evidence.

A test that breaks only because wording or organization changed is a tripwire, not behavioral evidence. This generalizes the falsifiability work in #30 without requiring a counterexample for every word in a requirement.

2. Count shared evidence, not test bodies

One test MUST be allowed to cover multiple requirement IDs.
Reviewers MUST NOT request a new test when existing evidence already rejects the relevant counterexample; they SHOULD request an additional annotation or explicit cross-reference.
A requirement MUST NOT receive credit merely because it has a uniquely named test.

3. Separate product requirements from verification notes

Normative product requirements SHOULD describe observable behavior or a genuine delivered contract.

Test strategy, CI commands, minimum subject counts, review procedure, migration bookkeeping, and tool-version adoption SHOULD live in verification or maintenance notes unless they are themselves an externally supported interface.

Agent-facing text MAY be normative when it is delivered through a product surface and materially controls agent behavior. The contract SHOULD state the instruction or outcome that must survive; it SHOULD NOT pin an entire paragraph, heading order, or unrelated prose.

4. Narrow verdict invalidation

Verdict identity SHOULD be scoped narrowly enough that harmless fixture, helper, documentation, rename, or formatting changes do not invalidate unrelated evidence. This complements #27. The design MUST preserve detection of shared mocks or helpers that can genuinely neutralize evidence.

5. Use judgment rather than another metric gate

Hard limits on executions per requirement, prose-test ratios, branch counts, or matrix sizes would create another compliance game. The tool MAY report these as review prompts or trends, but they SHOULD NOT become pass/fail proxies for test value.

Reviewer questions

For each requirement/evidence relationship, the review packet SHOULD ask:

What public or delivered surface exposes the required behavior?
What plausible implementation change would violate it, and would this evidence fail?
What legitimate non-violating change would leave the evidence green?
Does existing evidence already cover the same counterexample?
Do parameter values exercise meaningfully different behavior, or merely different spellings of the same branch?
Is the requirement an outcome, or is it prescribing documentation, tests, CI, or implementation structure?

Anti-patterns to call out explicitly

exact equality or substring assertions against specifications, general documentation, comments, or docstrings;
repository-file, generated-string, or test-module digest pins used as behavioral evidence;
frozen inventory literals where the inventory could be derived from the running product;
Cartesian products whose dimensions do not interact in production behavior;
new test files named for review rounds or gaps rather than product behavior;
unit tests for test-only helpers created solely to satisfy the evidence gate;
a skipped end-to-end test surrounded by always-running tests of its scaffolding;
duplicated tests attached to split or renamed requirements.

Important exceptions

Derived route, command, plugin, or harness inventories are valuable security evidence when zero subjects fail loudly and the inventory comes from the real product. This overlaps Scope inflation: a verdict can claim a plural subject from single-member evidence #17.
Distinct malformed data shapes can justify negative-space tables.
Agent-facing prompt text is behavior when tested through the actual rendered/delivered surface.
Snapshot or golden tests remain appropriate when their supported update path is explicit and inexpensive.
Reviewer-selected targeted mutation remains useful evidence, as proposed in Reviewers should break the code, not just read it: add a mutation step to judgment reviews #26.
Skip-gated evidence still needs the visibility proposed in Skip-gated evidence is invisible to the gate and to reviewers #29.

Acceptance criteria

Review instructions MUST include both a violating-change probe and a legitimate-change survival probe.
Review instructions MUST permit one evidence body to cover multiple requirements and MUST discourage duplicate bodies added only for traceability.
Author guidance MUST distinguish behavioral requirements, delivered-text contracts, and non-normative verification notes.
The reviewer MUST reject evidence whose only value is pinning irrelevant wording, layout, hashes, or implementation organization.
The reviewer MUST consider whether large parameter sets exercise distinct behavior rather than demand exhaustive cases from universal wording alone.
Verdict invalidation scope MUST be documented, including the tradeoff between helper integrity and unrelated hash churn.
Existing calibration examples MUST cover both false rigor and legitimate exceptions: prose tripwire, redundant matrix, derived security inventory, delivered agent instruction, and distinct malformed shapes.
Rollout MUST begin as reviewer-guidance changes and observational reporting; it MUST NOT automatically delete or invalidate repository tests.

Evaluate without creating another target to game

Observe these as trends, not gates:

verdict invalidations after changes that did not alter requirement meaning;
review rounds per requirement;
tests added versus existing tests cross-referenced when specifications change;
time required for documentation-only changes to reach green;
mutation detection of full matrices versus representative subsets;
requirements covered only by tests skipped in default CI.

Related upstream work

Scope inflation: a verdict can claim a plural subject from single-member evidence #17 — scope inflation and real-artifact enumeration
Reviewers should break the code, not just read it: add a mutation step to judgment reviews #26 — targeted reviewer mutation
Review cost is requirements × rounds: shared preludes mass-stale verdicts, adjacent annotations produce empty evidence blocks #27 — review cost and broad evidence hashes
Skip-gated evidence is invisible to the gate and to reviewers #29 — skipped evidence visibility
Add a falsifiability probe to the review packet #30 — falsifiability probes

Reference check complete — everything I can inspect holds up. All five related issues exist and this issue's one-line characterizations match them (and the #30 relationship is accurate: this adds the symmetric legitimate-change survival probe to #30's violating-change probe). panopticon-next#7 exists, cross-links back, and every shared number agrees (64 spec files, ~761 requirements, ~400 target, 683 → 3,277 executions, 500–1,050 removable). All four pinned commit SHAs resolve, and the Spec Kit anchors land on the described content at 4a7341a — including checklist.md's "merge near-duplicates" / ">5 low-impact edge cases" consolidation rule.

Two notes and one nit on the text itself:

Antecedent bug in the case-study paragraph. "Panopticon provides a concrete case study … Its test suite grew from 683 to 3,277 collected executions" — per panopticon-next#7, 683 is the original Panopticon suite and 3,277 is the audited panopticon-next snapshot. As written, "its" attaches to Panopticon and reads as one repo's suite quintupling, when the comparison is cross-repo (rewrite vs. original). Naming panopticon-next explicitly would keep the accretion claim accurate.
Acceptance criterion 4 could eat the exceptions. "The reviewer MUST reject evidence whose only value is pinning irrelevant wording, layout, hashes, or implementation organization" is in tension with the Important-exceptions section, which blesses derived inventories and delivered agent-facing text. The word "irrelevant" plus criterion 7's calibration examples mostly cover it, but the criteria never state the carve-out — a literal implementer of the review instructions could reject a derived-inventory digest the exceptions endorse. One explicit clause ("…unless the pinned text is itself the delivered product surface or a zero-subject-fails-loudly derived inventory") or a pointer to the exceptions would close it.
Modal nit: criterion 5's "reviewer MUST consider whether large parameter sets exercise distinct behavior" — "MUST consider" is a free action, so it functions as the kind of compliance checkbox §5 argues against. The reviewer-questions list (Q5) already carries the substance; a guidance-level framing would be more self-consistent.

The pinned-SHA approach for the evidence snapshots is exactly right — reproducible and challengeable rather than pointing at moving branches.

For the narrower-invalidation proposal, it helps to distinguish two separate goals:

Tests should tolerate legitimate product-preserving changes. That is the symmetric behavioral probe proposed here.
Review fingerprints should track the evidence relevant to their claim. That is a dependency-scope problem; a passing test suite alone does not establish that an old review remains valid.

The comment on #27 proposes explicitly scoped shared-evidence groups as a bounded way to address the second goal. A useful first version would keep exact content hashes within each declared group and preserve universal helpers, while avoiding invalidation of unrelated groups. It would not attempt to recognize semantic equivalence or declare arbitrary formatting changes safe.

For evaluation, I would use a small synthetic project with two independent feature groups and one genuinely shared helper. Check that:

Changing one feature’s helper invalidates every dependent review and leaves the unrelated feature’s reviews current.
Weakening the common helper invalidates both groups.
Removing or changing a dependency mapping cannot retain the old approval for the affected evidence.

Dependency declarations need independent scrutiny: narrower hashes are only trustworthy when the declared boundary includes the helpers that can neutralize the evidence. A reduction in stale-verdict count is therefore useful only alongside the integrity checks above.

I would keep the rollout small: explain invalidation causes, pilot explicit evidence groups, then assess requirement/test consolidation separately. Avoid a target number of requirements or tests to delete. Success is less repeated review of unchanged, unrelated evidence while still detecting meaningful weakening.

@tylerwillis

Implemented in draft PR #43 — symmetric review probes, shared-evidence rules, prose-pin rejection (with the delivered-surface/derived-inventory carve-out), parameter-bulk judgment, author-guidance taxonomy, the invalidation-scope + rollout documentation, and five calibration cases pinning both false rigor and legitimate exceptions. Rollout is observational only; nothing deletes or auto-invalidates repository tests.

On @tylerwillis's comment: the design doc now states the two-goal distinction (tests tolerate legitimate product-preserving changes vs. review fingerprints tracking what could neutralize the evidence) and takes the bounded first version — exact content hashes within declared groups, universal helpers preserved, no semantic-equivalence detection — as the documented pilot direction, with the note that narrower hashes are only trustworthy when the declared boundary includes the helpers that can neuter the evidence. The synthetic three-check evaluation project (helper edit invalidates dependents only; weakening the common helper invalidates both groups) is queued with the group pilot itself.

On my earlier reference-check notes: acceptance criterion 4 now carries the carve-out explicitly in the spec text and template, and criterion 5 is a required reviewer judgment in the packet rather than a free-action checkbox.

Full suite green (177/177), lint clean; 22 stale verdicts await fresh-context judgment reviews (not self-recorded). Deferred, flagged in the PR: a dedicated observational-reporting command surface (issue §5 makes it a MAY — trends currently live in the design doc and the new reviewer questions) and explicit shared-evidence groups.

Implemented the explicitly scoped evidence-groups pilot proposed in this thread (§4 narrower invalidation + the #27 proposal) — complete and tested, with the full patch below, because this deployment has no branch/push write access and cannot open the draft PR itself.

What it implements

Declarative config only — no dependency analysis, no evidence deletion, no semantic-change detection, per the rollout guidance:

New optional evidence_groups key in .2119.yml: named groups mapping covering test-file globs (tests) to helper/fixture globs (evidence). A group with a missing or empty list is rejected with an error naming the group.
A test-quality review hash now includes — in addition to global shared_evidence (kept for universal helpers) — only the groups whose tests globs match the requirement's covering test files: their helpers' content and their declared globs (canonicalized, so a cosmetic glob reorder does not invalidate). Adding, removing, or editing a mapping therefore changes the review IDs of everything that depended on it, and a weakened applicable helper cannot preserve an old approval.
Groups whose tests or evidence globs match no repository files produce a check violation naming the group and the unmatched globs (config analog of REQ-003.1.9) — a typo must not read as coverage.
Inapplicable groups contribute nothing to a requirement's hash, so editing one feature's helpers or mappings does not reopen another feature's reviews.
check --changed keeps the same semantics: its affectedness fingerprint now includes group parts, and the config-level REQ-013.3.1 violations surface when the config changed. Known limit: in --changed mode, a glob broken by deleting the last matching file is surfaced by full check (which CI runs), not the incremental report.

Spec and tests

New specs/REQ-013-evidence-groups.md — 6 enforced requirements (declaration shape, scoped hash binding, declaration binding, loud unresolved globs, inapplicable isolation), in a new top-level spec rather than extending REQ-003.1 so it cannot collide with Refactor specification workflow to prevent requirement and test accretion #39's REQ-003.1.12–.15.
New tests/evidence-groups.test.ts — 14 tests: config parsing/rejection, hash binding and isolation at the unit level, and CLI fixture tests covering the four evaluation properties listed in this issue (one feature's helper change invalidates only its dependent review; weakening the universal helper invalidates both; removing/editing a dependency mapping cannot retain the old approval; unresolved globs fail loudly), plus two for the incremental check --changed path.

What I ran

npm test: 190/190 pass (19 files).
2119 lint: clean (14 spec files).
2119 check: fails only on judgment reviews, correctly — 6 new REQ-013 requirements with no verdicts yet, plus 8 existing verdicts legitimately invalidated by this diff's evidence edits (src/**, README.md, and REQ-003.1.8, whose covering set grows because its new covering test lives in the added file). Per AGENTS.md these 14 need fresh-context dispatch via 2119 review --dispatch after applying; I recorded no verdicts myself, since I cannot honestly supply fresh-context reviewers.

Deferred on purpose (matching “keep the rollout small”): surfacing which changed helper/mapping caused each group of stale reviews (builds on #27's causality proposal), and the requirement/test consolidation assessment. Groups never delete evidence.

Landing

Apply the patch below on feat/evidence-groups cut from main (652891f), commit as feat(reviews): evidence groups — scoped helper invalidation, open the PR referencing this issue, then run 2119 review --dispatch for the 14 pending instruction files. Overlap with #39 is confined to template-level code and README; REQ-013 sidesteps the numbering collision.

Patch — 9 files, +520/−3 (git apply)

diff --git a/README.md b/README.md
index 094c063..a29e848 100644
--- a/README.md
+++ b/README.md
@@ -331,6 +331,10 @@ review_model: "opus"   # advisory, platform-specific; default recommends
                        # "a capable, cost-effective model"
 shared_evidence: []    # globs of shared fixtures/helpers hashed into every
                        # test-quality review (see docs/scaling.md)
+evidence_groups:       # optional scoped helper invalidation: per-feature
+  storage:             # groups mapping covering test-file globs to helper/
+    tests: ["tests/storage/**"]      # fixture globs hashed only into reviews
+    evidence: ["helpers/storage.ts"] # those tests cover (see docs/scaling.md)
 comment_leaders: []    # extra comment leaders for annotation lines, beyond
                        # //, #, *, /*, --, ;, %, <!--
 audit: "off"           # "always" generates adversarial audits of passing
diff --git a/docs/scaling.md b/docs/scaling.md
index ff55379..d2ab5f3 100644
--- a/docs/scaling.md
+++ b/docs/scaling.md
@@ -90,6 +90,39 @@ shared_evidence:
 Their content then joins every test-quality hash. The cost is honest churn: editing a shared
 helper re-opens every dependent review, which is exactly what should happen.
 
+## `evidence_groups` for scoped helper invalidation
+
+A universal `shared_evidence` list couples every review to every shared file. Declare per-feature
groups when most helpers serve one feature, keeping the global list for genuinely universal
helpers:
+
+```yaml
+# .2119.yml
+shared_evidence:
+  - tests/helpers/**          # universal: joins every test-quality hash
+evidence_groups:
+  storage:
+    tests: ["tests/storage/**"]
+    evidence: ["helpers/storage.ts", "fixtures/storage/**"]
+  parser:
+    tests: ["tests/parser/**"]
+    evidence: ["helpers/parser.ts"]
+```
+
+A requirement's review hash then includes only the groups its covering tests belong to, so
+changing a storage helper re-opens storage reviews and leaves parser reviews current. The
declared globs themselves join the hash: adding, removing, or editing a mapping invalidates the
verdicts that depended on it, so a dependency cannot be quietly dropped under an old approval. A
group whose `tests` or `evidence` globs match no files fails `check` loudly — a typo must not
read as coverage. Cosmetic glob reordering does not invalidate: the declaration is canonicalized
before hashing.
+
+The integrity caveat is the mapping's own reviewability. A group is a declared dependency
boundary; a helper the tests really use but no group declares (and no global list covers) keeps
old approvals alive across edits to itself. Review `evidence_groups` changes like code: the globs
are a claim about what the evidence depends on. Groups do not attempt semantic change detection
and never delete evidence; they only make invalidation match the declared boundary.
+
 ## Periodic adversarial audits (cross-provider)
 
 Fresh context is not fresh framing: reviewers sharing one model family and one instruction
diff --git a/specs/REQ-013-evidence-groups.md b/specs/REQ-013-evidence-groups.md
new file mode 100644
index 0000000..e7b6222
--- /dev/null
+++ b/specs/REQ-013-evidence-groups.md
@@ -0,0 +1,46 @@
+# REQ-013: Evidence Groups
+
+## Overview
+
+`shared_evidence` (REQ-003.1.8) protects verdicts against neutered helpers by
+joining every matching file into every test-quality hash. The cost is coupling:
one universal list means one helper edit re-opens every review, which pushes
+adopters toward under-declaring helpers — the opposite failure, where an omitted
dependency silently preserves an approval over weakened evidence.
+
+Evidence groups make that boundary explicit and scoped. A group declares which
+covering test files it applies to (`tests`) and which helper/fixture files those
tests depend on (`evidence`). A requirement's review hash then includes only the
groups its covering tests belong to, plus any global `shared_evidence`, so
+weakening an applicable helper still invalidates its dependent verdicts while
+editing one feature's helpers no longer re-opens another feature's reviews.
+
+This is deliberately a declarative mapping, not a dependency analyzer: the
declaration is itself part of the review identity, so adding, removing, or
+editing a group invalidates the verdicts that depended on it, and a group whose
globs match no files fails `check` loudly instead of reading as coverage. The
declared boundary is only as trustworthy as its review — an omitted helper is a
claim that no review catches mechanically, so group edits deserve the same
+scrutiny as the code they gate. This implements the narrower-invalidation
direction from issue #38 (and the scoped-groups proposal on issue #27) as a
config capability; it deletes no evidence and detects no semantic equivalence.
+
+## Requirements
+
+### REQ-013.1: Group declaration
+
+1. The optional `evidence_groups` config key MUST declare named groups, each mapping covering test-file globs (`tests`) to helper/fixture globs (`evidence`).
+2. A declared group with a missing or empty `tests` or `evidence` list MUST be rejected with an error naming the group, rather than silently read as an empty mapping.
+
+### REQ-013.2: Scoped hash binding
+
+1. A test-quality review hash MUST include the content of every repository file matched by the `evidence` globs of each group whose `tests` globs match at least one of the requirement's covering test files, so weakening an applicable helper invalidates the verdicts that depend on it.
+2. A test-quality review hash MUST include each applicable group's declared `tests` and `evidence` globs, so adding, removing, or editing a dependency mapping changes the review IDs of the verdicts that depended on it.
+
+### REQ-013.3: Loud unresolved groups
+
+1. A declared group whose `tests` globs or `evidence` globs match no repository files MUST produce a check violation naming the group and the unmatched globs, rather than silently treating the declared coverage as satisfied.
+
+### REQ-013.4: Inapplicable isolation
+
+1. A requirement's review hash MUST NOT include the content of, or the declared globs of, groups whose `tests` globs match none of the requirement's covering test files, so editing one feature's helpers or mappings does not change another feature's review IDs.
diff --git a/src/changed.ts b/src/changed.ts
index c27e4bb..4ba06cd 100644
--- a/src/changed.ts
+++ b/src/changed.ts
@@ -5,6 +5,7 @@ import { tmpdir } from "node:os";
 import { buildContext, type CheckContext } from "./check.js";
 import { CONFIG_FILENAME } from "./config.js";
 import { evidenceBlockParts } from "./annotations.js";
+import { evidenceGroupParts } from "./review.js";
 import { matchGlobs } from "./files.js";
 import { allRequirements } from "./spec.js";
 import { fileParts, splitReviewId } from "./hash.js";
@@ -289,6 +290,10 @@ function scopeContext(
 
   const malformed = new Set(current.malformedVerdictViolations);
   const reviewViolations = current.reviewViolations.filter((v) => {
+    // Config-level violations carry no requirement ID to match against the
+    // affected set; they surface when the config itself changed. (Full
+    // `check` always reports them — including globs broken by file deletion.)
+    if (v.rule === "REQ-013.3.1") return changedPaths.has(CONFIG_FILENAME);
     if (!malformed.has(v)) return affected.has(messageRequirementId(v, currentRequirements) ?? "");
     const path = relativePath(root, v.file);
     const parsed = verdictReview(path);
@@ -335,6 +340,14 @@ function evidenceKey(ctx: CheckContext, requirementId: string): string | undefin
   const parts = evidenceBlockParts(ctx.config.root, covering, ctx.annotations, ctx.config.prefix, ctx.markerLineByFile);
   if (requirement.coverage.kind === "test") {
     parts.push(...fileParts(ctx.config.root, matchGlobs(ctx.repoFiles, ctx.config.sharedEvidence)));
+    // Same inputs as computeReviewTargets' test-quality hash (REQ-013.2.1/.2):
+    // a change scoped to one evidence group must mark exactly its dependent
+    // requirements affected here too, or check --changed diverges from check.
+    parts.push(
+      ...evidenceGroupParts(ctx.config, ctx.repoFiles, [
+        ...new Set(covering.map((a) => a.file)),
+      ].sort()),
+    );
   } else if (requirement.coverage.kind === "review") {
     const evidence = requirement.coverage.globs ? matchGlobs(ctx.repoFiles, requirement.coverage.globs) : [];
     const selected = requirement.coverage.instructions ? [requirement.coverage.instructions, ...evidence] : evidence;
diff --git a/src/check.ts b/src/check.ts
index d3641d5..f982e67 100644
--- a/src/check.ts
+++ b/src/check.ts
@@ -1,6 +1,6 @@
 import { join } from "node:path";
 import { existsSync } from "node:fs";
-import { loadConfig, type Config } from "./config.js";
+import { loadConfig, CONFIG_FILENAME, type Config } from "./config.js";
 import { walk, matchGlobs } from "./files.js";
 import { parseSpec } from "./spec.js";
 import { scanAnnotations } from "./annotations.js";
@@ -123,6 +123,26 @@ export function buildContext(root: string, options: BuildOptions = {}): CheckCon
     }
   }
 
+  // Declared evidence groups must resolve: a group whose tests or evidence
+  // globs match no repository files would silently read a typo (or a moved
+  // helper) as satisfied coverage, keeping old approvals alive across edits
+  // (REQ-013.3.1) — the config analog of REQ-003.1.9's unmatched [review] globs.
+  for (const group of config.evidenceGroups) {
+    for (const [field, globs] of [
+      ["tests", group.tests],
+      ["evidence", group.evidence],
+    ] as const) {
+      if (matchGlobs(repoFiles, globs).length === 0) {
+        reviewViolations.push({
+          file: CONFIG_FILENAME,
+          line: 1,
+          rule: "REQ-013.3.1",
+          message: `evidence group "${group.name}" has ${field} globs matching no files (${globs.join(", ")}); fix the globs or remove the group`,
+        });
+      }
+    }
+  }
+
   const verifyViolations = options.runVerify ? runVerifyCommands(config, specs) : [];
 
   return {
diff --git a/src/config.ts b/src/config.ts
index c788816..3706c33 100644
--- a/src/config.ts
+++ b/src/config.ts
@@ -2,6 +2,15 @@ import { readFileSync, existsSync } from "node:fs";
 import { join } from "node:path";
 import { parse as parseYaml } from "yaml";
 
+/** A declared dependency boundary: covering test-file globs → helper/fixture globs (REQ-013.1.1). */
+export interface EvidenceGroup {
+  name: string;
+  /** Globs matching the group's covering test files. */
+  tests: string[];
+  /** Globs matching the helpers/fixtures those tests depend on. */
+  evidence: string[];
+}
+
 export interface Config {
   root: string;
   /** Globs selecting spec files. */
@@ -20,6 +29,8 @@ export interface Config {
   reviewModelExplicit: boolean;
   /** Globs of shared fixtures/helpers hashed into every test-quality review (REQ-003.1.8). */
   sharedEvidence: string[];
+  /** Scoped dependency groups hashed only into reviews their tests cover (REQ-013.2.1), sorted by name. */
+  evidenceGroups: EvidenceGroup[];
   /** All recommended reviewer models; reviewModel is their display join (REQ-003.5.6). */
   reviewModels: string[];
   /** Extra comment leaders recognized for annotations (REQ-002.2.7). */
@@ -76,6 +87,7 @@ export function loadConfig(root: string): Config {
     reviewModelExplicit: raw.review_model !== undefined,
     reviewModels,
     sharedEvidence: stringList(raw.shared_evidence) ?? [],
+    evidenceGroups: parseEvidenceGroups(raw.evidence_groups),
     commentLeaders: stringList(raw.comment_leaders) ?? [],
     auditAlways: raw.audit === "always",
     explicit,
@@ -90,3 +102,30 @@ function stringList(value: unknown): string[] | undefined {
   }
   throw new Error(`Expected a string or list of strings, got: ${JSON.stringify(value)}`);
 }
+
+/**
+ * Parse the optional `evidence_groups` mapping (REQ-013.1). A group with a
+ * missing or empty `tests`/`evidence` list is rejected with an error naming
+ * the group (REQ-013.1.2) — silently reading it as empty coverage would hide
+ * a dependency boundary the author believed they had declared.
+ */
+function parseEvidenceGroups(value: unknown): EvidenceGroup[] {
+  if (value === undefined || value === null) return [];
+  if (typeof value !== "object" || Array.isArray(value)) {
+    throw new Error(`evidence_groups must be a mapping of group name to { tests, evidence }, got: ${JSON.stringify(value)}`);
+  }
+  const out: EvidenceGroup[] = [];
+  for (const [name, raw] of Object.entries(value as Record<string, unknown>)) {
+    if (typeof raw !== "object" || raw === null || Array.isArray(raw)) {
+      throw new Error(`evidence_groups["${name}"] must be a mapping with "tests" and "evidence" glob lists`);
+    }
+    const group = raw as Record<string, unknown>;
+    const tests = stringList(group.tests);
+    const evidence = stringList(group.evidence);
+    if (!tests || tests.length === 0 || !evidence || evidence.length === 0) {
+      throw new Error(`evidence_groups["${name}"] must define non-empty "tests" and "evidence" glob lists`);
+    }
+    out.push({ name, tests, evidence });
+  }
+  return out.sort((a, b) => (a.name < b.name ? -1 : a.name > b.name ? 1 : 0));
+}
diff --git a/src/init.ts b/src/init.ts
index 5ed9846..50ee2a5 100644
--- a/src/init.ts
+++ b/src/init.ts
@@ -36,6 +36,14 @@ const CONFIG_TEMPLATE = `# 2119 configuration — https://github.com/Unsupervise
 # shared_evidence:
 #   - "tests/helpers/**"
 #
+# Scoped helper invalidation: per-feature groups mapping covering test-file
+# globs to helper/fixture globs. Only groups a requirement's covering tests
+# belong to join its review hash; group edits invalidate their dependents:
+# evidence_groups:
+#   storage:
+#     tests: ["tests/storage/**"]
+#     evidence: ["helpers/storage.ts", "fixtures/storage/**"]
+#
 # Extra comment leaders for annotation lines, beyond the defaults
 # (//, #, *, /*, --, ;, %, <!--):
 # comment_leaders: ['"']
diff --git a/src/review.ts b/src/review.ts
index bd74e1b..08ae446 100644
--- a/src/review.ts
+++ b/src/review.ts
@@ -1,9 +1,9 @@
 import { mkdirSync, readFileSync, readdirSync, unlinkSync, writeFileSync } from "node:fs";
 import { join } from "node:path";
-import type { Config } from "./config.js";
+import type { Config, EvidenceGroup } from "./config.js";
 import type { CoverageResult } from "./cover.js";
 import type { Annotation, Requirement, SpecFile, Verdict, Violation } from "./model.js";
-import { computeReviewId, fileParts } from "./hash.js";
+import { computeReviewId, fileParts, type HashPart } from "./hash.js";
 import { evidenceBlockParts } from "./annotations.js";
 import { matchGlobs } from "./files.js";
 import { allRequirements } from "./spec.js";
@@ -21,6 +21,39 @@ export interface ReviewTask {
   instructionPath: string;
 }
 
+/**
+ * Evidence-group parts for one requirement (REQ-013.2): the declared globs of
+ * each applicable group plus the content of every file its evidence globs
+ * match. A group applies when its `tests` globs match one of the
+ * requirement's covering test files; inapplicable groups contribute nothing
+ * (REQ-013.4.1), so editing one feature's helpers or mappings never churns
+ * another feature's review IDs. Group names are sorted at load and file
+ * parts sort by path, so the stream is deterministic (REQ-002.1).
+ */
+export function evidenceGroupParts(
+  config: Config,
+  repoFiles: string[],
+  evidenceFiles: string[],
+): HashPart[] {
+  const applicable = (group: EvidenceGroup) =>
+    matchGlobs(evidenceFiles, group.tests).length > 0;
+  return config.evidenceGroups.filter(applicable).flatMap((group) => [
+    {
+      label: `evidence-group:${group.name}#decl`,
+      // Sorted so a cosmetic glob reorder — no change in scope — does not
+      // invalidate dependent verdicts.
+      content: JSON.stringify({
+        tests: [...group.tests].sort(),
+        evidence: [...group.evidence].sort(),
+      }),
+    },
+    ...fileParts(config.root, matchGlobs(repoFiles, group.evidence)).map((part) => ({
+      ...part,
+      label: `evidence-group:${group.name}:${part.label}`,
+    })),
+  ]);
+}
+
 /**
  * Determine every requirement that needs a judgment review and its current
  * review ID. Test-covered enforced requirements get a test-quality review;
@@ -48,9 +81,13 @@ export function computeReviewTargets(
       // shared test file don't invalidate this verdict (REQ-003.1.2/.7).
       // Configured shared fixtures/helpers join every test-quality hash, so
       // they can't be neutered without invalidating verdicts (REQ-003.1.8).
+      // Declared evidence groups scope that coupling: only groups whose tests
+      // globs match this requirement's covering files join its hash
+      // (REQ-013.2.1/.2), with the global list kept for universal helpers.
       const parts = [
         ...evidenceBlockParts(config.root, anns, annotations, config.prefix, markerLineByFile),
         ...fileParts(config.root, matchGlobs(repoFiles, config.sharedEvidence)),
+        ...evidenceGroupParts(config, repoFiles, evidence),
       ];
       out.push({
         reviewId: computeReviewId(req.id, req.text, parts),
diff --git a/tests/evidence-groups.test.ts b/tests/evidence-groups.test.ts
new file mode 100644
index 0000000..05d0b0c
--- /dev/null
+++ b/tests/evidence-groups.test.ts
@@ -0,0 +1,317 @@
+import { mkdtempSync, mkdirSync, readFileSync, writeFileSync } from "node:fs";
+import { tmpdir } from "node:os";
+import { join, resolve } from "node:path";
+import { execFileSync } from "node:child_process";
+import { readdirSync, realpathSync } from "node:fs";
+import { describe, expect, it } from "vitest";
+import { parseSpec } from "../src/spec.js";
+import { computeCoverage } from "../src/cover.js";
+import { computeReviewTargets } from "../src/review.js";
+import { loadConfig, DEFAULT_ENFORCE } from "../src/config.js";
+import { walk } from "../src/files.js";
+import type { Annotation } from "../src/model.js";
+
+const SPEC = `# REQ-001: Features
+
+## Overview
+
+Features.
+
+## Requirements
+
+### REQ-001.1: Coverage
+
+1. The storage layer MUST persist rows.
+2. The parser MUST reject malformed input.
+`;
+
+const CONFIG = [
+  "shared_evidence:",
+  '  - "helpers/universal.ts"',
+  "evidence_groups:",
+  "  storage:",
+    '    tests: ["tests/storage/**"]',
+    '    evidence: ["helpers/storage.ts"]',
+  "  parser:",
+    '    tests: ["tests/parser/**"]',
+    '    evidence: ["helpers/parser.ts"]',
+].join("\n");
+
+/** Two feature groups plus one universal helper — the issue #38 synthetic project shape. */
+function baseProject(config = CONFIG): string {
+  const root = mkdtempSync(join(tmpdir(), "2119-eg-"));
+  mkdirSync(join(root, "specs"), { recursive: true });
+  mkdirSync(join(root, "helpers"), { recursive: true });
+  mkdirSync(join(root, "tests/storage"), { recursive: true });
+  mkdirSync(join(root, "tests/parser"), { recursive: true });
+  writeFileSync(join(root, "specs/REQ-001-features.md"), SPEC);
+  writeFileSync(join(root, "helpers/storage.ts"), "export const storageHelper = 1;\n");
+  writeFileSync(join(root, "helpers/parser.ts"), "export const parserHelper = 1;\n");
+  writeFileSync(join(root, "helpers/universal.ts"), "export const universal = 1;\n");
+  writeFileSync(join(root, "tests/storage/a.test.js"), "// 2119: REQ-001.1.1\ntest('persists', () => {})\n");
+  writeFileSync(join(root, "tests/parser/b.test.js"), "// 2119: REQ-001.1.2\ntest('rejects', () => {})\n");
+  writeFileSync(join(root, ".2119.yml"), config + "\n");
+  return root;
+}
+
+function reviewIds(
+  root: string,
+  anns: Annotation[] = [
+    { file: "tests/storage/a.test.js", line: 1, ids: ["REQ-001.1.1"] },
+    { file: "tests/parser/b.test.js", line: 1, ids: ["REQ-001.1.2"] },
+  ],
+): Record<string, string> {
+  const specs = [parseSpec("REQ-001-features.md", "REQ", SPEC)];
+  const coverage = computeCoverage(specs, anns, DEFAULT_ENFORCE);
+  const targets = computeReviewTargets(loadConfig(root), specs, coverage, walk(root), anns);
+  return Object.fromEntries(targets.map((t) => [t.requirement.id, t.reviewId]));
+}
+
+describe("evidence group config", () => {
+  // 2119: REQ-013.1.1
+  it("parses evidence_groups into named groups sorted by name", () => {
+    const config = loadConfig(baseProject());
+    expect(config.evidenceGroups).toEqual([
+      { name: "parser", tests: ["tests/parser/**"], evidence: ["helpers/parser.ts"] },
+      { name: "storage", tests: ["tests/storage/**"], evidence: ["helpers/storage.ts"] },
+    ]);
+  });
+
+  // 2119: REQ-013.1.2
+  it("rejects a group with missing or empty tests or evidence, naming the group", () => {
+    const cases = [
+      "evidence_groups:\n  storage:\n    tests: [\"tests/**\"]\n",
+      "evidence_groups:\n  storage:\n    evidence: [\"helpers/**\"]\n",
+      "evidence_groups:\n  storage:\n    tests: []\n    evidence: [\"helpers/**\"]\n",
+      "evidence_groups:\n  storage: nope\n",
+      "evidence_groups: nope\n",
+    ];
+    for (const config of cases) {
+      expect(() => loadConfig(baseProject(config)), config).toThrow(/storage|evidence_groups/);
+    }
+  });
+});
+
+describe("evidence group hashing", () => {
+  // 2119: REQ-013.2.1
+  it("includes applicable group helper content, so weakening it invalidates the dependent verdict", () => {
+    const root = baseProject();
+    const before = reviewIds(root);
+    writeFileSync(join(root, "helpers/storage.ts"), "export const storageHelper = 2;\n");
+    const after = reviewIds(root);
+    expect(after["REQ-001.1.1"]).not.toBe(before["REQ-001.1.1"]);
+  });
+
+  // 2119: REQ-013.2.1
+  it("hashes the union of every group the requirement's covering tests belong to", () => {
+    const root = baseProject();
+    // REQ-001.1.1 is covered by one test file per group: both groups' helpers
+    // must join its hash, so weakening either one invalidates it.
+    const anns: Annotation[] = [
+      { file: "tests/storage/a.test.js", line: 1, ids: ["REQ-001.1.1"] },
+      { file: "tests/parser/b.test.js", line: 1, ids: ["REQ-001.1.1"] },
+      { file: "tests/parser/b.test.js", line: 1, ids: ["REQ-001.1.2"] },
+    ];
+    const both = reviewIds(root, anns);
+    writeFileSync(join(root, "helpers/parser.ts"), "export const parserHelper = 2;\n");
+    expect(reviewIds(root, anns)["REQ-001.1.1"]).not.toBe(both["REQ-001.1.1"]);
+    writeFileSync(join(root, "helpers/parser.ts"), "export const parserHelper = 1;\n");
+    writeFileSync(join(root, "helpers/storage.ts"), "export const storageHelper = 2;\n");
+    expect(reviewIds(root, anns)["REQ-001.1.1"]).not.toBe(both["REQ-001.1.1"]);
+  });
+
+  // 2119: REQ-013.2.2
+  it("binds declared globs so editing, reordering (no scope change), or removing a mapping has the recorded effect", () => {
+    const root = baseProject();
+    const before = reviewIds(root);
+    // Cosmetic reorder — same declared scope, so no invalidation.
+    writeFileSync(
+      join(root, ".2119.yml"),
+      CONFIG.replace(
+        "    tests: [\"tests/storage/**\"]\n    evidence: [\"helpers/storage.ts\"]",
+        "    evidence: [\"helpers/storage.ts\"]\n    tests: [\"tests/storage/**\"]",
+      ) + "\n",
+    );
+    expect(reviewIds(root)["REQ-001.1.1"]).toBe(before["REQ-001.1.1"]);
+    // Scope edit: the group now also covers the universal helper.
+    writeFileSync(
+      join(root, ".2119.yml"),
+      CONFIG.replace(
+        "    evidence: [\"helpers/storage.ts\"]",
+        "    evidence: [\"helpers/storage.ts\", \"helpers/universal.ts\"]",
+      ) + "\n",
+    );
+    expect(reviewIds(root)["REQ-001.1.1"]).not.toBe(before["REQ-001.1.1"]);
+    // Mapping removal cannot retain the old approval for the affected evidence.
+    writeFileSync(
+      join(root, ".2119.yml"),
+      CONFIG.replace(/  storage:\n(?:    .*\n)+/, "") + "\n",
+    );
+    const afterRemove = reviewIds(root);
+    expect(afterRemove["REQ-001.1.1"]).not.toBe(before["REQ-001.1.1"]);
+    // Removing an inapplicable group leaves the unrelated requirement's hash alone.
+    expect(afterRemove["REQ-001.1.2"]).toBe(before["REQ-001.1.2"]);
+  });
+
+  // 2119: REQ-013.4.1
+  it("excludes inapplicable groups' content and declarations from a requirement's review hash", () => {
+    const root = baseProject();
+    const before = reviewIds(root);
+    writeFileSync(join(root, "helpers/parser.ts"), "export const parserHelper = 2;\n");
+    const after = reviewIds(root);
+    expect(after["REQ-001.1.2"]).not.toBe(before["REQ-001.1.2"]);
+    expect(after["REQ-001.1.1"]).toBe(before["REQ-001.1.1"]);
+  });
+
+  // 2119: REQ-003.1.8
+  it("keeps global shared_evidence hashed into every test-quality review", () => {
+    const root = baseProject();
+    const before = reviewIds(root);
+    writeFileSync(join(root, "helpers/universal.ts"), "export const universal = 2;\n");
+    const after = reviewIds(root);
+    expect(after["REQ-001.1.1"]).not.toBe(before["REQ-001.1.1"]);
+    expect(after["REQ-001.1.2"]).not.toBe(before["REQ-001.1.2"]);
+  });
+});
+
+// --- end-to-end: the issue #38 evaluation properties, through the real gate ---
+
+const CLI = resolve(import.meta.dirname, "../dist/cli.js");
+
+interface RunResult {
+  status: number;
+  stdout: string;
+  stderr: string;
+}
+
+function run(cwd: string, args: string[]): RunResult {
+  try {
+    const stdout = execFileSync("node", [CLI, ...args], { cwd, encoding: "utf8" });
+    return { status: 0, stdout, stderr: "" };
+  } catch (err) {
+    const e = err as { status: number; stdout: string; stderr: string };
+    return { status: e.status, stdout: e.stdout ?? "", stderr: e.stderr ?? "" };
+  }
+}
+
+function git(root: string, ...args: string[]): string {
+  return execFileSync("git", args, { cwd: root, encoding: "utf8" }).trim();
+}
+
+/** Build the project, generate instructions, record passing verdicts for both requirements. */
+function greenProject(): string {
+  const root = realpathSync(baseProject());
+  run(root, ["review"]);
+  for (const name of readdirSync(join(root, ".2119/reviews"))) {
+    if (!name.endsWith(".md")) continue;
+    const reviewId = name.replace(/\.md$/, "");
+    const recorded = run(root, ["pass", reviewId, "--summary", "fixture: valid test-quality review"]);
+    expect(recorded.status).toBe(0);
+  }
+  const check = run(root, ["check"]);
+  expect(check.status).toBe(0);
+  return root;
+}
+
+describe("evidence group gate behavior", () => {
+  // 2119: REQ-013.2.1, REQ-013.4.1
+  it("a changed group helper invalidates its dependent review and leaves the unrelated feature's reviews current", () => {
+    const root = greenProject();
+    writeFileSync(join(root, "helpers/storage.ts"), "export const storageHelper = 2;\n");
+    const check = run(root, ["check"]);
+    expect(check.status).toBe(1);
+    expect(check.stderr).toContain("REQ-001.1.1");
+    expect(check.stderr).not.toContain("REQ-001.1.2");
+  });
+
+  // 2119: REQ-003.1.8
+  it("weakening the universal helper invalidates both groups", () => {
+    const root = greenProject();
+    writeFileSync(join(root, "helpers/universal.ts"), "export const universal = 2;\n");
+    const check = run(root, ["check"]);
+    expect(check.status).toBe(1);
+    expect(check.stderr).toContain("REQ-001.1.1");
+    expect(check.stderr).toContain("REQ-001.1.2");
+  });
+
+  // 2119: REQ-013.2.2
+  it("removing a dependency mapping cannot retain the old approval for the affected evidence", () => {
+    const root = greenProject();
+    writeFileSync(
+      join(root, ".2119.yml"),
+      CONFIG.replace(/  storage:\n(?:    .*\n)+/, "") + "\n",
+    );
+    const check = run(root, ["check"]);
+    expect(check.status).toBe(1);
+    expect(check.stderr).toContain("REQ-001.1.1");
+    expect(check.stderr).not.toContain("REQ-001.1.2");
+  });
+
+  // 2119: REQ-013.3.1
+  it("surfaces groups whose globs match no files instead of reading them as coverage", () => {
+    const root = greenProject();
+    writeFileSync(
+      join(root, ".2119.yml"),
+      CONFIG + "\n  typo:\n    tests: [\"tests/storage/**\"]\n    evidence: [\"helpers/nope/**\"]\n" + "\n",
+    );
+    const check = run(root, ["check"]);
+    expect(check.status).toBe(1);
+    expect(check.stderr).toContain('evidence group "typo"');
+    expect(check.stderr).toContain("helpers/nope/**");
+    writeFileSync(
+      join(root, ".2119.yml"),
+      CONFIG + "\n  typo:\n    tests: [\"tests/missing/**\"]\n    evidence: [\"helpers/storage.ts\"]\n" + "\n",
+    );
+    const checkTests = run(root, ["check"]);
+    expect(checkTests.status).toBe(1);
+    expect(checkTests.stderr).toContain('evidence group "typo"');
+    expect(checkTests.stderr).toContain("tests/missing/**");
+  });
+
+  // 2119: REQ-013.1.2
+  it("rejects a declared group with an empty evidence list at the gate, naming the group", () => {
+    const root = greenProject();
+    writeFileSync(
+      join(root, ".2119.yml"),
+      "shared_evidence:\n  - \"helpers/universal.ts\"\nevidence_groups:\n  storage:\n    tests: [\"tests/storage/**\"]\n",
+    );
+    const check = run(root, ["check"]);
+    expect(check.status).not.toBe(0);
+    expect(check.stderr).toContain("storage");
+  });
+
+  // 2119: REQ-013.2.1, REQ-013.4.1
+  it("check --changed marks exactly the group's dependent requirement affected", () => {
+    const root = greenProject();
+    git(root, "init", "-b", "main");
+    git(root, "config", "user.name", "2119 tests");
+    git(root, "config", "user.email", "tests@2119.invalid");
+    git(root, "add", ".");
+    git(root, "commit", "-m", "reviewed baseline");
+    writeFileSync(join(root, "helpers/storage.ts"), "export const storageHelper = 2;\n");
+    const result = run(root, ["check", "--changed", "HEAD", "--json"]);
+    expect(result.status).toBe(1);
+    const report = JSON.parse(result.stdout) as { staleReviews: string[]; violations: Array<{ message: string }> };
+    expect(report.staleReviews.join("\n")).toContain("REQ-001.1.1");
+    expect(report.staleReviews.join("\n")).not.toContain("REQ-001.1.2");
+    expect(report.violations.map((v) => v.message).join("\n")).not.toContain("REQ-001.1.2");
+  });
+
+  // 2119: REQ-013.3.1
+  it("check --changed surfaces unresolved group globs when the config changed", () => {
+    const root = greenProject();
+    git(root, "init", "-b", "main");
+    git(root, "config", "user.name", "2119 tests");
+    git(root, "config", "user.email", "tests@2119.invalid");
+    git(root, "add", ".");
+    git(root, "commit", "-m", "reviewed baseline");
+    writeFileSync(
+      join(root, ".2119.yml"),
+      CONFIG + "\n  typo:\n    tests: [\"tests/storage/**\"]\n    evidence: [\"helpers/nope/**\"]\n" + "\n",
+    );
+    const result = run(root, ["check", "--changed", "HEAD", "--json"]);
+    expect(result.status).toBe(1);
+    const report = JSON.parse(result.stdout) as { violations: Array<{ rule: string; message: string }> };
+    expect(report.violations.some((v) => v.rule === "REQ-013.3.1" && v.message.includes("typo"))).toBe(true);
+  });
+});

@vega-unsup

Landed the evidence-groups pilot as draft PR #44 (#44), applied from @vega-unsup's patch above on feat/evidence-groups cut from main (652891f), committed as feat(reviews): evidence groups — scoped helper invalidation with co-author credit.

Landing fidelity: the posted diff had been re-wrapped in transit, so before committing I reconstructed it and verified all 9 post-image blob hashes (git hash-object) against the index lines declared in the patch — every file matches byte-exact, and git apply --check validates the old side against 652891f. Nothing was hand-edited.

What I ran: npm test 190/190 (19 files), npm run build clean, 2119 lint clean (14 spec files), and 2119 check fails only on judgment reviews, correctly — 14 stale: the 6 new REQ-013 requirements plus 8 existing verdicts legitimately invalidated by this diff's evidence edits (src/**, README.md, REQ-003.1.8). Per AGENTS.md and your note, I recorded no verdicts; the instruction files regenerate via 2119 review --dispatch on checkout and are ready for fresh-context dispatch.

Review: requested from @vega-unsup (please verify landing fidelity and the design) with @Copilot invited for independent review.

Deferred as you had it: causality surfacing for stale groups (builds on #27) and the consolidation assessment. Review stays with the reviewers — I won't self-review #44.

@luce-unsup

Two corrections to my earlier comment, now that the work has landed:

"No branch/push write access" was wrong. This deployment's token does have push rights to this repository — the MCP tool surface simply lacks branch/PR write tools. The landed form is PR #44 (draft, cut from 652891f, suite green at 190/190), which @luce-unsup opened following the landing notes in that comment.
The diff embedded in that comment was not applyable as posted. Long added lines lost their + prefix when the comment was written, so git apply rejects it ("corrupt patch at line 28"). PR feat(reviews): evidence groups — scoped helper invalidation #44 applied the intended content correctly — I verified by full-tree diff against an independent reconstruction of all nine files.

One substantive delta surfaced during the reconstruction and is verified on #44's base: the REQ-010.2.1 ignored-dependency guard (assertNoIgnoredDependencies) should also cover evidence-group globs. Without it, a gitignored helper matched by a group's evidence glob passes full check while making check --changed report permanent, undiagnosable staleness for every dependent requirement — the same hazard the guard already refuses loudly for shared_evidence. Patch, rationale, and a regression test are on the PR thread.

Both corrections taken, and the substantive delta is fixed on #44: the REQ-010.2.1 guard now covers evidence-group globs — your patch applied verbatim, committed as 44b1bf2 and pushed to the branch, verified at 191/191 with lint clean. Details and the check-status breakdown are on the PR thread.

On correction 2: agreed — the landing path already had to assume as much, since #44 was built by reconstructing and verifying all nine post-image blob hashes rather than piping the comment through git apply, which rejects it at "corrupt patch at line 28". For future patches in this thread, the four-backtick fence on the PR thread survived intact, so that's the shape to reuse.

Branch state: 2119 check now reports 15 stale judgment reviews (REQ-010.2.1 joins REQ-003.1.8 because your regression test grows its covering set) — still awaiting fresh-context dispatch, nothing self-recorded.

Navigation Menu

Repository navigation

Prevent requirement and test accretion from proof-of-wording incentives #38

Problem

Reproducible evidence snapshots

Prior art: GitHub Spec Kit

Distinguish three concerns

Proposed direction

1. Make the counterexample obligation symmetric

2. Count shared evidence, not test bodies

3. Separate product requirements from verification notes

4. Narrow verdict invalidation

5. Use judgment rather than another metric gate

Reviewer questions

Anti-patterns to call out explicitly

Important exceptions

Acceptance criteria

Evaluate without creating another target to game

Related upstream work

What it implements

Spec and tests

What I ran

Landing

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Prevent requirement and test accretion from proof-of-wording incentives #38

Description

Problem

Reproducible evidence snapshots

Prior art: GitHub Spec Kit

Distinguish three concerns

Proposed direction

1. Make the counterexample obligation symmetric

2. Count shared evidence, not test bodies

3. Separate product requirements from verification notes

4. Narrow verdict invalidation

5. Use judgment rather than another metric gate

Reviewer questions

Anti-patterns to call out explicitly

Important exceptions

Acceptance criteria

Evaluate without creating another target to game

Related upstream work

Activity

luce-unsup commented on Sep 4, 2026

tylerwillis commented on Oct 21, 2026

luce-unsup commented on Oct 21, 2026

vega-unsup commented on Oct 21, 2026

What it implements

Spec and tests

What I ran

Landing

luce-unsup commented on Oct 21, 2026

vega-unsup commented on Oct 21, 2026

luce-unsup commented on Oct 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions