@openwop/openwop-conformance 1.136.10 → 1.138.1

package/coverage.md

@@ -200,7 +200,7 @@ Every OpenAPI operation should have:
 4. A cited spec section in each assertion message.
 
 | Operation ID                                                                                | Positive coverage                                                                                                                                                                                                                                                                                                                                                                                                                             | Negative / auth / validation coverage                                                                                                                                                                                                                                                     | Gap                                                                                                                                                                                                                 |
-| ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
+| ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `getCapabilities`                                                                           | `discovery.test.ts`, `runtime-capabilities.test.ts`, `profileDerivation.test.ts`, `mcp-discoverability.test.ts`                                                                                                                                                                                                                                                                                                                               | `discovery.test.ts` covers optional `Capabilities-Etag`; `spec-corpus-validity.test.ts` validates schema shape                                                                                                                                                                            | Add scoped discovery scenario when a host advertises it.                                                                                                                                                            |
 | `getOpenApiSpec`                                                                            | `discovery.test.ts`                                                                                                                                                                                                                                                                                                                                                                                                                           | `spec-corpus-validity.test.ts` validates OpenAPI refs                                                                                                                                                                                                                                     | Add unavailable/transient error scenario only if host can simulate it.                                                                                                                                              |
 | `getWorkflow`                                                                               | `route-coverage.test.ts`; fixture-dependent lifecycle tests indirectly require seeded workflow IDs                                                                                                                                                                                                                                                                                                                                            | `route-coverage.test.ts` covers unknown workflow `404`/`403` envelope                                                                                                                                                                                                                     | Good.                                                                                                                                                                                                               |

package/dist/cli.js

@@ -17,7 +17,14 @@
  * Environment variables override flags (per the conformance harness's
  * existing convention):
  *   OPENWOP_BASE_URL, OPENWOP_API_KEY, OPENWOP_IMPLEMENTATION_NAME,
- *   OPENWOP_IMPLEMENTATION_VERSION, OPENWOP_LIFECYCLE_TIMEOUT_MS
+ *   OPENWOP_IMPLEMENTATION_VERSION, OPENWOP_LIFECYCLE_TIMEOUT_MS,
+ *   OPENWOP_POLL_TIMEOUT_SCALE, OPENWOP_MAX_WORKERS
+ *
+ * OPENWOP_LIFECYCLE_TIMEOUT_MS sets the DEFAULT poll bound only — it does
+ * not reach the many scenarios that pass an explicit `timeoutMs`.
+ * OPENWOP_POLL_TIMEOUT_SCALE (default 1) multiplies EVERY bound and is the
+ * knob to reach for when a run's failures are the endpoint (cold start,
+ * contention) rather than the host. See src/lib/polling.ts.
  *
  * Exit codes:
  *   0   all scenarios pass

package/dist/lib/requirement-ledger.js

