@openwop/spec-artifacts 2.3.4 → 2.4.1

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

@@ -1,4 +1,7 @@
-# `entities` — extension
+# `entities` extension
+
+> **Status: Draft · v2 extension.** Discovery-only reservation; no portable
+> operations or payload contract is defined in v2.3.3.
 
 | Field | Value |
 | --- | --- |
@@ -6,15 +9,23 @@
 | **technical:** | `experimental` |
 | **adoption:** | `single-witness` |
 | **peer-dependency id** | `entities` |
-| **advertised as** | `extensions.<org>.entities` (RFC 0169 §A.4) — never a root key |
+| **advertised as** | `extensions.<org>.entities` |
 | **owning RFC** | RFC 0144 |
+| **declared facets** | none defined |
 
-> **Status: Draft · v2.0.0-rc (2026-09-03).** Extension document (RFC 0169 §B.3; RFC 0167 Axiom 1: a family that cannot be witnessed unaided lives here and is not a core obligation).
+## Contract boundary
 
-## What it is
+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.
 
-RFC 0169 §B.3 (RFC 0144 extension class; prose-only §host.* section in v1; served under extensions.openwop-app.* by the one host that has it) The v1 prose that defines the surface is `spec/v1/host-capabilities.md` §host.entities (RFC 0144 extension class); it stands as the definition until this document carries its own normative text (P3-E and the Phase 4 host legs). A host that serves this surface advertises it under `extensions.<org>.entities` with the RFC 0169 record shape; a pack that requires it names `entities` in `peerDependencies` (RFC 0177 §B.1).
+The v1 description, [`spec/v1/host-capabilities.md`](https://github.com/openwop/openwop/blob/v2.3.3/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.
 
-## Witness
+## Conformance
 
-`claims-check`: the suite can read the claim from discovery but has no behavioral probe; adoption is measured by the INTEROP-MATRIX bundle evidence.
+The current `claims-check` witness validates only that the discovery claim is
+well formed. It does not demonstrate compatible runtime behavior.

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

@@ -1,13 +1,18 @@
-# `grpc-transport` — extension (demoted)
+# gRPC transport notes
+
+> **Status: Draft · non-normative note.** This is not a declared extension
+> family and is outside this rule.
 
 | Field | Value |
 | --- | --- |
 | **witness:** | `unwitnessable` |
 | **technical:** | `experimental` |
 | **adoption:** | `none` |
-| **advertised as** | not advertisable — no `grpc` block exists at the v2 root (RFC 0175 §A.1; RFC 0169 §A.1) |
+| **advertised as** | not advertisable; v2 has no `grpc` discovery record |
 | **owning RFC** | RFC 0175 (demotion); RFC 0094 §H (v1 text) |
 
-> **Status: Draft · v2.0.0-rc (2026-09-03).** RFC 0175 §A.1: `grpc-transport.md` leaves `core/`; the suite ships no gRPC client and no host advertises the block, so the transport is `unwitnessable`. Its six v1 MUSTs are SHOULDs of this extension. `openwop.proto` beside this file is a NON-NORMATIVE sketch (the v1 proto, unchanged; `package openwop.v1`). The door back into core is named: a v2.x additive RFC that generates the proto from `spec/v2/declaration.json` and lands a suite client. **Not a declared family — notes, outside the `ext/README.md` maturity rule; `Draft` here means unfrozen prose, not an unwitnessed family.**
-
-The v1 definition stands at `spec/v1/grpc-transport.md` for v1.x hosts.
+The [v1 `openwop.proto`](https://github.com/openwop/openwop/blob/v2.3.3/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/v2.3.3/spec/v1/grpc-transport.md).

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

@@ -1,4 +1,7 @@
-# `kanban` — extension
+# `kanban` extension
+
+> **Status: Draft · v2 extension.** Discovery-only reservation; no portable
+> operations or payload contract is defined in v2.3.3.
 
 | Field | Value |
 | --- | --- |
@@ -6,15 +9,23 @@
 | **technical:** | `experimental` |
 | **adoption:** | `single-witness` |
 | **peer-dependency id** | `kanban` |
-| **advertised as** | `extensions.<org>.kanban` (RFC 0169 §A.4) — never a root key |
+| **advertised as** | `extensions.<org>.kanban` |
 | **owning RFC** | RFC 0144 |
+| **declared facets** | none defined |
 
-> **Status: Draft · v2.0.0-rc (2026-09-03).** Extension document (RFC 0169 §B.3; RFC 0167 Axiom 1: a family that cannot be witnessed unaided lives here and is not a core obligation).
+## Contract boundary
 
-## What it is
+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.
 
-RFC 0169 §B.3 (RFC 0144 extension class; prose-only §host.* section in v1; served under extensions.openwop-app.* by the one host that has it) The v1 prose that defines the surface is `spec/v1/host-capabilities.md` §host.kanban (RFC 0144 extension class); it stands as the definition until this document carries its own normative text (P3-E and the Phase 4 host legs). A host that serves this surface advertises it under `extensions.<org>.kanban` with the RFC 0169 record shape; a pack that requires it names `kanban` in `peerDependencies` (RFC 0177 §B.1).
+The v1 description, [`spec/v1/host-capabilities.md`](https://github.com/openwop/openwop/blob/v2.3.3/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.
 
-## Witness
+## Conformance
 
-`claims-check`: the suite can read the claim from discovery but has no behavioral probe; adoption is measured by the INTEROP-MATRIX bundle evidence.
+The current `claims-check` witness validates only that the discovery claim is
+well formed. It does not demonstrate compatible runtime behavior.

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

@@ -1,4 +1,7 @@
-# `knowledge` — extension
+# `knowledge` extension
+
+> **Status: Draft · v2 extension.** Discovery-only reservation; no portable
+> operations or payload contract is defined in v2.3.3.
 
 | Field | Value |
 | --- | --- |
@@ -6,15 +9,23 @@
 | **technical:** | `experimental` |
 | **adoption:** | `single-witness` |
 | **peer-dependency id** | `knowledge` |
-| **advertised as** | `extensions.<org>.knowledge` (RFC 0169 §A.4) — never a root key |
+| **advertised as** | `extensions.<org>.knowledge` |
 | **owning RFC** | RFC 0144 |
+| **declared facets** | none defined |
 
-> **Status: Draft · v2.0.0-rc (2026-09-03).** Extension document (RFC 0169 §B.3; RFC 0167 Axiom 1: a family that cannot be witnessed unaided lives here and is not a core obligation).
+## Contract boundary
 
-## What it is
+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.
 
-RFC 0169 §B.3 (RFC 0144 extension class; prose-only §host.* section in v1; served under extensions.openwop-app.* by the one host that has it) The v1 prose that defines the surface is `spec/v1/host-capabilities.md` §host.knowledge (RFC 0144 extension class); it stands as the definition until this document carries its own normative text (P3-E and the Phase 4 host legs). A host that serves this surface advertises it under `extensions.<org>.knowledge` with the RFC 0169 record shape; a pack that requires it names `knowledge` in `peerDependencies` (RFC 0177 §B.1).
+The v1 description, [`spec/v1/host-capabilities.md`](https://github.com/openwop/openwop/blob/v2.3.3/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.
 
-## Witness
+## Conformance
 
-`claims-check`: the suite can read the claim from discovery but has no behavioral probe; adoption is measured by the INTEROP-MATRIX bundle evidence.
+The current `claims-check` witness validates only that the discovery claim is
+well formed. It does not demonstrate compatible runtime behavior.

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

@@ -1,4 +1,7 @@
-# `launchStudio` — extension
+# `launchStudio` extension
+
+> **Status: Draft · v2 extension.** Discovery-only reservation; no portable
+> operations or payload contract is defined in v2.3.3.
 
 | Field | Value |
 | --- | --- |
@@ -6,15 +9,23 @@
 | **technical:** | `experimental` |
 | **adoption:** | `single-witness` |
 | **peer-dependency id** | `launchStudio` |
-| **advertised as** | `extensions.<org>.launchStudio` (RFC 0169 §A.4) — never a root key |
+| **advertised as** | `extensions.<org>.launchStudio` |
 | **owning RFC** | RFC 0144 |
+| **declared facets** | none defined |
 
-> **Status: Draft · v2.0.0-rc (2026-09-03).** Extension document (RFC 0169 §B.3; RFC 0167 Axiom 1: a family that cannot be witnessed unaided lives here and is not a core obligation).
+## Contract boundary
 
-## What it is
+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.
 
-RFC 0169 §B.3 (RFC 0144 extension class; prose-only §host.* section in v1; served under extensions.openwop-app.* by the one host that has it) The v1 prose that defines the surface is `spec/v1/host-capabilities.md` §host.launchStudio (RFC 0144 extension class); it stands as the definition until this document carries its own normative text (P3-E and the Phase 4 host legs). A host that serves this surface advertises it under `extensions.<org>.launchStudio` with the RFC 0169 record shape; a pack that requires it names `launchStudio` in `peerDependencies` (RFC 0177 §B.1).
+The v1 description, [`spec/v1/host-capabilities.md`](https://github.com/openwop/openwop/blob/v2.3.3/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.
 
-## Witness
+## Conformance
 
-`claims-check`: the suite can read the claim from discovery but has no behavioral probe; adoption is measured by the INTEROP-MATRIX bundle evidence.
+The current `claims-check` witness validates only that the discovery claim is
+well formed. It does not demonstrate compatible runtime behavior.

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

@@ -1,4 +1,7 @@
-# `messaging` — extension
+# `messaging` extension
+
+> **Status: Draft · v2 extension.** Discovery-only reservation; no portable
+> operations or payload contract is defined in v2.3.3.
 
 | Field | Value |
 | --- | --- |
@@ -6,15 +9,23 @@
 | **technical:** | `experimental` |
 | **adoption:** | `single-witness` |
 | **peer-dependency id** | `messaging` |
-| **advertised as** | `extensions.<org>.messaging` (RFC 0169 §A.4) — never a root key |
+| **advertised as** | `extensions.<org>.messaging` |
 | **owning RFC** | RFC 0144 |
+| **declared facets** | none defined |
 
-> **Status: Draft · v2.0.0-rc (2026-09-03).** Extension document (RFC 0169 §B.3; RFC 0167 Axiom 1: a family that cannot be witnessed unaided lives here and is not a core obligation).
+## Contract boundary
 
-## What it is
+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.
 
-RFC 0169 §B.3 (RFC 0144 extension class; prose-only §host.* section in v1; served under extensions.openwop-app.* by the one host that has it) The v1 prose that defines the surface is `spec/v1/host-capabilities.md` §host.messaging (RFC 0144 extension class); it stands as the definition until this document carries its own normative text (P3-E and the Phase 4 host legs). A host that serves this surface advertises it under `extensions.<org>.messaging` with the RFC 0169 record shape; a pack that requires it names `messaging` in `peerDependencies` (RFC 0177 §B.1).
+The v1 description, [`spec/v1/host-capabilities.md`](https://github.com/openwop/openwop/blob/v2.3.3/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.
 
-## Witness
+## Conformance
 
-`claims-check`: the suite can read the claim from discovery but has no behavioral probe; adoption is measured by the INTEROP-MATRIX bundle evidence.
+The current `claims-check` witness validates only that the discovery claim is
+well formed. It does not demonstrate compatible runtime behavior.

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

@@ -1,4 +1,7 @@
-# `portability` — extension (goals, export, import)
+# Portability notes
+
+> **Status: Draft · non-core note.** This is not a declared extension family
+> and is outside this rule.
 
 | Field | Value |
 | --- | --- |
@@ -8,4 +11,10 @@
 | **advertised as** | `extensions.<org>.portability` |
 | **owning RFC** | RFC 0168 (decided in C.1 per RFC 0174 §E.2), RFC 0086/0087 (v1 text) |
 
-> **Status: Draft · v2.0.0-rc (2026-09-03).** `/v1/goals`, `/v1/export`, `/v1/import` were absent from the v1 OpenAPI while `spec/v1/portability.md` and the goals prose described them (RFC 0174 §E.2 noted the decision belongs to C.1). Decided (Phase 3 plan §11): they do not enter `api/v2/openapi.yaml`; the export/import bundle (`schemas/v2/export-bundle.schema.json`, `bundleVersion` "2") and the goals surface are this extension, advertised under `extensions.<org>.portability`, with `spec/v1/portability.md` as the definition until a v2.x additive RFC lands their operations with a witness. **Not a declared family — notes, outside the `ext/README.md` maturity rule; `Draft` here means unfrozen prose, not an unwitnessed family.**
+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/v2.3.3/spec/v1/portability.md).

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

@@ -1,4 +1,7 @@
-# `provider-idempotency` — extension (registry)
+# Provider idempotency registry
+
+> **Status: Draft · supporting registry.** This is not a declared extension
+> family and is outside this rule.
 
 | Field | Value |
 | --- | --- |
@@ -8,4 +11,9 @@
 | **advertised as** | not a discovery family — a data registry (`registry.json`) the Layer-2 obligation reads |
 | **owning RFC** | RFC 0173 §C.2, RFC 0150 G3 |
 
-> **Status: Draft · v2.0.0-rc (2026-09-03).** `registry.json` records which providers have a natural business-identity key (RFC 0173 §C.2: business-identity keying is the core obligation; the activity recipe is the documented fallback). Rows are measured by the Phase 4 host legs. The witness is `GET /runs/{runId}/effects` (`effect-ledger-projection.schema.json` `keying`). **Not a declared family — notes, outside the `ext/README.md` maturity rule; `Draft` here means unfrozen prose, not an unwitnessed family.**
+[`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`.

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

@@ -1,4 +1,7 @@
-# `restTransport` — extension
+# `restTransport` extension
+
+> **Status: Draft · v2 extension.** Discovery-only reservation; no portable
+> operations or payload contract is defined in v2.3.3.
 
 | Field | Value |
 | --- | --- |
@@ -6,15 +9,23 @@
 | **technical:** | `experimental` |
 | **adoption:** | `none` |
 | **peer-dependency id** | `restTransport` |
-| **advertised as** | `extensions.<org>.restTransport` (RFC 0169 §A.4) — never a root key |
+| **advertised as** | `extensions.<org>.restTransport` |
 | **owning RFC** | RFC 0115 |
+| **declared facets** | `conditionalRunGet`, `contentEncodings` |
 
-> **Status: Draft · v2.0.0-rc (2026-09-03).** Extension document (RFC 0169 §B.3; RFC 0167 Axiom 1: a family that cannot be witnessed unaided lives here and is not a core obligation).
+## Contract boundary
 
-## What it is
+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.
 
-RFC 0169 §C.5 (claims-check; ext/ unless a behavioral witness lands) The v1 prose that defines the surface is `spec/v1/capabilities.md` (root key `restTransport`, RFC 0113); it stands as the definition until this document carries its own normative text (P3-E and the Phase 4 host legs). A host that serves this surface advertises it under `extensions.<org>.restTransport` with the RFC 0169 record shape; a pack that requires it names `restTransport` in `peerDependencies` (RFC 0177 §B.1).
+The v1 description, [`spec/v1/capabilities.md`](https://github.com/openwop/openwop/blob/v2.3.3/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.
 
-## Witness
+## Conformance
 
-`claims-check`: the suite can read the claim from discovery but has no behavioral probe; adoption is measured by the INTEROP-MATRIX bundle evidence.
+The current `claims-check` witness validates only that the discovery claim is
+well formed. It does not demonstrate compatible runtime behavior.

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

@@ -1,4 +1,7 @@
-# `sandbox-runtime-notes` — extension (non-normative)
+# Sandbox runtime notes
+
+> **Status: Draft · non-normative note.** This is not a declared extension
+> family and is outside this rule.
 
 | Field | Value |
 | --- | --- |
@@ -8,4 +11,8 @@
 | **advertised as** | not advertisable (notes, not a surface) |
 | **owning RFC** | RFC 0173 §D (RFC 0035 superseded by the `packs` obligation at the cut) |
 
-> **Status: Draft · v2.0.0-rc (2026-09-03).** RFC 0035's `node:vm` demonstrator and its runtime notes are kept here as implementation history. In v2 isolation binds with pack execution (`security-defaults.md`): `sandbox.isolationModel` names `wasm | process | container | vm`; `node:vm` is not a value (RFC 0035 §20, `:130`: escapable by design). A host MAY register and validate packs without executing them. RFC 0035 flips `Superseded` at the RC. **Not a declared family — notes, outside the `ext/README.md` maturity rule; `Draft` here means unfrozen prose, not an unwitnessed family.**
+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.

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

@@ -1,4 +1,7 @@
-# `webResearch` — extension
+# `webResearch` extension
+
+> **Status: Draft · v2 extension.** Discovery-only reservation; no portable
+> operations or payload contract is defined in v2.3.3.
 
 | Field | Value |
 | --- | --- |
@@ -6,15 +9,23 @@
 | **technical:** | `experimental` |
 | **adoption:** | `single-witness` |
 | **peer-dependency id** | `webResearch` |
-| **advertised as** | `extensions.<org>.webResearch` (RFC 0169 §A.4) — never a root key |
+| **advertised as** | `extensions.<org>.webResearch` |
 | **owning RFC** | RFC 0144 |
+| **declared facets** | none defined |
 
-> **Status: Draft · v2.0.0-rc (2026-09-03).** Extension document (RFC 0169 §B.3; RFC 0167 Axiom 1: a family that cannot be witnessed unaided lives here and is not a core obligation).
+## Contract boundary
 
-## What it is
+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.
 
-RFC 0169 §B.3 (RFC 0144 extension class; prose-only §host.* section in v1; served under extensions.openwop-app.* by the one host that has it) The v1 prose that defines the surface is `spec/v1/host-capabilities.md` §host.webResearch (RFC 0144 extension class); it stands as the definition until this document carries its own normative text (P3-E and the Phase 4 host legs). A host that serves this surface advertises it under `extensions.<org>.webResearch` with the RFC 0169 record shape; a pack that requires it names `webResearch` in `peerDependencies` (RFC 0177 §B.1).
+The v1 description, [`spec/v1/host-capabilities.md`](https://github.com/openwop/openwop/blob/v2.3.3/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.
 
-## Witness
+## Conformance
 
-`claims-check`: the suite can read the claim from discovery but has no behavioral probe; adoption is measured by the INTEROP-MATRIX bundle evidence.
+The current `claims-check` witness validates only that the discovery claim is
+well formed. It does not demonstrate compatible runtime behavior.

package/spec/v2/id-field-bindings.json

@@ -20,6 +20,7 @@
     "failedNodeId": "nodeId",
     "fromAgentId": "agentId",
     "interruptId": "interruptId",
+    "interruptedNodeId": "nodeId",
     "keyId": "keyId",
     "lastNodeId": "nodeId",
     "libraryId": "libraryId",
@@ -47,9 +48,9 @@
     "traceId": "traceId",
     "triggerSubscriptionId": "subscriptionId",
     "typeId": "typeId",
+    "webhookId": "subscriptionId",
     "workflowId": "workflowId",
-    "workspaceId": "workspaceId",
-    "interruptedNodeId": "nodeId"
+    "workspaceId": "workspaceId"
   },
   "notAKind": {
     "annotationId": "no openwop id kind governs this surface; the grammar is the owning schema's own",
@@ -76,7 +77,7 @@
     "hostId": "no openwop id kind governs this surface; the grammar is the owning schema's own",
     "instanceId": "no openwop id kind governs this surface; the grammar is the owning schema's own",
     "invocationId": "no openwop id kind governs this surface; the grammar is the owning schema's own",
-    "itemIds": "no openwop id kind governs this surface; these are artifact-local item identifiers inside RefineFeedback (interrupt.md \u00a7RefineFeedback), opaque to the protocol",
+    "itemIds": "no openwop id kind governs this surface; these are artifact-local item identifiers inside RefineFeedback (interrupt.md §RefineFeedback), opaque to the protocol",
     "leaseId": "no openwop id kind governs this surface; the grammar is the owning schema's own",
     "memoryId": "no openwop id kind governs this surface; the grammar is the owning schema's own",
     "mergedIds": "memory-entry ids (agentMemoryConsolidated); no openwop id kind governs memory entries",
@@ -100,7 +101,6 @@
     "suiteId": "no openwop id kind governs this surface; the grammar is the owning schema's own",
     "taskId": "no openwop id kind governs this surface; the grammar is the owning schema's own",
     "toolId": "no openwop id kind governs this surface; the grammar is the owning schema's own",
-    "webhookId": "no openwop id kind governs this surface; the grammar is the owning schema's own",
     "workerId": "no openwop id kind governs this surface; the grammar is the owning schema's own"
   }
 }

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.3.4",
-  "corpusTag": "v2.3.4",
-  "updated": "2026-09-16"
+  "version": "2.4.1",
+  "corpusTag": "v2.4.1",
+  "updated": "2026-09-18"
 }