ARCADIA-Studio/harness/transition-lifecycle-20260913.md

Ordinary transition lifecycle and counterpart selection

Scope: issue 28 C1 cases 1–3 from the published assessment. Candidate branch codex/transition-lifecycle-9e8r6t extends ordinary/Text checkpoint 3f9e6a18af96b5cd10940da4093be8da28b9c835. The behavioral change is acbfb6cc929cb08b599b2e8ccf4d6752e63b84a8; d46854c2dc719bb8b44a0978102de44ecc3a6b39 adds only an inherited tuple-formatting correction. Live ownership and integration status remain in issue 28.

Findings and change

The existing endpoint deletion and ordinary transition engine conserves the retained counterpart in the six new lifecycle cases. These tests exercise both directions with independently authored root/child work, shared exchange-item definitions, SA typed ports, internal exchanges, placements, collapsed state, route labels and external artifact links. Expected deletions enumerate fixture-owned IDs independently of deletion implementation; whole-project equality detects incidental target changes. Old plans become stale, explicitly deleted target IDs are refused, a fresh implicit retry creates one counterpart, and a fresh subsequent retry reuses it without an undo entry. Recreating the source with the same name/alias but a new UUID does not silently recover its old correspondence. Explicit relinking changes only reviewed fields and adds the new trace.

These tests prove exact decoded-project JSON and canonical source round trips. They do not establish preservation of original source comments/formatting or file reopening in the packaged GUI. No tombstones, automatic name matching, structural merge policy, or new metamodel are introduced.

The native baseline exposed a separate obstacle: an Activity's long, unsorted counterpart menu offered opposite-layer ports, scenario records and other incompatible kinds. Selecting an offered output port caused an incompatibility error and disabled Apply. The correction shares the core's existing kind compatibility policy through counterpart_compatible, filters existing choices by name or alias, and sorts by name/alias/identity. Labels distinguish duplicate names using kind and alias. Explicit creation remains available.

Search state is separate from mappings and field resolutions. Typing does not replan or replace preview IDs; selected targets remain visible when filtered out. Missing and incompatible recovered selections remain identifiable and refused by the normal planner. Unique inferred correspondence counts distinct target IDs, so duplicate pair traces do not create false ambiguity; several distinct targets show an unresolved choice.

The chosen UI adds a text field to the existing picker. A searchable combo box was considered; it brings per-card cached option and selection state, while the separate field supports the needed filtering without changing reviewed mapping semantics. The inherited picker still requires pointer/touch interaction for opening and selection; this change is not complete keyboard accessibility.

Verification record

Windows environment: Rust/Cargo 1.98.1, stable-x86_64-pc-windows-gnullvm, LLVM MinGW, locked offline dependencies, one Cargo job, incremental caching disabled. Linux work remains paused by the user.

• First lifecycle run: compiled, then six failures in the new fixture's incomplete warning expectation. No product failure was established. The fixture now supplies a system of interest and concrete item contracts and checks the exact remaining allocation/context warning multiset by ID, code and field.
• Corrected core run: four compatibility tests and six lifecycle tests passed; 710 recorded inputs remained unchanged. Compatibility covers both-direction element/relation families, wrong layers/categories, missing/nonsemantic identities, and the observed real SA-port refusal against the full planner.
• Desktop workflow filter: 25 passed, zero failed/ignored, 1,164 filtered; includes query preservation, duplicate-name selection, recovery refusal and trace inference. Existing core workflows: 28 passed, zero failed/ignored/filtered.
• Strict Clippy: cargo clippy --locked --offline --workspace --all-targets -- -D warnings passed on acbfb6c. All successful test/lint input bytes match its 710 recorded Git blobs.
• Initial cargo fmt --all -- --check found only the inherited tuple layout in diagram/focus.rs. Commit d46854c fixes those line breaks; the repeated format check passed with empty output. Tests/lint above were not rerun on this formatting-only commit.
• Windows workspace/binaries build passed on d46854c, with the same 710 unchanged inputs as the final format check. GUI: 117,737,472 bytes, SHA256 6d3b0996bb153ab55c21672feec1e7303eb6c59eaad01f8dd8aa09609e08086c. This is a development build, not a packaged release.

Reproduction commands from the repository root with the documented Windows toolchain/runtime on PATH (CARGO_BUILD_JOBS=1, CARGO_INCREMENTAL=0 for this small disk):

cargo test --locked --offline -p oa-core --test transition_lifecycle --test transition_counterpart_compatibility -- --nocapture
cargo test --locked --offline -p oa-core --test workflows -- --nocapture
cargo test --locked --offline -p oa-desktop --bin arcadia-studio workflow:: -- --nocapture
cargo clippy --locked --offline --workspace --all-targets -- -D warnings
cargo fmt --all -- --check
cargo build --locked --offline --workspace --bins

See closed Cargo evidence for source inventories, raw results, hashes and an offline verifier. Its initial failures remain separate from corrected runs. The parent independently ran the reviewed verifier against both working and exact staged package bytes.

Native picker observation

The native comparison package retains all three launch attempts, original frames, copied teaching inputs, both build receipts and the independent frame review. It links the separate build/source evidence. The capture-helper source was retained from the earlier session but was not pinned at launch; frames establish recorded states, not independent action/PID attestation.

The corrected GUI trial ran 2026-09-13 15:22:22–15:27:13 UTC on d46854c. It reopened the copied teaching model from Recent models, selected Assess pressure alarm, and used Create System counterpart… to open the ordinary transition dialog. All 23 original state captures are retained. The copied files and executable remained byte-identical; the process exited zero with empty stdout/stderr. An earlier launch without the toolchain environment exited immediately with Windows code 3221225781 and empty logs; the same binary launched successfully after loading that environment. This is recorded as an invocation failure, not a passed launch or a reproduced in-app crash.

• Frames 06–07: two source mapping cards; Create plus six alphabetically sorted Function candidates, with full teaching-model aliases. Baseline frame 10 offered incompatible kinds; baseline 11 shows the resulting port-selection error.
• Frames 10–12: uppercase @SA_REPAIR narrows the list to the matching function, retaining the current Assess mapping until the user explicitly selects Repair.
• Frames 15 and 17: zero results retain Repair; two visible cards retain independent queries.
• Frames 18–19: normal Name conflict requires review; Keep target enables Apply. Frame 22 shows that clearing search retains the selected target and Keep target decision.
• Frame 23: Cancel dismisses the workflow and restores All changes saved. No reviewed transition was applied in this trial.

Independent read-only reviews found no blocking defect in the shared predicate, selection/query handling, recovery behavior, or lifecycle conservation evaluator. Two refinements were incorporated: empty-query feedback no longer asks to clear an already empty search, and query-isolation tests use two actual OA source cards. A separate review of original native frames confirmed the bounded observations above without a blocking visual regression. Remaining friction: disabled Apply can have its required field-review explanation below the fold, requiring a scroll. Keyboard-only picker operation and broader transition-dialog feedback remain incomplete.

The native trial establishes this finite Windows selection/review/cancel workflow. It does not establish native endpoint deletion/recreation/relink, saving an applied transition, packaged launch, or whole-project equality from screenshots. Those lifecycle operations have the core evidence above; the broader C1 native acceptance and integration/release decision remain open.