Add Rovo Dev provider with monthly credit tracking#1275
Conversation
|
Codex review: needs real behavior proof before merge. Reviewed June 13, 2026, 6:26 AM ET / 10:26 UTC. Summary Reproducibility: not applicable. as a bug reproduction; this PR adds a new provider. Source inspection confirms current main has no Rovo Dev provider, while the remaining validation gap is real-provider proof rather than reproducing an existing bug. 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 findings
Review detailsBest possible solution: Fix the remaining used-versus-remaining parsing case, then merge only after redacted latest-head CodexBar app or CLI proof shows a successful paid-account monthly-credit fetch and a maintainer accepts the undocumented endpoint/auth contract. Do we have a high-confidence way to reproduce the issue? Not applicable as a bug reproduction; this PR adds a new provider. Source inspection confirms current main has no Rovo Dev provider, while the remaining validation gap is real-provider proof rather than reproducing an existing bug. Is this the best way to solve the issue? No, not yet: the provider shape mostly follows existing patterns, but the parser should prefer remaining-derived usage when that is the reliable exhausted-quota signal, and the undocumented endpoint needs successful CodexBar proof or explicit maintainer acceptance. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against a2b56ea2b362. Label changesLabel justifications:
Evidence reviewedAcceptance criteria:
What 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.
Clawsweeper review fixes (commit 743a83e)[P1] Fixed —
|
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:
|
5988160 to
dcb264a
Compare
|
Maintainer repair pushed on exact head Changes:
Proof:
Fresh GitHub CI is now running. I am not merging this autonomously: the endpoint and Basic-auth contract are undocumented, and the available live proof only shows a blocked/anonymous response rather than a successful paid-account monthly-credit fetch through CodexBar. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dcb264a193
ℹ️ 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".
| if let explicit { | ||
| return explicit | ||
| } |
There was a problem hiding this comment.
Prefer remaining balance for exhausted Rovo credits
When Rovo Dev reports an exhausted Standard trial, the current credits/check payload can include monthlyRemaining: 0 and monthlyTotal: 2000 while also setting monthlyUsed: 0; this branch returns that explicit zero before deriving total - remaining, so exhausted accounts render as 0 / 2000 credits and 0% used. Prefer the derived remaining-based value when total and remaining are present (or at least for limit-exceeded statuses) so the menu reflects the actual cap.
Useful? React with 👍 / 👎.
- 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
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.
[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
dcb264a to
94f626b
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 94f626bf7b
ℹ️ 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".
| } | ||
|
|
||
| try RovoDevSettingsReader.validateEndpointOverrides(environment: environment) | ||
| let url = Self.creditsCheckURL(baseURL: RovoDevSettingsReader.apiURL(environment: environment)) |
There was a problem hiding this comment.
Apply the selected Rovo billing site to credit checks
For Rovo Dev users whose credits are tied to a selected Atlassian site (common with Free or multi-site accounts), this request ignores the atlassianBillingSite/cloudId that ACLI stores in ~/.rovodev/config.yml; Atlassian documents that setting as the site whose credit allocation Rovo Dev CLI should use (https://support.atlassian.com/rovo/docs/manage-rovo-dev-cli-settings/). Because the fetcher only calls the global credits/check URL with email/token, those accounts can get 403 or the wrong allocation even though acli rovodev is configured and works, so the provider should read/apply the billing site or otherwise mirror the CLI auth context before checking credits.
Useful? React with 👍 / 👎.
|
Exact head Holding merge for provider-contract acceptance. The implementation still depends on an undocumented endpoint/Basic-auth shape and lacks paid-account proof; CI cannot validate that external contract. |
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