Description
The Daily Regulatory Report (#63513, 2026-09-25) flagged two "critical" cross-report discrepancies — open_issues varying 152→179 (15.1%) and total_prs varying 1000→1900 (47.4%) — and its own workflow prompt (daily-regulatory.md:238) hardcodes open_issues as "SAME SCOPE, should match within 5-10%" across all reports. Live verification shows these aren't real regressions: two source workflows compute a windowed/capped value but label it with a metric name that scratchpad/metrics-glossary.md defines as absolute, all-time, no filter:
.github/workflows/daily-issues-report.md:164 — open_issues = len(df[df['state'] == 'OPEN']), where df is capped to "up to 1000 issues" (line 82). The report's own body ([daily issues] Daily Issues Report - 2026-09-25 #63454) admits this only spans ~5 days when volume is high ("the underlying dataset does not extend back a full 7 or 30 days"). The glossary (scratchpad/metrics-glossary.md:41-53) defines open_issues as "All open issues in repository, no time filter" and explicitly lists Daily Issues Report as a user of that absolute definition..github/workflows/daily-performance-summary.md:209 (rendered as "Total PRs" at line 473) — 'total': len(created_prs), where created_prs is filtered to createdAt >= window_start (a rolling 90-day window, lines 90-102). The glossary (scratchpad/metrics-glossary.md:203-213) defines total_prs as "Total count of pull requests in the repository across all states... no filters applied" and lists Daily Performance Summary as a user of that absolute definition.
Because both workflows silently repurpose an "absolute" glossary metric name for a windowed/capped computation, the Daily Regulatory Report's naive same-name comparison produces false "critical discrepancy" alarms, eroding trust in a monitor that has a good track record of catching real bugs (see prior fixes from regulatory-report findings, e.g. #55519).
Expected Impact
Either fix the two source workflows to compute what the glossary promises (absolute, unfiltered counts) for these specific field names, or rename their windowed variables (e.g. open_issues_in_sample, prs_created_90d) and update scratchpad/metrics-glossary.md to document the intentional scope split — either way, this removes a recurring false-positive class from the Daily Regulatory Report and restores open_issues/total_prs as genuinely comparable across reports.
Suggested Agent
Daily Regulatory Report workflow or a general code-quality/refactor agent — the fix is confined to two .md workflow prompt files plus a glossary doc update.
Estimated Effort
Medium (1-4 hours) — requires deciding rename vs. re-scope for each field, updating both workflow prompts, and syncing scratchpad/metrics-glossary.md.
Data Source
DeepReport Intelligence Briefing analysis run, 2026-09-26 (incremental cycle since prior briefing #63485), cross-referencing Daily Regulatory Report #63513, Daily Issues Report #63454, and Daily Performance Summary #63512.
Generated by 🔬 Deep Report · claude · agent · 226 AIC · ⌖ 9.45 AIC · ⊞ 13K · ◷
Description
The Daily Regulatory Report (#63513, 2026-09-25) flagged two "critical" cross-report discrepancies —
open_issuesvarying 152→179 (15.1%) andtotal_prsvarying 1000→1900 (47.4%) — and its own workflow prompt (daily-regulatory.md:238) hardcodesopen_issuesas "SAME SCOPE, should match within 5-10%" across all reports. Live verification shows these aren't real regressions: two source workflows compute a windowed/capped value but label it with a metric name thatscratchpad/metrics-glossary.mddefines as absolute, all-time, no filter:.github/workflows/daily-issues-report.md:164—open_issues = len(df[df['state'] == 'OPEN']), wheredfis capped to "up to 1000 issues" (line 82). The report's own body ([daily issues] Daily Issues Report - 2026-09-25 #63454) admits this only spans ~5 days when volume is high ("the underlying dataset does not extend back a full 7 or 30 days"). The glossary (scratchpad/metrics-glossary.md:41-53) definesopen_issuesas "All open issues in repository, no time filter" and explicitly lists Daily Issues Report as a user of that absolute definition..github/workflows/daily-performance-summary.md:209(rendered as "Total PRs" at line 473) —'total': len(created_prs), wherecreated_prsis filtered tocreatedAt >= window_start(a rolling 90-day window, lines 90-102). The glossary (scratchpad/metrics-glossary.md:203-213) definestotal_prsas "Total count of pull requests in the repository across all states... no filters applied" and lists Daily Performance Summary as a user of that absolute definition.Because both workflows silently repurpose an "absolute" glossary metric name for a windowed/capped computation, the Daily Regulatory Report's naive same-name comparison produces false "critical discrepancy" alarms, eroding trust in a monitor that has a good track record of catching real bugs (see prior fixes from regulatory-report findings, e.g. #55519).
Expected Impact
Either fix the two source workflows to compute what the glossary promises (absolute, unfiltered counts) for these specific field names, or rename their windowed variables (e.g.
open_issues_in_sample,prs_created_90d) and updatescratchpad/metrics-glossary.mdto document the intentional scope split — either way, this removes a recurring false-positive class from the Daily Regulatory Report and restoresopen_issues/total_prsas genuinely comparable across reports.Suggested Agent
Daily Regulatory Report workflow or a general code-quality/refactor agent — the fix is confined to two
.mdworkflow prompt files plus a glossary doc update.Estimated Effort
Medium (1-4 hours) — requires deciding rename vs. re-scope for each field, updating both workflow prompts, and syncing
scratchpad/metrics-glossary.md.Data Source
DeepReport Intelligence Briefing analysis run, 2026-09-26 (incremental cycle since prior briefing #63485), cross-referencing Daily Regulatory Report #63513, Daily Issues Report #63454, and Daily Performance Summary #63512.