[sharpca]

Summary

• Step 2's class table listed STALE-CANDIDATE as one of five triage classes
  while the same row called staleness "orthogonal", so the skill contradicted
  itself. Sonnet followed the table and returned triage_class: STALE-CANDIDATE for the stale fixture; Opus and Fable followed the
  "orthogonal" half and returned UNTRIAGED. The fixture expects UNTRIAGED,
  so Sonnet failed step-2-classify/case-4-stale-candidate on 10 of 10 runs.
• Staleness is a flag, not a class. The table now has four rows, and a
  paragraph under it states that an issue keeps its real class while
  is_stale_candidate carries staleness. Step 3's stale_candidate bucket
  reads the boolean instead of naming a class.
• The step-2 eval output spec drops STALE-CANDIDATE from the allowed
  triage_class values and says the rule explicitly, so the spec no longer
  re-introduces the contradiction the skill just dropped.

Type of change

• Skill change — prose only, no new fixture needed (see the test plan)
• Documentation (docs/, README.md, CONTRIBUTING.md)

Test plan

• markdownlint-cli2 on both changed files: 0 issues
• measured_tokens re-stamped with the repo's own counter
  (4984 → 5055, verified stamp == measured by re-running the tool's
  measure() against the stamped file)
• surface_hash unchanged, and checked rather than assumed: the
  fingerprint covers requires_config plus step/golden-rule headings, and
  git diff contains no heading line (grep -E '^[+-]#{1,6} ' is empty)
• No fixture changes, because none are needed:
  case-4-stale-candidate/expected.json already asserts
  UNTRIAGED + is_stale_candidate: true. This PR makes the skill agree
  with the fixture it was already graded against; it does not change what
  the correct answer is.
• Full eval suite not run locally — the runner needs a model CLI and
  credentials. The reproduction in the issue is the harness for this.

RFC-AI-0004 compliance

• Vendor neutrality — the new prose says "an untriaged issue last
  updated 216 days ago", taken from the fixture, and names no model as the
  expected behaviour. The issue's model comparison stays in the issue.

Linked issues

Closes #1678

Notes for reviewers

• The 216-day example in the new paragraph is the fixture's own numbers, so the
  prose and the graded case now describe the same issue.
• I left Step 3's pressure score (stale-candidate → 2 pts each (regardless of triage status)) untouched: it already reads staleness as orthogonal to the
  class, which is what this PR makes the rest of the skill say.
• golden-rule-details.md and fetch-queries.md carry no class wording, so the
  contradiction existed in exactly the two places changed here.

Generative AI disclosure

This change was authored with an AI coding agent (WorkBuddy AI, DeepSeek-V4.1-Flash)
under human review. The commit carries the Generated-by: trailer; the
contributor has reviewed the diff and owns the change.

[Kaap10]

Thanks for tackling #1678, @sharpca! The prompt fix itself is very well thought out — removing STALE-CANDIDATE from the 5-row mutually exclusive triage table and clarifying that staleness is an orthogonal boolean (is_stale_candidate: true) completely resolves the model divergence between Sonnet and Opus/Fable, while keeping the existing eval fixture case-4-stale-candidate/expected.json intact.

However, there is 1 major git branch issue that needs to be addressed before this PR can be reviewed and merged:

---

Major Blocker: Stacked PR / Branch Pollution

This PR was accidentally branched off your previous PR branch (#1752) rather than a clean branch off main:

• Commit 9f1da7d9 ("fix(security-tracker-stats): retry 5xx and default cache to temp root") from PR #1752 is included here.
• As a result, this PR currently touches 14 files across two unrelated skills/tools (security-tracker-stats-dashboard and issue-backlog-stats).

To fix this:
Please rebase your branch on origin/main to drop the PR #1752 commit:

git fetch origin main
git rebase --onto origin/main 9f1da7d93418ba7f0bc9150c171efad592eb7812 fix/stale-candidate-orthogonal
git push --force-with-lease origin fix/stale-candidate-orthogonal

This will isolate the PR diff to only the 2 files relevant to #1678 (plugins/magpie-issue/skills/backlog-stats/SKILL.md and tools/skill-evals/evals/issue-backlog-stats/step-2-classify/fixtures/output-spec.md).

---

Assessment of the Issue #1678 Changes (Commit f432930e)

Once the branch is rebased, the actual fix looks solid:

1. SKILL.md Step 2 & 3: Clear and unambiguous. The four-class table plus the explanatory paragraph under it prevents the LLM from trying to assign STALE-CANDIDATE as a primary class.
2. output-spec.md: The JSON schema enum and description explicitly drop STALE-CANDIDATE from allowed triage_class values.
3. Token Count: Restamped correctly (4984 -> 5055) and surface_hash is preserved since headings did not move.

[potiuk]

The fix is right and complete: staleness becomes the separate is_stale_candidate flag, the worked 216-day example matches case-4-stale-candidate, the stale_candidate count reads the flag, and the eval spec drops STALE-CANDIDATE from the enum to match. The step-2-classify eval passes 6/6 on it.

Since #1752 has merged, I rebased this branch onto main and dropped #1752's commit from it, so it now carries only your backlog-stats commit (65cf96f). Please pull (or reset to the new head) before pushing anything else to the branch. This is the PR that closes #1678 without the unrelated changes, so I am taking it forward over #1754.

Thank you!

---

This review was drafted by an AI-assisted tool and
confirmed by an Apache Magpie maintainer. The findings
below are observations, not blockers; an Apache Magpie
maintainer — a real person — will take the next look at the
PR. If you think a finding is mis-applied, please reply on
the PR and a maintainer will weigh in.

More on how Apache Magpie handles maintainer review:
Contributing guide.