Probe must-fire cases of a changed cop against main in the pipeline gates #1454

Open
opened 2026-10-28 06:14:17 +00:00 by jared · 0 comments
Owner

Problem

The pipeline gates do not test the must-fire cases of a changed or new suppression rule in a cop. A cop change can pass every gate while it misses offenses that main reports.

Observed

Seen on 2026-10-27 and 2026-10-28:

  1. #1361: the pipeline change released a guard before the branch check. A use inside the dead branch hid the offense. Main fired, the branch did not. All gates passed.
  2. #1384: the first green increment passed every gate. The owned-type check depended on load state and missed def self. methods.
  3. #1380: must-fire acceptance criteria were already true before the change. test-writer and test-reviewer looped 4 times without escalation.

Reproduce

n/a: process defect; see the three tickets above.

Approach

Direction: a cop-change ticket lists its must-fire cases. A gate or the behavior-verifier runs the changed cop and main's cop on those cases and reports any case where main fires and the branch does not. A must-fire case that main already fires on is flagged as not red.

Required work:

  1. Add the must-fire probe — check: present must-fire in plugins/os-sdlc/lib

Acceptance criteria

  1. Given a cop change that stops reporting a listed must-fire case that main reports, when the gates run, then a gate fails and names the case.
  2. Given a must-fire criterion that main already satisfies, when test-reviewer runs, then the loop escalates instead of repeating.

Origin

  • Trigger: three cop-change runs on 2026-10-27 and 2026-10-28
  • Improvised this session: none
  • Chain: missed offense reaches main ← no gate probes must-fire cases against main ← DESIGN (pipeline gates test only the new tests)
  • Root candidate: none found; searched must-fire, against main, behavior-verifier, probe, cop
  • Where: plugins/os-sdlc gates, behavior-verifier
  • Session: 9f415790-a6bd-4850-8d70-3dd45004ce2b
  • Transcript: /home/jared/.claude/projects/-home-jared-dev-cc-os/9f415790-a6bd-4850-8d70-3dd45004ce2b.jsonl

VERDICT: CREATE

## Problem The pipeline gates do not test the must-fire cases of a changed or new suppression rule in a cop. A cop change can pass every gate while it misses offenses that main reports. ## Observed Seen on 2026-10-27 and 2026-10-28: 1. #1361: the pipeline change released a guard before the branch check. A use inside the dead branch hid the offense. Main fired, the branch did not. All gates passed. 2. #1384: the first green increment passed every gate. The owned-type check depended on load state and missed `def self.` methods. 3. #1380: must-fire acceptance criteria were already true before the change. test-writer and test-reviewer looped 4 times without escalation. ## Reproduce n/a: process defect; see the three tickets above. ## Approach Direction: a cop-change ticket lists its must-fire cases. A gate or the behavior-verifier runs the changed cop and main's cop on those cases and reports any case where main fires and the branch does not. A must-fire case that main already fires on is flagged as not red. Required work: 1. Add the must-fire probe — check: present `must-fire` in `plugins/os-sdlc/lib` ## Acceptance criteria 1. Given a cop change that stops reporting a listed must-fire case that main reports, when the gates run, then a gate fails and names the case. 2. Given a must-fire criterion that main already satisfies, when test-reviewer runs, then the loop escalates instead of repeating. ## Origin - Trigger: three cop-change runs on 2026-10-27 and 2026-10-28 - Improvised this session: none - Chain: missed offense reaches main ← no gate probes must-fire cases against main ← DESIGN (pipeline gates test only the new tests) - Root candidate: none found; searched must-fire, against main, behavior-verifier, probe, cop - Where: plugins/os-sdlc gates, behavior-verifier - Session: 9f415790-a6bd-4850-8d70-3dd45004ce2b - Transcript: /home/jared/.claude/projects/-home-jared-dev-cc-os/9f415790-a6bd-4850-8d70-3dd45004ce2b.jsonl VERDICT: CREATE
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
jared/cc-os#1454
No description provided.