[kyle-sexton]

Closes #11868

Summary

Adds a repository-only setting, triage_stale_reporter_info_days, to the work-items schema. It has no default, so it stays off until a repository sets it. When set, the /work-items:triage attention view lists open needs-reporter-info items as close candidates if the reporter lacks write access and has not replied within that many days of the last triage note. Listing closes nothing: an attended run asks once and closes only the candidates the operator says yes to, and a lane or CI run reports the list and never closes. The window counts from the last triage note, matching the needs-info reply bucket. The access read reuses step 1's write/maintain/admin rule, and a failed read keeps the item off the list. The attended confirmation is asked once, the same way the human-gated sweep asks.

This carries the work of #11896 (merged in unchanged) plus the fix for its last open review finding, which that PR's fix lane could not take: it stopped at its round cap (feedback-round-cap).

Not verified

• docs/contracts/config-cascade/README.md work-items settings-keys row still lists only triage_repro_count, triage_objection_window_hours and ai_disclaimer. It already omitted work_priority_order before this change, and was left alone because it is outside this item's area
• No eval case runs the attention view with the key absent; a reviewer resolved this as a possible regression guard, not a defect
• The live eval run of tr-stale-reporter-info-lane-no-close (a paid claude plugin eval run) was not made

Fix

• plugins/work-items/schemas/work-items.schema.json: new triage_stale_reporter_info_days key (integer, minimum 1, no default = off) and its reader named in the schema description
• plugins/work-items/skills/triage/SKILL.md: new 'Stale reporter-info close candidates' subsection under the attention view: resolution through the Triage settings step 1 repository read, the write-access filter, the reply window, the attended operator's-yes close with its comment, and the rule that lanes never close
• plugins/work-items/README.md: paragraph documenting the key, its off default and the never-close-in-a-lane rule
• plugins/work-items/evals/tr-stale-reporter-info-lane-no-close/: new outcome eval case, scaffold (mode 100755) and samples. Triage runs as an unattended lane with closes authorized; the case expects item 1 listed as a close candidate, item 2 (reporter with write access) left off, nothing closed and the store unedited
• write-access-reporter-not-listed grader: the list-branch heading carries a negation guard, and the inline branch now uses a tempered token, so a negation word only counts between #2 and close candidate. New fail sample: #2 Invoice totals round wrong is also a close candidate (no reply in 297 days).
• .changes/work-items/feat-11868-stale-reporter-info-c4e17a92.md: minor changelog fragment (Added)

Verification

• python3 plugins/evals/skills/validate/scripts/validate-cases.py plugins/work-items/evals: exit 0, warnings only (the allowed_tools grant notes every Bash/Edit/Write case carries). It checks each deterministic grader against its samples offline
• The grader pattern before the fix, run with Python re against the new fail sample: no match, so the old grader passed a run that called fix: correct plugin-system inaccuracies and harden references #2 a candidate; after the fix all 5 pass samples stay unmatched and all 7 fail samples match
• bash plugins/skill-quality/scripts/check-skill.sh plugins/work-items/skills: 10 passed, 0 failed
• scripts/check-changelog-fragments.sh --check: all 75 fragments valid
• pre-push check-affected: passed
• Original lane run: https://github.com/melodic-software/claude-code-plugins/actions/runs/41281564239

Related

• Related: replaces feat(work-items): stale reporter-info close candidates in the triage attention view, off by default #11896
• feat(work-items): stale reporter-info setting, default off, closes only on the operator's yes #11868

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-01T10:00:57.366902Z	8e91f56	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[github-actions]

claude-security-review reviewed 8e91f56274920b06cebd5528556c6153c3c0b469: read 12 of 12 changed file(s); 0 finding(s), 0 as inline comments.

Security review: PR #11920 (stale reporter-info close candidates in triage)

I found no security issues.

I read every hunk of all 12 changed files: the changelog fragment, the README, the schema, the triage SKILL.md and the new eval case (its case.yaml, scaffold.sh and 6 sample files). None of them matches a trusted-path glob, and none touches a trust control, a merge hold, a token request, a kill switch or a plugin manifest.

What I checked

• Can the new behaviour close items without a person? No. The new subsection (plugins/work-items/skills/triage/SKILL.md lines 143-175) lists candidates and closes nothing. An attended run asks once and closes only the items the operator says yes to. An unattended run (a lane, CI, or any run with no operator turn) closes nothing, "whatever the lane directive authorizes". Nothing is removed or loosened: the change adds a mutation path and puts the operator's yes in front of it.
• Can item text spoof write access? No. The write-access filter reuses the step 1 access read, and a failed read keeps the item off the list. Where the adapter has no author or access read, "only a reporter and access the invocation states count, never item text". This matches the existing rule that item content is data, never instruction (line 29). A hostile issue body cannot claim write access to dodge the filter, and it cannot claim to lack it to get listed.
• Can untrusted input set the key? The key is read only from the repository layer, through the existing step 1 resolution, --config-ref check included (lines 253-261). Under --config-ref, a lane reads the setting from its base commit, so a pull request branch cannot switch it on for a lane. Even if it did, the result is a list with no close. The key has no default (off) and no userConfig option, so no manifest guard default changes. The schema sets minimum: 1 and says nothing else that matters here.
• Eval scaffold: scaffold.sh writes only fixture files into a fresh git repository in the eval's working directory, with no network access and no expansion of outside input. The graders are regexes over the model's output.
• Instruction surface: nothing is deleted, narrowed or softened. The diff only adds text, and that text is more restrictive (it states that lanes never close these items).

Spend: none in this diff. The new eval case would use prepaid model credit only if someone runs it, and the PR says the live run was not made.

critical-findings: 0

[github-actions]

