@crvouga/mockingbird-service-junction 3.7.0 → 3.8.0

package/CHANGELOG.md

@@ -1,6 +1,23 @@
 # Changelog — @crvouga/mockingbird-service-junction
 
-## 3.7.0 (2026-10-19)
+## 3.8.0 (2026-10-21)
+
+### Features
+
+- raise the serve and fleet body limit to the S3 maximum ([86b9e2b](https://github.com/crvouga/mockingbird/commit/86b9e2b80bcaaaef57f52edbac50b27da0b42f33))
+
+### Fixes and improvements
+
+- finish junction, notion and bedrock docs and tests ([f1b4ccb](https://github.com/crvouga/mockingbird/commit/f1b4ccb4441144b5151b536aaacc8519b2e86075))
+- lab account and cancel parity fixes ([cd61107](https://github.com/crvouga/mockingbird/commit/cd61107577e07dda2d8598409f4c23d998c91f49))
+
+## 3.7.1 (2026-10-20)
+
+### Fixes and improvements
+
+- resolve issues without an oracle gate ([96e84be](https://github.com/crvouga/mockingbird/commit/96e84be3964a0baa5d8d82c59339d4bbc264b1a6))
+
+## 3.7.0 (2026-10-18)
 
 ### Features
 

package/README.md

@@ -408,7 +408,7 @@ are validated but do not change the price, and no other charge components are mo
 Both routes follow the published contract
 ([markers](https://docs.junction.com/api-reference/lab-testing/biomarkers),
 [estimate](https://docs.junction.com/api-reference/lab-testing/estimate-order-set-pricing)); neither
-has been compared with the live sandbox (prices are contract-owned), so their parity is disabled and
+has been compared with the live sandbox (prices are contract-owned; best guess, not oracle-verified), so their parity is disabled and
 the 400 messages for unknown tests/markers are borrowed from `create_order`.
 
 `addOnSourceMarkers: true` (`--add-on-source-markers`) makes each biomarker line of an add-on order
@@ -417,7 +417,9 @@ default result lines carry no `source_markers`, and was reported from a sandbox
 been re-verified.
 
 `GET /v3/lab_tests` lists every lab test unless filtered; pass `status=active` to exclude inactive
-ones. The documented default of that filter is not stated, so the emulator does not change it.
+ones. The documented default of that filter is not stated, so the emulator does not change it:
+default-excludes-inactive (as #470 reports) is an unverified claim and is **not implemented**
+(best guess, not oracle-verified; `junction.markers-overlays.test.ts` pins the current contract).
 
 ## Lab accounts
 
@@ -549,7 +551,8 @@ accepts `client_bill` when no account is named). No account at any lab lists DC,
 either. `bioreference_current_platform`, `quest_sandbox_platform` and `sonora_quest_production_platform`
 follow listings an agent
 reported from `GET /v3/lab_test/lab_account` (a consumer-audit report with synthetic ids, not a
-repository probe); the older presets keep their shapes so pinned suites do not change.
+repository probe, so **best guess, not oracle-verified**); the older presets keep their shapes so
+pinned suites do not change.
 
 Every preset is `status: "active"` unless named `suspended_*`. `GET /__admin/lab-accounts/presets`
 returns the full records, the deprecated `aliases`, and the `synthetic` presets (not a recorded
@@ -1049,43 +1052,100 @@ from the public contract, **not measured production parity**. Both `expected-con
 and `sandbox-observed` return the persisted account association in POST/GET; a synthetic
 requisition uses that same stored provider account number.
 
-`sandbox-observed` uses explicit, account-owned observations, never a global delegated
-account billing override. For example, with synthetic fixture IDs:
+For [#440](https://github.com/crvouga/mockingbird/issues/440), the scoped account-owned
+billing control is a **best guess, not oracle-verified**. The reporter observed an explicit
+`client_bill` refusal for a root-selected delegated BioReference account even though its listing
+allowed that billing in AZ. They reported `400 {"detail":"Lab 13 does not support billing type patient_bill_passthrough"}`
+in the sandbox and the same error with `Lab 14` in production, including sandbox panel/add-on,
+home/walk-in and physician-present controls. These are report-derived errors; neither their
+cause nor a general vendor billing rule has been established. The repository's
+[2026-10-20 sanitized probe](https://github.com/crvouga/mockingbird/actions/runs/39397939244)
+could not find matching account/test inventory, recorded no order observations and created no
+user or orders. This evidence limit does not prevent a suite from testing the explicit fallback.
+
+Configure the reported refusal against the ID of a synthetic account loaded by `labAccounts`
+or your corpus. For example:
 
 ```ts
 import { createRuntime } from "@crvouga/mockingbird-service-junction"
 
+const delegatedAccountId = "11111111-1111-4111-8111-111111111111"
 const runtime = createRuntime({
+  labAccounts: [{
+    id: delegatedAccountId,
+    lab: "bioreference",
+    org_id: "55555555-5555-4555-8555-555555555555",
+    delegated_flow: "order_delegated",
+    allowed_billing: { client_bill: ["AZ"] },
+  }],
   labAccountBehavior: {
-    profile: "sandbox-observed",
+    profile: "observed",
+    oracle: "sandbox",
     accounts: {
-      "synthetic-delegated-id": {
+      [delegatedAccountId]: {
         rejectBilling: { client_bill: "Lab 13 does not support billing type patient_bill_passthrough" },
       },
-      "synthetic-ny-id": { allowBilling: { client_bill: ["NY", "NJ"] } },
     },
   },
 })
 ```
 
-These controls encode the independently reported observations in #440/#441. For #440 the
-reporter states that production returns the same refusal for a delegated BioReference
-account with explicit `client_bill` ("Lab 14 ..." there, "Lab 13 ..." in the sandbox);
-that is a reported observation, not a repository probe, and the vendor has not explained it,
-so no billing rule is built in. Exceptions apply only to explicit
-root account IDs and explicit billing. `defaultBillingTypes` still governs omitted
-billing independently. `GET/PUT /__admin/lab-account-behavior` inspect/change one
+Load a BioReference panel or marker catalog in the same runtime's corpus, then submit your
+normal valid order with root `lab_account_id: delegatedAccountId` and
+`billing_type: "client_bill"`. This configuration returns the exact configured 400 detail before
+creating an order or webhook, including when `physician` is present. It applies to both panel
+and add-on orders and home/walk-in collection. To model the production report, choose
+`oracle: "production"` and change the configured detail to `Lab 14 ...`; the oracle label
+describes the intended environment, not proof of verification. `sandbox-observed` remains an
+alias for `observed` with `oracle: "sandbox"`.
+
+The fallback is deliberately narrow: only that listed account's explicit root ID and explicit
+billing activate `rejectBilling`. Other delegated accounts keep their own policies. Omitting
+`billing_type` still uses `defaultBillingTypes` (or `client_bill` when no default is configured)
+and checks the account's listed billing. Thus this fixture accepts an omitted default
+`client_bill` even though it refuses explicit `client_bill`; configuring an omitted
+`patient_bill_passthrough` default rejects because the account lacks that billing, independently
+of `rejectBilling`. This distinction is the chosen emulator contract, not a verified production
+omission behavior. Nested-only IDs do not select the customer account. In the sandbox profile
+they follow the platform fallback with null POST/GET association; a successful root-selected
+account retains its persisted ID on both responses. Never treat nested-only acceptance as a
+successful delegated-account selection or retry a rejected customer order by dropping its ID.
+
+These controls do not model why Junction overrides the requested billing, validate physician
+selection, or establish any production omission/returned-identity rule. Native behavior remains
+the default. The separately reported NY/NJ acceptance uses the
+[`allowBilling` positive control](#explicit-nynj-customer-account-billing-441) below.
+`GET/PUT /__admin/lab-account-behavior` inspect/change one
 namespace's policy; changes survive its reset and never affect another namespace.
 Unknown profile names are rejected. CLI/server equivalents are `--lab-account-profile`
 and `--lab-account-sandbox-policies <json-file>` (the account-policy object).
 
 `sandbox-observed` also encodes the owner-recorded October 2026 sandbox omission controls
-(#439), which are recorded observations, not a live repository probe: an order whose
+(#439), which are recorded observations, **best guess, not oracle-verified by this repository**
+(its sandbox probe still finds no matching account inventory; no live POST/GET identity
+comparison has been run here): an order whose
 **root** `lab_account_id` is omitted, nested only in `order_set`, or an unknown UUID is
 placed on the lab's platform account (`lab_account_id: null` on POST and GET, no listed
 `allowed_billing` check), while a root ID naming a listed account keeps its identity and
 policy. `expected-contract` keeps the strict behavior (unknown ID → 400, omission → the
-house account).
+house account). The `native` profile keeps its historical response shape (no `lab_account_id`
+on the order); the explicit profiles return the stored association, never the requested id, so a
+test that asserts identity on both POST and an independent GET cannot pass on an ignored id.
+`junction.account-profiles.test.ts` holds the positive control and the six negative controls.
+
+#### Explicit Junction-owned account in an uncovered state (#494)
+
+Under `sandbox-observed` (or `observed` with `oracle: "sandbox"`), a **root** `lab_account_id`
+naming a Junction-owned account (`org_id: null`) whose listing has no billing type for the
+patient's state is refused with `400 {"detail":"Lab <lab name> does not support state <ST>"}`
+(for example `Lab BioReference does not support state AZ`) before any billing-type check, and no
+order or webhook is created. This follows the reported sandbox refusal (2026-10-19); it is a
+**best guess, not oracle-verified** here, and the reporter did not re-probe a covered state. It is
+kept apart from the billing-type message (`Lab 13 does not support billing type ...`) that a
+customer-owned account returns. A state that the account lists for another billing type keeps the
+billing message, an account-owned `allowBilling` exception counts as coverage, and
+customer-owned accounts, `native`, `expected-contract` and the production oracle keep their
+existing messages (the state rule is a sandbox observation only).
 
 The explicit profiles also accept `order_set.add_on` with `provider_ids` or `marker_ids`
 from one lab's configured marker catalog. The selected markers determine the synthetic
@@ -1096,6 +1156,54 @@ an order; requested add-on markers are never silently discarded.
 Panel and custom orders share account/billing checks for home and walk-in collection.
 The native profile keeps its existing panel-only contract.
 
+### Explicit NY/NJ customer-account billing (#441)
+
+The positive control for [#441](https://github.com/crvouga/mockingbird/issues/441) is a
+**best guess, not oracle-verified**. The reporter observed a non-delegated customer-owned
+BioReference account accepting explicit `client_bill` in NY despite advertising only
+`patient_bill_passthrough` for NY/NJ. The reported POST and independent GET both retained
+the requested account ID and `client_bill`. The
+[public billing rules](https://docs.junction.com/lab/overview/lab-accounts#billing-types)
+require the requested billing type and patient state to be listed; they do not establish this
+account-specific exception. The repository's
+[2026-10-20 sandbox probe](https://github.com/crvouga/mockingbird/actions/runs/39397939244)
+returned `complete: false` with `matching account inventory unavailable`, no observations and
+no resources created. No vendor acceptance was verified by that run.
+
+Load a synthetic active BioReference customer account with `delegated_flow: "not_delegated"`
+and `allowed_billing: { patient_bill_passthrough: ["NY", "NJ"] }`, plus an orderable
+BioReference panel. Set `labAccountBehavior` to the following, replacing the synthetic UUID
+with that fixture account's ID:
+
+```json
+{
+  "profile": "observed",
+  "oracle": "sandbox",
+  "accounts": {
+    "22222222-2222-4222-8222-222222222222": {
+      "allowBilling": { "client_bill": ["NY", "NJ"] }
+    }
+  }
+}
+```
+
+Submit a valid order with that ID at the root `lab_account_id`, explicit
+`billing_type: "client_bill"` and a NY or NJ patient address. POST and independent GET
+preserve both the selected account ID and `client_bill`; the account listing still advertises
+only its original `patient_bill_passthrough` states. This models an ordering exception without
+rewriting inventory or changing the requested billing. Including NJ is an explicit fixture
+assumption from the reported NY/NJ account, not an observed NJ oracle response.
+
+The exception applies only to the configured account, explicit billing type and configured
+states under `observed` (or its `sandbox-observed` alias). An unconfigured account or a state
+outside NY/NJ still fails the listed billing/state checks. Omitting `billing_type` evaluates
+`defaultBillingTypes` against the listed account billing: the default `client_bill` rejects,
+while an explicitly configured `patient_bill_passthrough` default accepts in NY/NJ and is
+returned as such. Native and `expected-contract` profiles retain their existing validation.
+The separate delegated refusal in #440 still requires its own `rejectBilling` entry; neither
+control establishes a universal rule based on delegation or lab. See
+`junction.account-profiles.test.ts` for the acceptance cases and strict negative controls.
+
 ### Observed profile and oracle label
 
 `profile: "observed"` with `oracle: "sandbox" | "production"` is the general form of
@@ -1106,8 +1214,9 @@ account and never as a blanket delegated-account rule: a delegated customer acco
 explicit `client_bill` only when its own entry says so. The October 2026 sandbox omission
 recordings (#439) are sandbox observations, so they apply only to `oracle: "sandbox"`; with
 `oracle: "production"` an omitted account selects the house account as `expected-contract`
-does. Whether production also refuses a delegated account when `billing_type` is omitted is
-unverified, so it is not modelled. `oracle` on any other profile, or `production` on the
+does, except that the production oracle defaults `omittedAccountBilling` to
+`{ bioreference: "unchecked" }` (#495, below). Whether production also refuses a delegated account
+when `billing_type` is omitted is unverified, so it is not modelled. `oracle` on any other profile, or `production` on the
 `sandbox-observed` alias, is refused.
 
 ### Omitted house-account billing (#467)
@@ -1116,7 +1225,13 @@ A reporter observed production accepting an AZ `client_bill` order with no `lab_
 a team whose house BioReference account lists only `patient_bill_passthrough` for NY and NJ,
 placing it on the house account (its requisition prints the house account number). That is a
 single consumer report, not a repository probe, so the default is unchanged (the listing is
-enforced). Opt in per lab:
+enforced). `profile: "observed", oracle: "production"` is the named profile for this
+production recording (#495) and turns it on for BioReference by default, **best guess, not
+oracle-verified** (sandbox, by contrast, places an omitted-id order on the platform account with a
+null association, see #439 above). With it, an omitted `lab_account_id` places the order on the
+Junction-owned account, the requisition names that account's number, and the account listing is
+unchanged (it still lists `client_bill` for no state). Set `omittedAccountBilling: { bioreference:
+"listed" }` to turn it off. For any other profile, opt in per lab:
 
 ```ts
 import { createRuntime } from "@crvouga/mockingbird-service-junction"
@@ -1153,7 +1268,9 @@ Behaviors the sandbox shows that clients must tolerate, every one off by default
 | --- | --- |
 | `sameSecondCancelStatus` (#474) | `POST /v3/order/{id}/cancel` in the same wall-clock second as the order's creation records a `cancelled.<method>.cancelled` event with the same timestamp, but `status`, `last_event` and `updated_at` stay `received`; a repeat cancel is a no-op. A cancel at least one second later reads back `cancelled`. |
 
-This was reported from the sandbox (not re-measured here, production unverified). The quirk does
+This was reported from the sandbox (not re-measured here, production unverified), so it is a
+**best guess, not oracle-verified**. It is off by default; a client that tests it should read the
+event log and wait at least a second between creating and cancelling. The quirk does
 not publish a webhook or cascade-cancel appointments for the stale cancel; the report does not say
 what the vendor does there.
 

package/SUPPORT.md

@@ -25,7 +25,7 @@ Generated from `openapi.yaml`; do not edit by hand.
 | `get_markers_v3_lab_tests_markers_get` | `GET /v3/lab_tests/markers` | ✅ supported | ❌ disabled | the marker inventory is the team's catalog (and any configured marker catalog); prices and availability are account-owned, so the emulator models the documented shape and filters, not a live inventory |
 | `get_markers_for_lab_test_v3_lab_tests__lab_test_id__markers_get` | `GET /v3/lab_tests/{lab_test_id}/markers` | ✅ supported | ✅ |  |
 | `list_order_set_markers_v3_lab_tests_list_order_set_markers_post` | `POST /v3/lab_tests/list_order_set_markers` | ✅ supported | ✅ |  |
-| `create_order_v3_order_post` | `POST /v3/order` | ✅ supported | ✅ | Native profile parity only; explicit account profiles add fixture-owned billing policies and custom-marker orders, without production parity certification. |
+| `create_order_v3_order_post` | `POST /v3/order` | ✅ supported | ✅ | Native profile parity only; explicit account profiles add fixture-owned billing policies and custom-marker orders as a best guess, not oracle-verified. Account-specific billing refusals and NY/NJ explicit client_bill acceptance (#441) are opt-in report-derived behavior, not a global vendor rule; the acceptance preserves POST/GET account identity and billing without changing advertised allowed_billing. The sandbox-observed omission/nested/unknown-id controls (#439), the explicit Junction-owned account state refusal (#494) and the production-oracle omitted-id house-account placement (#495) are recorded or reported observations, best guess, not oracle-verified by this repository. |
 | `get_area_info_v3_order_area_info_get` | `GET /v3/order/area/info` | ✅ supported | ❌ disabled | central_labs presence, within_radius counts and getlabs market coverage are provider-owned geo data that an emulator cannot replicate per-zip; covered by the client-parity scenario shape checks instead |
 | `get_psc_info_v3_order_psc_info_get` | `GET /v3/order/psc/info` | ✅ supported | ❌ disabled | patient_service_centers are real site inventories per zip (thousands of sites, result-capped at 30) that a fixture emulator cannot replicate per-zip; covered by the client-parity scenario shape checks instead |
 | `get_phlebotomy_appointment_availability_v3_order_phlebotomy_appointment_availability_post` | `POST /v3/order/phlebotomy/appointment/availability` | ✅ supported | ❌ disabled | availability slots are provider-side data whose values shift between sandbox calls; covered by the emulator-internal scheduling property suite instead |
@@ -41,7 +41,7 @@ Generated from `openapi.yaml`; do not edit by hand.
 | `reschedule_psc_appointment_v3_order__order_id__psc_appointment_reschedule_patch` | `PATCH /v3/order/{order_id}/psc/appointment/reschedule` | ✅ supported | ❌ disabled | rescheduling depends on live provider slot state; covered by the emulator-internal scheduling property suite instead |
 | `cancel_psc_appointment_v3_order__order_id__psc_appointment_cancel_patch` | `PATCH /v3/order/{order_id}/psc/appointment/cancel` | ✅ supported | ❌ disabled | cancellation depends on live provider appointment state; covered by the emulator-internal scheduling property suite instead |
 | `get_order_v3_order__order_id__get` | `GET /v3/order/{order_id}` | ✅ supported | ✅ |  |
-| `cancel_order_v3_order__order_id__cancel_post` | `POST /v3/order/{order_id}/cancel` | ✅ supported | ✅ |  |
+| `cancel_order_v3_order__order_id__cancel_post` | `POST /v3/order/{order_id}/cancel` | ✅ supported | ✅ | Default cancel always reads back cancelled; the sandbox same-second stale-status behavior is the opt-in quirk sameSecondCancelStatus (#474), reported from the sandbox, best guess, not oracle-verified. |
 | `simulate_order_v3_order__order_id__test_post` | `POST /v3/order/{order_id}/test` | ✅ supported | ✅ |  |
 | `get_result_raw_v3_order__order_id__result_get` | `GET /v3/order/{order_id}/result` | ✅ supported | ❌ disabled | results carry provider-side specimen data; covered by the emulator-internal results property suite instead |
 | `get_result_metadata_v3_order__order_id__result_metadata_get` | `GET /v3/order/{order_id}/result/metadata` | ✅ supported | ✅ |  |

package/dist/{chunk-NTGGNJKR.js → chunk-3KASXIUZ.js}

@@ -13,7 +13,7 @@ import {
   pullCorpus,
   resolveAdminPrefix,
   restoreClock
-} from "./chunk-27N4VA23.js";
+} from "./chunk-GYYWJPZH.js";
 import {
   defaultCorpus
 } from "./chunk-2FZJPMTR.js";
@@ -3070,7 +3070,7 @@ async function preflightFleet(config, options) {
             break;
         }
       }
-      targets.set(name, { ...target, packageVersion: packageVersion ?? "3.7.0" });
+      targets.set(name, { ...target, packageVersion: packageVersion ?? "3.8.0" });
     } catch (error) {
       throw new Error(`service ${name}: ${error instanceof Error ? error.message : String(error)}`, { cause: error });
     }
@@ -3296,7 +3296,11 @@ var serve = async (api, options = {}) => {
 // ../../adapters/node/dist/listen.js
 var listen = async (api, options = {}) => {
   const host = options.host ?? "127.0.0.1";
-  const server = await serve(api, { port: options.port ?? 0, host });
+  const server = await serve(api, {
+    port: options.port ?? 0,
+    host,
+    ...options.maxBodyBytes !== void 0 ? { maxBodyBytes: options.maxBodyBytes } : {}
+  });
   const address = server.address();
   const port = typeof address === "object" && address !== null ? address.port : options.port ?? 0;
   const shown = host.includes(":") ? `[${host}]` : host;
@@ -3495,7 +3499,8 @@ var httpChild = async (target, entry, options, admission, generation, privateAcc
   try {
     server = await listen(api, {
       port: entry.port ?? target.defaultPort,
-      host: entry.host ?? "127.0.0.1"
+      host: entry.host ?? "127.0.0.1",
+      ...target.maxBodyBytes !== void 0 ? { maxBodyBytes: target.maxBodyBytes } : {}
     });
     target.listening?.(server);
   } catch (error) {
@@ -4886,7 +4891,11 @@ var start = async (target, values, config) => {
   });
   if (config.idBase !== void 0)
     runtime.setIdBase?.(config.idBase);
-  const listening = await listen(runtime, { port: config.port, host: config.host });
+  const listening = await listen(runtime, {
+    port: config.port,
+    host: config.host,
+    ...target.maxBodyBytes !== void 0 ? { maxBodyBytes: target.maxBodyBytes } : {}
+  });
   target.listening?.(listening);
   console.log(`${target.name} emulator listening on ${listening.url}`);
   console.log(`${target.name} health: GET ${listening.url}${adminPrefix}/health`);
@@ -5255,4 +5264,4 @@ export {
   createServer2 as createServer,
   serveTarget
 };
-//# sourceMappingURL=chunk-NTGGNJKR.js.map
+//# sourceMappingURL=chunk-3KASXIUZ.js.map