Update to Postman

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -1,27 +1,50 @@
 ---
 name: api-simulation
-description: Runs your code for real against stand-ins for the HTTP services it calls, served together as one environment on one local port or one deployed URL, whether that code is a service you're changing, a frontend, a test suite or a demo. Use when you add or change code that calls other services and need to run it, test it, prove a fix or reproduce an upstream failure (timeouts, 5xx, 409, 429) end to end, locally or in CI, without the real services because they're unreachable, need credentials, cost money, have side effects or don't exist yet. Also answers what happens to a request, or to the data it writes, when a service it calls goes down, is slow or returns errors ("what happens to a booking if the email service is down?"), by running each failure instead of reading the code. Applies even when nobody says mock or simulation. To give a frontend or another team a stand-in for an API, use api-mocking. Covers `postman simulation`.
+description: Runs services, frontends, tests or demos against stand-ins for their HTTP dependencies, served as one environment locally or at a deployed URL. Use when you add or change code that calls other services and need to run it, test it, prove a fix or reproduce an upstream failure (timeouts, 5xx, 409, 429) end to end, locally or in CI, without the real services because they're unreachable, need credentials, cost money, have side effects or don't exist yet. Also answers what happens to a request, or to the data it writes, when a service it calls goes down, is slow or returns errors ("what happens to a booking if the email service is down?"), by exercising relevant failures and observing caller outcomes. Applies even when nobody says mock or simulation, and a `postman/simulations/` directory in the repository is itself a reason to load this before changing code it covers. To give a frontend or another team a stand-in for an API, use api-mocking. Covers `postman simulation`.
 ---
 
 # API Simulation
 
-A simulation serves several mocks as one environment, each reached by its
-routeKey: as a path prefix by default, or as an `x-mock-slug` header when the
-caller's paths can't change.
-
-Run your code against it rather than stubbing its HTTP client in tests or
-calling the real services. A stub skips the client, config, timeouts and
-error handling that will run in production; the real services need
-credentials and leave side effects. A simulation runs that code over real
-HTTP, the same way in CI, and its log shows what each dependency was asked.
-
-Do only what the task needs. If a `.sim.yaml` in `postman/simulations/`
-already covers it, run that one, and read the `<name>.context.md` beside it
-first: it holds the commands, the preconditions and the failures earlier runs
-hit, so reading it costs less than rebuilding any of that from the `.sim.yaml`
-and the handlers. One request through the changed path proves a change; build
-failure variants only when asked how the code fails or when it must survive a
-failure.
+Simulation lets you control how dependencies behave and explore how your code
+responds to different outcomes. This makes it easier to test assumptions
+repeatedly without real calls changing data, spending money, or notifying
+someone. Simulation context records those assumptions, the evidence supporting
+them, and what remains unknown. As sessions build on this context, it helps
+surface incorrect assumptions and avoid repeated investigation.
+
+Together, the simulation and its context provide a place to explore changes
+and identify what still needs validation against the real dependencies.
+
+Check whether an existing simulation in `postman/simulations/` covers the
+dependency interactions relevant to the task. Reusing its mocks and wiring
+can avoid rebuilding an environment; extend it only where the behavior you
+need to exercise is missing.
+
+The `<name>.context.yaml` beside a simulation records those assumptions, their
+supporting evidence, and unresolved questions so later sessions can build on
+earlier findings. For example, a timeout from `/payments` does not establish
+whether the payment failed or completed before the response arrived. The
+context file will document what has been established about the real provider
+and identify what still needs verification.
+
+A simulation serves several mocks as one environment: by default behind a
+proxy that answers for the dependencies' own hostnames, so the code under test
+keeps the base URLs it ships with, or on one local port where each member is
+reached by its routeKey.
+
+Simulation adds value when the result depends on real HTTP behavior, such as
+client configuration, serialization, timeouts or retries, and the real
+dependencies are unavailable or unsuitable for the exercise. Stubbing the
+HTTP client can bypass those behaviors. Choose verification that exercises
+what matters to the task: an existing test may already answer a local logic
+question, while a claim about the provider may need its contract or a real
+service check. A simulation's log shows what each stand-in was asked.
+
+Define the expected outcome and what observation would distinguish correct
+from incorrect behavior, including side effects when relevant. A request
+through the changed path shows that it ran; its response and resulting state
+determine whether the expectation held. Choose boundary and failure cases
+from the behavior changed and the consequences of getting it wrong.
 
 `postman simulation` needs CLI 1.70.0 or later (`postman --version`; an older
 CLI answers `postman simulation -h` with its general help).
