Add design corpus and wishlist

Twelve design docs (00-vision through 11-command-nexus) plus assets and
the wishlist, authored ahead of implementation.

Claude-Session: https://claude.ai/code/session_018BjQRYBR6jQja3jCRi5S3A

WISHLIST.md

@@ -0,0 +1,25 @@
+# Lanework — Feature Wishlist
+
+> Ideas worth developing further, deliberately outside the current design scope. Items get recorded as they come; grooming happens later. The DESIGN/ documents hold the committed design — nothing here is committed.
+
+## Items
+
+### 1. "While you were away" digest
+
+A human-facing digest of what changed on a board since the user last looked, derived from the git trail (commit messages already describe every settled change, agent and human alike). The read-ritual half of the masterplan pattern (DESIGN/08-agent-integration.md): agents file cards at near-zero friction all week; the digest is how the human catches up and stays honest about the plan. Sketch: on opening a board (or in the board popover), "since you last opened: 4 cards added by claude-code, 2 moved to Done" — clicking through highlights the affected cards. Requires git-enabled boards; another reason the git trail is the substrate of record.
+
+### 2. In-app shortcut recorder pane
+
+A Settings ▸ Shortcuts pane with a per-command recorder, writing the same `NSUserKeyEquivalents` mechanism the committed system-native remapping uses (DESIGN/04-interactions.md ▸ Configurable bindings) — so menus would keep showing effective bindings either way. Set aside as ceremony: System Settings ▸ App Shortcuts already covers remapping completely because every command is a menu item. Revisit only if users demonstrably don't find the system path.
+
+### 3. Move cards to another lane before deleting a lane
+
+An explicit "Move cards to…" action (context menu on a lane) that relocates a lane's cards to a chosen lane in one gesture. The old lane-delete confirmation dialog offered this as a delete intercept; the trash design replaced the dialog with a plain recoverable tombstone (DESIGN/04-interactions.md), so the relocation convenience — if ever wanted — should return as a deliberate standalone action, not a prompt.
+
+### 4. Restore a card version from its History section
+
+The card window's History section (DESIGN/05-card-window.md) is read-only in v1. A per-row "Restore this version" would forward-restore the card folder at that commit (a new commit — "Restore card 'X'" — never a rewrite, per DESIGN/06-history-undo.md). Needs design: attachments at the old version, versions that lived in another lane, interaction with the trash and the undo stack.
+
+### 5. Lane history
+
+Per-lane commit trail, the lane sibling of the card History section. Undecided whether it's wanted at all (a lane's own commits — rename, restyle, resize, reorder — are sparse; most of what changes "in" a lane belongs to its cards) and where it would surface, since lanes have no window.