Description
issue-arborist.md's data-fetch step (.github/workflows/issue-arborist.md:51) uses gh issue list --search "-parent-issue:*" intending to exclude issues that already have a parent, per the comment on line 48-49 ("Fetch the last 100 open issues that don't have a parent issue"). parent-issue: is not a real GitHub issue-search qualifier, so the filter is a silent no-op — the fetch pulls parented issues anyway.
This was caught live by the 2026-10-09 Issue Arborist run (discussion #67116): of the 100 "open issues without a parent" supplied to the agent, at least 7 already had confirmed parents (#66865–#66869 under #66862, #67044 under #67042), despite the search filter.
Expected Impact
Removes false-positive candidates from cluster/parent-child detection, so the agent spends its budget on genuinely orphaned issues instead of re-discovering links GitHub already has. Improves the accuracy of the issues_analyzed eval metric, which currently claims a scope ("open issues without parent") the fetch doesn't actually deliver.
Suggested Fix
Replace or supplement the -parent-issue:* search qualifier with a post-fetch filter: GitHub's REST/GraphQL issue APIs expose sub-issue parent info (e.g. via the issue's sub_issue_summary/parent relationship) that gh issue list --json doesn't currently surface in this query's field list. Either fetch with the fields needed to detect a parent and filter client-side with jq, or drop the ineffective search qualifier and rely entirely on a client-side filter.
Suggested Agent
issue-arborist workflow itself, or a developer touching .github/workflows/issue-arborist.md.
Estimated Effort
Quick (< 1 hour) — isolated to the single Fetch issues step in .github/workflows/issue-arborist.md.
Data Source
DeepReport Intelligence analysis, cycle following discussion #67076 (previous briefing) and #67116 (Issue Arborist Daily Report, 2026-10-09), which surfaced the parent-leak directly.
Generated by 🔬 Deep Report · claude · agent · 160.3 AIC · ⌖ 4.29 AIC · ⊞ 7.1K · ◷
Description
issue-arborist.md's data-fetch step (.github/workflows/issue-arborist.md:51) usesgh issue list --search "-parent-issue:*"intending to exclude issues that already have a parent, per the comment on line 48-49 ("Fetch the last 100 open issues that don't have a parent issue").parent-issue:is not a real GitHub issue-search qualifier, so the filter is a silent no-op — the fetch pulls parented issues anyway.This was caught live by the 2026-10-09 Issue Arborist run (discussion #67116): of the 100 "open issues without a parent" supplied to the agent, at least 7 already had confirmed parents (#66865–#66869 under #66862, #67044 under #67042), despite the search filter.
Expected Impact
Removes false-positive candidates from cluster/parent-child detection, so the agent spends its budget on genuinely orphaned issues instead of re-discovering links GitHub already has. Improves the accuracy of the
issues_analyzedeval metric, which currently claims a scope ("open issues without parent") the fetch doesn't actually deliver.Suggested Fix
Replace or supplement the
-parent-issue:*search qualifier with a post-fetch filter: GitHub's REST/GraphQL issue APIs expose sub-issue parent info (e.g. via the issue'ssub_issue_summary/parent relationship) thatgh issue list --jsondoesn't currently surface in this query's field list. Either fetch with the fields needed to detect a parent and filter client-side withjq, or drop the ineffective search qualifier and rely entirely on a client-side filter.Suggested Agent
issue-arboristworkflow itself, or a developer touching.github/workflows/issue-arborist.md.Estimated Effort
Quick (< 1 hour) — isolated to the single
Fetch issuesstep in.github/workflows/issue-arborist.md.Data Source
DeepReport Intelligence analysis, cycle following discussion #67076 (previous briefing) and #67116 (Issue Arborist Daily Report, 2026-10-09), which surfaced the parent-leak directly.