@@ -52,45 +75,37 @@
 Start it in the background, its log in a file:
 
 ```bash
-postman simulation run postman/simulations/checkout-dev.sim.yaml --port 4900 --output ndjson > sim.ndjson 2> sim.err &
+postman simulation run postman/simulations/checkout-dev.sim.yaml --proxy --output ndjson > sim.ndjson 2> sim.err &
 ```
 
-`--port` is optional. It's up when `sim.ndjson` has a `listening` event; a
-start-up error is in `sim.err`. That event carries the bound port and each
-member's address, so take the base URLs from it rather than from the port you
-asked for. Stop it with
+`--proxy` is how to run it unless something below rules it out: nothing about
+the code changes for the run — not a base URL, not a config file, not an SDK's
+built-in host — and because nothing the proxy answers for has to resolve, an
+internal hostname with no DNS record works.
+
+It's up when `sim.ndjson` has a `listening` event; a start-up error is in
+`sim.err`, a busy proxy port among them. Stop it with
 `pkill -INT -f "simulation run .*<file>.sim.yaml"`. Nothing reloads: restart
 it after a mock edit.
 
-Point the caller at it without changing what the code does once deployed.
-Under path routing, swap only the host and keep the path:
-`https://catalog.internal.example.com/v2` becomes
-`http://127.0.0.1:4900/catalog/v2`; a dropped `/v2` is the usual cause of a
-`404`. A hard-coded base URL should read an environment variable with
-today's value as the default. If the code mustn't change at all, run it
-behind the proxy instead, below.
-
-## Through a proxy, when no base URL can change
-
-`simulation run <file.sim.yaml> --proxy` puts the members behind a local
-forward proxy that answers for the dependencies' own hostnames, so the code
-keeps the base URLs it ships with. Any other host passes through to the real
-service. Reach for it when hostnames are hard-coded, built from config the
-change shouldn't touch, or owned by an SDK — and because nothing it answers
-for has to resolve, an internal hostname with no DNS record works.
-
 Read `postman simulation run --help` before driving it. The flags, what the
 caller's own process needs in order to reach the proxy, and what to do about a
 client that ignores it are all there and change with the CLI, so take them
 from the command rather than from here.
 
-Two things decide whether a proxied run proves anything. A member with no
-`origin:` in the `.sim.yaml` is never matched, so its traffic reaches the real
+What decides whether a proxied run proves anything is `origin:`. A member with
+none in the `.sim.yaml` is never matched, so its traffic reaches the real
 service and a run can come up having intercepted nothing — `simulation create`
 copies that field from the mock's manifest, so editing the manifest alone
 won't fix it ([reference/sim_yaml_schema.md](reference/sim_yaml_schema.md)).
-And conditions don't apply here: member `scenarios` are ignored, so failures
-need the one-port run.
+
+## Running it on one port instead
+
+`--port` puts every member on one local port, each addressable by its routeKey,
+with the code under test pointed at that port. Reach for it when a client has
+no proxy setting to honour, and when you want to address a member yourself —
+each one keeps a stable URL for the whole run, so a mock's control routes and
+its individual responses are a curl away.
 
 ## Reading the log
 
@@ -98,8 +113,8 @@
 `sim.ndjson`. A member with no `request` events isn't wired or isn't on this
 path. Some answers come from the simulation itself and mean wiring, not code:
 
-- `404 Unknown simulation member`: a base URL lost its routeKey, or a client
-  sent the wrong `x-mock-slug`.
+- `404 Unknown simulation member`, on a one-port run: a base URL lost its
+  routeKey, or a client sent the wrong `x-mock-slug`.
 - `501`, or a generated mock's `404 Endpoint not defined`: a call the mock
   doesn't model yet.
 - `502 Proxy error`: the member's process died, usually an async throw in a
@@ -108,12 +123,20 @@
 
 ## When a dependency goes down
 
