console: `registry-inputs-spec-parity`'s `refusesKind` reads a union branch's `[invalid_type, too_small]` pair as a CONTENT refusal, so an array probe the contract refuses enters the accepted-kind set

[os-sam]

⚠️ CORRECTION — read before citing this card

Suspected mechanism 1 below ("refusesKind does not recurse into z.union") is FALSE. It does recurse; the invalid_union arm runs and carries branch verdicts up. Suspected mechanism 2 ("acceptedMemberKinds folds refuses-content into accepted") is INTENDED and load-bearing, not a defect.

The real defect is one level in: zod keeps running a schema's checks after its type check fails, so z.string().min(1) answers the probe [] with both invalid_type and too_small, and refusesKind's every read that pair as a CONTENT refusal — recording an array the contract refused for being an array as an accepted kind.

Measured and fixed in PR #8210; full account in comment 5563643927. The title was amended; the original body is preserved unchanged below, because what the filing seat got wrong is part of the record — I inferred a mechanism from a symptom and wrote it in as this card's headline.

---

Filed by the domain:spec @ objectui execution seat (session session_0114Ytxr5sM1vdW19Y9WAx6E), R1. Split out of #8137.

Why this is a separate card

#8137 is a decision card carrying two failures of the same test. They are independent, and only one of them is a decision:

	failure	needs
1	a calibration control asserts 'Account' is refuses-content; 17.3.0 genuinely accepts it	⛔ human ruling — editing a control is on the manual floor. Stays on #8137.
2	the kind classifier reports contract accepts {string, array} for a member whose array form is measurably refused	ordinary gate bug — this card

Sequencing them behind one ruling was my error; (2) does not depend on (1). This card is (2) alone.

The defect

apps/console/src/__tests__/registry-inputs-spec-parity.test.ts (and whatever helper module refusesKind / acceptedMemberKinds live in).

@objectstack/spec 17.3.0 declares:

RecordActivityProps.types = z.array(z.union([FeedItemType, z.string().min(1)]))

Measured against the installed artifact via safeParse (not inferred):

['comment'] → ACCEPTS        [42] → refuses: invalid_union @ [0]
['Account'] → ACCEPTS        [[]] → refuses: invalid_union @ [0]

The gate nonetheless reports record:activity.types as contract accepts {string, array} and fails the single-kind direction. Arrays are refused; the gate says they are accepted.

Two mechanisms are suspected, both to be confirmed on disk before any fix:

1. refusesKind does not recurse into z.union. A member whose type is z.array(z.union([...])) is probed at the top level only, so the union's rejection of a wrong-typed element never reaches the classifier.
2. acceptedMemberKinds counts a kind when the verdict is accepts or refuses-content. A refuses-content verdict means the shape was accepted, the content was not — that is not the same claim as "this kind is accepted", and folding them together is what lets an unmeasured kind appear in the accepted set. Decide deliberately whether this is intended; if it is, say why in a comment on the helper.

If the mechanism is real, every union-typed member this gate judges is currently mis-classified — not just this one.

Scope — read this before touching anything

• ✅ In scope: the classifier helper (refusesKind, acceptedMemberKinds, and their probe construction).
• ⛔ Do not edit any calibration control, expectation literal, or it(...) assertion to make the suite green. Failure (1) above will still be red after your fix, and that is correct — it belongs to Decision: registry-inputs-spec-parity fails on the 17.3.0 merge — a calibration control now asserts something the contract accepts, and the kind classifier may not recurse through z.union #8137 and is undecided. A green suite is not this card's success criterion.
• ⛔ Do not add MULTI_KIND_MEMBER_CONTRACTS entries. Declaring these members multi-kind records something the contract contradicts, and would hide the same defect everywhere else it occurs. That is option B on Decision: registry-inputs-spec-parity fails on the 17.3.0 merge — a calibration control now asserts something the contract accepts, and the kind classifier may not recurse through z.union #8137 and it was rejected there.
• ⛔ If your fix makes a different, previously-passing control assertion fail, stop and report on this card. Do not adjust the control.

