Add named behavior creation and verified textual authoring examples

harness/release-behavior-creation-independent-review-20260910.md

@@ -0,0 +1,147 @@
+# Independent local behavior creation review — 2026-09-10
+
+Codex-9e8r6t /root/palette_finish. Read-only review of prepared
+`crates/oa-desktop/src/behavior/creation.rs`, its ten nested tests, the author's
+`release-local-behavior-creation-20260910.md` integration plan, current App
+execution/modal/recovery code and core eligibility rules. No production edits,
+Cargo or native Studio input. The module was not yet declared in the parent at
+review time; this is not compilation or acceptance evidence.
+
+Native comparison: `release-capella-creation-study-20260910.md`. The compact
+family/name/viewpoint card avoids Capella's separate chain semantic creation,
+rename and first representation actions. Explicit OA/SA viewpoint choice and
+source-versus-involvement language fit the observed distinction. The current
+SA boundary wording also respects Studio's actual System/SystemActor endpoint
+contract; it should not be broadened casually to all components.
+
+No material defect was found in the normal prepared command paths. Raw names,
+reserved IDs, family/layer restrictions, valid owner/context checks and failure
+retention are coherent. The opt-in first state view reuses its planner and
+substitutes stable presentation IDs, with no invented state/region. Recovery
+retains raw values and validates references when preparing. Whole-project and
+SourceBundle Undo/Redo/reopen checks are meaningful, although unexecuted at this
+boundary. A same-ID owner rename remains the same semantic identity; rejecting
+all such edits would not be justified by this review.
+
+Three bounded items were sent to the author and root before integration:
+
+1. **Command correlation is narrower than exact draft correlation.**
+   `created_by` matches CreateElement ID/layer/kind/name/parent and an optional
+   CreateDiagram projection, but not a scenario's viewpoint/context/body. A
+   prepared scenario command with only a different valid viewpoint or context
+   still matches. A batch containing the expected create followed by a rename
+   or deletion also matches because the recursive helper uses `any`. These
+   commands are not produced by this module's normal Submit; this is a boundary
+   hardening issue rather than a demonstrated UI failure. Compare the expected
+   command more fully or validate the resulting target before selection, and
+   test changed scenario body and later mutations in the same batch. Do not
+   describe the helper as exact full-command correlation before resolving it.
+
+2. **Captured Escape must preserve modal priority.** The plan correctly avoids
+   globally accepting captured keys. However, emitting Creation(Cancel) merely
+   because a draft exists is insufficient when a Save As, pending navigation,
+   hosted or model-menu overlay owns focus. Current App modal guards recognize
+   ordinary Escape specially. A creation-specific captured message may be
+   swallowed by those guards, or cancel the underlying draft if routed too
+   early. The added subscription must be scoped to the actual visible creation
+   card and respect overlay ownership. Require both a real focused creation
+   input first-Escape test and an overlay-focused captured Escape test proving
+   the underlying raw draft survives.
+
+3. **Minimum-size claims remain a layout/native gate.** `picker_view` limits its
+   candidate iterator to six and places actions outside the field scrollable,
+   which is a sound source-level structure. The 105-owner test only constructs
+   the view and asserts it exists; it does not assert rendered candidate count,
+   wrapping, action bounds or focus. Long Unicode names/aliases can create tall
+   rows. Verify six-candidate pagination and Create/Cancel reachability at the
+   minimum window, with optional scenario context expanded and machine owner
+   search, before describing this as verified usability.
+
+The author already identified the important shared integration risks: do not
+auto-apply a valid property draft while opening creation; include creation in
+all pending guards; select only after successful document execution; use the
+recorded layer for a recovered new SA behavior; retain simultaneous raw source
+and properties rather than calling a destructive sync; batch autofocus with
+existing lint work. These remain tests required of the actual integration, not
+additional confirmed defects in the standalone module.
+
+One deliberate UX limit remains: when a machine has no eligible participant,
+the card tells the user to cancel and create one in Architecture, losing this
+creation intent. A suspended draft plus local Create missing participant would
+better satisfy the revised goal and the observed OAS source-creation pattern.
+It is separate work from this module and must not be claimed as delivered here.
+
+## Integrated boundary review — 2026-09-11
+
+Codex-9e8r6t /root/behavior_audit. Independent read-only review of the uncommitted
+creation integration on `d114a271c5ecffcd7960fb8aa44d45989c10dc33`, after reading
+the revised PROJECT_GOAL, current Gitea decisions through #117, and the existing
+review above. The creation author retained the shared source/Cargo lease. No
+Rust edits, Cargo commands, native input, or new test execution by this reviewer.
+The author's concurrent owner/context label follow-up is outside this correctness
+review; App, behavior and checkpoint seams stayed frozen.
+
+**No additional confirmed blocker was found in the reviewed integration.** The
+earlier command-correlation and captured-Escape concerns have concrete code
+resolutions. This conclusion is bounded to the following source paths and
+counterexamples, not a claim of release or native acceptance:
+
+- **Command and success correlation:** `creation.rs:147` now compares the whole
+  deterministic prepared `Command`, including scenario body and every operation
+  in its batch. Changing only a valid viewpoint/context, adding a later rename
+  or delete, omitting the optional view, or presenting a different command cannot
+  inherit this creation's opening target. In `app.rs:851`, port-owner repair
+  leaves this Batch unchanged; correlation is captured before execution. Only
+  the success arm installs layer, new behavior selection, active owner and
+  opted-in state view. Rejection does not call sync or acknowledgement. Both
+  direct Behavior Submit and `apply_behavior` acknowledge after successful
+  execution. The first-view planner's temporary UUIDs are replaced with all
+  three reserved identities before comparison; the remaining planned fields
+  are deterministic for the current project.
+- **Pending and stale-input boundaries:** `app.rs:2303` rejects an Open event
+  from the previous layer before applying any draft, and creation Open uses its
+  own raw-property/source/pending guard instead of generic implicit Apply.
+  Existing owner/layer navigation and Undo/Redo pass through `apply`, which
+  refuses while creation is pending. Source/property edits and another behavior
+  Start cannot bypass that pending boundary. A retained creation draft rejects
+  field edits/preparation against a different Project ID; current owner/context
+  eligibility and reserved-ID collisions are revalidated before execution.
+  This is not a claim that every local form event carries a canvas-generation
+  token: it does not. No reachable cross-document semantic commit was identified
+  through the reviewed reset/busy/pending routes.
+- **Recovery and selection:** `app/checkpoints.rs:149` fully prepares recovery
+  before replacing the accepted document, reinstalls raw source and property
+  drafts, and uses `creation.pending_layer()` for a root-owned SA draft whose
+  selected project root has no layer. It does not resynchronize accepted text
+  after installing those raw buffers. A restored family-selected card batches
+  name focus with lint. Attempting Submit with simultaneous recovered property
+  or source drafts refuses before preparing/executing creation. The wrapper in
+  `behavior.rs:791` refuses multiple pending behavior drafts rather than choosing
+  one to discard.
+- **Escape ownership:** the new subscription receives only captured Escape and
+  maps it to ordinary `Message::Escape`; the existing subscription ignores that
+  captured event, avoiding a second ordinary Escape from those two listeners.
+  App handles model-menu, hosted, workflow, file, delete and pending overlays
+  before the creation-cancel arm at `app.rs:1756`. A first Escape therefore
+  dismisses the active modal while retaining creation; a subsequent Escape
+  cancels the local draft without a model transaction. Normal guards prevent
+  opening the model menu or architecture placement while creation is pending.
+
+Validation evidence read directly from `.local/behavior-creation-20260911/`:
+`focused-tests-4.log` reports 20/20 creation tests in 0.28 s,
+`behavior-tests.log` reports 166/166 in 13.35 s, and
+`checkpoint-tests.log` reports 13/13 in 2.26 s. These include the author's
+changed-body/trailing-command refusals, actual App selection and raw-input
+guards, a focused Iced TextInput captured-Escape path, and mounted candidate and
+pinned-action bounds. They are author-executed evidence, not an independent
+rerun. Native typography, optional-context expansion and the complete creation
+workflow remain root-owned acceptance. The missing-owner catalog detour above
+remains separate unfinished functionality.
+
+Frozen seam SHA-256 values for the reviewed source:
+
+```text
+app.rs             2CC2CF65CA0E2B999271BF6BE253D026102A4DA769D54A7BC9CF9982375B89F2
+app/checkpoints.rs B5D319E6FDA8DEC3CD068C362E9C35E941EACC32EDCD291D9F66E33A055209CF
+behavior.rs        C957C86226012F8A1E6ED406A6BBE3407424CCEA47C0994130483CE758C8C114
+```