Context

This is the output of an AI-assisted SDK component generation pilot — not intended for production merge as-is. We're sharing it for eng commentary on pattern adherence, architectural decisions, and feasibility of this approach as a development accelerator.

Background: Historical Contractor Payments was descoped from the Contractor Payments SDK launch because mixing historical and future-dated payments in one flow caused UX confusion. This PR builds a standalone HistoricalPaymentFlow component for recording past-dated contractor payments.

What's in this PR

A complete HistoricalPaymentFlow with a 3-step journey:

1. Select a past payment date — Date picker constrained to past dates, defaulting to yesterday
2. Select contractors and specify amounts — Same table/modal pattern as existing CreatePayment, minus payment method selector (always "Historical Payment")
3. Review and submit — Preview via API, submit with creationToken, success confirmation

15 new files under src/components/Contractor/Payments/HistoricalPayments/ following all existing SDK patterns: robot3 state machine, container/presentation split, BaseComponent, ComponentsContext, Zod forms, i18n, DataView, DOMPurify, React Query hooks.

See the README for full details on how it was built, file inventory, and current status.

How to test

1. Check out this branch
2. npm install && npm run sdk-app
3. Provision a demo company (or use existing)
4. Find "Contractor.Payments.HistoricalPayments.HistoricalPaymentFlow" in the sidebar
5. Walk through the full flow with live data

What's done

• Full flow works end-to-end with live API data (preview + create)
• TypeScript, ESLint, Prettier, commitlint all pass
• 31/32 PRD acceptance criteria met (1 minor — date range is permissive, defers to API validation)
• Pattern consistency with existing Contractor Payments SDK verified across all 15 architectural patterns

What's NOT done (would need before production)

• Unit tests (Vitest)
• Storybook stories
• Accessibility audit
• Design review
• Edge case handling (0 contractors, network errors, etc.)
• Integration into existing PaymentFlow (currently standalone only)

What we're looking for

This is shared for commentary, not merge approval:

• Pattern adherence — Does the code follow SDK conventions correctly?
• Architectural decisions — Is the simplified 3-state machine right, or should preview be a separate state?
• Gaps — What edge cases or requirements did the AI miss?
• AI pilot viability — Is this approach viable for accelerating future SDK component development?

🤖 Generated with Claude Code