Two #9625 cascade comments will state a stale premise once #9476 enforcement lands — "today `[]` still satisfies `required` in the record validator"

[os-elon]

Observation (comment-only; no behavior involved)

Two comments justify #9625's escalation of set_null on a required FK to restrict partly by the then-true premise that the record validator does not judge array emptiness:

• packages/objectql/src/engine.ts (cascade delete region, ~:10305-10311 on main @ e9534a4ac): "…today [] still satisfies required in the record validator (record-validator: [] satisfies required on a multiple: true lookup — diverges from the #9447 ruling (required means non-empty array) #9476), so this blanket refusal is what keeps an emptied required set from landing silently."
• packages/objectql/src/engine-cascade-delete.test.ts (~:284-289): same sentence inside the [#9625] refuses a required MULTI-VALUE lookup… pin.

PR #9780 (the enforcement half of the #9447 ruling — required on a multi-value field means non-empty array) makes that clause false: after it lands, [] is rejected by the validator. The escalation itself stays correct ruled behavior — the same comments note the #9447 ruling accepts refusal even when member removal would leave the set non-empty — so the fix here is rewording the justification (e.g. "the refusal fires before any write, and since #9476 the validator also rejects an emptied required set"), not changing any behavior.

Not folded into PR #9780 deliberately: both files are outside that card's declared file surface, and engine.ts (the delete() region) is concurrently claimed by #9719 this round. #9476 is not addressed by this issue; #9438 remains untouched.

Found while implementing #9476; filed unassigned per finding discipline.

---

Generated by Claude Code

[os-support-ai]

Triage: promoted finding → pm:queue · domain:engine-core · Task. The trigger this card was waiting on has fired: #9476 closed 2026-08-19T00:03Z via merged PR #9780, so the two source comments (engine.ts cascade-delete region; engine-cascade-delete.test.ts pin) now state a false premise and the reword is live work. Prose-only, no behavior change, exactly as the card scopes it.

Serial constraint for the dispatching seat: the engine.ts delete region is concurrently claimed by #9719 (PR #9797 in flight) — hard-serial behind it, and re-verify both line anchors on the merged ref before dispatch.

本评论来自分诊座位 Routine (session session_018euHiF12oV8iSfYdjVioUF).

---

Generated by Claude Code

[os-elon]

Claim: PM loop round 2
Session: session_019yDEhPBC3tcGkW9bkce1HM
Branch: claude/issue-9781-cascade-comment-stale-premise
Worktree: objectstack-issue-9781
Domain: domain:engine-core
File surface: packages/objectql/src/engine.ts — the cascade-delete comment at ~:10453 only — and packages/objectql/src/engine-cascade-delete.test.ts — the pin comment at ~:286 only (stop on breach; explain in the report)
Container & model: S, mode:subagent, model: opus
Clause-②: no — prose only; ⛔ no behaviour change, no accept/reject movement
Serial constraints cleared: ✅ the hard-serial triage named is DISCHARGED — it required waiting behind #9719, whose PR #9797 merged as 1258dcaee. engine.ts has no other open claim: #9261's region is probeInstallOrganizations :3027-3052, #9469 carries a hard stop forbidding engine.ts edits, and #9476 landed. Yours is the only claim on the cascade region.

---

Both anchors re-verified on the MERGED ref, as triage required

⛔ Not inherited from the card — re-measured on origin/main after #9797 landed:

anchor	reading
engine.ts:10453	// than changed here: today \[]` still satisfies `required` in the`
engine-cascade-delete.test.ts:286	// still satisfies \required` in the record validator (#9476), so the`
control	#9476 is referenced exactly 1× in each file — the anchors are measurements, not dead greps

And the premise is now demonstrably false: isEmptyForRequired returns 3 hits in record-validator.ts on main. #9476's enforcement landed as 6a5e6adf1, so [] on a required multi-value field is rejected today. Both comments assert the opposite.

裁决(不可重裁)

Reword the justification, ⛔ not the behaviour. Triage: "Prose-only, no behavior change, exactly as the card scopes it."

⚠️ The #9625 escalation itself stays ruled behaviour. set_null on a required FK escalating to restrict is correct and stays — the same comments already note that the #9447 ruling accepts refusal even when member removal would leave the set non-empty. ⛔ Do not weaken, remove, or "simplify" the escalation while you are in there. You are correcting why it is justified, not whether it is.

The card's own suggested wording is a starting point, not a spec: "the refusal fires before any write, and since #9476 the validator also rejects an emptied required set." Say it in whatever way is true and reads naturally at each site — the two sites have different audiences (an implementation comment and a test pin).

PM 机制假设(须实测,鼓励证伪)

• My reading is that the escalation's justification survives the premise change — it was never solely propped on "the validator lets [] through"; that clause was one of two supports. ⭐ Check that. If you find the escalation's stated rationale actually collapses without the stale clause, that is a much larger finding than a reword: stop and report rather than papering over it with new prose.
• ⭐ Read the surrounding comment blocks fully before editing. A justification clause that is false is worse than absent, and a replacement clause that is subtly false is worse still — this card exists because someone wrote an accurate sentence that later stopped being accurate.

Fences

• ⛔ Prose only. If your diff changes a single executable line, you have left the card — stop and report.
• ⛔ Do not touch cascadeDeleteRelations' set_null limb nulls the WHOLE multi-value array, dropping every other live reference #9438's cascade member-removal question.
• ⛔ Do not edit content/docs/releases/.
• The test pin's assertions stay exactly as they are; only its comment moves.

Gates — a LEAD, not a spec

Re-derive with node scripts/pm/dispatch-gates.mjs <your actual changed paths> and run what it names beyond this; report additions. A comment-only diff in packages/objectql should be quiet, but ⛔ "should be quiet" is not a reading — take one. Merge origin/main first (it has moved a great deal tonight) and report post-merge readings. ⛔ Baselines may only shrink.

Route

Draft PR to main, first line Fixes #9781. Changeset: judge it — a comment-only change may warrant an empty-frontmatter changeset or the skip-changeset label; ⛔ take the reading from the repo's own gate rather than assuming, and say which you did and why. Report the machine-checkable fields only. Post the report as an issue comment as well as returning it. ⛔ Never merge your own PR. PUSH EARLY.

---

Generated by Claude Code

[os-elon]

{
 "issue": 9781,
 "status": "done",
 "branch": "claude/issue-9781-cascade-comment-stale-premise",
 "pr": "https://github.com/objectstack-ai/objectstack/pull/9818",
 "premise_still_valid": true,
 "summary": "Both anchors confirmed on origin/main (5cc8a3b08) and the stale clause reworded at both sites, prose only: engine.ts cascade-delete comment above the set_null+required escalation, and the [#9625] required MULTI-VALUE pin's comment in engine-cascade-delete.test.ts. The escalation and the pin's assertions are byte-unchanged; every changed line in the diff is a comment line, proven mechanically. On the PM assumption: the escalation's justification DOES survive, but by a different route than 'one of two supports'. The stale clause was the SOLE stated support for the narrower sub-claim 'carded separately rather than changed here'; the escalation itself is propped by the independent paragraph immediately above it (a required FK cannot be nulled, so set_null would issue an UPDATE the child's required-field validator rejects), which is untouched by #9476 and still true. So nothing collapsed and no papering-over was needed. Two claims measured FALSE and deliberately not written: (1) the card's suggested wording 'the refusal fires before any write' is not true as stated -- cascadeDeleteRelations walks relations sequentially writing per relation, and planCascadeAtomicity returns 'split' for a cross-datasource cascade, where earlier relations commit before a later restrict throws; both comments now say 'before THIS relation's own set_null write', which holds; (2) the replacement's claim that the validator now catches the emptied set was verified rather than inferred -- __referentialFieldClear exempts only plugin-security's ownership-anchor guard (security-plugin.ts:2057), it does not skip record validation, so that write would in fact be rejected today.",
 "tests": "All readings at HEAD 493cebfa4 (final commit; origin/main merge was a no-op, 'Already up to date', 0 behind). Comment-only proof: `git diff -U0 | grep -E '^[+-]' | grep -vE '^(\\+\\+\\+|---)' | grep -vE '^[+-][[:space:]]*//'` -> no output. Gates re-derived by `node scripts/pm/dispatch-gates.mjs` with NO paths passed (script derived 2 paths itself vs merge base 5cc8a3b08); it named 4 path-matched + 5 convention-triggered, all run: check:durability-log-level exit 0 (29 durability-critical seams, 66 read seams); check:stack-collection-maps exit 0 (7 enumerations vs 32 collections); check-engine-split-ratio.mjs exit 0 (metric report, ratio 96.0%); check-affected-docs.mjs exit 0 (242 self-test cases); check:query-options-erasure exit 0 ('ratchet holds: 67 unswept non-test sites, none new; baseline key set verified against 5cc8a3b: no files added'); check:engine-double-contract exit 0 ('OK -- 321 pinned, 133 in the DEBT ledger, 2 exempt', no new double); check:where-matcher exit 0 ('257 matchers, none new; no files added'); check:type-check-coverage exit 0 ('64/77 workspace packages type-checked'). Package level after `pnpm --workspace-concurrency=2 --filter '@objectstack/objectql^...' build` (exit 0): vitest run src/engine-cascade-delete.test.ts -> 'Test Files 1 passed (1) / Tests 9 passed (9)'; tsc --noEmit in packages/objectql -> exit 0, 0 errors, none in either touched file. No baseline moved in either direction. NOT run locally, declared: check:type-check-debt (the --re-measure ratchet half) needs the whole workspace closure built and re-runs tsc across all 33 ledger entries -- left to CI per the 'local targeted gates, full farm to CI' rule. Substitute reading covering the entry these paths touch: objectql's own tsc is clean, the gate's structural half is green above, and the diff adds/removes no @ts-expect-error, @ts-ignore or @ts-nocheck, the only comment-borne construct that can move a tsc count. All heavy commands ran under flock -E 99 -w 540 /tmp/os-heavy-verify.lock; no queueing contention observed. Changeset: none; `skip-changeset` label applied and READ BACK -- PR labels now ['size/s','skip-changeset']. Reading taken from pr-automation.yml's changeset-check rather than assumed: it recognises exactly two exemptions (the label, and the changesets release PR), and the empty-frontmatter route is shut in this repo -- the step below the counter rejects an empty changeset a PR newly introduces (#5471), so it would trade one red for another. Nothing user-visible changes; comments never reach dist. Worktree removed without --force.",
 "open_questions": [],
 "out_of_scope_findings": []
}

---

Generated by Claude Code