Kanban card identity and configuration recovery

Kanban can bind a named array of card records. Every editable row needs a unique id containing nonempty text or a safe integer. The id identifies the card across reordering; text "1" and integer 1 identify different cards. Arrays without suitable ids remain readable. Grid does not assign positional ids back to the source. Native-table cards continue to use their native record identities.

Card editing requires a host with input commit receipts. Each write compares the last acknowledged array revision, preserves unrelated record fields, and accepts only the same binding's ready, advancing receipt with matching content. Record property order may change; array order and scalar types must match. Card changes stay visible while saving. A failed or uncertain save retains the local copy, pauses further writes and provides Export card copy, explicit Retry card save, and confirmed Load saved cards. Reopening the same session does not replay an uncertain save. A model, account, partition or binding change admits a separate owner; anonymous previews do not share drafts by their surface name alone.

Use Add a card to create a named-array card in a list. Grid assigns a new stable text ID and writes the mapped title/list fields; existing records and their metadata survive. Drag to place cards within or between lists, or use Control/Command with Up/Down to reorder and Left/Right to change lists. Order is the source-array order, shared with other views of that array. Invalid or full proposals refuse before a write; a refused create keeps the title in its composer. Failed acknowledged creates and reorders retain the complete local array. Card detail mappings must be distinct and cannot replace id or reserved keys.

Named-array editing is bounded to 5,000 records and 8 Mi JSON characters. Display projection is not an edit basis: non-record members, unsupported typed values, reserved metadata keys, excessive nesting and any source that cannot round-trip through the supported input encoding remain read-only. Repair those sources in Code or use the native-table workflow. The existing source is never replaced by a partial projection.

In the workbench, open Card activity settings and enable activity with a separate property. For native tables, choose an existing separate text column; add that column in Table first if needed. Saving settings changes only the acknowledged board configuration, never card data. Changing or disabling the mapping preserves the former property and files without migrating history. The setup refuses mapped-field collisions and unreadable local/array activity. Run and print views do not expose this authoring control.

Map items.activity to a separate JSON-text property to enable conversation, file references and retained history on named-array cards. The mapping must not reuse id or a mapped title, list, assignee, labels, due date, description or color field. Missing activity starts empty; malformed or full activity keeps the source readable and refuses edits without replacing it.

Activity for … opens the card's conversation and attachments. Uploading stores bytes in the workbook's Files; Attach uploaded file saves the reference through the same acknowledged array writer as card edits. An uncertain upload retains its reference for explicit byte verification. Removing a reference leaves the file in Files. Download checks size and SHA-256. The limits are 25 MiB per file and, per card, 100 references, 500 comments, 1,000 history events and 1 MiB of activity JSON. No history is silently trimmed.

Card moves, reorders and completed detail edits retain before/after source field values. Detail typing stays local until Done, producing one event for the completed edit. Comments and attachments preserve existing history and unknown activity metadata. History begins when activity is enabled and covers Kanban changes; names are unverified display labels, times come from the author's device and comments send no notifications. Card deletion removes its activity, so export a copy to keep it. Print includes all retained activity for array cards without editing controls. See the array activity example.

Column configuration uses its own confirmed source writer and recovery controls. A save compares both configuration revision and exact authored preimage. An uncertain save preserves local setup; export both versions before deciding to load the saved configuration or deliberately replace it. This owner is separate from card data and activity. Deleting a populated list preserves every card with its stored list id under Unmapped cards; deliberately assign a configured list there. Failed configuration saves do not delete card data.

Array recovery in this increment is session-local. Configuration recovery uses the existing device-local source journal where the host supports it and reports storage failures. Neither is a substitute for an acknowledged model save. Native persistence, a fresh-process array recovery journey and packaged-app latency remain separate verification work; the retained local evidence is in Document/Kanban evidence.