@postman/postman-plugin 0.5.0-rc.0 → 0.5.1

package/dist/hosts/factory.js

@@ -2,17 +2,43 @@ import { GIT_URL, REPO, isSameRepo, redact } from '../source.js';
 import { blocked, guard, mustProbeText, mustRun } from './shared.js';
 import { result } from './types.js';
 const MARKETPLACE = 'postman-plugin', PLUGIN_ID = `postman@${MARKETPLACE}`, SCOPE = 'user', NEXT = 'Restart Droid for the change to take effect.';
+function rowsOfWrappedTable(text) {
+    const lines = text.split(/\r?\n/), headerAt = lines.findIndex((line) => /^[A-Z]+(?: [A-Z]+)*(?: {2,}[A-Z]+(?: [A-Z]+)*)+\s*$/.test(line));
+    if (headerAt === -1) {
+        return [];
+    }
+    const columns = [...lines[headerAt].matchAll(/[A-Z]+(?: [A-Z]+)*/g)].map((match) => ({ name: match[0], start: match.index })), rows = [];
+    for (const line of lines.slice(headerAt + 1)) {
+        const cells = columns.map(({ start }, i) => line.slice(start, columns[i + 1]?.start).trim()), previous = rows.at(-1), continuesPrevious = !cells[0];
+        if (!continuesPrevious) {
+            rows.push(Object.fromEntries(columns.map(({ name }, i) => [name, cells[i]])));
+        }
+        else if (previous) {
+            columns.forEach(({ name }, i) => { previous[name] += cells[i]; });
+        }
+    }
+    return rows;
+}
+export function installedPlugins(droidPluginList) {
+    const bracketedScopes = droidPluginList.split(/\r?\n/)
+        .map((line) => /^\s*(\S+@\S+)\s+\[(\w+)\]/.exec(line))
+        .filter((match) => match !== null)
+        .map(([, plugin, scope]) => `${plugin} [${scope}]`);
+    return bracketedScopes.length ?
+        bracketedScopes :
+        rowsOfWrappedTable(droidPluginList).map((row) => `${row.PLUGIN} [${row.SOURCE}]`);
+}
 function hasInstalledPlugin(text) {
-    return text.split('\n').some((line) => new RegExp(`^${PLUGIN_ID}\\s+\\[${SCOPE}\\]`).test(line.trimStart()));
+    return installedPlugins(text).includes(`${PLUGIN_ID} [${SCOPE}]`);
 }
 function marketplaceSource(text) {
-    for (const line of text.split('\n')) {
+    for (const line of text.split(/\r?\n/)) {
         const match = /^\s*(\S+)\s+\(\d+ plugins?\)\s+(.+?)(?:\s+"[^"]*")?\s*$/.exec(line);
         if (match && match[1] === MARKETPLACE) {
             return match[2];
         }
     }
-    return null;
+    return rowsOfWrappedTable(text).find((row) => row.MARKETPLACE === MARKETPLACE)?.SOURCE ?? null;
 }
 function sourceWithoutFactoryPrefix(source) {
     return source.replace(/^(?:github|url):/, '');

package/mcp.pi.json

@@ -6,8 +6,8 @@
       "description": "Postman workspaces, collections, specs, environments, mocks and monitors",
       "headers": {
         "X-Source": "postman-pi-plugin",
-        "X-Plugin-Version": "0.5.0-rc.0",
-        "User-Agent": "postman-pi-plugin/0.5.0-rc.0"
+        "X-Plugin-Version": "0.5.1",
+        "User-Agent": "postman-pi-plugin/0.5.1"
       }
     }
   }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@postman/postman-plugin",
-  "version": "0.5.0-rc.0",
+  "version": "0.5.1",
   "description": "Postman's API engineering skills for coding agents: a Pi package, and an npx installer that sets up Claude Code, Codex, Cursor, Kimi Code, Factory Droid, OpenCode and Pi.",
   "type": "module",
   "license": "Apache-2.0",

package/skills/api-simulation/SKILL.md

