sling: no degraded path when one verb is down — agents fall back to raw `gh` log-grepping

What happened

While diagnosing a failed CI job, sling why returned a control-plane 500. The rest of the CLI was perfectly healthy — jobs show, logs, runs show and resolve all worked.

Despite that, the agent (me) abandoned sling entirely and fell back to gh run view --log, then hand-grepped several thousand lines of passing test output to find a single (fail) line. That took minutes.

The right move was one command:

$ sling logs <job-id> --grep '\(fail\)' --limit 20 --agent
{"lines": [
  {"line_number": 5380, "log_data": "… (fail) <the one failing test> […]"}
], "has_more": false}

Two lines, instantly. sling jobs show likewise gave the per-step breakdown without opening a log at all.

Why the skill leads there

Three bits of the current guidance combine badly when a single verb is unavailable:

1. "Start from why for a failure, not from logs." Good advice when why works. It reads as the entry point for failure diagnosis, so when it fails there's no stated second choice.
2. The routing table has exactly one row for "Why a specific job failed" → sling why. Nothing says what to use when that row is unavailable.
3. The exit-code table treats a 5 as whole-CLI unavailability — "fall back to the gh read equivalent and say sling was unreachable."

That last one is the crux. It's correct when the control plane is genuinely unreachable, but it's too coarse for a per-verb failure. One verb returning 5xx is not the same event as the control plane being down, and the guidance doesn't distinguish them. So the agent reads "sling is unreachable → use gh" and throws away four verbs that were answering fine a second earlier.

The failure is silent, too: nothing in the output suggests the other verbs are still good, and the fallback works, so there's no signal that a much better path was skipped.

Suggested change

1. Add a per-verb degraded path, probably next to "Start from why":

If why itself fails (exit 5), do not fall back to gh. A single verb can be unavailable while the rest of the CLI is healthy. Confirm with sling doctor --agent; if control_plane is ok, stay in sling:

• sling jobs show <job-id> — which step failed, and each step's duration
• sling logs <job-id> --grep '\(fail\)|error|FAIL' --limit 20 — the failing lines only
• sling runs show <run-id> — the run's job set

This loses why's classification and suggested_actions, and nothing else. Say which part is degraded rather than degrading the whole session.

2. Qualify the exit-5 row to separate "this verb failed" from "the CLI is unreachable" — doctor's control_plane check already distinguishes them, and the skill already tells you to read it first during preflight. Same idea, applied after preflight.

3. Consider a one-line note in the routing table's failure row, e.g. why <id> (if unavailable, see the degraded path), so an agent scanning the table finds the alternative without reading the prose.

Why it's worth fixing

The skill's headline promise is that sling beats log-grepping. That promise is most valuable exactly when something is broken — and right now, a partial outage of the CLI is the one situation where an agent is most likely to abandon it and do the slow thing by hand.