From 37b3a94c39945c89ec32e3be9ea75bc289f2b891 Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 7 Sep 2026 05:39:36 +0000 Subject: [PATCH] test(console): re-point record:activity.types calibration control at '' (objectui#8137) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `@objectstack/spec` 17.3.0 made `RecordActivityProps.types` an OPEN vocabulary (`z.array(z.union([FeedItemType, z.string().min(1)]))`) — objectstack#11658 executing the maintainer's 2026-08-24 ruling on objectstack#11507. The member calibration control probed that vocabulary with an unlisted word, `'Account'`, which the widened contract now accepts, so the row asserted something false. Re-pointed at `''`, the one content refusal the widening kept: `''` IS a string, so the only check it fails is `.min(1)` and it raises no `invalid_type` anywhere — right kind, wrong content. That preserves the pair's whole job, which is to separate a CONTENT refusal from the KIND refusal asserted on the `42` line directly below (untouched). The comment above the row is rewritten in the same edit: it stated the retired premise ("a spec enum of strings"), and leaving it under a corrected value would be exactly the stale-restatement defect. Editing a calibration control is on the manual floor. Authorised by the maintainer on 2026-09-07 against the exact diff, scoped to this one row and its comment. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_0114Ytxr5sM1vdW19Y9WAx6E --- ...137-record-activity-calibration-repoint.md | 10 ++++++++++ .../registry-inputs-spec-parity.test.ts | 20 ++++++++++++++----- 2 files changed, 25 insertions(+), 5 deletions(-) create mode 100644 .changeset/8137-record-activity-calibration-repoint.md diff --git a/.changeset/8137-record-activity-calibration-repoint.md b/.changeset/8137-record-activity-calibration-repoint.md new file mode 100644 index 000000000..48401d08a --- /dev/null +++ b/.changeset/8137-record-activity-calibration-repoint.md @@ -0,0 +1,10 @@ +--- +--- + +Re-point the `record:activity.types` member calibration control in +`registry-inputs-spec-parity` from `'Account'` to `''` (objectui#8137). +`@objectstack/spec` 17.3.0 made that vocabulary open — +`z.array(z.union([FeedItemType, z.string().min(1)]))`, objectstack#11658 +executing the maintainer's 2026-08-24 ruling on objectstack#11507 — so the old +probe now accepts, while `''` is still refused for its CONTENT via `.min(1)`. +Test only; no package is released by this change. diff --git a/apps/console/src/__tests__/registry-inputs-spec-parity.test.ts b/apps/console/src/__tests__/registry-inputs-spec-parity.test.ts index e6b3db51c..9c74d5d71 100644 --- a/apps/console/src/__tests__/registry-inputs-spec-parity.test.ts +++ b/apps/console/src/__tests__/registry-inputs-spec-parity.test.ts @@ -3144,11 +3144,21 @@ describe('registry `inputs` vs `@objectstack/spec` ComponentPropsMap (repo-wide) // …and the second half of the calibration: a CONTENT refusal at the member // position is NOT a kind refusal, so the coarse-kind ceiling survives one - // level down exactly as it does at the top. `record:activity.types` is a - // spec enum of strings — a string member is refused as a VALUE, and reading - // that as "the string member declaration is invented" would condemn a - // declaration derived from the contract itself. - expect(specMemberVerdict('record:activity', 'types', 'array', 'Account')).toBe( + // level down exactly as it does at the top. + // + // `record:activity.types` was a CLOSED `z.enum([...])` of strings when this + // row was written, and it probed that enum with an unlisted word. + // `@objectstack/spec` 17.3.0 made the vocabulary OPEN — + // `z.array(z.union([FeedItemType, z.string().min(1)]))`, objectstack#11658 + // executing the maintainer's 2026-08-24 ruling on objectstack#11507 — so no + // ordinary string is refused there any more and the unlisted word ACCEPTS. + // The widening kept exactly ONE content refusal, and it is the one this + // control needs: `''` IS a string, so the only check it fails is `.min(1)` + // and it raises no `invalid_type` anywhere — right KIND, wrong CONTENT. + // That is exactly the distinction from the `42` line below, which is + // refused for its KIND, and it is why the pair still discriminates. + // Re-pointed under the maintainer 2026-09-07 authorisation on objectui#8137. + expect(specMemberVerdict('record:activity', 'types', 'array', '')).toBe( 'refuses-content', ); expect(specMemberVerdict('record:activity', 'types', 'array', 42)).toBe('refuses-kind');