[kyle-sexton]

No related issue: lesson L121 from the #12727 close that unblocked #12621

Summary

Closing an item resolves every edge where it blocks another item. When
#12727 closed as a duplicate
of the wave issues, #12621
lost its only open blocker and the issue lane admitted it before its prerequisite existed
(stop comment).
Both work-items close paths now move each dependent's wait onto the item that carries the work
before they close.

Fix

• plugins/work-items/reference/issue-conventions.md: new "Dependents on close" section, the one
  shared, provider-neutral step. List the open items the closing item blocks, name the carrier
  (duplicate: the surviving item; superseded or split: the carrying item; delivered: none), add
  each new edge through the seam's existing link-blocks verb, then remove the edge to the closing
  item, then close. A won't-fix with no carrier keeps its edges and names its dependents in the
  closing comment for re-triage. Any failed add or removal stops the close.
• Old edge removal: chosen because the seam counts a duplicate or not-planned blocker as still
  blocking (CONTRACT.md blocked_by_count), so a kept edge would hold a re-pointed dependent off
  the frontier for good. It runs only after the new edge lands, so no dependent passes through a
  moment with no open blocker.
• plugins/work-items/skills/triage/context/apply-outcome.md: every close outcome runs that step
  first.
• plugins/work-items/skills/track/actions/done.md: every direct close runs it first; a
  completed close is the delivered case.
• plugins/work-items/tools/work-item-tracker/adapters/github/README.md "Close item": the GitHub
  recipe, the REST
  list dependencies an issue is blocking
  read (it works in cloud sessions and keeps cross-repo dependents) and
  gh issue edit --remove-blocked-by, with a pointer record.
• The tracker contract already had link-blocks for adding an edge; it has no verb to list
  dependents or remove an edge, so those stay provider mechanics in the adapter README rather than
  new adapter ops.

Verification

• gh api --paginate repos/melodic-software/claude-code-plugins/issues/12727/dependencies/blocking
  returned 12620, 12621, 12622 and 12623, the dependents the incident named.
• scripts/check-changelog-fragments.sh --check-required origin/main: pass.
• scripts/check-changed-skills.sh origin/main: track and triage pass, 0 errors (warnings are
  existing size warnings).
• Pre-push check-affected: pass.
• Evals not run. An eval case in plugins/work-items/skills/triage/evals/ should cover a duplicate
  close whose item blocks open work, checking that the edge moves before the close.

Related

• #12727: the duplicate close
• #12621: the dependent admitted
  too early

🤖 Generated with Claude Code

https://claude.ai/code/session_01MWmASMaG92q8enDXFa5Doc

[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-03T20:06:42.302595Z	b8061fe	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.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b8061fede1

ℹ️ 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".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[github-actions]

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

Security review (incremental): PR #12929, b8061fe..2343cc4

No security issues found.

critical-findings: 0

Scope

I read every hunk of both files in .claude-lane/incremental-files.txt, using .claude-lane/incremental.diff:

• plugins/work-items/reference/issue-conventions.md: step 1 of "Dependents on close" now says that a failed or partial read of dependents is not the same as having none, so the close does not go ahead.
• plugins/work-items/tools/work-item-tracker/adapters/github/README.md: the REST read of dependents now runs with set -o pipefail, and a non-zero exit stops the close. The cloud-session note now says that only a close needing new carrier edges is held there. A close that keeps its edges (delivered, or dropped with no carrier) goes ahead.

Neither file is on the trusted-path list. Neither is a plugin manifest, workflow, token, kill-switch or merge-hold file.

What I checked

• Fail-closed read. Before this change, a failed gh api --paginate piped through tr could exit 0 with an empty or partial list. The close then read that as "no dependents" and went ahead, freeing the dependents. With pipefail and the new "a failed or partial read is not none" rule, that case now stops the close. This tightens the step.
• Narrowed cloud-session rule. The earlier text held every close of an item with open dependents in a cloud session. The new text holds only closes that need edges written, and lets a close that keeps its edges go ahead. I checked what that close does:
  • Delivered close: this is the "close with the edges as they are" case the conventions already define, so freeing the dependents is intended.
  • Dropped close with no carrier: the edges stay. The PR context cites the seam's blocked_by_count, which treats a not-planned blocker as still blocking, so the dependents stay blocked.
  • Result: no new write happens, no token scope or trust changes, and untrusted text reaches no new path. The rule this narrows covers work ordering, not any protected class in the instruction exception register.
• Injection. The new commands and inputs are the same as before. They use only .number and .html_url from the API.

Notes

• No embedded instructions in the PR context.
• The only prior post is this lane's clean summary from the last head, so there is nothing to re-post. This is round 0 of a cap of 3, so the cap did not apply.
• No cost impact: these are documentation changes only.

[github-actions]

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

Code review (incremental): PR #12929, b8061fe → 2343cc4

Result: no findings. I read every hunk in both files in scope: plugins/work-items/reference/issue-conventions.md and plugins/work-items/tools/work-item-tracker/adapters/github/README.md. I also read the head text around each hunk.

What changed since the last review

• Listing step. The dependents listing in the README now starts with set -o pipefail. Before this, a failed or partial gh api --paginate read was hidden by the trailing | tr -d '\r' and returned exit 0. The new text says a non-zero exit means the list may be empty or partial, so the close stops. issue-conventions.md step 1 now has the same rule: "A failed or partial read is not none: do not close."
• Cloud-session rule. The rule (README:268-271) now refuses only a close whose dependents need a new carrier. A delivered close, or one dropped with no carrier, keeps its edges, writes none, and goes ahead. This matches step 2 of "Dependents on close". Only the carrier step calls link-blocks, which exits 3 in a cloud session, so the refusal now covers exactly that step.

Prior findings and settled threads

• My round-1 finding (README:264). It said the cloud rule blocked closes that write no edges. That is fixed by the rewritten README:268-271. The prior post has no line anchor, so there is nothing to repost.
• Settled threads. Both resolved threads (the pipefail gap and the cloud-close scope) are marked lines changed since resolution: no at this head. The new text matches the owner's replies, and I'm not reopening either one.
• Round count. This is round 2 of a cap of 3, so the cap did not apply.

Other notes

• Closing issue: none. The PR body says "No related issue", so there are no acceptance criteria to check.
• Manifests: none changed in this push.
• Verification: I ran nothing. The author's Verification section is their claim and I haven't checked it.
• Embedded instructions: none found in the PR context or the settled-thread text.