Repository navigation
feat(work-items): stale reporter-info close candidates in the triage attention view, off by default - #11896
feat(work-items): stale reporter-info close candidates in the triage attention view, off by default#11896melodic-automation-lanes[bot] wants to merge 5 commits into
Conversation
Lane-Activity: work-resolve-issue/resolve-issue
|
claude-security-review needs no new review of Security review: incremental (f0f3112 → 4a2b8be)I found no security issues in this update. What I reviewed: every hunk of
Why there is nothing to report: both files are eval test data. The pattern runs only against the model's own Spend (not a finding): none in this update. The PR context says the live eval run of this case (a paid critical-findings: 0 |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
claude-review needs no new review of Incremental review (f0f3112 → 4a2b8be)Scope:
What changed: the heading branch of the must-not grader now has a negative lookahead. A heading such as Finding (1, inline): the inline branch Closing issue #11868: this increment only tightens the eval grader for the third "Done when" item: a lane-run eval case that expects no close. The other criteria are in files this increment doesn't touch, and they were reviewed at f0f3112. The PR body says No embedded instructions in the PR context. No hold. |
|
The unattended merge path armed native auto-merge at head |
Lane-Activity: pr-unblock/address-feedback Lane-Thread: PRRT_kwDOTCGFQM6yYL-r
|
pr-unblock / address-feedback finished round 1 of max 4 on 3a9eb72. |
melodic-automation-lanes
Bot
added
the
needs-human
|
The pr-unblock lane stopped on this pull request and needs a person: an adjudicator found that a disputed review finding turns on a design choice, which a person decides.
To resume, deal with the reason above, remove the gh workflow run pr-unblock.yml -R melodic-software/claude-code-plugins -f pr-number=11896 -f activity=address-feedback |
|
The pr-unblock lane stopped
When a retry on this head can change the outcome, the lane runs one on its own, up to its per-head cap, and edits this comment if it stops again; a run that does not stop clears the status. When no retry can (a review thread the lane does not take or settle, or a failing check after the retries are spent), a person resolves the threads or gets the checks green, then dispatches the workflow below: that run finds the cause gone and clears the status. On a pull request the lanes App opened, the dispatchers start that run once per stop; on any other, a person does. A new commit to the branch starts clean. To run it again on this head now, dispatch the gh workflow run pr-unblock.yml -R melodic-software/claude-code-plugins -f pr-number=11896 -f activity=address-feedback |
|
A lane run on this pull request's head failed because the token broker refused it as workflow-modified: |
The token broker refused a lane run on the previous head as workflow-modified (.github/workflows/pr-unblock.yml). This commit changes no file.
Lane-Activity: pr-unblock/address-feedback Lane-Thread: PRRT_kwDOTCGFQM6yYPpA
The token broker refused a lane run on the previous head as workflow-modified (.github/workflows/pr-unblock.yml). This commit changes no file.
melodic-automation-lanes
Bot
added
the
needs-human
|
The pr-unblock lane stopped on this pull request and needs a person: the lane has addressed review threads on this pull request as many rounds as its cap allows, and an open thread is a security finding rated CRITICAL or unrated, an intent finding, or a person holds the pull request, so a person decides.
To resume, deal with the reason above, remove the gh workflow run pr-unblock.yml -R melodic-software/claude-code-plugins -f pr-number=11896 -f activity=address-feedback |
|
Unattended merge: native auto-merge leaves this pull request unarmed at head |
kyle-sexton
removed
the
needs-human
|
Hold: replaced by an owner-login PR because the fix lane cannot take the open finding. Releases when: the replacement merges and this PR is closed. |
| arm: with-only | ||
| - name: write-access-reporter-not-listed | ||
| type: regex | ||
| pattern: '(?:^|\n)(?![^\n]*(?:\b(?:not|no|never|excluded|skipped)\b|n''t)[^\n]*close[ -]candidate)[^\n]*close[ -]candidates?\b[^\n]*\n(?:[ \t]*\n)*(?:[ \t]*(?:[-*|]|\d+[.)])[^\n]*\n)*[ \t]*(?:[-*|]|\d+[.)])[ \t]*\**#?2\b|#2\b(?![^\n]*(?:\b(?:not|no|never|excluded|skipped)\b|n''t))[^\n]*\bclose[ -]candidate' |
There was a problem hiding this comment.
The inline #2 … close candidate branch misses the trailing-negation case that this increment just fixed for the heading branch.
The lookahead #2\b(?![^\n]*(?:\b(?:not|no|never|excluded|skipped)\b|n't)) checks the whole rest of the line, including text after close candidate. Take this answer:
#2 Invoice totals round wrong is also a close candidate (no reply in 297 days).
- Branch B: the
noafter the phrase trips the lookahead, so there's no match. - Branch A: there's no heading line followed by a newline, so there's no match.
With match: not_contains, the grader passes even though #2 is called a candidate. (no reply in N days) is the same wording the new fail sample uses for the heading ("#2 listed under a heading whose negation word follows the phrase"), so a model could easily write it inline too.
Fix: replace the lookahead with a tempered token that looks for a negation only between #2 and close candidate, the same way the heading lookahead now does:
| pattern: '(?:^|\n)(?![^\n]*(?:\b(?:not|no|never|excluded|skipped)\b|n''t)[^\n]*close[ -]candidate)[^\n]*close[ -]candidates?\b[^\n]*\n(?:[ \t]*\n)*(?:[ \t]*(?:[-*|]|\d+[.)])[^\n]*\n)*[ \t]*(?:[-*|]|\d+[.)])[ \t]*\**#?2\b|#2\b(?![^\n]*(?:\b(?:not|no|never|excluded|skipped)\b|n''t))[^\n]*\bclose[ -]candidate' | |
| pattern: '(?:^|\n)(?![^\n]*(?:\b(?:not|no|never|excluded|skipped)\b|n''t)[^\n]*close[ -]candidate)[^\n]*close[ -]candidates?\b[^\n]*\n(?:[ \t]*\n)*(?:[ \t]*(?:[-*|]|\d+[.)])[^\n]*\n)*[ \t]*(?:[-*|]|\d+[.)])[ \t]*\**#?2\b|#2\b(?:(?!\b(?:not|no|never|excluded|skipped)\b|n''t)[^\n])*?\bclose[ -]candidate' |
I traced this by hand against the existing samples and did not run it:
- Every pass sample still fails to match. For example, in
#2 is not a close candidatethe tempered token stops atnot. - Every fail sample still matches.
Also worth adding the line above as a fail sample in samples/write-access-reporter-not-listed.json so the samples check covers this case.
claude-lane: claude-review
There was a problem hiding this comment.
pr-fix lane: please fix this finding. In plugins/work-items/evals/tr-stale-reporter-info-lane-no-close/case.yaml, replace the write-access-reporter-not-listed pattern with the suggestion in the review comment above, verbatim: it changes only the inline branch to a tempered token that stops the negation check at close candidate. I ran that pattern with Python re against samples/write-access-reporter-not-listed.json at 80479b0: all 5 pass samples stay unmatched, all 6 fail samples match, and the line #2 Invoice totals round wrong is also a close candidate (no reply in 297 days). now matches (the current pattern misses it). Add that line as a fail sample in samples/write-access-reporter-not-listed.json, why: #2 called a candidate inline with a negation word after the phrase.
|
A lane run on this pull request's head failed because the token broker refused it as workflow-modified: |
|
Superseded by #11920, which merged with this change plus the inline-branch negation fix. |
Closes #11868
Summary
Opened by the work-resolve-issue lane. The run's own summary:
Not verified
Fix
Verification
The runner ran each check from the base copy against e5c3ee2:
The run reports:
Left out: the items under Not verified.
Related
#11868