@@ -123,6 +123,14 @@ export function readLedgerFile(path) {
  * returned early, threw and swallowed, or was never written leaves no entry, and
  * the honest reading of no entry is "this was not exercised".
  */
+/**
+ * Has this requirement already been recorded in THIS run? Distinguishes "the
+ * scenario classified itself" from "nothing has been recorded yet" — which
+ * `dispositionOf` cannot, since it folds the absent case to `blocked`.
+ */
+export function hasRequirement(requirementId) {
+    return ledger.has(requirementId);
+}
 export function dispositionOf(requirementId) {
     return ledger.get(requirementId)?.disposition ?? 'blocked';
 }

package/dist/lib/scenario-disposition.js

@@ -48,6 +48,14 @@ export function requirementIdForFile(basename) {
         ? requirementIdForScenario(basename)
         : `openwop.scenario.${basename.replace(/\.test\.ts$/, '')}`;
 }
+/**
+ * Marks an `executed-pass` row whose file ALSO recorded a soft-skip note — the
+ * file asserted something, then stopped short (gap G8). Greppable on purpose: a
+ * bundle reader filters `disposition === 'executed-pass' && detail?.startsWith(
+ * PARTIAL_WITNESS_PREFIX)` to find rows where the requirement may not have been
+ * the thing that passed.
+ */
+export const PARTIAL_WITNESS_PREFIX = 'partial-witness: ';
 /** Worker half: fold a file's per-test states (+ any gate-recorded reason) into
  *  the ONE disposition the file records. */
 export function fileDisposition(states, gateReason, assertionCount) {
@@ -115,6 +123,28 @@ export function resolveFileRecord(states, gateReason, assertionCount, noted) {
         disposition = noted.kind;
         detail = noted.reason;
     }
+    else if (noted !== null && disposition === 'executed-pass') {
+        // PARTIAL WITNESS (2026-08-19, gap G8). The file asserted something and then
+        // soft-skipped: `return softSkip(...)` yields a PASS state, not a skip, so
+        // neither branch above fires and the note used to be discarded outright. The
+        // row then read `executed-pass` for a requirement the run may never have
+        // reached — e.g. a file asserting a `201` setup precondition before
+        // returning `inapplicable`.
+        //
+        // Same defect as the note-after-`ctx.skip()` case the comment above records;
+        // note-after-ASSERTION was the half that stayed. Both hid because nothing
+        // goes red.
+        //
+        // The disposition is deliberately NOT changed. Honouring the note here would
+        // downgrade a file that legitimately completed its requirement AND
+        // soft-skipped an optional extra leg — trading a false positive for a false
+        // negative, on a per-FILE note that cannot say which leg it came from. The
+        // durable fix is per-`it` recording; this makes the affected rows
+        // self-identifying first, so that change follows measurement instead of
+        // preceding it. `detail` is permitted on `executed-pass` (RFC 0148 §A only
+        // REQUIRES it for other dispositions), so this is additive on the wire.
+        detail = `${PARTIAL_WITNESS_PREFIX}${noted.kind}: ${noted.reason}`;
+    }
     return detail === undefined ? { disposition } : { disposition, detail };
 }
 /**

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@openwop/openwop-conformance",
-  "version": "1.136.10",
+  "version": "1.138.1",
   "description": "Production-ready black-box conformance suite for OpenWOP v1.0 compliant servers.",
   "repository": {
     "type": "git",

package/schemas/CORPUS-STAMP.json

@@ -1,5 +1,5 @@
 {
   "_comment": "Provenance of this vendored schemas/ copy. See conformance/README.md \u00a7\"Resolving the contract\". Compare against the stamp in your installed @openwop/openwop-conformance to detect a stale hand-copied contract.",
-  "suiteVersion": "1.136.10",
-  "corpusCommit": "0d8fd3fde8cca5785c23d4b7e64281f1876ab342"
+  "suiteVersion": "1.138.1",
+  "corpusCommit": "3555363038ce8ea7e40dc2f2a41c39066228e69c"
 }

package/schemas/capabilities.schema.json

@@ -3495,7 +3495,7 @@
     },
     "idempotency": {
       "type": "object",
-      "description": "RFC 0036 \u2014 Multi-region idempotency contract. Optional v1 advertisement. The existing `crossRegion: 'single-region'|'best-effort'|'strict'` categorical claim lives under `capabilities.idempotency.crossRegion` per spec/v1/idempotency.md \u00a7'Multi-region idempotency (annex)'. The `multiRegion` sub-block here gives a granular advertisement that hosts SHOULD pair with the categorical `crossRegion` claim.",
+      "description": "RFC 0036 \u2014 Multi-region idempotency contract. Optional v1 advertisement. The existing `crossRegion: 'single-region'|'reconciled-records'|'fenced-effects'` categorical claim lives under `capabilities.idempotency.crossRegion` (this description named the pre-RFC-0150-\u00a7D vocabulary `'best-effort'|'strict'` until 2026-08-18 \u2014 both values were RETIRED by \u00a7D and the sibling `crossRegion` enum has been correct throughout, so only this prose was wrong; a reader of it would have believed two non-values were advertisable) per spec/v1/idempotency.md \u00a7'Multi-region idempotency (annex)'. The `multiRegion` sub-block here gives a granular advertisement that hosts SHOULD pair with the categorical `crossRegion` claim.",
       "additionalProperties": true,
       "properties": {
         "supported": {

package/schemas/certification-bundle-v2.schema.json

@@ -24,7 +24,17 @@
       "properties": {
         "name": { "type": "string", "minLength": 1 },
         "version": { "type": "string", "minLength": 1 },
-        "vendor": { "type": "string" }
+        "vendor": { "type": "string" },
+        "commit": {
+          "type": "string",
+          "minLength": 1,
+          "description": "OPTIONAL, self-reported source revision the host was built from. NOT sufficient to attribute the bundle: a commit does not determine the artifact unless the build is deterministic — a tier-2 host measured 283/22 vs 303/2 from two builds of one commit whose container image ran `npm install` rather than `npm ci` (conformance-certification.md §\"What a bundle attributes to\")."
+        },
+        "build": {
+          "type": "string",
+          "minLength": 1,
+          "description": "OPTIONAL, self-reported identifier of what ACTUALLY EXECUTED — this, not `commit`, is what a verifier needs to re-run the same thing. Which identifier is reachable depends on when the bundle is written: a container image digest is strongest but does not exist yet for a bundle baked INTO the image at certify time; a builder-assigned build id is available during the build; a digest of the resolved dependency manifest (lockfile or resolved tree) is available at certify time and pins the closure that actually varied in the measurement behind this field. State which kind it is rather than reaching for the strongest-sounding one. See conformance-certification.md §\"A bundle attributes to a BUILD\"."
+        }
       }
     },
     "discovery": {

package/src/cli.ts

@@ -17,7 +17,14 @@
  * Environment variables override flags (per the conformance harness's
  * existing convention):
  *   OPENWOP_BASE_URL, OPENWOP_API_KEY, OPENWOP_IMPLEMENTATION_NAME,
- *   OPENWOP_IMPLEMENTATION_VERSION, OPENWOP_LIFECYCLE_TIMEOUT_MS
+ *   OPENWOP_IMPLEMENTATION_VERSION, OPENWOP_LIFECYCLE_TIMEOUT_MS,
+ *   OPENWOP_POLL_TIMEOUT_SCALE, OPENWOP_MAX_WORKERS
+ *
+ * OPENWOP_LIFECYCLE_TIMEOUT_MS sets the DEFAULT poll bound only — it does
+ * not reach the many scenarios that pass an explicit `timeoutMs`.
+ * OPENWOP_POLL_TIMEOUT_SCALE (default 1) multiplies EVERY bound and is the
+ * knob to reach for when a run's failures are the endpoint (cold start,
+ * contention) rather than the host. See src/lib/polling.ts.
  *
  * Exit codes:
  *   0   all scenarios pass

package/src/lib/polling.test.ts

@@ -0,0 +1,80 @@
+/**
+ * Unit tests for `polling.ts` — the poll-bound scaling knob.
+ *
+ * These exist because the defect being fixed was a knob that did not reach
+ * what its documentation said it reached: `OPENWOP_LIFECYCLE_TIMEOUT_MS` was
+ * documented as the way to bound long polls, but it supplies only the DEFAULT,
+ * so every call site passing an explicit `timeoutMs` ignored it. Shipping the
+ * replacement untested would repeat the defect one layer up, so the scale is
+ * asserted here rather than assumed.
+ *
+ * @see polling.ts
+ */
+
+import { describe, it, expect, afterEach } from 'vitest';
+import { scaledTimeoutMs } from './polling.js';
+
+const KEY = 'OPENWOP_POLL_TIMEOUT_SCALE';
+
+function withScale(value: string | undefined, fn: () => void): void {
+  if (value === undefined) delete process.env[KEY];
+  else process.env[KEY] = value;
+  fn();
+}
+
+afterEach(() => {
+  delete process.env[KEY];
+});
+
+describe('polling: scaledTimeoutMs', () => {
+  it('is an exact no-op when the knob is unset — no existing measurement moves', () => {
+    withScale(undefined, () => {
+      for (const ms of [100, 1_000, 5_000, 10_000, 15_000, 30_000, 60_000]) {
+        expect(scaledTimeoutMs(ms)).toBe(ms);
+      }
+    });
+  });
+
+  it('is an exact no-op at scale 1, including the string form', () => {
+    withScale('1', () => expect(scaledTimeoutMs(10_000)).toBe(10_000));
+    withScale('1.0', () => expect(scaledTimeoutMs(10_000)).toBe(10_000));
+  });
+
+  it('scales explicit bounds, which the documented env var could never reach', () => {
+    withScale('3', () => {
+      expect(scaledTimeoutMs(10_000)).toBe(30_000);
+      expect(scaledTimeoutMs(15_000)).toBe(45_000);
+    });
+  });
+
+  it('preserves the ORDERING of deliberately-short bounds — the reason this scales rather than floors', () => {
+    withScale('4', () => {
+      const short = scaledTimeoutMs(100);
+      const long = scaledTimeoutMs(10_000);
+      expect(short).toBe(400);
+      expect(long).toBe(40_000);
+      // A floor would have collapsed these two to the same value, silently
+      // rewriting every negative assertion that depends on a short bound.
+      expect(short).toBeLessThan(long);
+    });
+  });
+
+  it('rounds up, so a fractional scale never shortens a bound', () => {
+    withScale('1.5', () => expect(scaledTimeoutMs(1_001)).toBe(1_502));
+    withScale('1.0001', () => expect(scaledTimeoutMs(100)).toBeGreaterThanOrEqual(100));
+  });
+
+  it('falls back to 1 for a mis-set knob rather than producing an instant failure', () => {
+    // A zero, negative, or unparseable scale would turn every poll into an
+    // immediate timeout — which reads as a catastrophic host defect, the exact
+    // misattribution this knob exists to prevent.
+    for (const bad of ['0', '-2', 'abc', 'NaN', 'Infinity', '', '  ']) {
+      withScale(bad, () => expect(scaledTimeoutMs(10_000)).toBe(10_000));
+    }
+  });
+
+  it('reads the environment at CALL time, so a harness may set it after import', () => {
+    withScale('2', () => expect(scaledTimeoutMs(1_000)).toBe(2_000));
+    withScale('5', () => expect(scaledTimeoutMs(1_000)).toBe(5_000));
+  });
+});

package/src/lib/polling.ts

@@ -6,7 +6,25 @@
  * Polling is the lowest-common-denominator wire; SSE-specific scenarios
  * live in stream-modes.test.ts.
  *
- * Bound long polls with OPENWOP_LIFECYCLE_TIMEOUT_MS env var (default 10s).
+ * Bound long polls with OPENWOP_LIFECYCLE_TIMEOUT_MS env var (default 10s) —
+ * but note what that knob can and cannot reach. It supplies the DEFAULT only,
+ * so it has no effect on the ~110 call sites that pass an explicit `timeoutMs`
+ * (59 of them passing the same `10_000` the default already was). An operator
+ * measuring a host on a cold or contended endpoint would set the documented
+ * variable, observe no change in those scenarios, and record a failure that
+ * measured the environment rather than the host.
+ *
+ * `OPENWOP_POLL_TIMEOUT_SCALE` (default `1`) closes that: it multiplies EVERY
+ * poll bound, explicit or default. Scaling rather than flooring is deliberate —
+ * a floor would flatten the deliberately-short bounds (`100`, `1000`) that some
+ * negative assertions depend on, while a scale preserves every call site's
+ * intent relative to the others. At the default it is a no-op, so no existing
+ * measurement moves.
+ *
+ * Neither knob is a way to make a hanging host pass: the assertion is that a
+ * terminal state is REACHED, and a host that never reaches one fails at any
+ * bound. What they buy is the ability to say whether a timeout measured the
+ * host or the harness.
  */
 
 import { driver } from './driver.js';
@@ -33,6 +51,25 @@ export interface RunSnapshot {
 const POLL_INTERVAL_MS = 250;
 const DEFAULT_TIMEOUT_MS = Number(process.env.OPENWOP_LIFECYCLE_TIMEOUT_MS ?? 10_000);
 
+/**
+ * Multiplier applied to every poll bound (see the module docstring). Invalid,
+ * non-positive, or non-finite values fall back to `1` rather than silently
+ * producing a zero or negative deadline — a mis-set knob must not turn every
+ * poll into an instant failure that looks like a host defect.
+ */
+function pollTimeoutScale(): number {
+  const raw = process.env.OPENWOP_POLL_TIMEOUT_SCALE;
+  if (raw === undefined || raw === '') return 1;
+  const n = Number(raw);
+  return Number.isFinite(n) && n > 0 ? n : 1;
+}
+
+/** Apply the scale to a bound, rounding up so a scale of 1 is exactly a no-op. */
+export function scaledTimeoutMs(timeoutMs: number): number {
+  const scale = pollTimeoutScale();
+  return scale === 1 ? timeoutMs : Math.ceil(timeoutMs * scale);
+}
+
 const TERMINAL = new Set(['completed', 'failed', 'cancelled']);
 
 export async function getRun(runId: string): Promise<RunSnapshot> {
@@ -48,7 +85,7 @@ export async function pollUntil(
   predicate: (snap: RunSnapshot) => boolean,
   opts: { timeoutMs?: number; label?: string } = {},
 ): Promise<RunSnapshot> {
-  const timeoutMs = opts.timeoutMs ?? DEFAULT_TIMEOUT_MS;
+  const timeoutMs = scaledTimeoutMs(opts.timeoutMs ?? DEFAULT_TIMEOUT_MS);
   const deadline = Date.now() + timeoutMs;
   let last: RunSnapshot | null = null;
   while (Date.now() < deadline) {

package/src/lib/requirement-ledger.test.ts

@@ -0,0 +1,75 @@
+/**
+ * Unit tests for `requirement-ledger.ts` — recording precedence.
+ *
+ * These pin the property `setup.ts` relies on when it decides whether to write
+ * its automatic file-level record: a scenario that classified ITSELF must win
+ * outright. The comment on that line claimed as much for years while the code
+ * only delivered it on DISAGREEMENT — a same-disposition re-record reached
+ * `ledger.set` and replaced the scenario's own `detail` and `assertionCount`
+ * with the file-level ones. Harmless while details were rarely set on a pass;
+ * visible the moment `resolveFileRecord` began attaching a `partial-witness:`
+ * marker, which would have stamped "may not have witnessed this" over a
+ * scenario's own explicit finding.
+ *
+ * @see requirement-ledger.ts, setup.ts
+ */
+
+import { describe, it, expect, beforeEach } from 'vitest';
+import {
+  recordRequirement,
+  hasRequirement,
+  entryOf,
+  dispositionOf,
+  resetLedger,
+} from './requirement-ledger.js';
+
+const ID = 'openwop.scenario.ledger-precedence-fixture';
+
+beforeEach(() => {
+  resetLedger();
+});
+
+describe('requirement-ledger: recording precedence', () => {
+  it('hasRequirement distinguishes "not recorded" from "recorded", which dispositionOf cannot', () => {
+    // `dispositionOf` folds the absent case to `blocked`, so it reads the same
+    // for a requirement nobody touched and one deliberately recorded blocked.
+    expect(hasRequirement(ID)).toBe(false);
+    expect(dispositionOf(ID)).toBe('blocked');
+
+    recordRequirement(ID, 'blocked', 'seam absent');
+    expect(hasRequirement(ID)).toBe(true);
+    expect(dispositionOf(ID)).toBe('blocked');
+  });
+
+  it('a same-disposition re-record OVERWRITES detail and assertionCount — the reason setup.ts must guard', () => {
+    recordRequirement(ID, 'executed-pass', 'witnessed the MUST NOT on the wire', { assertionCount: 9 });
+    expect(entryOf(ID).detail).toBe('witnessed the MUST NOT on the wire');
+
+    // No throw: `recordRequirement` only rejects a CONFLICTING disposition.
+    recordRequirement(ID, 'executed-pass', 'partial-witness: inapplicable: branch leg skipped', { assertionCount: 2 });
+    expect(entryOf(ID).detail).toBe('partial-witness: inapplicable: branch leg skipped');
+    expect(entryOf(ID).assertionCount).toBe(2);
+  });
+
+  it('a CONFLICTING disposition throws, which is how the explicit record already won on disagreement', () => {
+    recordRequirement(ID, 'executed-pass', undefined, { assertionCount: 4 });
+    expect(() => recordRequirement(ID, 'blocked', 'file-level fold said blocked')).toThrow(/already recorded/);
+    // The first recording survives the rejected second one.
+    expect(dispositionOf(ID)).toBe('executed-pass');
+  });
+
+  it('guarding on hasRequirement preserves the explicit record in BOTH directions', () => {
+    // This is precisely what setup.ts now does before its automatic write.
+    recordRequirement(ID, 'executed-pass', 'witnessed the MUST NOT on the wire', { assertionCount: 9 });
+    if (!hasRequirement(ID)) {
+      recordRequirement(ID, 'executed-pass', 'partial-witness: inapplicable: branch leg skipped', { assertionCount: 2 });
+    }
+    expect(entryOf(ID).detail).toBe('witnessed the MUST NOT on the wire');
+    expect(entryOf(ID).assertionCount).toBe(9);
+  });
+
+  it('still refuses a non-pass disposition with no reason — an unactionable row', () => {
+    expect(() => recordRequirement(ID, 'blocked', '   ')).toThrow(/without a reason/);
+    expect(hasRequirement(ID)).toBe(false);
+  });
+});

package/src/lib/requirement-ledger.ts

@@ -158,6 +158,15 @@ export function readLedgerFile(path: string): readonly LedgerEntry[] {
  * returned early, threw and swallowed, or was never written leaves no entry, and
  * the honest reading of no entry is "this was not exercised".
  */
+/**
+ * Has this requirement already been recorded in THIS run? Distinguishes "the
+ * scenario classified itself" from "nothing has been recorded yet" — which
+ * `dispositionOf` cannot, since it folds the absent case to `blocked`.
+ */
+export function hasRequirement(requirementId: string): boolean {
+  return ledger.has(requirementId);
+}
+
 export function dispositionOf(requirementId: string): Disposition {
   return ledger.get(requirementId)?.disposition ?? 'blocked';
 }

package/src/lib/risk-disposition.test.ts

@@ -0,0 +1,91 @@
+/**
+ * Unit tests for the closed/transferred predicate in
+ * `scripts/generate-assurance-status.mjs`.
+ *
+ * This predicate is not cosmetic. Project-wide gates have been keyed to the
+ * open-Critical count it produces, so a false closure silently loosens a
+ * constraint — and a false open silently keeps one in force.
+ *
+ * It previously matched the bare substring `closed` anywhere in a row's status
+ * cell, which produced two failures in opposite directions:
+ *
+ *   · RFC 0151 R1 ("Compensation executes twice", Critical) reads
+ *     "Open — ... unwitnessed" and was counted CLOSED from 2026-08-16 onward,
+ *     because the cell mentions "(G1 closed 2026-08-16)" — a DIFFERENT item's
+ *     closure. A substring of an adjacent concept.
+ *   · A row stating that a risk "cannot be closed by repository work" was
+ *     counted closed by saying so.
+ *
+ * The predicate is duplicated here rather than imported because the generator is
+ * a standalone ESM script with no exports; the duplication is pinned by
+ * `matches the generator's source` below, which fails if the two drift.
+ *
+ * @see scripts/generate-assurance-status.mjs
+ */
+
+import { describe, it, expect } from 'vitest';
+import { readFileSync, existsSync } from 'node:fs';
+import { join, dirname } from 'node:path';
+import { V1_DIR } from './paths.js';
+
+const NEGATED = /\b(cannot|can ?not|could not|will not|never|not)\s+be\s+(closed|resolved)\b|\bnot closed\b/i;
+const EXPLICIT = /\*\*(CLOSED|Closed)\b|~~|Realised and remediated/i;
+const TRANSFERRED = /\*\*(?:OPEN\s+—\s+)?TRANSFERRED\b/i;
+
+function disposition(status: string): 'closed' | 'transferred' | 'open' {
+  const closed = EXPLICIT.test(status) && !NEGATED.test(status);
+  if (closed) return 'closed';
+  return TRANSFERRED.test(status) ? 'transferred' : 'open';
+}
+
+describe('assurance risk disposition', () => {
+  it('does NOT read a nested reference to another item as this row being closed', () => {
+    // The exact RFC 0151 R1 shape. "Open", "unwitnessed", and a parenthetical
+    // about gap G1 closing — a different thing entirely.
+    const status =
+      'Open — **Sweep 2026-08-16:** **Mitigated in prose** — inverse-action identity tuple stated; ' +
+      '`compensation.md` §C now states the persistence shape (G1 closed 2026-08-16); unwitnessed for retry-stability';
+    expect(disposition(status)).toBe('open');
+  });
+
+  it('does NOT read a row that says a risk cannot be closed as closed', () => {
+    expect(disposition('**OPEN — TRANSFERRED.** This risk cannot be closed by repository work.')).not.toBe('closed');
+  });
+
+  it('reads an explicit marker as closed', () => {
+    expect(disposition('**CLOSED.** The recurrence mechanism is in the tree and executing.')).toBe('closed');
+    expect(disposition('~~superseded~~ — folded into RFC 0150 §D')).toBe('closed');
+    expect(disposition('**Realised and remediated in scope:** bundle 1 invalidated')).toBe('closed');
+  });
+
+  it('distinguishes transferred from open, because §A.1 turns on the difference', () => {
+    expect(disposition('**OPEN — TRANSFERRED to a named tracked surface.** Tracked in KNOWN-LIMITS.')).toBe('transferred');
+    expect(disposition('Open — unwitnessed. No host advertises the capability.')).toBe('open');
+  });
+
+  it('is not fooled by the word appearing in ordinary prose', () => {
+    expect(disposition('Open — the comment window closed without review.')).toBe('open');
+    expect(disposition('Open — closes when a host implements fencing.')).toBe('open');
+  });
+
+  it('matches the generator source — fails if the two drift apart', () => {
+    // `V1_DIR` is null in the PUBLISHED package layout, which ships no `spec/`
+    // and no `scripts/`. Resolving the path at module scope — or casting the
+    // null away — is what made six scenarios throw at import for every npm
+    // consumer while staying green in a repo checkout. Resolve inside the test
+    // and skip when the repo is not there.
+    if (V1_DIR === null) return;
+    const script = join(dirname(V1_DIR), '..', 'scripts', 'generate-assurance-status.mjs');
+    if (!existsSync(script)) return;
+    const src = readFileSync(script, 'utf8');
+    // Guard the shape, not the byte-for-byte text: the generator must still gate
+    // on an explicit marker AND a negation check, never on a bare substring.
+    expect(src, 'generator must keep the negation guard').toMatch(/const negated = /);
+    expect(src, 'generator must require an explicit closed marker').toMatch(/const explicitlyClosed =/);
+    expect(src, 'generator must still separate transferred rows').toMatch(/const transferred = /);
+    expect(
+      /const closed = \/\(\^\|\\s\)\(closed\|resolved/.test(src),
+      'the bare-substring test must not come back',
+    ).toBe(false);
+  });
+});

package/src/lib/scenario-disposition.ts

@@ -49,6 +49,15 @@ export function requirementIdForFile(basename: string): string {
     : `openwop.scenario.${basename.replace(/\.test\.ts$/, '')}`;
 }
 
+/**
+ * Marks an `executed-pass` row whose file ALSO recorded a soft-skip note — the
+ * file asserted something, then stopped short (gap G8). Greppable on purpose: a
+ * bundle reader filters `disposition === 'executed-pass' && detail?.startsWith(
+ * PARTIAL_WITNESS_PREFIX)` to find rows where the requirement may not have been
+ * the thing that passed.
+ */
+export const PARTIAL_WITNESS_PREFIX = 'partial-witness: ';
+
 export type FileTestState = 'pass' | 'fail' | 'skip';
 
 /** Worker half: fold a file's per-test states (+ any gate-recorded reason) into
@@ -125,6 +134,27 @@ export function resolveFileRecord(
     // dead code — which is how seven files carried notes the ledger never saw.
     disposition = noted.kind;
     detail = noted.reason;
+  } else if (noted !== null && disposition === 'executed-pass') {
+    // PARTIAL WITNESS (2026-08-19, gap G8). The file asserted something and then
+    // soft-skipped: `return softSkip(...)` yields a PASS state, not a skip, so
+    // neither branch above fires and the note used to be discarded outright. The
+    // row then read `executed-pass` for a requirement the run may never have
+    // reached — e.g. a file asserting a `201` setup precondition before
+    // returning `inapplicable`.
+    //
+    // Same defect as the note-after-`ctx.skip()` case the comment above records;
+    // note-after-ASSERTION was the half that stayed. Both hid because nothing
+    // goes red.
+    //
+    // The disposition is deliberately NOT changed. Honouring the note here would
+    // downgrade a file that legitimately completed its requirement AND
+    // soft-skipped an optional extra leg — trading a false positive for a false
+    // negative, on a per-FILE note that cannot say which leg it came from. The
+    // durable fix is per-`it` recording; this makes the affected rows
+    // self-identifying first, so that change follows measurement instead of
+    // preceding it. `detail` is permitted on `executed-pass` (RFC 0148 §A only
+    // REQUIRES it for other dispositions), so this is additive on the wire.
+    detail = `${PARTIAL_WITNESS_PREFIX}${noted.kind}: ${noted.reason}`;
   }
   return detail === undefined ? { disposition } : { disposition, detail };
 }

package/src/lib/webhook-receiver.test.ts

@@ -0,0 +1,76 @@
+/**
+ * Unit tests for `webhook-receiver.ts` — the signature-header contract.
+ *
+ * This verifier is the reference a subscriber implementer copies. It required
+ * `v1=` and therefore rejected, as malformed, the exact header `webhooks.md`
+ * §"Delivery headers" mandates (`X-openwop-Signature: sha256={hex}`). The
+ * divergence survived because `webhook-receiver-adversarial.test.ts` signs with
+ * `signPayload` and verifies with `verifyWebhookDelivery` — a closed loop that is
+ * self-consistent and wrong, and so green against every host. These cases pin the
+ * header against the SPEC rather than against the suite's own output.
+ *
+ * @see webhook-receiver.ts, spec/v1/webhooks.md §"Delivery headers"
+ */
+
+import { describe, it, expect } from 'vitest';
+import { createHmac } from 'node:crypto';
+import {
+  SIGNATURE_PREFIX,
+  createReceiverState,
+  verifyWebhookDelivery,
+  signPayload,
+} from './webhook-receiver.js';
+
+const SECRET = 'shhh-not-a-real-secret';
+const BODY = JSON.stringify({ event: { type: 'run.completed' } });
+
+/** Build the header exactly as `webhooks.md` documents it, not as we emit it. */
+function specShapedHeader(ts: number): string {
+  const hex = createHmac('sha256', SECRET).update(`${ts}.${BODY}`).digest('hex');
+  return `sha256=${hex}`;
+}
+
+describe('webhook-receiver: the X-openwop-Signature prefix follows the spec', () => {
+  it('the constant is the spec value, not the algorithm-header value', () => {
+    // `v1` names the SIGNING SCHEME (X-openwop-Signature-Algorithm). It is not
+    // the encoding prefix. One value, two fields — the conflation this fixes.
+    expect(SIGNATURE_PREFIX).toBe('sha256=');
+  });
+
+  it('ACCEPTS a header built to the spec by hand, with no help from signPayload', () => {
+    const ts = Math.floor(Date.now() / 1000);
+    const result = verifyWebhookDelivery(
+      SECRET,
+      specShapedHeader(ts),
+      'v1',
+      String(ts),
+      BODY,
+      createReceiverState(),
+    );
+    expect(result.accepted).toBe(true);
+  });
+
+  it('REJECTS the pre-2026-08-19 `v1=` prefix as malformed — the shape the spec never defined', () => {
+    const ts = Math.floor(Date.now() / 1000);
+    const hex = createHmac('sha256', SECRET).update(`${ts}.${BODY}`).digest('hex');
+    const result = verifyWebhookDelivery(
+      SECRET,
+      `v1=${hex}`,
+      'v1',
+      String(ts),
+      BODY,
+      createReceiverState(),
+    );
+    expect(result.accepted).toBe(false);
+    if (!result.accepted) expect(result.reason).toBe('malformed_signature_header');
+  });
+
+  it('signPayload emits what the verifier accepts AND what the spec documents', () => {
+    const ts = Math.floor(Date.now() / 1000);
+    const { signatureHeader, algorithmHeader } = signPayload(SECRET, ts, BODY);
+    // Both halves matter: agreeing with the verifier alone is the closed loop
+    // that hid the bug, so this also compares against the hand-built header.
+    expect(signatureHeader).toBe(specShapedHeader(ts));
+    expect(algorithmHeader).toBe('v1');
+  });
+});