@@ -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 @@ The run is a server that never exits, so a foreground command never returns.
 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 @@ A passing test command doesn't show the dependency path ran: read
 `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 @@ path. Some answers come from the simulation itself and mean wiring, not code:
 
 ## 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.
 
-- **Unreachable:** point its base URL at a port nothing listens on.
+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. 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 @@ stock reserved and never released.
 
 ## 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 @@ first. It fails on a pulled member, which keeps its owner's `id:`; copy it to
 
 ## 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.

package/skills/api-simulation/reference/context_file.md

@@ -1,159 +1,193 @@
-# `<name>.context.md`
+# `<name>.context.yaml`
 
-The handoff document beside a simulation: `postman/simulations/checkout.sim.yaml`
-gets `checkout.context.md`, and a foldered simulation keeps both in its folder.
-`simulation create` and the Postman app write it from what they already know,
+The handoff record beside a simulation: `postman/simulations/checkout.sim.yaml`
+gets `checkout.context.yaml`, and a foldered simulation keeps both in its folder.
+`simulation create` and the Postman app write it from a fixed template,
 `simulation update` renames it with the simulation, and `simulation delete`
-removes it. An existing one is never overwritten, because it holds what earlier
-sessions learned.
+removes it.
 
-It is prose for whoever works here next, human or agent. Nothing parses it, so
-there is no schema to satisfy — but the generated headings and the
-`<!-- begin:observations -->` markers are what a reader and the next write
-expect to find, so keep them.
+**Update the existing record without discarding prior claims or evidence.**
+Replacing it with a fresh template loses findings and unresolved assumptions
+while looking complete.
 
-Keep it to the generated sections plus `## What didn't work`, in Markdown,
-under about a screenful, so the line that matters is the one a reader lands on
-rather than one they have to search for.
+It carries what is believed about the services this simulation stands in for,
+and what each belief rests on. **api-simulation** is how a simulation is run,
+read and judged — its commands running clean is not yet the work being done.
 
-## What the generated file contains
+## Its shape
 
-A fresh file states the simulation's name, the date, its members and the hosts
-they stand in for, and the run command for this simulation's own path.
-Everything needing someone who has actually run it is left as an `@todo` HTML
-comment, so a half-filled file reads as half-filled instead of as fact.
+The whole file is YAML under a fixed key schema. The key names and the `status`
+vocabulary are fixed; the template carries each key's field schema in the
+comments above it. A `null` is something nobody has established yet.
 
-| Section | Holds |
+| Key | Holds |
 | --- | --- |
