@crvouga/mockingbird-service-junction 3.6.1 → 3.7.1

package/CHANGELOG.md

@@ -1,5 +1,21 @@
 # Changelog — @crvouga/mockingbird-service-junction
 
+## 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
+
+- resolve the agent-reported issue queue in one batch ([25c52b6](https://github.com/crvouga/mockingbird/commit/25c52b668a53ddb80b968419601a20abf33f956b))
+
+### Fixes and improvements
+
+- record reported production refusal for delegated explicit client_bill ([3525699](https://github.com/crvouga/mockingbird/commit/35256996166f4f8ddcf25f16b7fcca2ca72c1a38))
+
 ## 3.6.1 (2026-10-18)
 
 ### Fixes and improvements

package/README.md

@@ -56,7 +56,11 @@ npx mockingbird-junction serve --help
 | `--port <n>` | `8787` | Port to listen on (`0` for any free port; the bound URL is printed) |
 | `--host <host>` | `127.0.0.1` | Interface to bind |
 | `--corpus <default\|none\|file>` | `default` | The shipped corpus, no corpus (synthetic data), or a file from `corpus pull` |
-| `--geo <corpus\|synthetic>` | `corpus` with a corpus | How unknown ZIPs are answered; see [Geo](#geo-corpus-or-synthetic) |
+| `--geo <corpus\|synthetic\|corpus+synthetic>` | `corpus` with a corpus | How unknown ZIPs are answered; see [Geo](#geo-corpus-or-synthetic) |
+| `--zip-overlays <file>` | — | [ZIP aliases and per-ZIP overrides](#hybrid-geo-and-zip-overlays) |
+| `--catalog-overlays <file>` | — | [Lab tests derived from catalog ones](#catalog-overlays-and-a-la-carte-markers) at boot |
+| `--marker-catalog <file>` | — | Markers `GET /v3/lab_tests/markers` offers, with [pricing](#catalog-overlays-and-a-la-carte-markers) |
+| `--add-on-source-markers` | off | Name the markers behind each add-on result line |
 | `--lab-accounts <file>` | built-in fixtures | [Lab accounts](#lab-accounts): a JSON array, or `{ "presets": [...], "accounts": [...] }` |
 | `--team-id <uuid>` | the corpus's team | The [team](#team-identity) the emulator answers as |
 | `--max-users <n>` | unlimited | Enforce the sandbox's [live-user cap](#sandbox-limits) |
@@ -245,10 +249,11 @@ Every Mockingbird service answers the same control surface, outside the vendor's
 | `GET` / `POST` / `DELETE /__admin/faults` | List, add or clear [fault rules](#faults-and-error-shapes) (`DELETE ?id=` removes one) |
 | `POST /__admin/faults/presets/{name}` | Add a named Junction fault; body may override `count`, `rate`, `operationId`… |
 | `GET /__admin/metrics` | Requests by operation and status, fault count, and **unmatched routes** |
-| `GET /__admin/orders` | Orders in the namespace with their current status and the `lab_account_id` each was placed with (`null`: Junction's platform account) |
+| `GET /__admin/orders` | Orders in the namespace with their current status, the `lab_account_id` each was placed with (`null`: Junction's platform account) and `lab_account_request` (below) |
 | `POST /__admin/orders/{id}/transition` | Move an order: `{ "to": "completed", "result": "abnormal" }` ([order control](#order-control)) |
 | `GET` / `PUT /__admin/results/{id}` | Read or install an exact result payload / PDF for an order |
 | `GET /__admin/result-fixtures` | The named results |
+| `GET` / `PUT /__admin/quirks` | Read or replace the namespace's opt-in [sandbox quirks](#sandbox-quirks) (`{ "quirks": { "sameSecondCancelStatus": true } }`) |
 | `GET` / `PUT /__admin/lab-accounts` | Read or replace the namespace's [lab accounts](#lab-accounts) (`{ "accounts": [...], "presets": [...] }`; `{ "accounts": null }` restores the default) |
 | `POST /__admin/lab-accounts` | Add one account; 409 if the id exists |
 | `PATCH` / `DELETE /__admin/lab-accounts/{id}` | Merge fields into an account (`{ "status": "suspended" }`, `{ "states": [...] }`) / remove it; 404 if absent |
@@ -328,6 +333,92 @@ a radius with no recording, or any read with parameters the corpus did not recor
 `--geo synthetic` the derivation still applies, and only reads with nothing to derive from are
 invented.
 
+### Hybrid geo and ZIP overlays
+
+`--geo corpus+synthetic` (`geo: "corpus+synthetic"`) replays the recording for the ZIPs the corpus
+covers and synthesizes every other ZIP, so a suite needs no second, synthetic runtime as a
+fallback. A covered ZIP is still never answered next to its recording: a read the recording cannot
+answer (see above) refuses with the same 424 as `--geo corpus`. Switch it per namespace with
+`PUT /__admin/geo {"mode": "corpus+synthetic"}`.
+
+`zipOverlays` (`--zip-overlays <file>`, or `PUT /__admin/geo {"overlays": {...}}`) edits answers
+for individual ZIPs, in any geo mode:
+
+```json
+{
+  "aliases": { "07105": "85004" },
+  "overrides": { "07105": { "phlebotomy_served": true }, "10118": { "no_pscs": true } }
+}
+```
+
+An alias makes a ZIP answer as another one (coverage, recordings and the synthetic model all use
+the target; the response echoes the requested ZIP). `phlebotomy_served` sets
+`phlebotomy.is_served` (and `providers`) on `area/info`; `no_pscs` empties the `psc/info` list and
+zeroes the `within_radius` counts on `area/info`. An override is looked up by the requested ZIP,
+then by its alias target. Overlays are configuration: they survive `reset()`.
+
+The sealed sandbox recording agrees with the report behind this feature that NJ `07030` is not
+served for at-home phlebotomy, and the synthetic model reports `10118`, `11201`, `12207`, `07030`
+and `07601` as not served. It does not know that NJ `07105` is served (the synthetic model only
+serves a handful of ZIP prefixes), so set that one with an override.
+
+## Catalog overlays and a-la-carte markers
+
+**Catalog overlays** (`catalogOverlays`, `--catalog-overlays <file>`) add lab tests derived from
+ones the catalog already holds, with no network access, to every namespace at boot and again on
+every `reset()`:
+
+```ts
+import { createRuntime } from "@crvouga/mockingbird-service-junction"
+
+createRuntime({
+  catalogOverlays: [
+    {
+      from: "lipid_panel_athome", // id or slug of a catalog lab test (or an earlier overlay)
+      id: "aaaaaaaa-aaaa-4aaa-8aaa-aaaaaaaaaaaa",
+      name: "Lipid Panel: Quest",
+      slug: "lipid_panel_quest", // default: derived from name
+      lab: "sonora_quest", // a lab slug the catalog lists, or a lab record { id, slug, name, ... }
+      stripAoe: true, // markers lose their ask-on-order questions
+      autoGenerated: true, // lists with generation_method=auto, not by default
+    },
+  ],
+})
+```
+
+`method`, `price` (dollars) and `status` can be overridden too. Moving the clone to a lab gives its
+markers and expected results that lab's id. A bad overlay (unknown `from`, non-UUID or duplicate
+`id`, unknown `lab`) fails at boot naming `catalogOverlays[n].<field>`.
+
+**A-la-carte markers.** `GET /v3/lab_tests/markers` lists the markers a team can order one by one:
+those embedded in active catalog lab tests, plus `markerCatalog` entries (`--marker-catalog
+<file>`) with their own `price`, `pricing`, `aoe`, `expected_results` and `a_la_carte_enabled`. It
+takes `lab_id`, `lab_slug` (wins over `lab_id`), `name` (a name substring, or a provider test code),
+`a_la_carte_enabled`, `lab_account_id` (narrows to the account's lab), `include_pricing`, `page` and
+`size`, and answers `{ markers, total, page, size, pages }` (plus `pricing: { currency, data }` keyed
+by marker id for the page's markers with `include_pricing=true`). A marker price is read as dollars
+(`"12.50"` is `base_amount_minor: 1250`); `"N/A"` is `{ "unspecified": "price_unavailable" }`.
+
+`POST /v3/lab_test/estimate_order_set_pricing` prices each order set (`lab_test_ids` and/or
+`add_on.marker_ids` / `provider_ids`) as one `lab_charge` component: the sum of the lab tests'
+`price` and the add-on markers' prices, with a `marker_breakdown` for add-ons. If any add-on marker
+has no stated price the whole estimate is `price_unavailable`. `modality`, `us_state` and `billing`
+are validated but do not change the price, and no other charge components are modelled.
+
+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
+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
+carry `source_markers: [{ marker_id, name, slug, provider_id }]`. It is off by default, because the
+default result lines carry no `source_markers`, and was reported from a sandbox probe that has not
+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.
+
 ## Lab accounts
 
 `create_order` selects explicit linked accounts in either `active` or `ready_to_launch`
@@ -445,8 +536,21 @@ but NJ, NY and RI (47).
 | `bioreference_platform` | `bioreference` | `not_delegated` | `client_bill`: `PLATFORM_ACCOUNT_STATES` | `[]` | recorded ("Junction BioReference Account") |
 | `bioreference_patient_bill_passthrough` | `bioreference` | `not_delegated` | `patient_bill_passthrough`: NJ, NY | the team | recorded |
 | `quest_platform` / `labcorp_platform` | `quest` / `labcorp` | `not_delegated` | `client_bill`: `PLATFORM_ACCOUNT_STATES` | `[]` | recorded ("Junction Quest/Labcorp Account") |
+| `bioreference_current_platform` | `bioreference` | `not_delegated` | `patient_bill_passthrough`: NJ, NY | `[]` | team listing reported 2026-10-18 (#475) |
+| `quest_sandbox_platform` | `quest` | `not_delegated` | `client_bill`: `PLATFORM_ACCOUNT_STATES`; `commercial_insurance`: all 50 | `[]` | sandbox listing reported 2026-10-18 (#475) |
+| `sonora_quest_production_platform` | `sonora_quest` | `not_delegated` | `client_bill`: `PLATFORM_ACCOUNT_STATES` | `[]` | production listing reported 2026-10-18 (#475) |
 | `suspended_bioreference` / `suspended_quest` / `suspended_labcorp` | as above | `not_delegated` | as the platform accounts | `[]` | the platform shapes with `status: "suspended"` |
 
+The September recording's `bioreference_platform` is **illustrative, not a current listing**: the
+house BioReference account now lists only `patient_bill_passthrough` for NJ and NY (use
+`bioreference_current_platform`, and see
+[omitted house-account billing](#omitted-house-account-billing-467) for how production still
+accepts `client_bill` when no account is named). No account at any lab lists DC, so no preset does
+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.
+
 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
 account). `bioreference_customer_multi_state` is a deprecated alias of `bioreference_platform`: it
@@ -584,6 +688,8 @@ valid choices, never approximated. `result` picks a named result — `normal`, `
 shape. For an exact payload, `PUT /__admin/results/{id}` with `{ "results": [...],
 "missing_results": null, "interpretation": "critical", "pdf_base64": "…" }`.
 
+**Same-second cancel.** See the opt-in [sandbox quirks](#sandbox-quirks).
+
 There is no `isTestCancelled` in Junction's contract; cancelling produces the vendor's
 `cancelled.<method>.cancelled` event and webhook, which is what a consumer derives that flag from.
 
@@ -630,6 +736,23 @@ so one worker's injected failure never lands on another's request; one added in-
 applies to every namespace unless given a `namespace`. Over HTTP: `POST /__admin/faults` with the same fields, or
 `POST /__admin/faults/presets/sandbox_user_quota`.
 
+A rule can also match on the request itself: `path`, `pathPattern`, `requestHeaders`, `query`, and
+`requestBody`, a map from a dotted path in the JSON body to the value it must equal. That targets
+one member when the backend sends no namespace header, with an optional `body` to answer with:
+
+```bash
+# Refuse one member's order
+curl -X POST localhost:8787/__admin/faults -d '{"method":"POST","path":"/v3/order",
+  "requestBody":{"patient_details.email":"member-a@example.test"},"status":503}'
+# No phlebotomy slots for one ZIP code
+curl -X POST localhost:8787/__admin/faults -d '{"method":"POST",
+  "pathPrefix":"/v3/order/phlebotomy/appointment/availability",
+  "requestBody":{"zip_code":"00000"},"status":200,"body":{"slots":[],"timezone":"America/Phoenix"}}'
+```
+
+A body that is missing, not JSON, or not a JSON object never matches. See the
+[fault rule reference](../../../docs/admin-controls/FAULTS.md#match-on-the-request-body).
+
 ## Webhooks
 
 With `webhooks` / `--webhook-url`, every event is delivered signed, with retries:
@@ -730,7 +853,7 @@ Main entry (`@crvouga/mockingbird-service-junction`, runtime-neutral):
 
 | Export | Description |
 | --- | --- |
-| `createRuntime` | `(options?: JunctionRuntimeOptions) => JunctionRuntime` — the served emulator (health, admin, namespaces, clock, faults, metrics, journal, webhooks) as one `fetch`. Options: `corpus`, `geo`, `labAccounts`, `teamId`, `limits`, `identity`, `defaultBillingTypes`, `fixtures`, `journalSize`, `webhooks`, `onWebhook`, `sqlite`, `clock`, `seed`, `adminKey`, `onLog`. |
+| `createRuntime` | `(options?: JunctionRuntimeOptions) => JunctionRuntime` — the served emulator (health, admin, namespaces, clock, faults, metrics, journal, webhooks) as one `fetch`. Options: `corpus`, `geo`, `zipOverlays`, `catalogOverlays`, `markerCatalog`, `addOnSourceMarkers`, `labAccounts`, `teamId`, `limits`, `identity`, `defaultBillingTypes`, `labAccountBehavior`, `quirks`, `fixtures`, `journalSize`, `webhooks`, `onWebhook`, `sqlite`, `clock`, `seed`, `adminKey`, `onLog`. |
 | `JunctionAPI` | Class. `new JunctionAPI(options?)`: one namespace's emulator, implementing `fetch(request: Request): Promise<Response>`. |
 | `JUNCTION_NAMESPACE` | `"junction"` — the default namespace's storage key when sharing a `sqlite` client. |
 | `document` | The vendored Junction OpenAPI document (Mockingbird subset) that drives routing. |
@@ -801,7 +924,8 @@ Main entry (`@crvouga/mockingbird-service-junction`, runtime-neutral):
 | `reset()` | `Promise<void>` — clear state; re-install the corpus or default catalog, and the configured lab accounts. |
 | `installCorpus(corpus)` | Install a `SealedCorpus`: observations (shared, read-only), catalog, labs, lab accounts, ZIP coverage. |
 | `corpusInfo()` | `CorpusInfo \| undefined` — label, recording date, source and counts. |
-| `geoMode` | `"corpus" \| "synthetic"`, settable. |
+| `geoMode` | `"corpus" \| "synthetic" \| "corpus+synthetic"`, settable. |
+| `zipOverlays` | [ZIP aliases and overrides](#hybrid-geo-and-zip-overlays) for this namespace; settable, kept across `reset()`. |
 | `configureLabAccounts(layout?)` / `labAccounts()` | Replace (a list, or `{ presets, accounts }`; `undefined` restores the default) / read the team's lab accounts. |
 | `addLabAccount(input)` / `addLabAccountPreset(name, id?)` / `patchLabAccount(id, patch)` / `removeLabAccount(id)` | Change one account; kept across `reset()`. |
 | `teamId` | The team this namespace answers as. |
@@ -828,7 +952,11 @@ type JunctionAPIOptions = {
   namespace?: string             // storage namespace; default "junction"
   now?: () => number             // clock in ms; default Date.now
   corpus?: SealedCorpus          // installed now and on every reset()
-  geo?: "corpus" | "synthetic"   // default "corpus" with a corpus, else "synthetic"
+  geo?: "corpus" | "synthetic" | "corpus+synthetic"   // default "corpus" with a corpus, else "synthetic"
+  zipOverlays?: { aliases?: Record<string, string>; overrides?: Record<string, { phlebotomy_served?: boolean; no_pscs?: boolean }> }
+  catalogOverlays?: CatalogOverlay[]    // lab tests cloned from catalog ones, now and on every reset()
+  markerCatalog?: MarkerCatalogEntry[]  // markers GET /v3/lab_tests/markers offers on top of the catalog's
+  addOnSourceMarkers?: boolean          // add-on result lines carry source_markers; default false
   labAccounts?: LabAccountInput[] | { presets?: (string | { name; id? })[]; accounts?: LabAccountInput[] }
   teamId?: string                // default: the corpus's recorded team, else MOCK_TEAM_ID
   limits?: { maxUsers?: number | null; simulateRequiresSandbox?: boolean; rateLimitPerSecond?: number | null }
@@ -921,29 +1049,71 @@ 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 sandbox observations in #440/#441;
-they do not establish production billing behavior. 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. For the separately reported NY/NJ exception in #441, `allowBilling` can map an
+explicit billing type to allowed states on that fixture's account, for example
+`{ allowBilling: { client_bill: ["NY", "NJ"] } }`; this too is a best guess, not oracle-verified.
+`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).
@@ -964,3 +1134,71 @@ until the combined-panel semantics are verified. Malformed add-ons also refuse w
 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.
+
+### Observed profile and oracle label
+
+`profile: "observed"` with `oracle: "sandbox" | "production"` is the general form of
+`sandbox-observed` (an alias that always reports `oracle: "sandbox"`), so
+`GET /__admin/lab-account-behavior` says which vendor environment a configuration reproduces.
+Account-owned `rejectBilling` / `allowBilling` observations apply to either oracle, per
+account and never as a blanket delegated-account rule: a delegated customer account refuses
+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
+`sandbox-observed` alias, is refused.
+
+### Omitted house-account billing (#467)
+
+A reporter observed production accepting an AZ `client_bill` order with no `lab_account_id` on
+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:
+
+```ts
+import { createRuntime } from "@crvouga/mockingbird-service-junction"
+
+createRuntime({
+  labAccountBehavior: {
+    profile: "expected-contract",
+    omittedAccountBilling: { bioreference: "unchecked" },
+  },
+})
+```
+
+With `unchecked`, an order whose **root** `lab_account_id` is omitted (a nested-only id is
+ignored) and that resolves to a Junction-owned account (`org_id: null`) skips that account's
+listed billing and state check. The order keeps the house account's identity on POST, GET and
+the requisition. Explicit selection of the house account keeps its listed policy (or an
+account-owned `rejectBilling`), and a customer-owned account chosen by routing keeps its own
+listing. `GET/PUT /__admin/lab-account-behavior` read and change `omittedAccountBilling`.
+
+### Where an order's account id was sent (#473)
+
+`GET /__admin/orders` adds `lab_account_request: { labAccountId, nestedLabAccountId }` per order
+(`instance().orderLabAccountRequest(id)`): the id carried at the request root, which selects
+the account, and the one nested in `order_set`, which Junction ignores. Each is `null` when
+absent. The request body itself is still not stored; orders seeded by a fixture have
+`lab_account_request: null`.
+
+### Sandbox quirks
+
+Behaviors the sandbox shows that clients must tolerate, every one off by default
+(`createRuntime({ quirks })`, or per namespace `GET/PUT /__admin/quirks`; they survive `reset()`).
+
+| Quirk | Effect |
+| --- | --- |
+| `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
+not publish a webhook or cascade-cancel appointments for the stale cancel; the report does not say
+what the vendor does there.
+
+### Requisition text layout (#464)
+
+The synthetic requisition PDF prints two text lines: `Requisition <order id>` and
+`Account number: <provider number>` (`unknown` when the order has no frozen number), so an
+extractor that accepts a field label only at the start of a line finds it. The layout is for
+interoperability, not vendor pixel fidelity.

package/SUPPORT.md

@@ -2,8 +2,8 @@
 
 Generated from `openapi.yaml`; do not edit by hand.
 
-- operations in spec: **40**
-- supported by the emulator: **40**
+- operations in spec: **42**
+- supported by the emulator: **42**
 - parity enabled: **22**
 
 | operationId | route | emulator | parity | notes |
@@ -17,13 +17,15 @@ Generated from `openapi.yaml`; do not edit by hand.
 | `patch_user_info_v2_user__user_id__info_patch` | `PATCH /v2/user/{user_id}/info` | ✅ supported | ✅ |  |
 | `get_latest_user_info_user_v2_user__user_id__info_latest_get` | `GET /v2/user/{user_id}/info/latest` | ✅ supported | ✅ |  |
 | `get_paginated_lab_tests_for_team_v3_lab_test_get` | `GET /v3/lab_test` | ✅ supported | ✅ |  |
+| `estimate_order_set_pricing_v3_lab_test_estimate_order_set_pricing_post` | `POST /v3/lab_test/estimate_order_set_pricing` | ✅ supported | ❌ disabled | prices are contract-owned; the emulator prices from the configured catalog (lab test price, marker price) and models the documented shape only |
 | `get_team_lab_accounts_v3_lab_test_lab_account_get` | `GET /v3/lab_test/lab_account` | ✅ supported | ❌ disabled | lab-account inventory is fixture-owned; the emulator models the documented shape, filters and routing rules, not a live account inventory |
 | `get_lab_tests_for_team_v3_lab_tests_get` | `GET /v3/lab_tests` | ✅ supported | ✅ |  |
 | `get_lab_test_for_team_v3_lab_tests__lab_test_id__get` | `GET /v3/lab_tests/{lab_test_id}` | ✅ supported | ✅ |  |
 | `get_labs_v3_lab_tests_labs_get` | `GET /v3/lab_tests/labs` | ✅ supported | ✅ |  |
+| `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 are opt-in report-derived behavior, not a global vendor rule. |
 | `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 |