Skip to content

Clarify regression detection guidelines and enhance explanation of regression hints #37

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
amir-yogev-gh merged 2 commits into from
May 6, 2026
Merged

Clarify regression detection guidelines and enhance explanation of regression hints #37

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
5a5243d
Clarify regression detection guidelines and enhance explanation of re…
amir-yogev-gh May 3, 2026
cf3c543
Refine regression detection criteria and clarify chronological constr…
amir-yogev-gh May 4, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 6 additions & 2 deletions triage/skills/analyze.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -194,23 +194,27 @@ Set `duplicateOf` to **null** and `duplicateConfidence` to **null** when there i

### Step 6: Detect Possible Regressions (Using `resolved.json`)

A regression signals that functionality was broken, fixed, and is now broken again. The value of regression detection is the **insight** it provides: it tells the team that a previous fix did not hold, points to the area that keeps breaking, and highlights a pattern of instability worth investigating.

Populate `regressionOf` from the schema above. Compare each unresolved issue’s **error signature** and **symptoms** to **recently resolved** bugs in `resolved.json` (same project, from `/scan`).
Comment thread
amir-yogev-gh marked this conversation as resolved.

**Chronological constraint:** the resolved bug's **resolution date** must be before the open bug's **creation date**. If the fix landed after the new bug was filed, it cannot be a regression.

When a resolved issue likely fixed the **same area** and the open bug reads like a **reappearance** (same stack line, same API error, same workflow break), set `regressionOf` on the open issue:

```json
{
"key": "EDM-900",
"summary": "Fixed null dereference in checkout totals",
"resolved": "2026-02-01T10:00:00.000+0000",
"reason": "Same NPE in OrderTotals.java as EDM-900; reopened after release 3.2"
"reason": "Same NPE in OrderTotals.java as EDM-900; fix in 3.1 did not hold — reappeared in 3.2, likely incomplete root cause"
}
```

- `key` — resolved issue key (required)
- `summary` — short summary of the resolved bug (required)
- `resolved` — resolution date ISO string if known, else null
Comment thread
amir-yogev-gh marked this conversation as resolved.
- `reason` — one sentence tying this open bug to that fix (required)
- `reason` — one sentence: what broke again and why the previous fix may not have held (required)

Set `regressionOf` to **null** when no plausible resolved match exists. This feeds the report **Regression** column and **Possible Regressions** section.

Expand Down
2 changes: 2 additions & 0 deletions triage/skills/assess.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,8 @@ You perform **full triage on one bug** — the same analytical dimensions as bul
- **Staleness / activity** — created/updated dates; whether CLOSE-style staleness applies (vague + inactive), without needing other issues for comparison
- **Duplicates** — multi-angle `jira_search` + **duplicateConfidence** (0–100) for candidates; if mode A, exclude self-key when comparing
- **Regression hint** — search resolved bugs (e.g. last 90 days) for same signature/symptoms; describe possible **regressionOf**-style relationship in prose (no `resolved.json` required if you query Jira)
- A regression signals functionality that was broken, fixed, and is now broken again — focus on the insight: what area keeps failing and whether the prior fix was incomplete or reintroduced
- **Chronological constraint:** the resolved bug's *resolution date* must be before the open bug's *creation date* — if the fix landed after the new bug was filed, it cannot be a regression
- **ESCALATE / WONT_FIX** — when the text clearly warrants it (cross-team, security, out of scope)

**Skip only what inherently needs multiple open bugs:**
Expand Down
Loading