@openwop/spec-artifacts 2.0.9 → 2.0.10

package/spec/v2/core/runs.md

@@ -1,6 +1,6 @@
 # Runs
 
-> **Status: Stable · v2.0.9 (2026-09-10) · RFC 0170 §A, §D.1; RFC 0171 §D; RFC 0176 §B.1.**
+> **Status: Stable · v2.0.10 (2026-09-10) · RFC 0170 §A, §D.1; RFC 0171 §D; RFC 0176 §B.1.**
 
 ## Why this exists
 

package/spec/v2/core/security-defaults.md

@@ -1,6 +1,6 @@
 # Security Defaults
 
-> **Status: Stable · v2.0.9 (2026-09-10) · RFC 0173 (§A–§E), 0164 §22, 0170 §B.**
+> **Status: Stable · v2.0.10 (2026-09-10) · RFC 0173 (§A–§E), 0164 §22, 0170 §B.**
 
 ## Why this exists
 

package/spec/v2/core/versioning.md

@@ -1,6 +1,6 @@
 # Versioning and Release
 
-> **Status: Stable · v2.0.9 (2026-09-10) · RFC 0172, 0179, 0176.**
+> **Status: Stable · v2.0.10 (2026-09-10) · RFC 0172, 0179, 0176.**
 
 ## Why this exists
 
@@ -41,17 +41,17 @@ A request on a `/v1/…` path key MUST NOT carry `OpenWOP-Version` with a value
 
 Every protocol response MUST carry `OpenWOP-Version: <major>.<minor>` naming the contract that produced it. Reporting a version other than the one used is a silent downgrade and non-conformant; the `dual-stack-negotiation` scenario falsifies it. Emitting the header on `/v1/` responses is additive in v1.x and REQUIRED in v2.
 
-A *protocol response* is one produced by an operation named in `spec/v2/path-manifest.json` (or its `/v1/` twin through the overlap). The quantifier is deliberately not "any path": a host may serve other things on its origin — an application shell, a hosting fallback, a proprietary route — and those responses were produced by no protocol contract, so there is no version for them to name. Errata 2026-09-10: this section previously read "a response on any path MUST carry …", which a shell page on a shared name violated literally while the rationale (a silent downgrade) could not apply to it. The same over-broad quantifier was corrected in §1.2 on 2026-09-09.
+A *protocol response* is one produced by an operation named in `spec/v2/path-manifest.json` (or its `/v1/` twin through the overlap); a shell, a hosting fallback or a proprietary route on the same origin has no version to name. Errata 2026-09-10: this read "any path" — §1.2's quantifier defect again.
 
-**A non-protocol response MUST NOT carry `OpenWOP-Version` and MUST NOT be `application/json`.** This is what keeps the two distinguishable, not a loophole: a reader, a cache, or the conformance suite that sees a response without the header, or with a `text/html` body, MUST NOT count it as a protocol response — it did not reach the operation (`v2-advertised-path-space-served`, `reachedUnderMajor2`; the scenario had been the rule for a week before this prose).
+**A non-protocol response MUST NOT carry `OpenWOP-Version` and MUST NOT be `application/json`**; a reader, a cache or the suite MUST NOT count a response without the header, or with a `text/html` body, as reaching the operation (`reachedUnderMajor2`).
 
-**Content negotiation on a shared name is permitted, with conditions.** A host MAY serve both a protocol operation and a non-protocol resource (a page) under one unversioned name, selecting on `Accept`, if all three hold:
+**Content negotiation on a shared name is permitted, with conditions.** A host MAY serve a protocol operation and a page under one unversioned name, selecting on `Accept`, iff:
 
-1. A request that identifies as a protocol client MUST receive the protocol response for the applicable major (§1.3) with `OpenWOP-Version` on it. A request identifies as a protocol client when it carries `OpenWOP-Version`, **or** when its `Accept` admits `application/json` without preferring `text/html` — an absent `Accept` and `*/*` both qualify. The default is the wire, not the page; only an explicit `text/html` preference selects the page. Browsers send that; nothing that speaks the protocol does.
-2. The non-protocol response obeys the paragraph above (no `OpenWOP-Version`, not `application/json`).
-3. The response carries `Vary: Accept, OpenWOP-Version` so no cache serves one representation to a client that asked for the other.
+1. A request identifying as a protocol client — `OpenWOP-Version` present, **or** an `Accept` admitting `application/json` without preferring `text/html` (absent and `*/*` included) — MUST get the protocol response for the applicable major (§1.3) with `OpenWOP-Version`; only an explicit `text/html` preference selects the page.
+2. The page obeys the paragraph above.
+3. The response carries `Vary: Accept, OpenWOP-Version`.
 
-A host that cannot meet all three MUST move the non-protocol resource off the shared name.
+Otherwise the page MUST move off the shared name.
 
 ### 1.5 Client precedence and `minClientVersion`
 
@@ -108,7 +108,7 @@ A consumer that vendors any file from `schemas/`, `api/`, or `spec/` MUST pin to
 
 Through the overlap a host MUST advertise both majors (§1.1), MUST emit `OpenWOP-Version` on every response (§1.4), and MUST serve `/.well-known/openwop` as one resource whose representation the request header selects (`capabilities.md`). The dual-stack scenario creates one run through `/v1/runs` with no header and reads it through `/runs` with `OpenWOP-Version: 2`; the response headers name the contract used.
 
