This is a comment left during a code review.
Path: src/infra/retry-policy.ts
Line: 93-99

Comment:
**Misleading "rate limited" log message for network retries**

The `onRetry` log always says `"rate limited"` regardless of the error type. Now that the runner also retries on network errors (`TypeError`, `ECONNRESET`, etc.), operators using `verbose: true` (e.g. in `provider.ts` via `shouldLogVerbose()`) will see confusing log entries like `discord command deploy rate limited, retry 1/2 in 500ms` for what is actually a transient network failure.

```suggestion
      onRetry: params.verbose
        ? (info) => {
            const labelText = info.label ?? "request";
            const maxRetries = Math.max(1, info.maxAttempts - 1);
            const reason =
              info.err instanceof RateLimitError ? "rate limited" : "network error";
            log.warn(
              `discord ${labelText} ${reason}, retry ${info.attempt}/${maxRetries} in ${info.delayMs}ms`,
            );
          }
        : undefined,
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/discord/monitor/reply-delivery.test.ts
Line: 410-426

Comment:
**Duplicate test coverage for 400 error**

This test ("does not retry on 400 validation error") is functionally identical to the existing "does not retry on 4xx client errors" test immediately below it (lines 428–444): both use `Object.assign(new Error("bad request"), { status: 400 })` and assert exactly 1 call. The new test adds no new coverage and may cause confusion. Consider removing it or replacing it with a distinct 4xx status (e.g. 422 or 403) to broaden coverage without duplication.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/infra/retry-policy.ts
Line: 68-76

Comment:
**Early return suppresses TypeError fallback when an unknown `.code` is present**

The current logic short-circuits on any string `.code` property:

```
if (typeof (err as { code?: unknown }).code === "string") {
  return DISCORD_RETRYABLE_ERROR_CODES.has(code);  // returns false for unknown codes
}
return err instanceof TypeError && DISCORD_NETWORK_ERROR_RE.test(err.message);
```

A `TypeError("fetch failed")` that also happens to carry an unrecognized `.code` (e.g. some future undici error variant or a library wrapper that attaches a code) will be classified as non-retryable and never reach the `TypeError` + message check. This may not matter today since standard fetch `TypeError`s from undici don't carry a `.code`, but the asymmetry is fragile. Consider checking the code-based path only when the code actually matches, and falling through otherwise:

```typescript
export function isRetryableDiscordNetworkError(err: unknown): boolean {
  if (!(err instanceof Error)) {
    return false;
  }
  const code = (err as { code?: unknown }).code;
  if (typeof code === "string" && DISCORD_RETRYABLE_ERROR_CODES.has(code)) {
    return true;
  }
  return err instanceof TypeError && DISCORD_NETWORK_ERROR_RE.test(err.message);
}
```

How can I resolve this? If you propose a fix, please make it concise.