lint `relationship/delete-behavior` suggestion still names `set_null` as declarable on a master_detail — a spelling #9689 makes a parse-time rejection

[os-warren]

Filing unassigned — recording, not claiming. Found during the #9689 R3 patch round's consumer sweep; same class as #11409 (skill docs) and #11410 (field designer form), but a third distinct surface with its own fix site, so it gets its own card rather than riding either.

Measured

packages/lint/src/data-model-rules.ts (rule relationship/delete-behavior, severity suggestion):

if (def.deleteBehavior === undefined) {
 issues.push({
 severity: 'suggestion',
 rule: 'relationship/delete-behavior',
 message: `master_detail "${obj.name}.${fieldName}" → ${parent} should declare deleteBehavior (cascade/restrict/set_null)`,
 path: `${fieldPath}.deleteBehavior`,
 fix: "deleteBehavior: 'cascade'",
 });
}

The message enumerates set_null as one of the three values an author may declare on a master_detail. Since PR #11406 (#9689, maintainer ruling 2026-08-19), an authored deleteBehavior: 'set_null' on a master_detail is a named parse-time rejection — so this suggestion, followed literally, walks the author into a publish-time error. The fix payload ('cascade') is fine; only the message enumeration is stale.

Note the rule itself is healthy and unaffected by #9689's idempotent-materialization change: it consumes RAW authored objects (lintDataModel(objects: any[]) — verified from packages/cli/test/data-model-rules.test.ts, which passes raw literals), where absent has always meant "not authored".

Suggested shape (not prescribing)

Message becomes (cascade/restrict) for master_detail, possibly with the same outcome-naming courtesy as the #9689 rejection message (set_null is not honored on this type; use a lookup if children must survive the parent). One string edit plus its test.

Refs: #9689, PR #11406, #11409, #11410.

---

Generated by Claude Code

[os-zhuang]

Triage: lands in packages/lint (the relationship/delete-behavior suggestion text) → domain:devx, type Task, pm:blocked.

Blocked-by: #9689

Rationale: the spelling this suggestion names becomes a parse-time rejection only when #9689 lands (in flight, pm:blocking, incremental redo via its PR), and that PR's sweep obligation may fix this very string. Unlock action: on #9689's close, grep the suggestion text on the merged ref — if the string survives, this is a one-line text fix inheriting #9689's ruled vocabulary; if it's gone, close as absorbed. ⛔ Do not fix ahead of the landing: the lint suggestion is currently true (the spelling still parses today), and flipping it early would make the lint lie until #9689 merges.

---

Generated by Claude Code