@crvouga/mockingbird-service-junction 2.3.1 → 3.1.0

package/CHANGELOG.md

@@ -1,5 +1,30 @@
 # Changelog — @crvouga/mockingbird-service-junction
 
+## 3.1.0 (2026-10-08)
+
+### Features
+
+- redesign emulator experience ([d6038c2](https://github.com/crvouga/mockingbird/commit/d6038c27eebbaa1751f02bc9305002a5b1304779))
+
+### Dependencies
+
+- `@crvouga/mockingbird-service-sqlite`
+
+## 3.0.0 (2026-10-07)
+
+### ⚠️ Breaking changes
+
+- point the repo at crvouga/mockingbird ([1bf35a4](https://github.com/crvouga/mockingbird/commit/1bf35a422b84a85b50b09b72bd7cc7093082a86e))
+- point the repo at crvouga/emulates ([cdb5e53](https://github.com/crvouga/mockingbird/commit/cdb5e536ed8c1f52345e3984f089001c25fdb08a))
+- rename Emulators to Emulates ([2e10d9c](https://github.com/crvouga/mockingbird/commit/2e10d9cff84c54ac37768fc9a19d1aefd3943744))
+- rebrand Mockingbird to Emulators ([1adca65](https://github.com/crvouga/mockingbird/commit/1adca65ce28242f11cff98eac05d2be88f680cbe))
+
+### Fixes and improvements
+
+- typecheck the brand gate before builds ([fc36095](https://github.com/crvouga/mockingbird/commit/fc3609514de70ffe3170a5d216fb8a49f9ce7cbb))
+- format the emulates records query ([8698872](https://github.com/crvouga/mockingbird/commit/8698872509d06002be5a8fcdc85d79f8462320c3))
+- preserve JSON prototype keys ([fba8e4d](https://github.com/crvouga/mockingbird/commit/fba8e4d2e4219d825f1ca705cabc44b5dbbb8f02))
+
 ## 2.3.1 (2026-10-05)
 
 ### Fixes and improvements

package/DISCOVERY.md

@@ -1,7 +1,7 @@
 # @crvouga/mockingbird-service-junction discovery
 
 This is the installed-package index for coding agents and tooling. All relative links resolve
-inside `node_modules/@crvouga/mockingbird-service-junction/`; no repository checkout is needed to discover the mock's
+inside `node_modules/@crvouga/mockingbird-service-junction/`; no repository checkout is needed to discover the emulator's
 supported surface or documented behavior.
 
 ## Capability and behavior sources
@@ -48,7 +48,7 @@ designed for assertions and diagnosis by consuming test suites.
 ## Report a mismatch or missing capability
 
 Follow the [agent reporting contract](https://github.com/crvouga/mockingbird/blob/main/docs/REPORTING_ISSUES.md). Include package version,
-operation/command, a minimal redacted request, actual mock result, expected oracle result or vendor
+operation/command, a minimal redacted request, actual emulator result, expected oracle result or vendor
 documentation, and whether the mismatch appears in the matrix. Never include keys, tokens,
 customer data, prompts, PHI, card data, or unredacted recordings.
 

package/README.md

@@ -1,8 +1,8 @@
 # @crvouga/mockingbird-service-junction
 
-> Familiar calls. Faithful echoes. Part of [Mockingbird](https://github.com/crvouga/mockingbird).
+> Local emulators. Real API contracts. Part of [Mockingbird](https://github.com/crvouga/mockingbird).
 
-Stateful mock of the [Junction (formerly Vital) API](https://docs.junction.com/): users
+Stateful emulator of the [Junction (formerly Vital) API](https://docs.junction.com/): users
 (`/v2/user`), the lab-testing catalog, lab orders (create, cancel, simulate, results,
 requisitions), at-home phlebotomy and patient-service-center (PSC) scheduling, and the
 `labtest.order.*` / `labtest.appointment.updated` webhooks. All 40 operations in the vendored
@@ -10,7 +10,7 @@ OpenAPI subset are served, and behaviour is checked by differential property tes
 Junction sandbox.
 
 Use it to take Junction off your suite's critical path: no sandbox key, no shared 50-user sandbox
-cap (the mock enforces no sandbox limit unless a test [asks for one](#sandbox-limits)), no
+cap (the emulator enforces no sandbox limit unless a test [asks for one](#sandbox-limits)), no
 cross-suite interference. Serve it as a local origin with one command, or run it in-process.
 
 ```bash
@@ -18,10 +18,10 @@ npx mockingbird-junction serve   # http://127.0.0.1:8787, recorded sandbox corpu
 ```
 
 - Operation coverage: [SUPPORT.md](https://github.com/crvouga/mockingbird/blob/main/packages/service/junction/SUPPORT.md)
-- Drop-in readiness and the sandbox quirks the mock mirrors:
+- Drop-in readiness and the sandbox quirks the emulator mirrors:
   [docs/drop-in.md](https://github.com/crvouga/mockingbird/blob/main/packages/service/junction/docs/drop-in.md)
 - Behaviour notes: [docs/behavior.md](https://github.com/crvouga/mockingbird/blob/main/packages/service/junction/docs/behavior.md)
-- **What the mock does not model:** [below](#what-is-and-is-not-modelled). Read it before trusting a
+- **What the emulator does not model:** [below](#what-is-and-is-not-modelled). Read it before trusting a
   green suite.
 
 ## Install
@@ -37,7 +37,7 @@ native dependencies: state lives in an in-memory SQLite engine written in TypeSc
 | --- | --- | --- |
 | `@crvouga/mockingbird-service-junction` | any (Node, Bun, Workers, browsers) | `JunctionAPI`, `createRuntime`, corpus and verify tools |
 | `@crvouga/mockingbird-service-junction/server` | Node | `createServer()` — a listening HTTP server |
-| `@crvouga/mockingbird-service-junction/corpus` | any | `defaultCorpus` — the recording shipped in the package (a separate entry, so importing the mock never parses it) |
+| `@crvouga/mockingbird-service-junction/corpus` | any | `defaultCorpus` — the recording shipped in the package (a separate entry, so importing the emulator never parses it) |
 | `mockingbird-junction` (bin) | Node | `serve`, `corpus pull`, `corpus diff`, `verify` |
 
 ## Usage
@@ -58,12 +58,12 @@ npx mockingbird-junction serve --help
 | `--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) |
 | `--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 mock answers as |
+| `--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) |
 | `--identity <strict\|adopt-users>` | `strict` | Unknown `user_id`s: 404, or [create on first use](#fixtures-and-identity) |
 | `--default-billing-type <lab=type,…>` | `client_bill` | The `billing_type` an order for that lab gets when it omits one ([billing](#default-billing-type)) |
 | `--fixtures <file>` | — | [Users and orders](#fixtures-and-identity) every namespace starts with |
-| `--journal-size <n>` | `1000` | Requests each namespace's [journal](#is-this-the-mock) keeps |
+| `--journal-size <n>` | `1000` | Requests each namespace's [journal](#is-this-the-emulator) keeps |
 | `--webhook-url <url>` / `--webhook-secret <whsec_…>` | off | Deliver [signed webhooks](#webhooks) (secret also from `MOCKINGBIRD_JUNCTION_WEBHOOK_SECRET`) |
 | `--webhook-retry-delays <ms,…>` | Svix's schedule | Delay before each delivery attempt, e.g. `0,1000,5000` in tests |
 | `--webhook-scope <scope>` | — | Sent as `x-mockingbird-scope` on every delivery |
@@ -124,7 +124,7 @@ or a loaded corpus). The result has `url`, `port`, `runtime` and `close()`.
 
 ### `createRuntime` (any Fetch server)
 
-`createRuntime` is the whole served mock — health, admin, namespaces, clock, faults, metrics — as a
+`createRuntime` is the whole served emulator — health, admin, namespaces, clock, faults, metrics — as a
 single runtime-neutral `fetch(request)`. Hand it to `Bun.serve`, a Worker, or call it directly:
 
 ```ts
@@ -199,7 +199,7 @@ const order = await call("POST", "/v3/order", {
 })
 console.log(order.status, (order.json.order as { id: string }).id) // 200 "<uuid>"
 
-// Every event the mock published, oldest first:
+// Every event the emulator published, oldest first:
 console.log(junction.webhookEvents().map((event) => event.event_type)) // ["labtest.order.created"]
 ```
 
@@ -239,8 +239,8 @@ Every Mockingbird service answers the same control surface, outside the vendor's
   through the admin API (lab accounts, limits, identity, geo) belongs to one namespace and survives
   that namespace's `POST /__admin/reset`; data does not.
 - `x-mockingbird: junction@<version>; ns=<namespace>` — on **every** response: vendor answers,
-  errors, faults, admin and health. Junction never sends it, so it tells the mock from the vendor
-  (see [Is this the mock?](#is-this-the-mock)).
+  errors, faults, admin and health. Junction never sends it, so it tells the emulator from the vendor
+  (see [Is this the emulator?](#is-this-the-emulator)).
 
 | Route | Does |
 | --- | --- |
@@ -270,7 +270,7 @@ Every Mockingbird service answers the same control surface, outside the vendor's
 | `DELETE /__admin/users/{id}` | Remove a user outright, leaving no deletion tombstone |
 | `POST /__admin/orders` | Insert an order, optionally already in a `status`, through `create_order`'s record builder |
 | `POST /__admin/import` | `{ "users": [...], "orders": [...] }` in one call |
-| `GET` / `DELETE /__admin/requests` | The namespace's [request journal](#is-this-the-mock) (`?operationId=`, `?status=`, `?since=`, `?limit=`, `?all=1`) / clear it |
+| `GET` / `DELETE /__admin/requests` | The namespace's [request journal](#is-this-the-emulator) (`?operationId=`, `?status=`, `?since=`, `?limit=`, `?all=1`) / clear it |
 | `GET /__admin/corpus`, `PUT /__admin/geo` | The loaded corpus; switch [geo mode](#geo-corpus-or-synthetic) |
 | `GET /__admin/webhooks` | [Deliveries](#webhooks) with every attempt |
 | `POST /__admin/webhooks/{id}/replay`, `POST /__admin/webhooks/flush` | Redeliver one message; run pending retries now |
@@ -283,7 +283,7 @@ a new SDK call shows up — as a count — before it fails a suite as a 404.
 
 Provider-owned inventory — area serviceability, PSC site lists, the lab catalog, labs, lab
 accounts — cannot be synthesized faithfully. A corpus is an exact recording of those
-parameter-stable reads, and the mock answers them byte for byte.
+parameter-stable reads, and the emulator answers them byte for byte.
 
 **The shipped corpus** (`defaultCorpus`, and what `serve` loads unless told otherwise) was recorded
 from the Junction sandbox. It covers area and PSC serviceability for 57 ZIPs across the US, the PSC
@@ -344,7 +344,7 @@ one active account for the lab is selected, several select the first listed, and
 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 mock does not
+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
@@ -354,9 +354,9 @@ accounts are linked for the lab places the order (the guide says it "may be reje
 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 mock uses the first listed.
+from outside; the emulator uses the first listed.
 
-Junction's order (`ClientFacingOrder`) has no `lab_account_id`, so neither does the mock's: not on
+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
 placed with is reported only by `GET /__admin/orders` and `instance().orderLabAccount(orderId)`.
 
@@ -455,7 +455,7 @@ works and keeps its own default id (`presetAccountId("bioreference_customer_mult
 
 ### Team identity
 
-The mock answers as one team: `team_id` on users, orders and webhooks, and the team that
+The emulator answers as one team: `team_id` on users, orders and webhooks, and the team that
 `team_id_allowlist` is checked against. It is, in order: `teamId` / `--team-id`, the team a
 version-2 corpus recorded (`corpus pull` reads it from a listed user, else from the accounts'
 allowlists), else the fixed `MOCK_TEAM_ID`. `GET /__admin/team` reports it.
@@ -463,18 +463,18 @@ allowlists), else the fixed `MOCK_TEAM_ID`. `GET /__admin/team` reports it.
 A version-2 corpus keeps each account's allowlist **verbatim**, so an account the real team is not
 linked to answers `400 {"detail": "Lab account is not linked to your team"}` exactly as it does
 live. A version-1 corpus (no `teamId`) still loads and behaves as 0.2.0 did: every recorded account
-is also linked to the mock team.
+is also linked to the emulator team.
 
 **Empty allowlists.** Junction's own Quest, Labcorp and BioReference accounts carry
-`team_id_allowlist: []`, and a real team's listing returns them, so the mock lists them and treats
+`team_id_allowlist: []`, and a real team's listing returns them, so the emulator lists them and treats
 them as linked. Ordering through one by explicit id, and with the id omitted when it is the lab's
 only active account, places the order on the sandbox (`corpus/lab-account-probes.json`, recorded
-by the parity run), as the mock does. `verify --orders` re-checks it whenever the corpus has such
+by the parity run), as the emulator does. `verify --orders` re-checks it whenever the corpus has such
 an account.
 
 ## Sandbox limits
 
-The mock exists to escape the sandbox's restrictions, so it enforces none of them unless a test
+The emulator exists to escape the sandbox's restrictions, so it enforces none of them unless a test
 asks — this is a tested guarantee (500 users in a loop all succeed), not an accident.
 
 | Sandbox limit | Modelled | Default | Turn it on |
@@ -508,7 +508,7 @@ curl -X POST localhost:8787/__admin/import -d @test/junction-fixtures.json
   user and lab test must exist (404 otherwise).
 - Inserted records go through the same builders as `create_user` / `create_order`, so every read
   path (`GET /v2/user/{id}`, resolve by `client_user_id`, `GET /v3/order/{id}`,
-  `GET /v3/orders?user_id=`) sees them as API-created. Default timestamps read the mock clock.
+  `GET /v3/orders?user_id=`) sees them as API-created. Default timestamps read the emulator clock.
 - **No webhook fires** unless the body has `"emitWebhooks": true`: fixtures should not trigger
   backend side effects.
 - `fixtures` / `--fixtures <file>` loads `{ "users": [...], "orders": [...] }` into every namespace
@@ -521,9 +521,9 @@ and the request proceeds. The journal marks the request `adopted: true`. **Order
 adopted**: an unknown order id always 404s, because inventing an order hides real bugs. The default,
 `strict`, is Junction's own behaviour.
 
-## Is this the mock?
+## Is this the emulator?
 
-A mock 404 and a sandbox 404 are byte-identical, which is how a backend half-pointed at the sandbox
+An emulator 404 and a sandbox 404 are byte-identical, which is how a backend half-pointed at the sandbox
 goes unnoticed. Three things make it visible:
 
 - **`x-mockingbird` on every response.** Assert on it in a test helper:
@@ -531,12 +531,12 @@ goes unnoticed. Three things make it visible:
   ```ts
   import { expect } from "vitest"
 
-  /** Wrap the fetch your Junction client uses; fails any call that did not reach the mock. */
+  /** Wrap the fetch your Junction client uses; fails any call that did not reach the emulator. */
   export const mockOnlyFetch =
     (inner: typeof fetch = fetch): typeof fetch =>
     async (input, init) => {
       const response = await inner(input, init)
-      expect(response.headers.get("x-mockingbird"), `${String(input)} did not reach the Junction mock`).toMatch(
+      expect(response.headers.get("x-mockingbird"), `${String(input)} did not reach the Junction emulator`).toMatch(
         /^junction@/,
       )
       return response
@@ -545,7 +545,7 @@ goes unnoticed. Three things make it visible:
 
 - **The request journal.** Each namespace keeps its last 1000 requests (`--journal-size`,
   `journalSize`): operation id, method, path, status, duration, fault id, the user / order /
-  lab-account ids it touched, and when (mock clock). `GET /__admin/requests?operationId=create_order_v3_order_post`
+  lab-account ids it touched, and when (emulator clock). `GET /__admin/requests?operationId=create_order_v3_order_post`
   proves an order was placed here; an empty answer proves it was not. Never bodies.
 - **Miss headers on 404s.** A missing user or order keeps Junction's body byte for byte and adds
   `x-mockingbird-miss: order <id>` (or `user <id>`, `user client:<client_user_id>`) and
@@ -592,7 +592,7 @@ delayed simulations (`?delay=<seconds>`) due and moves appointment windows, with
 
 ## Faults and error shapes
 
-Error bodies the mock reproduces byte for byte, checked against the sandbox by `verify` and the
+Error bodies the emulator reproduces byte for byte, checked against the sandbox by `verify` and the
 parity suite (`ORDER_NOT_FOUND` holds the unknown-order text per operation id):
 
 | Case | Status | Body |
@@ -639,7 +639,7 @@ With `webhooks` / `--webhook-url`, every event is delivered signed, with retries
   official `svix` verifier, and a receiver written for real Junction, accept it unchanged. (Signing
   `"<timestamp>.<body>"` without the message id, as this package's own server script did before,
   is not Svix-compatible.)
-- Timestamps are wall-clock even when the mock clock is moved, because receivers reject timestamps
+- Timestamps are wall-clock even when the emulator clock is moved, because receivers reject timestamps
   outside a few minutes of their own clock.
 - Any 2xx is delivered; anything else is retried on Svix's schedule (immediately, 5 s, 5 min,
   30 min, 2 h, 5 h, 10 h, 10 h) or `retryDelaysMs`. `POST /__admin/webhooks/flush` runs pending
@@ -669,7 +669,7 @@ console.log(typeof accept, junction.webhooks?.deliveries().length) // "function"
 
 ## Verify
 
-`verify` is the fidelity guarantee: it runs the same requests against real Junction and the mock
+`verify` is the fidelity guarantee: it runs the same requests against real Junction and the emulator
 and reports every divergence.
 
 ```bash
@@ -687,7 +687,7 @@ npx mockingbird-junction verify --real-key "$JUNCTION_SANDBOX_KEY" --orders --sa
   bodies must match in shape, and byte for byte for the documented error bodies.
 
 It exits 1 on any divergence. The scenario always deletes its user (and cancels its order), because
-it runs against the same capped sandbox the mock exists to relieve. `verifyAgainstReal` is the same
+it runs against the same capped sandbox the emulator exists to relieve. `verifyAgainstReal` is the same
 check as a function. This repo runs it in CI against the Junction sandbox.
 
 ## Determinism
@@ -700,7 +700,7 @@ availability, and which requests a partial-`rate` fault hits. Wall-clock by desi
 
 ## What is and is not modelled
 
-A mock that is silent about its gaps is how a green suite starts lying. Specifically:
+An emulator that is silent about its gaps is how a green suite starts lying. Specifically:
 
 - **Corpus-backed** (byte-exact): area and PSC serviceability for covered ZIPs; the catalog, labs,
   expected results and lab accounts of the team the corpus was recorded from.
@@ -714,11 +714,11 @@ A mock that is silent about its gaps is how a green suite starts lying. Specific
   - 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 mock uses the first listed.
+    `lab_account_id` is omitted (see [Lab accounts](#lab-accounts)); the emulator uses the first listed.
   - 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.
-  - Phlebotomy availability breadth: the sandbox serves it only for `85004`; the mock generates slots
+  - Phlebotomy availability breadth: the sandbox serves it only for `85004`; the emulator generates slots
     for any covered ZIP.
   - Webhook retry jitter across a snapshot restore (the jitter stream is not part of a snapshot).
   - Operations outside the vendored OpenAPI subset: they return 404 and are counted as
@@ -730,12 +730,12 @@ Main entry (`@crvouga/mockingbird-service-junction`, runtime-neutral):
 
 | Export | Description |
 | --- | --- |
-| `createRuntime` | `(options?: JunctionRuntimeOptions) => JunctionRuntime` — the served mock (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`. |
-| `JunctionAPI` | Class. `new JunctionAPI(options?)`: one namespace's mock, implementing `fetch(request: Request): Promise<Response>`. |
+| `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`. |
+| `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. |
 | `operationIds` | Every `operationId` in `document`. |
-| `supportedOperationIds` | The `operationId`s the mock implements (all of them). |
+| `supportedOperationIds` | The `operationId`s the emulator implements (all of them). |
 | `pullCorpus` | `(options: PullCorpusOptions) => Promise<SealedCorpus>` — record a corpus from a real team (GETs only). |
 | `diffCorpus` | `(before, after) => CorpusDiff` — ZIPs, lab tests, lab accounts and observations added / removed / changed. |
 | `fingerprintCorpus` | `(corpus) => Promise<string>` — SHA-256 of a corpus's content. |
@@ -744,7 +744,7 @@ Main entry (`@crvouga/mockingbird-service-junction`, runtime-neutral):
 | `SEALED_CORPUS_VERSION` | Current corpus format version (`2`: adds `teamId`). |
 | `SUPPORTED_SEALED_CORPUS_VERSIONS` | Versions `parseSealedCorpus` loads (`[1, 2]`). |
 | `MOCK_TEAM_ID` | The team id used when neither `teamId` nor the corpus gives one. |
-| `OTHER_TEAM_ID` | A team that is not the mock's, for fixtures modelling another team's account. |
+| `OTHER_TEAM_ID` | A team that is not the emulator's, for fixtures modelling another team's account. |
 | `isLinkedToTeam` | `(account, teamId) => boolean` — the allowlist rule (`[]` counts as linked). |
 | `LAB_ACCOUNT_PRESETS` | The [lab-account presets](#lab-account-presets), without ids. |
 | `LAB_ACCOUNT_PRESET_ALIASES` | Deprecated preset names → the preset each stands for (`bioreference_customer_multi_state` → `bioreference_platform`). |
@@ -875,9 +875,9 @@ For contributors to the mockingbird repo only.
 ```bash
 bun test                                   # offline suites, incl. scheduling state space
 bun test junction.runtime.property.test.ts # service contract, corpus, lab accounts, faults, webhooks, verify
-bun test junction.sdk.property.test.ts     # drives the served mock through @tryvital/vital-node
+bun test junction.sdk.property.test.ts     # drives the served emulator through @tryvital/vital-node
 
-bun run mock:serve                         # env-configured `serve`: HOST, PORT, MOCKINGBIRD_JUNCTION_CORPUS,
+bun run emulator:serve                         # env-configured `serve`: HOST, PORT, MOCKINGBIRD_JUNCTION_CORPUS,
                                            # MOCKINGBIRD_JUNCTION_WEBHOOK_URL / _SECRET / _SCOPE
 bun run corpus:record -- --force           # re-record the shipped corpus/sandbox-sealed.json (JUNCTION_API_KEY)
 bun run verify -- --real-key "$KEY"        # `mockingbird-junction verify` from source
@@ -898,7 +898,7 @@ Webhook parity needs a public receiver; see
 
 A completion-target simulation on an active testkit advances through delivery and queues
 completion for the next millisecond of the injected `now` clock. This is a deterministic
-mock scheduling boundary, not a claim about Junction's processing latency. Order, result,
+emulator scheduling boundary, not a claim about Junction's processing latency. Order, result,
 transaction, and order-list reads apply due work to its owning order. A second simulation
 is not required. Results remain unavailable while the testkit is `delivered_to_lab`.
 Cancelled orders never complete from queued simulation work.

package/SUPPORT.md

@@ -3,10 +3,10 @@
 Generated from `openapi.yaml`; do not edit by hand.
 
 - operations in spec: **40**
-- supported by the mock: **40**
+- supported by the emulator: **40**
 - parity enabled: **22**
 
-| operationId | route | mock | parity | notes |
+| operationId | route | emulator | parity | notes |
 | --- | --- | --- | --- | --- |
 | `get_teams_users_v2_user_get` | `GET /v2/user` | ✅ supported | ✅ |  |
 | `create_user_v2_user_post` | `POST /v2/user` | ✅ supported | ✅ |  |
@@ -17,31 +17,31 @@ 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 | ✅ |  |
-| `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 mock models the documented shape, filters and routing rules, not a live account inventory |
+| `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_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 | ✅ |  |
-| `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 a mock 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 mock 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 mock-internal scheduling property suite instead |
+| `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 |
 | `get_phlebotomy_appointment_cancellation_reason_v3_order_phlebotomy_appointment_cancellation_reasons_get` | `GET /v3/order/phlebotomy/appointment/cancellation-reasons` | ✅ supported | ✅ |  |
-| `get_psc_appointment_availability_v3_order_psc_appointment_availability_post` | `POST /v3/order/psc/appointment/availability` | ✅ supported | ❌ disabled | availability slots are provider-side data whose values shift between sandbox calls; covered by the mock-internal scheduling property suite instead |
+| `get_psc_appointment_availability_v3_order_psc_appointment_availability_post` | `POST /v3/order/psc/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 |
 | `get_psc_appointment_cancellation_reason_v3_order_psc_appointment_cancellation_reasons_get` | `GET /v3/order/psc/appointment/cancellation-reasons` | ✅ supported | ✅ |  |
-| `get_phlebotomy_appointment_v3_order__order_id__phlebotomy_appointment_get` | `GET /v3/order/{order_id}/phlebotomy/appointment` | ✅ supported | ❌ disabled | appointment payloads embed provider-side slot data; covered by the mock-internal scheduling property suite instead |
-| `book_phlebotomy_appointment_v3_order__order_id__phlebotomy_appointment_book_post` | `POST /v3/order/{order_id}/phlebotomy/appointment/book` | ✅ supported | ❌ disabled | booking depends on live provider slot state; covered by the mock-internal scheduling property suite instead |
-| `reschedule_phlebotomy_appointment_v3_order__order_id__phlebotomy_appointment_reschedule_patch` | `PATCH /v3/order/{order_id}/phlebotomy/appointment/reschedule` | ✅ supported | ❌ disabled | rescheduling depends on live provider slot state; covered by the mock-internal scheduling property suite instead |
-| `cancel_phlebotomy_appointment_v3_order__order_id__phlebotomy_appointment_cancel_patch` | `PATCH /v3/order/{order_id}/phlebotomy/appointment/cancel` | ✅ supported | ❌ disabled | cancellation depends on live provider appointment state; covered by the mock-internal scheduling property suite instead |
-| `get_psc_appointment_v3_order__order_id__psc_appointment_get` | `GET /v3/order/{order_id}/psc/appointment` | ✅ supported | ❌ disabled | appointment payloads embed provider-side slot data; covered by the mock-internal scheduling property suite instead |
-| `book_psc_appointment_v3_order__order_id__psc_appointment_book_post` | `POST /v3/order/{order_id}/psc/appointment/book` | ✅ supported | ❌ disabled | booking depends on live provider slot state; covered by the mock-internal scheduling property suite instead |
-| `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 mock-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 mock-internal scheduling property suite instead |
+| `get_phlebotomy_appointment_v3_order__order_id__phlebotomy_appointment_get` | `GET /v3/order/{order_id}/phlebotomy/appointment` | ✅ supported | ❌ disabled | appointment payloads embed provider-side slot data; covered by the emulator-internal scheduling property suite instead |
+| `book_phlebotomy_appointment_v3_order__order_id__phlebotomy_appointment_book_post` | `POST /v3/order/{order_id}/phlebotomy/appointment/book` | ✅ supported | ❌ disabled | booking depends on live provider slot state; covered by the emulator-internal scheduling property suite instead |
+| `reschedule_phlebotomy_appointment_v3_order__order_id__phlebotomy_appointment_reschedule_patch` | `PATCH /v3/order/{order_id}/phlebotomy/appointment/reschedule` | ✅ supported | ❌ disabled | rescheduling depends on live provider slot state; covered by the emulator-internal scheduling property suite instead |
+| `cancel_phlebotomy_appointment_v3_order__order_id__phlebotomy_appointment_cancel_patch` | `PATCH /v3/order/{order_id}/phlebotomy/appointment/cancel` | ✅ supported | ❌ disabled | cancellation depends on live provider appointment state; covered by the emulator-internal scheduling property suite instead |
+| `get_psc_appointment_v3_order__order_id__psc_appointment_get` | `GET /v3/order/{order_id}/psc/appointment` | ✅ supported | ❌ disabled | appointment payloads embed provider-side slot data; covered by the emulator-internal scheduling property suite instead |
+| `book_psc_appointment_v3_order__order_id__psc_appointment_book_post` | `POST /v3/order/{order_id}/psc/appointment/book` | ✅ supported | ❌ disabled | booking depends on live provider slot state; covered by the emulator-internal scheduling property suite instead |
+| `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 | ✅ |  |
 | `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 mock-internal results property suite instead |
+| `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 |