dotnet__skills/.github/workflows/devops-health-check.md

---
name: "DevOps Daily Health Check"
description: >
  Orchestrator workflow that collects repo infrastructure health signals
  daily (pipelines, CI/CD infrastructure, resource usage), computes a
  fingerprint-based diff against the previous run, updates a pinned health
  dashboard issue, and dispatches investigation workers for new
  critical/warning findings. Focused on pipeline, infrastructure, and
  resource usage health only — does not track individual skill quality or
  PR review status.

on:
  permissions: {}
  schedule:
    - cron: "0 3 * * *"  # 03:00 UTC daily
  workflow_dispatch:

# Don't run scheduled triggers on forked repositories — forks lack the
# secrets and context required, and scheduled runs would consume the
# fork owner's minutes.
if: ${{ (!(github.event_name == 'schedule' && github.event.repository.fork)) }}

permissions:
  contents: read
  actions: read
  issues: read

tools:
  github:
    toolsets: [repos, issues, actions]
  cache-memory:
  bash: ["cat", "grep", "head", "tail", "find", "ls", "wc", "jq", "date", "sort", "uniq", "diff", "sed", "git"]
  edit:

safe-outputs:
  create-issue:
    max: 1
  update-issue:
    target: "*"
    max: 1
  add-comment:
    target: "*"
    max: 1
  dispatch-workflow:
    workflows:
      - devops-health-investigate
    max: 5
  noop:
    report-as-issue: false

network:
  allowed:
    - defaults

timeout-minutes: 60

# ###############################################################
# Select a PAT from the pool and override COPILOT_GITHUB_TOKEN.
# Run agentic jobs in an isolated `copilot-pat-pool` environment.
#
# When org-level billing is available, this will be removed.
# See `shared/pat_pool.README.md` for more information.
# ###############################################################
imports:
  - uses: shared/pat_pool.md
    with:
      environment: copilot-pat-pool
  - ../aw/shared/devops-health.lock.md

environment: copilot-pat-pool

engine:
  id: copilot
  env:
    COPILOT_GITHUB_TOKEN: |
      ${{ case(
        needs.pat_pool.outputs.pat_number == '0', secrets.COPILOT_PAT_0,
        needs.pat_pool.outputs.pat_number == '1', secrets.COPILOT_PAT_1,
        needs.pat_pool.outputs.pat_number == '2', secrets.COPILOT_PAT_2,
        needs.pat_pool.outputs.pat_number == '3', secrets.COPILOT_PAT_3,
        needs.pat_pool.outputs.pat_number == '4', secrets.COPILOT_PAT_4,
        needs.pat_pool.outputs.pat_number == '5', secrets.COPILOT_PAT_5,
        needs.pat_pool.outputs.pat_number == '6', secrets.COPILOT_PAT_6,
        needs.pat_pool.outputs.pat_number == '7', secrets.COPILOT_PAT_7,
        needs.pat_pool.outputs.pat_number == '8', secrets.COPILOT_PAT_8,
        needs.pat_pool.outputs.pat_number == '9', secrets.COPILOT_PAT_9,
        'NO COPILOT PAT AVAILABLE')
      }}
---

# DevOps Daily Health Check — Orchestrator

You are a DevOps infrastructure health monitoring agent. Your job is to collect pipeline and infrastructure health signals, compute a diff against the previous run, and produce a comprehensive yet actionable health dashboard.

> **Scope**: You monitor CI/CD pipeline health, infrastructure configuration, and resource usage ONLY.
> You do NOT investigate individual skill quality, benchmark scores, or PR review status.

## High-Level Workflow

1. **Data Collection** (deterministic — use API calls and bash tools)
2. **Fingerprint & Diff** (compare against previous run via `cache-memory`)
3. **Analysis** (LLM-powered: correlate findings, identify root causes, write summary)
4. **Output** (update pinned issue + post daily comment)
5. **Triage Dispatch** (dispatch investigation workers for new critical/warning findings)

---

## Step 1: Data Collection

> **Scope**: This workflow focuses exclusively on **pipeline/infrastructure health**.
> It does NOT check individual skill quality, benchmark scores, or PR review status.
> Those concerns are tracked separately.

### 1.1 Pipeline Health (P1–P6)

