Lists: guard the destructive DSL rebuild vs the non-destructive properties edit

[Adron]

Stacked PR — 3 of 3

issue-22-destructive-guard → base issue-21-typed-row-editor (PR #163) → issue-18-column-builder (PR #161) → issue-17-list-schema-service (PR #143). Merge bottom-up: #143, #161, #163, then this.

What this adds

PUT /api/lists/{id}/schema is one route with two bodies whose consequences are nothing alike, so the column editor offers two clearly different actions — never one “Save schema” that quietly picks the destructive one:

Save columns → { properties: [ … ] }
Renames, adds, single removals and reordering, applied in place: column ids kept, row data kept, the list's own title and description untouched. It states its plan first — “Save columns adds 1, renames 1, deletes link, reorders the columns — in place, with every row's data kept.”

Rebuild columns… → { schema: { … } }
A separate, explicitly-labelled action behind an in-place confirmation (no native message box; nothing blocks the dispatcher) that names exactly what it costs:

• all N columns dropped and recreated with new ids;
• rows are NOT deleted — values whose key no longer has a column stay in each row, unshown and unvalidated, with the affected keys named;
• validation rules and visibility conditions survive only because the drafts re-send what they read — said plainly, including that anything added on the web since the editor opened does not;
• the list's title is overwritten, from an editable box pre-filled with the current title;
• the list's description is overwritten, and cleared if the box is blank.

When a draft can only go through the rebuild (any of the six richer types), the safe save refuses and points at the rebuild button by name instead of dead-ending.

Live evidence (probed today, 2026-09-16)

Driven with the bodies the real draft view-model serializes — a throwaway net10.0 console project <Compile Include>-ing the model and draft files by absolute path read the live list's data.properties[] and …/schema, built the drafts through ListColumnDraftViewModel.FromField, applied a rename + an add + a drop + a reorder, and emitted both bodies. Lists were titled ZZ claude-probe … and deleted; a closing GET /api/lists shows only the account's pre-existing New list.

	safe properties	destructive schema
rows	kept, ids identical	kept, ids identical
dropped column's values	stripped from every row (409 + propertiesWithData: ["link"] without ?force=true; 200 with it)	left in rowData as orphans
column ids	preserved	all new
list title	untouched	overwritten from schema.name
list description	untouched	overwritten — null when omitted

That asymmetry in the middle row is the one that is easy to get backwards, and it is why the two confirmations are worded differently: properties ?force=true deletes the value, a rebuild keeps it as an orphan. The rebuild confirmation deliberately never says “rows will be deleted”.

Verified in the same run: the safe save's 409 → confirm → ?force=true cycle; the title/description overwrite on rebuild; the description coming back null from a rebuild that omits it; and ListSchema.Validate() clean on the generated DSL.

Left unverified

• No WPF rendering check is possible from macOS. dotnet build passes in Debug and Release. The confirmation panel uses AmberBrush + Surface3Brush with 3px corners on the 4pt grid, but it wants eyes on Windows — along with the ComboBox and DatePicker noted in Lists: schema column form builder (12 field types) #161/Lists: typed, schema-driven row editor (replaces the freeform JSON box) #163.
• The rebuild is the only path for the six richer types, which means a list holding one can never be edited safely again. That is the API's constraint, not a UI choice — the type picker flags those types as “(rebuild only)” at the moment of the click (Lists: schema column form builder (12 field types) #161).
• Not touched here: per-column validation-rule editing (Schema: validation-rule editor + client-side row validation #19) and the conditional-visibility editor (Schema: conditional-visibility rule editor #20). The drafts carry both through a rebuild so those issues have something to build on.

Closes #22

🤖 Generated with Claude Code