You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Across this cycle's analysis, five independent recurring reliability/quality bugs were each closed as "fixed" one or more times, yet a fresh check today (2026-08-10) shows every single one is still broken:
Yes — memory/deep-report branch has exactly 1 commit total, dated 2026-04-03. .github/workflows/deep-report.md still writes to the two-level-deep path (/tmp/gh-aw/repo-memory/default/memory/deep-report/) that #51172's own diagnosis says is silently dropped by the *.md file-glob. See companion issue for the concrete fix.
2
Copilot Session Insights: 0 conversation transcripts available
Yes — 2026-08-10 Documentation Noob Test Report: "Engine choice is a fork in the road with no guidance."
That is 5 separate lineages, roughly 25+ historical issue closures combined, none of which produced a durable fix. In at least the repo-memory case (#1), the issue was closed directly with no linked merged PR (timeline API shows event: closed with no source PR) — the fix was never actually implemented, just described and closed.
Why this matters
Each of these closures creates a false "resolved" signal that suppresses re-filing (dedup gates correctly treat "already closed as fixed" as a reason to not re-raise it) — which is exactly the failure mode: the dedup logic that keeps the issue tracker clean is also what lets a falsely-closed bug hide from every subsequent DeepReport/audit cycle until someone happens to read the actual current state (as this cycle did for #1) instead of trusting issue status.
Recommendation
Add a lightweight verification step before any DeepReport-family or specialized-agent workflow closes a self-filed reliability/doc issue as resolved:
Require the closing comment to cite a merged PR/commit SHA that implements the change (not just a description of the intended fix).
For infra-facing bugs specifically (repo-memory, log retention, artifact paths), add a same-cycle or next-cycle automated re-check of the actual artifact/state (e.g., "does the target branch have a new commit", "does access.log exist in the next sampled run") before allowing the tracking issue to be closed, rather than closing on the strength of a plan description alone.
For docs bugs that keep regressing, consider a lint/test that fails CI if Quick Start renders without a Glossary link on first use of a tracked jargon list, so the fix can't silently not-land the way rejig docs #1 didn't.
Data sources
DeepReport Intelligence Briefing analysis, 2026-08-10 — cross-referenced discussions #51110, #51172 (deep-report), #51111 (deep-report), #51725 (copilot-session-insights), #51654 (observability), #51678 (docs-noob-tester), plus gh api search/issues history back to Feb 2026.
Suggested Agent: New Agent (or extend audit-workflows/deep-report closing logic) Estimated Effort: Medium (1-4 hours) for the verification-gate change; the underlying bugs themselves are separate, larger efforts.
Generated by 🔬 Deep Report · agent · 237.7 AIC · ⌖ 55.3 AIC · ⊞ 11.3K · ◷
Across this cycle's analysis, five independent recurring reliability/quality bugs were each closed as "fixed" one or more times, yet a fresh check today (2026-08-10) shows every single one is still broken:
memory/deep-reportbranch has exactly 1 commit total, dated 2026-04-03..github/workflows/deep-report.mdstill writes to the two-level-deep path (/tmp/gh-aw/repo-memory/default/memory/deep-report/) that #51172's own diagnosis says is silently dropped by the*.mdfile-glob. See companion issue for the concrete fix.access.log/gateway.jsonlmissing)access.log, 0/2 MCP runs havegateway.jsonl/rpc-messages.jsonl(0.0% coverage both categories).That is 5 separate lineages, roughly 25+ historical issue closures combined, none of which produced a durable fix. In at least the repo-memory case (#1), the issue was closed directly with no linked merged PR (
timelineAPI showsevent: closedwith nosourcePR) — the fix was never actually implemented, just described and closed.Why this matters
Each of these closures creates a false "resolved" signal that suppresses re-filing (dedup gates correctly treat "already closed as fixed" as a reason to not re-raise it) — which is exactly the failure mode: the dedup logic that keeps the issue tracker clean is also what lets a falsely-closed bug hide from every subsequent DeepReport/audit cycle until someone happens to read the actual current state (as this cycle did for #1) instead of trusting issue status.
Recommendation
Add a lightweight verification step before any DeepReport-family or specialized-agent workflow closes a self-filed reliability/doc issue as resolved:
access.logexist in the next sampled run") before allowing the tracking issue to be closed, rather than closing on the strength of a plan description alone.Data sources
DeepReport Intelligence Briefing analysis, 2026-08-10 — cross-referenced discussions #51110, #51172 (deep-report), #51111 (deep-report), #51725 (copilot-session-insights), #51654 (observability), #51678 (docs-noob-tester), plus
gh api search/issueshistory back to Feb 2026.Suggested Agent: New Agent (or extend
audit-workflows/deep-reportclosing logic)Estimated Effort: Medium (1-4 hours) for the verification-gate change; the underlying bugs themselves are separate, larger efforts.