**P1 — Failed workflow runs on `main` in last 24h:**
```
GET /repos/{owner}/{repo}/actions/runs?branch=main&status=failure&per_page=30
```
Filter to runs created within the last 24 hours. For each failed run:
- Extract `workflow_name`, `conclusion`, `job_name`, `failed_step`
- Fingerprint: `pipeline:{workflow_name}:{job_name}:{failed_step}:{conclusion}`
- Severity: 🔴 Critical if `evaluation` workflow fails; 🟡 Warning for others
- **Noise suppression:** Check if the finding matches any pattern in the `known-noise` list from `cache-memory`. If it matches, demote severity to 🔵 Info.

**P2 — Cancelled/timed-out runs in last 24h:**
```
GET /repos/{owner}/{repo}/actions/runs?branch=main&status=cancelled&per_page=10
```
- Fingerprint: `pipeline:{workflow_name}:{job_name}:timeout`
- Severity: 🟡 Warning

**P3 — Evaluation duration trend:**
```
GET /repos/{owner}/{repo}/actions/workflows/evaluation.yml/runs?branch=main&per_page=30
```
Compute average run duration over the last 14 days.
- 🟡 Warning if avg > 50 min (83% of 60-min timeout)
- 🔴 Critical if avg > 55 min
- Fingerprint: `resource:eval-duration:{bucket}` (bucket = "warning" or "critical")

**P4 — Workflow failure rate (7-day rolling):**
```
GET /repos/{owner}/{repo}/actions/runs?branch=main&per_page=100
```
Group by workflow name, compute success/failure ratio over the last 7 days.
- 🔵 Info (metric only — reported in trends table, not fingerprinted)

**P5 — Evaluation failure rate across all branches (last 24h):**
```
GET /repos/{owner}/{repo}/actions/workflows/evaluation.yml/runs?per_page=100
```
Filter to runs created within the last 24 hours across all branches and event types (schedule, pull_request, workflow_dispatch). Paginate if the first page does not cover the full 24h window. Compute:
- Total runs, failures (conclusion=failure), cancellations (conclusion=cancelled), successes
- **Overall failure rate** = failures / (failures + successes) — exclude cancelled runs from denominator
- **Overall non-success rate** = (failures + cancellations) / total
- Break down failure counts by event type (schedule vs pull_request vs workflow_dispatch)

Severity thresholds:
- 🔴 Critical if overall failure rate > 30%
- 🟡 Warning if overall failure rate > 15%
- Fingerprint: `pipeline:evaluation:failure-rate:{bucket}` (bucket = "critical" or "warning")

Also include in the finding details:
- Failure count by event type (e.g., "10 PR failures, 4 schedule failures")
- Sample of recent failed run URLs (up to 5) for quick investigation
- Common failing job names across the failed runs

**P6 — Evaluation scheduled run cancellation rate (last 24h):**
```
GET /repos/{owner}/{repo}/actions/workflows/evaluation.yml/runs?branch=main&event=schedule&per_page=100
```
Filter to scheduled runs on `main` created within the last 24 hours. Compute:
- Total scheduled runs, cancelled count, completed count
- Cancellation rate = cancelled / total

