type-breakdown

Type Breakdown

Walk the user through the requested code paths, types, abstractions, and data flow.

Turn a broad plan into a concrete, type-driven implementation outline. Prefer pseudocode, type signatures, and execution structure over PRD-style prose.

Inspect the existing code before proposing new abstractions.

If the subject is simple, keep the walkthrough concise. Otherwise, use the structure below as a reference. Do not follow it rigidly when a section does not apply.

Use these markers:

[existing]  Confirmed in the codebase
[inferred]  Implied by the current implementation
[proposed]  Introduced by this plan
[?]         Unresolved

Execution Tree

Start from the entry point and expand the call path recursively in execution order.

For every relevant call, show:

• Fully qualified function, method, class, or module name
• File where it is defined
• Parent file and call site
• Responsibility
• Input and output types
• Data transformations
• Side effects
• Possible errors
• Child calls

Use this format:

▼ [existing] CheckoutController.create
  defined: src/checkout/api/CheckoutController.ts:24
  input:   CreateCheckoutRequest
  output:  Promise<HttpResponse<CreateCheckoutResponse>>

  └─▶ [existing] CreateCheckout.execute
      defined: src/checkout/application/CreateCheckout.ts:18
      called:  CheckoutController.ts:42
      input:   CreateCheckoutCommand
      output:  Result<Checkout, CreateCheckoutError>
      effects: reads customer, writes checkout

      ├─▶ CustomerRepository.find
      ├─▶ Checkout.create
      └─▶ CheckoutRepository.save

Use × N for repeated calls over collections. Do not invent line numbers when they are unavailable.

Type Flow

Show how data becomes progressively more constrained:

unknown
  → CreateCheckoutRequest
  → CreateCheckoutCommand
  → ResolvedCheckoutInput
  → Checkout
  → CheckoutRow
  → CreateCheckoutResponse

Identify the validation or transformation responsible for each transition.