@openwop/spec-artifacts 2.42.6 → 2.42.8

package/spec/v2/errors.schema.json

@@ -0,0 +1,38 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://openwop.dev/spec/v2/errors.schema.json",
+  "title": "OpenWOP v2 error registry",
+  "description": "Shape of spec/v2/errors.json: one row per registered error code. schemas/v2/error-envelope.schema.json and the status table in spec/v2/core/errors.md are generated from it by scripts/generate-error-envelope.mjs, which also validates the registry against this schema. Data, not a wire artifact.",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["$schema", "version", "updated", "vendorCodePattern", "rows"],
+  "properties": {
+    "$schema": { "type": "string", "const": "https://openwop.dev/spec/v2/errors.schema.json" },
+    "$comment": { "type": "string" },
+    "version": { "type": "string", "pattern": "^[0-9]+\\.[0-9]+$", "description": "The registry format version." },
+    "updated": { "type": "string", "pattern": "^[0-9]{4}-[0-9]{2}-[0-9]{2}$" },
+    "vendorCodePattern": { "type": "string", "format": "regex", "description": "The pattern a vendor (non-registered) code MUST match." },
+    "rows": { "type": "array", "minItems": 1, "items": { "$ref": "#/$defs/row" } }
+  },
+  "$defs": {
+    "row": {
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["code", "httpStatus", "statusSource", "retriable", "details", "since", "source"],
+      "properties": {
+        "code": { "type": "string", "pattern": "^[a-z][a-z0-9]*(_[a-z0-9]+)*$", "description": "The value of the envelope's `error` field. Unique across rows." },
+        "meaning": { "type": "string", "minLength": 1, "description": "One plain-English line: what the code tells a client." },
+        "httpStatus": { "type": "integer", "minimum": 400, "maximum": 599, "description": "The status a host MUST answer with." },
+        "statusSource": { "type": "string", "minLength": 1, "description": "Provenance of the status: stated in v1 prose, a v1 convention, or decided for v2." },
+        "retriable": { "type": "boolean", "description": "Whether a client may retry the same request. Timing lives in Retry-After only." },
+        "details": {
+          "type": ["object", "null"],
+          "description": "The JSON Schema for this code's `details` object, or null when details is an open object."
+        },
+        "since": { "type": "string", "pattern": "^[0-9]+\\.[0-9]+$", "description": "The protocol version that first registered the code." },
+        "deprecated": { "type": "boolean", "description": "True when the code is deprecated. Absent means not deprecated." },
+        "source": { "type": "string", "minLength": 1, "description": "Provenance: the document or decision the row came from." }
+      }
+    }
+  }
+}

package/spec/v2/ext/README.md

@@ -1,14 +1,15 @@
 # OpenWOP v2 extensions
 
-> **Status: Stable · RFC 0177 §E, RFC 0174 §E.2.** This page defines the
-> maturity labels used by extension documents. Extensions are outside the core
-> profile unless a core document explicitly incorporates them.
+> **Status: Stable.**
+
+This page defines the maturity labels that extension documents carry.
+Extensions are outside the core profile unless a core document explicitly
+incorporates them.
 
 Each declared extension has a page at `spec/v2/ext/<name>/README.md` and a row
-in [`../declaration.json`](../declaration.json). Presence in the declaration
-reserves its identifier; it does not make the extension interoperable. Read the
-individual page to determine whether it defines portable behavior or only a
-discovery claim.
+in [`../declaration.json`](../declaration.json). A row reserves the identifier;
+it does not make the extension interoperable. Read the individual page to see
+whether it defines portable behavior or only a discovery claim.
 
 ## Maturity labels
 
@@ -17,42 +18,54 @@ conformance evidence.
 
 ### `Draft`
 
-Declared, but not supported by qualifying interoperability evidence.
+Declared, but without qualifying interoperability evidence.
 
 **Predicate:** The family is declared in `spec/v2/declaration.json` with
 `anchor: ext`.
 
 ### `Stable`
 
