Skip to content

fix(spec): refuse a malformed actions array in the non-strict bound-action merge - #19815

Merged
objectstack-fleet[bot] merged 2 commits into
mainfrom
claude/issue-19799-merge-actions-actions-shape
Sep 23, 2026
Merged

objectstack-fleet[bot] merged 2 commits into
mainfrom
claude/issue-19799-merge-actions-actions-shape

Conversation

@objectstack-fleet

@objectstack-fleet objectstack-fleet Bot commented Sep 23, 2026 •

Copy link
Copy Markdown
Contributor

Fixes #19799

Clause-②: no (narrowing)

What changed

mergeActionsIntoObjects (packages/spec/src/stack.zod.ts) — the merge that ends every defineStack call and composeStacks step 7 — now shape-guards every actions array it hands to sortActionsByOrder: the top-level one and each object's own. A non-array, or an array holding a non-object entry, is refused with StackSchemaInvalidError (STACK_SCHEMA_INVALID, status: 422), the zod issues at the strict parse's own paths, all findings in one refusal:

site non-array non-object entry
top-level actions ['actions'] ['actions', index]
an object's own actions ['objects', i, 'actions'] ['objects', i, 'actions', index]

The non-array half reuses the shared describeNonArrayCollection helper, so the top-level refusal is the line composeStacks step 3 already draws for a non-array actions. undefined is the one non-array accepted (key absent). sortActionsByOrder is unchanged: its callers now only ever hand it an array of objects.

Landing site: as expected — mergeActionsIntoObjects, plus a new test file and a changeset. No other package.

Readings (at origin/main e7a8bd43a4, built dist)

Before, defineStack(config, { strict: false }):

  • top-level actions: 5 / 'abc': TypeError: actions.some is not a function, code/status undefined
  • top-level actions: [null]: TypeError reading order of null; [5]: accepted, entry handed on
  • object actions: 5 / {}: TypeError: actions.some is not a function; [null]: TypeError reading order

The strict door on the same inputs: STACK_SCHEMA_INVALID / 422 at ['actions'], ['actions', 0], ['objects', 0, 'actions'], ['objects', 0, 'actions', 0] — so the object-level path is refused by the strict door, and this PR refuses it at the same path with the same envelope. After this PR every row above answers exactly that.