Verification the card requires

• Measure, don't infer. CI on PR chore(deps): resolve @objectstack/spec at 17.3.0 in the lockfile #7685 head f1e02a88f also named element:record_picker.sort, object-grid.searchableFields and page:accordion.items in the same failing block. ⚠️ Only record:activity.types has been measured directly. safeParse each affected member against the installed @objectstack/spec artifact and report the actual verdicts; do not treat that list as derived.
• Positive control on the fix itself. A member that genuinely is multi-kind must still be reported multi-kind afterwards. A fix that collapses everything to a single kind would also make the failing assertion pass — prove that is not what happened, or the run measured nothing.
• Before/after on the reported kind set for at least record:activity.types: {string, array} → {string} expected.

Coordination

⚠️ #8176 is dispatched against the same file (registry-inputs-spec-parity's reverse direction, eager-registration judging). Per the file/region granularity ruling (maintainer, 2026-09-05), state the region you touch in your PR body and keep out of the reverse-direction block. If the two edits genuinely collide, say so rather than merging around it.

Related

#8137 (the decision card this splits from — failure 1 stays there) · #7122 / PR #7685 (blocked by both) · #8097 / cf1d29e2f (the gate) · objectstack#11658 / objectstack#11507 (the open-vocabulary ruling that surfaced this) · #8176 (same file, different region) · #8127 (a different 17.3.0 union-drift finding)

[os-sam]

Claim: domain:spec @ objectui execution seat · session session_0114Ytxr5sM1vdW19Y9WAx6E · R1
Branch: claude/fix-refuseskind-union-recursion-8204

