Add Rovo Dev provider with monthly credit tracking#1275
Conversation
- Add UsageProvider.rovodev + IconStyle.rovodev cases - RovoDevSettingsReader: reads ROVODEV_API_TOKEN, ROVODEV_EMAIL, ROVODEV_API_URL - RovoDevUsageFetcher: Basic auth against api.atlassian.com/rovodev/v3/credits/check; parses monthlyUsed/monthlyTotal with daily fallback; surfaces status (OK, RATE_LIMITED, USER_BLOCKED) - RovoDevProviderDescriptor: api-only fetch strategy resolving from env vars or token accounts - RovoDevProviderImplementation: settings fields for email + API token with link to id.atlassian.com - RovoDevSettingsStore: rovoDevAPIToken (apiKey) + rovoDevEmail (workspaceID) - ProviderConfigEnvironment: applyRovoDevOverrides injects both ROVODEV_API_TOKEN and ROVODEV_EMAIL - ProviderTokenResolver: rovoDevToken() + rovoDevResolution() - LogCategories: rovoDevUsage log category - UsageStore: debug log entry for rovodev - 14 unit tests: settings reader, JSON parser, URL builder, snapshot conversion, errors - docs/rovodev.md: setup, how it works, credential resolution, troubleshooting - docs/providers.md: summary table row + detailed entry
|
Codex review: needs real behavior proof before merge. Reviewed June 2, 2026, 7:05 AM ET / 11:05 UTC. Summary Reproducibility: not applicable. as a bug reproduction; this is a new provider feature. Source inspection confirms current main has no Rovo Dev provider and PR head adds the new fetch/config path. Review metrics: 2 noteworthy metrics.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Land after maintainer sign-off and redacted output from the latest CodexBar provider path shows a real monthly-credit fetch, keeping the provider disabled by default. Do we have a high-confidence way to reproduce the issue? Not applicable as a bug reproduction; this is a new provider feature. Source inspection confirms current main has no Rovo Dev provider and PR head adds the new fetch/config path. Is this the best way to solve the issue? Unclear until provider-path proof is added. The implementation follows the existing descriptor, strategy, settings, and test shape, but the endpoint/auth contract should be proven through CodexBar before merge. AGENTS.md: found and applied where relevant. Codex review notes: model gpt-5.5, reasoning high; reviewed against 55c0a105002f. Label changesLabel changes:
Label justifications:
Evidence reviewedWhat I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0a08870478
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } | ||
|
|
||
| // 2. Token accounts (label stores email, token stores API key) | ||
| if let account = context.tokenAccounts?.first(where: { !$0.token.isEmpty && !$0.label.isEmpty }) { |
There was a problem hiding this comment.
Fix unresolved tokenAccounts access
In the inspected ProviderFetchContext definition (Sources/CodexBarCore/Providers/ProviderFetchPlan.swift), there is no tokenAccounts property—only selectedTokenAccountID and environment/settings fields—so adding this fallback makes the new Rovo Dev provider fail to compile as soon as this strategy is built. The selected account is already projected through the environment in the app/CLI fetch context, so this needs to resolve through the existing token-account/environment path or add the missing context support.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in commit 4ddda02.
ProviderFetchContext has no tokenAccounts property — you are correct. Credentials are resolved exclusively from context.env, which is populated by ProviderConfigEnvironment.applyRovoDevOverrides (injecting ROVODEV_API_TOKEN + ROVODEV_EMAIL from the settings-stored values). Simplified resolveCredentials to a single guard reading from context.env, and removed the isAvailable tokenAccounts fallback from the implementation as well. Zero new compile errors after the fix.
Validated against live api.atlassian.com/rovodev/v3/credits/check response: - Add modelUsages: [String: Int]? — per-model token usage map - Add retryAfterSeconds: Int? — retry hint when rate limited - Remove redundant explicit CodingKeys from RovoDevBalance (names match) - Parser correctly handles null monthly fields with daily fallback
…tchStrategy ProviderFetchContext has no tokenAccounts property — only selectedTokenAccountID and env vars. Credentials are injected via ProviderConfigEnvironment.applyRovoDevOverrides which puts ROVODEV_API_TOKEN and ROVODEV_EMAIL into context.env from settings. - Simplify resolveCredentials to read only from context.env - Simplify isAvailable to check email+token (no tokenAccounts fallback needed) Addresses Codex review P1 finding.
Replace placeholder 'A' mark with proper Rovo Dev icon using the official Atlassian Rovo brand gradient (purple #8270DB → blue #579DFF → #2684FF), matching the visual identity of the Rovo Dev product and CLI. Also copy icon to docs/logos/rovodev.svg for docs site use.
[P1] Add .rovodev to ProviderImplementationRegistry switch - Without this, adding .rovodev to UsageProvider makes makeImplementation non-exhaustive and the app target fails to compile. [P2] Add .rovodev to directAPIKeyEnvironmentKey in ProviderConfigEnvironment - supportsAPIKeyOverride now returns true for .rovodev, enabling the documented 'codexbar config set-api-key --provider rovodev' CLI path. [P2] Remove unsupported token-account credential claim from docs - Token accounts cannot carry two credentials (email + token), so they are not a supported auth path for Rovo Dev. Docs now state this clearly with a note directing users to env vars or Settings instead.
Clawsweeper review fixes (commit 743a83e)[P1] Fixed —
|
[P1] Register RovoDevProviderDescriptor in ProviderDescriptorRegistry
- Add .rovodev to the descriptors dict in ProviderDescriptorRegistry
- Without this, bootstrap iterates .rovodev from allCases and hits
preconditionFailure('Missing ProviderDescriptor for rovodev')
[P2] Add .rovodev to CodexBarConfigValidator.workspaceIDProviders
- Email is stored in workspaceID field for Rovo Dev (two-credential provider)
- Without this, a valid Rovo Dev config reports 'workspace_unused' warning
- Rovo Dev is now a recognised workspaceID consumer alongside azureopenai,
openai, opencode, opencodego, deepgram
Clawsweeper second-pass fixes (commit 5988160)[P1] Fixed — descriptor registered in
|
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
@clawsweeper re-review |
|
🦞👀 Command router queued. I will update this comment with the next step. Re-review progress:
|
Summary
Adds Rovo Dev as a new CodexBar provider, tracking monthly credit usage for Atlassian's AI coding agent.
What's new
UsageProvider.rovodev+IconStyle.rovodevenum casesRovoDevSettingsReader— readsROVODEV_API_TOKEN,ROVODEV_EMAIL,ROVODEV_API_URLenv vars +~/.rovodev/config.ymlbilling siteRovoDevUsageFetcher— Basic auth (email:apiToken) againsthttps://api.atlassian.com/rovodev/v3/credits/check; parsesmonthlyUsed/monthlyTotalwith daily fallback; surfaces status (OK, RATE_LIMITED, USER_BLOCKED)RovoDevProviderDescriptor— api-only fetch strategy; resolves credentials from env vars or token accountsRovoDevProviderImplementation— settings fields for Atlassian email + API token with link toid.atlassian.comRovoDevSettingsStore—rovoDevAPIToken(→apiKey) +rovoDevEmail(→workspaceID)ProviderConfigEnvironment—applyRovoDevOverridesinjects bothROVODEV_API_TOKENandROVODEV_EMAILinto fetch envProviderTokenResolver:rovoDevToken()+rovoDevResolution()LogCategories:rovoDevUsagelog categoryUsageStore: debug log entry for rovodevdocs/rovodev.md: full setup guide, how it works, credential resolution order, troubleshootingdocs/providers.md: summary table row + detailed entryAuth approach
HTTP Basic auth:
base64(email:apiToken)— the same Atlassian API token used withacli rovodev auth login. No OAuth flow needed.Credential resolution order
ROVODEV_API_TOKEN+ROVODEV_EMAILenvironment variablesPlans supported
Commands run