fix: normalize legacy claudeCode provider at all decode boundaries

[aaditagrawal]

Summary

• Adds migration 017 to normalize claudeCode → claudeAgent in existing DB data (events, projections, sessions)
• Adds runtime normalization at the event store decode boundary for any data the migration missed
• Adds claudeCode → claudeAgent mapping in toProviderKind() and normalizeProviderKind() for UI/store paths
• Ensures users with existing chat histories from the pre-rename era don't crash on upgrade

Test plan

• bun run dev starts cleanly on a database with claudeCode events
• bun typecheck passes all 7 packages
• Migration test passes
• Key test suites pass (200 tests)

Summary by CodeRabbit

Release Notes

• Bug Fixes

  • Fixed provider identification inconsistencies across the application to ensure proper and reliable provider functionality and stable operations throughout the system.

• Chores

  • Implemented automated normalization of legacy provider identifiers in stored records to maintain consistency and ensure unified provider references across all application data storage and processing components.

[coderabbitai]

📝 Walkthrough

Walkthrough

These changes implement a migration strategy to normalize legacy provider identifiers from "claudeCode" to "claudeAgent" across the persistence layer and web application. The updates span database migrations, event store decoding, and provider kind normalization in the web UI.

Changes

Cohort / File(s)	Summary
Database Persistence Layer apps/server/src/persistence/OrchestrationEventStore.ts	Added normalizeLegacyProviderNames pre-processing function to mutate decoded event payloads, rewriting "claudeCode" to "claudeAgent" before schema validation. All calling sites now use the normalized decodeEvent wrapper.
Migration Registry apps/server/src/persistence/Migrations.ts	Registered new migration entry 017 (NormalizeLegacyClaudeCodeProvider) into the inline migration registry and migrationEntries list for execution by the migration loader.
Migration Scripts apps/server/src/persistence/Migrations/016_CanonicalizeModelSelections.ts, apps/server/src/persistence/Migrations/017_NormalizeLegacyClaudeCodeProvider.ts	Added data normalization steps to rewrite "claudeCode" to "claudeAgent" in JSON payloads across orchestration_events, projection_threads, projection_projects, and projection_thread_sessions tables using SQLite JSON functions.
Web Application Provider Normalization apps/web/src/composerDraftStore.ts, apps/web/src/lib/threadProvider.ts	Updated normalizeProviderKind and toProviderKind to treat legacy provider value "claudeCode" as "claudeAgent" during normalization and provider kind resolution.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Poem

🐰 From code to Claude we hop with care,
Migrations run through databases fair,
Legacy names become the new,
Provider kinds both old and new,
Normalization hops on through! 🚀

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 25.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: normalizing legacy claudeCode provider references to claudeAgent at decode boundaries throughout the codebase.
Description check	✅ Passed	The PR description provides a clear summary of changes, rationale for the fix, and a comprehensive test plan, though it lacks before/after screenshots (not applicable here since no UI visual changes are involved).

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/claudeCode-normalization

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

apps/server/src/persistence/Migrations/016_CanonicalizeModelSelections.ts (1)

249-290: Consider consolidating with Migration 017.

These SQL statements (lines 251-290) perform the same claudeCode → claudeAgent normalization that Migration 017 also performs on the same tables and fields. While the duplication is idempotent and safe, it results in unnecessary database operations for users upgrading through both migrations.

The docstring in Migration 017 explains this was intentional to handle users who ran Migration 016 before the rename landed. If this is the intended behavior for different upgrade paths, consider adding a comment here explaining why the duplication exists.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/server/src/persistence/Migrations/016_CanonicalizeModelSelections.ts`
around lines 249 - 290, Migration 016 currently repeats the same `claudeCode` →
`claudeAgent` updates as Migration 017 for the orchestration_events
(payload_json $.modelSelection.provider and $.defaultModelSelection.provider)
and projection tables (projection_threads.model_selection_json $.provider and
projection_projects.default_model_selection_json $.provider); either remove the
duplicate SQL or, if duplication is intentional to support different upgrade
paths, add a concise comment above these UPDATE blocks in
016_CanonicalizeModelSelections explaining that this repetition mirrors
Migration 017 to handle users who ran 016 before the rename landed and is
intentionally idempotent. Ensure the comment references Migration 017 and the
specific JSON fields (payload_json.modelSelection/provider,
payload_json.defaultModelSelection/provider, model_selection_json.provider,
default_model_selection_json.provider) so future readers understand the
rationale.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@apps/server/src/persistence/Migrations/016_CanonicalizeModelSelections.ts`:
- Around line 249-290: Migration 016 currently repeats the same `claudeCode` →
`claudeAgent` updates as Migration 017 for the orchestration_events
(payload_json $.modelSelection.provider and $.defaultModelSelection.provider)
and projection tables (projection_threads.model_selection_json $.provider and
projection_projects.default_model_selection_json $.provider); either remove the
duplicate SQL or, if duplication is intentional to support different upgrade
paths, add a concise comment above these UPDATE blocks in
016_CanonicalizeModelSelections explaining that this repetition mirrors
Migration 017 to handle users who ran 016 before the rename landed and is
intentionally idempotent. Ensure the comment references Migration 017 and the
specific JSON fields (payload_json.modelSelection/provider,
payload_json.defaultModelSelection/provider, model_selection_json.provider,
default_model_selection_json.provider) so future readers understand the
rationale.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 4151b352-4125-4940-a6ce-a156fa9829e5

📥 Commits

Reviewing files that changed from the base of the PR and between 66fd12c and 0b90315.

📒 Files selected for processing (6)

• apps/server/src/persistence/Layers/OrchestrationEventStore.ts
• apps/server/src/persistence/Migrations.ts
• apps/server/src/persistence/Migrations/016_CanonicalizeModelSelections.ts
• apps/server/src/persistence/Migrations/017_NormalizeLegacyClaudeCodeProvider.ts
• apps/web/src/composerDraftStore.ts
• apps/web/src/lib/threadProvider.ts