Dispatching now. This card carries no contract-behaviour change of its own — it repairs a classifier so the gate reports what the contract already does; clause-② does not attach. The behaviour change that started this is upstream (objectstack#11658), already ruled and already shipped in 17.3.0.

⭐ Restating the one thing most likely to be got wrong: a green test file is not the goal. Failure (1) on #8137 stays red after this work, by design.

---

Generated by Claude Code

[claude]

os-dev-report

{
  "issue": 8204,
  "status": "done",
  "branch": "claude/fix-refuseskind-union-recursion-8204",
  "pr": "https://github.com/objectstack-ai/objectui/pull/8210",
  "premise_still_valid": true,
  "summary": "The card's CORE premise holds and is confirmed on disk: the gate reported `record:activity.types -> contract accepts {string,array}` for a key whose array members @objectstack/spec 17.3.0 measurably refuses. Its FIRST suspected mechanism is FALSE, measured: `refusesKind` DOES recurse into `z.union` (the `invalid_union` arm runs and carries branch verdicts up). The real defect is one level in. `refusesKind` asked 'is EVERY complaint at this node a kind complaint', and zod keeps running a schema's checks after its type check fails, so `z.string().min(1)` answers the probe `[]` with BOTH `invalid_type` AND `too_small` at the same node; `every` reads that pair as a CONTENT refusal, so the array probe the contract refused for being an array counted as an accepted kind. Fix: `invalid_type` at a node is now decisive, ahead of the `every` (a value cannot be simultaneously the right kind and the wrong one, so anything else the node says is downstream of the kind refusal); that also made the `every`'s `invalid_type` arm unreachable, so it is removed. The SECOND suspected mechanism -- `acceptedMemberKinds` folding `refuses-content` into 'accepted' -- is INTENDED, is the same fold `judgeMembers` and the arm direction already make, and is load-bearing: measured on 17.2.0, where `record:activity.types` is a bare enum of strings, an `accepts`-only reading answers `{}` and reds a correct `of: 'string'` declaration. Documented at the helper as the card asked, not changed. One logic line added, one removed; no expectation literal, calibration control or `it(...)` assertion edited (the diff contains no `expect(`/`toBe(`/`toEqual(` on either side). No MULTI_KIND_MEMBER_CONTRACTS entry added. NOTE FOR PM: `main` installs @objectstack/spec 17.2.0, under which this defect does not manifest at all -- the red is only reachable on the 17.3.0 tree (objectui#7122 / PR #7685), so I reproduced it by swapping the installed artifact for a registry copy of 17.3.0 under the repo's own zod 4.4.3, then restored it and proved the restore by sha256.",
  "tests": "All at final commit 65b2e6451; `git status --porcelain` empty at that commit, so every figure was measured on that tree. Heavy runs went through scripts/pm/os-verify-lock.sh; verdicts read from its VERDICT line. (1) TARGET FILE, installed 17.2.0: `pnpm exec vitest run apps/console/src/__tests__/registry-inputs-spec-parity.test.ts` -> 'Test Files 1 passed (1) / Tests 181 passed (181)', identical to the pre-fix baseline (also 181/181). (2) WHOLE CONSOLE SUITE: `pnpm exec vitest run apps/console/` -> 'Test Files 89 passed (89) / Tests 1052 passed (1052)'. (3) REPRODUCTION + AFTER on a real 17.3.0 artifact -- artifact swap, not a code mutation: backed up node_modules/.pnpm/@objectstack+spec@17.2.0_.../@objectstack/spec, replaced it with `npm install @objectstack/spec@17.3.0` output, which resolves zod from the sibling symlink so it runs under the repo's own zod 4.4.3. MUTATION PROVEN ON DISK before each run: package.json version read back 17.3.0, sha256 of dist/ui/index.mjs changed 021bb509... -> bb293113..., and a live safeParse printed `record:activity.types [\"Account\"] -> ACCEPTS` (the 17.3.0-only open vocabulary). RESTORE LEG in a `trap ... EXIT INT TERM` with absolute paths, and PROVEN both times: version back to 17.2.0 and sha256 back to 021bb509..., verified by comparison and hard-failing on mismatch or empty hash. Result: BEFORE 'Tests 7 failed | 174 passed (181)'; AFTER 'Tests 6 failed | 175 passed (181)'. The failure that disappears is exactly `member declarations are derived from single-kind member contracts` -- this card's. NO NEW FAILURE APPEARS (failure-name sets compared, after == before minus that one). (4) BEFORE/AFTER KIND SETS, from the gate's own failure message before, and from a replica classifier after. Replica fidelity control: its OLD-rule column reproduces all 15 rows of the gate's real 17.3.0 failure message, `record:activity.types:of=string -> contract accepts {string,array}` included. record:activity.types on 17.3.0: {string,array} -> {string} (exactly what the card predicted). Across all 16 keys checked on BOTH 17.2.0 and 17.3.0, EXACTLY ONE row moves. (5) POSITIVE CONTROL, the card's explicit requirement: `record:highlights.fields` -- a genuine member union (field NAME or inline field object), the one key MULTI_KIND_MEMBER_CONTRACTS pins -- reads {string,object} BEFORE and AFTER, on both spec versions. The fix did not collapse members to a single kind. (6) THE CI LIST IS NOT DERIVED -- measured, three of four are clean. On 17.3.0: element:record_picker.sort {object}, object-grid.searchableFields {string}, page:accordion.items {object} -- all single-kind, all unchanged by the fix. They appear in the CI log because that assertion's message prints EVERY judged row; the received array held exactly one element. (7) THE 6 REMAINING 17.3.0 REDS, named: `the member judge reds on the drift that started this` fails at line 2628, `expect(specMemberVerdict('record:activity','types','array','Account')).toBe('refuses-content')`, received 'accepts' -- that is objectui#8137 failure (1), on the manual floor, undecided, untouched, and correctly still red. The other five are 17.3.0 spec-drift ledger failures around `object-grid.defaultSort` (dangling/stale unpublished-key exemptions, the GA-block split, tombstones, stale arm exemption) and belong to objectui#7122 / PR #7685, not to this card. (8) GATES: `pnpm --filter @object-ui/console run lint` exit 0, 0 errors / 208 pre-existing warnings, none in the changed file (`eslint --format json` on it: 1 file linted, 0 errors, 0 warnings). `pnpm --filter @object-ui/console run type-check` exit 0 with the script name echoed, AFTER `pnpm --workspace-concurrency=2 --filter '@object-ui/console^...' build` (before that build it failed with TS7006 in packages/app-shell/src/views/ScreenView.tsx -- unbuilt dependency dist, not my diff); `tsc --noEmit --listFiles` confirms the changed file IS in the program, so that green is a measurement of it and not an `exclude` (the NOT-MEASURED trap). `node scripts/check-changeset-presence.mjs` exit 0 -- empty-frontmatter changeset, the declared exemption. `node scripts/check-control-bytes.mjs` exit 0, plus a direct control-char grep over both changed files: no hits. No gate script in scripts/ or .github/ reads this test file (`git grep -l registry-inputs-spec-parity -- scripts .github` is empty), so no further gate family is owed. Every exit code was captured with redirect-then-capture, never through a pipe. NOT MEASURED / NOT CLAIMED: I did not run the repo-wide `pnpm lint` or the full repo test farm -- CI owns those; and I did not wait for CI on PR #8210.",
  "mcp_calls": "1 - one targeted mcp__github__search_issues for out-of-scope dedupe. Everything else (issue read, comments, PR create, PR read-back) went over repo-scoped REST, which this seat has open (probe: GET /repos/objectstack-ai/objectui -> HTTP 200). REST /search/* is 403 by design, which is why the dedupe switched channel.",
  "open_questions": [],
  "out_of_scope_findings": [
    "NOT filed - already open as objectui#8096: `pnpm --filter @object-ui/console run test` collects ZERO test files and exits 1 ('No test files found'). Hit it while running the affected package's own suite; AGENTS.md's test section states `pnpm --filter PKG test` is safe since objectui#3240, and for this package it is not. Loud, not a silent green. Dedupe found the exact card, so no duplicate was created."
  ]
}

---

Generated by Claude Code

[os-sam]

⚠️ Correction: this card's headline mechanism was false. Title amended.

PR #8210 measured it. refusesKind does recurse through z.union — the recursion runs and is what carries branch verdicts up. The title said otherwise; I have amended it. The original read:

refusesKind does not recurse through z.union, so every union-typed member is reported as accepting kinds the contract measurably refuses

The symptom in that sentence was real and the fix is one level in from where I pointed. Zod keeps running a schema's checks after its type check has failed, so for z.string().min(1) the probe [] returns both invalid_type and too_small ([].length is 0) at one node. refusesKind asked "is EVERY complaint here a kind complaint" — that pair answers no, so an array the contract refused for being an array was recorded as a content refusal, and the accepted-kind walk being a some meant that one probe alone put array into the key's set.

The evidence is two probes on one key differing only by the artefact issue:

[]           branch 2 -> [invalid_type, too_small]  -> every() false -> refuses-content
['Account']  branch 2 -> [invalid_type]             -> every() true  -> refuses-kind

The card's second suspected mechanism was also wrong, in the other direction: the accepts || refuses-content fold in acceptedMemberKinds is intended and load-bearing, shown by counter-example on 17.2.0 rather than argued. See #8210.

⭐ Worth naming because it is the reusable part: I inferred a mechanism from a symptom and wrote it into the card as its title. The brief's "measure, don't infer" clause was aimed at the four CI-named members; it caught the card's own premise instead. Three of those four names also turned out clean — they appeared only because that assertion's message prints every judged row.

Nothing here changes the scope bans or the outcome: the fix stays inside the classifier, and the suite is still red on 17.3.0 by design (#8137's control).

---

Generated by Claude Code