ARCADIA-Studio/harness/release-semantic-review.md

Independent R1/R2/R4 semantic review

Final focused status: all material findings from this narrow review are closed. Historical findings and evidence below are retained chronologically. The final verification section distinguishes the accepted semantic/form checkpoint from subsequent scenario-authoring integration.

Reviewed 2026-09-05 against the current goal, PLAN, actual core and desktop source. This is a narrow milestone review, not final release acceptance. R3 semantic reconciliation, R5 state/event expansion and R6 data contracts were explicitly outside this review. No application files were edited; no Computer Use was performed because the lead owns native interaction.

Material findings

P1 — Branch-local replies and lifeline destruction silently permit contradictory execution paths

crates/oa-core/src/validation.rs:1098 defines guaranteed_before by walking only the after occurrence's ancestors. The duplicate-reply check at approximately1277 and lifetime check at1315 reuse it as though it also determines whether two events can occur in order on any one branch path. These are different questions.

Two actual reproductions were built and run:

1. Scenario steps: Call A→B; Optional fragment whose one branch contains Reply B→A to that call; then another Reply B→A to the same call. The optional path executes two replies to one invocation. validation::validate reports zero errors and no scenario warnings.
2. Scenario steps: normal conversation; Optional fragment whose one branch deletes B; then a message to B. Taking the optional branch uses a destroyed lifeline. Validation again reports zero errors and no scenario warnings.

The existing straight-line checks work and the current reST describes only guaranteed-path checks. This is therefore also a contract gap: the narrow rule currently leaves these concrete invalid paths entirely undiagnosed. It does not require simulation or expression solving to detect them.

Smallest fix: retain the strict dominance/common-path predicate for proving that a correlated Call precedes Reply. Add a separate structural relation for whether two occurrences can execute on the same branch path and in what order. Distinct branches of one Alternative are mutually exclusive; a branch and an occurrence after its enclosing fragment can coexist; Parallel branches can coexist. Use this relation for conflicting replies and lifetime checks, at least warning when a violation is possible and rejecting structurally certain contradictions. Do not flatten alternatives into an unconditional execution order. Cover Optional/Alternative versus following siblings, two Parallel replies, and legal mutually exclusive Alternative replies in regression tests.

P2 — Role-based operational scenario lifelines are rejected despite valid role assignment and realization

validation.rs:2483–2500 compares represented lifeline identity only against exchange work identity or its concrete effective_performer. ScenarioViewpoint::ParticipantInteraction explicitly allows Role lifelines, and scenario-use bindings separately support realized operational roles. The endpoint check cannot express the same legitimate role correspondence.

Actual reproduction:

• OA activities Request service and Provide service, connected by Interaction.
• Entity Controller allocates Request service.
• Controller realizes Role Coordinator; Coordinator is assigned Request service.
• Other entity allocates Provide service.
• A ParticipantInteraction scenario represents Coordinator on its first lifeline and Other on its second, with a correctly directed call and correlated reverse reply.

The base graph is valid; validation rejects the scenario with two scenario_endpoint errors. Removing the concrete allocation and relying on RoleAssignment/RoleRealization inference has the same underlying mismatch: effective performer remains Controller rather than the represented role.

Smallest fix: define one core endpoint/lifeline compatibility helper that recognizes an explicitly assigned Role for the work, and participant correspondence through a valid RoleRealization where appropriate. Preserve wrong-role rejection. Reuse it for scenario-use identity compatibility and desktop choices rather than adding another slightly different predicate. Test the valid role case, a distinct unassigned role realized by the same entity, ambiguous realizations, and the existing direct-work/participant/port cases.

P1 integration seam — Graphical reply lifeline choices use forward exchange direction

Current crates/oa-desktop/src/forms.rs:600–661, lifeline_matches, always chooses global exchange source for sender and target for receiver. Core's validate_occurrence_context correctly reverses these endpoints when Reply reuses its correlated Call exchange. Consequently a valid reverse reply's sender and receiver are excluded from their corresponding choice lists, while invalid forward-direction choices are offered.

