[detection-analysis] Detection Analysis Report — 2026-08-09 #51652
Closed
Replies: 1 comment
|
This discussion has been marked as outdated by Detection Analysis Report. A newer discussion is available at Discussion #52181. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Summary
Analysis window: 2026-08-08 23:30 UTC → 2026-08-09 23:30 UTC (last 24 full hours)
Warning
2 workflows were flagged as misconfigured this run: Q and ESLint Monster. Both run frequently (5 and 7 times respectively in the last 7 days) but have no
gh-aw-detectionfeature configured at all. See the table below for details.Note on the Regular-run success rate: of the 21 "failed" Regular runs, all 21 are
action_required(blocked pending manual approval via the security gate for external/fork-triggered events) — not agent execution failures. Zero Regular runs had a true agent-logic failure. The one true failure in this window (PR Sous Chef, run 31338952148) was in the detection-enabled group and showed no detection-step-specific error signal (genericagent_logic_failure,ErrorCount=0).Comparison Chart
Misconfigured Workflows
gh-aw-detectionunset, >3 runs/7d (nofeaturesblock at all in.github/workflows/q.md)features:\n gh-aw-detection: trueto the workflow frontmatter and recompile (gh aw compile)gh-aw-detectionunset, >3 runs/7d (nofeaturesblock in.github/workflows/eslint-monster.md)features:\n gh-aw-detection: trueto the workflow frontmatter and recompile (gh aw compile)No violations were found for Rule 2 (name-based opt-in expectation — all workflows named with audit/analyzer/report/detector/monitor/inspector already have detection enabled), Rule 3 (detection-step failures), or Rule 4 (alternating detection status within the window).
View All Run Metrics
* AI Moderator, Issue Monster, and Avenger show
detect=falsein this window's run logs only because their agent job did not execute (approval gate or a job-levelif:skip-condition) — their source frontmatter was verified via GitHub MCP to already havegh-aw-detection: trueconfigured correctly. These are not misconfigurations.Aggregate metrics:
View Historical Trend
Insufficient history to render a trend chart this run. The canonical trend cache (
trending/detection/history.jsonl) now holds its first data point (today, 2026-08-09). A trend chart requires 2+ points and will be generated starting with tomorrow's run.Data hygiene note: a differently-named cache file (
trending/detection-metrics/history.jsonl) was found containing a single older record from 2026-08-08 with a different, incompatible schema (missing failure-count fields, and substantially differentregular_runs/regular_avg_tokensvalues). It was not merged into the canonical history to avoid introducing inconsistent trend data. This naming/schema inconsistency should be reconciled in a future update to the trending logic.Recommendations
features: gh-aw-detection: trueto both workflows' frontmatter and recompile, so future runs are properly classified and monitored for detection-step health./tmp/gh-aw/cache-memory/trending/(detection/vsdetection-metrics/) with incompatible schemas — standardize on one path/schema so historical trending can accumulate reliably.detect=falsestatus this window is a run-log artifact (job skipped/blocked), not a real misconfiguration; source frontmatter is already correct.(/content)
All reactions