Repository navigation
DataSource.deleteView's declared return is still the narrow { deleted } — consumers through the shared interface cannot see the per-home outcomes #4479 added #4564
Description
Activity
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:
DeleteViewResult+ViewHomeDeleteOutcomemove to packages/types/src/data.ts beside the interface;DataSource.deleteView?'s declared return widens toPromiseofDeleteViewResult; 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).- 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.
- 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.
- 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
- added a commit that references this issue
on Aug 13, 2026
Metadata
Metadata
Assignees
Labels
No labels
Follow-up accepted from #4479 / PR #4562's consumer census, filed for the pool (unassigned).
The gap: PR #4562 widened the ObjectStackAdapter's
deleteViewto returnDeleteViewResult { deleted, draft?, published? }(exported from @object-ui/data-objectstack). Butpackages/types/src/data.ts:538still declares the shared interface method asdeleteView?(objectName, viewName): Promiseof 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 onlydeleted, 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/ViewHomeDeleteOutcomeshapes 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