[Fleet Monitor] petry-projects/.github-private — issue-triage-runner.yml

[don-petry]

🔴 CRITICAL: petry-projects/.github-private / issue-triage-runner.yml

Metric	Value
Failure Rate	100% (11 / 11 runs)
Status	CRITICAL
p50 Duration	554s
p95 Duration	644s
Successful Runs	0
Cancelled Runs	0

Workflow: issue-triage-runner.yml

Last updated by Fleet Monitor run on 2026-05-27.
Threshold: failure rate > 10% over the monitored window.

[don-petry]

Dev-Lead Implementation Plan

Issue: #401 — [Fleet Monitor] petry-projects/.github-private — issue-triage-runner.yml

Root Cause

aw.sh safe-output apply reads allowed-labels as a flat top-level frontmatter key, but issue-triage.md stores the allowed labels under safe-outputs.add-labels.allowed (a nested gh-aw format). Because the flat key is missing, allowed-labels defaults to [], making every label Claude returns "not in allowed set" — causing 100% rejection in the apply job.

Scope

Add allowed-labels and max-labels as flat top-level keys to the issue-triage.md frontmatter so aw.sh can read them correctly; keep the existing safe-outputs structure for gh aw compile compatibility. Add a test that verifies valid labels pass (not just that invalid labels are rejected).

Implementation Checklist

• tests/aw/issue-triage/test_aw_run.sh — add Test 6: valid labels + comment → "validation passed" (red phase)
• .github/workflows/issue-triage.md — add allowed-labels list and max-labels: 3 as flat top-level frontmatter keys (green phase)

Tests to Write

• Test 6: safe-output apply with {"labels":["bug","needs-triage"],"comment":"..."} → output contains "validation passed"

Test Command

bash tests/aw/issue-triage/test_aw_run.sh

[don-petry]

Dev-Lead: Implementation Complete

Root Cause

aw.sh safe-output apply reads allowed-labels as a flat top-level key from the workflow frontmatter. issue-triage.md only had the label list under safe-outputs.add-labels.allowed (a nested gh-aw format), so fm.get("allowed-labels", []) returned []. With an empty allowed set, every label Claude returned was flagged as "not in allowed set" → sys.exit(1) → 100% failure of the apply job.

Plan Execution

• Posted implementation plan on issue [Fleet Monitor] petry-projects/.github-private — issue-triage-runner.yml #401
• Added Test 6 (red): safe-output apply with valid labels → must see "validation passed" — confirmed failing before fix
• Fixed .github/workflows/issue-triage.md: added allowed-labels list and max-labels: 3 as flat top-level frontmatter keys alongside the existing safe-outputs block (kept for gh aw compile compatibility)
• All 6 tests green; shellcheck and agent-profile lint clean

Test Results

PASS  scenario-4: 2 existing labels → skip=true
PASS  safe-output: 4 labels exceeds max-labels:3 → rejected
PASS  safe-output: disallowed label → rejected
PASS  safe-output: skip flag → no writes
PASS  safe-output: empty comment → rejected
PASS  safe-output: valid allowed labels → validation passed

Results: 6 passed, 0 failed

[lint] shellcheck on 34 file(s)...
[lint] validating 4 agent profile(s)...
[lint] all checks passed

Files Changed

• .github/workflows/issue-triage.md: added allowed-labels (7-item list) and max-labels: 3 as flat top-level frontmatter keys; existing safe-outputs block retained unchanged
• tests/aw/issue-triage/test_aw_run.sh: added Test 6 — verifies valid labels pass safe-output validation (regression guard)

Notes

The existing Test 2 ("4 labels exceeds max-labels:3 → rejected") was already passing before this fix, but for the wrong reason — all 4 labels were rejected as "not in allowed set" rather than for exceeding the count limit. After the fix it rejects correctly with "more than 3 labels". The safe-outputs nested block is kept in place because gh aw compile (used in lint.yml) may rely on that format; the two representations are consistent.