💭 The relevant files are providerIconUtils.ts and providerDriverMeta.ts. I need to check whether PiAgentIcon actually exists in the Icons set, and note that some doc comments were removed.

1. git_tools — PiAgentIcon

2. browse_code — apps/web/src/components/settings/providerDriverMeta.ts

💭 I want to check AddProviderInstanceDialog to see if it still lists ohMyPi as a placeholder "coming soon" provider — if so, that would create a duplicate entry now that it's a real driver, which is worth flagging as a UI consistency issue.

3. browse_code — apps/web/src/components/settings/AddProviderInstanceDialog.tsx

💭 I notice the coming soon list also has "Pi Agent" using the same PiAgentIcon that's now assigned to Oh My Pi, which could be confusing since these seem to be different products despite sharing an icon.

4. browse_code — apps/web/src/components/Icons.tsx

5. browse_code — apps/web/src/components/chat/providerIconUtils.ts

💭 I should check whether PROVIDER_OPTIONS in session-logic includes "ohMyPi" -- if it's missing there, the provider would be added to settings but wouldn't actually show up in the chat picker, leaving a UI gap.

6. git_tools — PROVIDER_OPTIONS

7. browse_code — apps/web/src/session-logic.ts

💭 I notice PROVIDER_OPTIONS doesn't include ohMyPi and want to check whether the picker actually pulls from that list or from a server-provided providers list instead, so PROVIDER_OPTIONS might just be for ordering/labels. I should check where AVAILABLE_PROVIDER_OPTIONS and PROVIDER_ICON_BY_PROVIDER are used, and confirm session-logic.ts is in scope even though it hasn't been changed yet.

8. git_tools — AVAILABLE_PROVIDER_OPTIONS|PROVIDER_ICON_BY_PROVIDER

💭 The provider icon mapping looks fine since it's driven by server-side driverKind data. Now I'm checking the diff for UI-consistency concerns, starting with the removed doc comments on badgeLabel and getDriverOption in providerDriverMeta.ts — just comment deletions, which I need to weigh against the rule about preserving explanatory comments. The bigger question is whether the new Oh My Pi driver should have a warning badge like Cursor and Grok's "Early Access" labels, given it's a brand-new experimental integration with documented limitations.

9. git_tools — pickerSidebarBadge

💭 I'm noticing a discrepancy: the earlier file view at that commit didn't show devin or the multi-line claudeAgent entry, but the grep results do. That suggests the grep might be searching a different revision than the one I viewed, so I need to double check which ref each command actually used. Setting that aside, I want to look at where the model picker sidebar renders provider entries — whether it pulls from PROVIDER_OPTIONS or from server-provided providers — so I should search for the ModelPicker sidebar component.

10. browse_code — In apps/web/src, how does the model/provider picker sidebar build its list of providers — does it use PROVIDER_OPTIONS / AVAILABLE_PROVIDER_OPTIONS from session-logic.ts, or the server-provided provider instances? Also, where is badgeLabel from providerDriverMeta.ts rendered, and where is pickerSidebarBadge rendered? Give file paths and code snippets.

💭 I'm noticing that Oh My Pi, being a minimal new integration with documented limitations, lacks the badgeLabel that other experimental drivers like cursor and grok use—that's a consistency gap worth flagging, especially since the PR also removed the doc comment explaining that convention. I want to verify the comment removal precisely against the git diff.