-| Header | Generation date and what the mocks came from. |
-| `## Purpose` | What the simulation stands in for and what work it unblocks. Generated as the member list and a pointer to the handlers; needs hindsight, so it is the last thing to rewrite. |
-| `## Execution` | The commands, in order: start the simulation, start the service pointed at it, prove it is up, count what got called, stop. The generated block leaves the service's own command, the proof request, the port and the log path as `@todo`. |
-| `## Assumptions` | Every precondition someone had to discover, what the simulation takes for granted about the dependencies' own behaviour, the seeded data worth reusing, and what the simulation cannot reproduce. Each is a dated claim, the consequence of it not holding, and how it was established. |
-| `## Observations` | One dated line per run, newest first, between the `begin`/`end` markers: which members took traffic and which took none. A summary, not a request log, and a failure goes in `## What didn't work` instead. |
-| `## What didn't work` | Failures this simulation has already hit, a dated line each: what broke, the signature you'd recognize it by, where it surfaced, and the cause. Not generated — add the heading at the end, after `## Observations`, the first time a run gives you one. |
-
-`## Observations` and `## What didn't work` both accrete, so a run is visible
-in the file after the next one; `## Purpose`, `## Execution` and
-`## Assumptions` are rewritten in place, since they describe the simulation as
-it stands rather than a run. Each accreting section is bounded: `## What didn't
-work` keeps the ten most recent, a line staying until a run shows it fixed, and
-`## Observations` the five most recent runs. Past that the oldest go.
-
-A run that keeps its line is how a pattern becomes visible — a member silent
-for three runs running is worth more than the same fact seen once.
-
-Don't restate what the generated file already says: its `## Assumptions` ships
-with the ones that hold for every simulation.
-
-## What earns a line
-
-Write what running it taught you, and only that. Each line passes one test:
-the repo doesn't already state it. That leaves five kinds of thing, and they
-are the file's whole value:
-
-- **A precondition you had to discover** — the setting, the service, the
-  cleanup a run needs before it works at all. In `## Assumptions`.
-- **A failure and its cause**, with where it surfaced, so the next session
-  recognizes it instead of debugging it again. In `## What didn't work`.
-- **What the run takes for granted about a dependency itself** — that an
-  operation is idempotent, that a timeout means nothing committed, what order
-  events arrive in. A mock answers these whether or not anyone checked, so its
-  answer is a belief your code now relies on. In `## Assumptions`.
-- **What the simulation can't reproduce, and what nobody has settled**, so a
-  passing run is read for what it actually proves. In `## Assumptions`.
-- **What the last run served**: which members took traffic, which stayed
-  silent, and why. In `## Observations`.
-
-For anything the repo does state — routes and request shapes, valid actions,
-auth mechanics, each mock's hosts, config flags — name the file that holds it,
-the way the generated `## Purpose` points at the handlers, and let the reader
-go there. One source stays true; a copy here drifts, and this file gets
-committed, so a named file is also how a credential stays out of it.
-
-Write statements that stay true between runs. Counts, timings and coverage
-belong to the run that produced them, so leave them in the log and keep the
-pattern here: "every member served except `workspace`" rather than a tally.
-
-## How a line carries its evidence
-
-The log a claim came from isn't committed, so the line is all the next session
-gets. Date every claim in `## Assumptions` and `## What didn't work`, and say
-where it came from when a run didn't show it: `(observed 2026-10-22)` for what
-a run established, `(reasoned 2026-10-22, src/payments/client.ts)` for what was
-read rather than run.
-
-A failure also carries the signature the next session will recognize it by —
-the error text, the status, the member that sent it — since that is what
-someone matches a new failure against. Quote the error itself, never a
-response body. For the rest, name the committed file that holds it: the
-handler that threw, the mock example captured from the real service, the test
-that reproduces it. Not the run's log, which is wherever that run redirected
-output and which the next run overwrites.
-
-A good `## Assumptions` is a claim, its consequence and its date; a good
-`## Observations` is a few lines; a good `## What didn't work` is one line per
-failure:
-
-```markdown
-## Assumptions
-
-- **`payments` treats a retried charge as idempotent on `Idempotency-Key`.**
-  If it doesn't, the retry path charges twice. Nobody has settled it and the
-  mock answers as though it does. (reasoned 2026-10-22, the mock's handler)
-- **Redis holds no `EVENT_BATCH` key when a run starts.** A leftover one
-  crashes the aggregation flush before any request is sent. (observed
-  2026-10-22)
-
-<!-- begin:observations -->
-2026-10-22: every member served except `workspace`, which the service never
-calls in development, and `god`, which models no endpoints.
-2026-10-18: same, and `payments` served only `POST /charges`.
-<!-- end:observations -->
-
-## What didn't work
-
-- 2026-10-22: the aggregation flush crashed on start —
-  `TypeError: batch.map is not a function` in `src/events/flush.ts`, from a
-  stale Redis `EVENT_BATCH` key an earlier run left behind. Not a simulation
-  error, so the log shows nothing.
-- 2026-09-30: `payments` answered `501` for `POST /refunds` — the mock models
-  no refund path, so a run that reaches it proves nothing about refunds.
+| `purpose` | `stands_in_for` and `unblocks` — what the simulation stands in for and what work it unblocks. Record the intended purpose when known and refine it as you learn, distinguishing intended outcomes from demonstrated results. The members it serves, their route keys and the hosts they answer for are in the `.sim.yaml` beside it. |
+| `assumptions` | What the code relies on about a dependency's behaviour. One claim per entry: `id`, `status`, `claim`, `reason`, `verification`, `source`, `updated_at`. |
+| `fingerprints` | What the claims were written against — `id`, `date`, `commit`, `cli`. |
+
+Everything else about this simulation lives where it already is: the members and
+their origins in the `.sim.yaml`, the handlers in `postman/mocks/`, and how to
+run any of it in **api-simulation**. Use this record to connect those details
+to the assumptions and findings a later session needs.
+
+Keep an entry when it helps a later session make a decision without repeating
+the investigation, even if supporting details already exist in the repo.
+For routes, request shapes, auth or config, link the file that holds them and
+record the conclusion, evidence and uncertainty relevant to the caller.
+Avoid copying details that can drift, and keep credentials out of this
+committed record.
+
+## What an assumption is
+
+A claim about how a dependency behaves, which the code under test relies on:
+what 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. A mock answers these
+whether or not anyone checked, so its answer is a belief your code now carries.
+
+For example, checkout may retry a payment after a timeout without knowing
+whether the first attempt charged the customer. This illustrative entry
+records the provider assumption that makes that retry safe; the paths and
+run reference are examples, not evidence from this repository.
+
+```yaml
+- id: payment-retry-does-not-double-charge
+  status: unknown
+  claim: Retrying a payment for the same unchanged cart with identical payment
+    details and the same idempotency key within 24 hours creates at most one
+    charge at the payment provider, even if the first response times out.
+  reason: Checkout relies on this guarantee to retry without double-charging
+    the customer. The stand-in deduplicates payments by key, but that behavior
+    was configured by us; a passing simulation does not establish the
+    provider's retention window or handling of a retry after a timeout.
+  verification: On 2026-10-28, ran the checkout timeout test. The stand-in
+    recorded a successful charge, then delayed its response past the caller's
+    timeout. Checkout retried with the same payment details and key, and the
+    stand-in returned the original payment ID with one charge in its state.
+    This demonstrates caller key reuse in this scenario. The provider's
+    idempotency contract has not been checked; confirm its scope and retention
+    window, including retries after an ambiguous outcome, before relying on
+    this assumption for real payments.
+  source: src/checkout/submit-payment.ts; postman/mocks/payments/handler.js;
+    tests/checkout/payment-timeout.test.ts; runs/cart-payment-timeout-001
+  updated_at: "2026-10-28"
 ```
 
-## Working with it
-
-Read it before starting. An observed claim holds until your run contradicts
-it; a reasoned one is a hypothesis, so check it, cheaply, when your run depends
-on it. Check the assumptions and anything recorded about what a run doesn't
-prove before concluding that something works. A claim this run contradicts is
-a finding to report, not to quietly route around.
-
-What it already answers, it answers: `## Execution` holds commands that ran,
-and `## Assumptions` holds preconditions someone already established, so both
-are usable as they stand rather than as a starting point to rebuild from. The
-code you are about to change still needs reading; the setup around it is what
-this file is for. A session that reads the document and then repeats the
-search it was meant to replace has paid for it twice.
-
-Then leave it truer than you found it:
-
-- Replace the `@todo`s your run can answer, and delete each one you replace.
-- Correct what you found wrong. Say what it is now, not what it used to be.
-- Add the precondition you had to discover, or the thing the simulation turned
-  out not to reproduce, as another dated claim-and-consequence pair.
-- Add what broke and why to `## What didn't work`, and delete the lines there
-  your run showed fixed.
-- Add this run's summary to the top of the `## Observations` block, read from
-  the simulation's log, and drop the oldest line past five.
-
-A run that only confirms the file still adds its `## Observations` line.
-
-## Rules
-
-- Leave another session's assumptions and limits standing unless your run
-  contradicted one: not exercised is not the same as not true.
-- Keep this file for how the simulation behaves, and let the `.sim.yaml`
-  speak for what it is.
-- Rewrite `## Purpose` when the simulation's scope genuinely changed.
-- Prefer deleting a line to adding one. Everything here is something the next
-  session must either trust or re-check.
+One claim per entry. A sentence holding two claims is two entries, because
+evidence can settle one and leave the other standing.
+
+### `status`
+
+| Value | Means | For example |
+| --- | --- | --- |
+| `supported` | Evidence supports the claim, within a stated scope. | The provider guarantees idempotency for 24 hours. |
+| `contradicted` | Evidence provides a counterexample. | A timed-out request did create an order. |
+| `unknown` | Available evidence cannot establish or reject it. | Key scope across token refresh is unspecified. |
+| `conflicting` | Applicable sources disagree. | Documentation promises immediate revocation; a real probe observes continued access. |
+
+`supported` is the one to be careful with: support comes with a scope, so the
+claim says what that scope is. Name the operation, relevant conditions and
+window the evidence covers. Narrow an overbroad claim before marking it
+`supported`; a check at one point in a window does not establish behavior
+throughout it.
+
+`contradicted` and `conflicting` are findings to report, not states to route
+around. A contradiction says the code relies on something untrue; a conflict
+says two sources disagree and nobody has settled which governs — often a
+contract promising one thing while the running service does another.
+
+### `reason`, `verification` and `source`
+
+Three different jobs, and keeping them apart is what makes a claim checkable.
+
+`reason` is the judgment: why the evidence adds up to this status. It is the
+field that earns its place on a `conflicting` or `unknown` claim, where the
+status alone does not say what is unresolved.
+
+`verification` is what was actually done and what it showed — a contract read,
+a request made and its response, a handler inspected. Include when the
+verification occurred and the revision or environment it covered, using a
+fingerprint entry where applicable. Name what is still
+planned or blocked and what would settle it, and say when a piece of evidence
+has gone stale and why, since stale evidence stays as history but cannot
+establish a current status.
+
+Match the claim to the kind of evidence. A mock handler shows what the
+stand-in models; a simulated run shows how the caller behaved under that
+model. Neither independently establishes the real dependency's behavior.
+Use provider evidence for that: distinguish a published contract's promise
+from behavior observed against the real service, and retain the conditions
+and scope of each. If only the mock supports a provider assumption, that
+assumption remains `unknown` even when the caller test passes.
+
+`source` is where to go and re-check it, so the next session can audit the
+claim rather than take it on trust. Any of:
+
+- a file and line range in this repo, where the code shows what it relies on;
+- a request that was actually made and what came back — the target environment
+  (stand-in or real service), sequence and status codes, with a retrievable
+  test or run reference where available;
+- the dependency's own code, or its published contract, read for the endpoint
+  in question.
+
+A claim is only as good as what it points at, so `source` carries the specific
+thing, not its category: `api/policies/hasAccess.js:12-115` rather than "read
+the code". A claim with nothing to point at is `unknown`.
+
+Where two sources disagree, `verification` says what each one showed and
+`status` is `conflicting` — that is the state a contract promising one thing
+while the running service does another belongs in.
+
+### `updated_at`
+
+The day the entry was last written, `YYYY-MM-DD`. Set it when you add a claim,
+and set it again whenever you change one — a new status, a fresh piece of
+verification, a reworded claim.
+
+This date tracks record maintenance. Rewording a claim does not refresh its
+evidence: judge that from the date, revision and environment in `verification`
+and its referenced fingerprint. Re-check when relevant behavior or conditions
+have changed, or when the evidence's applicability is unclear.
+
+Nothing enforces this. `simulation create` writes an empty list and no command
+edits entries, so the field is only as true as the session that last wrote it.
+
+## Where claims come from
+
+Evidence first, claim second. Make the run or read the code, then write down
+what it establishes — including the parts nobody had written down before, which
+are the valuable half: a call order you did not expect, a dependency answering
+something the code does not handle, a member never called at all.
+
+Going the other way — writing the claim and then looking for something to back
+it — is how a guess ends up marked `supported`. A claim written ahead of any
+evidence is fine; it is `unknown` until something points at it.
+
+## Fingerprints
+
+What the claims were written against: `git rev-parse HEAD` and
+`postman --version`. Append an entry when either differs, and say so when the
+tree is dirty — a sha alone reads as a clean checkout.
+
+Tie each verification to the fingerprint it used. Appending a new fingerprint
+does not revalidate older claims. A changed commit or CLI is a reason to
+assess whether relevant behavior changed; it does not by itself invalidate
+all prior evidence.
+
+## Reading it before you start
+
+Read the claims relevant to the task before repeating dependency research.
+Compare their scope and evidence with the code, configuration and provider
+conditions your work depends on. Reuse findings that still apply, and inspect
+the code you are changing to identify assumptions the change may affect.
+
+Treat `supported` as conditional on that applicability, not as a permanent
+guarantee. Revisit affected claims when relevant conditions change or their
+evidence no longer establishes the current behavior. If current support is
+unresolved, mark the claim `unknown` and preserve the prior evidence with the
+reason it no longer settles the question. An `unknown` or `conflicting` claim
+is worth investigating when the task depends on it; record what would settle
+it if verification remains blocked.
+
+Preserve unrelated claims and their history. A claim not exercised in this
+session is not thereby contradicted or stale.

package/skills/api-simulation/reference/sim_yaml_schema.md

@@ -26,7 +26,7 @@ since the file is what declares the hostnames.
 `simulation create` writes each `path:` relative to the repository root, the
 directory holding `postman/`, and puts the simulation in a folder of its own
 (`postman/simulations/checkout-dev/checkout-dev.sim.yaml`) so its
-`<name>.context.md` sits beside it; the app records that document in a
+`<name>.context.yaml` sits beside it; the app records that document in a
 `context:` ref. Reading is broader than writing — a path relative to
 `postman/simulations/`, to the file, absolute or `~/`, naming the folder or
 the manifest inside it, all resolve — and an unresolvable one names every