[melodic-automation-lanes]

Closes #11869

Summary

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

Triage now recognizes an idea issue: a feature request that names something to build but says nothing about what it is for. Such an item skips the redundancy, ledger and cluster checks and steps 2 to 4 (step 2's direction gate still applies). Triage runs the needs-spec label preflight, posts a comment naming /planning:interview as the next step, then in one edit applies needs-spec and removes the raw marker. A lane does not run the interview; an interactive session offers to. A new eval case checks the route and that triage does no exploration. Design choices, based on the existing skill: I modelled the route on the split-size/probe-first routes, which name the next skill and leave running it to a person. The park label goes through the same preflight as status: confirmed, since needs-spec is not in the live label set's documented axes yet. A signal-marked idea issue keeps its C5 labels.

Not verified

• python3 plugins/evals/skills/validate/scripts/validate-cases.py plugins/work-items/evals: this lane cannot run an interpreter and has no wrapper for it, so I hand-checked samples against the patterns instead. Left to the PR's CI
• bash plugins/skill-quality/scripts/check-skill.sh plugins/work-items/skills: no wrapper for it in this lane, and check-affected skipped changed-skills because it runs the checked tree's own code. Left to the PR's CI
• check-evals-quality wrapper: it takes an evals.json file, not a case.yaml directory, so it does not apply to the new case; check-affected lists evals-quality as CI only
• tidy: not run because the change is about 400 changed lines, over the 300-line tidy cutoff (9 new files plus 3 edited markdown files, all in plugins/work-items with .changes/work-items)
• The eval does not grade the label edit on .work-items/1.md. The local-markdown adapter has no label listing or label-edit verb, so whether the needs-spec preflight passes there is uncertain. The final-message grader checks the route instead
• needs-spec is not added to the tracker's human floor (WIT_HUMAN_FLOOR_STATUS_LABELS in tools/work-item-tracker/lib/labels.sh), so a parked idea issue can still appear on list-frontier. This is outside this issue's done-when; a follow-up may want it
• The eval case was not executed against a model (paid run); only its static samples were checked
• git status shows untracked dotfiles at the checkout root (.bashrc, .bash_profile, .gitconfig, .idea, .mcp.json, .profile, .ripgreprc, .vscode, .zprofile, .zshrc) that this run did not create; they look like sandbox artifacts and should not go into the patch

Fix

• plugins/work-items/skills/triage/SKILL.md: adds the 'Idea issue' route to step 1, ahead of the checks: definition, no exploration, preflight, then comment, then needs-spec plus raw-marker removal, the signal-marker exception, and offering the interview interactively but never running it in a lane. A
• plugins/work-items/skills/triage/context/apply-outcome.md: adds needs-spec to the raw-marker clearing invariant and to the labels the preflight covers
• plugins/work-items/reference/label-taxonomy.md: lists needs-spec on the Meta axis
• plugins/work-items/evals/tr-idea-issue-routes-to-interview/case.yaml: new eval case for an idea issue on a local-markdown scaffold. Graders: the final message names /planning:interview and needs-spec, and no Grep, Glob, source Read or Bash search runs over the checkout
• plugins/work-items/evals/tr-idea-issue-routes-to-interview/scaffold.sh: scaffold holding one raw idea issue plus source code an exploring triage would search
• plugins/work-items/evals/tr-idea-issue-routes-to-interview/samples/*.json: pass/fail samples for each of the five deterministic graders
• .changes/work-items/work-resolve-issue-issue-11869-5d2c9a17.md: minor changelog fragment for the triage route

Verification

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

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

The run reports:

• /home/runner/work/claude-code-plugins/claude-code-plugins/.lane/checks/bin/check-changelog-fragments: all 53 fragments valid (ran before and after the review fixes)
• /home/runner/work/claude-code-plugins/claude-code-plugins/.lane/checks/bin/check-affected: 12 passed, 6 skipped over 11 changed files (ran before and after the review fixes)
• fresh-context review subagent over the whole diff: no blocking defects. It hand-checked every sample under Python re and JS RegExp. Its findings were fixed: Bash grader now catches commands after a newline and 'ls src'; Grep/Glob exemptions narrowed to the plugin root and the .work* paths; preflight
• The lane run: https://github.com/melodic-software/claude-code-plugins/actions/runs/41281674150

Left out: the items under Not verified.

Related

#11869

[github-actions]

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

Security review (incremental, 8175049 → 5e24718)

No security issues found in this change.

I read every hunk of the two files in scope in .claude-lane/incremental.diff:

• plugins/work-items/evals/tr-idea-issue-routes-to-interview/case.yaml: only the description and expected_outcome text changed. The case now says it checks the route and the lack of exploration, but not whether the needs-spec label edit lands. The graders, scaffold, tool allowances and execution settings are unchanged, so the case can't run anything it couldn't run before.
• plugins/work-items/skills/triage/SKILL.md: two bullets were removed from the ## Next section (

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

  Line 343 in 5e24718

  ## Next

  ). One pointed to /work-items:attend-queue for items that keep the human-gated label, the other to /session-flow:workflow.
  • I checked the removal with the instruction-surface lens. Both lines suggested a next skill to run; neither was a rule that stopped any action, so removing them removes no guardrail.
  • The human-gated label test, the sweep, and the line saying items that keep the label are /work-items:attend-queue rows (around L202) are all still in place.
  • I didn't read docs/contracts/instruction-exception-register/README.md (the list of protected rule classes); I judged the removal by what breaks without the lines, which is nothing that a rule enforced.

None of the trusted-path globs matches either file. Neither file is a trust control or a plugin manifest. The PR context contains no embedded instructions aimed at this lane.

critical-findings: 0

[github-actions]

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

claude-lane: claude-review

[github-actions]

A parked idea issue still shows up on the autonomous frontier. wit_filter_frontier --autonomous (tools/work-item-tracker/lib/frontier.sh:41-45) drops an item only if it has the human-gated label or a label in the human floor. The floor's status list (lib/labels.sh:40-43) has status: needs-decision and status: needs-info but not needs-spec.

This route applies needs-spec with no role, status: or work-class label. So an item parked here (e.g. this eval's #1 after the park) is listed by list-frontier --autonomous. The needs-info and needs-decision parks are kept off it.

An attended /work-items:work run picking from that frontier can then start building something whose intent this paragraph says can't be judged yet. The label-path lanes still need the autonomous-eligible label, so they are not affected.

The PR body leaves this as a follow-up. Adding needs-spec to the floor, with a frontier test, would make the park hold like the other two. If it stays out of scope, a sentence here or a follow-up issue would keep the gap on record.

claude-lane: claude-review

[melodic-automation-lanes]

pr-unblock / address-feedback: UNCERTAIN, left open

Evidence: plugins/work-items/tools/work-item-tracker/lib/frontier.sh:41, plugins/work-items/tools/work-item-tracker/lib/labels.sh:40, plugins/work-items/skills/triage/SKILL.md:266

The claim holds. wit_filter_frontier with autonomous=true drops an item only for the human-gated label or a floor label, and WIT_HUMAN_FLOOR_STATUS_LABELS lists status: needs-decision and status: needs-info but not needs-spec. The idea-issue route applies needs-spec with no role or status label, so a parked item stays on the autonomous frontier. The real fix is to add needs-spec to the human floor in labels.sh and add a frontier test. That is shared tracker infrastructure used by every frontier caller, and the review-thread scope check refuses labels.sh for this lane. Leaving the thread open for a person to choose: widen this PR to change the floor, or file a follow-up and note the gap in the skill.

[melodic-automation-lanes]

pr-unblock / adjudicate-feedback: the finding stands

A fresh-context adjudicator read the review comment, the locations both sides cited and the code at 8175049c0854ba847d04320baf1ffed120de8711, without the fixing lane's reasoning, and found that the finding holds. The next address-feedback round fixes it; a round that leaves this thread open again ends the lane in a failing status.

Evidence: plugins/work-items/tools/work-item-tracker/lib/frontier.sh:41, plugins/work-items/tools/work-item-tracker/lib/labels.sh:40, plugins/work-items/skills/triage/SKILL.md:266

[kyle-sexton]

pr-fix lane: please fix this finding. Add needs-spec to the human floor in plugins/work-items/tools/work-item-tracker/lib/labels.sh (the status list at lines 40-43 holds only status: needs-decision and status: needs-info), plus a frontier test showing that list-frontier --autonomous drops a needs-spec item. That way the idea-issue park holds like the other two. The change is in the same plugin, so it belongs in this PR.

[melodic-automation-lanes]

pr-unblock / address-feedback: UNCERTAIN, left open

Evidence: plugins/work-items/tools/work-item-tracker/lib/labels.sh:40, plugins/work-items/tools/work-item-tracker/lib/frontier.sh:43, plugins/work-items/tools/work-item-tracker/lib/frontier.test.sh:139

The direction asks for two changes: add needs-spec to the human floor in lib/labels.sh, and add a frontier test showing that the autonomous frontier drops a needs-spec item. The finding still holds at this head. WIT_HUMAN_FLOOR_STATUS_LABELS (labels.sh:40-43) lists only status: needs-decision and status: needs-info. wit_filter_frontier (frontier.sh:30 and 41-45) drops an autonomous item only for the human-gated label or a floor label, so a bare needs-spec item stays on the autonomous frontier. labels.sh is in this lane's scope because the direction names it. The test is not. Its home is lib/frontier.test.sh, where the STATUS fixture at lines 137-148 already covers the other two status parks, and the review-thread scope check refuses that file: it is a .sh file outside this thread's directory and is not a path the direction names. Every other frontier test in the tracker is also a .sh file under tools/work-item-tracker, so none is in scope either. Landing the floor change without the test would ship half of the direction and leave a behavior change untested. Putting a frontier test under skills/triage just to pass the scope check would put it in the wrong place. So this round makes no edit. To let the next round do both parts, post the fix request again and name plugins/work-items/tools/work-item-tracker/lib/frontier.test.sh as well as labels.sh. With both in scope, the fix is: add needs-spec to the floor list in labels.sh (it is a bare Meta label, not a status: value, so the comment above the list should say so), add a needs-spec item to the STATUS fixture asserting that the autonomous frontier drops it and the default frontier keeps it, and add needs-spec to the floor sentence in CONTRACT.md at lines 306-307.

[github-actions]

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

Incremental review (8175049 → 5e24718): no findings.

I read every hunk in both files that changed in this range.

• plugins/work-items/evals/tr-idea-issue-routes-to-interview/case.yaml: the description and expected_outcome now say the case grades only that the final message names needs-spec as the parking label. It does not grade whether the label edit lands. That matches the grader at line 17, which only looks for /planning:interview and needs-spec in the final message. It also matches the PR's "Not verified" note: the local-markdown tracker has no label listing, so the preflight may stop the edit. The closing issue's done-when asks for an eval that "expects the interview route and no exploration", and the case still does that. The needs-spec park itself is described in SKILL.md step 1, which covers the first done-when item.
• plugins/work-items/skills/triage/SKILL.md: the ## Next section drops the /work-items:attend-queue and /session-flow:workflow bullets, so it now has 4 bullets. That fits the "two to four bullets" shape that check 27 in plugins/skill-quality/scripts/check-skill.sh warns about. /work-items:attend-queue is still named in the body, at SKILL.md#L186 and #L202, so that route is still documented. The /session-flow:workflow "unsure where this leaves the work" fallback is gone from this skill. That is a deliberate trade to fit the bullet cap, not a defect.

I ran no checks myself (this lane has no shell). The PR's statements about validate-cases.py and check-skill.sh come from the author and I did not confirm them.

I found no embedded instructions in the PR context.

[melodic-automation-lanes]

The unattended merge path armed native auto-merge at head 8175049c0854ba847d04320baf1ffed120de8711.

[melodic-automation-lanes]

pr-unblock / address-feedback finished round 1 of max 4 on 5e24718.

[melodic-automation-lanes]

The pr-unblock lane stopped address-feedback on this pull request: an adjudicator found a review finding stands, and the next round left it open again. The lane sets no label: the run ends in a failing pr-unblock/address-feedback status on the head the lane gated.

• Reason: feedback-stood-open
• Head: 5e24718d319314ab7dfbe34766d65ea331769138
• Run: https://github.com/melodic-software/claude-code-plugins/actions/runs/41290427739

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=11893 -f activity=address-feedback

[melodic-automation-lanes]

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

a pr-unblock lane stopped its head (pr-unblock/address-feedback is failure), which ci-status fails
  in the merge queue

[kyle-sexton]

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.

[melodic-automation-lanes]

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

[kyle-sexton]

Superseded by #11918, which carries this change plus the needs-spec human-floor fix and its frontier test.