Fleet Triage

Fleet Triage

Cognitive triage of fleet-managed issues. The audit scan surfaces findings deterministically; you make the judgment calls.

When to Use

• After running fleet audit scan and seeing cognitive findings
• Before running fleet dispatch to prevent wasting sessions on non-actionable issues
• When asked to triage, clean up, or review fleet issues

Core Principle

Tools are evidence, you are expertise. The scan tells you what exists. You read the content and decide what to do.

Process

Phase 1: Build a Lightweight Index

Pull all open issues as a summary table. Do NOT read issue bodies yet.

gh issue list --repo <owner>/<repo> --state open --limit 50 \
  --json number,title,labels,milestone

Classify each issue into buckets by title and labels alone:

Record the index in a triage artifact (see Triage Artifact).

Phase 2: Batch Triage from Index

For Insight and Assessment buckets, you can often decide without reading the body:

• Duplicate insights (same title pattern, sequential numbers like "Update 2", "Update 3", "Update 4") → Close older duplicates, keep latest
• Insights with no milestone → Likely orphaned, close
• Assessments with linked PRs → Check if PR is merged; if so, close

Update the triage artifact with decisions.

Phase 3: Deep Dive (One at a Time)

For Ambiguous or Execution issues only:

gh issue view <N> --repo <owner>/<repo>

Read the body. Evaluate:

1. Is there actionable code work? Look for "Files to modify:", "Proposed Implementation", specific code paths
2. Is it stale? Has the work already been done by another PR? Check linked PRs
3. Are the labels accurate? Does an "Execution" issue actually describe an insight?
4. Should it be dispatched? Only if there's concrete code work with clear acceptance criteria

Record your decision in the triage artifact before moving to the next issue.

Phase 4: Apply Decisions

After all decisions are recorded, present the triage artifact to the user for review. Then apply:

# Close issues
gh issue close <N> --repo <owner>/<repo> --comment "Closing: <reason>"

# Relabel
gh issue edit <N> --repo <owner>/<repo> --remove-label fleet --add-label fleet-insight

# Dispatch (only confirmed actionable issues)
fleet dispatch --owner <owner> --repo <repo>

Triage Artifact

Create a persistent artifact at triage-<repo>.md:

# Triage: <owner>/<repo>

## Summary
- Total open: N
- Reviewed: N
- Close: N | Keep: N | Dispatch: N | Relabel: N

## Decisions

| # | Title | Labels | Decision | Reason |
|---|-------|--------|----------|--------|
| 194 | [Fleet Insight] Coverage | fleet, fleet-insight | CLOSE | Insight, no code action |
| 141 | [Fleet Execution] Update Enums | fleet, fleet-assessment | DEEP DIVE | Mixed labels, need to read body |

Token Management

• Never load all 25 issue bodies at once — each body can be 500-2000 tokens
• Process one deep dive at a time, record decision, then move on
• The triage artifact survives context resets — pick up where you left off
• For batch closes, use gh issue close in a single command per issue

Common Patterns

Duplicate Detection

Fleet analyzers often create duplicate insights across runs. Look for:

• Sequential "Update N" suffixes (keep only the latest)
• Same title with different numbers
• Same objective described in different words

Stale Assessment Detection

An assessment may have been addressed by a PR that didn't reference the issue:

• Check if the described code changes already exist in main
• Check if a similar PR was merged without Fixes #N

Mislabeled Issues

The analyzer sometimes labels insights as fleet (execution-worthy) when they're informational:

• Body says "No source changes" → should be fleet-insight, not fleet
• Body says "N/A - This is an Insight report" → not dispatchable