@openwop/spec-artifacts 2.42.6 → 2.42.8

package/spec/v2/ext/entities/README.md

@@ -1,7 +1,8 @@
 # `entities` extension
 
-> **Status: Draft · v2 extension.** Discovery-only reservation; no portable
-> operations or payload contract is defined in the current v2 corpus.
+> **Status: Draft.**
+
+`entities` names generic entity CRUD over projects and workspace assets. It is a discovery-only reservation: v2 defines no portable operations or payload contract for it.
 
 | Field | Value |
 | --- | --- |
@@ -10,24 +11,23 @@
 | **adoption:** | `single-witness` |
 | **peer-dependency id** | `entities` |
 | **advertised as** | `extensions.<org>.entities` |
-| **owning RFC** | RFC 0144 |
 | **declared facets** | none defined |
 
 ## Contract boundary
 
-A host MAY advertise this identifier under its registered organization namespace.
-The extension record is organization-defined, so clients MUST NOT infer portable
-operations, payloads, or authorization semantics from its presence. A pack may
-name `entities` as a dependency only when the host and pack share
-an out-of-band definition of that dependency.
+A host MAY advertise `entities` as `extensions["<org>.entities"]`, where `<org>` is its registered organization ([capabilities.md §3.2](../../core/capabilities.md)). The record is organization-defined, so:
 
