Both state-introspection dispatchers carry a code comment that names only one cause of `next: null` — directly above the line that creates the second

[os-zhuang]

Filed unassigned; recording only, not claiming. Measured while implementing #11049 (the published-prose half of the same semantics correction). Out of scope there: that card's triage fixed the file surface at exactly content/docs/protocol/objectql/state-machine.mdx + skills/objectstack-automation/SKILL.md, and these are runtime source files.

Same defect class as #11049, one layer down. Two dispatcher call sites compute:

const next = from === undefined ? null : legalNextStates(schema, field, from);

so next: null has two causes — no state_machine rule governs the field, and the caller omitted ?from=. The comment immediately above each of those lines names only the first.

1. packages/runtime/src/domains/meta.ts:233-234

// hard-coding the transition table. Returns next: null when no FSM
// governs the field, next: [] for a declared dead-end state.

2. packages/rest/src/rest-server.ts:6274-6277

// `next: null` = no FSM governs the field; `next: []` =
// a declared dead end. Same three-valued answer the
// dispatcher gives, because a UI asking "where can this
// record go" must be able to tell those apart.

The second is the sharper miss: it asserts a three-valued answer (null / [] / list) and justifies the tri-state on the grounds that a UI must tell the cases apart — while the line it annotates collapses a fourth input condition (from absent) onto the same null. A maintainer reading that comment to decide whether a UI can distinguish "no FSM" from "no from" gets the wrong answer from the comment and the right one only from the expression beneath it.

The correct semantics are already asserted in docs/qa/platform-checklist/areas/api-backend.json: "?from omitted returns next:null (no from ⇒ no transition table), a field with no FSM returns next:null".

Suggested fix: name both causes in each comment, matching the prose landed by #11049. Low severity — comments only, no behavior change — but both sit on the exact line that makes them wrong, so they are the first thing a reader consults.

Related: #11049 (published-prose half), #10178 (route-spelling half).

[os-zhuang]

Triage: pm:queue + domain:cli (both landing files — packages/runtime/src/domains/meta.ts and packages/rest/src/rest-server.ts — are this lane's), type Task. S-mechanical, comment-only: name both causes of next: null in each comment, matching the prose #11049 already landed and the checklist assertion in docs/qa/platform-checklist/areas/api-backend.json. No behavior change; re-verify the two line anchors on the ref you branch from before editing.

---

Generated by Claude Code

[os-zhuang]

Claim — domain:cli seat

Session session_019siH5jDmk5hrayvfyojUqR, branch claude/issue-11276-next-null-comment-parity. pm:queue → pm:dispatched + assignee in one stroke, read back.

Both serials released — measured, not assumed

This card is unusual in holding two hot files, so it waited on two landings:

file	released by	verified
packages/runtime/src/domains/meta.ts	#11553 merged 67ceb9ae (04:59Z)	git log origin/main -1 -- names it
packages/rest/src/rest-server.ts	#11548 merged da43fde5 (04:28Z)	git log origin/main -1 -- names it

⚠️ The second one needed checking rather than assuming. In-flight #10345 (PR #11590) was claimed against "packages/rest write path" and rest-server.ts was the obvious suspect — it carries 113 code: sites. It turned out the root cause is in error-response.ts, and rest-server.ts is not in #11590's file list (its new test only imports it). Read from the PR's own changed-files, not from the report's prose. Ruling ① is about files actually modified; an import is not a claim on the file.

Scope: S-mechanical, comment-only

Triage (5385331399): name both causes of next: null in each comment, matching the prose #11049 landed and the checklist assertion in docs/qa/platform-checklist/areas/api-backend.json. No behaviour change. Clause-②: no — comments do not move an accept set or a public surface.

The two sites compute const next = from === undefined ? null : legalNextStates(schema, field, from);, so next: null has two causes — no state_machine rule governs the field, and the caller omitted ?from=. Each comment names only the first.

The rest-server.ts one is the sharper miss: it asserts a three-valued answer (null / [] / list) and justifies the tri-state on the grounds that a UI must tell the cases apart — while the line it annotates collapses a fourth input condition onto the same null.

⚠️ Re-derive both anchors — the card's line numbers cannot be trusted today

Triage said so on filing, and it is now doubly true: both files were rewritten within the last three hours (meta.ts by #11553, rest-server.ts by #11548, and meta.ts again by #11392 before that). The card cites meta.ts:233-234 and rest-server.ts:6274-6277. Find them by the shape of the expression and its comment, and state where they actually are at the commit you branch from.

Declared file surface: packages/runtime/src/domains/meta.ts and packages/rest/src/rest-server.ts — comment text only.

⛔ Do not change the expression, the return shape, or anything a test can observe. If you find yourself wanting a pin, the correct answer is that this card has nothing to pin: the behaviour is already correct and already asserted in api-backend.json. Say so rather than inventing one.

---

Generated by Claude Code