Evidence is direct source inspection: reference_ids calls lifeline_matches for sender/receiver; the helper does not inspect message_kind or reply_to. Core at approximately2522 does. This was reported to the lead while R4 form wiring was still underway, so it is an integration requirement to verify after those concurrent edits, not a claim about a finished release UI.

Smallest fix: use the same core helper above for derived message endpoint direction and semantic lifeline compatibility. Add a form-choice regression asserting correct reversed choices for same-exchange replies and ordinary choices for an explicit reverse exchange; exercise both graphically after integration.

Verification and reproduction artifact

Executed successfully:

$env:CARGO_TARGET_DIR='D:/CodexBuilds/Capella2-01a06e2e'
cargo test --locked -p oa-core --test release_topology --test release_capabilities --test release_scenarios

All 20 existing tests pass: six topology, seven mission/capability, seven scenario. Their fixtures cover ordinary branch topology/reuse, closure mapping, straight-line calls/replies/lifetime, field references, deletion/reidentify/undo. They do not cover the above branch interactions or role lifelines.

A separate read-only-to-application reproduction package is retained at:

D:/CodexBuilds/Capella2-release1-01a06e2e/semantic-review-repro

Run:

$env:CARGO_TARGET_DIR='D:/CodexBuilds/Capella2-01a06e2e'
cargo run --offline --manifest-path D:/CodexBuilds/Capella2-release1-01a06e2e/semantic-review-repro/Cargo.toml

Observed output:

duplicate_reply_after_optional: 0 errors, codes ["missing_system", "unallocated_leaf", "unallocated_leaf"]
use_after_optional_delete: 0 errors, codes ["missing_system", "unallocated_leaf", "unallocated_leaf"]
valid_role_lifeline: 2 errors, codes ["scenario_endpoint", "scenario_endpoint"]

The external package includes the existing release_scenarios fixture and adds only reproduction construction; it has its own Cargo.toml/lockfile and changes no repository tests.

Correctness and simplicity assessment

No additional concrete high-impact R1 or R2 defect was found in this pass. Typed contextual SequenceLink relations, explicit reference visitors, validated atomic commands and ordinary core enums fit the existing architecture without a new framework. Required transition closure includes contextual sequence links and reusable target dependencies; tests cover remapping and both directions. Capability inclusion/specialization remain separate graphs and preserve containment independently, which is clear and appropriate.

The principal avoidable duplication is endpoint agreement between core validation, scenario-use bindings and desktop filtering. Consolidating that precise predicate is a small correctness fix, not grounds for a wider abstraction or refactor. All findings require independent verification after the fixes; this review does not mark R4 or the release complete.

Focused independent re-review after core fixes

Original branch and Role findings are closed in core by independently rerunning the unchanged original constructions. Current output reports duplicate_reply and lifeline_lifetime errors for the two invalid Optional paths, and no errors for the valid Role scenario. semantic_representation_compatible, lifeline_matches_endpoint, and message_endpoints now provide shared core semantics. The corrected possibly_before distinguishes structural co-execution from call dominance, retaining valid mutually exclusive Alternative replies.

Reran all focused suites: 24 tests pass (six topology, seven capability, eleven scenario). The four added regression groups cover the earlier findings and shared message direction helper. Desktop picker closure remains pending lead integration and an explicit notification to review those changes.

Remaining P1 — Loop repetition is still analyzed as a single execution

Current validation.rs:1211–1261 finds order at the first diverging structural ancestor but never considers returning to an earlier step during a subsequent Loop iteration. The message/lifetime scans also exclude the occurrence itself. Two additional independently compiled constructions produce zero errors and no scenario warnings:

• One Call occurs before a Loop. The Loop body contains a Reply correlated to that outside Call. Repeating the body replies to the same single call multiple times.
• A Loop body uses lifeline B, then deletes B. A subsequent iteration uses the already destroyed lifeline before executing another deletion.

These require no interpretation of free-text conditions to diagnose as possible violations. There is no loop bound in the model proving at most one execution. Both constructions are appended as loop_review() to the external reproduction program. Observed output:

one_call_with_repeated_reply: 0 errors, codes ["missing_system", "unallocated_leaf", "unallocated_leaf"]
use_after_delete_next_loop_iteration: 0 errors, codes ["missing_system", "unallocated_leaf", "unallocated_leaf"]

