refactor(sdk-app): split design components into View/Container layers

[aaronlee777]

Summary

Split the design app's prototype layer into pure Views (presentational, prop-driven) and thin Containers (data fetching + event dispatch + route wiring). Once that split exists, a per-prototype Component States viewer can render any View in isolation with mock data — no MSW, no live API.

Migrated CompensationHistory, all of contractor-management, and all of contractor-self-onboarding to the new pattern. Three prototype state viewers ship as part of this change.

Final layout

sdk-app/src/design/
  components/                            ← Views (pure presentational)
    common/
    contractor/
      management/                          ContractorList, ContractorDetails,
                                            ContractorAddress, ContractorPay,
                                            ContractorDocuments, ContractorDismissalForm,
                                            ContractorRehireForm, +Form variants…
      self-onboarding/                     ContractorWelcome, ContractorDocumentList,
                                            ContractorDocumentSignature, ContractorOnboardingComplete
      shared/                              AddressForm, PaymentMethodForm, ProfileDetailsForm
    employee/
      management/
        CompensationHistory/

  prototypes/                            ← Containers (data + routing)
    contractor-management/                 ContractorList, ContractorDismiss, ContractorRehire,
                                           ContractorManagementFlow, ContractorProfile/,
                                           AddContractor/, states.tsx, index.tsx
    contractor-self-onboarding/            ContractorLanding, ContractorSelfProfile,
                                           ContractorSelfAddressForm, ContractorSelfPaymentMethodForm,
                                           ContractorDocumentSigner, ContractorSignatureForm,
                                           ContractorOnboardingSummary,
                                           ContractorSelfOnboardingWizard,
                                           states.tsx, index.tsx
    employee-management/CompensationHistory/  CompensationHistory.tsx (container),
                                              states.tsx, index.tsx

Naming rule: single file per route container when one file is enough; folder when multiple. No Route suffix anywhere — the folder location already says it. Views and containers can share a name (e.g. ContractorList); when both end up in the same file the View is aliased on import (as ContractorListView).

What this PR delivers

Structure

• Pure Views relocated to design/components/{contractor,employee}/{management,self-onboarding,shared}/.
• Thin containers in design/prototypes/<prototype>/ that own data fetching, mutations, and event dispatch.
• self-onboarding/ lifted from inside contractor-management/ to a sibling prototype (prototypes/contractor-self-onboarding/).
• contractor-profile/ subfolder flattened — ContractorManagementFlow and ContractorProfile/ now sit at the prototype root.
• Route suffix dropped from ContractorList, ContractorDismiss, ContractorRehire.
• AddContractor/ wizard flattened to prototypes/contractor-management/AddContractor/.

Component States viewers

Three live viewers, each with a right-rail sidebar that lists Views and per-View configurations:

• /design/employee-compensation-history/component-states/ — CompensationHistory (4 configs).
• /design/contractor-management/component-states/ — ContractorList (8 configs), ContractorDismissalForm (4), ContractorDetails (4), ProfileDetailsForm (2), AddressForm (2), PaymentMethodForm (2).
• /design/contractor-self-onboarding/component-states/ — ContractorWelcome (3), ContractorDocumentList (4), ContractorDocumentSignature (2), ContractorOnboardingComplete (1), ProfileDetailsForm (3), AddressForm (2), PaymentMethodForm (3).

Shared-form viewers in both contractor surfaces so the same Views can be inspected with management-context copy or onboarding-context copy.

Shared form refactor

• PaymentMethodForm (shared) was a container masquerading as a View — it did its own suspense queries, mutations, and event dispatch. Split into a pure View (just fields + form mechanics) and lifted the data wiring into each consumer (self-onboarding container + AddContractor wizard step). Matches AddressForm / ProfileDetailsForm shape. Also fixed a stale requestBody field name (the SDK type expects contractorBankAccountCreateRequestBody).

Dead-code removal

• Deleted MockedRender, MockedEntitiesOutlet, sdk-app/src/mocks/ (browser worker + useMockHandlers), and sdk-app/public/mockServiceWorker.js. With every state demo passing data via props directly, the MSW machinery wasn't earning its keep.
• Removed the handlers: RequestHandler[] field from PrototypeConfiguration and every handlers: [] line in states files.
• ComponentStatesPage now calls configuration.render() directly.

Other small wins

• Local W-9 PDF bundled at sdk-app/public/sample-documents/w9.pdf so the DocumentSignature demo's DocumentViewer actually renders something (irs.gov refuses to be embedded).
• Registry sidebar now lists Prototype / Component states children under Contractor Self-Onboarding.

What's not in this PR

• The wizard's AddContractor/ContractorProfile.tsx step (with the self-onboarding toggle + classification fields) is intentionally kept separate from the shared ProfileDetailsForm. The forms are structurally different and consolidating would mean ~8 toggle props on the shared View.
• Unit tests for the newly-extracted self-onboarding Views — the existing CompensationHistory test was migrated and still passes; adding tests for the rest can come in a follow-up.

Test plan

• npm run sdk-app — open the design app.
• Sidebar shows three prototypes with Prototype / Component states children: Compensation History, Contractor Management, Contractor Self-Onboarding.
• Compensation History → Component states → step through Single job / Multiple jobs / Mixed wages / Empty.
• Contractor Management → Component states → step through every component: List (8 configs), Dismissal Form (4), Basic Details (4), Profile Details Form (2), Address Form (2), Payment Method Form (2).
• Contractor Self-Onboarding → Component states → step through Welcome (3), Profile Details (3), Address Form (2), Payment Method Form (3), Document List (4), Document Signature (2), Onboarding Complete (1). The Document Signature default config should render a W-9 in the DocumentViewer.
• Live prototype routes still work: /design/employee-compensation-history/prototype, /design/contractor-management, /design/contractor-self-onboarding.
• npx tsc --noEmit clean.
• npm run test -- --run sdk-app/src/design/components/employee/management/CompensationHistory/CompensationHistory.test.tsx passes (4 tests).

🤖 Generated with Claude Code

[boostsecurity-io-ai]

⚠️  1 New Security Finding

The latest commit contains 1 new security finding.

Findings Note: 1 finding is displayed as an inline comment.

Not a finding? Ignore it by adding a comment on the line with just the word noboost.

Scanner: boostsecurity - Semgrep

[boostsecurity-io-ai]

CWE-338: Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)
Original Rule ID: rules_lgpl_javascript_crypto_rule-node-insecure-random-generator

Details

The product uses a Pseudo-Random Number Generator (PRNG) in a security context, but the PRNG's algorithm is not cryptographically strong.

The application uses cryptographically weak random number generators such as
crypto.pseudoRandomBytes() or Math.random() for security-sensitive
operations. The crypto.pseudoRandomBytes() function uses a non-cryptographic
PRNG that may be predictable, while Math.random() is explicitly designed for
general-purpose use and is completely unsuitable for cryptographic purposes.
Using these functions for generating session tokens, CSRF tokens, password reset
tokens, encryption keys, or other security-critical values allows attackers to
predict future outputs by observing previous values. This predictability can lead
to session hijacking, authentication bypass, or complete compromise of
cryptographic protections.
 📘 Learn More

AI Remediation

The code previously used Math.random() to generate part of a document UUID, which is not cryptographically secure and could allow an attacker to predict values. The fix replaces it with crypto.randomBytes(), which uses the operating system's secure random number generator to provide unpredictability and improved security for generated identifiers.

Suggested change

	uuid: `doc-${Math.random().toString(36).slice(2, 8)}`,
	uuid: `doc-${require('crypto').randomBytes(4).toString('hex')}`,