-Witnessed. At least one host at evidence tier 2 or better serves it, and a
+Witnessed: at least one host at evidence tier 2 or better serves it, and a
 **certified** bundle in `evidence/v2-host-bundles/` records the family's
 declared witness class as satisfied.
 
-**Predicate:** Every `Stable` document's family has at least one
-`executed-pass` row under its witness id in a bundle whose relevant profile
-claim is `certified: true`, and the seven-day comment window has run since the
-promotion PR.
+**Predicate:** The family has at least one `executed-pass` row under its
+witness id `openwop.family.<key>`, in a bundle that certifies at least one
+profile and whose `discovery.url` origin is listed at tier 2 or better in
+[`evidence/host-tiers.json`](https://github.com/openwop/openwop/blob/main/evidence/host-tiers.json). The seven-day
+comment window has also run since the promotion PR.
+
+The label means only what the family's witness class checks:
+
+- `witnessable-gated` or `seam-gated`: the host behaves as the page says.
+- `claims-check`: the host advertises the reservation in a well-formed record.
+  Two hosts are not shown to interoperate on it, because the page defines no
+  portable operations.
 
 ### `Retired`
 
-Withdrawn. The family is removed from the declaration, and the document names
+Withdrawn: the family is removed from the declaration, and the document names
 its replacement or the RFC that retired it.
 
-**Predicate:** The family is absent from the declaration; the document carries
-a `Superseded by:` or `Retired by:` line.
+**Predicate:** The family is absent from the declaration, and the document
+carries a `Superseded by:` or `Retired by:` line.
 
-The gate enforces both directions:
+The check works both ways:
 
 - A `Stable` document without qualifying evidence fails validation.
 - A `Draft` document with qualifying evidence is reported as eligible for
   review and promotion.
 
-A directory without a corresponding declared family is an implementation or
-migration note and MUST identify itself as outside this maturity rule. This
-currently applies to `grpc-transport`, `portability`,
-`provider-idempotency`, and `sandbox-runtime-notes`.
+### `Note`
+
+A directory with no declared family is an implementation or migration note. It
+carries `Status: Note.` and MUST say it is not a declared family. It is outside
+this maturity rule and never becomes `Stable`. Today the notes are
+`grpc-transport`, `provider-idempotency`, and `sandbox-runtime-notes`.
 
 ## What this does not decide
 
-Whether an extension should become core. That requires a separate RFC,
-normative text, machine-readable contracts, and a behavioral witness.
+Whether an extension should become core. That takes a separate RFC, normative
+text, machine-readable contracts, and a behavioral witness.
+
+*Sources: RFC 0174, RFC 0177, RFC 0220.*

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

@@ -1,66 +1,62 @@
 # `a2uiSurface` extension
 
-> **Status: Draft · v2 extension.** Normative contract for the `ui.a2ui-surface`
-> envelope kind at per-kind schema version 2 (RFC 0209), and the deprecated
-> `deltaTransport` facet (RFC 0114 in v1).
+> **Status: Draft.**
+
+The normative contract for the `ui.a2ui-surface` envelope kind at per-kind schema version 2, and for the deprecated `deltaTransport` facet.
 
 | Field | Value |
 | --- | --- |
-| **witness:** | `claims-check` |
+| **witness:** | `seam-gated` |
 | **technical:** | `experimental` |
 | **adoption:** | `none` |
 | **peer-dependency id** | `a2uiSurface` |
-| **advertised as** | `extensions.<org>.a2uiSurface` |
-| **owning RFC** | RFC 0209 |
+| **advertised as** | `schemaVersions.kinds["ui.a2ui-surface"]: 2`; the deprecated facet only under `extensions.<org>.a2ui-surface` |
 | **declared facets** | `deltaTransport` (deprecated) |
 
 ## Versions
 
-`ui.a2ui-surface` has two per-kind schema versions in v2, both in
-[`schemas/v2/envelopes/ui.a2ui-surface.schema.json`](../../../../schemas/v2/envelopes/ui.a2ui-surface.schema.json):
+`ui.a2ui-surface` has two per-kind schema versions, both in [`schemas/v2/envelopes/ui.a2ui-surface.schema.json`](../../../../schemas/v2/envelopes/ui.a2ui-surface.schema.json):
 
 | Version | Branch | Shape |
 | --- | --- | --- |
-| `1`, `0` or absent | `$defs/payloadV1` | the RFC 0102 seven-component tree pinned by `catalogVersion: "0.9.1"`, unchanged from v1 |
-| `2` | `$defs/payloadV2` | `{ reasoning?, version: "v0.9", catalogId, surfaceId, messages[1..64] }`: an ordered run of A2UI v0.9 server-to-client messages in the profile below |
-
-An engine MUST validate an envelope against exactly one branch: the one for the
-version that `core/events.md` §"The envelope-kind catalog" selects (the emitted
-version, or the advertised one under `warn` below the floor). It MUST NOT
-validate against the union: a version-2 envelope carrying a version-1 payload is
-invalid, and so is the reverse. The root `anyOf` exists for tooling; a host that
-asks a model to emit version 2 hands the provider `$defs/payloadV2` alone.
-
-A host admits version 2 by advertising `schemaVersions.kinds["ui.a2ui-surface"]: 2`.
-The catalog rules then apply unchanged, so a consumer that knows only version 1
-refuses version 2 with `unknown_schema_version` and fails closed.
-
-In a version-2 payload, `catalogId` is an enum of the host-pinned catalogs, today
-exactly `https://a2ui.org/specification/v0_9/catalogs/basic/catalog.json`. Every
-message's `surfaceId` MUST equal the payload's `surfaceId`, and a
-`createSurface.catalogId` MUST equal the payload's `catalogId`. The schema cannot
-express either cross-field rule, so the engine checks both at admission and
-refuses a violation with `envelope_invalid`.
+| `1`, `0` or absent | `$defs/payloadV1` | the seven-component tree pinned by `catalogVersion: "0.9.1"` |
+| `2` | `$defs/payloadV2` | `{ reasoning?, version: "v0.9", catalogId, surfaceId, messages[1..64] }` |
+
+A version-2 payload is an ordered run of A2UI v0.9 server-to-client messages in the profile below.
+
+### Choosing the branch
+
+An engine MUST validate an envelope against exactly one branch: the one for the version that [`core/events.md`](../../core/events.md) §"The envelope-kind catalog" selects (the emitted version, or the advertised one under `warn` below the floor).
+
+- It MUST NOT validate against the union. A version-2 envelope carrying a version-1 payload is invalid, and so is the reverse.
+- The root `anyOf` exists for tooling. A host that asks a model to emit version 2 hands the provider `$defs/payloadV2` alone.
+
+A host admits version 2 by advertising `schemaVersions.kinds["ui.a2ui-surface"]: 2`. The catalog rules apply unchanged: a consumer that knows only version 1 refuses version 2 with `unknown_schema_version` and fails closed.
+
+### Cross-field rules
+
+In a version-2 payload, `catalogId` is an enum of the host-pinned catalogs, today exactly `https://a2ui.org/specification/v0_9/catalogs/basic/catalog.json`.
+
+- Every message's `surfaceId` MUST equal the payload's `surfaceId`.
+- A `createSurface.catalogId` MUST equal the payload's `catalogId`.
+
+The schema cannot express either rule, so the engine checks both at admission and refuses a violation with `envelope_invalid`.
 
 ## The profile
 
-Every message that validates against `payloadV2.messages[]` MUST also validate
-against upstream A2UI v0.9 `server_to_client.json` with the basic catalog and
-`common_types.json` bound. The profile only removes; it never adds a property
-A2UI lacks. Conformance vendors the upstream files, pinned by SHA-256
-(`conformance/fixtures/upstream/a2ui-v0.9/`).
+Every message that validates against `payloadV2.messages[]` MUST also validate against upstream A2UI v0.9 `server_to_client.json` with the basic catalog and `common_types.json` bound. The profile only removes; it never adds a property A2UI lacks. Conformance vendors the upstream files, pinned by SHA-256 (`conformance/fixtures/upstream/a2ui-v0.9/`).
 
 | Message | Profile |
 | --- | --- |
-| `createSurface` | `surfaceId`, `catalogId`, optional `theme` limited to `primaryColor` and `agentDisplayName` |
+| `createSurface` | `surfaceId`, `catalogId`, optional `theme` (`primaryColor`, `agentDisplayName` only) |
 | `updateComponents` | `surfaceId` and `components[1..512]` from the set below |
 | `updateDataModel` | as upstream: `surfaceId`, optional `path` (JSON Pointer), optional `value` |
 | `deleteSurface` | as upstream |
 
-Components, each closed and discriminated by a single-string-enum `component`:
-`Text`, `TextField`, `CheckBox`, `ChoicePicker`, `DateTimeInput`, `Button`,
-`Column`, `Row`, `Card`, `Divider`. A dynamic value is a literal or a `{path}`
-data binding. `Column` and `Row` take static `children` id lists only.
+Components are each closed and discriminated by a single-string-enum `component`: `Text`, `TextField`, `CheckBox`, `ChoicePicker`, `DateTimeInput`, `Button`, `Column`, `Row`, `Card`, `Divider`.
+
+- A dynamic value is a literal or a `{path}` data binding.
+- `Column` and `Row` take static `children` id lists only.
 
 | Excluded | Why |
 | --- | --- |
@@ -68,80 +64,70 @@ data binding. `Column` and `Row` take static `children` id lists only.
 | `FunctionCall` values, except `checks[].condition` calling `required` | code execution on the renderer; `a2ui-surface-no-code-exec` |
 | `TextField.variant: "obscured"` | a surface MUST NOT solicit a secret; `a2ui-surface-no-secret-input` |
 | `Image`, `Video`, `AudioPlayer`, `createSurface.theme.iconUrl` | each fetches a URL; `a2ui-surface-no-network-egress` |
-| `createSurface.sendDataModel` | collected data returns only through the action below |
-| `Icon` | its vocabulary is renderer-defined; deferred |
+| `createSurface.sendDataModel` | collected data returns only through actions |
+| `Icon` | renderer-defined vocabulary; deferred |
 | `List`, `Tabs`, `Modal`, `Slider`, data-model templates | outside the day-one profile |
 
 ## Actions and collected data
 
-A `Button.action` MUST be the A2UI server-event arm `{ event: { name, context? } }`
-with `name` ∈ {`resume`, `exchange`}: an interrupt resume or a conversation
-exchange. When a user fires one, the consumer resolves `event.context` against
-the surface's data model and submits the result, as the interrupt `resumeValue`
-for `resume` or as the exchanged turn's data for `exchange`. With no `context` it
-submits the whole data model at `/`. It MUST NOT submit anywhere else.
+A `Button.action` MUST be the A2UI server-event arm `{ event: { name, context? } }` with `name` ∈ {`resume`, `exchange`}: an interrupt resume or a conversation exchange.
 
-A host MUST NOT emit a surface whose evident purpose is credential collection.
-Collected values become a `resumeValue` in the event log, where SR-1 redaction is
-a backstop, not a licence.
+When a user fires an action, the consumer resolves `event.context` against the surface's data model and submits the result:
+
+- for `resume`, as the interrupt `resumeValue`;
+- for `exchange`, as the exchanged turn's data;
+- with no `context`, it submits the whole data model at `/`.
+
+It MUST NOT submit anywhere else.
+
+A host MUST NOT emit a surface whose evident purpose is credential collection. Collected values become a `resumeValue` in the event log, where SR-1 redaction is a backstop, not a licence.
 
 ## The fold
 
-A surface is identified by `(runId, surfaceId)`. Its state is the fold, in event
-`sequence` order, of the `messages` of every version-2 `ui.a2ui-surface` envelope
-the run recorded with that `surfaceId`, under A2UI v0.9 semantics:
-`updateComponents` upserts components by `id`, `updateDataModel` replaces or
-removes the value at `path`, and `deleteSurface` ends the surface.
+A surface is identified by `(runId, surfaceId)`. Its state is the fold, in event `sequence` order, of the `messages` of every version-2 `ui.a2ui-surface` envelope the run recorded with that `surfaceId`, under A2UI v0.9 semantics:
 
-The host MUST refuse, rather than record, an envelope that would make the fold
-invalid, with `envelope_invalid`:
+- `updateComponents` upserts components by `id`;
+- `updateDataModel` replaces or removes the value at `path`;
+- `deleteSurface` ends the surface.
+
+The host MUST refuse, rather than record, an envelope that would make the fold invalid, with `envelope_invalid`:
 
 - the first envelope for a `surfaceId` does not begin with `createSurface`;
 - `createSurface` is sent for a live `surfaceId`;
 - any message follows `deleteSurface` without a new `createSurface`.
 
-A consumer MUST NOT render the surface, or enable any action on it, until the
-fold holds exactly one component with `id: "root"`. `partial: true` keeps its
-per-envelope meaning; a surface's actions stay disabled until the envelope that
-last touched it has finalized.
+A consumer MUST NOT render the surface, or enable any action on it, until the fold holds exactly one component with `id: "root"`. `partial: true` keeps its per-envelope meaning: a surface's actions stay disabled until the envelope that last touched it has finalized.
 
 ## Replay and fork
 
-Recorded surface envelopes are returned as recorded; no surface is regenerated.
-A reader MUST keep accepting version-1 envelopes on replay, fork and poll for the
-life of the major, including on a host whose floor is now 2: recorded envelopes
-are read, not re-admitted through the envelope-kind catalog. A fork at `fromSeq`
-folds only the envelopes in `[0, fromSeq)`.
+Recorded surface envelopes are returned as recorded, never regenerated.
+
+- A reader MUST keep accepting version-1 envelopes on replay, fork and poll for the life of the major, including on a host whose floor is now 2. Recorded envelopes are read, not re-admitted through the envelope-kind catalog.
+- A fork at `fromSeq` folds only the envelopes in `[0, fromSeq)`.
 
 ## Trust
 
-If any envelope in a surface's fold carries `meta.contentTrust: "untrusted"`, the
-whole surface is untrusted and the `untrusted_content_blocks_approval` rule
-applies to every action on it: an `approval` interrupt it is bound to MUST NOT
-advance. A later trusted `updateComponents` does not launder an earlier untrusted
-one, and one untrusted update taints a surface a trusted node created. The SR-1
-harness walks every message.
+If any envelope in a surface's fold carries `meta.contentTrust: "untrusted"`, the whole surface is untrusted. The `untrusted_content_blocks_approval` rule then applies to every action on it: an `approval` interrupt it is bound to MUST NOT advance.
+
+- A later trusted `updateComponents` does not launder an earlier untrusted one.
+- One untrusted update taints a surface a trusted node created.
+
+The SR-1 harness walks every message.
 
 ## `deltaTransport` (deprecated)
 
-`schemas/v2/a2ui-surface-delta-frame.schema.json` and the `deltaTransport` facet
-are deprecated for major 2 (`spec/v1/deprecations.json`,
-`openwop.deprecation.v2-a2ui-delta-frame` and `-delta-transport-facet`). A v2 host
-SHOULD NOT advertise the facet: incremental updates are version-2 envelopes
-carrying `updateComponents` / `updateDataModel`, recorded and replayable by the
-fold. The rows carry `removeIn: "3.0"` until RFC 0197 is `Accepted`; removal then
-follows its `v2-minor` path. v1's RFC 0114 stands.
+`schemas/v2/a2ui-surface-delta-frame.schema.json` and the `deltaTransport` facet are deprecated for major 2 (`spec/v1/deprecations.json`, `openwop.deprecation.v2-a2ui-delta-frame` and `-delta-transport-facet`).
+
+A v2 host SHOULD NOT advertise the facet. Incremental updates are version-2 envelopes carrying `updateComponents` / `updateDataModel`, recorded and replayable by the fold.
+
+The rows carry `removeIn: "3.0"`. An earlier removal takes the `v2-minor` path of [overview.md §0a](../../core/overview.md): a migration row for the replacement, and a row rescheduled to name the removal minor at least two minors and 30 days ahead.
 
 ## Conformance
 
-- `conformance/src/coherence/a2ui-v09-profile.test.ts` (corpus gate, no host): the
-  profile ⊂ upstream check, each excluded affordance refused, the pinned catalog,
-  the unchanged version-1 branch and the `ui.*`/`media.*` kind carve-out.
-- `conformance/src/scenarios/v2-a2ui-v09-surface.test.ts` (major 2, seams-gated on
-  `POST /conformance/seams/sample/a2ui/emit-surface` in `api/seams-v2.yaml`):
-  version selects branch, fold guarded, catalog equality, legacy readable and
-  sticky taint. A host without the seam records `inapplicable`.
-- No render before `root` is a renderer guarantee the server-oriented suite cannot
-  observe; it is witnessed by a reference-app client probe (`tier: reference-impl`).
-
-The `claims-check` witness above is the discovery claim of `extensions.<org>.a2uiSurface`.
+- **`conformance/src/coherence/a2ui-v09-profile.test.ts`** (corpus gate, no host): the profile ⊂ upstream check, each excluded affordance refused, the pinned catalog, the unchanged version-1 branch and the `ui.*`/`media.*` kind carve-out.
+- **`conformance/src/scenarios/v2-a2ui-v09-surface.test.ts`** (major 2, seams-gated on `POST /conformance/seams/sample/a2ui/emit-surface` in `api/seams-v2.yaml`): version selects branch, fold guarded, catalog equality, legacy readable and sticky taint. A host without the seam records `inapplicable`.
+- **No render before `root`** is a renderer guarantee the server-oriented suite cannot observe. A reference-app client probe witnesses it (`tier: reference-impl`).
+
+The family witness is `openwop.family.a2uiSurface`. It is the last leg of `v2-a2ui-v09-surface`: a version-2 surface is admitted and a version-1 body under schema version 2 is refused, in the same run. It shares the seam gate, so a host without the seam records `inapplicable`.
+
+*Sources: RFC 0102, RFC 0114, RFC 0197, RFC 0209, RFC 0220.*

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

@@ -1,7 +1,8 @@
 # `brand` extension
 
-> **Status: Draft · v2 extension.** Discovery-only reservation; no portable
-> operations or payload contract is defined in the current v2 corpus.
+> **Status: Draft.**
+
+`brand` names a host service for brand artifacts: themes and personas. 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** | `brand` |
 | **advertised as** | `extensions.<org>.brand` |
-| **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 `brand` as a dependency only when the host and pack share
-an out-of-band definition of that dependency.
+A host MAY advertise `brand` as `extensions["<org>.brand"]`, 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#hostbrand)
-(§host.brand), 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 `brand` 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.brand`:
+
+- the key `<org>.brand` matches `extensionsKeyPattern`, and `<org>` is registered and not reserved;
+- the record is a JSON object;
+- `brand` 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/canvas/README.md

@@ -1,7 +1,8 @@
 # `canvas` extension
 
-> **Status: Draft · v2 extension.** Discovery-only reservation; no portable
-> operations or payload contract is defined in the current v2 corpus.
+> **Status: Draft.**
+
+`canvas` names a host service that reads and writes canvas state. 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** | `canvas` |
 | **advertised as** | `extensions.<org>.canvas` |
-| **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 `canvas` as a dependency only when the host and pack share
-an out-of-band definition of that dependency.
+A host MAY advertise `canvas` as `extensions["<org>.canvas"]`, 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#hostcanvas)
-(§host.canvas), 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 `canvas` 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.canvas`:
+
+- the key `<org>.canvas` matches `extensionsKeyPattern`, and `<org>` is registered and not reserved;
+- the record is a JSON object;
+- `canvas` 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/chat/README.md

@@ -1,7 +1,8 @@
 # `chat` extension
 
-> **Status: Draft · v2 extension.** Discovery-only reservation; no portable
-> operations or payload contract is defined in the current v2 corpus.
+> **Status: Draft.**
+
+`chat` names a host service that posts messages and cards into a host-established chat session. 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** | `chat` |
 | **advertised as** | `extensions.<org>.chat` |
-| **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 `chat` as a dependency only when the host and pack share
-an out-of-band definition of that dependency.
+A host MAY advertise `chat` as `extensions["<org>.chat"]`, 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#hostchat)
-(§host.chat), 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 `chat` 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.chat`:
+
+- the key `<org>.chat` matches `extensionsKeyPattern`, and `<org>` is registered and not reserved;
+- the record is a JSON object;
+- `chat` 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/coordination/README.md

@@ -1,7 +1,8 @@
 # `coordination` extension
 
-> **Status: Draft · v2 extension.** Discovery-only reservation; no portable
-> operations or payload contract is defined in the current v2 corpus.
+> **Status: Draft.**
+
+`coordination` names multi-participant coordination primitives that operate on roles, such as voters and competitors. 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** | `coordination` |
 | **advertised as** | `extensions.<org>.coordination` |
-| **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 `coordination` as a dependency only when the host and pack share
-an out-of-band definition of that dependency.
+A host MAY advertise `coordination` as `extensions["<org>.coordination"]`, 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#hostcoordination)
-(§host.coordination), 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 `coordination` 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.coordination`:
+
+- the key `<org>.coordination` matches `extensionsKeyPattern`, and `<org>` is registered and not reserved;
+- the record is a JSON object;
+- `coordination` 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/dataIntegration/README.md

@@ -1,7 +1,8 @@
 # `dataIntegration` extension
 
-> **Status: Draft · v2 extension.** Discovery-only reservation; no portable
-> operations or payload contract is defined in the current v2 corpus.
+> **Status: Draft.**
+
+`dataIntegration` names typed data-source operations: fetches from configured external sources, transforms and run-scoped variables. It is a discovery-only reservation: v2 defines no portable operations or payload contract for it.
 
 | Field | Value |
 | --- | --- |
@@ -9,30 +10,26 @@
 | **technical:** | `experimental` |
 | **adoption:** | `single-witness` |
 | **peer-dependency id** | `dataIntegration` |
-| **advertised as** | `extensions.<org>.dataIntegration` |
-| **owning RFC** | RFC 0144 |
+| **advertised as** | `extensions.<org>.data-integration` |
 | **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 `dataIntegration` as a dependency only when the host and pack share
-an out-of-band definition of that dependency.
+A host MAY advertise `dataIntegration` as `extensions["<org>.data-integration"]`, 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#hostdataintegration)
-(§host.dataIntegration), 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 `dataIntegration` as a dependency only when the host and pack share an out-of-band definition of it.
 
-For MCP access, the v1 `ctx.dataIntegration.fetchMCP` operation is superseded
-by `ctx.mcp` ([`host-services.md`](../../core/host-services.md) §`mcp`, RFC 0204),
-which returns MCP results unaltered. Retiring `fetchMCP` from an organization's
-`dataIntegration` record is that organization's decision.
+For MCP access, `ctx.mcp` ([`host-services.md`](../../core/host-services.md) §`mcp`) supersedes the v1 `ctx.dataIntegration.fetchMCP` operation and returns MCP results unaltered. Whether an organization's `dataIntegration` record keeps `fetchMCP` is that organization's decision.
 
 ## 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.dataIntegration`:
+
+- the key `<org>.data-integration` matches `extensionsKeyPattern`, and `<org>` is registered and not reserved;
+- the record is a JSON object;
+- `dataIntegration` 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, RFC 0204.*