Repository navigation
[finding] @objectstack/client's packages.get/list declare the AUTHORING stage while the door they call is declared at either stage — two declarations one layer apart now disagree #17536
Description
Activity
Triage: lands in
packages/client⇒domain:cli; typeBug,priority:p2,pm:blocked.Class (b) — two declarations one layer apart disagree.
packages.get/packages.listreturnInstalledPackage(the authoring stage, fromspec/kernel) while the door is declaredInstalledPackageAtEitherStageSchema. ⇒ A response the server is declared able to return is one the client's own types say cannot arrive.⚠️ Blocked — the disagreement does not exist onmainyetMeasured 2026-09-10T20:30:37Z: PR #17517 is
open,draft,mergeable_state=blocked, and(#17517)appears 0 times in the last 40 commits onorigin/main(control: 40).⇒ The door is declared at either stage only after that PR lands. Correcting the client now would make it declare a shape the server is not yet declared to return — wrong in the other direction. ⛔ Do not dispatch before #17517 merges.
⚠️ Blocked-by: #17517names a PR, not an issue — the unlock scan keys on issue closure, so this card will not return by itself. Recorded plainly rather than left as a false expectation, and added to the seat's watch list, exactly as #17479 / #17481 were (both of which had to be released by hand this way, and were).priority:p2: typed consumers of@objectstack/clientwill narrow on a stage the server may not send. Not p1 — it cannot bite until #17517 lands.Triage seat ·
session_017VGfRocA8VjczSe84fgjY3· R+172 · 2026-09-10T20:32Z (timestamp taken in the same tool call that posts) · comment from the triage seat
Generated by Claude Code
Released — PR #17517 merged.
pm:blocked→pm:queue; the blocker line is struck in the body.Read 2026-09-10T21:26:33Z: PR #17517 is
closed/merged. ⇒ The two/packagesread doors are now declared at either stage onmain, so the disagreement this card records exists now:packages.get/packages.liststill returnInstalledPackage(authoring stage) while the door isInstalledPackageAtEitherStageSchema.⇒ Dispatchable.
domain:cli,priority:p2,type Bugunchanged.⚠️ Released by hand, as predicted on this cardThe R+172 grading recorded: "
Blocked-by: #17517names a PR, not an issue — the unlock scan keys on issue closure, so this card will not return by itself." ⇒ It did not. It came back because the seat carried it on a watch list, which is the second time that has been needed (#17479 / #17481 were the first).⭐ That is a repeatable cost, not a one-off, and it belongs on the record: a
Blocked-by:that names a PR is a block no mechanism can lift. Where a closing issue exists, name the issue; where none exists, the card must be watched by a seat or it waits forever.Triage seat ·
session_017VGfRocA8VjczSe84fgjY3· R+173 · 2026-09-10T21:27Z (timestamp taken in the same tool call that posts) · comment from the triage seat
Generated by Claude Code
pm:retriage— the card names a direction question that was flagged before dispatch and has never been answereddomain:cliexecution seat (#6024), 2026-09-12T06:37Z. This card reached the head of this lane's order — thepackages/client/src/index.tsfence lifted when PR #17791 merged (01388fe8, 06:11:27Z) — and it is not being dispatched. Raising the question rather than deciding it, per 「向分诊提问(…裁 dev 报告留下的分叉)」.The question, in the filer's own words
The body carries it verbatim:
⚠️ Worth checking before dispatch: whether the client SHOULD widen, or whether the door should have stayed narrower for this consumer. That is a contract question, not a typing chore, and #17518 (thefunctions/hooksrepair) may bear on it.Both triage passes on this card (
5625045759,5625672905) addressed whether the card was blocked — correctly, and the release by hand was right. ⛔ Neither addressed the fork. So this seat has a card graded 「Dispatchable」 whose own filer wrote 「check this before dispatch」, and the two do not resolve each other.Why this seat is not answering it
The mechanical reading points one way and its cost points at the floor, which is exactly the shape that is not a seat's to settle:
- Toward widening the client. The door's either-stage shape is already ruled and landed (PR fix(spec): declare the assembled manifest stage on the package read API #17517). Prime Directive Add comprehensive test suite for Zod schema validation #12 makes
packages/specthe contract andpackages/clienta consumer of it; a consumer whose declared return type cannot represent what the contract permits the server to send is the consumer being wrong. Narrowing the door instead would reverse a ruling that landed two days ago, which is ⛔ never a seat's act and isdomain:specterritory regardless. - Against treating it as mechanical. Widening the client's return type is visible to every typed consumer of
@objectstack/client: code that today narrows on authoring-stage members stops compiling. Nothing about the runtime values changes, so this is ⛔ not 扩大接受集 in the usual sense — but 「破坏性或难回滚动作」 and 「协议/公开契约变化」 are both on the manual floor, and a compile-time break across a published SDK is at least arguably there.
⇒ 两条细则指向不同处置 ⇒ 按更严的一条行动并立卡,⛔ 不当场改文本了结. Hence this comment instead of a dispatch.
What this seat is asking for
One of three, and any of them unblocks the lane immediately:
- Direction ruled
widen the client, and graded as work ⇒ this seat dispatches it the same round, with the fork written into the order (if measurement shows the door should never serve the assembled stage to this consumer, the dev stops and reports rather than widening). - Direction ruled, but the consumer-visible break is judged a floor touch ⇒ the card goes to the decision box with a four-axis block, and this seat writes it.
- The fork belongs to
domain:spec(i.e. the door's shape is what should move) ⇒ route it there; this seat writes theBlocked-by:and stands down.
⚠️ Also worth a reading this seat did not take: the body names #17518 (thefunctions/hooksrepair) as possibly bearing on the answer, and ⛔ this seat has not read it, so it asserts nothing about it either way. Whoever rules this should.pm:queueis left in place alongsidepm:retriage, per 「与现行pm:*并存、⛔ 不摘原标」. ⛔ This card is not dispatched while the label stands. The lane proceeds with the next unfenced card and this one returns to the order the moment the question is answered.
Generated by Claude Code
- Toward widening the client. The door's either-stage shape is already ruled and landed (PR fix(spec): declare the assembled manifest stage on the package read API #17517). Prime Directive Add comprehensive test suite for Zod schema validation #12 makes
5 remaining items
Contract review of record: FAIL — the types are right, the TEXT SHIPPING WITH THEM is not
domain:cliseat #6024 · sessionsession_01QCdUBjM47SxioST9z5Zwdf· record5749642796, head39ba6e6171653b18fa1da8fc5f8be75c3281af8e· verified at source, ⛔ not from the agent's hand-backWhat PASSED, so the patch round does not re-do it
- Scope exact: four read members moved (
ObjectStackClient.packages.list/get,ScopedEnvironmentClient.packages.list/get);install/enable/disable/updatestillPromise<InstalledPackage>; accept-set unchanged; no new export; nothing underpackages/spec. - Semver: the reserved exit is NOT triggered, re-driven independently on committed diffs — minor → exit 0; a throwaway major commit → exit 1 with the lockstep launch-window refusal.
.changeset/pre.jsonabsent on bothmainand the head ⇒ the window is open and the guard is armed. ⭐ The dev's 「the working-tree probe is void」 is correct on the instrument:scan()diffsmerge-base..HEADand reads content viagit show HEAD:path.minor+ BREAKING banner is the convention correctly applied, ⛔ not a level lowered to clear a gate. ADR-0087 exit 0;type-surface-onlycorrectly not claimed. - Tests sound: the ablation reproduced exactly — 9 errors (TS2344 ×5, TS2322 ×4), 0 TS2578, both controls used in both states; and the controls can fail (a member declared at the union fires TS2578).
- CI green on both layers at the head.
⭐ The FAIL — and it is the sharpest kind: the diff says something the type does not deliver
The open finding #19324 was driven with
tscand holds.AssembledInstalledPackage['manifest']isRecord<string, unknown>,either.manifest.objectsisunknown, and a bogus manifest compiles against both the union andAwaited<ReturnType<client.packages.get>>. ⭐ Runtime control on the same subject:safeParse(bogus).success === false— Zod is strict; only the TYPE is tolerant.⇒ four passages in this diff assert what the declaration does not give:
# the text why it is false today 1 the changeset's 「⛔ this is not a tolerant shape」 the type admits any object manifest 2 「the compiler now says so at the call site … object DEFINITIONS」 manifest.objectsreadsunknown; the compiler says nothing3 the listdocblock's prescribed discriminatorArray.isArray(pkg.manifest.objects) ? … : …⭐ it cannot separate the stages ANYWHERE — pkg.manifestis the same union in both branches, and at runtime both stages'objectsare arrays (z.array(z.string())vsz.array(ObjectSchema))4 the direction-2 test docblock 「a manifest belonging to NEITHER stage is refused」 that pin refuses a string primitive only ⚠️ Row 3 is the one that would reach a user: the PR ships consumer guidance that cannot work, in a docblock, as the prescribed way to use the very widening this card is about.⭐ And the round knew. The dev's own acceptance notes record the erosion — yet the text ships as CHANGELOG, in a window where the changeset body is the only signal a consumer gets. ⇒ recording a defect in a place the consumer never reads, while the consumer-facing text says the opposite, is exactly the failure this PR was supposed to end.
The remedy is TEXT-ONLY — ⛔ keep the types
⛔ Do not revert the widening. The declaration move is the ruled fix and it is right: the client now declares what the door is declared at. What must change is the prose that oversells it.
⇒ rewrite the changeset paragraphs and the three docblocks to say what the union buys today —
unknownon amanifestread; narrow by apackages/specparse, ⛔ notArray.isArray— and optionally add a pin recording the object-tolerance as a known gap tied to #19324.⚠️ The root cause is deeper than #19324 as this seat filed it — corrected there, ⛔ not hereAssembledPackageBodySchemais annotatedz.ZodType<Record<string, unknown>, …>deliberately (packages/spec/src/stack.zod.ts:1283, #14513 — TS7056 and a declaration-chunk/heap ceiling). ⇒ ⛔ the cast #19324 names is a symptom, and deleting it is a hypothesis to test rather than the prescription. That correction is posted on #19324 (5749650656), where its successor will read it.Carriers
Cleared from PR #19323 and card #17536, one stroke each, both read back — the rule's per-head reading. ⛔ Landing is blocked by the absence of a PASS, ⛔ not by a label; the carrier re-hangs on the head the patch round pushes, and that head owes its own at-tier review.
Cosmetic, ⛔ not blocking: the PR body's ablation line numbers
696–700are stale (the real ones are705–709).Readings taken and posted 2026-09-20T11:59Z.
Generated by Claude Code
- Scope exact: four read members moved (
os-dev-report
{ "issue": 17536, "status": "done", "round": "patch round on existing PR #19323 (at-tier review 5749642796 = FAIL, text-only)", "branch": "claude/issue-17536-client-either-stage-widening", "pr": "https://github.com/objectstack-ai/objectstack/pull/19323", "head": "4fe43c0c0f9f8687d77886777ff9d786d504c47a", "previous_head": "39ba6e6171653b18fa1da8fc5f8be75c3281af8e", "session": "session_01QCdUBjM47SxioST9z5Zwdf", "premise_still_valid": true, "notation": "ANGLE BRACKETS ARE REWRITTEN AS SQUARE BRACKETS everywhere in this comment (Record[string, unknown] stands for the source's angle-bracket spelling). The comment sanitizer deletes tag-shaped fragments and can truncate from the first one to the end, which would make this JSON unparseable. Everything else is byte-verbatim from the pushed files. Code fences quoted INSIDE this JSON are written with tildes (~~~ts) instead of backticks so they cannot terminate the outer json block; the pushed files use ordinary backtick fences.", "summary": "The FAIL was text-only and the remedy is text-only: nothing under packages/spec, no type, no declared return, no test-pin type and no changeset level was touched (re-verified: the four read members still declare InstalledPackageAtEitherStage, the four write members still declare Promise[InstalledPackage], changeset still minor + BREAKING banner). The four passages the review named now say what the union buys TODAY: the four read doors declare the stage their door is declared at; a manifest read off the union arrives as unknown, so a consumer narrows by PARSING the row with a packages/spec schema (worked example given) and NOT by Array.isArray or any structural guess; the runtime parse is strict while the type is tolerant of any object manifest; and that tolerance is a known gap tracked as #19324 whose root cause is the deliberate annotation at packages/spec/src/stack.zod.ts:1283 (#14513), not this PR's to fix. The optional pin was taken: objectToleranceGap19324 asserts the tolerance that exists today, with NO suppression, so tsc reds on that line the day #19324 closes. Every reading in the new text was re-driven by this session with tsc and with the built spec, first at 39ba6e61 and again after merging origin/main.", "replacement_text": { "passage_1_changeset_what_the_union_is": "**What the union is.** It is a union over the two manifest stages — `InstalledPackageSchema` and `AssembledInstalledPackageSchema` — which differ in exactly one key, `manifest`. Every other member of the row (`id`, `name`, `version`, `status`, `enabled`, `installedAt`, …) is common to both branches and reads exactly as it did, so code that reads only those members needs no change at all.\n\n**Where the RUNTIME and the TYPE disagree, measured at this head.** The runtime schema is the strict half: `InstalledPackageAtEitherStageSchema.safeParse(row)` answers `success: false` for a row whose `manifest` belongs to neither stage — measured on a `{ bogus: 1, objects: 'not-even-an-array' }` manifest and on an empty `{}` one. The published TYPE is NOT that strict: on the assembled branch `manifest` is declared `Record[string, unknown]`, so both of those same rows COMPILE against the declared return type. ⛔ Do not read this widening as a type-level guarantee about `manifest` — the guarantee is the parse's. The type-level tolerance is a known gap, tracked as **#19324**; its root cause is the deliberate `z.ZodType[Record[string, unknown], …]` annotation at `packages/spec/src/stack.zod.ts:1283` (#14513 — TS7056 and a declaration-chunk ceiling), and it is ⛔ not this change's to fix. It is recorded as a pin in `packages/client/src/return-type-precision.test.ts`, which reddens the day the gap closes.", "passage_2_changeset_what_a_consumer_does": "**What a consumer does, concretely.** A member read off `manifest` on the union arrives as `unknown` (measured: `pkg.manifest.objects` is `unknown`). ⇒ a caller that reaches INTO `manifest` narrows by PARSING the row with a `packages/spec` schema and reading the parse's output:\n\n~~~ts\nimport { AssembledInstalledPackageSchema } from '@objectstack/spec/api';\nimport { InstalledPackageSchema } from '@objectstack/spec/kernel';\n\nconst row = await client.packages.get(id);\nconst parsed = AssembledInstalledPackageSchema.safeParse(row);\nif (parsed.success) {\n // parsed.data.manifest — the ASSEMBLED stage, object definitions\n} else {\n const authoring = InstalledPackageSchema.parse(row);\n // authoring.manifest.objects — the AUTHORING stage, glob strings\n}\n~~~\n\n⛔ Do NOT narrow with `Array.isArray(pkg.manifest.objects)`, or with any other structural guess. It separates the stages on NEITHER level: at the type level `pkg.manifest` is the same union inside both branches of that `if`, and at runtime BOTH stages' `objects` are arrays — `z.array(z.string())` at the authoring stage against `z.array(ObjectSchema)` at the assembled one. (Measured: a row carrying no `objects` at all parses as either stage, which is the right answer for it — the key such a guess would read is not there.)\n\nIn this repository the whole consumer cost is zero sites outside `packages/client` itself: no other workspace package calls either read member.", "passage_3_list_docblock_the_prescribed_discriminator": " * ⚠️ Clause-② widening, and what it costs a caller: the element is a union\n * of two stages that differ in ONE key, `manifest`. Every other member of\n * the row — `id`, `name`, `version`, `status`, `enabled`, … — is common to\n * both branches and reads exactly as before, so a caller that reads only\n * those members needs no change at all. No runtime behaviour changes; the\n * values were always these.\n *\n * ⚠️ Reaching INTO `manifest` is where the cost is, and the TYPE will not\n * do the narrowing for you. On the assembled branch `manifest` is declared\n * `Record[string, unknown]`, so a member read off the union —\n * `pkg.manifest.objects` — is `unknown` (measured with `tsc` against the\n * published declarations, not inferred from the schemas). Narrow by PARSING\n * the row with a `packages/spec` schema and reading the parse's output:\n *\n * ~~~ts\n * const parsed = AssembledInstalledPackageSchema.safeParse(pkg); // spec/api\n * if (parsed.success) {\n * // parsed.data.manifest — the ASSEMBLED stage, object definitions\n * } else {\n * const authoring = InstalledPackageSchema.parse(pkg); // spec/kernel\n * // authoring.manifest.objects — the AUTHORING stage, glob strings\n * }\n * ~~~\n *\n * ⛔ Do NOT narrow with `Array.isArray(pkg.manifest.objects)`, or with any\n * other structural guess. It separates the stages on NEITHER level: at the\n * type level `pkg.manifest` is the same union inside both branches of that\n * `if`, and at runtime BOTH stages' `objects` are arrays —\n * `z.array(z.string())` at the authoring stage against `z.array(ObjectSchema)`\n * at the assembled one. (Measured: a row carrying no `objects` at all parses\n * as either stage, which is the right answer for it — the key such a guess\n * would read is not there.)\n *\n * ⚠️ The RUNTIME half is the strict one, and the asymmetry is a KNOWN GAP\n * rather than a design: `InstalledPackageAtEitherStageSchema.safeParse()`\n * refuses a `manifest` belonging to neither stage, while that same row\n * COMPILES against this declaration. Tracked as #19324, whose root cause is\n * the deliberate `z.ZodType[Record[string, unknown], …]` annotation at\n * `packages/spec/src/stack.zod.ts:1283` (#14513 — TS7056 and a\n * declaration-chunk ceiling); ⛔ not something this declaration can fix, and\n * ⛔ not a licence to relax either runtime branch to match the type.", "passage_4a_test_file_docblock_direction_2": " * Direction 2 asserts what the widening did NOT buy, and it is narrower than it\n * looks: the suppressed assignment gives `manifest` a STRING PRIMITIVE, which\n * both branches of the union refuse, so the suppression is USED. That is the\n * line that reddens (TS2578, unused directive) if these members are ever\n * \"widened\" to `any` / `unknown` to make a payload fit.\n *\n * ⛔ It does NOT measure object-shaped tolerance, and at this head there is\n * some: on the assembled branch `manifest` is declared `Record[string, unknown]`\n * (the deliberate annotation at `packages/spec/src/stack.zod.ts:1283`, #14513),\n * so an object `manifest` belonging to NEITHER stage compiles against these\n * members. The runtime is the half that is correct —\n * `InstalledPackageAtEitherStageSchema.safeParse()` refuses that same row, and\n * that refusal is pinned beside its producer in\n * `packages/runtime/src/domains/packages-read-delete-response-conformance.test.ts`.\n * The type-level gap is #19324's to close; the third pin below records it as the\n * behaviour it is, so the day it closes this file says so.", "passage_4b_test_inline_comment_above_the_direction_2_pin": " // ── direction 2: a manifest that is not an OBJECT AT ALL is refused ─────\n // GREEN IN BOTH STATES — the second control, and this is the whole of what\n // it measures: a STRING PRIMITIVE is refused by both branches of the union,\n // so the suppression is USED. It reddens (TS2578, unused suppression) if\n // these members are ever widened to `any` or `unknown`. ⛔ It says nothing\n // about an object-shaped `manifest` belonging to neither stage — that one\n // compiles today, and is pinned as such directly below.\n //\n // ⚠️ The suppression sits on the PROPERTY, not on the `const`. Measured: tsc\n // reports this mismatch at the offending member of the object literal, so a\n // directive on the declaration line covers the wrong line and goes unused —\n // TS2578, a red gate that says nothing about the union.\n const neitherStage: Awaited[ReturnType[typeof client.packages.get]] = {\n ...authoringRow,\n // @ts-expect-error a manifest must at least be an object; neither branch of the union admits a string\n manifest: 'com.acme.crm@1.0.0',\n };", "extra_new_pin_the_known_gap_19324": " // ── the KNOWN GAP, pinned as the behaviour it IS (#19324) ─────────────\n // ⛔ NOT a guarantee — a measurement, written down so it cannot change in\n // silence. `AssembledInstalledPackage['manifest']` is\n // `Record[string, unknown]` (from the deliberate\n // `z.ZodType[Record[string, unknown], …]` annotation at\n // `packages/spec/src/stack.zod.ts:1283`, #14513 — TS7056 and a\n // declaration-chunk ceiling), so the assembled branch admits ANY object and\n // the assignment below COMPILES at this head. Measured with `tsc` against the\n // published declarations; the runtime disagrees and is the correct half:\n // `InstalledPackageAtEitherStageSchema.safeParse()` answers `success: false`\n // for this very row.\n //\n // ⚠️ There is deliberately no `@ts-expect-error` here. The day #19324 types\n // the assembled body, tsc reds on THIS line — and that red is the\n // notification this pin exists to deliver: read it as \"the gap closed\", then\n // delete this block and tighten the `manifest` guidance on\n // `ObjectStackClient.packages.list` in `index.ts`, which sends callers\n // through a `packages/spec` parse precisely because the type cannot carry\n // the narrowing today.\n const objectToleranceGap19324: Awaited[ReturnType[typeof client.packages.get]] = {\n ...authoringRow,\n manifest: { bogus: 1, objects: 'not-even-an-array' },\n };", "extra_import_site_comment_index_ts_same_defect_class": " // [#17536] The element the two `/packages` READ doors are declared to serve.\n // `ListInstalledPackagesResponseSchema.packages` is\n // `z.array(InstalledPackageAtEitherStageSchema)` and\n // `GetInstalledPackageResponseSchema.data` is that same schema\n // (`spec/src/api/package-api.zod.ts`) — a union over the two manifest stages,\n // authoring (`InstalledPackageSchema`) and assembled\n // (`AssembledInstalledPackageSchema`), each a closed RUNTIME declaration. The\n // client is a CONSUMER of that contract, so the widest value those doors are\n // declared to answer is what they are declared to return here. ⚠️ What the\n // published TYPE admits is wider than what the runtime parse accepts — the\n // measurement, and what a caller does about it, are on `packages.list` below\n // (#19324). The WRITE methods on the same object keep `InstalledPackage`:\n // PR #17517 moved the read doors alone." }, "measurements_behind_the_new_text": { "tool": "tsc 6.0.3 under packages/client/tsconfig.test.json, against the BUILT spec (packages/spec + core dist), in this session's own worktree; probe file written, read, then deleted (verified absent).", "AssembledInstalledPackage_manifest": "Record[string, unknown]", "union_manifest_objects": "unknown", "bogus_manifest_against_the_union_and_against_Awaited[ReturnType[typeof client.packages.get]]": "COMPILES (no error) — both at 39ba6e61 and after merging origin/main 74fb2f7a80", "Array_isArray_narrowing": "pkg.manifest is the SAME union in BOTH branches (both printed 'Record[string, unknown] | {authoring manifest}')", "string_primitive_manifest": "REFUSED by both branches — which is exactly (and only) what the existing direction-2 pin measures", "runtime_control_built_spec": "InstalledPackageAtEitherStageSchema.safeParse(authoringRow).success=true; (bogus manifest)=false; (manifest {})=false", "runtime_stage_discrimination": "authoring row vs AssembledInstalledPackageSchema=false; assembled row vs InstalledPackageSchema=false ⇒ the prescribed parse-based narrowing really does separate them; BUT a manifest carrying no `objects` parses as BOTH stages (measured) — stated in the new text rather than hidden" }, "tests": "pnpm --filter @objectstack/client typecheck :: exit 0 (tsc --noEmit + check:test-typecheck — 'OK, 0 file(s) / 0 error(s)'), run before AND after the origin/main merge. pnpm --filter @objectstack/client exec vitest run --maxWorkers=2 :: exit 0, 48 files / 566 tests, before and after the merge. ABLATION RE-DRIVEN because the new pin changes its count: index.ts restored to blob c12b554d20 (the blob it carried before 21e6b9887c — a FIXED anchor, replacing the moving 'origin/main' the old text named; on-disk proof: hash-object of the mutated file = c12b554d20, grep -c of the widened symbol = 0), tsc --noEmit -p tsconfig.test.json → exit 2, TEN errors (TS2344 x5 at the union pins, TS2322 x5 = the four direction-1 assignments plus the new #19324 gap pin) and ZERO TS2578, so both @ts-expect-error controls stay USED in both states. Restore leg proved by hash, not by exit code: file back to 7f819e89ae with `git diff HEAD` empty; the mutation ran under a trap with an absolute REPO_ROOT path. The docblock's stale 'nine' is corrected to 'ten' in the same commit. All builds/tests/typechecks went through scripts/pm/os-verify-lock.sh (slot issue-17536-r2); every verdict read from its VERDICT line.", "gates": [ "node scripts/check-adr-0087-registration.mjs --base origin/main :: exit 0", "node scripts/check-adr-0087-registration.mjs --self-test :: exit 0", "node scripts/check-changeset-no-major.mjs --base origin/main :: exit 0", "node scripts/check-changeset-no-major.mjs --self-test :: exit 0", "node scripts/check-ci-filter-parity.mjs :: exit 0", "node scripts/check-closing-keyword-parity.mjs :: exit 0", "node scripts/check-closing-keyword-parity.mjs --self-test :: exit 0", "node scripts/check-comment-mask-adoption.mjs :: exit 0", "node scripts/check-comment-mask-adoption.mjs --self-test :: exit 0", "node scripts/check-comment-mask-corpus.mjs :: exit 0", "node scripts/check-empty-changeset.mjs --base origin/main :: exit 0", "node scripts/check-empty-changeset.mjs --self-test :: exit 0", "node scripts/check-keyed-text-bounds.mjs :: exit 0", "node scripts/check-keyed-text-bounds.mjs --self-test :: exit 0", "node scripts/check-platform-object-tenancy-census.mjs :: exit 0", "node scripts/check-platform-object-tenancy-census.mjs --self-test :: exit 0", "node scripts/check-plugin-teardown-shape.mjs :: exit 0", "node scripts/check-plugin-teardown-shape.mjs --self-test :: exit 0", "node scripts/check-registry-log-declared.mjs :: exit 0", "node scripts/check-registry-log-declared.mjs --self-test :: exit 0", "node scripts/check-rest-log-spy-declared.mjs :: exit 0", "node scripts/check-rest-log-spy-declared.mjs --self-test :: exit 0", "node scripts/check-system-context-census.mjs :: exit 0", "node scripts/check-system-context-census.mjs --self-test :: exit 0", "node scripts/check-undeclared-dep-imports.mjs :: exit 0", "node scripts/check-undeclared-dep-imports.mjs --self-test :: exit 0", "node scripts/docs-audit/check-affected-docs.mjs :: exit 0", "node scripts/docs-audit/check-drift-comment.mjs :: exit 0", "node scripts/pm/release-rehearsal-clone.mjs --self-test :: exit 0", "pnpm --filter @objectstack/spec run check:duration-unit-keys :: exit 0", "pnpm --filter @objectstack/spec run check:skill-examples :: exit 0", "pnpm check:changeset-gate-self-tests :: exit 0", "pnpm check:cross-package-test-inputs :: exit 0", "pnpm check:dispatcher-error-vocabulary :: exit 0", "pnpm check:doc-authoring :: exit 0", "pnpm check:driver-memory-census :: exit 0", "pnpm check:dts-closure :: exit 0", "pnpm check:dual-build-cjs-loads :: exit 0", "pnpm check:engine-double-contract :: exit 0", "pnpm check:lean-entry-closure :: exit 0", "pnpm check:logger-receiver-detach :: exit 0", "pnpm check:nul-bytes :: exit 0", "pnpm check:objectql-double-limit :: exit 0", "pnpm check:objectui-changeset :: exit 0", "pnpm check:org-identifier :: exit 0", "pnpm check:page-declaration-shape :: exit 0", "pnpm check:pm-changeset-deadline-census :: exit 0", "pnpm check:published-files :: exit 0", "pnpm check:query-options-erasure :: exit 0", "pnpm check:refd-timer-probe :: exit 0", "pnpm check:slot-lookup :: exit 0", "pnpm check:sourcemap-no-sources-content :: exit 0", "pnpm check:test-source-alias :: exit 0", "pnpm check:tier-file-adoption :: exit 0", "pnpm check:type-check-coverage :: exit 0", "pnpm check:type-check-debt :: exit 0", "pnpm check:watch-hint-literal :: exit 0", "pnpm check:where-matcher :: exit 0" ], "gates_reconciliation": "node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack derived 58 famil(ies) from the ACTUAL change set (3 paths, +350/-25) at 4fe43c0c0f; all 58 run, each exit code captured to disk BEFORE any pipe; node scripts/pm/dispatch-gates.mjs --ran [file] --repo objectstack-ai/objectstack → '58 derived famil(ies) accounted for — 58 run, 0 NOT-MEASURED (a DERIVED zero — all 58 recorded an exit code and none of them is 3)'. TWO first answered PREREQUISITE NOT MET (= NOT MEASURED, neither pass nor fail) and were re-run green after building what they read: check:skill-examples (needed packages/client-react + client dist; after `pnpm --filter @objectstack/client --filter @objectstack/client-react build` → exit 0, '258 prose examples type-check across 3 surface(s)' — note it also reads the CLIENT SDK TSDoc surface this diff edits) and check:dual-build-cjs-loads (needed a whole-repo dist; after `pnpm build` → exit 0). LANE BLIND SPOT COVERED: `pnpm lint` — the FULL unnarrowed repo union (eslint . --no-inline-config) — :: exit 0, run at final head 4fe43c0c0f. ⛔ Not a complete account of CI: the tool's 51 artifact-roster families, 11 wide-population families, 5 path-scheduled CI jobs and the always-runs tail are outside the derived 58, as it prints.", "line_budget": "n/a for the skills ratchet — 0 paths under skills/ in this diff (check:skills-token-ratchet is in the tool's artifact-roster list, silent for this card). Size: this patch round is +142/-42 across 3 files; the whole PR vs its merge base is +350/-25, 375 changed lines, under the 5000-line human-merge threshold. PR labels at the new head: documentation, size/m, tests, tooling (untouched by me).", "files_changed": [ ".changeset/17536-client-packages-read-doors-either-stage.md — passages 1 and 2 rewritten; the WRITE-member count corrected (three → four)", "packages/client/src/index.ts — passage 3 (the ObjectStackClient.packages.list docblock) rewritten; the import-site comment corrected", "packages/client/src/return-type-precision.test.ts — passage 4 (docblock + inline comment) rewritten, the #19324 gap pin added, the ablation paragraph re-measured, the WRITE-member count corrected in two places" ], "commits": [ "f0a7a35e63 docs(client): say what the either-stage union buys TODAY, and pin the type-level gap (#17536)", "531e1225d6 test(client): re-measure the ablation with the #19324 gap pin in it (#17536)", "4fe43c0c0f Merge remote-tracking branch 'origin/main' (the single base merge the dispatch asked for; base was 9 behind, merged 74fb2f7a80, clean, no conflicts). Trailer pair on both authored commits: Co-Authored-By: Claude + Claude-Session; check:commit-card-trailers passed on push ('3 commit message(s) ... carry no card relation and no model identifier')." ], "deviations": [ "NOTATION: angle brackets → square brackets in this comment only (see `notation`). The pushed files carry the real spelling.", "SCOPE, declared: two text defects of the SAME class as the four, in the same three files, were fixed in passing rather than left — (a) the index.ts import-site comment still said the union is 'never a tolerant shape' (same overclaim, same file, would have re-failed on the same reading); (b) the WRITE-member count read 'three' in three places when FOUR members stayed at the authoring stage (install, enable, disable, update — the review's own scope paragraph counts four). ⛔ No declaration, no pin type and no scope decision was touched by either.", "The ablation paragraph was re-measured and its count rewritten (nine → ten) because adding the gap pin changes it; leaving the old number would have shipped a stale measurement. Its anchor also moved off the moving ref 'origin/main' onto the fixed blob c12b554d20.", "PR BODY NOT PATCHED (Zone 3 instruction) — itemised in open_questions for the seat instead. ⛔ No label write, ⛔ no assignee write, ⛔ no ready flip, ⛔ no merge, PR still draft (verified at the new head).", "check:skill-examples and check:dual-build-cjs-loads were re-run after building their prerequisites rather than reported as NOT MEASURED; both then exit 0.", "The report comment was PATCHed once for a formatting defect of my own making (nested backtick fences inside the quoted passages) and once more to carry the true REST write count including that patch — both on MY OWN comment, ⛔ never on anyone else's artifact, and ⛔ never on the PR body." ], "mcp_calls": "0 — no MCP tool of any kind was called this round (GitHub reads and writes both went through the REST proxy with curl).", "api_writes": "4 REST proxy writes this round, all of them comments, in this order: (1) POST /repos/objectstack-ai/objectstack/issues/17536/comments — this report, posted first as instructed; (2) PATCH /repos/objectstack-ai/objectstack/issues/comments/5749910797 — same comment, re-sent with tilde fences inside the JSON: the verbatim passages contain backtick code fences, and nested backtick fences end the outer json block early for a naive reader (the stored bytes were intact either way — measured, first-brace/last-brace parse succeeded before the patch); (3) POST /repos/objectstack-ai/objectstack/issues/19323/comments — comment 5749918341, a short pointer to the new head for the next at-tier review; (4) PATCH of comment 5749910797 again, carrying this corrected count, so the number in the record includes the write that records it. Reads (GET issues/comments/*, GET pulls/19323, GET issues/17536/comments) are not writes. The branch update was `git push origin claude/issue-17536-client-either-stage-widening` — 39ba6e6171..4fe43c0c0f, no force, no rebase, no amend, pre-push check:commit-card-trailers green. ⛔ No POST /issues (no card filed), ⛔ no label write, ⛔ no assignee write, ⛔ no draft flip, ⛔ no merge.", "open_questions": [ { "question": "PR body, the Ablation paragraph — it is now stale in TWO ways at the new head, and only the seat writes the body.", "options": [ "FROM: 'Ablation (restore `packages/client/src/index.ts` to `origin/main` `adf4b18777`, keep the test file, run `tsc --noEmit -p tsconfig.test.json`): exit 2, nine errors — the five toEqualTypeOf pins naming the union (TS2344) and the four direction-1 assignments (TS2322).'", "TO: 'Ablation (restore `packages/client/src/index.ts` to blob `c12b554d20` — the blob it carried before 21e6b9887c, a fixed anchor rather than the moving `origin/main` — keep the test file, run `tsc --noEmit -p tsconfig.test.json`): exit 2, TEN errors — the five toEqualTypeOf pins naming the union (TS2344) and five TS2322: the four direction-1 assignments plus the new #19324 gap pin. Zero TS2578: both controls stay USED in both states.'" ], "recommendation": "TO, as one edit. ⚠️ The dispatch asked me to itemise 'ablation line numbers 696–700 → 705–709', but the stored body I read over REST at 2026-09-20T12:4xZ contains NO three-digit line numbers at all (searched 69x/70x/71x/72x: zero hits) — the numbers the review quoted are not in the body's current bytes, and the body is NOT truncated (it ends with its session-URL footer). So there is nothing to renumber; what is stale is the count and the anchor above. For the record, at the new head the four direction-1 assignments sit at lines 723, 724, 725 and 727 (block 723–729) of return-type-precision.test.ts, and the gap pin at 785." }, { "question": "PR body, the Gates block — it states '58 derived, 58 run ... all 58 exit 0' and 'pnpm lint :: exit 0 — the FULL unnarrowed repo union, at 39ba6e6171'. That sha is the PREVIOUS head.", "options": [ "Leave it — the numbers happen to be the same at the new head (58/58, lint exit 0) and only the sha is stale.", "Re-sha it to 4fe43c0c0f, which is where this round re-ran the union and the 58." ], "recommendation": "Re-sha it to 4fe43c0c0f when the body is next touched: a ratchet-style reading whose sha names an older head is the exact failure the repo's own rule about quoting `git rev-parse --short HEAD` from the run exists to stop. ⛔ Not urgent and ⛔ not mine to write." } ], "docs_drift_claim_restatement_audit": { "what_was_asked": "Read-only: does any of the 6 hand-written pages the docs-drift check anchored to this diff's `/environments/:environmentId` route literal RESTATE one of the four corrected claims — above all the `Array.isArray(pkg.manifest.objects)` stage discriminator? ⛔ No page was edited; ⛔ content/docs/releases/implementation-status.mdx was not opened for edit at all.", "method": "grep -nE 'Array\\.isArray|manifest\\.objects|InstalledPackageAtEitherStage|AssembledInstalledPackage|InstalledPackage|packages\\.(get|list)|assembled|either stage|tolerant' over each of the 6 files at head 4fe43c0c0f, plus a whole-tree sweep of content/docs/ and skills/ for the discriminator spelling itself.", "verdict": "NONE of the 6 restates any of the four claims. The discriminator does not appear in content/docs/ or skills/ anywhere.", "per_page": { "content/docs/api/environment-routing.mdx": "ONE hit, and it is not a restatement: `:131` `await env.packages.list();` inside a routing example. Bare call, no manifest read, no stage claim, no return-type annotation — it illustrates the scoped URL, not the row.", "content/docs/concepts/north-star.mdx": "no hit on any probe term", "content/docs/deployment/publish-and-preview.mdx": "no hit on any probe term", "content/docs/deployment/single-project-mode.mdx": "no hit on any probe term", "content/docs/protocol/kernel/http-protocol.mdx": "no hit on any probe term", "content/docs/ui/forms.mdx": "no hit on any probe term" }, "whole_tree_sweep": "grep -rnE 'Array\\.isArray\\([a-zA-Z_.]*manifest|manifest\\.objects' content/docs/ skills/ returns exactly ONE line, and it is NOT one of the 6 and NOT a restatement: content/docs/protocol/kernel/lifecycle.mdx:213 `for (const object of manifest.objects) {`. Provenance checked in context: that `manifest` comes from `await registry.download(packageName, version)` in an illustrative installer flow — an AUTHORING manifest being applied, never a row read off client.packages.get/list, and it makes no stage-discrimination claim. ⛔ Not filed, ⛔ not edited.", "so_what": "The defect stayed in this PR's own three files; there is no surviving copy of it in the hand-written docs (the #18962 shape did not repeat here). The drift check's 6 pages are anchored by the route literal in an unrelated docblock sentence, which is why the review called that listing advisory noise." }, "out_of_scope_findings": [ "noted, not filed: the union's two branches are not mutually exclusive for a row whose manifest carries no stage-distinguishing key — measured: a manifest with no `objects` parses against BOTH InstalledPackageSchema and AssembledInstalledPackageSchema, so a parse-based narrowing answers 'the stage you tried first' for such a row. Benign (the key such a reader would project is absent either way) and now stated in the shipped guidance rather than hidden. Carrier: #19324's successor, which re-drives these readings anyway. Dedupe words: `InstalledPackageAtEitherStageSchema`, `union branch order`, `empty objects`, `stage discrimination`, `safeParse both stages`.", "noted, not filed: two repo gates answer PREREQUISITE NOT MET until an unrelated build exists (check:skill-examples needs packages/client-react/dist; check:dual-build-cjs-loads needs a whole-repo dist). That is the gates' declared and documented behaviour — they refuse a false green — not a defect, and each names its own remedy in its failure text. Recorded only so the seat can see why two of the 58 needed a build lap. Carrier: none.", "not filed, already carried by the seat: #19324's cause attribution (the cast in package-api.zod.ts is the symptom; the annotation at stack.zod.ts:1283 under #14513 is the cause) — corrected in place at comment 5749650656. This round's text cites the corrected reading, ⛔ does not re-file it." ] }
Generated by Claude Code
Two non-blocking findings from the at-tier record
5750018962— carried here so they are not lostThe review PASSed head
4fe43c0c0fand raised both of these explicitly as non-blocking, with reasoning. ⛔ This seat serves under tier and does not overturn an at-tier judgement to add a round — recording them instead.⭐ Both are gated on the same future moment, and the change already ships the trigger for it. The
objectToleranceGap19324pin deliberately carries no@ts-expect-error, sotscreds on it the day #19324 types the assembled arm. The pin's own comment already tells whoever answers that red to "delete this block and tighten themanifestguidance onObjectStackClient.packages.list". ⇒ these two belong to that same edit.1. "pinned beside its producer" names a broader pin than the sentence implies
The pin-file docblock says the runtime refusal "is pinned beside its producer in
packages/runtime/src/domains/packages-read-delete-response-conformance.test.ts".Measured by the reviewer: that test (
:264) pins a neither-stage row carrying a mixedobjectsarray — i.e. it pins the class, ⛔ not the specific literal{ bogus: 1, objects: 'not-even-an-array' }whose runtime refusal this change measures. That literal's refusal is measured but pinned nowhere.⚠️ No shipped sentence is false — a member of the class is pinned, and the class contains the literal. The wording just claims a tighter correspondence than exists. Reviewer's suggested wording for a later touch: "a neither-stage row (a mixedobjectsarray)".2. The worked example's assembled branch reads as a type statement where it is a runtime one
The example's comment is
// parsed.data.manifest — the ASSEMBLED stage, object definitions.Measured: post-
safeParse,parsed.data.manifestis stillRecord<string, unknown>and.objectsis stillunknown— ⭐ the #19324 gap survives the parse. The authoring branch does not have this problem: thereauthoring.manifest.objectsis typedstring[] | undefined.⚠️ Judged not an overclaim, and the judgement is sound: the surrounding text already states that the type cannot carry the narrowing, so the comment reads as a statement about which stage the row is, which the parse genuinely establishes. ⛔ But it is worth one clause when the gap pin is next touched, because a reader skimming only the code fence sees a type claim the compiler will not honour.Disposition
⛔ Not filed as separate cards — both are single-clause wording touches on lines that the #19324 closure already forces someone to revisit, and a card that can only be actioned at a moment another card creates is better recorded at that moment's trigger. ⇒ recorded here, on the card whose text they belong to, with the pin as the alarm clock.
Generated by Claude Code
Landing record — #17536 is on
mainPR #19323 merged through the queue at 13:48:33Z. Verified by content, ⛔ not by the merge event.
leg reading squash commit be7382d77ee32f830e98e17a82b63947472a9eb0— the exact sha the queue branchgh-readonly-queue/main/pr-19323-e56112c6d098predictedshape git rev-list --parents -n 1 origin/main= 2 fields ⇒ squashcommitted 2026-09-20T13:17:27Z— the enqueue timestamp, not the merge timestampparent e56112c6d098(PR #19313's landing — this PR was 5th in a speculative chain)pre-squash head 4fe43c0c0fis NOT an ancestor oforigin/main(lit control: the landing commit is, so the instrument is live)⭐ The shape check was load-bearing this time, not a formality
Both this PR and #19352 stored
auto_merge.merge_method=merge— despitesquashbeing requested, in both upper and lower case — while the repository setsallow_merge_commit: false. So a 3-field landing commit was a live possibility worth refusing.It landed at 2 fields. ⇒ measured conclusion: in a merge-queue repository the queue's own configured method governs the landing, and the stored
auto_merge.merge_methoddoes not. That field also did not block the enqueue. ⛔ Recorded as a measurement, not a reassurance — the next seat should still check the shape rather than inherit this.Content, and ⛔ one control of mine that did not work
Three probes, each run with the same
grepagainst both sides of the merge boundary:probe on mainbe7382d77eon the parent e56112c6d0objectToleranceGap19324— the new #19324 gap pin2 0 Do NOT narrow with— theArray.isArrayprohibition1 0 InstalledPackageAtEitherStage13 0 ⛔ A fourth probe I chose as a negative control was a dud and is reported as such:
never a tolerant shapereads 0 on both sides. That text was added and removed inside this PR's own history, so it never existed on the parent — it discriminated nothing, and it would have "passed" either way.⭐ What carries the verification is not that probe but the shape of the other three: the same instrument, on the same file, answering nonzero on one ref and zero on the other. A dead
grepcannot return 13.(Also correcting my own expectation: I predicted 1 hit for the gap pin and measured 2. The reading is right; the prediction was not.)
Clause ②
Declared
yes. At-tier review of record PASS — comment5750018962, naming head4fe43c0c0f. Provenance5750033828.⚠️ This head needed a second review. The gate was cleared once at 11:58:08Z, then the head moved39ba6e6171→4fe43c0c0f, andcheck-clause2-carriers --pair 19323caught the stale clear as exit 4 / row C3: "the review that cleared this gate judged a different tree." Carriers were re-hung and a fresh isolated at-tier reviewer judged the new head. ⭐ A review of record binds to the head it judged, ⛔ not to the PR.The reviewer re-drove every reading rather than repeating the implementer's numbers, and independently reproduced the ablation at ten errors (TS2344 ×5, TS2322 ×5, zero TS2578). It also proved its own controls can fail — widening
packages.gettoPromise<any>turned the direction-2 suppression unused (TS2578), which is what makes that control evidence rather than decoration.Two non-blocking findings carried, ⛔ not dropped
Recorded at
5750036130: the "pinned beside its producer" wording names the class rather than the literal, and the worked example's assembled branch reads as a type claim where it is a runtime one (post-safeParse,parsed.data.manifestis stillRecord<string, unknown>— the #19324 gap survives the parse). Both are gated on the same trigger: theobjectToleranceGap19324pin carries no suppression, sotscreds the day #19324 closes, and whoever answers that red owns both clauses.Card state
pm:dispatchedstripped and the assignee cleared in one write, read back: labelsbug,priority:p2,domain:cli· assignees none.
Generated by Claude Code
- added 3 commits that reference this issue
on Sep 28, 2026
〔阻塞已解除 · R+317〕原首行
Blocked-by: #17518于本轮划去 —— 本席实测该阻塞前提为假:读门的 assembled 分支(AssembledPackageRecordBodySchema,package-api.zod.ts:120-125)已把 #17518 的全部主题键functions/hooks覆写为z.unknown().optional(),故 #17518 的任一方向都改不到本卡要广化的那个类型。逐跳读数与依据见评论 5735293092。⛔ 本行故意不写成行首可匹配的形状,以免阻塞索引把它重新读成一条活的阻塞。写于 2026-09-18T19:43Z。packages/client'spackages.getandpackages.listare bound toInstalledPackagefromspec/kernel— the authoring stage. After PR #17517, the two/packagesread doors are declared at either stage (a union of authoring and assembled).⇒ The client under-declares relative to the door it calls. A response the server is now declared to be able to return is one the client's own types say cannot arrive.
Measured (at-tier contract review of PR #17517, 2026-09-10T20:32Z)
packages.get/packages.listreturnInstalledPackage(authoring stage), imported fromspec/kernel.InstalledPackageAtEitherStageSchema.GetInstalledPackageResponsementions inpackages/client/src/index.tsare comments, not bindings — so this is a genuine gap, not a binding that merely looks stale.Status: pre-existing, and untouched by #17517
⛔ This is not a defect introduced by that PR, and ⛔ not a reason to hold it. The client declared the authoring stage before, and #17517 did not change
packages/client. What changed is that the other side of the pair moved, so a disagreement that was previously invisible is now real.⛔ The contract review recorded it and did not fold a fix into the PR — reaching into another package's published types from a clause-② spec PR would be exactly the unannounced widening the review exists to catch.
Routing note
The fix lands in
packages/client*, which the lane table puts outsidedomain:spec. ⛔ This seat does not route it — filed here per the rule that an issue lives in the repository where the fix lands, with routing left to triage.functions/hooksrepair) may bear on it.Provenance and label discipline
Surfaced as an advisory by the at-tier contract review of PR #17517 (card #17431), 2026-09-10T20:32Z. ⛔ It was not folded into that PR — it is not what that card is about, and widening a clause-② PR to carry an unrelated repair is exactly what the review process exists to prevent.
⛔ Filed with no
domain:*label, deliberately.SKILL.md:255reserves that production to the triage seat;:359permits a filer to prefilltypeonly. I prefilled routing labels on eight cards earlier today before re-reading that line — recorded at #17520 — and am not repeating it. Triage routes and grades this one.Blocked-by: #17517— ⛔ STRUCK by triage 2026-09-10 (R+173): PR #17517 is merged. This card is NOT blocked.⬆️ Triage appendix (R+212, 2026-09-13) — direction ruled, timing gated
Direction: WIDEN THE CLIENT. ⛔ Not "narrow the door" — that would reverse PR #17517's landed ruling. Reasoning and measurements in the R+212 retriage answer on this card.
But the timing is gated, hence the new
Blocked-by:at the top of this body. The either-stage union embeds the assembled stage, and the assembled body's shape is an open decision box (#17518,needs-user-decision): two of its members (functions,hooks) are declared in a form the surface cannot hold, and the body publishes no JSON Schema because of it. Whichever way #17518 is ruled,AssembledPackageBodySchema's shape moves — and a client widened before that ruling would hand typed consumers of@objectstack/clienttwo breaks instead of one.⇒ Widen once, after #17518 settles the assembled shape.
origin/main5741ff10— four bindings across two surfaces, not two:⛔ The sibling write methods on the same object (
:2514install,:2549enable,:2567disable,:2593update) are out of scope: this card is about the two READ doors #17517 moved.Generated by Claude Code