@openwop/openwop-conformance 1.72.2 → 1.98.0

package/CHANGELOG.md

@@ -1,5 +1,41 @@
 # `@openwop/openwop-conformance` Changelog
 
+## [1.81.0] — 2026-08-12 — RFC 0149 §D lifecycle coherence
+
+Adds one scenario (suite 420 → 421): `rfc-lifecycle-coherence.test.ts`, three always-on server-free legs. §D asks the corpus generator to fail when an `Accepted` RFC "retains an unresolved acceptance blocker not explicitly carried". The obvious rule — every box ticked before `Accepted` — was measured and rejected: of 141 `Accepted` RFCs, 42% ticked all, 25% ticked none, 24% ticked some, so a blanket gate fails **69 RFCs on its first run**, and a gate that fires 69 times gets disabled rather than fixed. The follow-up hypothesis (that the partially-ticked RFCs were a blocker backlog) also failed on reading them: every trailing item in `0027`/`0040`/`0041` is deliberately unticked **and annotated with why**, which *is* §D's "explicitly carried", just in a parenthetical rather than a register row. **Shipped rule: annotated vs bare, not ticked vs unticked** — an unticked item with no explanation is indistinguishable from one nobody checked. Scoped to RFCs ≥ 0147 so it binds the cohort that proposed it, with a leg asserting exactly that; earlier RFCs are the dated record of a period when the convention did not exist, and the boundary is asserted so a new RFC cannot inherit the exemption. All 67 bare items across 0147–0156 were annotated to land it. The non-vacuity guard is load-bearing here because **the gate's passing state and its broken state look identical**. Sabotage-verified.
+
+## [1.80.0] — 2026-08-12 — RFC 0149 §E canonical-family shadowing
+
+Adds one scenario (suite 419 → 420): `discovery-canonical-family-no-shadow.test.ts`, three always-on server-free legs, plus invariant `discovery-canonical-family-no-shadow`. RFC 0073 puts canonical families at the document root and `host-extensions.md` puts vendor surface under `x-host-*` / `vendor.*` / `private.*`; together that is what makes discovery negotiable. **Nothing forbade a canonical family name appearing inside the namespaced region** — `vendor.acme.auth`, or an `x-host-acme-*` object carrying its own `interrupts` — so a consumer that merges vendor surface over the root before negotiating reads a vendor's `auth` block as *the* auth contract. `host-extensions.md` already tells clients to treat extension surface as opaque, but **that binds the consumer, not the host publishing the collision**. Second leg: no discovery example may carry credential material, since discovery is served credential-free to anonymous callers. The family list is **read from `capabilities.schema.json`** rather than hand-listed. The corpus was already clean, so this is a guardrail rather than a repair and was **sabotage-verified rather than red-before-green**.
+
+## [1.79.0] — 2026-08-12 — RFC 0149 §C `protocolVersion` grammar
+
+Adds one scenario (suite 418 → 419): `protocol-version-grammar.test.ts`, twenty always-on server-free legs. The field was specified **three incompatible ways at once**: `capabilities.schema.json` said `minLength: 1`, this suite's own `isCore` predicate tested `startsWith('1.')`, and prose called it semver while every example showed two components. So `"v1.0"`, `"1.0.0"`, and `"banana"` all validated — and `"1.0.0"` additionally **derived `openwop-core`**, meaning the predicate deciding openwop-compatibility was looser than the schema every host validates against. Comparison needs an integer major and minor; neither is extractable from an unconstrained string. Now `^(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)$` in the schema, in `profiles.ts`, and in `version-negotiation.md`, with a leg asserting the schema pattern and the predicate are the same string. Closes gap V2, open since v1.0.
+
+## [1.78.0] — 2026-08-12 — RFC 0150 §D multi-region effect vocabulary
+
+Adds one scenario (suite 417 → 418): `multi-region-effect-vocabulary.test.ts`, eight always-on server-free legs, plus invariant `multi-region-stale-owner-no-effect`. **`crossRegion: "strict"` was a latency claim in an effect-safety slot** — documented as bounded read-visibility while sitting atop a ladder implementers read as effect safety, though a host replicating at 0 ms can still issue duplicate effects from two regions. Removed rather than renamed to `fenced-effects`, because a rename would promote every existing advertisement into a claim no host substantiated. **`partitionRecoveryStrategy` advertised rules violating two MUSTs already in force**: `last-writer-wins` and `first-writer-wins` are time-ordered, but the annex MUSTs lex-min(runId) and a reproducible survivor, and under a partition there is no shared clock. Both removed; `lexicographic-min-run-id` added. Wire change to the advertised enum, landed as a clean break because no hosts are deployed.
+
+## [1.77.0] — 2026-08-12 — RFC 0150 §B logical effect identity v2
+
+Adds one scenario (suite 416 → 417): `effect-identity-composition.test.ts`, six always-on server-free legs, plus invariant `logical-effect-id-retry-stable`. `spec/v1/idempotency.md` specified the Layer-2 key as `sha256(runId ':' nodeId ':' attempt ':' providerKey)` while the same document promised a retried call's identity "is identical" — **both cannot hold**. A retry counter in the preimage gives every retry a fresh key, so the invocation log never hits, and because the engine injects that value as the provider's `Idempotency-Key`, it sends Stripe or OpenAI a different key each attempt, defeating the provider-side dedup the same paragraph invokes as its safety net. **The same defect was already recorded one layer down** as `idempotency-key-deterministic`, fixed in the `core.openwop.http` node pack at 1.1.2. v1.2 specifies the domain-separated, tenant-bound composition over a `logicalInvocationOrdinal` that MUST NOT change across retries.
+
+## [1.76.0] — 2026-08-12 — RFC 0149 §B discovery-example root layout
+
+Adds one scenario (suite 415 → 416): `capability-example-root-layout.test.ts`, three legs, server-free, skipped under the published layout. Eight `spec/v1` examples — several under headings like "Capability advertisement (normative)" — showed the deprecated top-level `capabilities` wrapper, so the corpus taught in normative voice a document shape RFC 0073 Phase 4 grades as non-conformant. **No gate caught it because a fenced example is prose to every validator in the corpus.** All eight unwrapped. Authoring-time only; runtime tolerance untouched. The historical carve-out is asserted rather than assumed — every `RFCS/` example still showing the wrapper is numbered below 0073.
+
+## [1.75.0] — 2026-08-12 — RFC 0148 §C certification floor enforcement
+
+Adds one scenario (suite 414 → 415): `certification-floor-enforcement.test.ts`, six always-on server-free legs. `PROFILE_FLOOR_SCENARIOS` defined a floor for `openwop-core-standard` alone, and `verifyBundleProfile()` derived `floorProven` from `missingFloor.length === 0 && prefixOk` — **both vacuously true over an absent floor**, so every other profile passed RFC 0089 §B(2) having been checked against nothing. Floors were transcribed from `profiles.md`, which already named them. **An empty floor and an unwritten floor are now different values** (`discoveryOnly` vs `floorUnspecified`). A live test asserting the committed reference bundle was ACCEPTED was inverted — it had been passing only because the floor was undefined.
+
+## [1.74.0] — 2026-08-11 — RFC 0149 §A canonical OpenAPI path resolution
+
+Adds one scenario (suite 413 → 414): `openapi-resolved-paths.test.ts`, three legs including a guard. The canonical `servers[].url` ended in `/v1` while every versioned path key also began `/v1`, so generic resolution produced **`/v1/v1/*` for 44 operations**. The red run surfaced a consequence the RFC had not anticipated: `/.well-known/openwop` is a path key in the same document, so it resolved to `/v1/.well-known/openwop` — **a client generated from the canonical contract could not perform discovery at all**, which is worse than a mis-resolved operation because discovery is the bootstrap. Editorial: the reference SDKs already issued `/v1/*` against a bare base URL, so the SDKs and the OpenAPI document disagreed and the SDKs were correct.
+
+## Gap: 1.59.0 – 1.73.1
+
+**These releases have no entry here.** This file went unmaintained from `1.58.0` (2026-07-23) while the package advanced to `1.73.1`, and the entries above resume at `1.74.0`. The missing range is not reconstructed rather than guessed at: the authoritative record for those suite versions is the root [`CHANGELOG.md`](../CHANGELOG.md), which tracked every landing. Fabricating plausible entries would make this file assert knowledge it does not have, which is the failure mode the RFC 0147 program exists to close — so the gap is named instead.
+
 ## [1.58.0] — 2026-07-23 — RFC 0135 workflow-chain `internal` visibility flag
 
 Adds one scenario (suite 400 → 401) for **RFC 0135 — workflow-chain gallery visibility (`internal` chains)**: `workflow-chain-internal-flag.test.ts`, all legs always-on and server-free: the manifest schema's §WorkflowChain carries a boolean `internal` property; a chain declaring `internal: true` validates (and absent stays valid — absent ⇒ false); a non-boolean `internal` is rejected by the schema; and the spec (`workflow-chain-packs.md` §"Chain visibility (RFC 0135)") pins the two normative rules — a host's default template-gallery/picker listing MUST omit `internal: true` chains, and `internal` is presentational only, NOT an authorization boundary. The gallery-omission behavior itself has no normative wire listing endpoint, so it is witnessed at the reference host (host regression test) per RFC 0135 §Conformance, not over the wire. Spec minor bumps (one new optional manifest field), so the suite minor bumps.