refactor(convex): extract validators into separate files

[larryro]

Summary

• Creates dedicated validators.ts files for each Convex model domain
• Moves Convex validators from types.ts to separate validators.ts files
• Reduces code in type files by ~1,470 lines while adding ~1,306 lines in organized validator files
• Improves maintainability by separating validation logic from type definitions

Affected Domains

• approvals
• conversations
• customers
• documents
• email_providers
• integrations
• organizations
• products
• tone_of_voice
• websites
• wf_definitions
• wf_executions
• wf_step_defs

Test plan

• Verify Convex functions still work correctly with extracted validators
• Run type checking to ensure no TypeScript errors
• Test affected API endpoints

🤖 Generated with Claude Code

Summary by CodeRabbit

• Refactor
  • Reorganized internal validation logic by separating validators into dedicated modules across the platform. This improves code structure and maintainability without affecting any functionality or user-facing behavior.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR systematically refactors the codebase to separate validator definitions from type definitions across multiple model modules. New validators.ts files are created to house Convex validator definitions, while types.ts files are updated to use TypeScript type inference (via Infer<typeof validator>) instead of inline validator/interface declarations. Import statements are updated throughout the codebase to reference validators from their new module locations, and barrel index files are updated to re-export both validators and types separately. This consolidates validator logic in dedicated modules while deriving types from those validators.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Possibly related PRs

• tale-project/poc2#440 — Introduces and uses approvalResourceTypeValidator alongside other approval validators that are also affected by this refactoring
• talecorp/poc2#143 — Splits conversation validators and types into separate modules, which aligns with the conversation-related changes in this PR
• optimize chat agent #5 — Modifies the same customer_action.ts file to update validator import sources alongside other validator-related changes

---

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

[coderabbitai]

Actionable comments posted: 9

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)

services/platform/convex/model/wf_executions/types.ts (1)

8-110: Document the manual types pattern and sync strategy.

The manual TypeScript interfaces are maintained separately from runtime validators, creating a risk of drift. While this separation can provide better IDE support, it requires careful coordination.

Consider one of these approaches:

1. Document the pattern (quick fix): Add a comment explaining why types are manual and how to keep them synchronized with validators:

   /**
    * MANUAL TYPES (these rely on Doc types, not validators)
    * 
    * Note: These TypeScript interfaces are maintained separately from runtime
    * validators in ./validators.ts for better IDE support. When updating validators,
    * ensure corresponding type definitions are updated to match.
    */

2. Use type inference (recommended): Import validators and derive types to ensure they stay in sync:

   import type { Infer } from 'convex/values';
   import {
     updateExecutionStatusArgsValidator,
     completeExecutionArgsValidator,
     // ... other validators
   } from './validators';
   
   export type UpdateExecutionStatusArgs = Infer<typeof updateExecutionStatusArgsValidator>;
   export type CompleteExecutionArgs = Infer<typeof completeExecutionArgsValidator>;

Based on learnings, approach #1 is acceptable for this codebase if properly documented.

services/platform/convex/model/integrations/types.ts (1)

73-73: Consider adding a comment explaining the Shopify API version.

A brief comment noting when this version was chosen or a link to Shopify's versioning documentation would help future maintainers understand update implications.