Delete Is a Folio Fact, Not a Placement

Decision

Owner ruling, 2026-09-04 (decision-12). This is an implied invariant of the Folio model as already built, stated so nobody redesigns it: deletion is a Folio-level fact (folios.deletedAt); placement is a separate fact on the pin; Remove is the placement operation; sealed versions are immutable history; ordinary live search runs over active Folios.

1. A deleted Folio is omitted from the live canvas. No greyed-out deleted card on the normal drafting canvas.
2. Older sealed editions are untouched and continue to render any deleted Folio they pinned.
3. Delete is not Remove. Delete is never redefined as a placement mutation.
4. The live pin may stay intact after Delete, so Put back restores the Folio to the same position without reconstructing placement.
5. When a later parent version is sealed, deleted children are not included in that newly sealed schedule. Older sealed schedules are never altered.
6. Deleted Folios are excluded from future search and discovery results. Any surface that returns ordinary active Folios filters deleted ones out by default.
7. Deleted items appear only in a dedicated Deleted or restore context, if and when one is built. This record does not open that work.

In plain terms: striking a clause from the working file takes it off the page you are drafting on and out of the index, but the signed versions that included it are not touched, and the file keeps its place-marker so "put it back" returns it to the same spot. Striking is not the same as moving it to another file, which is Remove.

Menu grouping, 2026-09-08 (superseded 2026-09-09)

The shared Folio menu grouped the two intentions under Remove. The flyout labelled them Remove from module/document and Delete folio, separated by a rule. Only Delete folio received destructive styling.

One Delete on the card menus, 2026-09-09

Owner ruling: the block, module and Document card menus offer one Delete row and no "Remove from module/document". Delete keeps the meaning above: a recoverable Folio fact, never a purge. A sealed edition of the parent still shows the deleted child; only the live draft omits it, and Put back returns it. The reason for dropping detach from the menus is that a detached folio was left with no parent showing it and nothing in the product surfaced it afterwards. The remove operation, its catalogue row and its executor (arrangementWrites.ts) stay for the Library's "Remove from Library" (library-is-a-shelf, point 15); the card menus simply bind no handler to it.

In plain terms: the menu now has one way to take a clause out of the working draft, and it is the reversible one. The signed versions that included the clause are untouched.

Verified against the tree, 2026-09-04

• convex/folio/lifecycleWrites.ts writes and clears deletedAt only; no pin is touched. Its test asserts the row is "its former self plus exactly deletedAt". Consistent with points 3 and 4.
• convex/folio/snapshot.ts does not skip deleted children: the live canvas still shows them with a Put back row. That is the gap point 1 closes, and no test asserts the contrary.
• convex/folio/versionWrites.ts seals a deleted child still on the schedule with the rest, and its header says so. Point 5 reverses that: the sealed schedule omits the deleted child's pin, the fresh head keeps it, and the deleted child's own draft is not sealed by the cascade. GB-190.
• convex/folio/recentReads.ts already drops deleted Documents from the recent list (tested). No search index exists yet; GB-54 gates the first search work and now carries point 6 as a criterion.
• Nothing in the tree shows a greyed deleted card on the canvas.

Consequences

• Stage D composition writes (settled constraint 23): the canvas omits deleted children, so a before or after anchor names a visible sibling; the deleted child's pin stays where it is, unseen.
• Save-time dedup: a deleted child that the baseline pinned counts as a schedule change, so the next save of the parent mints an edition without it. After that save the deleted child is still pinned on the fresh head and Put back still restores its position.
• Delete on a Document keeps working as a list fact on Document Home.

Revisit

Only when a dedicated Deleted or restore surface is designed; that is its own decision and its own task, and it does not reopen the points above.

Owned descendants — 2026-09-14

The owner refined deletion to include a container's owned descendants. Confirm with an explicit warning before deleting a Project or Document through its menu. The write follows parentFolioKey ownership, marks active descendants in the same transaction, and keeps saved editions. Restoring a container restores only rows with its deletion timestamp, preserving earlier independent child deletions. Document revision boundaries still apply when deleting from a Project page.