[melodic-automation-lanes]

Closes #11867

Summary

Opened by the work-resolve-issue lane. The run's own summary:

Triage step 1 now has the triage agent read the repository's glossary, the ADRs covering the item's area and its scope statement before any evaluation check, and report them in a Read first: line. A new repository-only setting, triage_outside_prs (boolean, default false), is declared in the work-items schema. The attention view resolves it with the bundled parse-concern-value.sh before listing, and lists and fetches no PRs unless it is true; a PR named explicitly is still triaged. I made the key repository-only, with no userConfig option, because the issue calls it a repository setting and the schema already has a repository-only key, work_priority_order. A new eval case covers the unset key: the attention view must show no [PR] rows.

Not verified

• python3 plugins/evals/skills/validate/scripts/validate-cases.py plugins/work-items/evals was not run: this lane cannot run an interpreter, and the check-evals-quality wrapper accepts only evals.json files. Left to the PR's CI evals checks. The reviewer traced it by hand and expects exit 0 with one W
• bash plugins/skill-quality/scripts/check-skill.sh plugins/work-items/skills was not run: this lane's Bash runs only the named wrappers, and check-affected skipped changed-skills. Left to the PR's CI. The reviewer read the checks and expects no FAIL; SKILL.md is under 500 lines
• The new eval case was not executed against a model (no eval runner in this lane)
• Tidy pass 5 (ai-slop audit fix) was only partly run: detect.sh and digest-guard.sh cannot run under this lane's Bash rule. A rubric read by eye and a grep found no em dashes and no catalog vocabulary in the changed lines
• review-venue.txt was absent, so a local fresh-context subagent did the review
• docs/contracts/config-cascade/README.md (work-items settings-keys row) does not list triage_outside_prs. It already omitted work_priority_order, and it is outside this change's area, so it was left alone
• The working tree has untracked files this run did not create: .bash_profile, .bashrc, .gitconfig, .idea, .mcp.json, .profile, .ripgreprc, .vscode, .zprofile, .zshrc. They look like runner-environment files and were left untouched; they are not part of this change
• changelog fragment written by hand: the new-changelog-fragment wrapper refused because HEAD is detached; the name follows the existing work-resolve-issue-issue-<n>-<hex> pattern and check-changelog-fragments accepts it

Fix