-Run it rather than reason from the code: each way of going down takes a
-different path through the caller, and a stub skips the client code that
-picks the path. Fail the one dependency in each shape that matters, a run
-each, with the others answering normally:
+Choose failures from the outcome the user needs to understand. A failure
+before a write, a timeout after a write may have completed, and a failure
+during compensation can expose different risks: lost work, duplicate writes
+or unreleased resources. Read the caller to identify relevant paths, then
+exercise the ones whose runtime behavior remains uncertain.
+
+Isolating one failure helps attribute the result. Combine failures or model
+partial completion when the question depends on their interaction. The
+injection must represent the event being investigated: delaying a response
+alone does not establish whether a write completed before the timeout.
+Examples of available techniques:
 
-- **Unreachable:** point its base URL at a port nothing listens on.
+- **Unreachable:** point its base URL at a port nothing listens on. This one
+  needs the one-port run, since under `--proxy` the base URLs are the point.
 - **Hanging:** give its member a `latency` condition longer than the
   client's timeout. If the client sets none, that is the finding: Node's
   `fetch` waits about five minutes, so say so rather than wait it out.
@@ -131,19 +154,24 @@
 
 ## Its context document
 
-Every simulation is created with a `<name>.context.md` beside it, holding what
-running this one has taught: the commands that start it and prove it's up, the
-preconditions and what breaks when one fails, what it takes for granted about
-the dependencies themselves, the data seeded to test with, the failures earlier
-runs already hit, and what a passing run still doesn't prove. The `.sim.yaml` says what the simulation is, not how it behaves, so
-this is the file that saves a session the search. A new one is mostly
-`@todo`s, which are the questions a first real run answers.
-
-Every line passes one test — the repo doesn't already state it — so it stays
-about a screenful, and a claim carries the date and the run that established
-it, because the log it came from isn't committed. Its sections and conventions
-are in [reference/context_file.md](reference/context_file.md); read that
-before writing it back.
+Every simulation is created with a `<name>.context.yaml` beside it, holding
+what the code is believed to rely on about the dependencies it calls — who the
+caller is taken to be, which plan or permission is assumed, the order calls go
+in, what gets retried, the shape of the data — and what each belief rests on.
+The `.sim.yaml` says what the simulation is, not what the services it stands in
+for do, so this is the record that saves a session the search.
+
+Read relevant claims before investigating the dependencies, and assess whether
+their evidence still applies to this task. Write what you established back
+into the document before you finish. Each claim carries a `status`,
+the `reason` the evidence adds up to it, the `verification` that was done and
+what it showed, and a `source` to re-check it against, so the next session can
+tell a claim a contract promises from one a request actually demonstrated.
+Preserve existing claims and their evidence when updating the file, including
+unresolved assumptions and historical findings. Its fixed schema and guidance
+on evidence and reuse are in
+[reference/context_file.md](reference/context_file.md); read that before
+writing to it.
 
 ## Keeping it
 
@@ -173,16 +201,21 @@
 
 ## Before you say it works
 
-Claim nothing until what you're testing actually ran: a service printed
-that it's listening and answered your request, or the frontend or test
-suite finished, and its calls are in the log. If its start command exited
-or hung, the run proved nothing; say so and why. Say what a pass proves,
+Claim a simulation passes only after the code under test ran and you observed
+the expected response or state change. Use its calls in the log to confirm
+the dependency path was exercised; for injected failures, use the caller
+outcomes described above. If startup failed or the relevant path never ran,
+report that limitation. Say what a pass proves,
 your code against these stand-ins rather than the real services, what still
 needs the real service before release, and where each mock came from,
 including when you skipped the owner's.
 
-Then write the run back into `<name>.context.md`, so the next session starts
-where this one ended: the `@todo`s it answered, whatever it found wrong, a
-precondition you had to discover, what broke and why, and which members served
-or stayed silent — the last is a line every run adds, so a member silent across
-several runs reads as a pattern rather than a one-off.
+Then write what you established back into `<name>.context.yaml`, so the next
+session starts where this one ended. Add or update claims that help a later
+session reuse the findings. For each claim the run settled or contradicted,
+update its `status`, the `verification` that was done and the `source` to
+re-check it against. Scope what you claim to what you actually
+exercised — "held in the scenarios run" rather than "works" — since the record
+is read later as evidence, and the two don't mean the same thing.
+[reference/context_file.md](reference/context_file.md) has what each field is
+for.