@@ -0,0 +1,35 @@
+# This was cut from /home/gluck/dev/figaro-qua/main/plans/form-deltas-in-ui-ir.md for further review.
+
+______________________________________________________________________
+
+## 7. The fork-on-a-form bug, confirmed (same session, filed here for the same hand)
+
+`fig fork @form` births a **figaro**, not a forked form: verified live, the
+child is `kind=conversation` with `aria_id` and `system.forked_from` on its
+board. So `fork` and `bind` on a form are SYNONYMS and one of the two names
+is a lie.
+
+Cause, one line: `XwalStore.ForkWith` hard-codes
+`forkWithKind(..., kindConversation)`, while `forkWithKind`'s own comment
+says the caller chooses the child's species. The fork verb has no way to say.
+
+**The form→form operation already exists and is already documented**:
+`CreateForm(parent, patch)` — *"Parent "" forks the null root; a form id
+duplicates that form's state into a fresh @id"* (`rpc.FormCreateRequest`).
+`createFormAndReport` even takes a `parent`. **Every CLI caller passes ""**,
+so nothing reaches it. `fig form new` while attended to a form mints a
+SIBLING off the null root and inherits nothing — verified.
+
+So the fix is wiring, not mechanism: `fig fork` on a node of kind `form`
+routes to `CreateForm(parent)`. Two real questions with it:
+
+1. a form's timeline is one ceremonial record, so `<id>:<turn>` addresses
+   nothing — a form fork is always at the head, and the verb should say so
+   rather than silently ignoring a coordinate.
+1. `CreateForm` REQUIRES a patch (*"a fork that transforms nothing is a fork
+   nobody can name"*) and `fig fork` takes none. Either fork-a-form demands
+   `-S`, or that rule is relaxed for this path. That is a ruling, not an
+   implementation detail.
+
+Recorded and NOT to be built (Gluck, explicitly): `cast` on a form with no
+argument minting a figaro, and a role fork meaning fork-both-and-recast.
@@ -4,7 +4,7 @@ Plan of record for the work Gluck specified on 2026-08-13. Written by aria
 b2b0c543 (session 4) for the role holder who takes it; I am not that holder,
 so this is a plan and not a claim about built code.
 
----
+______________________________________________________________________
 
 ## 0. What this is
 
@@ -62,8 +62,8 @@ The mechanism to copy (not to call) is `internal/provider/projection.go`:
 
 1. each IR record carries cursors — `libretto:<sourceid>` for observed forms,
    the node's own form channel for the bound board;
-2. consecutive records bracket a window;
-3. the patches in that window come from `Libretto(source).PatchesBetween` for
+1. consecutive records bracket a window;
+1. the patches in that window come from `Libretto(source).PatchesBetween` for
    a studied form, and from the board's own `FormPatchesBetween` for the
    bound one.
 
@@ -87,9 +87,9 @@ as the translator ignores them. An old transcript shows no form deltas.
 
 Both are derived from ordinary deltas; neither needs a new channel.
 
-| when | the TUI says |
-|---|---|
-| `aria_id` changes on the BOUND form | *This figaro has been forked from `<id>`* |
+| when                                           | the TUI says                                   |
+| ---------------------------------------------- | ---------------------------------------------- |
+| `aria_id` changes on the BOUND form            | *This figaro has been forked from `<id>`*      |
 | `target-aria` changes on a form of kind `role` | *Role `<formid>` recast to figaro `<aria id>`* |
 
 The first is available today without inference: a fork's birth patch stamps
@@ -113,16 +113,25 @@ Global theming: take colours from the theme table rather than literals, and
 add a token (`stateDim` or similar) rather than reusing the comment colour by
 coincidence. One name, one meaning.
 
+- note that each line should be truncated to the width of the screen. Use
+  common sense and tui design skill for creating visually appealing tui indicators.
+  Form id, path, and whatever event text we chose should be rendered in a visibly
+  pleasing, but succinct way. Since the deltas will appear in a node patch,
+  I do not expect them to be individually selectable. They should be selected
+  and yanked alongside whatever node they are defined one. Selection / enter in TUI
+  should expand it. Use the verbose fig show flag or whatever is appropriate for
+  viewing them in standard out rather than in TUI alt screen.
+
 ## 5. Build order
 
 1. **The types** (`livedoc.Node`, `aria.Turn`, `FormDelta`): additive,
    `omitempty`, nothing reads them yet. Wire-compatible with old clients.
-2. **The hub-side assembly**, behind a function with its own test: given a
+1. **The hub-side assembly**, behind a function with its own test: given a
    record range and a store, produce the deltas. This is where the cursor
    arithmetic lives and where the three inherited rules are enforced.
-3. **The projector** (`internal/uiir`) attaches them to nodes.
-4. **The TUI** draws them.
-5. **The two sentences**, last, because they are a rendering of (1)-(4) and
+1. **The projector** (`internal/uiir`) attaches them to nodes.
+1. **The TUI** draws them.
+1. **The two sentences**, last, because they are a rendering of (1)-(4) and
    not a mechanism.
 
 Each step is independently testable, and 1-2 are safe to land alone.
@@ -142,36 +151,4 @@ Each step is independently testable, and 1-2 are safe to land alone.
   render twice, assert equality, and make it fail if anyone reaches for the
   provider cache to speed it up.
 
----
-
-## 7. The fork-on-a-form bug, confirmed (same session, filed here for the same hand)
-
-`fig fork @form` births a **figaro**, not a forked form: verified live, the
-child is `kind=conversation` with `aria_id` and `system.forked_from` on its
-board. So `fork` and `bind` on a form are SYNONYMS and one of the two names
-is a lie.
-
-Cause, one line: `XwalStore.ForkWith` hard-codes
-`forkWithKind(..., kindConversation)`, while `forkWithKind`'s own comment
-says the caller chooses the child's species. The fork verb has no way to say.
-
-**The form→form operation already exists and is already documented**:
-`CreateForm(parent, patch)` — *"Parent \"\" forks the null root; a form id
-duplicates that form's state into a fresh @id"* (`rpc.FormCreateRequest`).
-`createFormAndReport` even takes a `parent`. **Every CLI caller passes ""**,
-so nothing reaches it. `fig form new` while attended to a form mints a
-SIBLING off the null root and inherits nothing — verified.
-
-So the fix is wiring, not mechanism: `fig fork` on a node of kind `form`
-routes to `CreateForm(parent)`. Two real questions with it:
-
-1. a form's timeline is one ceremonial record, so `<id>:<turn>` addresses
-   nothing — a form fork is always at the head, and the verb should say so
-   rather than silently ignoring a coordinate.
-2. `CreateForm` REQUIRES a patch (*"a fork that transforms nothing is a fork
-   nobody can name"*) and `fig fork` takes none. Either fork-a-form demands
-   `-S`, or that rule is relaxed for this path. That is a ruling, not an
-   implementation detail.
-
-Recorded and NOT to be built (Gluck, explicitly): `cast` on a form with no
-argument minting a figaro, and a role fork meaning fork-both-and-recast.
+______________________________________________________________________