Problem
Before PR #318, idd-list Step 3.7 fed three signals into the Blocked (waiting on external) group: a non-empty ### Blocking section, a blocked label, and a wait-class Suggested-next (cluster UNKNOWN wait / waiting for a collaborator reply). Round 2 rewired Step 3.7 around the shared three-signal gate and kept a sentence saying the blocked label and wait-class signals "only affect Blocked-group placement, not the gate" — but the entry's group is now produced solely by idd_actionability_group, and no step computes those two signals any more.
Effect: an issue carrying a blocked label with an empty ### Blocking section landed in the Blocked group on main and lands in Actionable now after #318, with a lifecycle command attached. This repo has no blocked label today (so nothing changes here), but the plugin ships to repos that use that convention, and the wait-class heuristic is label-independent.
Source
Expected
Either restore an operative instruction in Step 3.7 — when GROUP=actionable, a blocked label or a wait-class Suggested-next still moves the entry to the Blocked group with the label name / wait pattern as blocked_reason — and define what the Blocked row prints when $BLOCK_LINE is empty; or delete the two claims and record honestly that #84's two secondary signals were retired in 3.1.0.
Acceptance criteria
Complexity
Simple — single skill file plus one test assertion; the decision is binary and the #84 contract is already written.
Problem
Before PR #318, idd-list Step 3.7 fed three signals into the Blocked (waiting on external) group: a non-empty
### Blockingsection, ablockedlabel, and a wait-class Suggested-next (cluster UNKNOWN wait / waiting for a collaborator reply). Round 2 rewired Step 3.7 around the shared three-signal gate and kept a sentence saying theblockedlabel and wait-class signals "only affect Blocked-group placement, not the gate" — but the entry'sgroupis now produced solely byidd_actionability_group, and no step computes those two signals any more.Effect: an issue carrying a
blockedlabel with an empty### Blockingsection landed in the Blocked group onmainand lands in Actionable now after #318, with a lifecycle command attached. This repo has noblockedlabel today (so nothing changes here), but the plugin ships to repos that use that convention, and the wait-class heuristic is label-independent.Source
Expected
Either restore an operative instruction in Step 3.7 — when
GROUP=actionable, ablockedlabel or a wait-class Suggested-next still moves the entry to the Blocked group with the label name / wait pattern asblocked_reason— and define what the Blocked row prints when$BLOCK_LINEis empty; or delete the two claims and record honestly that #84's two secondary signals were retired in 3.1.0.Acceptance criteria
idd-list/SKILL.mdagree on what feeds the Blocked groupComplexity
Simple — single skill file plus one test assertion; the decision is binary and the #84 contract is already written.