DataSource.deleteView's declared return is still the narrow { deleted } — consumers through the shared interface cannot see the per-home outcomes #4479 added

[yinlianghui]

Follow-up accepted from #4479 / PR #4562's consumer census, filed for the pool (unassigned).

The gap: PR #4562 widened the ObjectStackAdapter's deleteView to return DeleteViewResult { deleted, draft?, published? } (exported from @object-ui/data-objectstack). But packages/types/src/data.ts:538 still declares the shared interface method as deleteView?(objectName, viewName): Promise of the narrow { deleted: boolean }. The adapter's wider return is assignable, so nothing breaks — but a consumer reaching the adapter THROUGH the shared DataSource interface sees only deleted, not the per-home outcomes. Today's single real call site (ObjectView's handleDeleteView) reads nothing, so the gap is latent.

Design question the card carries (dependency direction): data-objectstack depends on types, not vice versa — so the widened shape cannot be imported downward. Either (a) the canonical DeleteViewResult/ViewHomeDeleteOutcome shapes MOVE to packages/types (data.ts), with data-objectstack importing and re-exporting them (entry-reachable growth in both packages ⇒ minor/minor; re-export keeps existing importers compiling), or (b) types re-declares the shape structurally (duplication the one-resolver rule dislikes). (a) looks right; the dispatch should measure whether anything else imports the data-objectstack spellings before moving them.

Small card: types + data-objectstack, one interface line + a type move + pins that the adapter still satisfies the interface and existing importers still compile. Refs: #4479, PR #4562.

---

Generated by Claude Code

[yinlianghui]

CLAIM — session_017Qqyix2QcnpUC9XeYVDzx3, branch claude/issue-4564-deleteview-interface-shape. Dispatching a dev agent now.

PM ruling (delegated decision authority; maintainer veto window open — record objections here): option (a) as the card leans — the canonical shapes MOVE to packages/types:

1. DeleteViewResult + ViewHomeDeleteOutcome move to packages/types/src/data.ts beside the interface; DataSource.deleteView?'s declared return widens to Promise of DeleteViewResult; data-objectstack imports the types and RE-EXPORTS them under the same names so every existing importer keeps compiling byte-compatible (pin: an import of either name from @object-ui/data-objectstack still resolves and is identical to the types spelling).
2. Measure FIRST whether anything beyond data-objectstack's own suite imports the current spellings (grep repo-wide) — each importer pinned at its read; expected zero given PR fix(data-objectstack): deleteView removes every home the view has — draft-only, published, and pairs (#4479) #4562 just landed them.
3. Pins: the adapter still satisfies the interface (a type-level assertion, not just compilation-by-accident); the widened interface's optionality unchanged; fix(data-objectstack): deleteView removes every home the view has — draft-only, published, and pairs (#4479) #4562's 15 deleteView pins green untouched; the one real call site (ObjectView handleDeleteView) compiles unchanged.
4. Changesets: '@object-ui/types' minor (entry-reachable interface + type growth), '@object-ui/data-objectstack' patch-or-minor per its measured .d.ts (a re-export swap should be declaration-identical — if byte-identical, patch; say which). Never major.

Sequencing: gate worktree creation on PR #4562 reaching origin/main (armed on green CI — foreground git-log polling). Mutual exclusion: ⛔ #4548 in flight (packages/react + repo-wide canary) — types/data.ts is not its expected surface but if it moves mid-run, re-fetch and recreate rather than race; #4553-p2 (fields/gantt), #4305 (app-shell flow) disjoint.

---

Generated by Claude Code

---

Generated by Claude Code