-**A run minted under major 1 and read under major 2 MUST be named by its tenant-bound projection** `<tenantId>/<the v1 id>` (`identity.md` §5). A host MUST NOT return the bare v1 id in a major-2 response body. This paragraph is normative because its absence was a real defect: until 2026-09-04 §5 described the overlap's shape and said nothing about the identifier, so a conformance check asserted byte-equality with the v1 id, a host implemented `identity.md` §5 instead, and the two could not both hold. Neither reading was wrong about §5 — §5 had no reading.
+**A run minted under major 1 and read under major 2 MUST be named by its tenant-bound projection** `<tenantId>/<the v1 id>` (`identity.md` §5). A host MUST NOT return the bare v1 id in a major-2 response body. Normative since 2026-09-04, when a conformance check asserting byte-equality with the v1 id and a host implementing `identity.md` §5 could not both hold — §5 had no reading.
 
 The projection is mandatory rather than optional for a reason that is not stylistic. A tenant-bound id carries the tenant segment that §5's `403 id_tenant_mismatch` check reads. **A bare, unprefixed id has no tenant segment, so the mandatory cross-tenant refusal cannot run on it at all.** Admitting a legacy unprefixed form under major 2 would therefore create a class of identifiers — exactly the long-lived ones, carried over from v1 — on which major 2's tenant-isolation check is structurally inapplicable. The grammar in `ids.schema.json` has no legacy branch, and it MUST NOT acquire one.
 
@@ -116,7 +116,7 @@ The overlap ends at v1 end-of-support (`overview.md`), when `protocolVersions[]`
 
 **Retirement is atomic, and that is a consequence of §1.1 rather than a separate rule.** Through the overlap `preferredVersion` MUST name a `1.x` member; a host that drops v1 from `protocolVersions[]` advertises a `2.x` `preferredVersion`. There is no legal intermediate state in which both majors are advertised and `2.x` is preferred, so flipping `preferredVersion` ahead of the drop is not a smaller first step — it is the same step. Dropping v1 therefore retires the whole `/v1` path space at once, not incrementally.
 
-**Retirement flips every header-less request's contract.** Through the overlap a header-less request on an unversioned name is served major 1 (§1.3), and on a host whose v1 surface lives under `/v1/` that name is not a v1 key — so it falls through to whatever else the host serves there, typically an application page. The v1 default is what separates the page from the wire. At end-of-support the same header-less request is served major 2, the name *is* a v2 key, and the page starts answering the protocol operation to browsers. An inventory that counts `/v1/` paths cannot see this hazard because there is no `/v1/` in it. The test is `set(top-level segments of the manifest's paths) ∩ set(anything else the host serves unversioned)`: on the reference host the intersection is empty; a host with a non-empty intersection MUST, before end-of-support, either move the other resource off the shared name or serve it under the §1.4 content-negotiation conditions, which make the disambiguator `Accept` rather than the retiring default. Recorded 2026-09-10 from a tier-1 host whose intersection was `{agents, prompts, runs}`.
+**Retirement flips every header-less request's contract.** Through the overlap a header-less request on an unversioned name is served major 1 (§1.3); where the v1 surface lives under `/v1/` that name is not a v1 key and falls through to whatever else is served there — typically a page. At end-of-support the same request is served major 2 and the page starts answering the operation. A `/v1/`-counting inventory cannot see this. Test: `manifest top-level segments ∩ anything else served unversioned` (`{agents, prompts, runs}` on the host that found it). A non-empty intersection MUST be resolved before end-of-support: move the page, or serve it under §1.4's conditions.
 
 **Open gap — host-proprietary paths have no defined successor.** A host may serve `/v1` roots the manifest does not name. §1.2 does not bind them, and at end-of-support the `/v1` prefix that addressed them is gone, so the protocol says nothing about where they go. This is **undecided, not permissive**: the corpus reserves a vendor namespace for capability records (`capabilities.md` §"extensions"), error codes (`errors.md`), event types (`events.md`), and pack-document properties (`packs.md`), each keyed to an org registered in `spec/v2/declaration.json` — and has no equivalent for paths. RFC 0172 rejected a `/v2/` path space and did not reach this question. The one worked example of a legitimate path space outside the manifest is the seams profile (`conformance.md` §"Test seams"), which stays honest by advertising `openwop-conformance-seams-v2` in `profiles[]` rather than by any path-level rule. A host in this position SHOULD record the affected roots before end-of-support so the set is known when the question is decided.
 

package/spec/v2/core/webhooks.md

@@ -1,6 +1,6 @@
 # Webhooks
 
-> **Status: Stable · v2.0.9 (2026-09-10) · RFC 0165 §C.1, 0173 §B, 0176 §D.2, 0171 §A.4.**
+> **Status: Stable · v2.0.10 (2026-09-10) · RFC 0165 §C.1, 0173 §B, 0176 §D.2, 0171 §A.4.**
 
 ## Why this exists
 

package/spec/v2/core/workflow-chain-packs.md

@@ -1,6 +1,6 @@
 # Workflow Chain Packs
 
-> **Status: Stable · v2.0.9 (2026-09-10) · RFC 0177, RFC 0133.**
+> **Status: Stable · v2.0.10 (2026-09-10) · RFC 0177, RFC 0133.**
 
 ## Why this exists
 

package/spec/v2/release.json

@@ -1,6 +1,6 @@
 {
   "$comment": "RFC 0172 \u00a7D.1 \u2014 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.0.9",
-  "corpusTag": "v2.0.9",
+  "version": "2.0.10",
+  "corpusTag": "v2.0.10",
   "updated": "2026-09-05"
 }