Summary

• Problem: Pi is a fully functional community AI provider (registered at startup, returned by GET /api/providers, accepted by PATCH /api/config/assistants) but selecting it in the Settings wizard showed a generic "no dedicated editor yet" placeholder — users had no way to enter a model string.
• Why it matters: Pi supports ~20 LLM backends (Google Gemini, Anthropic Claude, OpenRouter models, etc.). Without the UI, users must manually edit config files to use Pi.
• What changed: Added a Pi-specific editor branch in AssistantConfigSection (SettingsPage.tsx) with a model text input and format helper text. Fixed a semantically wrong test assertion in api.providers.test.ts that passed only because Pi wasn't registered in test setup.
• What did not change: No backend changes — the API already accepted Pi settings. No new dependencies, no schema migrations, no new API endpoints.

UX Journey

Before

User selects "Pi (community)" from Provider dropdown in Settings > Assistant

Settings page renders:
  ┌─────────────────────────────────────────────────────────┐
  │ Provider: [ Pi (community)                          v ] │
  │                                                         │
  │ Provider-specific settings stored generically for       │
  │ Phase 2. No dedicated editor yet.                       │
  └─────────────────────────────────────────────────────────┘

User cannot enter a model — must manually edit config files.

After

User selects "Pi (community)" from Provider dropdown in Settings > Assistant

Settings page renders:
  ┌─────────────────────────────────────────────────────────┐
  │ Provider: [ Pi (community)                          v ] │
  │                                                         │
  │ Pi (community)    Community provider — ~20 LLM backends │
  │ Model             [google/gemini-2.5-pro              ] │
  │                   Format: <pi-provider>/<model-id>      │
  │                   e.g. anthropic/claude-haiku-4-5,      │
  │                        openrouter/qwen/qwen3-coder      │
  └─────────────────────────────────────────────────────────┘

User enters model ref, saves — value persists across reloads.

Architecture Diagram

Before

GET /api/providers ──▶ allProviderEntries (includes pi)
                            │
                            ▼
                    AssistantConfigSection.map()
                       ├── provider.id === 'claude'  → Claude editor
                       ├── provider.id === 'codex'   → Codex editor
                       └── else                      → [GENERIC FALLBACK] ← Pi landed here

After

GET /api/providers ──▶ allProviderEntries (includes pi)
                            │
                            ▼
                    AssistantConfigSection.map()
                       ├── provider.id === 'claude'  → Claude editor
                       ├── provider.id === 'codex'   → Codex editor
                       ├── provider.id === 'pi'      → [Pi editor] ← NEW
                       └── else                      → Generic fallback

Connection inventory:

Label Snapshot

• Risk: risk: low
• Size: size: XS
• Scope: web, tests
• Module: web:settings, server:providers-test

Change Metadata

• Change type: feature
• Primary scope: web

Linked Issue

• Closes archon setup wizard does not offer Pi as an AI provider option (follow-up to #1494) #1607

Validation Evidence (required)

bun run validate

• Evidence provided: full bun run validate run completed without errors
• No commands skipped

Security Impact (required)

• New permissions/capabilities? No
• New external network calls? No
• Secrets/tokens handling changed? No
• File system access scope changed? No

Compatibility / Migration

• Backward compatible? Yes — the fallback branch is untouched; any provider without a dedicated editor still renders the generic fallback
• Config/env changes? No
• Database migration needed? No

Human Verification (required)

What was personally validated beyond CI:

• Verified scenarios: Pi editor panel renders when Pi is selected; model input accepts google/gemini-2.5-pro; nested-slash format openrouter/qwen/qwen3-coder accepted without client-side rejection; Claude and Codex editor panels unaffected; generic fallback still present for unknown providers
• Edge cases checked: Empty model field (starts blank for new config); model value persists after save and page reload; updateProviderSettings('pi', ...) correctly calls PATCH /api/config/assistants
• What was not verified: Live Pi SDK round-trip (requires Pi binary installed); all ~20 Pi backend models

Side Effects / Blast Radius (required)

• Affected subsystems/workflows: Settings page UI only (packages/web/src/routes/SettingsPage.tsx); providers test (packages/server/src/routes/api.providers.test.ts)
• Potential unintended effects: None — insertion point is between the codex branch and generic fallback; no shared state modified
• Guardrails/monitoring for early detection: Existing CI test suite; the generic fallback still catches any future provider not yet in the switch

Rollback Plan (required)

• Fast rollback command/path: git revert HEAD — removes the Pi branch from SettingsPage.tsx and restores the original test assertion; users fall back to the generic placeholder
• Feature flags or config toggles: None — Pi already appeared in the dropdown before this PR; this PR only changes what renders after selecting it
• Observable failure symptoms: If Pi editor causes a render error, React error boundary would display; console would show the component stack

Risks and Mitigations

• Risk: TypeScript strict mode rejects the (providerSettings.model as string | undefined) assertion
  • Mitigation: Identical pattern already in use in the Codex branch (line ~540); copied verbatim
• Risk: Line numbers in SettingsPage.tsx shifted from plan
  • Mitigation: Identified insertion point by pattern matching (end of codex if-block, before generic fallback comment) rather than hard-coded line numbers