• plugins/work-items/skills/triage/SKILL.md: the read-first step in step 1 (glossary, area ADRs, scope statement, a Read first: output line); an 'Outside-PR intake' paragraph under Triage settings (repository layer only, default false, invalid value taken as false, reported in a Settings line); the
• plugins/work-items/schemas/work-items.schema.json: new triage_outside_prs boolean key, default false; the top description notes it has no userConfig layer
• plugins/work-items/README.md: a paragraph documenting triage_outside_prs
• plugins/work-items/evals/tr-outside-prs-unset-lists-no-pr/case.yaml: new eval case; the key is unset (no work-items.yaml) and the listing includes an outside PR; graders: ＃31 listed, triage_outside_prs reported false, no PR row (no [PR] prefix and no ＃32 table or list row), no PR listing command
• plugins/work-items/evals/tr-outside-prs-unset-lists-no-pr/samples/*.json: pass and fail samples for each of the four graders
• .changes/work-items/work-resolve-issue-issue-11867-5d2e8c71.md: minor work-items changelog fragment

Verification

The runner ran each check from the base copy against df5ce8d:

• scripts/check-changelog-fragments.sh --check: passed

The run reports:

• check-changelog-fragments (run 3 times, last after the review fixes): All 60 changelog fragment(s) under .changes/ are valid
• check-affected (run 3 times, last after the review fixes): 11 passed, 7 skipped over 9 changed files; validator runs that execute the checked tree's own code, such as changed-skills, are skipped and left to CI
• Traced each regex and tool_used grader against its samples by hand (pattern semantics under JavaScript RegExp): every sample lands on the side it is filed under
• Fresh-context subagent review of the full diff: no high-severity findings. Fixed: the no-pr-rows grader now also catches a ＃32 table or list row, a numbered list and a backticked prefix; the gh api pattern now covers quoted paths, gh search prs and pullRequests; the case description names the Bash g
• Code-tidying tidy-diff over the changed hunks: three wording edits in SKILL.md and README.md; the passes for JSON and YAML files had nothing to change
• The lane run: https://github.com/melodic-software/claude-code-plugins/actions/runs/41281563218

Left out: the items under Not verified.

Related

#11867

[github-actions]

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

Security review (incremental, c55d60a → 0bff85a)

No security issues found.

This review covers the two files changed since the last review:

• plugins/work-items/evals/tr-numbered-states-read-first/case.yaml: the no-tracker-write grader's input_match regex is rewritten so read-only calls stop counting as writes. A gh api call with an explicit -X GET plus -f, or a gh api graphql -f query=... read, no longer matches. A call still counts as a write when it uses -X POST/PATCH/PUT/DELETE, mutation, --input (unless the method is GET), or -f/--field outside GET and outside graphql.
• plugins/work-items/evals/tr-numbered-states-read-first/samples/no-tracker-write.json: two new pass samples cover those two read-only forms.

Both files are eval test data. They are read by the eval grader and never run in a lane that holds credentials. Neither file matches a trusted-path glob. The change touches no trust control, plugin manifest, standing instruction, workflow or token scope. Loosening the grader can only change whether an eval sample passes or fails. It cannot leak a token, compromise an account or machine, or cause a charge. The PR context file contains no embedded instructions aimed at this lane.

critical-findings: 0

[github-actions]

claude-review reviewed 0bff85ab3c9007d8709065480b36515329da3267: read 2 of 2 changed file(s); 0 finding(s), 0 as inline comments.

Incremental code review: c55d60a → 0bff85a

Scope: I reviewed the two files changed since c55d60a. I read every hunk of both in .claude-lane/incremental.diff, and read the whole head file of each for context.

• plugins/work-items/evals/tr-numbered-states-read-first/case.yaml: the no-tracker-write input_match regex
• plugins/work-items/evals/tr-numbered-states-read-first/samples/no-tracker-write.json: two new pass samples

Result: no findings.

What changed

The gh api branch of the regex is now split into two parts:

1. Always a write: an explicit -X/--method of POST, PATCH, PUT or DELETE, or the word mutation.
2. A write unless excluded: an implied write. That means --input with no explicit -X GET, or -f/-F/--field/--raw-field with no explicit -X GET and no graphql endpoint.

Read-only searches (-X GET ... -f q=...) and GraphQL queries are no longer counted as tracker writes.

Hand trace (JavaScript RegExp semantics)

I traced each sample through the regex by reading it; nothing was executed.

• New pass: gh api -X GET search/issues -f q=.... Branch 1 finds no mutating method and no mutation. Branch 2's -X GET lookahead rejects it. Result: no match ✔
• New pass: gh api graphql -f query='{ repository(...) ... }'. Branch 1 finds no mutation. Branch 2's [ \t]graphql lookahead rejects the -f/--field part, and there is no --input. Result: no match ✔
• Existing pass: gh api repos/o/r/issues/31\ngrep -F .... The command segment stops at the literal \n, so the -F after it is out of scope. Result: no match ✔
• Existing fails, all still match:
  • -X POST: branch 1
  • implied-POST -f 'labels[]=bug': branch 2, since there is no GET and no graphql
  • GraphQL mutation {...}: branch 1 via \bmutation\b
  • gh issue edit and gh issue comment: first alternative ✔
• gh api graphql --input file.json still counts as a write, because the graphql exclusion covers only the field flags. That errs on the safe side.

Considered, not raised

The -X GET and graphql exclusions look for those words anywhere in the command segment, not only as the method or endpoint. So a REST write whose own field text contains graphql or -X GET, such as -f body='... graphql ...', would not be counted. A triage run told to "change nothing" is unlikely to produce that command, so I did not count it as a finding. Anchoring graphql to the endpoint position would close the gap if it ever matters.

Not verified

• I did not run validate-cases.py. This lane has no shell, so it is left to the PR's CI evals checks.
• The eval case was not run against a model.

No settled-threads file was supplied. The PR context holds no instructions aimed at this lane.

[melodic-automation-lanes]

The unattended merge path armed native auto-merge at head df5ce8d62b11551fd095e99e99ceca9744eaeac4.

[github-actions]

claude-review: 1 inline finding(s) on a84c06b923751f24c14f71d1860b55871bdc12a3; the summary is in this lane's pull request comment.

claude-lane: claude-review

[melodic-automation-lanes]

pr-unblock / address-feedback finished round 1 of max 4 on 2d7029a.

[github-actions]

claude-review: 1 inline finding(s) on 2d7029a5ece2bc428920a32c2e1bf1ce0771a59e; the summary is in this lane's pull request comment.

claude-lane: claude-review

[melodic-automation-lanes]

Unattended merge: native auto-merge leaves this pull request unarmed at head 0bff85ab3c9007d8709065480b36515329da3267. The lanes clear this reason on their own; the next scheduled run judges it again.

pr-merge's gate refuses its verifier verdict (verify:missing)

[melodic-automation-lanes]

pr-unblock / address-feedback finished round 2 of max 4 on c55d60a.

[github-actions]

claude-review: 1 inline finding(s) on c55d60a2b08737dd0ac5d5443fe5af5e9fe9f012; the summary is in this lane's pull request comment.

claude-lane: claude-review

[melodic-automation-lanes]

The pr-unblock lane stopped address-feedback on this pull request: the pull request has an unresolved review thread the lane does not take (a reviewer it does not act on, a review of an older head, or a thread it already answered), so no lane resolves it and a session builder takes it. The lane labels it needs-session for a session builder, who makes the change this lane cannot, and the run ends in a failing pr-unblock/address-feedback status on the head the lane gated.

• Reason: feedback-untaken-threads
• Head: 0bff85ab3c9007d8709065480b36515329da3267
• Run: https://github.com/melodic-software/claude-code-plugins/actions/runs/41299777698

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 pr-unblock workflow:

gh workflow run pr-unblock.yml -R melodic-software/claude-code-plugins -f pr-number=11908 -f activity=address-feedback

[melodic-automation-lanes]

The unattended merge path armed native auto-merge at head 0bff85ab3c9007d8709065480b36515329da3267.