Shipping Automation — Module 5: Courier Approval & Set Ship Date

System: Shipping Automation (Module 5 / Asana "Part 2") Source repositories (read-only): lifeinteriors/shipping-v6-nswo, lifeinteriors/shipping-v6-swo Source of truth for intent: Miro board "Module 2 V6.1 — Courier Approval & Set Ship Date" Interactive documentation: https://claude.ai/code/artifact/56822bef-4dc2-4a69-b87b-bc913a87004b Status: Documented from code + Miro board + live saved-search data + fulfilment schedule sheet.

This entry captures the business logic of the courier-approval automation. Per the access policy, the logic is recorded here, not changed in the source repositories.

1. Summary

When a customer's order is paid and ready, the automation decides which courier should carry it and what date it ships, writes the approval back to NetSuite, and only sets aside the orders that don't fit the rules for a human to review.

It is delivered as two AWS Lambda functions with near-identical architecture, split by order type:

The two flows run as one system: Flow 1 (nswo) runs first, then Flow 2 (swo). An order can be promoted from Flow 1 to Flow 2.

2. Business logic (plain language)

Written for the fulfilment team.

In one line: the system looks at orders that are ready, works out the best courier and delivery day for each, and books it in automatically — asking a person to step in only when an order doesn't fit the rules.

The two piles of orders

• Send as it's ready — parts of the order can go out as stock lands (Ship Complete = No).
• Send all together — the customer's whole order must arrive in one go (Ship Complete = Yes).

An order can move from the first pile to the second if it's meant to travel with another order. The "send all together" pile is always handled second.

When an order is "ready" (all must be true)

• Paid in full (nothing owing)
• Not on hold
• Not already booked with a courier
• Not already approved or closed
• No drop-ship items
• Items are Standard or 2-Man goods
• No ship date already set in the past
• At least one item still to send

A "send all together" order also waits until every item across the linked orders is in stock.

Picking the courier

The paid service level (Standard / 2-Man / Full Service) sets the list of couriers to try, in preferred order. For each, the system checks whether it covers the delivery postcode; the first that covers it wins.

• If none cover it → use the courier the customer picked at checkout, unless that was "To Be Confirmed", in which case hold the order for review.
• If a Standard order contains an item needing 2-Man handling → upgrade the whole order to 2-Man.

Picking the day

Earliest sensible day, respecting the courier's notice period, the customer's requested date, and (for Life trucks) whether the truck for that region still has room that day.

• NSW / ACT (local): ship and deliver on the same day.
• QLD / VIC (interstate): goods travel by linehaul, so the ship date is set to the weekly linehaul day — Tuesday for Brisbane, Thursday for Melbourne.
• Other states on a Life truck: not supported — left for review.

Outcomes