Smallest safe fix: preserve single-iteration dominance for ordinary Call→Reply validation, but identify enclosing Loop ancestors. A Reply repeated by a loop that does not similarly repeat its correlated Call needs a diagnostic. Lifecycle messages inside a potentially repeating loop need a clear diagnostic when repetition can create an already existing or use/delete an already destroyed lifeline. Conservative warnings are appropriate if finite bounds/guards cannot be proven; silence currently presents these paths as coherent. Avoid indiscriminately prohibiting loops: a Call and matching Reply repeated together within the same operand remain valid. Cover nested loops, Call outside versus inside the repeating scope, and the [use, delete] back-edge case.

Desktop integration follow-up

After lead notification, inspected the current typed scenario-use/binding/call selectors. The original reverse Reply selector finding is closed by source inspection: forms now uses message_endpoints and lifeline_matches_endpoint. Scenario bindings call the shared semantic helper in the same local→referenced direction as core, retain one-to-one constraints and scope candidates to the relevant scenarios. No native verification was performed by this reviewer.

One new P2 regression was reproduced in the state-observation branch of the updated form helper (forms.rs:667 at review time). The exchange endpoint helper is not equivalent to state-owner compatibility:

• SA Functional scenario lifeline represents Function F.
• F is allocated to System S.
• State Q belongs to S's StateMachine/Region.
• A State observation references Q on F's lifeline.

Core accepts the model, because validate_occurrence_context permits effective_performer(F) == S. The new form selector evaluates lifeline_matches_endpoint(p, F_lifeline, S) != Some(false), which returns false, hiding the valid lifeline. The prior form code included this work-performer allowance. The external reproduction now contains state_picker_review() and prints:

function_lifeline_state_observation: 0 errors, codes ["unallocated_leaf", "missing_initial"]
form_state_selector_accepts_function: false

Smallest fix: preserve the state observation's dedicated compatibility rule (represented owner, or work effectively performed by that owner), ideally shared by state validation and its picker. Do not broaden general exchange endpoint identity to compensate for the reversed state/performer relation. Add a form-choice regression with a Function/Activity lifeline, plus a wrong-owner negative case.

Final focused closure

Independently reran the external compiled reproductions against the frozen core and the 27 current focused tests: seven capability, six topology and fourteen scenario. All tests pass. The new scenario tests cover nested loop reply scope, balanced repeated lifetimes, and optional cleanup that cannot guarantee balance.

Current observed behavior:

• Optional reply plus subsequent duplicate: rejected with duplicate_reply.
• Optional destruction plus subsequent use: rejected with lifeline_lifetime.
• Valid assigned Role lifeline: accepted without errors.
• Reply repeated without its Call: accepted as an editable model with reply_repetition warning.
• [use, delete] repeated lifetime: accepted as an editable model with lifeline_repetition warning.
• Balanced Call/Reply and create/use/delete loops: covered by passing current regressions.
• Valid state observation on allocated Function lifeline: accepted by core; the restored form predicate independently evaluates true. Source inspection confirms the form uses the represented-owner/effective-performer rule, preserving distinct exchange compatibility semantics.

The original reverse Reply direction and binding selector integration remain coherent by inspected source. There is no remaining material semantic finding from this focused review. Conservative loop warnings deliberately leave conditions and at-most-once constraints to the engineer; they no longer silently present questionable repetition as coherent.

An attempted fresh cargo test --locked -p oa-desktop forms::tests encountered a subsequent concurrent integration state: behavior.rs:18 declared mod scenario before behavior/scenario.rs was written, causing E0583. The lead confirmed that all 50 desktop tests, including the State picker regression, had passed at the preceding verified checkpoint and that the isolated scenario authoring worker had then started its next task. That 50-test result is lead-reported, not independently observed by this reviewer. Per lead instruction, no rebuild was attempted while the new module was under construction. This temporary build state is not closure evidence for the ongoing authoring milestone; its integration must be verified separately.

Only this report and the external reproduction package were changed. No native/UI verification was performed in this review. This closes the narrow R1/R2/R4 semantic findings, not final release acceptance.