[P2.1] Capabilities matrix + graceful feature degradation

[frankbria]

Phase 2 — Capabilities & safety. Make Ralph's Claude-specific features optional
per provider instead of silently misbehaving.

Scope

• Each adapter exposes the [P0.2] capabilities record.
• Gate these features on capabilities, with a one-time logged WARN when disabled:
  • MAX_TOKENS_PER_HOUR token limiting (needs supports_token_usage).
  • Permission-denial circuit breaker No Approval Request, silent fail #101 (needs supports_permission_denials).
  • API-limit detection Claude Extra Usage Bug #100/[BUG] Timeout (exit code 124) misidentified as API 5-hour usage limit #183 (needs supports_api_limit_detection).
  • Pre-assigned vs resume-id vs continue-last session handling.
• Exit detection via RALPH_STATUS stays always-on (portable).

Acceptance

• With a capability off, the dependent feature no-ops + logs once; circuit breaker,
  rate limiting, exit detection still function on supported signals.
• Tests cover each gate on/off.

Depends on: [P0.2], [P1.2], [P1.3]. Blocks: [P3.1].

[coderabbitai]

🔗 Related PRs

#142 - feat(exit): detect permission denials and halt loop (Issue #101) [merged]
#219 - fix(loop): detect Claude Extra Usage quota exhaustion (#100) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[github-actions]

🏷️ Triage: Enhancement

Categorized this as an enhancement / feature work item and applied the enhancement label.

Why: This is a scoped Phase 2 task in the multi-provider epic (P2.1 — capabilities matrix + graceful feature degradation), not a bug report or support question. It proposes new behavior — gating Claude-specific features (token limiting, permission-denial circuit breaker #101, API-limit detection #100/#183, session handling) on a per-adapter capabilities record with one-time WARN logging when a capability is off. The issue is well-specified, with clear scope and acceptance criteria, so no additional information is needed from the author.

Not a duplicate: This is a distinct phase item; no other open issue covers the P2.1 capabilities-gating work.

Recommended next steps:

• This work is gated by its stated dependencies — [P0.2] (capabilities record), [P1.2], and [P1.3] — which should land before implementation begins. It in turn blocks [P3.1].
• Ensure the always-on RALPH_STATUS exit-detection path stays portable across providers, per the scope note.
• Add on/off tests for each capability gate as called out in the acceptance criteria.

The existing multi-provider label is preserved; enhancement is added as the triage category.

Generated by Issue Triage Assistant for issue #315 · opus48 370.1K · ◷