DR-062 — "Compose existing backend only" is not a binding constraint; new backend is feasible where it serves the deliverable

Owner ruling S470: the “thin UI composes existing backend, no new promotion backend” framing (id-145 BI-38) is incorrect as a hard constraint — new backend endpoints are feasible where they deliver the intended behaviour. Generalises: a Checker must not FAIL a subtask solely for adding backend when the behaviour requires it — prefer the correct backend over a compose-only workaround. (The checker doctrine’s scope-containment blocker carries no such carve-out, which is why this stays a live register rule; exercised in anger at S481.)

(Swept unrecorded at ec9fcfde; re-accepted by owner ruling S499 — the S499 tombstone audit found it still binding with no other home.)

Action-site homes (S504 owner ruling, re-home + keep): the carve-out is stated in BOTH checker surfaces — canonical:.dev-workflow/sdlc/.claude/agents/task-checker.md (Claude Code path) and canonical:.claude/agents/intent-specialists/verifier.md (Intent path — a tracked REFERENCE REPLICA since S507; the live agent runs inside the Intent UI, so re-apply the carve-out there too after any upstream refresh). This entry stays the ADR of record.