Tests

  • New packages/spec/src/define-stack-non-strict-actions-shape-refusal.test.ts: 16 cases — each malformed shape at both sites asserts code + status + issue paths + invalid_type/expected; strict-door parity; controls (well-formed arrays merged and ordered by order, absent and empty actions accepted).
  • Ablation (fix removed by restoring stack.zod.ts from base, test imports src directly so no dist leg): 11 failed / 5 passed (5 bare-TypeError rows read code undefined, 6 falsy/entry rows were accepted); the 5 greens are the strict-door and control cases. Restore proven by git hash-object equal to the HEAD blob and an empty git diff HEAD.
  • pnpm --filter @objectstack/spec test: 519 files passed / 1 skipped, 15249 tests passed. pnpm --filter @objectstack/spec typecheck: exit 0 (test-layer debt held).
  • dispatch-gates.mjs --commands: 82 derived, 80 exit 0, 2 NOT MEASURED (exit 3 PREREQUISITE NOT MET — check:dual-build-cjs-loads and check:type-check-debt need the whole workspace built; CI's).
  • eslint (narrowed): the 2 touched TS files, --format json count 2, 0 errors / 0 warnings; eslint.config.mjs never enables type-aware linting, so this diff cannot move any untouched file's verdict.

Acceptance notes

  • composeStacks also ends in this merge, so a hand-built input stack whose actions (top-level or on an object) carries a non-object entry such as 5 is now refused at step 7 with the same code instead of being carried into the artifact. The step-3 comment ("a non-object entry is concatenated as-is") still describes step 3 itself.
  • Out of scope, reported to the seat for filing: composeStacks over two stacks still raises a bare TypeError before step 7 for a top-level actions: [null] (reading objectName), an object's actions: 5 (.entries is not a function) and an object's actions: [null] (reading name) — in collectComposedActionKeyCollisions, outside this card's file surface.

Generated by Claude Code

@github-actions github-actions Bot added size/m documentation Improvements or additions to documentation tests tooling labels Sep 23, 2026
@github-actions

Copy link
Copy Markdown
Contributor

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see
  • the SDK route bridge reached 60 of 215 client-bound route-ledger rows — the other 155 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 155: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 100 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
  • a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
  • a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 136 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 6eaa0f4a81a0146250f083df2b9d000b75dbec61 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from d4161be8ca70cfc550c547d4b1d8ddae7beaec18 — the merge of head 1a108852475fa4d5837b41b38abe77eaf567bb1d into base 6eaa0f4a81a0146250f083df2b9d000b75dbec61, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin d4161be8ca70cfc550c547d4b1d8ddae7beaec18 && git checkout d4161be8ca70cfc550c547d4b1d8ddae7beaec18
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 6eaa0f4a81a0146250f083df2b9d000b75dbec61 1a108852475fa4d5837b41b38abe77eaf567bb1d && git checkout -B drift-repro 6eaa0f4a81a0146250f083df2b9d000b75dbec61 && git merge --no-ff 1a108852475fa4d5837b41b38abe77eaf567bb1d

node scripts/docs-audit/affected-docs.mjs --json 6eaa0f4a81a0146250f083df2b9d000b75dbec61

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

@objectstack-fleet

Copy link
Copy Markdown
Contributor Author

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 1a108852475fa4d5837b41b38abe77eaf567bb1d

① Derived judgments

  • The strict door (ObjectSchema.actions and the top-level actions are both z.array(ActionSchema).optional()) refuses every shape at exactly the claimed paths — 5 / 'abc' / null / false → expected array at ['actions'] and ['objects', 0, 'actions']; [null] / [5] / [[]] → expected object at ['actions', 0] and ['objects', 0, 'actions', 0]; STACK_SCHEMA_INVALID / 422. strict: false after the PR answers byte-identical code / status / path / expected on every shape at both sites; multi-site findings arrive in one refusal.
  • undefined and [] accepted (unchanged); top-level {} normalized to [] on BOTH doors (parity, not widening); object-level {} refused on both.
  • Base measured: [5] returned inside a success, null handed on, [null] / 5 bare TypeErrors ⇒ every change narrows; nothing previously refused is accepted.
  • Guard runs after fix(spec): defineStack strict:false refuses a non-array objects with an ADR-0112 envelope #19798's objects guards and before both sortActionsByOrder calls; every caller (non-strict defineStack, post-parse strict path — cannot newly fail, composeStacks step 7) unchanged on well-formed input. Reuses fix(spec): composeStacks refuses a non-array concatenated collection instead of dropping its content #19794's describeNonArrayCollection; the hunk is 57 pure additions — fix(spec): defineStack strict:false refuses a non-array objects with an ADR-0112 envelope #19798's refusals and messages untouched.
  • Tests: new file 16/16; sibling precedent files 178/178; ablation 11 failed / 5 passed as claimed.
  • Minor prose imprecision (non-blocking): the changeset says a falsy non-array was 「handed on untouched」 — only null was; false threw. Still a narrowing.

② Semver level

Changeset minor + BREAKING + adr-0087: not-required (no-migration-prescription) + Clause-②: no (narrowing) — canonical. The PR BODY's line read no — narrowing: … (the seat's own claim spelling): readClause2Line gives arm null, so check-changeset-no-major took its not-declared branch (exit 0, level axis stood down). ⇒ the seat corrected the PR body line to Clause-②: no (narrowing) after this review (read back: arm narrowing).

③ Boundary flags

Implemented-by: claude/issue-19799-merge-actions-actions-shape
Reviewed-by: session_01VWsFyWDp8Rjb2Ma6a3Cyo8

VERDICT: PASS

Rendered by an isolated at-tier review subagent, adopted by domain:spec seat 4 after re-reading the finding's site on origin/main and re-running readClause2Line on the corrected body line. Checks at review time: 14 success, 3 skips, 15 in progress, 0 failed — landing waits for every check green.


Generated by Claude Code

@objectstack-fleet
objectstack-fleet Bot marked this pull request as ready for review September 23, 2026 08:40
@objectstack-fleet
objectstack-fleet Bot added this pull request to the merge queue Sep 23, 2026
Merged via the queue into main with commit c1dfa52 Sep 23, 2026
44 checks passed
@objectstack-fleet
objectstack-fleet Bot deleted the claude/issue-19799-merge-actions-actions-shape branch September 23, 2026 09:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation size/m tests tooling

Projects

None yet

1 participant