• Goal: build a Parcel Monkey-like comparison experience on this site with dimensional + weight inputs, address intake, and a platform finder's fee at checkout.
• Recommended v1: aggregator API behind this app + Stripe Checkout, not one-by-one direct carrier integrations on day one.
• Later optional path: Stripe Connect application-fee model only if funds must be split to connected third parties.

1. Collect shipment data (origin, destination, weight, dimensions).
2. Validate and normalize addresses.
3. Create normalized shipment object.
4. Request rates across enabled carriers in one aggregator call.
5. Render service-rate cards with ETA + price.
6. User selects a rate.
7. Collect payment.
8. Purchase label for selected rate.
9. Store label URL + tracking + provider IDs for auditability.

1. Frontend quote card

   Ship-from, ship-to, weight, dimensions, units toggle (lb/in vs kg/cm), package type, quote action, then rate cards (cheapest/fastest/best-value badges).

2. Backend quote service

   Validate addresses, convert units, call aggregator, compute finder's fee server-side, return normalized safe quote objects.

3. Payment service

   Create checkout only after user selects a valid rate and always recompute totals server-side before payment.

• Preferred v1: single-platform checkout where customer pays shipping + finder's fee (+ optional insurance/tax), then platform buys label after successful payment.
• Finder's fee policy: configurable server-side rules such as fixed, percentage, or hybrid `max(fixed, percentage)`.
• Stripe recommendation: start with Checkout for launch speed; move to Payment Intents later if embedded checkout UX is required.

1. Never trust client totals; recompute server-side before payment creation.
2. Use idempotency to prevent duplicate checkout sessions and duplicate label purchases.
3. Treat rates as temporary; reject stale selections.
4. Persist provider IDs (`shipment_id`, `rate_id`, transaction/payment IDs, tracking number).
5. Log each stage (input -> quote -> payment -> webhook -> label purchase).
6. Hash quote inputs; invalidate selection if address/parcel changes.
7. Webhook-first fulfillment: buy label only after confirmed payment.

POST /api/shipping/validate-address
POST /api/shipping/quote
POST /api/shipping/select-rate
POST /api/payments/create-checkout-session
POST /api/payments/webhook
POST /api/shipping/purchase-label
GET  /api/shipping/quote/:quoteId
GET  /api/shipping/label/:shipmentId

1. Quote form + internal types
2. Address validation
3. Rates endpoint
4. Rate cards UI
5. Stripe Checkout session creation
6. Webhook fulfillment
7. Label purchase
8. Shipment success page

1. Phase 1 - Foundation: Linux CLI fluency + container image workflow + Kubernetes core objects.

   Run short daily kubectl drills (`get`, `describe`, `logs`, `exec`, `explain`) and summarize what each command proved.

2. Phase 2 - Core administration: cluster architecture, kubeadm workflow, scheduling controls, services, ingress, storage.

   Rotate one domain at a time with mission-first labs, then recreate fixes from memory.

3. Phase 3 - Troubleshooting emphasis: `CrashLoopBackOff`, `ImagePullBackOff`, DNS/service reachability, node readiness, rollout breakages.

   Use timed rounds: inspect -> isolate -> patch -> verify -> re-check.

4. Phase 4 - Exam simulation: full-length performance runs and documentation navigation speed.

   Use Killer.sh style mock tasks and strict per-task time limits with command-history review.