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
Analysis window: 2026-08-08 23:30 UTC → 2026-08-09 23:30 UTC (last 24 full hours)
Metric
Value
Total workflow runs
39
Detection-enabled runs
11 (28.2%)
Regular runs
28 (71.8%)
Detection success rate
90.9%
Regular success rate
25.0%
Misconfigured workflows
2
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-detection feature 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 (generic agent_logic_failure, ErrorCount=0).
Comparison Chart
Misconfigured Workflows
Workflow
Misconfiguration Type
Runs (7d)
Recommended Fix
Q
Rule 1: gh-aw-detection unset, >3 runs/7d (no features block at all in .github/workflows/q.md)
5
Add features:\n gh-aw-detection: true to the workflow frontmatter and recompile (gh aw compile)
ESLint Monster
Rule 1: gh-aw-detection unset, >3 runs/7d (no features block in .github/workflows/eslint-monster.md)
7
Add features:\n gh-aw-detection: true to 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
Workflow
Engine
Detection
Runs (24h)
Outcomes
PR Sous Chef
pi
✅ true
7
6 success, 1 failure
Agentic Workflow Audit Agent
claude
✅ true
1
1 success
Daily Regulatory Report Generator
copilot
✅ true
1
1 success
Duplicate Code Detector
codex
✅ true
1
1 success
Daily AWF Spec Compiler Surfacing Review
pi
✅ true
1
1 success
AI Moderator
—
❌ false*
12
12 action_required (blocked, not failed)
Q
—
❌ false (misconfigured)
9
9 action_required (blocked, not failed)
Issue Monster
—
❌ false*
4
4 success
Avenger
—
❌ false*
2
2 success
ESLint Monster
pi
❌ false (misconfigured)
1
1 success
* AI Moderator, Issue Monster, and Avenger show detect=false in this window's run logs only because their agent job did not execute (approval gate or a job-level if: skip-condition) — their source frontmatter was verified via GitHub MCP to already have gh-aw-detection: true configured correctly. These are not misconfigurations.
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 different regular_runs/regular_avg_tokens values). 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
Fix Q and ESLint Monster: add features: gh-aw-detection: true to both workflows' frontmatter and recompile, so future runs are properly classified and monitored for detection-step health.
Reconcile the trending cache: two divergent history files exist under /tmp/gh-aw/cache-memory/trending/ (detection/ vs detection-metrics/) with incompatible schemas — standardize on one path/schema so historical trending can accumulate reliably.
No action needed on AI Moderator, Issue Monster, or Avenger — their apparent detect=false status this window is a run-log artifact (job skipped/blocked), not a real misconfiguration; source frontmatter is already correct.
Monitor PR Sous Chef's single failure (run 31338952148) — no detection-specific error was found, but keep an eye out if failures recur, since it's the workflow with the most detection-enabled runs (7) in this window.
(/content)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
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