Approved · Approved (upgraded) · Approved (customer's online pick) · Held for review · Waiting (missing stock — retries next run).

3. Entry gate & flow

flowchart TD
  ST([Order is ready]) --> SC{Ship Complete?}
  SC -->|No| F1["Flow 1 · nswo (search 7132)"]
  SC -->|Yes| F2["Flow 2 · swo (search 7136)"]
  F1 --> STG{Ships together<br/>with another order?}
  STG -->|Yes| FLIP["Set Ship Complete = Yes<br/>→ picked up by Flow 2"]
  STG -->|No| CSL1[Courier Service Level]
  F2 --> AIC{All items committed?}
  AIC -->|No| IG[Skip - wait for next run]
  AIC -->|Yes| CSL2[Courier Service Level]
  FLIP -. next run .-> F2

Saved-search entry criteria ("Sales Orders NSSS")

An order only enters when all hold:

• Sales order balance owing = 0
• At least 1 item not shipped
• "Exported to Courier" = false
• "Hold Order" = false
• "Courier Approval" = false
• Orders / items not closed
• No item has a Drop Ship PO
• Item default shipping method is 2 Man Sensitive or Standard
• Ship Date not on/before today OR Ship Date empty & "Reason for service change" empty

4. Courier routing by service level

First courier whose postcode check passes wins (each courier has a whitelist CSV in S3).

Postcode check & front-end rate-card fallback

flowchart TD
  C[Next courier in hierarchy] --> P{Postcode valid?}
  P -->|Valid| AP["Approve · reason 15"]
  P -->|Invalid| MORE{More couriers to try?}
  MORE -->|Yes| C
  MORE -->|No| FE{Front-end pick is TBC?}
  FE -->|Yes| DIS["Disapprove · reason 5 (board shows 10)"]
  FE -->|No| RC["Approve customer's rate-card pick · reason 14"]

5. Ship date, CBM capacity & linehaul

Base date = SO committed date / today, or the CX requested date when it is later than the SO committed date or the PO dispatch date (SO_cxRequestedDate in nswo; maxCxRequestedDate across the group in swo).

flowchart TD
  DC[Date Check base date] --> LIFE{Is Life courier?}
  LIFE -->|No| SHIP[Add Ship Date only]
  LIFE -->|Yes| STATE{Destination state}
  STATE -->|NSW / ACT| NSW["Ship Date = Scheduled Delivery Date (same day)"]
  STATE -->|QLD| QLD["Delivery date + Ship = Tuesday before + Linehaul SYD to BRIS"]
  STATE -->|VIC| VIC["Delivery date + Ship = Thursday before + Linehaul SYD to MEL"]

• Buffer: non-Life count business days; Life trucks may count weekend days when marked available in the schedule sheet.
• CBM: for Life trucks, capacity is checked against the schedule sheet per region (limited to the first few candidate dates); capacity is reserved on selection. Ordering resolved by which SO was placed first.
• Schedule/CBM loop: schedule check → if no available date, ignore order + error email; else CBM check → fits ⇒ approve, else find next available date and repeat.
• Life deliveries to states other than NSW/VIC/QLD are rejected (no partial update).

The above is the current behaviour. A revised date model is planned — see below.

Planned change — ship date, SDD & linehaul

Status: planned — not yet implemented in shipping-v6-nswo / shipping-v6-swo. Documented here ahead of the code change; until it ships, the current logic above applies.

The revised model computes the ship date first and derives the delivery date forward, and it removes the fixed weekly linehaul weekday (Tue/Thu) anchoring.

flowchart TD
  B["today + 1 + buffer"]:::state --> LIFE{"Is Life courier?"}:::dec
  LIFE -->|"No"| SH1(["Ship Date — no SDD"]):::ok
  LIFE -->|"Yes · NSW/ACT"| SH2(["Ship Date = SDD"]):::ok
  LIFE -->|"Yes · VIC/QLD"| SH3(["Ship Date = Line Haul Date"]):::ok --> SDD3(["SDD = Ship Date + 1 + buffer"]):::ok
  classDef state fill:#e5e7eb,stroke:#c3cdd8,color:#1f2937
  classDef ok fill:#33a866,stroke:#268a52,color:#fff
  classDef dec fill:#f0932b,stroke:#c96a1f,color:#fff

What changes vs the current (OLD) logic:

When this ships, §11 (Workflow map, diagram 4) and the linehaul test cases in §12 (group F) should be updated to match.

6. Approval reason codes

⚠️ Board vs code mismatch: the disapprove note is labelled (10) on the Miro board, but every deployed config sets N_RFSC_DIS_PCODENOTCOV = 5. Treat 5 as the live value; confirm in NetSuite.

7. Courier schedule sheet (fulfilment-owned)

A Google Sheet (single tab INTEGRATION SCHEUDULE) maintained by the fulfilment team. The Courier Schedule microservice reads it; the automation only reads it.

Layout: columns A–H are per-courier/truck settings; every following column is one calendar day with a TRUE/FALSE availability flag.

Two dedicated linehaul rows mark departure days (toggleable per week):

• LINEHAUL - VIC — every Thursday (SYD → MEL)
• LINEHAUL - QLD — every Tuesday (SYD → BRIS)

Rules baked into the sheet:

• Life availability sets the scheduled delivery date; other couriers set the ship date.
• Buffers exclude weekends unless the weekend day is selected (e.g. order Thursday, buffer 3 → Fri + Mon + Tue; if Saturday available → Fri + Sat + Mon).
• Tiebreak: prefer the lower-CBM truck — "all loaded first".
• One Life row's three NetSuite IDs serve Standard, 2 Man, and Full Service ship-vias at once.

8. Input data — saved-search source

Each flow is fed by a NetSuite saved search returning one row per order line (rows sharing SO_internalID belong to the same order).

SO_shipTogetherWithID (7136 only) is the internal ID of another SO this order must ship with — the field mergeSalesOrders follows to build ship-together groups. Search 7132 omits it, which is why nswo has no merge step.

Key columns: SO_postcode/SO_state (postcode + linehaul), SO_shipVia/SO_shipViaId (current courier), SO_lifeRegion/SO_lifeTruckNumber (scheduling/CBM), SO_cxRequestedDate, SO_courierServiceLevel (paid level), item_defaultShippingMethod (item mix), item_packageCBM (× committed qty = CBM), item_qtyCommitted (drives the "all committed?" gate).

Ship-via reference (from live data): 3420 = TBC · 201100 = Life 2 Man · 247628 = Life Standard · 253939 = Life Full Service · 112729 = TLC · 112728 = Pedemont · 17186 = AusPost · 39973 = Allied · 2864 = Designer Transport.

Customer requested delivery date

Field: SO_cxRequestedDate — the date the customer asked to receive the order by. Present in both saved searches, format DD/MM/YYYY, and may be blank. For a merged swo group the automation uses maxCxRequestedDate — the latest requested date across all linked orders — so the whole group lands on or after the latest customer ask.

How it's used: it sets a floor on the scheduled date. The Date Check base date is the SO committed date / today, or the CX requested date when that is later than the committed / PO dispatch date. The chosen ship/delivery date is then the first valid courier day on or after that floor. Blank = no customer preference → the courier buffer governs instead.

Ship together with this order

Field: SO_shipTogetherWithID — the internal ID of another sales order this order must be delivered with. Present only in the 7136 (swo) search; blank means the order ships on its own.

It drives two mechanisms:

1. Flow 1 (nswo): an order flagged to ship together with another SO has its Ship Complete set to Yes, so it drops out of Flow 1 and is picked up by Flow 2 (swo) on the next run. (nswo's search has no SO_shipTogetherWithID column — this is the "Ships together with another SO?" gate.)
2. Flow 2 (swo): mergeSalesOrders follows SO_shipTogetherWithID to build a group, which:
   • ships together — updateGroupedSalesOrders writes the same courier + dates to every linked SO;
   • only proceeds when every item across all linked SOs is committed (allSOsCommitted) — otherwise the whole group waits;
   • uses group totals — total CBM across all items, and maxCxRequestedDate;
   • pulls in a linked SO that isn't in the search results via SuiteQL (ns.getSalesOrder).

flowchart TD
  subgraph N["Flow 1 · nswo"]
    O1["Order flagged to ship<br/>together with another SO"]:::state --> Q{"Linked to<br/>another SO?"}:::dec
    Q -->|"Yes"| P["Set Ship Complete = Yes<br/>→ picked up by Flow 2"]:::branch
    Q -->|"No"| C1["Process on its own"]:::ok
  end
  subgraph S["Flow 2 · swo"]
    G["mergeSalesOrders follows<br/>SO_shipTogetherWithID"]:::state --> AC{"All items across<br/>the group committed?"}:::dec
    AC -->|"No"| W["Group waits<br/>(nothing booked)"]:::note
    AC -->|"Yes"| U["updateGroupedSalesOrders —<br/>same courier + dates to every linked SO"]:::ok
  end
  classDef state fill:#e5e7eb,stroke:#c3cdd8,color:#1f2937
  classDef dec fill:#f0932b,stroke:#c96a1f,color:#fff
  classDef branch fill:#fdf3c4,stroke:#e6d270,color:#5b4d00
  classDef ok fill:#33a866,stroke:#268a52,color:#fff
  classDef note fill:#9aa5b1,stroke:#7c8894,color:#fff

Example (reciprocal group): a Float modular sofa split across two orders that reference each other:

They merge into one group (VIC 3754, Full Service). Because the third piece is 0/1, allSOsCommitted is false → the group waits, nothing is booked, and it retries next run once the piece is committed.

Data quirks:

• Self-reference: some rows set SO_shipTogetherWithID to their own internal ID (e.g. S311157, S312794) — a group of one; the merge logic tolerates it.
• Chains: links can chain (A↔B, B↔C) — the group is the whole connected set of orders.

9. Worked examples

Real orders traced end-to-end (dates computed from a 31 Jul 2026 run against the schedule sheet).

A · Local 2-Man (nswo) — S315316

NSW 2112, Syd R5 - North West, paid 2 Man, 2 items (Standard-Life), CBM 4.8 m³, CX date 30/10/2026. → Life 2 Man; CBM 4.8 vs 6 m³ truck (tight fit); CX date 30/10 overrides the 3-day buffer; NSW = local so ship = delivery on the first Syd R5 truck day on/after 30 Oct 2026. Approved (15).

B · Local Full Service (swo) — S308550

NSW 2040, Syd R4 - West, paid Full Service, 1 item, CBM 1.39 m³, no CX date. → Life Full; CBM fits 16 m³; 3-day buffer → ship & deliver Fri 7 Aug 2026. Approved (15).

C · Interstate QLD linehaul (swo, merged) — S310492 + S310562

QLD 4173, Bris R3 - East, Full Service, both orders committed, group CBM 0.74 m³. → Life Full; fits 13 m³ truck; latest CX date (5/7/2026) is past so 7-day buffer applies; first Bris R3 truck day = deliver Tue 18 Aug 2026; QLD linehaul → ship Tue 11 Aug 2026 (SYD → BRIS), applied to both linked orders. Approved (15).

D · Merged group — waiting (swo) — S301287 + S306157

VIC 3754, Full Service, a Float modular sofa split across two linked orders; one piece 0/1 in stock. → allSOsCommitted = false → whole group skipped this run, retried next run when the last piece is committed. Waiting — nothing booked.

10. Known divergences & things to watch

• Disapprove reason: board shows (10); config sets N_RFSC_DIS_PCODENOTCOV = 5. Confirm in NetSuite.
• TT (Two Man): no postcode CSV → always fails its postcode check in practice.
• All-AusPost 2-Man orders: routed to manual review, not auto-processed.
• Standard → 2-Man upgrade: a margin loss (customer paid Standard); the front-end rate card is the noted pain point.
• Board is titled "Module 2" while the repos' package.json call this "Module 5" — same stage, different naming.
• nswo config keys: queryHelper/rds reference config.AWS_RDS_DBNAME and several libs read config.AWS_REGION, but neither key is defined in nswo config (resolve to undefined). swo defines AWS_REGION and sources the DB name from Secrets Manager.

11. Workflow map

The whole courier-approval flow as a colour-coded workflow, styled after the Module 2 V6.1 board. ①②③ mark reusable sub-flows referenced across the map.

Legend: 🟨 start · 🟧 process / decision hub · ⬜ courier / state · 🟦 postcode check / ship-via · 🟩 approve / set date · ⬛ ignore · ①②③ sub-flow

1 · Dispatch — which flow an order enters

flowchart TD
  START(["START"]):::start --> SC(("Ship Complete?")):::hub
  SC -->|"No — Flow 1 · nswo"| S2["Saved search 7132"]:::branch
  SC -->|"Yes — Flow 2 · swo"| S1["Saved search 7136"]:::branch
  S2 --> STG(("Ships together<br/>with another SO?")):::hub
  STG -->|"Yes"| FLIP["Set Ship Complete = Yes<br/>→ Flow 2 next run"]:::branch
  STG -->|"No"| CSLn(("Courier<br/>Service Level")):::hub
  S1 --> AIC(("All items<br/>committed?")):::hub
  AIC -->|"No"| IG["Ignore"]:::ignore
  AIC -->|"Yes"| CSLs(("Courier<br/>Service Level")):::hub
  classDef start fill:#f6d64a,stroke:#caa72a,color:#3a2f00
  classDef hub fill:#ef8a3c,stroke:#c96a1f,color:#fff
  classDef branch fill:#fdf3c4,stroke:#e6d270,color:#5b4d00
  classDef ignore fill:#1f2937,stroke:#111827,color:#fff

2 · Courier hierarchy & approval (Full Service · ① Two Man)

flowchart TD
  subgraph FS["Full Service — swo"]
    direction LR
    LFS(["Life Full Service"]):::state --> PFS["Postcode Check"]:::pc
    PFS -->|"Valid"| AFS(["Approve · 15"]):::ok
    PFS -->|"Invalid"| DFS(["DT Full Service"]):::state --> PDF["Postcode Check"]:::pc
    PDF -->|"Valid"| ADF(["Approve · 15"]):::ok
    TLC(["TLC — auto-approved"]):::state --> ATL(["Approve · 15"]):::ok
  end
  subgraph TM["① Two Man — nswo + swo"]
    direction LR
    L2(["Life 2 Man"]):::state --> P2["Postcode Check"]:::pc
    P2 -->|"Valid"| A2(["Approve · 15"]):::ok
    P2 -->|"Invalid"| D2(["DT 2 Man"]):::state --> PD2["Postcode Check"]:::pc
    PD2 -->|"Valid"| A2
    PD2 -->|"Invalid"| PE(["Pedemont"]):::state --> PPE["Postcode Check"]:::pc
    PPE -->|"Valid"| A2
    PPE -->|"Invalid"| TT(["TT — no postcode file, fails"]):::state --> PTT["Postcode Check"]:::pc
    PTT -->|"Valid"| A2
    PTT -->|"Invalid"| FE{"FE courier<br/>= TBC?"}:::dec
    FE -->|"Yes"| DIS(["Disapprove · 5"]):::note
    FE -->|"No"| RC(["Approve — Rate Card · 14"]):::ok
  end
  classDef state fill:#e5e7eb,stroke:#c3cdd8,color:#1f2937
  classDef pc fill:#5b8def,stroke:#3a6fd0,color:#fff
  classDef ok fill:#33a866,stroke:#268a52,color:#fff
  classDef note fill:#9aa5b1,stroke:#7c8894,color:#fff
  classDef dec fill:#f0932b,stroke:#c96a1f,color:#fff

3 · Standard item routing (nswo)

flowchart TD
  CIL(("Check ITEM<br/>Logistic Service")):::hub
  CIL --> B1["1+ item is 2 Man"]:::branch --> J1(("① jump to<br/>2-Man logic")):::hub --> N21(["Approve · 21<br/>premium upgrade"]):::ok
  CIL --> B2["≥1 item Standard_Life"]:::branch --> PL["Postcode · Life Std"]:::pc
  PL -->|"Valid"| SVL["Ship Via → Life Std"]:::pc --> AL(["Approve · 15"]):::ok
  PL -->|"Invalid"| PDA["Postcode · DT ATL"]:::pc
  PDA -->|"Valid"| SVD["Ship Via → DT ATL"]:::pc --> AD(["Approve · 15"]):::ok
  PDA -->|"Invalid"| FE2{"FE = TBC?"}:::dec
  FE2 -->|"Yes"| DIS2(["Disapprove · 5"]):::note
  FE2 -->|"No"| RC2(["Approve — Rate Card · 14"]):::ok
  CIL --> B3["All Standard_Auspost"]:::branch --> AAP["Ship Via → AusPost"]:::pc --> OKA(["Approve · 15"]):::ok
  CIL --> B4["All / ≥1 Standard"]:::branch --> AAL["Ship Via → Allied"]:::pc --> OKL(["Approve · 15"]):::ok
  classDef hub fill:#ef8a3c,stroke:#c96a1f,color:#fff
  classDef branch fill:#fdf3c4,stroke:#e6d270,color:#5b4d00
  classDef pc fill:#5b8def,stroke:#3a6fd0,color:#fff
  classDef ok fill:#33a866,stroke:#268a52,color:#fff
  classDef note fill:#9aa5b1,stroke:#7c8894,color:#fff
  classDef dec fill:#f0932b,stroke:#c96a1f,color:#fff

4 · ② Set the ship date — CBM & linehaul

flowchart TD
  DC["Date Check<br/>SO committed / today / CX requested"]:::state --> LIFE{"Is Life courier?"}:::dec
  LIFE -->|"No"| G3a(("③ Schedule<br/>+ CBM")):::hub --> SH(["Add Ship Date"]):::ok
  LIFE -->|"Yes"| NSW(["NSW + ACT"]):::state --> G3b(("③")):::hub --> SHb(["Add Ship Date"]):::ok --> DVb(["Add Scheduled<br/>Delivery Date"]):::ok
  LIFE -->|"Yes"| QLD(["QLD"]):::state --> G3c(("③")):::hub --> DVc(["Add Scheduled<br/>Delivery Date"]):::ok --> SHc(["Add Ship Date<br/>Tue before"]):::ok --> LHc(["Add Line Haul Date"]):::ok --> RTc(["Line Haul Route<br/>SYD → BRIS"]):::ok
  LIFE -->|"Yes"| VIC(["VIC"]):::state --> G3d(("③")):::hub --> DVd(["Add Scheduled<br/>Delivery Date"]):::ok --> SHd(["Add Ship Date<br/>Thu before"]):::ok --> LHd(["Add Line Haul Date"]):::ok --> RTd(["Line Haul Route<br/>SYD → MEL"]):::ok
  classDef state fill:#e5e7eb,stroke:#c3cdd8,color:#1f2937
  classDef hub fill:#ef8a3c,stroke:#c96a1f,color:#fff
  classDef ok fill:#33a866,stroke:#268a52,color:#fff
  classDef dec fill:#f0932b,stroke:#c96a1f,color:#fff

5 · ③ Schedule & CBM sub-flow (Life trucks)

flowchart LR
  SCH["Schedule Check<br/>Google Sheet"]:::state --> AV{"Available<br/>date?"}:::dec
  AV -->|"No"| ERR(["Ignore + Error email"]):::ignore
  AV -->|"Yes"| CBM["CBM Check<br/>Google Sheet"]:::state --> FIT{"Fit CBM?"}:::dec
  FIT -->|"Yes"| OKK(["Approve"]):::ok
  FIT -->|"No"| NX["Find next<br/>available date"]:::state --> SCH
  classDef state fill:#e5e7eb,stroke:#c3cdd8,color:#1f2937
  classDef ok fill:#33a866,stroke:#268a52,color:#fff
  classDef dec fill:#f0932b,stroke:#c96a1f,color:#fff
  classDef ignore fill:#1f2937,stroke:#111827,color:#fff

12. Test cases & UAT

Acceptance tests — scenario, input, and expected outcome for each rule. The Result column doubles as a sign-off sheet. Reason codes: 15 approved · 21 upgraded · 14 rate-card · 5 disapproved (postcode).

How to run UAT (staging)

• Environment: run on staging — AWS_LAMBDA_FUNCTION_VERSION=$LATEST selects the staging config (sandbox NetSuite, staging courier API).
• Dry-run first: swo exposes N_QUEUER_DRY_RUN, NS_SAVED_SEARCH_DRY_RUN, COURIER_SCHEDULE_API_DRY_RUN; nswo has AWS_RDS_IN_DRY_RUN + a courier dry-run. Trace decisions without writing to NetSuite.
• Seed: create a sandbox sales order that meets the entry criteria (paid, not on hold, not already approved, correct item shipping methods).
• Trigger: invoke the Lambda (manual kickoff / test.index.mjs).
• Verify in NetSuite: Courier Approval set, Ship Via updated, RFSC reason code, Ship Date + Scheduled Delivery Date (and linehaul fields for QLD/VIC). Check the logs; confirm no error email unless the case expects one.

A · Entry & eligibility (saved-search gating)

B · Flow routing (ship complete & grouping)

C · Courier selection by service level

D · Postcode validation & front-end fallback

E · Scheduling, CBM & buffer

F · Linehaul (Life couriers)

G · Edge cases & resilience

UAT sign-off

• ☐ Ran on staging (sandbox NetSuite) — dry-run traced, then a live staging write.
• ☐ Entry gating (A) — ineligible orders correctly excluded.
• ☐ Flow routing (B) — ship-together promotion & all-committed gate behave as expected.
• ☐ Courier selection (C) — every service-level path picks the right courier; Standard→2 Man upgrade fires.
• ☐ Postcode fallback (D) — rate-card approve (14) and TBC disapprove (5) both correct.
• ☐ Scheduling (E) & linehaul (F) — dates, CBM, buffer, and Tue/Thu linehaul verified.
• ☐ Reason codes (X2) match config; no unintended NetSuite writes during dry-run.
• ☐ Sign-off: name & date ____________________

13. Source references (read-only)

Business logic lives in these files (do not edit — read-only per the access policy):

• shipping-v6-nswo/controllers/app.mjs, shipping-v6-swo/controllers/app.mjs — main decision loop
• helper/courierScheduleClient.mjs — buffers, CBM, date selection
• helper/formatter.mjs — order formatting (swo adds mergeSalesOrders)
• controllers/ns.mjs — NetSuite writes (swo adds updateGroupedSalesOrders)
• controllers/aws.mjs — postcode validation, S3, SES
• helper/enums.mjs — couriers & service levels
• config/{staging,production}.mjs — reason codes, saved-search IDs

Full architecture, repo differences, and file-by-file reference are in the interactive documentation: https://claude.ai/code/artifact/56822bef-4dc2-4a69-b87b-bc913a87004b