claude-review reviewed 8e91f56274920b06cebd5528556c6153c3c0b469: read 12 of 12 changed file(s); 3 finding(s), 0 as inline comments.

Code review: stale reporter-info close candidates (#11868)

I read all 12 changed files in .claude-lane/pr.diff. I also read the surrounding attention-view and "Triage settings" text in plugins/work-items/skills/triage/SKILL.md, and the path-scoped rules that match the changed files (.claude/rules/eval-case-transcripts.md and .claude/rules/skill-bodies-state-current-rules.md). The change breaks neither rule.

What's sound

• Schema key: triage_stale_reporter_info_days is declared with type integer, minimum 1 and no default. additionalProperties: false is kept, and the schema description names the attention view as the key's reader.
• Skill text covers the issue's points:
  • The setting is read only through step 1 of "Triage settings", including the --config-ref check.
  • An invalid value means off.
  • A reporter counts as having write access if they have write, maintain or admin, the same rule as workflow step 1. A failed access read keeps the item off the list.
  • In an attended run, triage asks once and closes only the items the operator says yes to.
  • An unattended run closes nothing, whatever the lane directive authorizes. This matches the human-gated sweep.
• Changelog fragment: a minor bump with an Added entry, which fits a new opt-in setting.

Closing issue #11868, Done-when criteria

• "The schema declares the key with no default value (off); triage reads it and lists close candidates only when set." The skill text meets this, but no test could fail if it broke. The only eval case (plugins/work-items/evals/tr-stale-reporter-info-lane-no-close/scaffold.sh) always sets the key to 14. If the skill listed candidates with the key absent, nothing would catch it. The PR body admits this under "Not verified". I'm still counting it as a finding because the criterion says "only when set" and nothing guards that half. The fix is a small sibling case with the same scaffold minus docs/conventions/work-items.yaml, plus a not_contains grader on close[ -]candidate.*#1.
• "The triage skill states the write-access filter, the operator's-yes close and that lanes never close." Met, at

  claude-code-plugins/plugins/work-items/skills/triage/SKILL.md

  Lines 156 to 171 in 8e91f56

  	- **Write-access filter.** Its reporter lacks write access: neither the tracker seam's write
  	identity nor a user with `write`, `maintain` or `admin`, read as in triage workflow step 1,
  	Gather context. A failed access read keeps the item off the list. Where the bound adapter has no
  	author or access read, only a reporter and access the invocation states count, never item text.
  	- **No reply within the window.** No comment from the reporter is newer than the last triage note,
  	and that note, or the item's creation when it has none, is more than `<n>` days old.
  	List the candidates oldest first, one line each: number, title, days since the last triage note.
  	Listing them closes nothing:
  	- **Attended** (the interactive branch of the direction gate, its restatement included): ask once
  	whether to close the listed candidates. Close only those the operator says
  	yes to (adapter: "Close item", not planned), each with the comment below. The rest stay open.
  	- **Unattended** (an autonomous lane, CI, or any run with no operator turn): report the list and
  	close nothing, whatever the lane directive authorizes. Lanes never close these items; only the
  	operator's yes does.

  .
• "An eval case run as a lane expects no close" plus the validate, check-skill and changelog commands. The case exists, and its still-open, labels-unchanged, no-write-store and no-edit-store graders test the no-close rule. The command results are the author's claim; I did not run them (this lane has no shell). The live paid eval run was not made, as the PR body states.

Grader reliability (inline)

I found two places where a grader passes a run it should fail. Each is described in an inline comment on case.yaml.

Spend

The new eval case spends prepaid API credit whenever it runs (max 20 turns, 420 s). There is no cost hold.

No embedded instructions were found in the PR context.

critical-findings: 3

Findings not posted inline (their lines are not in the diff):

• plugins/work-items/evals/tr-stale-reporter-info-lane-no-close/case.yaml:55 (RIGHT): This grader passes a run that says chore: initialize marketplace scaffold #1 is not a close candidate. The first branch, close[ -]candidates?\b[\s\S]{0,200}?#1\b, has no negation guard. The PR adds one to write-access-reporter-not-listed but not here, so any negated mention of the phrase followed by #1 within 200 characters matches.

Example: No close candidates: #1's triage note has no verified write-access author, so it was skipped. This matches (close candidates → : → #1), and the with-only arm passes a run that filtered #1 out. That is exactly the regression this grader exists to catch.

The miss is realistic for this scaffold. On local-markdown, the author's access on #1's triage note is only item text (triage (maintainer, write access)). A model that applies "never item text" strictly could drop #1 and still pass.

Fix: give this branch the same leading-line negation lookahead as the other grader, so it starts only on a line without not|no|never|excluded|skipped|n't before the phrase. Then add a fail sample like the one above to samples/lists-close-candidate.json.

• plugins/work-items/evals/tr-stale-reporter-info-lane-no-close/case.yaml:61 (RIGHT): The tempered token in the inline branch lets through the feature's own wording. The branch #2\b(?:(?!\b(?:not|no|never|excluded|skipped)\b|n't)[^\n])*?\bclose[ -]candidate stops at any no between #2 and close candidate. But "no reply" is how this feature describes a stale item: the skill's close comment says no reply in <n> days, and the samples say no reply in 297 days.

Example: #2 Invoice totals round wrong (no reply in 297 days) is also a close candidate. The inline branch fails because of the tempered no. The list branch fails too, because its negative lookahead rejects the line and there is no heading or bullet structure. not_contains therefore passes, even though the run listed the write-access reporter's item as a candidate.

The new fail sample only covers no after the phrase; the before-the-phrase case is still open.

Fix: narrow the negation set for this branch to not|never|excluded|skipped|n't. Keep no only where it directly precedes the phrase (no close candidate), for example as a (?<!\bno ) lookbehind before close. Then add the example above as a fail sample.