From 5a5243d472d276a75b559b0a3675891adaad66bc Mon Sep 17 00:00:00 2001 From: Amir Yogev Date: Sun, 3 May 2026 17:32:08 +0300 Subject: [PATCH 1/2] Clarify regression detection guidelines and enhance explanation of regression hints --- triage/skills/analyze.md | 8 ++++++-- triage/skills/assess.md | 2 +- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/triage/skills/analyze.md b/triage/skills/analyze.md index 4c87aca..221509b 100644 --- a/triage/skills/analyze.md +++ b/triage/skills/analyze.md @@ -194,8 +194,12 @@ 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`). +**Chronological constraint:** the resolved bug must have been **created before** the open bug. An older unresolved bug cannot be a regression of a newer resolved bug. + 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 @@ -203,14 +207,14 @@ When a resolved issue likely fixed the **same area** and the open bug reads like "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; original fix in release 3.1 did not hold — reappeared after release 3.2, suggesting the root cause was not fully addressed or was reintroduced" } ``` - `key` — resolved issue key (required) - `summary` — short summary of the resolved bug (required) - `resolved` — resolution date ISO string if known, else null -- `reason` — one sentence tying this open bug to that fix (required) +- `reason` — explain what broke again and why the previous fix may not have held (required). Focus on the insight: what area keeps failing, whether the root cause was likely incomplete, or whether a later change reintroduced the problem Set `regressionOf` to **null** when no plausible resolved match exists. This feeds the report **Regression** column and **Possible Regressions** section. diff --git a/triage/skills/assess.md b/triage/skills/assess.md index 5352e52..b84f601 100644 --- a/triage/skills/assess.md +++ b/triage/skills/assess.md @@ -21,7 +21,7 @@ You perform **full triage on one bug** — the same analytical dimensions as bul - **Priority mismatch** — compare Jira priority to severity implied by summary/description (same logic as bulk `priorityMismatch`) - **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) +- **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:** only flag a regression when the resolved bug was created *before* the open bug — an older bug cannot be a regression of a newer fix - **ESCALATE / WONT_FIX** — when the text clearly warrants it (cross-team, security, out of scope) **Skip only what inherently needs multiple open bugs:** From cf3c543110133d45300ceec3d34e053b941223be Mon Sep 17 00:00:00 2001 From: Amir Yogev Date: Mon, 4 May 2026 21:03:35 +0300 Subject: [PATCH 2/2] Refine regression detection criteria and clarify chronological constraints (address review comments) --- triage/skills/analyze.md | 6 +++--- triage/skills/assess.md | 4 +++- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/triage/skills/analyze.md b/triage/skills/analyze.md index 221509b..bb7ea1d 100644 --- a/triage/skills/analyze.md +++ b/triage/skills/analyze.md @@ -198,7 +198,7 @@ A regression signals that functionality was broken, fixed, and is now broken aga 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`). -**Chronological constraint:** the resolved bug must have been **created before** the open bug. An older unresolved bug cannot be a regression of a newer resolved bug. +**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: @@ -207,14 +207,14 @@ When a resolved issue likely fixed the **same area** and the open bug reads like "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; original fix in release 3.1 did not hold — reappeared after release 3.2, suggesting the root cause was not fully addressed or was reintroduced" + "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 -- `reason` — explain what broke again and why the previous fix may not have held (required). Focus on the insight: what area keeps failing, whether the root cause was likely incomplete, or whether a later change reintroduced the problem +- `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. diff --git a/triage/skills/assess.md b/triage/skills/assess.md index b84f601..7b65d0b 100644 --- a/triage/skills/assess.md +++ b/triage/skills/assess.md @@ -21,7 +21,9 @@ You perform **full triage on one bug** — the same analytical dimensions as bul - **Priority mismatch** — compare Jira priority to severity implied by summary/description (same logic as bulk `priorityMismatch`) - **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:** only flag a regression when the resolved bug was created *before* the open bug — an older bug cannot be a regression of a newer fix +- **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:**