@crvouga/mockingbird-service-junction 3.4.0 → 3.5.0

package/CHANGELOG.md

@@ -1,5 +1,11 @@
 # Changelog — @crvouga/mockingbird-service-junction
 
+## 3.5.0 (2026-10-16)
+
+### Features
+
+- resolve SQL, routing and writer gaps ([73f97d0](https://github.com/crvouga/mockingbird/commit/73f97d0d2379f44b9131180498f4fab76648fed9))
+
 ## 3.4.0 (2026-10-15)
 
 ### Features

package/DISCOVERY.md

@@ -41,6 +41,8 @@ repository; live parity is an additional oracle check, not a substitute for the
 - `GET /__admin/metrics`
 - `GET /__admin/faults/presets`
 - `GET /__admin/ui`
+- `GET/PUT /__admin/lab-account-omission-policies`
+- `GET/PUT /__admin/requisitions/:id`
 
 For HTTP services, use `x-mockingbird-namespace` (or the documented credential/path carrier) so
 parallel tests do not share state. Admin state, journal, metrics and fault-preset endpoints are

package/README.md

@@ -330,23 +330,31 @@ invented.
 
 ## Lab accounts
 
-`create_order` routes, accepts and rejects `lab_account_id` against the team's lab accounts, the
-way the sandbox does: an explicit id must exist, be linked to the team and be active; with no id,
-one active account for the lab is selected, several select the first listed, and a lab with none
-falls back to Junction's platform account. The billing type must be allowed in the patient's
-state by the account's `allowed_billing`.
-
-Two of Junction's documented rules are **not** enforced by the sandbox, so the emulator does not
-enforce them either. An id naming another lab's account is accepted and the order is placed with
-that account (the guide says it must be "associated with the lab selected for the order"):
-recorded in `corpus/lab-account-probes.json`, where a Labcorp test ordered through Junction's
-BioReference account was placed, and reported live by a consumer's team
-([#138](https://github.com/crvouga/mockingbird/issues/138)). An omitted id while several active
-accounts are linked for the lab places the order (the guide says it "may be rejected"): reported
-live by a consumer's team ([#136](https://github.com/crvouga/mockingbird/issues/136)); the
-sandbox team the parity run uses has one account per lab, so `verify --orders` checks it whenever
-a corpus has such a lab. Which of the several accounts the sandbox bills through is not visible
-from outside; the emulator uses the first listed.
+`create_order` selects explicit linked accounts in either `active` or `ready_to_launch`
+status. With no id, exactly one orderable linked account is selected. Multiple orderable
+accounts use the per-lab `labAccountOmissionPolicies` control (`platform`, the default, or
+`reject`). Platform selection uses an orderable linked account with `org_id: null`, or an
+opaque platform account for a supported platform lab. It never chooses a customer account
+by listing order. With no linked accounts, supported labs use the platform; with linked
+accounts but none orderable, ordering fails. Billing type and patient state are checked
+against the selected account. This follows the
+[Junction guide](https://docs.junction.com/lab/overview/lab-accounts); the choice between
+platform fallback and rejection varies by lab/team, so configure `reject` where appropriate.
+Set `{ labAccountOmissionPolicies: { bioreference: "platform" } }` at runtime creation, or
+`PUT /__admin/lab-account-omission-policies` with `{ "policies": { "bioreference": "reject" } }`.
+`GET` reads the effective overrides. Overrides are namespace isolated and kept across reset.
+
+Explicit ids naming another lab's account remain accepted, matching the sandbox probe in
+`corpus/lab-account-probes.json` and [#138](https://github.com/crvouga/mockingbird/issues/138).
+Delegation alone does not change account selection.
+
+Requisition PDFs are synthetic and contain labelled `Account number:` evidence copied from
+the selected account's `provider_account_id` **when the order is created**. Later account edits,
+reordering or routing changes cannot change that evidence. Opaque platform accounts show
+`unknown`. Use `GET /__admin/requisitions/:id` to inspect it, or `PUT` with
+`{ "provider_account_id": "MOCK-CUSTOMER" }` (or `null` for explicitly unknown evidence) to
+install a namespace-isolated fixture. Reset removes the orders and their requisition fixtures.
+This models account evidence, not a vendor's exact PDF layout or proof of a real association.
 
 Junction's order (`ClientFacingOrder`) has no `lab_account_id`, so neither does the emulator's: not on
 the create response, `GET /v3/order/{id}`, `GET /v3/orders` or webhooks. The account an order was
@@ -705,8 +713,8 @@ An emulator that is silent about its gaps is how a green suite starts lying. Spe
     accounts is not reproduced. Run `verify --orders` with your team's corpus to check what you rely on.
   - Rate limits and outages, except when injected as faults or switched on as
     [limits](#sandbox-limits).
-  - Which of several active accounts for a lab the sandbox bills an order through when
-    `lab_account_id` is omitted (see [Lab accounts](#lab-accounts)); the emulator uses the first listed.
+  - Lab/team-specific omission defaults must be configured through `labAccountOmissionPolicies`
+    (see [Lab accounts](#lab-accounts)); exact vendor requisition layout is not modelled.
   - Adopted users (`adopt-users`) have `client_user_id` equal to their `user_id`; nothing in
     Junction corresponds to adoption.
   - Real 429 / 5xx bodies: the presets are plausible, not recorded.

package/SUPPORT.md

@@ -44,7 +44,7 @@ Generated from `openapi.yaml`; do not edit by hand.
 | `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 | ✅ |  |
 | `get_result_pdf_v3_order__order_id__result_pdf_get` | `GET /v3/order/{order_id}/result/pdf` | ✅ supported | ❌ disabled | PDF bytes are provider-rendered; compared by shape (byteLength) only in the scenario script |
-| `get_order_requisition_pdf_v3_order__order_id__requisition_pdf_get` | `GET /v3/order/{order_id}/requisition/pdf` | ✅ supported | ❌ disabled | PDF bytes are provider-rendered; compared by shape (byteLength) only in the scenario script |
+| `get_order_requisition_pdf_v3_order__order_id__requisition_pdf_get` | `GET /v3/order/{order_id}/requisition/pdf` | ✅ supported | ❌ disabled | Synthetic PDF includes persisted selected provider account number or unknown; admin evidence override supported; live comparison remains shape-only |
 | `get_orders_v3_orders_get` | `GET /v3/orders` | ✅ supported | ✅ |  |
 | `get_order_transaction_v3_order_transaction__transaction_id__get` | `GET /v3/order_transaction/{transaction_id}` | ✅ supported | ❌ disabled | order transactions are not available to the sandbox team (feature not available) |
 | `get_order_transaction_result_v3_order_transaction__transaction_id__result_get` | `GET /v3/order_transaction/{transaction_id}/result` | ✅ supported | ❌ disabled | lab results are not available to the sandbox team (feature not available) |