-The v1 description,
-[`spec/v1/host-capabilities.md`](https://github.com/openwop/openwop/blob/main/spec/v1/host-capabilities.md#hostentities)
-(§host.entities), is useful for migration but is not a
-standalone v2 interoperability contract. A future revision can replace this
-boundary with normative behavior, schemas, and a behavioral witness.
+- a client MUST NOT infer portable operations, payloads, or authorization semantics from its presence;
+- a pack may name `entities` as a dependency only when the host and pack share an out-of-band definition of it.
 
 ## Conformance
 
-The current `claims-check` witness validates only that the discovery claim is
-well formed. It does not demonstrate compatible runtime behavior.
+The `claims-check` witness checks only that the discovery claim is well formed, not runtime behavior. `conformance/src/scenarios/v2-ext-family-claims.test.ts` records it under `openwop.family.entities`:
+
+- the key `<org>.entities` matches `extensionsKeyPattern`, and `<org>` is registered and not reserved;
+- the record is a JSON object;
+- `entities` is not also a member of the discovery root.
+
+A host that does not advertise the family records `inapplicable`. A `Stable` label on this page therefore means a host at evidence tier 2 or better advertises the reservation correctly. It does not mean two hosts interoperate on it ([`../README.md`](../README.md)).
+
+*Sources: RFC 0144.*

package/spec/v2/ext/grpc-transport/README.md

@@ -1,7 +1,8 @@
 # gRPC transport notes
 
-> **Status: Draft · non-normative note.** This is not a declared extension
-> family and is outside this rule.
+> **Status: Note.**
+
+A non-normative note, not a declared family. v2 has no normative gRPC transport, because the conformance suite has no gRPC client or behavioral witness.
 
 | Field | Value |
 | --- | --- |
@@ -9,10 +10,7 @@
 | **technical:** | `experimental` |
 | **adoption:** | `none` |
 | **advertised as** | not advertisable; v2 has no `grpc` discovery record |
-| **owning RFC** | RFC 0175 (demotion); RFC 0094 §H (v1 text) |
 
-The [v1 `openwop.proto`](https://github.com/openwop/openwop/blob/main/spec/v2/ext/grpc-transport/openwop.proto)
-is retained as a sketch and uses `package openwop.v1`; it is not a v2 contract.
-v2 has no normative gRPC transport because the conformance suite has no gRPC
-client or behavioral witness. The v1 contract remains in
-[`spec/v1/grpc-transport.md`](https://github.com/openwop/openwop/blob/main/spec/v1/grpc-transport.md).
+[`openwop.proto`](https://github.com/openwop/openwop/blob/main/spec/v2/ext/grpc-transport/openwop.proto) is a sketch only. It is not a v2 contract.
+
+*Sources: RFC 0094, RFC 0175.*

package/spec/v2/ext/kanban/README.md

@@ -1,7 +1,8 @@
 # `kanban` extension
 
-> **Status: Draft · v2 extension.** Discovery-only reservation; no portable
-> operations or payload contract is defined in the current v2 corpus.
+> **Status: Draft.**
+
+`kanban` names board, task, timeline and automation operations. It is a discovery-only reservation: v2 defines no portable operations or payload contract for it.
 
 | Field | Value |
 | --- | --- |
@@ -10,24 +11,23 @@
 | **adoption:** | `single-witness` |
 | **peer-dependency id** | `kanban` |
 | **advertised as** | `extensions.<org>.kanban` |
-| **owning RFC** | RFC 0144 |
 | **declared facets** | none defined |
 
 ## Contract boundary
 
-A host MAY advertise this identifier under its registered organization namespace.
-The extension record is organization-defined, so clients MUST NOT infer portable
-operations, payloads, or authorization semantics from its presence. A pack may
-name `kanban` as a dependency only when the host and pack share
-an out-of-band definition of that dependency.
+A host MAY advertise `kanban` as `extensions["<org>.kanban"]`, where `<org>` is its registered organization ([capabilities.md §3.2](../../core/capabilities.md)). The record is organization-defined, so:
 
-The v1 description,
-[`spec/v1/host-capabilities.md`](https://github.com/openwop/openwop/blob/main/spec/v1/host-capabilities.md#hostkanban)
-(§host.kanban), is useful for migration but is not a
-standalone v2 interoperability contract. A future revision can replace this
-boundary with normative behavior, schemas, and a behavioral witness.
+- a client MUST NOT infer portable operations, payloads, or authorization semantics from its presence;
+- a pack may name `kanban` as a dependency only when the host and pack share an out-of-band definition of it.
 
 ## Conformance
 
-The current `claims-check` witness validates only that the discovery claim is
-well formed. It does not demonstrate compatible runtime behavior.
+The `claims-check` witness checks only that the discovery claim is well formed, not runtime behavior. `conformance/src/scenarios/v2-ext-family-claims.test.ts` records it under `openwop.family.kanban`:
+
+- the key `<org>.kanban` matches `extensionsKeyPattern`, and `<org>` is registered and not reserved;
+- the record is a JSON object;
+- `kanban` is not also a member of the discovery root.
+
+A host that does not advertise the family records `inapplicable`. A `Stable` label on this page therefore means a host at evidence tier 2 or better advertises the reservation correctly. It does not mean two hosts interoperate on it ([`../README.md`](../README.md)).
+
+*Sources: RFC 0144.*

package/spec/v2/ext/knowledge/README.md

@@ -1,7 +1,8 @@
 # `knowledge` extension
 
-> **Status: Draft · v2 extension.** Discovery-only reservation; no portable
-> operations or payload contract is defined in the current v2 corpus.
+> **Status: Draft.**
+
+`knowledge` names knowledge-base retrieval through the host's RAG pipeline. It is a discovery-only reservation: v2 defines no portable operations or payload contract for it.
 
 | Field | Value |
 | --- | --- |
@@ -10,24 +11,23 @@
 | **adoption:** | `single-witness` |
 | **peer-dependency id** | `knowledge` |
 | **advertised as** | `extensions.<org>.knowledge` |
-| **owning RFC** | RFC 0144 |
 | **declared facets** | none defined |
 
 ## Contract boundary
 
-A host MAY advertise this identifier under its registered organization namespace.
-The extension record is organization-defined, so clients MUST NOT infer portable
-operations, payloads, or authorization semantics from its presence. A pack may
-name `knowledge` as a dependency only when the host and pack share
-an out-of-band definition of that dependency.
+A host MAY advertise `knowledge` as `extensions["<org>.knowledge"]`, where `<org>` is its registered organization ([capabilities.md §3.2](../../core/capabilities.md)). The record is organization-defined, so:
 
-The v1 description,
-[`spec/v1/host-capabilities.md`](https://github.com/openwop/openwop/blob/main/spec/v1/host-capabilities.md#hostknowledge)
-(§host.knowledge), is useful for migration but is not a
-standalone v2 interoperability contract. A future revision can replace this
-boundary with normative behavior, schemas, and a behavioral witness.
+- a client MUST NOT infer portable operations, payloads, or authorization semantics from its presence;
+- a pack may name `knowledge` as a dependency only when the host and pack share an out-of-band definition of it.
 
 ## Conformance
 
-The current `claims-check` witness validates only that the discovery claim is
-well formed. It does not demonstrate compatible runtime behavior.
+The `claims-check` witness checks only that the discovery claim is well formed, not runtime behavior. `conformance/src/scenarios/v2-ext-family-claims.test.ts` records it under `openwop.family.knowledge`:
+
+- the key `<org>.knowledge` matches `extensionsKeyPattern`, and `<org>` is registered and not reserved;
+- the record is a JSON object;
+- `knowledge` is not also a member of the discovery root.
+
+A host that does not advertise the family records `inapplicable`. A `Stable` label on this page therefore means a host at evidence tier 2 or better advertises the reservation correctly. It does not mean two hosts interoperate on it ([`../README.md`](../README.md)).
+
+*Sources: RFC 0144.*

package/spec/v2/ext/launchStudio/README.md

@@ -1,7 +1,8 @@
 # `launchStudio` extension
 
-> **Status: Draft · v2 extension.** Discovery-only reservation; no portable
-> operations or payload contract is defined in the current v2 corpus.
+> **Status: Draft.**
+
+`launchStudio` names launch-studio operations for the multi-canvas launch workflow. It is a discovery-only reservation: v2 defines no portable operations or payload contract for it.
 
 | Field | Value |
 | --- | --- |
@@ -9,25 +10,24 @@
 | **technical:** | `experimental` |
 | **adoption:** | `single-witness` |
 | **peer-dependency id** | `launchStudio` |
-| **advertised as** | `extensions.<org>.launchStudio` |
-| **owning RFC** | RFC 0144 |
+| **advertised as** | `extensions.<org>.launch-studio` |
 | **declared facets** | none defined |
 
 ## Contract boundary
 
-A host MAY advertise this identifier under its registered organization namespace.
-The extension record is organization-defined, so clients MUST NOT infer portable
-operations, payloads, or authorization semantics from its presence. A pack may
-name `launchStudio` as a dependency only when the host and pack share
-an out-of-band definition of that dependency.
+A host MAY advertise `launchStudio` as `extensions["<org>.launch-studio"]`, where `<org>` is its registered organization ([capabilities.md §3.2](../../core/capabilities.md)). The record is organization-defined, so:
 
-The v1 description,
-[`spec/v1/host-capabilities.md`](https://github.com/openwop/openwop/blob/main/spec/v1/host-capabilities.md#hostlaunchstudio)
-(§host.launchStudio), is useful for migration but is not a
-standalone v2 interoperability contract. A future revision can replace this
-boundary with normative behavior, schemas, and a behavioral witness.
+- a client MUST NOT infer portable operations, payloads, or authorization semantics from its presence;
+- a pack may name `launchStudio` as a dependency only when the host and pack share an out-of-band definition of it.
 
 ## Conformance
 
-The current `claims-check` witness validates only that the discovery claim is
-well formed. It does not demonstrate compatible runtime behavior.
+The `claims-check` witness checks only that the discovery claim is well formed, not runtime behavior. `conformance/src/scenarios/v2-ext-family-claims.test.ts` records it under `openwop.family.launchStudio`:
+
+- the key `<org>.launch-studio` matches `extensionsKeyPattern`, and `<org>` is registered and not reserved;
+- the record is a JSON object;
+- `launchStudio` is not also a member of the discovery root.
+
+A host that does not advertise the family records `inapplicable`. A `Stable` label on this page therefore means a host at evidence tier 2 or better advertises the reservation correctly. It does not mean two hosts interoperate on it ([`../README.md`](../README.md)).
+
+*Sources: RFC 0144.*

package/spec/v2/ext/messaging/README.md

@@ -1,7 +1,8 @@
 # `messaging` extension
 
-> **Status: Draft · v2 extension.** Discovery-only reservation; no portable
-> operations or payload contract is defined in the current v2 corpus.
+> **Status: Draft.**
+
+`messaging` names outbound chat-egress dispatch through host-owned connectors. It is a discovery-only reservation: v2 defines no portable operations or payload contract for it.
 
 | Field | Value |
 | --- | --- |
@@ -10,24 +11,23 @@
 | **adoption:** | `single-witness` |
 | **peer-dependency id** | `messaging` |
 | **advertised as** | `extensions.<org>.messaging` |
-| **owning RFC** | RFC 0144 |
 | **declared facets** | none defined |
 
 ## Contract boundary
 
-A host MAY advertise this identifier under its registered organization namespace.
-The extension record is organization-defined, so clients MUST NOT infer portable
-operations, payloads, or authorization semantics from its presence. A pack may
-name `messaging` as a dependency only when the host and pack share
-an out-of-band definition of that dependency.
+A host MAY advertise `messaging` as `extensions["<org>.messaging"]`, where `<org>` is its registered organization ([capabilities.md §3.2](../../core/capabilities.md)). The record is organization-defined, so:
 
-The v1 description,
-[`spec/v1/host-capabilities.md`](https://github.com/openwop/openwop/blob/main/spec/v1/host-capabilities.md#hostmessaging)
-(§host.messaging), is useful for migration but is not a
-standalone v2 interoperability contract. A future revision can replace this
-boundary with normative behavior, schemas, and a behavioral witness.
+- a client MUST NOT infer portable operations, payloads, or authorization semantics from its presence;
+- a pack may name `messaging` as a dependency only when the host and pack share an out-of-band definition of it.
 
 ## Conformance
 
-The current `claims-check` witness validates only that the discovery claim is
-well formed. It does not demonstrate compatible runtime behavior.
+The `claims-check` witness checks only that the discovery claim is well formed, not runtime behavior. `conformance/src/scenarios/v2-ext-family-claims.test.ts` records it under `openwop.family.messaging`:
+
+- the key `<org>.messaging` matches `extensionsKeyPattern`, and `<org>` is registered and not reserved;
+- the record is a JSON object;
+- `messaging` is not also a member of the discovery root.
+
+A host that does not advertise the family records `inapplicable`. A `Stable` label on this page therefore means a host at evidence tier 2 or better advertises the reservation correctly. It does not mean two hosts interoperate on it ([`../README.md`](../README.md)).
+
+*Sources: RFC 0144.*

package/spec/v2/ext/portability/README.md

@@ -1,21 +1,7 @@
 # Portability notes
 
-> **Status: Draft · non-core note.** This is not a declared extension family
-> and is outside this rule.
+> **Status: Retired.**
 
-| Field | Value |
-| --- | --- |
-| **witness:** | `claims-check` |
-| **technical:** | `experimental` |
-| **adoption:** | `none` |
-| **advertised as** | `extensions.<org>.portability` |
-| **owning RFC** | RFC 0168 §C.1; RFC 0174 §E.2; RFCs 0086 and 0087 (v1 text) |
+Superseded by: [portability.md](../../core/portability.md).
 
-The v2 core API does not define goals, export, or import operations. The
-[`export-bundle` schema](../../../../schemas/v2/export-bundle.schema.json) records
-the proposed bundle shape, but no portable transport or behavioral witness is
-defined. A host MAY expose an organization-specific portability extension; a
-client MUST NOT assume it is compatible with another host's extension.
-
-The v1 background is in
-[`spec/v1/portability.md`](https://github.com/openwop/openwop/blob/main/spec/v1/portability.md).
+This page is not a declared extension family. `portability` is a core family, and its rules live there.

package/spec/v2/ext/provider-idempotency/README.md

@@ -1,19 +1,16 @@
 # Provider idempotency registry
 
-> **Status: Draft · supporting registry.** This is not a declared extension
-> family and is outside this rule.
+> **Status: Note.**
+
+A supporting registry, not a declared family.
 
 | Field | Value |
 | --- | --- |
 | **witness:** | `witnessable-gated` |
 | **technical:** | `experimental` |
 | **adoption:** | `none` |
-| **advertised as** | not applicable; supporting registry only |
-| **owning RFC** | RFC 0173 §C.2, RFC 0150 G3 |
+| **advertised as** | not applicable |
+
+[`registry.json`](./registry.json) lists providers known to expose a natural business-identity key. It informs the Layer-2 idempotency requirement in [`security-defaults.md`](../../core/security-defaults.md). Hosts report the chosen strategy through `GET /runs/{runId}/effects` and the `keying` field of `effect-ledger-projection.schema.json`.
 
-[`registry.json`](./registry.json) lists providers known to expose a natural
-business-identity key. It informs the Layer-2 idempotency requirement in
-[`security-defaults.md`](../../core/security-defaults.md); it does not add a
-discovery family. Hosts report the chosen strategy through
-`GET /runs/{runId}/effects` and the `keying` field of
-`effect-ledger-projection.schema.json`.
+*Sources: RFC 0150, RFC 0173.*

package/spec/v2/ext/restTransport/README.md

@@ -1,33 +1,44 @@
 # `restTransport` extension
 
-> **Status: Draft · v2 extension.** Discovery-only reservation; no portable
-> operations or payload contract is defined in the current v2 corpus.
+> **Status: Draft.**
+
+`restTransport` names conditional GET and response compression on run reads. The run-snapshot rules are in [`runs.md`](../../core/runs.md) §"Caching and encoding". This page defines the claim and what advertising it adds to those rules.
 
 | Field | Value |
 | --- | --- |
-| **witness:** | `claims-check` |
+| **witness:** | `witnessable-gated` |
 | **technical:** | `experimental` |
-| **adoption:** | `none` |
+| **adoption:** | `single-witness` |
 | **peer-dependency id** | `restTransport` |
-| **advertised as** | `extensions.<org>.restTransport` |
-| **owning RFC** | RFC 0115 |
+| **advertised as** | `extensions.<org>.rest-transport` |
 | **declared facets** | `conditionalRunGet`, `contentEncodings` |
 
-## Contract boundary
+## The claim
+
+A host MAY advertise `restTransport` as `extensions["<org>.rest-transport"]`, where `<org>` is its registered organization ([capabilities.md §3.2](../../core/capabilities.md)). The record's two facets are:
+
+| Facet | Type | Meaning |
+| --- | --- | --- |
+| `conditionalRunGet` | boolean | `true` claims a validator on every run-snapshot read |
+| `contentEncodings` | array of `gzip`, `br`, `zstd` | the codings the host produces for a run-snapshot read |
+
+Other members of the record are the organization's own.
+
+## What the claim adds
 
-A host MAY advertise this identifier under its registered organization namespace.
-The extension record is organization-defined, so clients MUST NOT infer portable
-operations, payloads, or authorization semantics from its presence. A pack may
-name `restTransport` as a dependency only when the host and pack share
-an out-of-band definition of that dependency.
+A host whose record sets `conditionalRunGet: true` MUST carry, on every `200` of `GET /runs/{runId}`, the strong `ETag` that runs.md §"Caching and encoding" makes a SHOULD. The stability and `304` rules there then always apply.
 
-The v1 description,
-[`spec/v1/capabilities.md`](https://github.com/openwop/openwop/blob/main/spec/v1/capabilities.md)
-(`restTransport`), is useful for migration but is not a
-standalone v2 interoperability contract. A future revision can replace this
-boundary with normative behavior, schemas, and a behavioral witness.
+For each coding listed in `contentEncodings`, a request that names only that coding in `Accept-Encoding` MUST receive it, subject to the rules in runs.md §"Caching and encoding".
+
+A client MUST NOT infer anything else from the record.
 
 ## Conformance
 
-The current `claims-check` witness validates only that the discovery claim is
-well formed. It does not demonstrate compatible runtime behavior.
+`conformance/src/scenarios/v2-ext-rest-transport.test.ts` (major 2) records the witness under `openwop.family.restTransport`:
+
+- **Conditional GET:** runs the `conformance-approval` fixture to `waiting-approval`. It checks for a strong `ETag`, a `304` with no body on a matching `If-None-Match`, and a changed `ETag` once the run completes.
+- **Codings:** for each advertised coding, the decoded body is byte-identical to the identity body.
+
+A host without the claim records `inapplicable`. A host that makes the claim but lacks the fixture records `blocked`.
+
+*Sources: RFC 0115, RFC 0220.*

package/spec/v2/ext/sandbox-runtime-notes/README.md

@@ -1,18 +1,16 @@
 # Sandbox runtime notes
 
-> **Status: Draft · non-normative note.** This is not a declared extension
-> family and is outside this rule.
+> **Status: Note.**
+
+A non-normative note, not a declared family.
 
 | Field | Value |
 | --- | --- |
 | **witness:** | `unwitnessable` |
 | **technical:** | `experimental` |
 | **adoption:** | `none` |
-| **advertised as** | not advertisable (notes, not a surface) |
-| **owning RFC** | RFC 0173 §D; RFC 0035 (superseded) |
+| **advertised as** | not advertisable |
+
+`node:vm` is not an isolation model; its demonstrator is implementation history only. The v2 contract is in [`security-defaults.md`](../../core/security-defaults.md): `sandbox.isolationModel` is one of `wasm`, `process`, `container`, or `vm`, and pack execution is bound to the advertised isolation mode.
 
-RFC 0035's `node:vm` demonstrator is retained only as implementation history;
-`node:vm` is not an isolation model. The v2 contract is in
-[`security-defaults.md`](../../core/security-defaults.md):
-`sandbox.isolationModel` is one of `wasm`, `process`, `container`, or `vm`, and
-pack execution is bound to the advertised isolation mode.
+*Sources: RFC 0035, RFC 0173.*

package/spec/v2/ext/webResearch/README.md

@@ -1,7 +1,8 @@
 # `webResearch` extension
 
-> **Status: Draft · v2 extension.** Discovery-only reservation; no portable
-> operations or payload contract is defined in the current v2 corpus.
+> **Status: Draft.**
+
+`webResearch` names search, fetch and research orchestration through the host's search adapter. It is a discovery-only reservation: v2 defines no portable operations or payload contract for it.
 
 | Field | Value |
 | --- | --- |
@@ -9,25 +10,24 @@
 | **technical:** | `experimental` |
 | **adoption:** | `single-witness` |
 | **peer-dependency id** | `webResearch` |
-| **advertised as** | `extensions.<org>.webResearch` |
-| **owning RFC** | RFC 0144 |
+| **advertised as** | `extensions.<org>.web-research` |
 | **declared facets** | none defined |
 
 ## Contract boundary
 
-A host MAY advertise this identifier under its registered organization namespace.
-The extension record is organization-defined, so clients MUST NOT infer portable
-operations, payloads, or authorization semantics from its presence. A pack may
-name `webResearch` as a dependency only when the host and pack share
-an out-of-band definition of that dependency.
+A host MAY advertise `webResearch` as `extensions["<org>.web-research"]`, where `<org>` is its registered organization ([capabilities.md §3.2](../../core/capabilities.md)). The record is organization-defined, so:
 
-The v1 description,
-[`spec/v1/host-capabilities.md`](https://github.com/openwop/openwop/blob/main/spec/v1/host-capabilities.md#hostwebresearch)
-(§host.webResearch), is useful for migration but is not a
-standalone v2 interoperability contract. A future revision can replace this
-boundary with normative behavior, schemas, and a behavioral witness.
+- a client MUST NOT infer portable operations, payloads, or authorization semantics from its presence;
+- a pack may name `webResearch` as a dependency only when the host and pack share an out-of-band definition of it.
 
 ## Conformance
 
-The current `claims-check` witness validates only that the discovery claim is
-well formed. It does not demonstrate compatible runtime behavior.
+The `claims-check` witness checks only that the discovery claim is well formed, not runtime behavior. `conformance/src/scenarios/v2-ext-family-claims.test.ts` records it under `openwop.family.webResearch`:
+
+- the key `<org>.web-research` matches `extensionsKeyPattern`, and `<org>` is registered and not reserved;
+- the record is a JSON object;
+- `webResearch` is not also a member of the discovery root.
+
+A host that does not advertise the family records `inapplicable`. A `Stable` label on this page therefore means a host at evidence tier 2 or better advertises the reservation correctly. It does not mean two hosts interoperate on it ([`../README.md`](../README.md)).
+
+*Sources: RFC 0144.*

package/spec/v2/profiles.json

@@ -4,6 +4,7 @@
   "profiles": [
     {
       "id": "openwop-discovery-core",
+      "summary": "The host publishes a valid v2 discovery document and negotiates the protocol version; it makes no claim about running workflows.",
       "predicate": {
         "families": [],
         "metadata": [
@@ -21,6 +22,7 @@
     },
     {
       "id": "openwop-core-standard",
+      "summary": "The host runs workflows to the executable floor: interrupts, replay, webhooks, idempotency and the event log. This is what an unqualified \"OpenWOP conformant\" claim means.",
       "predicate": {
         "families": [
           "interrupt",
@@ -43,13 +45,15 @@
         "v2-run-bulk-cancel",
         "v2-run-pause-resume",
         "v2-run-options-limits",
-        "v2-sse-last-event-id"
+        "v2-sse-last-event-id",
+        "v2-sse-last-event-id-cursor"
       ],
       "requirementIds": [],
-      "note": "rc.59: five unaided run-surface witnesses joined the floor — v2-run-cancel (runs.md §Cancel: 409 run_terminal on a terminal run), v2-run-bulk-cancel (§Cancel: per-entry envelopes, id_tenant_mismatch / not_found, details.maxRunIds), v2-run-pause-resume (§Pause and resume: 409 run_terminal / run_state_conflict, the literal drainPolicy echo, the immediate cut), v2-run-options-limits (capabilities.md limits metadata honoured on create), v2-sse-last-event-id (events.md §SSE frames: Last-Event-ID resumes at the next sequence, never re-emits the resumption point). cancelRun, bulkCancelRuns and pauseRun are core operations by the runs.md surface table (only ancestry, annotations and eval-summary are 404-when-unadvertised), so a host that omits one is blocked, not inapplicable, and the floor refuses it — the prose's outcome. Their optional legs (values mode, the conformance-delay / conformance-cancellable fixtures) record inapplicable with the reason and the file row stays a witnessed pass. Measured before the change: the reference host passes all five (rc.58, 179 / 0 / 0 / 42); neither production host satisfies this predicate, so no existing claim moves. seeded from spec/v1/core-standard-manifest.json at P3-B; floor minted rc.45, one or more unaided witnesses per predicate family: interrupt (token scheme), replay (the effect-seam manifest — its seam-driven no-re-fire leg lives in v2-effect-seam-no-refire on the seams floor), webhooks (durable delivery), idempotency (Layer-1 key grammar), eventLog (era key, era stamp, closed event type, poll cursor). Deliberately absent: v2-pinned-run-disposition (seam-gated and opt-in), v2-v1-signed-webhook-accepted (a coexistence scenario, driven through the seam; the cut gate is its home), v2-effect-identity-business-key (retry leg seam-driven), v2-approver-enforced (conditional on the refKinds facet)."
+      "note": "2.42.7: v2-sse-last-event-id-cursor joined the floor (events.md §SSE frames, RFC 0213 §A: Last-Event-ID is an exclusive cursor, a well-formed id past the log is not refused, and the header is read only after authorization). It was held off the floor until the three bundle hosts were measured. Measured on committed bundles, it is executed-pass on the v2 reference host (2.42.2), MyndHyve (2.42.0) and openwop-app (2.42.2 side revision); the first two carry partial-witness only for the SHOULD leg (a malformed id accepted, recorded not failed), so no existing claim moves. rc.59: five unaided run-surface witnesses joined the floor — v2-run-cancel (runs.md §Cancel: 409 run_terminal on a terminal run), v2-run-bulk-cancel (§Cancel: per-entry envelopes, id_tenant_mismatch / not_found, details.maxRunIds), v2-run-pause-resume (§Pause and resume: 409 run_terminal / run_state_conflict, the literal drainPolicy echo, the immediate cut), v2-run-options-limits (capabilities.md limits metadata honoured on create), v2-sse-last-event-id (events.md §SSE frames: Last-Event-ID resumes at the next sequence, never re-emits the resumption point). cancelRun, bulkCancelRuns and pauseRun are core operations by the runs.md surface table (only ancestry, annotations and eval-summary are 404-when-unadvertised), so a host that omits one is blocked, not inapplicable, and the floor refuses it — the prose's outcome. Their optional legs (values mode, the conformance-delay / conformance-cancellable fixtures) record inapplicable with the reason and the file row stays a witnessed pass. Measured before the change: the reference host passes all five (rc.58, 179 / 0 / 0 / 42); neither production host satisfies this predicate, so no existing claim moves. seeded from spec/v1/core-standard-manifest.json at P3-B; floor minted rc.45, one or more unaided witnesses per predicate family: interrupt (token scheme), replay (the effect-seam manifest — its seam-driven no-re-fire leg lives in v2-effect-seam-no-refire on the seams floor), webhooks (durable delivery), idempotency (Layer-1 key grammar), eventLog (era key, era stamp, closed event type, poll cursor). Deliberately absent: v2-pinned-run-disposition (seam-gated and opt-in), v2-v1-signed-webhook-accepted (a coexistence scenario, driven through the seam; the cut gate is its home), v2-effect-identity-business-key (retry leg seam-driven), v2-approver-enforced (conditional on the refKinds facet)."
     },
     {
       "id": "openwop-conformance-seams-v2",
+      "summary": "The host mounts the conformance test seams under /conformance/seams/ so the suite can drive seam-based scenarios; it is a testing surface, not a production feature.",
       "predicate": {
         "families": [],
         "metadata": [

package/spec/v2/release.json

@@ -1,6 +1,6 @@
 {
   "$comment": "RFC 0172 §D.1 — the one release identity the v2 artifacts derive from. `version` is the next corpus tag `v<version>` (the publish workflow's coordinated-release tag pattern `v*`; RFC 0172's `openwop/v2.<minor>.<patch>` spelling is amended to this at its flip). api/v2/*.yaml info.version, the suite's 2.x version and @openwop/spec-artifacts read it. Bumped by the release PR that cuts the tag, never by hand elsewhere.",
-  "version": "2.42.6",
-  "corpusTag": "v2.42.6",
+  "version": "2.42.8",
+  "corpusTag": "v2.42.8",
   "updated": "2026-09-27"
 }