11. git_tools — apps/web/src/** c034f51..f2c9b9b

💭 I'm noting two issues: the deletion of doc comments in providerDriverMeta.ts documenting the badge contract seems like unrelated collateral removal that should be restored, and the new "Oh My Pi" entry is missing the badgeLabel: "Early Access" marker that comparable newly-added drivers like Cursor and Grok carry, despite docs indicating significant limitations. I also notice PiAgentIcon is reused for both the new "ohMyPi" driver and the disabled "Pi Agent" coming-soon entry, so the same picker will show two rows with identical icons — this creates ambiguous provider identity that could persist if piAgent ships later. I'll flag it as a suggestion to introduce a distinct icon rather than sharing PiAgentIcon. Separately, I'm noting an unrelated style-only reformatting in providerIconUtils.ts's stripLeadingQualifier function — collapsing braces in code untouched by the PR's purpose, which falls under the rule not to fail for harmless aesthetic changes. I'll leave it unmentioned inline given its low signal-to-noise value. Checking whether PROVIDER_OPTIONS needs an entry for the new driver — since it's not actually consumed by the picker, it doesn't require one. I'm also considering whether ProviderSettingsForm properly handles clearWhenEmpty: "omit" and hidden: true annotations, though that's more of a contracts concern outside this review's scope. Now I want to verify whether hidden: true is actually a supported annotation key in the settings form — if it's not, the "enabled" boolean would end up rendering as a visible field in the settings UI, which would be a genuine inconsistency worth checking against the annotation contract in ProviderSettingsForm and deriveProviderSettingsFields.

12. browse_code — In apps/web/src/components/settings/ProviderSettingsForm.tsx (and deriveProviderSettingsFields), which providerSettingsForm annotation keys are supported (e.g. hidden, placeholder, clearWhenEmpty)? Show the code that reads the annotation and how other provider settings schemas (e.g. GrokSettings, OpenCodeSettings in packages/contracts) declare enabled fields. Is hidden: true and clearWhenEmpty: "omit" honored?

💭 I'm noticing OhMyPiSettings deviates from the pattern other providers follow — it uses raw Schema.Struct instead of the makeProviderSettingsSchema helper, which still typechecks since Schema.Struct has a fields property, but I'm wondering whether skipping the order field in providerSettingsFormSchema causes issues elsewhere. I'm also flagging that Oh My Pi defaults enabled: true while similar experimental providers default to false, meaning it'll show up in everyone's provider picker and get probed automatically. That's a real UI-consistency concern, but since it lives in packages/contracts, which is outside my scope of files I can comment on directly, I can only surface it as a note in the summary rather than an inline suggestion. Since that file isn't in scope, I'll fold the finding into the providerDriverMeta comment instead. I'm settling on two inline findings: first, the new driver lacks a badgeLabel like the other preview drivers (Cursor, Grok), despite the docs listing limitations and enabled defaulting to true — I'll suggest adding "Early Access". Second, a deleted doc comment documenting the badgeLabel/driver-kind contract should be restored, which requires commenting on the removed lines using the original line numbers on the diff's left side. I also spot another finding: PiAgentIcon is shared between the new "ohMyPi" driver and the existing coming-soon "piAgent" driver, meaning the Add Provider dialog would show two rows with identical icons since ProviderInstanceIcon/ModelListRow can't distinguish them. That's a real visual identity collision worth flagging on providerIconUtils.ts's added line, suggesting a distinct OhMyPiIcon instead — and since the check defaults to failure when findings exist, I'll mark this as a failure. I want to confirm the piAgent coming-soon entry is unchanged at the merge base and that Icons.tsx has no dedicated OhMyPi icon defined. Checking the line numbers, the hunk adds the icon mapping for "ohMyPi" at new line 19 in providerIconUtils.ts, and the driverMeta entry spans lines 72-77, so I'll anchor my finding comment around line 73. I'm working out the exact multi-line suggestion for the new provider entry (value, label, icon, badgeLabel, settingsSchema fields) so my inline comment matches lines 72-77 precisely. I should also decide whether to flag the incidental reformatting in providerIconUtils' stripLead helper as a drive-by change worth noting. For the second finding, I'm drafting a comment explaining that the PR removed the doc comment describing the badgeLabel contract and getDriverOption's documentation, which is unrelated to the actual feature addition, and I'll suggest restoring that documentation with a code suggestion reinserting the deleted comment block.

13. modify_pr — UI consistency review of the in-scope web changes (apps/web/src/components/chat/providerIconUtils.ts, apps/web/src/components/settings/providerDriverMeta.ts). The new driver is registered through the shared ProviderClientDefinition contract and the shared icon map, which is the right ownership. Three consistency issues on the changed lines are noted inline: 1. The new ohMyPi definition reuses PiAgentIcon, which is already the icon of the disabled piAgent "Coming Soon" row, so the Add-provider radio list renders two visually identical providers. 2. The new definition ships without badgeLabel, unlike the other opt-in/preview drivers, even though the guide documents several missing capabilities and the schema defaults it to enabled. 3. Two doc comments in providerDriverMeta.ts were deleted as unrelated collateral, including the one that documents the badgeLabel badge contract used by both render sites.