From 21c4ae0e8dee32256b650335d1b5a824ba8019ec Mon Sep 17 00:00:00 2001 From: Jen Garcia Date: Sat, 19 Sep 2026 17:57:51 -0400 Subject: [PATCH] chore: version packages --- .changeset/grant-evaluation-fixtures.md | 13 ------------- packages/conformance-fixtures/CHANGELOG.md | 14 ++++++++++++++ packages/conformance-fixtures/package.json | 2 +- 3 files changed, 15 insertions(+), 14 deletions(-) delete mode 100644 .changeset/grant-evaluation-fixtures.md diff --git a/.changeset/grant-evaluation-fixtures.md b/.changeset/grant-evaluation-fixtures.md deleted file mode 100644 index 57585b92..00000000 --- a/.changeset/grant-evaluation-fixtures.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -'@haverstack/conformance-fixtures': minor ---- - -Pin the grantee arms and the evaluation-time refusals that the fixtures only described. - -Two fixtures covered a grant with no grantee at all and a group arm with no role, and both said in prose that the other arms "are refused the same way" — a rule stated in a fixture and checked by nothing. Nine fixtures now stand behind it: each incomplete arm (`entity` with no `entityId`, `group` with no `groupId`), an empty `entityId` as distinct from an absent one, the listing-only `role: 'any'` that a `listGrants()` query may ask for and a stored grantee may never carry, an unrecognized `kind`, and a `null` grantee reported as the missing field it is rather than read as absent-then-defaulted. - -Two more pin the half of the rule no request shape can show: that a grant reaching storage unvetted confers nothing when it is read back. A grant naming `_app@1` still answers 403 on a create, and a mutate verb with no read companion in the same grant conveys neither the write nor a read — so it answers 404, not 403. Both are states `grant()` refuses and a server mapping a request body, an import, or a foreign server's response can still produce. - -Also pins that an `anyone` element labelled anything but `read` is refused, which is load-bearing beyond the element: stored, it would read as world read _and_ satisfy the `read` a `write` element needs beside it, silencing write-implies-read for every grantee on the record. - -No behavior change — every rule here is already in `docs/spec/access-control.md`. A consumer holding these fixtures to a coverage gate will see the new names and need to dispatch or skip them. diff --git a/packages/conformance-fixtures/CHANGELOG.md b/packages/conformance-fixtures/CHANGELOG.md index 0b30326c..0bdccad8 100644 --- a/packages/conformance-fixtures/CHANGELOG.md +++ b/packages/conformance-fixtures/CHANGELOG.md @@ -1,5 +1,19 @@ # @haverstack/conformance-fixtures +## 0.31.0 + +### Minor Changes + +- [#320](https://github.com/haverstack/core/pull/320) [`f99ab6b`](https://github.com/haverstack/core/commit/f99ab6b990721ed3f12893d53570762c8e0383c1) Thanks [@cuibonobo](https://github.com/cuibonobo)! - Pin the grantee arms and the evaluation-time refusals that the fixtures only described. + + Two fixtures covered a grant with no grantee at all and a group arm with no role, and both said in prose that the other arms "are refused the same way" — a rule stated in a fixture and checked by nothing. Nine fixtures now stand behind it: each incomplete arm (`entity` with no `entityId`, `group` with no `groupId`), an empty `entityId` as distinct from an absent one, the listing-only `role: 'any'` that a `listGrants()` query may ask for and a stored grantee may never carry, an unrecognized `kind`, and a `null` grantee reported as the missing field it is rather than read as absent-then-defaulted. + + Two more pin the half of the rule no request shape can show: that a grant reaching storage unvetted confers nothing when it is read back. A grant naming `_app@1` still answers 403 on a create, and a mutate verb with no read companion in the same grant conveys neither the write nor a read — so it answers 404, not 403. Both are states `grant()` refuses and a server mapping a request body, an import, or a foreign server's response can still produce. + + Also pins that an `anyone` element labelled anything but `read` is refused, which is load-bearing beyond the element: stored, it would read as world read _and_ satisfy the `read` a `write` element needs beside it, silencing write-implies-read for every grantee on the record. + + No behavior change — every rule here is already in `docs/spec/access-control.md`. A consumer holding these fixtures to a coverage gate will see the new names and need to dispatch or skip them. + ## 0.30.0 ### Minor Changes diff --git a/packages/conformance-fixtures/package.json b/packages/conformance-fixtures/package.json index 46eec1cc..50c58ae1 100644 --- a/packages/conformance-fixtures/package.json +++ b/packages/conformance-fixtures/package.json @@ -1,6 +1,6 @@ { "name": "@haverstack/conformance-fixtures", - "version": "0.30.0", + "version": "0.31.0", "description": "Request/response fixtures for the Stack API wire protocol, shared between adapter-api and server implementations", "type": "module", "exports": {