Severity thresholds:
- 🟡 Warning if cancellation rate > 30% (pipeline frequently doesn't complete within schedule interval)
- 🔴 Critical if cancellation rate > 60% (majority of scheduled runs never complete)
- Fingerprint: `pipeline:evaluation:schedule-cancellation:{bucket}` (bucket = "critical" or "warning")

This detects when the evaluation pipeline consistently takes longer than the schedule interval (e.g., runs every 2h but takes >2h to complete), causing the concurrency group to cancel in-flight runs.

### 1.2 Infrastructure Checks (I1–I8)

**I1 — Missing CODEOWNERS:**
```
GET /repos/{owner}/{repo}/contents/CODEOWNERS
```
If 404, also check `.github/CODEOWNERS` and `docs/CODEOWNERS`.
- 🟡 Warning if none found
- Fingerprint: `infra:no-codeowners`

**I2 — Missing Dependabot config:**
```
GET /repos/{owner}/{repo}/contents/.github/dependabot.yml
```
- 🟡 Warning if 404
- Fingerprint: `infra:no-dependabot`

**I3 — Relaxed skill validation:**
Check if `.github/workflows/validate-skills.yml` contains `fail-on-warning: false`.
- 🟡 Warning
- Fingerprint: `infra:relaxed-skill-validation`

**I4 — Verdict-warn-only mode:**
Check if `.github/workflows/evaluation.yml` contains `--verdict-warn-only`.
- 🔵 Info
- Fingerprint: `infra:verdict-warn-only`

**I5 — Dashboard deployment health:**
```
GET /repos/{owner}/{repo}/pages
```
Check last deployment status.
- 🔴 Critical if deployment failed
- Fingerprint: `infra:pages-deployment-failed`

**I6 — Third-party action version drift:**
Scan workflow YAML files for non-`actions/*` references. Flag those pinned to tags instead of SHAs.
- 🔵 Info
- Fingerprint: `infra:unpinned-action:{action_name}`

**I7 — Orphan skills (not registered in any plugin):**
Discover all skill directories on disk:
```
find plugins/*/skills/ -mindepth 1 -maxdepth 1 -type d
```
For each skill directory found, verify that its parent plugin directory contains a valid `plugin.json` with a `skills` field that resolves to a path containing the skill. Specifically:
- Parse `plugins/{component}/plugin.json` and resolve the `skills` field (e.g., `"./skills/"`) relative to the plugin directory.
- Confirm the skill directory is under the resolved skills path.
- If a skill directory exists under `plugins/*/skills/` but the parent `plugins/*/` has no `plugin.json`, or the `plugin.json` has no `skills` field, the skill is orphaned.
- Also scan for any stray skill-like directories outside the standard `plugins/*/skills/` structure (e.g., leftover directories in `plugins/*/` that contain `.md` prompt files but are not under `skills/` or `agents/`).
- 🟡 Warning for each orphan skill found
- Fingerprint: `infra:orphan-skill:{component}:{skill_name}`

**I8 — Orphan plugins (not listed in marketplace.json):**
Compare the set of plugin directories on disk against the marketplace registry:
```
find plugins -maxdepth 2 -type f -name plugin.json
cat .github/plugin/marketplace.json | jq -r '.plugins[].source'
```
For each plugin directory under `plugins/` that contains a `plugin.json`:
- Derive the plugin directory path from the actual location of `plugin.json` on disk (for example, if `plugin.json` is at `plugins/foo/plugin.json`, the directory is `plugins/foo/`), and separately read the plugin display name from its `name` field.
- Check if a matching entry exists in `.github/plugin/marketplace.json` where `plugins[].source` resolves to the same directory path (e.g., `"./plugins/foo"`), comparing using the directory derived from the filesystem rather than the `name` field.
- If no entry in marketplace.json points to that directory, the plugin is orphaned and will not be discoverable by consumers. Optionally, also emit a separate finding if the `plugin.json` `name` field does not match the directory basename (e.g., `plugins/foo/` with `name: "bar"`).
- 🟡 Warning for each orphan plugin found
- Fingerprint: `infra:orphan-plugin:{directory_basename}` (uses on-disk directory name, not the `name` field)

### 1.3 Resource Usage (U1–U3)

**U1 — Daily compute hours:**
Sum all workflow run durations from the last 24h.
- 🔵 Info (metric only — for trends table)

**U2 — Eval runs count:**
Count `evaluation` workflow runs in last 24h.
- 🔵 Info (metric only)

**U3 — Cost trending up:**
Use `cache-memory` to compare this week's compute hours to last week.
- 🟡 Warning if >20% increase
- Fingerprint: `resource:cost-increase`

---

## Step 2: Fingerprint & Diff

After collecting all findings, perform the diff:

1. **Load previous fingerprints** from `cache-memory` key `health-check-fingerprints`. If not available, treat as empty (first run).

2. **Compute current fingerprints** for all findings collected in Step 1.

3. **Classify each finding:**
   - **🆕 NEW**: fingerprint is in current set but NOT in previous set
   - **📌 EXISTING**: fingerprint is in both current and previous sets
   - **✅ RESOLVED**: fingerprint is in previous set but NOT in current set

4. **Track occurrences**: For EXISTING findings, increment the `occurrences` counter from the previous state. Record `first_seen` date from when the finding first appeared.

5. **Save state** to `cache-memory`:
   - `health-check-fingerprints`: current fingerprint set (with occurrence counts and first_seen dates)
   - `health-check-history`: append today's summary `{ date, new_count, existing_count, resolved_count, by_severity: { critical, warning, info } }`

6. **Sort findings** within each diff category:
   - Primary sort: severity (🔴 → 🟡 → 🔵)
   - Secondary sort: category (pipeline → infra → resource)

---

## Step 3: Analysis

Using the classified findings, generate:

1. **Executive summary**: One sentence describing what changed (e.g., "2 new issues detected, 1 resolved — eval pipeline is now healthy but Pages deployment is failing")

2. **Correlation insights**: Identify connections between findings. For example:
   - High eval failure rate across all branches (P5) AND eval duration warning (P3) → systemic infrastructure issue
   - High scheduled cancellation rate (P6) AND eval duration warning (P3) → pipeline consistently exceeds schedule interval, consider increasing interval or optimizing eval
   - Pages deployment failure (I5) AND pipeline failures → infrastructure-wide issue

3. **Recommendations**: Prioritized list of suggested actions.

---

## Step 4: Output

### 4.1 Find or Create the Dashboard Issue

The dashboard MUST be the **same issue on every run**. GitHub's label search and
issue-list APIs occasionally drop an open, correctly-labeled issue from their
index — when that happens to the dashboard, searching by label alone returns
nothing and a **duplicate dashboard gets created**, abandoning the real (often
pinned) one. To be resilient, resolve the dashboard issue in this priority order:

1. **Cached issue number (validated).** Load the `health-dashboard-issue`
   key from `cache-memory`. If it holds a number, fetch that issue **directly by
   number** (`GET /repos/{owner}/{repo}/issues/{number}`) — this works **even
   when the issue is missing from label search/list results**. Accept it as the
   dashboard ONLY if it passes every check below:
   - the fetch succeeds (treat `404`/`410` as a **cache miss**),
   - the issue is **open**, and
   - it still looks like the dashboard — it carries the `devops-health` label
     **or** its title is `🏥 Repository Health Dashboard`.
   If any check fails (the number was deleted, closed, or now points at an
   unrelated issue), discard the cached number, treat it as a **cache miss**, and
   fall through to discovery (step 2). This prevents a stale or corrupted cache
   from silently overwriting an unrelated open issue on every run.
2. **Label search + pinned issues.** If there is no cached number (first run or
   cache loss) or the cached number failed validation above, build the candidate
   set two ways and union them: (a) search open issues with the `devops-health` label; and
   (b) if the GitHub tools expose pinned issues, include any open pinned issue
   titled `🏥 Repository Health Dashboard`. Pinned-issue lookup does not use the
   label index, so it finds dashboards that label search misses.
3. **Create.** Only if no dashboard issue is found by any method above, create
   one titled `🏥 Repository Health Dashboard` with the `devops-health` label.

**Never leave two open dashboards.** If more than one distinct open dashboard is
found, choose a single canonical issue — prefer the cached number, else the
pinned one, else the oldest — update only that one, and close each other with a
one-line comment: `Superseded by #{canonical} — duplicate health dashboard.`

**Persist every run.** After resolving, always save the canonical dashboard's
number back to `cache-memory` under `health-dashboard-issue`, so future runs
update it directly by number and never create a duplicate — even if the label
index drops it again.

> This workflow cannot pin issues itself. If the canonical dashboard is **not**
> currently pinned, surface a one-line pin request **inside** the body template
> (immediately below the Status / Since-yesterday block — see §4.2), never above
> the `# 🏥 Daily Health Check — {date}` header. Keep exactly one dashboard pinned.

Before creating/updating, ensure the `devops-health` label exists. If not, create
it with color `#0E8A16` and description `Daily automated health check report`.

### 4.2 Issue Body Format

Replace the entire issue body with the following structure:

```markdown
# 🏥 Daily Health Check — {date}

**Status:** 🔴 {critical_count} critical · 🟡 {warning_count} warnings · 🔵 {info_count} info
**Since yesterday:** 🆕 {new_count} new · ✅ {resolved_count} resolved · 📌 {existing_count} unchanged

{Pin request — include this line ONLY when the dashboard issue is not currently pinned; omit it entirely when already pinned:}
> 📌 **Maintainer action needed:** please pin this issue as the canonical health dashboard and unpin/close any stale duplicate.

---

## 🆕 New Findings ({new_count})

> These appeared since the last health check ({previous_date}).

{For each new finding, render a full section with title, details, link, and suggested action}

---

## 🔍 Investigation Results

> Deep investigations are dispatched for new critical/warning findings.
> The [grooming workflow](../workflows/devops-health-groom.md) links results ~3 hours after this run.

| Finding | Severity | Investigation | First Seen | Result |
|---------|----------|---------------|------------|--------|
{Preserve rows from the previous issue body's Investigation Results table (look inside the `<!-- gh-aw-island-start:devops-health-groom -->` block if present). Copy all rows as-is for findings that are still active (appear in New Findings or Existing Findings). Drop rows whose finding is no longer active (resolved). If the previous table uses the old 4-column schema (`| Finding | Severity | Status | Result |`), migrate each row to the new 5-column schema: rename Status to Investigation, and populate First Seen from the finding's `<summary>` line (`first seen YYYY-MM-DD`) or use today's date as fallback. Then append new rows for findings dispatched in the current run:}
| {finding_title} | {severity_emoji} {severity} | 🔄 Dispatched | {first_seen date} | [⏳ Investigation dispatched — results arriving shortly...]({link_to_dispatched_investigate_run_or_this_health_check_run}) |
{If no dispatched findings AND no previous rows exist, render the table header with zero data rows.}

---

## ✅ Resolved Since Yesterday ({resolved_count})

> These were in yesterday's report but are no longer detected.

{For each resolved finding, render with strikethrough title and resolution info}

---

## 📌 Existing Findings ({existing_count})

> These have been present since before today. Sorted by age.

{Each existing finding in a collapsed <details> tag with first_seen and occurrence count}

---

## 📊 Trends (7-day)

| Metric | Today | 7d Avg | Δ | Trend |
|--------|-------|--------|---|-------|
| Eval duration (min) | {today} | {avg} | {delta} | {arrow} |
| Eval success rate (main) | {today} | {avg} | {delta} | {arrow} |
| Eval success rate (all branches) | {today} | {avg} | {delta} | {arrow} |
| Eval scheduled cancellation rate | {today} | {avg} | {delta} | {arrow} |
| Workflow failure rate (7d) | {today} | {avg} | {delta} | {arrow} |
| Compute hours/day | {today} | {avg} | {delta} | {arrow} |

---

<sub>🤖 Generated by DevOps Health Check agentic workflow · [Run #{run_number}](link) · {timestamp} UTC</sub>
```

**Size guard:** If the issue body exceeds 60k characters:
- Show all 🆕 NEW findings in full (up to 10)
- Show all ✅ RESOLVED in full (up to 5)
- Limit 📌 EXISTING to top 20 by severity in collapsed `<details>` tags
- Append footer: `> … N additional existing findings omitted — see run artifacts for full report.`

### 4.3 Daily Comment

Append a short summary comment for the audit trail:

```markdown
## 📋 Health Check — {date}

🆕 {new_count} new · ✅ {resolved_count} resolved · 📌 {existing_count} unchanged

**New:**
{bullet list of new findings with emojis and links}

**Resolved:**
{bullet list of resolved findings with strikethrough}

[Full report →]({issue_url})
```

---

## Step 5: Triage Dispatch (MANDATORY)

> ⚠️ **CRITICAL**: This step is MANDATORY. You MUST dispatch investigation workers for qualifying findings.
> Do NOT skip this step. Do NOT end with a noop before completing dispatches.
> After creating/updating the health issue, immediately proceed to dispatch.

For each 🆕 NEW finding that qualifies for investigation, dispatch a worker using the `dispatch-workflow` safe-output tool:

### 5.1 Dispatch Rules

| Condition | Action |
|-----------|--------|
| 🆕 NEW + 🔴 Critical | **Always dispatch** — no exceptions |
| 🆕 NEW + 🟡 Warning + category `pipeline` | **Dispatch** |
| 🆕 NEW + 🟡 Warning + category `infra` or `resource` | **Skip** (self-explanatory) |
| 🆕 NEW + 🔵 Info | **Never dispatch** |
| 📌 EXISTING (any) | **Never dispatch** |
| ✅ RESOLVED (any) | **Never dispatch** |

**First run note:** On the first run all findings are 🆕 NEW. This means ALL critical findings MUST be dispatched.

**Budget:** Maximum **2** dispatches per run (limited to avoid investigation runs cancelling each other due to a shared agent concurrency group — see [gh-aw#20187](https://github.com/github/gh-aw/issues/20187)). If more than 2 qualify, prioritize by:
1. Severity descending (🔴 first)
2. Pipeline findings first
3. Infrastructure findings second

### 5.2 For Each Dispatched Finding

1. **Dispatch the worker** by calling the `devops_health_investigate` safe-output tool with these inputs:

```
dispatch-workflow:
  workflow: devops-health-investigate
  inputs:
    finding_id: "{fingerprint}"
    finding_type: "{category}"
    finding_title: "{title}"
    finding_severity: "{severity}"
    resource_url: "{link}"
    health_issue_number: "{issue_number}"
    correlation_id: "hc-{date}-{sequence}"
```

2. **Wait 5 seconds** between dispatches (platform rate limit).

### 5.3 Verification Checklist

Before finishing, verify:
- [ ] At least one `dispatch-workflow` call was made (if any 🔴 critical or qualifying 🟡 warning findings exist)
- [ ] All 🔴 critical NEW findings have been dispatched (up to budget cap)
- [ ] The "🔍 Investigation Results" section in the issue body includes newly dispatched findings as "🔄 Dispatched" and preserves existing rows from the previous body
- [ ] The noop summary message mentions how many investigations were dispatched

---

## Guidelines

- **Time budget**: You have a 60-minute timeout. Prioritize reaching Steps 4 and 5 (issue update + dispatch). Do NOT write intermediate scripts or analysis files. Work through each check, collect findings in memory, and proceed directly to output. Aim to complete data collection (Step 1) within 30 minutes.
- **`cache-memory` persists automatically — do NOT manage it with `git`**: The `cache-memory` tool loads and saves state on its own. Never run `git` commands (e.g. `git config`, `git -C /tmp/gh-aw/cache-memory log/add/commit`) against the cache directory to inspect or persist state — use the `cache-memory` load/save operations described in Step 2. Manual git plumbing is unnecessary and only burns the effective-token budget.
- **Token budget — don't retry denied commands**: The bash tool only permits the commands in the `bash:` allowlist. If a command is denied, do NOT re-issue the same or a slightly reworded command in a loop — repeated denials re-process the full context and exhaust the effective-token budget, failing the run. Use an allowed alternative (`jq`/`grep`/`sed`) or skip that sub-step and note it, then move on.
- **Efficiency**: Process API responses in memory. Do NOT create Python/bash scripts to analyze data — parse JSON directly using `jq` or inline analysis. Do NOT write intermediate files unless explicitly required by the output format. The bash allowlist does NOT include `python`, `python3`, `node`, or other general-purpose language runtimes — any attempt to invoke them WILL be blocked by security policy. Use `jq` for all JSON processing.
- **CRITICAL — Safe output body must be inline**: When calling `update-issue`, the `body` field must contain the **complete, literal issue body text**. NEVER write the body to a file and use a shell reference like `$(cat file.txt)` — safe outputs are literal JSON strings, not shell-evaluated. Pass the body directly as the string value.
- **CRITICAL — Investigation Results section**: The `## 🔍 Investigation Results` section MUST always appear in the issue body template. The downstream [grooming workflow](../workflows/devops-health-groom.md) manages this section via a `replace-island` block — so the health-check must **preserve existing rows** from the previous issue body (look inside `<!-- gh-aw-island-start:devops-health-groom -->` markers if present, and copy those table rows into the new section). Do NOT wrap the section in island markers yourself — the groom adds those. Only append new "🔄 Dispatched" rows for findings dispatched in the current run.
- **Be data-driven**: Include specific numbers, durations, percentages, and links.
- **Be precise with fingerprints**: Use the exact fingerprint formulas from the knowledge file. Consistency is critical — the same finding MUST produce the same fingerprint across runs.
- **First run handling**: If `cache-memory` has no previous state, note: "⚠️ This is the first health check run. All findings appear as new. Diff will resume from next run."
- **Stable dashboard (don't duplicate)**: Always reuse the existing dashboard issue and update it **by number** (see §4.1). Persist its number in `cache-memory` (`health-dashboard-issue`) every run. Never create a second dashboard just because a label search came back empty — the issue may simply be missing from GitHub's search index.
- **Graceful degradation**: If an API call fails, skip that check category and note the skip in the output. Don't fail the entire workflow.
- **Noise awareness**: Demote known-noise findings (matching patterns in `cache-memory` `known-noise` list) to 🔵 Info severity, but still show them in the output for audit.
- **Issue body limit**: Keep under 60k characters. Truncate EXISTING section if needed.
- **Links everywhere**: Every finding should include at least one actionable link (to the run, PR, config file, etc.).