work-items/tracker: list-sub-items returns empty because gh --json subIssues nodes carry no repository field

[kyle-sexton]

Agent Brief

Type: Bug

Summary: list-sub-items and list-frontier --parent return empty on GitHub because the adapter filters sub-issue nodes on a repository field that gh --json subIssues does not emit.

Current behavior:

Publishing a spec container with native sub-issues succeeds (edges verified on GitHub), but work-item-tracker.sh list-sub-items <container> returns an empty list. The GitHub adapter intersects subIssues.nodes on .repository.nameWithOwner; gh 2.97 returns sub-issue nodes without a repository field, so the intersection is always empty. Container rollup, list-frontier --parent, and /work-items:ship status are blind to every sub-item. Observed 2026-09-06 while publishing #3799 through #3823.

Desired behavior:

list-sub-items returns every native sub-issue of the container, and list-frontier --parent <n> scopes correctly, on the gh version currently installed and on the field shape the GitHub API documents for sub-issues. When the same-repo filter is still wanted, derive it from a field the API actually returns (for example the node's url or repository { nameWithOwner } requested explicitly in a GraphQL query) rather than a field absent from the REST-backed --json projection.

Key interfaces:

• GitHub adapter list-sub-items verb: same-repo filter predicate
• Seam list-frontier --parent (depends on the verb above)
• Adapter conformance test for sub-item enumeration

Acceptance criteria:

• list-sub-items 3799 returns the six sub-issues of Epic: typed ticket body (EARS acceptance criteria + design artifacts) #3799
• list-frontier --parent 3799 returns planning: plan the typed-ticket-body lane #3805 while it is open and unclaimed
• An adapter conformance test covers a container with at least one sub-issue and fails on the old predicate
• The gh version the fix was verified against is recorded in the adapter README

Out of scope:

• Adapters other than GitHub
• Changing the container publish path (edges are already correct)

Blocked by

None. Can start immediately.

[kyle-sexton]

Claimed by the autonomous worker lane.

• instance: vm-worker-202609050257
• lease expires: 2026-09-06T09:20:00Z (60 min TTL, renewed while active)
• scope: implement, test, independently review, open a close-linked draft PR. This lane does not merge.

Held until now rather than claimed on sight: this item was filed at 07:46 UTC and this lane skips anything touched within 30 minutes, so a triage lane still editing it would not be interrupted. Claimed at 08:18, past that window.

Known collision, flagged for whoever merges: unmerged PR #3745 already bumps this same plugin to 0.39.63 and adds a CHANGELOG.md entry. This work touches different files in plugins/work-items/ but shares that changelog and plugin.json, so the version-bump parity gate will collide. The worker is instructed to renumber above whatever main carries at the time and to merge rather than force if a push conflicts.

---

Generated by Claude Code

[kyle-sexton]

Handoff: PR #3830 is open, close-linked and review-ready. Lease released; the merge lane owns it from here.

Two things need a decision before this merges.

1. fix(work-items): scope github sub-issue rollup off the node url #3832 is a duplicate — same defect, same url-derivation, same base SHA, same three files. fix(work-items): scope GitHub sub-issues by url, not the absent repository field #3830 is canonical by lowest-number convention, but that is a tiebreak and yours to overrule. fix(work-items): scope github sub-issue rollup off the node url #3832 carries live gh 2.97.0 evidence (now ported here with attribution) but rests on a false premise about cross-repo sub-issues and bumps no version.
2. The acceptance criteria naming live issue numbers were not exercised on this branch — this runner has gh 2.45.0, which predates subIssues. A spot check on a 2.94+ host is still owed.

Worth knowing beyond this issue: because the filter silently returned nothing, any lane reading sub-issues through the tracker could not tell "no children" from "the read failed". Conclusions drawn from list-sub-items or list-frontier --parent before this lands are suspect.

---

Generated by Claude Code