Establish OA/SA prototype baseline and first-release work

This commit is contained in:
2026-09-05 17:04:16 +03:00
commit 93ba83d321
109 changed files with 56512 additions and 0 deletions
+27
View File
@@ -0,0 +1,27 @@
# Architectural and product decisions
- **One typed model, three Rust crates.** `oa-core` owns semantics, validation, transactions, history, references, language and projection. `oa-desktop` is an Iced editor; `oa-server` is an Axum transport/store. A second GUI/text model, event framework or runtime plugin ABI would introduce unnecessary synchronization and extension complexity.
- **Bounded OA/SA profile.** Typed element bodies determine layer/kind; separate records describe relationships, diagrams, realization traces and artifacts. SA has one System and external Actors; LA/PA deployment and executable simulation are outside V2. The normative reST contract and scope document state exact semantics instead of implying full Capella/SysML conformance.
- **Nesting derives from meaning.** Semantic containment and leaf allocation feed independent diagram projections. A placement drag changes geometry, never ownership. Shared projection drives canvas, Fit and SVG. Scenario/state graphics project the same behavior records and select them directly; numbered routes lead to full transition details.
- **Creation respects its workspace.** Architecture creation also places the new element in the current view. Behavior and Data creation preserve existing architecture diagrams; an explicit placement command remains available. The shared creation path enforces this once, while core commands maintain occurrence ownership and sequence order.
- **Equivalent editing, explicit drafts.** Every persistent field is available in typed property controls and canonical source. Source Apply validates and commits one transaction. Invalid source/property drafts remain editable; separate text/model history avoids ambiguous Undo. The temporary JSON form adapter is closed over typed records, not a second semantic schema.
- **Stable identity and readable changes.** Globally unique UUIDs and persisted aliases serve distinct purposes. Flat canonical declarations and @alias references reduce Git churn. Exact string controls preserve escaped LF/CR/tab values. Comments/formatting normalize on Apply; a comment-preserving parser and LSP were deferred. V1 migration preserves old IDs and deterministically assigns new view/occurrence UUIDv5 identities.
- **Identity updates are ordinary atomic edits.** Reference maintenance happens within the validated candidate. Selection and pending canvas gestures follow resulting IDs; editing an already-selected card preserves its draft until release. Placement relocation preserves UUID, geometry and artifact ownership, then focuses its committed diagram and perspective.
- **Transitions are reviewed engineering decisions.** Canonical OA-to-SA traces support creation/linking in either direction. Preview offers explicit dependencies, System/Actor boundary choices and counterparts. Existing-target reconciliation compares names/descriptions using reviewed baselines, with Keep/Take/merged values. It is not structural synchronization or a claim of lossless phase reversal. Scope follows ownership/reference dependencies, not every incident edge.
- **Local and service persistence have distinct concurrency boundaries.** Desktop saves compare exact last-read bytes immediately before atomic replacement to detect ordinary external editor/Git changes. Conflicts preserve drafts/files for Save as/reopen; this is not filesystem compare-and-swap. The service persists complete current-model envelopes before publishing revisions, with exclusive directory ownership and ETag preconditions. SQLite, distributed replicas, retained history and retry receipts were unnecessary for the bounded prototype.
- **Artifacts remain opaque engineering references.** URI/revision/fragment metadata can target any model record. Desktop and API retain it without fetching or executing content. Desktop/hosted transfer uses explicit source import/export; a direct hosted editor requires a separate concrete workflow.
- **Native graphics and deployment.** Retain Iced WGPU with Windows, X11 and Wayland support. The tested WSLg environment requires Mesa software Vulkan. Separate headless server binaries avoid GUI dependencies. Docker/systemd recipes are documented; actual remote installation is not implied by local verification.
- **Evidence governs completion.** Original Capella was operated in an isolated example and its useful nesting/navigation/transition patterns informed the UI. Independent reviews, real native workflows and automated invariants complement each other. Platform and feature boundaries remain explicit in validation/scope documents.
# First-release decisions (supersede narrower V2 exclusions below)
- OA/SA semantic scope follows `release-semantics-audit.md` R1–R6 and actual Capella workflow evidence. Later Arcadia layers remain future work; missing OA/SA reuse, topology, state/data contracts and semantic transition review do not become release limitations.
- Preserve one typed Rust core and atomic validated model commands. Mission/capability links and process topology are independent of containment and diagram placement. Work/chain reuse uses stable reference occurrences rather than copied semantic objects; sequence guards belong to contextual links rather than global exchanges.
- Desktop lint uses one background parser plus the latest queued source version. Accepted model checks are cached separately from draft diagnostics. Stale results cannot enter a different document or overwrite newer edits. The REST service prepares bounded candidates outside its global store lock and rechecks ETags during commit.
- Relationship creation follows the selected engineering concept: directional names, compatible endpoint choices, optional generated relationship names and conditional extension text in the initial dialog. Existing model transactions remain the sole commit path.
- Help is an offline Rust topic registry with search and guarded workspace links. Task navigation is separated from the independently scrolling model explorer so search and perspective controls remain available at minimum window size. Fit uses the actual measured canvas, with a pre-layout fallback, rather than assuming a fixed amount of window chrome.
- Source/schema3 and explicit V2 migration are planned for the expanded release. Current schema2 is an integration checkpoint, not a new compatibility claim. Existing V2 packages remain preserved until final release acceptance.
- R5 state/event contract adopts region-owned entry/exit symbols attached to their containing boundary, independent per-region history, strict transient pseudo routing without event triggers, and preservation of the last removed typed trigger as descriptive text. This supports explicit engineering semantics without an execution engine; exact invariants and migration policy are in release-state-contract.md.
- Git is now explicitly authorized by the user. Establish a source baseline on codex/release1-engineering, then use focused commits at verified milestones. Use Git worktrees for independent writers when their scope can be partitioned; root integrates and owns native UI. Keep target/dist, recovery/store files and credentials outside version control. No remote publication is implied.
- User's hierarchy/port correction supersedes generic graph defaults. Architecture/dataflow/capability content differs by engineering purpose, while containment/allocation and port anchors remain derived from semantic records. The exact correction and remaining port metamodel work are in release-diagram-port-correction.md.
+44
View File
@@ -0,0 +1,44 @@
# First release execution plan
## Outcome and baseline
Deliver the first release of Arcadia Studio for system engineers: complete Operational Analysis and System Analysis/System Architecture workflows, equivalent graphical and textual models, clear artifact traceability and a deployable/programmatically accessible Rust service. Logical/Physical Architecture and later Arcadia layers are future releases, as the new objective explicitly states.
The authoritative objective is the attachment ending 81e84f53-2b51-4151-9e34-59414bda8b2d/goal-objective.md. The accepted 0.2.0 prototype is the baseline, not proof of this release's completeness. Its source is preserved at D:/CodexBuilds/Capella2-release1-01a06e2e/v2-source-baseline.zip and its existing binary archives remain in dist until replacement passes acceptance.
## Existing architecture and retained decisions
Retain three Rust crates and one typed Project/validated atomic Command boundary. oa-core owns semantics, references, history, transitions, source and persistence; oa-desktop owns Iced interaction/drafts/projections; oa-server owns REST/ETag/current-model storage. Keep identity, semantic containment, allocation and per-diagram placement separate. No runtime plugin framework or later-layer skeleton.
The current forms are a closed typed-record adapter, not a second metamodel. Expand their real creation/reference/variant controls with every semantic addition. Core choices must drive graphical choices. New persistent fields participate in text round trips, identity/removal visitors, transitions, API schemas and graphical authoring tests.
## Milestones and measurable acceptance
Current priority within milestone2: address the user's diagram/port correction using `release-diagram-port-correction.md`. Separate engineering views, actual owner-bound port geometry and full functional/component-port semantics precede further breadth. Existing R5 state authoring is preserved; it still needs native verification.
1. **Release coverage audit and interfaces.** Compare actual core/UI/API with official Capella OA/SA semantics and the new objective. Freeze a coverage table and concrete variant/reference/transition contracts before editing shared interfaces. Distinguish unsupported later layers from missing OA/SA workflows; V2 exclusions are reconsidered. Native audit exercises onboarding/help/authoring at supported sizes. Independent audits have separate file ownership.
2. **Complete engineering semantics.** Fill verified gaps in capability relationships and mission involvement; operational process/functional-chain function/control topology; scenario/state/data constructs needed by OA/SA engineers. Add typed semantic-content drift and reviewed existing-counterpart reconciliation, including reference mapping and explicit dependency/ownership decisions. Every addition has a usable graphical authoring workflow, equivalent source/API representation, meaningful reject/undo/delete/reidentify/transition tests and a worked example. Exact additions and invariants are recorded in the coverage/interface artifact from milestone1, avoiding speculative LA/PA concepts.
3. **Approachable authoring and help.** Replace static help with searchable topic navigation, concise concepts, numbered OA→SA tutorials, related topics and direct workspace actions. Add a focused starting workspace, recent models and practical creation guidance. Improve source authoring with asynchronous versioned lint, semantic warnings, diagnostic navigation and find/go-to tools. Make selection/navigation and hidden/placed model distinctions clear. Add recoverable local checkpoints for unsaved accepted models and drafts; preserve explicit file-save/conflict behavior.
4. **Connected automation workflow.** Keep headless deployment and shared core REST contract. Add direct optional desktop open/publish/save of hosted models using explicit connection details and conditional ETags, preserving drafts on failure/conflict and keeping credentials in memory. Verify actual desktop→API→desktop edits and artifact integration locally. Update OpenAPI, deployment and source contracts for the expanded release semantics.
5. **Release integration and polish.** Guided examples cover OA goals/roles/process alternatives, system missions/capabilities/boundary contracts, chains/scenarios/states and evidence. Review default/minimum/wide layouts, practical keyboard paths, empty/loading/error/recovery states and performance on representative models. Build/run the actual native app after each meaningful UI milestone, fix from evidence, then reverify.
6. **Independent final acceptance and packaging.** Fresh requirements, correctness, native UX and simplicity reviews in parallel; fix all material findings and rerun affected checks. Full Windows/Linux locked tests, formatting, strict Clippy and optimized builds. Operate primary GUI workflows and actual service transport. Verify current docs/reST rendering, examples/migration, reproducible source workflow, package binary equality/archive contents and checksums. Only then replace 0.2.0 bundles and mark this goal complete.
Dependencies: milestone1 freezes shared interfaces for2; guide/lifecycle work in3 can proceed independently once UI ownership is partitioned. Structural counterpart work depends on2. Hosted client4 depends on final core/API types but transport/lifecycle can be developed independently. Milestones5–6 integrate all preceding work.
## UI and state flow
Keep task navigation, engineering perspective and context-sensitive properties. A Home/start workspace offers projects, recovery and tutorials without obscuring active modeling. Help uses local Rust-owned content and search/category navigation; workspace links pass explicit events and respect draft/modal guards.
Text edits update a snapshot/version; parsing/semantic lint runs on a blocking worker and only the latest result is adopted. Syntax errors and semantic warnings have distinct severity/location and navigate to source. Applying text remains one atomic model transaction. Invalid text and property input are recoverable drafts.
Recovery writes separate per-session checkpoints in user-local application data, never silently overwrites a model file, and offers explicit restore. Recent paths are convenience metadata. Hosted models use a separate connection/resource/revision/ETag handle; ordinary core editing and Undo stay local until explicit conditional Save. Network/file failures retain the same draft. Tokens are not persisted or included in diagnostics.
## Failure and verification strategy
Cover wrong-layer/reference/kind input, ownership/reference cycles, duplicate or ambiguous counterpart matches, stale plans/ETags, typed semantic drift, sequence control topology and repeated occurrences, invalid source/property drafts, external file edits, failed storage/network operations, oversized models and unavailable graphics. Keep incomplete engineering work editable through warnings while rejecting structural corruption.
Tests must cover user-visible meaning and cross-representation invariants, not just serialize the same value twice. Use actual HTTP and native CUA for end-to-end behaviors. Independent review targets current artifacts and the original release objective, not only implementation summaries. Record unsupported/unavailable environments without turning missing required functionality into a limitation.
## Definition of done
Every concrete requirement in the new objective and release coverage table has authoritative current evidence. Primary OA/SA engineering workflows work graphically, textually and through the API; help is navigable and useful; native Windows/Linux UI is intentionally designed and exercised; no blocking/high-impact defect remains; strict checks pass; independent findings are closed; durable docs accurately reflect the release; another engineer can build/run/test and use the supplied packages. V2 completion alone does not satisfy this goal.
+50
View File
@@ -0,0 +1,50 @@
# First release state — R4 authoring / native iteration / R5 integration
## Objective and baseline
Active goal: feature-complete OA + SA/Architecture first release, beyond V2; objective attachment81e84f53-2b51-4151-9e34-59414bda8b2d. User demands closer original Capella study and practical usability. Later layers remain future work. V2 source ZIP and dist packages preserved; do not mark release complete. PLAN.md is current milestone/acceptance source.
## Verified implementation
- R2 missions/capabilities, R1 process topology and R4 declared scenarios/message semantics implemented in shared core; exact handoffs release-capability-core.md, release-topology-core.md, release-scenarios-core.md.
- Fresh independent release-semantic-review.md findings CLOSED: branch-local duplicate replies/use-after-delete, Role compatibility, loop repetition diagnostics, reverse Reply picker and state-owner picker. Independent27 R1/R2/R4 tests + compiled external repro passed. Core worker71 focused regressions + strict Clippy passed before R5. Loop warnings distinguish uncertainty from execution claims.
- R1 contextual tools now work from empty and legacy Process/Chain; preserve legacy linear interpretation and perform explained atomic path conversion. Root added measured Fit/zoom and scaled hit testing after native excessive-scroll finding; empty process now has guidance. Latest source not native reverified yet.
- R4 dedicated scenario.rs authoring supports typed lifelines, all message styles, paired Call+Reply, explicit bound ScenarioUse, fragments/operand destinations/actions/state observations, carried values. Core helpers drive endpoint/viewpoint compatibility. Worker six scenario tests; root56 full desktop tests passed session50129 before source-find addition.
- Root R4 property forms include typed message/payload/reuse/binding fields and new constructors. Shared core reply/role helpers; distinct state-owner/effective-performer rule restored after review and tested. Modeling actions picklist near top of capability/mission properties; Connections inspector traverses real core references and diagram placements.
- Source lint runs bounded max1worker/latestversion, caches accepted model checks, rejects stale diagnostics across reset. Source navigation uses layout sensor; root further added focus, declaration context and literal Find/Go to line (CtrlF/CtrlG/F3/ShiftF3), UTF-8 byte cursor offsets, invalid-draft preservation. Latest59 desktop test run session22577 currently building after tests; inspect result before claiming complete.
## Current native verification
Root exclusively owns Computer Use. Sky persistent bindings sky/studioWindow/studioState/studioDialog/dialogState. Refresh inventory before next action. CUA through node_repl @oai/sky skill26.901.41600, not disabledcua_repl. Native file dialogs sometimes return tiny16px screenshot first; use screenshot width>100 for coordinates. One observed action then fresh capture; typing after focus observation.
Verified checkpoint executable: D:/CodexBuilds/Capella2-release1-01a06e2e/ui-r1-r4-checkpoint/arcadia-studio.exe SHA256B24611C9AA7BF686BDA3FDD0B25BB0CE71715D5FED471287ECBAE2B0BF385F98; window395472. This predates scenario authoring, topology zoom and Find. AltF4 requested after SaveAs, fresh inventory needed to confirm closure. stderr empty and process responsive during run.
- Native1440x900 and1100x700: guide/search, persistent task/explorer navigation; selected capability correctly identifies placement; Modeling actions menu appears near top. SourceForSelection now reveals correct declaration, but it lands near viewport bottom without focus; root further focus/context patch pending native verification.
- Help→resize→Open saved capability model now automatically fits47% with all nodes visible: original cache/layout Fit bug fixed and native reverified.
- Connections outgoing extension→target capability→incoming capability/chain relationships works. Right panel retains connection tab during creation, hiding name fields; root now switches new element to Properties and added EditProperties(id) message for explicit property actions. Pending native check.
- Created empty OA Process Choose rescue response, involved Assess incident through +Work, used Branch/parallel to create Report distress / Respond to distress alternatives after it, condition Incident needs more information + else. Observed5newSequenceLinks,4branchnodes, rendered guard/alternative routes. At minimum width excessively horizontal graph; root now adds Fit/zoom (not yet native checked). Branch form scroll works and commit is atomic via same Command path.
- Saved full result through native SaveAs to ui-r1-r4-checkpoint/process-branch-ui.arcadia. On-disk source verified process name, exact guard and5SequenceLinks. No original fixture overwritten.
- Earlier R2 native extension fixture ui-r2-checkpoint/capability-extension-ui.arcadia preserved: Rescue in heavy weather extends Protect life at sea, condition Sea state is 6 or higher; exact source verified. Prior app closed.
- Original Capella six native benchmark workflows recorded in release-capella-workflow-benchmark.md. Original window524804 disappeared from fresh inventory this turn; do not assume open. Disposable workspace/sample under D:/CodexBuilds/Capella2-release1-01a06e2e; preserve it. Reopen if more comparisons needed.
## Active ownership
- Root: desktop app/forms/views/workflow/navigation/guide/source_navigation, topology.rs (released by worker after wrapper edits), state docs, exclusive CUA. Next: finish current59test/build result, copy new checkpoint, native Fit/zoom/sourceFind/scenarioauthoring/save-reopen; strict desktop Clippy. Root basicR5forms enums/refs/Event constructors already added; ergonomic state workflow still needed.
- release_capella_benchmark: ONLY behavior.rs + behavior/scenario.rs and benchmark docs. R4 authoring code complete, final focused checks/report then release. Root owns topology now. Shared behaviorEvent::is_submit guards both editors; root integrated. Event routing explicitly tags scenario commit so viewport events cannot redirect it.
- release_capability_core: R5 core model/validation/private state_validation.rs/references/session/transitions/projection/demo/coretests(exceptlanguage). Exact adopted contract release-state-contract.md: Event Signal/Time/Change, After/At, External/Local/Internal, typed trigger/effect refs,9newpseudostates, is_stable_state. Events/refs and state module compile; hierarchy/cardinality/focused tests underway. Source factory defaults preserved; Project::relate/Command::Connect use Local from EntryPoint. No desktop ownership.
- release_text_service_fix: language/persistence/tests/server/API/OpenAPI/language.rst. R5 source/API landed; previously16language+17HTTP/config+1unit passed, reST warning-free. Await core finalfreeze for final focused/strict checks; may read-only draft R3contract while waiting. R6 read-only report done: release-data-contract.md; not implemented.
- release_semantics_review: idle, focused review closed. Reuse after R5 / current graphical changes for fresh review.
## Required remaining work
R5 ergonomic state/event authoring/rendering plus finalcore/source verification; R6 data/contracts per design (lead still must freeze decisions); R3 fullsemantic drift and mapped existing-counterpart review; categories/persistentfilters/coverage; home/recent/recovery; optional hosteddesktop ETagopen/publish/save; explicit schema3 losslessV2migration; workedexamples and currentdocs; independent finalrequirements/correctness/UI/simplicity reviews; Windows/Linux fullchecks/nativeflows/packages. No V2 exclusion substitutes for release acceptance.
## Environment
Windows Rust1.98.1, target D:/CodexBuilds/Capella2-01a06e2e. Build cargo build --locked -p oa-desktop; tests cargo test --locked -p oa-desktop. Copy checkpoint exe before native launch so further builds can link. WSLUbuntu24.04 config per verification-v2-linux.md. Git unborn/untracked preserve. No disk blocker. Prior target/debug deletion rejected: do not retry/bypass. FinalMSRV/platform/clean-workflow checks remain.
## Usage-limit interruption recovery
All three workers stopped with explicit account usage-limit errors; no worker is still active. Root owns recovery/integration of their current files. R5 core+server full locked tests passed in root session11632 (exit0). Worker left behavior.rs declaring states module without writing states.rs; root is completing that module before the next build. Native currentcheckpoint disappeared from process/window inventory without stderr output; root relaunched preserved ui-scenario-checkpoint executable, new returned window1050736. No unsaved native work was lost (last work was only reopening saved fixture). Root just verified Find/Enter/F3/CtrlG+line1 with actual selection and minimum1100x700layout; Fit/scenarioauthoring remain next native checks.
## User correction: diagram hierarchy and ports — current priority
User reports architecture diagrams have become generic graphs and port semantics/rendering differ dubiously from Capella. Lead confirmed projection includes almost every relation between placed objects, Overview flattens every parent, and renderer has no boundary-port anchors. Reopening original Capella to inspect SAB/SDFB/OAB ownership and port workflows before freezing corrective contract. Preserve completed state editor work; state native verification is pending, not release complete. Current desktop:59 prior full regressions +4 new state authoring tests pass, cargo check passes after recovery; strict Clippy/current full63 tests not yet run. New state_scene.rs gives actual nested geometry, internal transition rows and vector pseudostate symbols. No fresh agents available: three existing agents still errored on account usage limits; root continues.
## Git adoption and hierarchy checkpoint
User explicitly authorized Git and optional worktrees. Existing .git was unborn; created codex/release1-engineering, added repository ignore/line-ending rules, and preparing the first source checkpoint. Future isolated implementation can use worktrees after this commit; read-only reviews do not need them. Nothing pushed or published.
Hierarchy correction implementation: dedicated FunctionalDataflow/Capabilities projections, architecture filters participants/work + exchanges, six focused demo views with architecture preferred on open/layer change, calculated boundary ports referenced by FE/BoundaryExchange, shared movement/hit/SVG anchors. Layout measures port room and 64px headers, orders root containers by actual exchange flow. Source/OpenAPI enum support updated. Functional/component port metamodel correction remains required; do not mistake improved rendering for semantic completion.
Verification: full locked core+desktop+server tests exit0 root session12111; desktop64 tests, new3 core projection regressions and1 desktop port hit/preview/SVG test. Earlier new group-movement test incorrectly used projected origin as stored MoveNode target; corrected to command's absolute persisted-coordinate contract, and shared layout/header measurement now avoids the native offset mismatch. Strict workspace Clippy passed before projection changes; rerun needed on this checkpoint. Native checkpoint ui-hierarchy-checkpoint SHA256D6055F659754E9159232483EAF9FA595C1D7F53683F8FB618D855F04B9C931A5 built/copied; native launch/verification next. Capella graphical window395654 remains a splash, console launcher14556 unresponsive; no new native port study claimed.
+36
View File
@@ -0,0 +1,36 @@
# R2 capability and mission core milestone — 2026-09-05
Status: the bounded R2 core contract is integrated and tested. Graphical authoring, source/API parity and native workflow verification are separate integration gates; this report does not claim the release or the larger semantic audit is complete.
## Frozen interface
- `Kind::OperationalMission`, `OaBody::Mission`: OA mission; default counterpart is `Kind::Mission` / `SaBody::Mission`. Both are root semantic records. Scenarios may use either mission as their context.
- `CapabilityInclude { source, target }`: including capability → included capability.
- `CapabilityExtend { source, target, condition: String }`: extending capability → extended capability. Blank/whitespace conditions produce warning `missing_extension_condition`; conditions also use the ordinary text-validity checks. Draft extensions remain editable.
- `CapabilityGeneralization { source, target }`: specific capability → general capability.
- `MissionInvolvement { source, target }`: OA Entity/Actor → OperationalMission; SA System/SystemActor → Mission.
- Existing `MissionCapability { source, target }`: OperationalMission → OA Capability, or SA Mission → SystemCapability.
- `TraceKind::Mission`: canonical OA OperationalMission → SA Mission. The transition planner creates this typed trace in either direction. Existing explicit Capability ↔ SA Mission mappings remain available and use Manual traces; Mission→OA now defaults to OperationalMission while reusing a uniquely existing explicit Capability trace.
All new relations reject cross-layer, wrong-family and self endpoints. Inclusion and generalization each reject directed cycles in their own graph, including transitive cycles. They remain independent of containment and of one another. Extension is conditional augmentation; no separate extension-cycle restriction was invented beyond the audited no-self rule.
The ordinary relation endpoint visitor performs transition mapping, reidentification, deletion and reference checks for all four new variants. New mission bodies have no hidden references. No new registry, transaction type or projection path was needed. Semantic relationships remain directed diagram edges; they do not create visual/semantic parenthood. The schema stays version 2 temporarily during interface integration; the release migration/version change belongs to the language integration worker.
## Verification actually run
With `CARGO_TARGET_DIR=D:/CodexBuilds/Capella2-01a06e2e`:
```
cargo test -p oa-core --locked --test workflows --test review_regressions --test process_diagnostics --test release_capabilities
cargo clippy -p oa-core --all-targets --locked -- -D warnings
```
Observed: **51 tests passed** (28 workflows, 15 prior regressions, 1 process diagnostic, 7 new capability/mission tests); strict core Clippy passed. Modified test files were formatted with Rustfmt edition 2024.
The new `release_capabilities.rs` exercises both perspectives and directions, exact endpoint preservation and extension condition propagation, atomic cycle rejection with redo/history retained, invalid condition rejection and undo, typed Mission trace defaults and legacy mapping reuse, complete mission-map dependency transitions, scenario/artifact/placement/trace references across UUID changes and deletions, counterpart survival after source deletion, and projection direction independently of nesting.
The first broader run exposed the old regression expectation that reverse SA Mission creation defaults to OA Capability. That test now explicitly preserves Capability as an alternative in both directions and verifies the new OperationalMission default. An initial full-core run also found the complete source fixture missing new relation kinds; the independently owned language worker is updating that fixture. This report intentionally does not count an unobserved final full-core/source run as passing.
## Remaining release obligations
Integrate the usable mission/capability graphical workflow, readable direction/condition labels and source/API constructors/specification. Then verify the actual native mission map workflow and conduct independent review. R1 contextual process/chain topology, R3 semantic drift/reconciliation, R4 reusable scenarios, R5 state/event semantics and R6 data contracts remain required by the release audit.
@@ -0,0 +1,99 @@
# Original Capella workflow benchmark — resumed, 2026-09-05
Status: **incomplete**. This record contains only actual observed UI behavior. The six requested capability, chain, scenario, state, data/interface and everyday-workflow comparisons have not been completed. The source/schema investigation remains separately recorded in `release-semantics-audit.md`; it is not a substitute for this runtime benchmark.
## Observed native UI
Original Capella 7.0.1 was restored from its minimized window. The open IFE sample displayed `[OAB] All Operational Activities and Entities` at 2560×1392. The screenshot showed Passenger, Aircraft, Crew, Personal Device, Ground Operator and Airline Company containers. Pilot and Cabin Crew nested inside Crew; their operational activities nested inside their participant boxes. Activities remained connected by named interactions crossing container boundaries. Selecting a path highlighted its activity boxes and connecting arrows in blue without discarding surrounding context.
The right palette grouped tools by Entities, Roles, Activities, Accelerators and Common. Visible tools included Operational Entity/Actor, Communication Mean, Role, Manage Role Allocation, Operational Activity, Interaction, Manage Activity Allocation, Activities from Mode/State, Elements from Scenario, Constraint and applied property-value groups. This is concrete evidence for contextual grouped authoring, explicit allocation operations and semantic insertion accelerators. It does not prove that any creation tool was exercised.
The bottom Semantic Browser followed the selected `Broadcast Movies` operational activity. Its three columns exposed referencing elements, the current element and referenced elements. Actual entries included Allocating Entity; Incoming Interactions; Operational Processes; four Realizing System Functions; Scenarios; Parent; All Related Diagrams; All Related Tables; Active in States (Cruising and Takeoff); and Outgoing Interactions. The browser toolbar offered Back/Forward, diagram visibility, limited expansion, sorting, follow-selection and requirements options. Several related diagrams and the System Functions–Operational Activities table were discoverable from this one selection.
Release acceptance tasks justified by these observations:
- Select a nested leaf and immediately see its performer, incoming/outgoing exchanges, process/scenario uses, active states, counterparts and related diagrams with navigation in both directions.
- Create or insert appropriate objects using task-grouped controls close to the current view; keep containment, allocation and diagram insertion distinct.
- Navigate from a selected activity through a realization and back, preserving view context; provide visible relationship names rather than unexplained endpoint-ID lists.
- Highlight a selected engineering path while retaining readable surrounding architecture.
These are observed-control comparisons, not a claim that the current Studio passes them.
## Interruption and recovery evidence
Selecting the project and issuing Explorer Ctrl+C/Ctrl+V to make a disposable copy left the original main window marked disabled. Repeated window inventories exposed no copy modal. Escape and one explicit activation/re-observation did not reveal a recoverable dialog. No original model edit or save was performed. The original `.metadata/.log` had no new entry from this attempt; its last entries were older transition class-loading messages, so they do not explain this behavior.
A separate Capella process was launched using a separate workspace. A filesystem copy of the sample was prepared without changing the original. The new process displayed Welcome and opened the Import wizard with General, Capella Example, Git, Install, Tasks and Team categories. The sample has **not** been imported into the new workspace yet.
Some state captures for the Capella target displayed pixels from a foreground application instead. Those mismatched captures were not used for input. Explicit activation and re-observation restored visible Capella. The next attempted import-category click returned: **Computer Use was stopped by the user with the physical Escape key.** All CUA stopped immediately. Further native input requires fresh user steering.
## Historical continuation handles (superseded by resumed checkpoint below)
- Original executable: `C:/Users/sorok/Downloads/capella-7.0.1.202503211540-win32-win32-x86_64/capella/capellac.exe`.
- Original window: `3673208`; original workspace: `D:/CodexBuilds/Capella2-v2-01a06e2e/capella-workspace`.
- Separate benchmark window: `2035890`, title `capella-workspace - Capella`; launch exec session: `75759`.
- Separate workspace: `D:/CodexBuilds/Capella2-release1-01a06e2e/capella-workspace`.
- Disposable sample copy: `D:/CodexBuilds/Capella2-release1-01a06e2e/capella-sample-source/In-Flight Entertainment System`.
- Last new-process UI: Import wizard, not yet completed.
Screenshots were captured and visually inspected through native Computer Use outputs in this task. No screenshot files were saved and no completed six-workflow benchmark is claimed. No Studio source changes or builds were part of this interrupted UI investigation.
## Resumed native benchmark — 2026-09-05, ongoing
Computer Use works after the desktop update. Fresh inventory had no Capella. Launched the existing executable with the isolated release workspace (exec session 55359, window 524804), imported the already prepared disposable IFE source using File > Import > General > Existing Projects into Workspace, and loaded its AIRD. The source is the disposable copy, not the original workspace.
### Mission/capability authoring (performed)
From the System Analysis workflow, expanded **Define Actors, Missions and Capabilities**. It offers automatic OA-capability transition, contextual System Actor creation from OA participants, contextual Capability or Mission creation from OA capability, contextual actor diagram, mission/capability map and participant traceability matrix. Created `[MCB] Studio benchmark` through the mission/capability map command. The diagram palette separately exposes Actor, Mission, Capability; Capability Exploitation, Involved Actor, Extends, Includes, Generalization; and existing-element insertion tools Capabilities, Missions, Relationships, Actors.
Actually created a Mission and Capability with palette then canvas position. The property dialog exposed capability pre/postconditions, inheritance, involved functions/chains, available states/modes, realized capabilities and involved components. Renamed the new capability `Deliver safe entertainment`. Existing-capability insertion opened a searchable available/selected tree chooser; double-clicking `Integrate Aircraft Constraints` transferred it to selected, and OK inserted a placement of that existing object. Created Includes by palette > source capability > target capability, then Capability Exploitation by palette > mission > capability. Both links appeared and selection identified `Abstract Capability Include` and `Capability Exploitation` respectively in Properties and semantic path.
Friction: plain `Mission 6`/`Capability 14` defaults require a follow-up rename. The dark theme renders nearly black external names and edges on dark gray, making engineering content much less readable than the palette. Large representation/property chrome consumes substantial room. Useful behavior to preserve: view-specific creation, explicit insertion versus semantic creation, endpoint tools with compatible-target feedback, and capability-level semantic involvement editing.
### Functional-chain involvement and control (performed)
Opened `[SFCD] Resume VOD Movie` using the SA diagram viewer's Functional Chain Description category. The view contains function involvements, including actor functions in blue and system functions in green, connected by functional-exchange involvements. Palette **Involvements** includes Function, Exchange, Exchange and Function, Functional Chain and Connect Functions; **Sequencing** includes AND/OR/IT controls, corresponding construct accelerators, Sequence Link, Function on Sequence Link, Exchange with Sequence Link and Exchange from Sequence Link.
Actually inserted an existing `Broadcast Audio Announcement` chain through Functional Chain > canvas > filtered same-layer chain chooser > OK. Capella created a **Functional Chain Reference**, rendered as a titled nested container with the reused chain's inner functions. Resizing that container revealed more nested content rather than copying the source functions. Added an OR control and connected an existing `Watch Video on Private Screen` involvement to it with a **Sequence Link**. The selected link has a distinct Condition field and Links reference field. The control has explicit OR/AND/ITERATE kinds. Thus functional exchange semantics and contextual precedence are separately authored, and chain reuse is a reference with nested visualization.
Release acceptance derived from this direct operation: insert existing work/exchange/chain from a contextual picker; create a branch control and guarded precedence without inventing a global functional exchange; visibly distinguish actual referenced work from its involvement; open/expand a reusable chain by identity; permit diagram geometry changes independently of semantic reuse. These observations do not establish that Studio currently passes the workflows.
### Scenario messages and reuse (performed)
Opened `[FS] Perform Audio Announcement` from the SA workflow's Function Scenario category. Four lifelines represent named actor/system functions, with exchange messages, execution bars and explanatory notes. The palette offers System Function, existing Functions, Functional Exchange with return branch, Functional Exchange, Reference, LOOP variants, Operand, Involved State/Mode, Duration and Exchange Context.
Actually used Reference by dragging across the four lifelines. The chooser offered two other Function Scenarios, filtered to the appropriate scenario type. Selected `Determine Passenger Service Availability`. The result is a `ref` region with its target name; Properties identifies a Use/Interaction Use with Covered Instance Roles and Referenced Scenario. No explicit role-correspondence dialog appeared in this operation. Right-clicking that reference > Open > its named scenario opened the referenced scenario in another tab. This is actual reference navigation, not only a visible menu item.
In the target scenario, chose **Functional Exchange with return branch** and clicked `Select Passenger Service` then `Handle Service Activation Requests`. The Create a Message dialog offered either a new named exchange or the compatible existing `PassengerVODServiceSelection` exchange with those endpoints. Chose the existing exchange. Capella created an additional call occurrence, dashed return branch and receiver execution bar, while preserving the original occurrence higher in the scenario. The new call's Properties shows the invoked exchange and explicit SYNCHRONOUS_CALL kind, with alternatives ASYNCHRONOUS_CALL, REPLY, CREATE, DELETE and TIMER. The observed workflow reuses the model exchange while creating scenario-specific occurrences.
Concrete Studio acceptance: create a message by choosing visible lifeline endpoints and an endpoint-compatible exchange; offer a call-and-reply action with paired occurrences; allow the same exchange more than once; render readable message names and execution spans; create a named scenario-reference region and open its target without losing the calling view. References and message occurrences need explicit semantic identity. ALT/LOOP operand creation, durations, exchange contexts and transition correspondences were not exercised in this pass.
### States, regions and event triggers (performed subset)
Opened `[MSM] IFE Operating Modes`. The sample includes Initial, Choice, Final, ordinary modes and a composite `Maintenance` mode containing `Region 1` and nested modes. The palette exposes Mode, State, Region, Initial, Join, Choice, Fork, Terminate, Final, Deep History, Shallow History and Transition. Created a **Deep History** H* node by clicking inside Maintenance's region; its semantic path confirms that region owns it. A subsequent attempt to connect it to Sustaining did not produce a visible edge; the cause was not diagnosed, and no successful history fallback is claimed.
Opened the existing Choice-to-Content Management transition's property dialog. It exposes Guard, Effects, realizations and a Triggers list containing `Load Digital Media` with a function icon. Added a Time Event using the trigger clock button, selected AFTER, opened its Opaque Expression editor, and entered `30 s` in the LinkedText body. After accepting the expression, event and transition dialogs, the trigger list displayed both `Load Digital Media` and `[AFTER]30 s`. The selected Time Event properties also showed the expression and AFTER kind. Thus this observed trigger set can refer to an involved function as well as an explicit timed event.
Useful behavior: container-based region ownership; recognizable pseudostate glyphs; transition-local guard/effect/trigger authoring; typed relative and absolute time-event choices. Friction: adding a short relative delay required three nested dialogs, and the updated edge label clipped the combined triggers. Studio acceptance is a concise transition editor supporting semantic trigger references, typed timed events and readable labels, with a clear region destination when adding state nodes. Change-event creation, full transition validity, orthogonal regions and history execution remain untested here.
### Data, interfaces and allocation (performed subset)
Opened `[CDB] In-Flight Entertainment Dictionary`. Existing classes render properties inside their class boxes, associations carry role names and multiplicities, and an enumeration shows its BUSINESS/PREMIUM/ECONOMY literals. The sample's own note says this particular dictionary is conceptual and is not connected to its functional analysis; that note is a sample limitation, not a Capella capability limitation.
Created `Interface 1` with the Interface palette tool. Interface Properties exposes visibility, a Super reference and allocated Exchange Items. Expanded the exchange-item creation variants: Event, Operation, Flow, Data and Undefined Exchange Item. Chose **Operation** and clicked the canvas, creating `ExchangeItem 1`; Properties confirms Exchange Mechanism OPERATION, alternatives EVENT/FLOW/SHARED_DATA, abstract/final flags, Super and Exchange Item Elements.
Used **Manage Exchange Item Allocations**, clicked the interface, and selected the existing ExchangeItem 1 in the familiar available/selected tree picker. After OK, the interface displays ExchangeItem 1 as an internal row while the separately placed exchange-item object remains visible. Selecting the internal row identifies a distinct **Exchange Item Allocation** pointing to the item. Its Properties include Transmission Protocol (unset, synchronous, asynchronous, unicast, multicast, broadcast) and Acquisition Protocol (unset, read, accept). This is direct evidence for representing an allocation by nesting rather than a noisy edge, without confusing it with semantic containment of the allocated item.
Studio acceptance: create an exchange item with an explicit mechanism, allocate it to an interface from a compatible-object picker, show the allocation as a nested named row, preserve the item identity across placements, and edit allocation-specific protocols separately from the item definition. Property typing/ranges/defaults/multiplicity edits, interface exchange realization, and exchange-category operations remain untested in this native pass.
### Everyday navigation and representation operations (performed subset)
The task-oriented workflow page and type-grouped diagram viewer were used repeatedly to locate and open MCB, SFCD, FS, MSM and CDB representations. Existing-object insertion consistently uses a searchable available/selected picker with tree/list display and semantic paths. The scenario-reference Open command was used successfully. A reused-chain container was resized to reveal nested content without changing the referenced model object.
Pressed **F9** on the newly created exchange-item allocation. Semantic Browser opened three panes: Referencing Elements; Current Element (including Parent = Interface 1 and All Related Diagrams = the CDB); and Referenced Elements (Exchange Item = ExchangeItem 1). This gives a navigable explanation of an allocation's owner, target and representations instead of only an opaque edge. The previously inspected scenario-reference context menu additionally exposes Show in Project Explorer (F8), Show in Semantic Browser (F9), Show Related Elements, Impact Analysis, Show/Hide, Layout, Reset Origin, Validate, Allocation Management and mass-editing/visualization actions. Except for F9 and Open, these menu actions were observed rather than executed in this resumed pass.
### Checkpoint and remaining comparison work
This pass materially advanced all five engineering feature comparisons with actual creation/editing, and exercised a subset of navigation; it is still **not** a completed six-area benchmark. Remaining direct comparisons include participant/include/extend variants; complete AND/OR/iterate branch topology; OA process equivalents; scenario operands/context/correspondences; state transition edge cases; data properties and categories; show/hide/selection productivity; and a current transition-preview round trip. Controls merely seen in a palette are distinguished from successfully operated controls above. No conclusions about Studio passing these acceptance workflows are implied.
CUA handed back to the lead for Studio verification. Original Capella remains open, window **524804**, launch exec session **55359**, maximized at 2560x1392. The active tab is the CDB with the allocation selected and Semantic Browser visible; other edited benchmark diagrams remain open. Changes are **unsaved** in the disposable sample. Re-inventory windows before future input; these are continuation hints, not durable identities. All screenshots were captured and inspected through the native Computer Use tool; no screenshot files were saved. No Studio code or build was changed by this benchmark agent.
+161
View File
@@ -0,0 +1,161 @@
# R6 data and interface contract proposal
Status: read-only design, 2026-09-05. No implementation, test pass, or native Studio acceptance is claimed here. This is the recommended integration contract for the lead to freeze before the R6 worker changes exhaustive enums. It extends the current typed model and transaction path; it does not introduce an instance database, expression evaluator, units engine, or plugin metamodel.
## Evidence and scope
Current `model.rs` has Information/Material/Energy/Event in one item-kind enum, primitive/enum/Record type definitions, fields with type/multiplicity/unit, and `Interface.items: Vec<Id>`. `references.rs` centrally maintains these links. The desktop uses the generic typed forms, including an item picker; its kind selector still mixes Event with physical nature. The R6 gap and release proof are recorded in `release-semantics-audit.md`.
The native benchmark in `release-capella-workflow-benchmark.md` actually created an Operation exchange item, an interface, and an allocation of that existing item. The allocation is independently selectable, has its own transmission/acquisition protocols, and appears as a nested row while the original item retains its identity. The dictionary displayed nested class properties, enum literals, association role names and multiplicities. Numeric/default edits and category operations were not exercised; do not report them as native observations.
Primary-source support: Capella Information defines independent exchange mechanisms, operation-parameter directions, typed numeric/string bounds/defaults, and structured types/associations. This supports the feature families, not every simplification chosen below. [Information.ecore](https://raw.githubusercontent.com/eclipse-capella/capella/master/m2/plugins/org.polarsys.capella.core.data.def/model/Information.ecore). Capella's interface allocation is a relationship with an allocated item and sender/receiver protocol properties; its container is the allocating interface. [CompositeStructure.ecore](https://raw.githubusercontent.com/eclipse-capella/capella/master/m2/plugins/org.polarsys.capella.core.data.def/model/CompositeStructure.ecore). Functional input/output ports are distinguished in the Arcadia reference, as already cited in the audit. [Arcadia metamodel](https://mbse-capella.org/resources/arcadia-reference/Arcadia%20Language%20-%20MetaModel.pdf).
The detailed rules below are explicit Studio design decisions. They are not claims of complete Capella/UML compatibility.
## Proposed persisted shapes
Retain existing headers, layer ownership, field IDs, relation IDs and `TypeRef`. All additions belong to the final schema/source version 3. Reference-bearing properties participate in the existing reference visitor, delete impact, transition closure and semantic review snapshot.
```rust
enum ExchangeItemKind { Information, Material, Energy } // remove legacy Event via migration
enum ExchangeMechanism { Unspecified, Flow, Event, Operation, SharedData }
enum ParameterDirection { Unspecified, In, Out, InOut, Return }
enum FieldStorage { Value, Reference }
enum DataValue { Boolean(bool), Integer(i64), Real(f64), String(String), Enumeration(String) }
enum DataTypeDefinition {
Boolean,
Integer { minimum: Option<i64>, maximum: Option<i64> },
Real { minimum: Option<f64>, maximum: Option<f64> },
String { minimum_length: u32, maximum_length: Option<u32> },
Enumeration { literals: Vec<String> },
Record { supertype: Option<Id> },
}
SharedBody::ExchangeItem {
kind: ExchangeItemKind,
mechanism: ExchangeMechanism,
supertype: Option<Id>,
}
SharedBody::DataType {
definition: DataTypeDefinition,
default: Option<DataValue>,
unit: String,
}
SharedBody::DataField {
type_ref: TypeRef,
minimum: u32,
maximum: Option<u32>,
unit: String,
direction: ParameterDirection,
storage: FieldStorage,
default: Option<Vec<DataValue>>,
}
SharedBody::Interface { supertype: Option<Id> }
enum TransmissionProtocol { Unspecified, Synchronous, Asynchronous, Unicast, Multicast, Broadcast }
enum AcquisitionProtocol { Unspecified, Read, Accept }
RelationBody::InterfaceItemAllocation {
source: Id, // Interface
target: Id, // ExchangeItem
order: u32, // presentation order within the source interface
transmission: TransmissionProtocol,
acquisition: AcquisitionProtocol,
}
RelationBody::DataAssociation {
source: Id, // Record DataType
target: Id, // Record DataType
source_role: String,
target_role: String,
source_minimum: u32,
source_maximum: Option<u32>,
target_minimum: u32,
target_maximum: Option<u32>,
source_navigable: bool,
target_navigable: bool,
}
```
`InterfaceItemAllocation` is deliberately distinct from the existing `ExchangeAllocation` (boundary exchange realizes a work exchange). The former is a normal relation record, so it already supports artifact traceability, selection, query, identity changes and undo. `Interface.items` must not remain a second writable list of the same fact. Use a derived `interface_items()`/`effective_interface_allocations()` helper wherever existing code needs the items.
New GUI defaults: Information + Unspecified mechanism; bounds absent; String length 0..*; type default absent; field 1..1, Unspecified direction, Value storage, no field default; no supertype; protocols Unspecified. Append an allocation after existing order values; ties are valid and sort by alias/UUID, so ordinary relation creation with order 0 remains deterministic. The contextual “Operation parameter” action sets In and the “Physical flow” action sets Material + Flow. Defaulting generic creation to an asserted mechanism would invent an engineering decision.
## Item mechanism, parameter and message semantics
- Nature describes what crosses the boundary; mechanism describes how its contract is used. Material/Energy + Flow is directly useful. Do not derive nature from fields or rename an Event item to Material. Material/Energy with Event/Operation/SharedData warrants an explanatory warning (often the author intended information *about* the physical exchange), not an unsupported categorical rejection.
- Unspecified mechanism is a valid draft with a located completeness warning. Flow is an ongoing value/physical transfer contract; Event is a notification; Operation is an invocation with input/output parameters; SharedData describes access to shared information. No mechanism schedules or executes behavior.
- Parameter direction is interpreted from the operation provider/callee's perspective: In travels on invocation, Out and Return on response, InOut participates in both. Only fields directly owned by an Operation item may set a direction other than Unspecified. Record fields describe structure and have Unspecified direction; they inherit their containing parameter's direction when viewed in a message.
- An Operation may have no parameters or no response parameters (a void operation). Allow multiple Out fields and at most one Return field across the effective inherited parameter set. An Unspecified operation parameter is a warning; it must not silently become In. In/Out/InOut/Return on non-operation content is a structural error; changing mechanism therefore requires resolving incompatible directions in the same transaction.
- Keep R4 call/reply pairing and endpoint/path checks. Add phase-aware value annotation checking only where the message actually carries an Operation item: Call values can address In/InOut; Reply values Out/InOut/Return. Unspecified parameters warn and remain addressable during authoring. Event/Flow exchange annotations do not gain operation directions. A Call without an Operation item is a warning, preserving existing generic call modeling; it is not reinterpreted or broken on migration.
### Necessary R4 reference seam
`MessageValue { field, expression }` currently identifies a field definition. When `origin` and `destination` both use the same `Coordinate` record, both have the same nested `latitude` field UUID. One UUID cannot disambiguate two argument values or enforce their possibly different directions.
Recommend adding `MessageValue.path: Vec<Id>` (default `[]`) with the existing `field` as terminal ID. `path` contains the enclosing DataField IDs from the direct item parameter down to, but excluding, the terminal field. Direct parameters have an empty path. Each hop must follow Value storage through a named Record's effective fields. Uniqueness is `(path, field)` rather than `field`. Aliases render each hop in text, and the picker displays `origin.latitude` / `destination.latitude` with both UUIDs maintained.
For old empty-path nested annotations, resolve exactly one valid path when possible during version-2 migration. If several paths exist, retain the old field-definition annotation and issue `message_value_ambiguous_path`; do not guess an argument or discard the expression. The editor offers explicit path selection. This unresolved legacy form has no asserted parameter direction, so only warn until resolved. New graphical annotation creation always writes a concrete path. This is a small R4 shape amendment to freeze with R6, not a second scenario engine.
## Types, values, multiplicity and units
Numeric ranges are inclusive; an absent bound means unbounded within the represented Rust numeric domain. Integer literals are signed 64-bit; Real literals are finite IEEE-754 binary64. Reject NaN/infinities, integer overflow, reversed ranges and defaults outside range. Do not compare integer ranges by converting to f64. The spec must explicitly avoid claiming arbitrary-precision decimal arithmetic. Canonical serialization retains a valid JSON/source numeric spelling with round-trip value equality.
String lengths count Unicode scalar values (`chars().count()`), not UTF-8 bytes or grapheme clusters. Enforce nonnegative ordered bounds and default lengths. Enum literals remain case-sensitive unique nonempty strings; a default must match a literal. Rename/remove of a literal is a transaction affecting defaults or is rejected if it would leave invalid values. No heuristic matching by display name.
`DataType.default` is a scalar value for Boolean/Integer/Real/String/Enumeration definitions. `DataField.default = None` means no explicit field default, and `Some([])` is an explicit empty collection allowed only at minimum 0. A nonempty field default is a sequence of typed scalar values with length in the field's multiplicity. A scalar field therefore uses a one-value vector. Type defaults supply the value of an individual element; they do not instantiate a required number of values or make a collection present. Field defaults override type defaults; a derived/read-only inspector row can show the effective element default. No numeric/string coercion; `Real(1.0)` is distinct from `Integer(1)`.
Record/object-reference literals and executable default expressions are outside this concrete scalar-default feature. Reject them explicitly instead of accepting opaque JSON or validating only part of a literal. A record may still be described completely by its typed fields and their scalar defaults. R4 `MessageValue.expression` remains a descriptive expression annotation, not a `DataValue` claimed to have been evaluated.
Unit text is an engineering annotation, not a dimension or conversion registry. Numeric named types can define a reusable unit. An empty field unit inherits the type unit; an explicit field unit equal to that unit is redundant but valid. A different nonempty unit on a named type with a nonempty unit is a warning and must be shown clearly, because the tool cannot prove conversion compatibility. Units on nonnumeric fields are preserved with a warning (legacy models permit them). Never convert bounds/defaults based on unit strings. Required physical acceptance can use `kg/s`, `V`, `A` and `degC` without introducing a units framework.
## Records, specialization, associations and ownership
Record specializations have at most one same-layer Record supertype. Effective fields are inherited fields followed by locally owned fields. Preserve inherited field UUIDs; show their origin/read-only ownership in nested rows. Reject cycles and local fields with a name already present in the inherited set; this release has no implicit shadowing/redefinition. Supertype removal can remove inherited fields from the effective payload and must trigger the existing annotation-pruning/impact path. Inheritance is not model containment: deleting a derived type never deletes its base or base fields.
ExchangeItem and Interface each get the same single-supertype pattern, constrained to their own family and layer, acyclic. A specialized item inherits fields and must preserve the base nature and any specified base mechanism; it may refine an Unspecified base mechanism. Incompatible changes are rejected as an explicit contract conflict. An interface inherits allocations; a local allocation of an already inherited item is rejected rather than creating ambiguous protocol overrides. Editing the original allocation changes all inheritors, with reverse usage navigation. Empty records/items/interfaces remain valid authoring drafts, with warnings where an allocated/carrying contract lacks definition.
Value storage means the field's values form part of the serialized/transported record value; Reference storage means a link to a separately identified record object. Reference storage requires `TypeRef::Named` pointing to a Record, permits no scalar default, and does not imply ownership/deletion of the target type. Model containment is always the DataField's actual `parent`; changing storage never reparents the referenced type.
Detect cycles in the graph of mandatory Value record fields (edges with minimum > 0), including effective inherited fields, and warn `record_no_finite_value`: such a type cannot have a finite fully populated value. This is a completeness warning rather than rejection because existing V2 record references lacked storage semantics and the model describes types rather than asserting an instantiated value. Optional (minimum 0) or Reference cycles are permitted without that warning. This distinguishes a linked-list/tree definition from an impossible required self-value while keeping saved models readable. Traversal must use a visited/path guard and bounded work; do not reject every recursive type just to simplify recursion.
`DataAssociation` is a binary reference relationship between Record types. It does not add contained fields, carry a payload transitively, or imply deletion of instance objects. Self-associations are valid. The source-end multiplicity says how many source instances may be related to one target instance, and vice versa; a multiplicity is not a count of model elements. Role names belong to the named ends. Navigation toward an end is permitted when that end's navigable flag is true. Empty roles are a completeness warning, invalid ranges are errors, and same-type self-associations require distinct nonempty role names when both ends are navigable. Associations remain distinct identified relations even when endpoint types match; duplicate role contracts warrant a warning rather than global source/target deduplication.
Do not add association composition/shared aggregation in this tranche without their ownership semantics: Value fields already supply nested value composition, and binary association supplies cross references. Exchange categories and persistent diagram filters remain a separate named release requirement; they must not be encoded as fake DataAssociations or fake exchanges.
## Interface allocation and port rules
The allocation source is an Interface and target a same-layer ExchangeItem; at most one direct allocation per source/target pair. Sender/receiver protocols belong to this relationship, not the global item. A nested interface row selects the allocation UUID, opens allocation protocols, and offers “Open item” / “Find usages”. Removing the row removes allocation only. The item and other interfaces' allocations remain. Protocol enums represent the choices actually benchmarked; no constraint is invented between protocol and item mechanism without evidence. An Unspecified protocol is valid and need not generate noise.
Provided/required interface relations retain their current meaning. Boundary/work exchange compatibility must use the effective inherited interface-item set, with the same-item or documented item-specialization acceptance rule. Recommendation: an exchange may carry a specialized item when the interface allocates its base (subtype satisfies base contract); the reverse does not satisfy a specialized contract. Compare UUID plus an explicit ancestry walk, never names. Reuse this rule in exchange allocation and port checks.
Functional ports on Activities/Functions are directed In or Out. Participant ports retain In/Out/InOut. Preserve legacy function InOut as an actionable warning so saved projects remain readable. New UI creation and Change direction controls expose only In/Out for work owners. For consistent REST/source draft behavior, core validation continues to report a warning for an explicit legacy/author-entered InOut; do not create an unpersisted origin flag or make input channel determine validity. Publish this draft allowance honestly in the spec.
Provide a transaction-level Split bidirectional work port action. Keep the original port ID as the selected primary direction, create a sibling opposite port, preserve owner/interface, remap source_port usages to Out and target_port usages to In, and preview ambiguous non-exchange references/artifact attachments rather than duplicating their meaning silently. The action must be undoable; input/output placements are ordinary port placements. An alternative strict ban on all new API InOut would require a persisted explicit legacy distinction or automatic load-time split, neither recommended for this minimal contract.
## Source, API, migration and lifecycle
1. Freeze final `schema_version = 3` and `arcadia 3` after R5/R6 shapes are agreed. Retain explicit readers for original schema/source 2 and V1. The two golden V2 fixtures must stay byte-for-byte unchanged. Treat existing staged version-2 R1/R2/R4 additions as a documented compatibility input, not as evidence that original V2 carried their semantics.
2. V2 Information/Material/Energy becomes the same nature with Unspecified mechanism, never guessed Flow. V2 Event becomes Information + Event. Old Integer/Real/String/Record constructors receive empty bounds/default/supertype; old fields retain UUID, parent, type, multiplicity and unit, plus Unspecified direction / Value storage / no default. Old interfaces gain no supertype.
3. Convert each old `Interface.items` entry into one InterfaceItemAllocation, with deterministic UUID v5 using the project UUID namespace and stable name `v2-interface-item:<interface-uuid>:<item-uuid>`. Generate a deterministic collision-free alias from the endpoint aliases/IDs, protocols Unspecified, and `order` equal to its original zero-based list index. Validate collision against *all* existing object IDs and aliases; fail a pathological collision with a located migration diagnostic rather than overwrite anything. This preserves the existing list's visible ordering without retaining two writable representations of membership.
4. Keep all old element/relation/diagram/node/trace/artifact identities. Migrating a file does not change stored revision until explicit save/import commit. Canonical output is version 3, so opening old source may show an explicit upgrade diff. The migration report lists semantic defaults and generated allocation IDs. Update V1 migration through the same V2-to-V3 semantic normalization rather than two divergent new-data migrations.
5. Text uses the existing readable constructor grammar, typed numbers/enum constructors, and unquoted aliases for references. Add `supertype` and MessageValue `path` to reference-aware fields; `direction`, `storage`, `mechanism`, protocols and typed DataValue constructors to the catalog. OpenAPI describes each exact closed object/enum, finite ranges, reference semantics and migration defaults. No JSON blob escape hatch. Keep the current REST query/transaction/candidate/ETag endpoints; new relation kinds are normal queryable records, not new services.
6. Shared helpers should compute effective fields, item ancestry, effective interface allocations and carried *field paths* once per validation snapshot. The public `carried_fields()` helper can derive the terminal-ID set for existing callers. Direct fields of either storage kind are carried, including inherited fields; recursive descent only follows Value record fields and never association/Reference targets. Make validation, picker compatibility, API diagnostics and transitions call these helpers to avoid divergent definitions.
7. Reidentify/remap visits every supertype, association/allocation endpoint and every MessageValue path entry. Required transition closure copies/remaps required types, supertypes, fields and interface allocation records; associations between included types are preserved, but do not cause a whole dictionary to be copied merely because a type has a reference association. Exact dependency policy is visible in the existing preview. R3 baseline/diff must include bounds, default values, units, direction, storage, protocols, specialization and end-role contracts.
8. Delete impact never removes a base type merely because its user is deleted. Deleting a base with surviving derived contracts or a named type with dependent fields must show those consequences and use the existing explicit cascading transaction policy; do not silently substitute String. Removing an interface allocation does not delete its item. Removing carried-field connectivity prunes or explicitly reports affected R4 annotations according to the current deletion policy; no dangling field paths survive a successful transaction.
## Observable release proof and focused regression plan
- Build OA Material fuel Flow and Energy electrical Flow with field quantities using reusable bounded types (`MassFlow`, `Voltage`), and an information Operation with In/InOut/Out/Return parameters using an enum and a nested record. Create these through contextual GUI actions, edit a field row, and read the resulting contracts without raw constructors.
- Allocate the same operation to two interfaces; show nested allocation rows and separate global item. Change one allocation's protocol and verify the other remains unchanged. Select a row, follow item/owner/reverse usages, attach a development artifact to the allocation, delete one allocation, undo, and reload.
- Define a base record plus specialized record with an inherited enum field, a distinct local bounded value, and an association to another record. Verify nested inherited rows, role labels/multiplicities, navigation and no noisy allocation arrows. Use a reused Coordinate record twice in operation parameters and verify scenario value pickers show both concrete paths.
- Exercise a Call with input values and paired Reply with output/return values. Rename/reidentify the record field and operation; annotations remain attached. Wrong-direction values, invalid field paths, wrong enum defaults, integer overflow, non-finite reals, reversed limits, invalid multiplicity and inheritance cycles produce located diagnostics and preserve the last accepted model.
- Verify empty types/interfaces, Unspecified mechanisms/directions, recursive optional/reference data and legacy InOut produce understandable drafts/warnings, without crashes or recursive traversal stalls. Run the work-port split and verify both directions, all exchange references, undo and saved source.
- Round-trip the same model through GUI save/load, canonical source parse/format, JSON, REST candidate/transaction/export/restart, and OA-to-SA/back transition preview. Query allocation/association records, reidentify their endpoints, and verify artifact links plus R3 semantic drift. Confirm invalid REST changes remain atomic with unchanged ETag/disk state.
- Keep original V2 golden migrations and add a small fixture containing legacy Event, InOut functional port, Interface.items, nested records, defaults absent and reused nested message field ambiguity. Verify deterministic new IDs, no lost old IDs/content, precise migration reports and canonical second-save stability.
- Native inspect at normal and compact widths: nested rows, long qualified field names, inherited origin, bounds/unit labels, protocol editor, source lint navigation and diagram association ends. Numeric entry must accept temporary editing text without committing invalid data or moving keyboard focus unexpectedly.
## Decisions the lead should explicitly accept or alter before coding
Recommended: separate nature/mechanism with honest Unspecified defaults; scalar/list-of-scalar typed defaults with finite numeric domains; one same-family supertype; reference associations and Value/Reference field storage; allocation as an identified relation; MessageValue path qualification; legacy InOut as a visible draft warning with an explicit split action. Each choice has a specified migration above.
The main bounded limitations are arbitrary-precision decimals, record/object-instance default literals, expression evaluation, dimensional conversion, association aggregation/redefinition and multiple inheritance. These must be documented as unsupported, not silently represented as unchecked text or described as completed Capella semantics. Their absence does not prevent the listed physical, quantity, operation, record, interface and traceability workflows. Exchange categories/filter work remains required elsewhere in the release plan.
@@ -0,0 +1,23 @@
# Diagram and port correction — adopted priority, 2026-09-05
User identifies flat graph diagrams and divergent port concepts as material defects. This is a release requirement, not optional visual polish. The prior data contract's generic InOut-port warning is insufficient.
## Evidence
Core `projection.rs` emits every relationship between placements; Overview removes all containment. Demo architecture mixes participants/work with capabilities, processes, chains and missions. `diagram.rs` paints every object, including a Port, as a large card; functional edges ignore their source_port/target_port geometry. Boundary exchanges disappear unless ports themselves are placed. This explains the reported divergence despite existing allocation-parent logic.
Official [diagram descriptions](https://mbse-capella.org/features.html) distinguish OAB/SAB allocation, functional dataflow, capability and state views. [Allocation documentation](https://raw.githubusercontent.com/eclipse-capella/capella/master/doc/plugins/org.polarsys.capella.ui.doc/html/05.%20Diagram%20Management/Allocating%20Functions%20on%20Components.mediawiki) explains nested allocated leaves and distinguishable inferred parent summaries.
Installed 7.0.1 Help, `4.05. Diagram Editor`, says function ports appear automatically with their displayed functions in synchronized diagrams. `7.1. Modeling accelerators` describes component exchange generation producing component ports and port allocations, and separate exchange-item propagation/synchronization to function ports.
The [FunctionalAnalysis metamodel](https://raw.githubusercontent.com/eclipse-capella/capella/master/m2/plugins/org.polarsys.capella.core.data.def/model/FunctionalAnalysis.ecore) distinguishes FunctionInputPort/FunctionOutputPort with incoming/outgoing item contracts; FE creation automatically creates those endpoints. ComponentPort has distinct Standard/Flow kind and orientation applicable to Flow, plus ComponentPortAllocation to allocated ports. These semantics must not be reduced to one bidirectional interface-bearing field.
Native Capella reopen attempted using the existing disposable workspace. Console launcher pid14556 has not exposed a targetable modeling window; graphical launcher also reported no targetable window. No new native port workflow has been observed yet. Existing native benchmark establishes nested OA activities and class/interface allocation rows but does not prove ports.
## Ordered implementation
1. Correct shared projection + SVG + canvas: architecture shows participant containment and allocated work with meaningful exchange edges; dataflow shows work hierarchy; capabilities have a dedicated view. Keep an explicitly named all-relationships view for exploration. Do not change semantic objects just to remove clutter. Ports derive as small, selectable boundary anchors of visible owners, and exchanges terminate on the actual port. Computed links after collapse must not invent port identities. Group movement, Fit, SVG and hit testing use this same geometry.
2. Correct authoring/model contracts: distinguish functional In/Out contracts from component Standard/Flow ports; function-port exchange items; explicit component→function port allocation and direction/owner checks. Creating a functional exchange creates or reuses compatible ports atomically. OA interactions remain activity-to-activity without fake functional ports. Preserve legacy IDs/prose/interface references in the explicit schema3 migration, with reviewed resolution for incompatible old InOut work ports. Implement source/form/API/reference/transition parity with this change, not a canvas-only workaround.
3. Contextual insertion/allocation and grouped edge filters, orthogonal routes and labels. Default demo/worked examples must communicate these modeling distinctions immediately. Show allocation/containment explanations and derived-summary styling. Verify nested movement/collapse/reveal, creation, port selection/connection, exchange allocation, undo, save/reopen and SVG on actual native UI at default/minimum size.
Keep R5 state editor's current code/tests; its native acceptance remains pending. R6 data contract and release audit must be amended around step2 before implementation. All prior first-release requirements remain active.
+121
View File
@@ -0,0 +1,121 @@
# R1 / R2 / R4 language and API integration — 2026-09-05
Status: these bounded source/API milestones are implemented and verified. This
is not first-release completion; native authoring and remaining R3/R5/R6,
lifecycle, migration and final independent reviews remain required.
## Current contract
- R2: `oa_mission`, Mission traces, include/extend/generalization and mission
involvement have canonical source and OpenAPI counterparts. Conditional
extension preserves its exact condition. The broad fixture covers all 28
element kinds and all 20 current relation kinds (including R1 SequenceLink).
- R1: Control Choice/Merge/Fork/Join/Loop and SequenceReference use typed source;
`sequence @alias` is a real reference field. The OA and SA round-trip fixture
contains work contributions, parallel/alternative paths, an explicit loop,
a reused sequence and guarded contextual links. Recursive reuse and invalid
reference spelling reject atomically.
- R4: scenario viewpoints, every message kind including Timer, call correlation,
carried-field expressions and ScenarioUse bindings have canonical source and
closed OpenAPI payloads. Reference fields are `scenario`, `reply_to`, `field`,
`referenced` and `local`; viewpoint/message-kind enum fields remain readable.
Native parser fixtures cover both strict work viewpoints, call/reply reversal,
create/delete order, timers, values and a reused scenario. No expressions are
evaluated or silently converted to literals.
- `docs/language.rst` now specifies the current R1/R2/R4 constructors, ownership,
topology/message/reuse constraints, traces, compatibility and located lint.
`docs/api.rst` and `docs/openapi.json` expose the matching service contract.
The rendered language/API HTML is regenerated from those reST sources.
## Compatibility is deliberate and testable
Schema 2 remains a temporary integration header. Omitted old Scenario viewpoint
hydrates as MixedLegacy in **both source and JSON**, rather than applying a
new GUI factory's stricter interpretation. Missing Exchange message fields
hydrate as Asynchronous, no reply correlation and no value annotations. The
V1 migration constructor supplies the same explicit defaults.
The original V2 coastal rescue source and JSON are preserved under
`crates/oa-core/tests/fixtures/v2-coastal-rescue.*`. Do not regenerate them from
the new demo. The golden regression compares the exact original JSON against
the upgraded model after removing only the newly added defaults: every other
persistent field remains equal. Original source and JSON produce the same
model; canonical source records explicit compatibility choices and round-trips.
The final distinct release schema and explicit V2 migration are still required
after R5/R6 interfaces freeze. Current serde defaults are staged compatibility,
not evidence of that future adapter. New schema-3 contracts must not silently
inherit these missing-field defaults without an explicit decision.
## Verification actually observed
Target: `D:/CodexBuilds/Capella2-01a06e2e`, Windows Rust 1.98.1.
```
cargo test -p oa-core --locked
cargo test -p oa-server --locked
cargo clippy -p oa-server --all-targets --locked -- -D warnings
```
Current combined core: **83 passed** (15 language, 4 admission/lint, 7
capability, 6 topology, 7 scenario, 15 prior regressions, 28 workflows,
1 process diagnostic). Server: **16 HTTP/configuration tests + 1 deterministic
prepared-commit test passed**. Strict server all-target Clippy passes; the core
dependency is checked as part of that command, while the core owner separately
ran strict all-target core Clippy. Owned Rust files pass Rustfmt. Language/API
reST builds halt on warnings and both completed without warnings.
The actual HTTP suite imports the new mission/branching chain model, edits a
SequenceLink guard, exports equivalent readable source, filters by the new
relation kind and restarts from disk. A separate actual HTTP case imports the
original V2 JSON, rejects a malformed richer source without advancing its
revision, edits a typed call value, retains reply references, exports equivalent
source and reopens the accepted envelope after restart.
TS1 parser/API responsiveness evidence remains in
`harness/release-text-service-audit.md`: exact formerly stalling 638,689-byte
source rejected in 0.050 s; concurrent native/legacy JSON catalog reads and a
valid-candidate/rename race verified on the optimized native server. Those exact
wall times were measured at the R2 checkpoint. The same rejection/concurrency
transport regressions pass after R4; no new throughput guarantee is inferred.
No Computer Use operations were performed by this worker. No probe server or
test process is intentionally left running. Current first-release changes have
not yet had final Linux, container, release-toolchain or independent review
verification; prior V2 platform evidence must remain labeled as prior evidence.
## R5 state/event source and service integration checkpoint
R5 shapes are coordinated with the core worker: nine additional StateKind/Kind
vertices, Event Signal/Time After/At/Change, and StateTransition
`transition_kind`, `triggers`, `effects`. Language uses `oa_`/`sa_` snake-case
declarations, alias references in the new lists and a typed transition-kind
word. The existing generic constructors handle the rest; no separate parser,
event registry or service route was introduced. Core serde/factory defaults
provide staged External/[]/[] compatibility, and the original V2 golden test
now excludes only those added defaults when proving every original field
remains identical. Trigger/guard/effect strings are explicitly compared.
The all-kind parity fixture includes all 38 kinds. A separate OA/SA source test
exercises every new vertex, all Event bodies, every TransitionKind, Unicode
and quoted prose, invalid typed enums/references, and old-field defaults.
OpenAPI now names StateKind, EventBody, TimeEventKind and TransitionKind;
language section 4.4 records the approved state semantics and API documents the
ordinary batch/reference lifecycle. Header remains **temporary schema 2**;
the explicit final schema-3 migration is still required after R6.
Observed at this checkpoint: 16/16 language tests; 17/17 HTTP/configuration
tests plus the deterministic Store unit; strict all-target server Clippy.
The actual HTTP event test imports source, creates an Event and changes its
transition in one batch, reidentifies event/payload UUIDs, retains exact prose,
checks stale ETag 412 and wrong-layer rollback 422, queries Event records,
exports equal source, removes trigger/effect/payload references and verifies
the last removed trigger leaves descriptive intent, then restarts from disk.
A follow-up added a located warning assertion for empty Time expression.
Its rerun intersected the core worker's deliberate state-topology integration:
`lib.rs` declared `state_validation` before the new file was saved, producing
E0583. No source/service workaround was added. Await final core topology freeze,
then rerun language+admission tests, server regression and strict Clippy.
Both reST outputs already render with halt-on-warning enabled; an initial short
section underline warning was fixed and successfully re-rendered.
+49
View File
@@ -0,0 +1,49 @@
# First-release native UX audit — 2026-09-05
Independent, bounded review of the existing V2 executable against the new first-release objective. No application source or existing model was modified by this review. Computer Use used the supported `@oai/sky` native API; screenshots were captured and visually inspected after each meaningful action.
## Environment and scope
- Windows packaged executable: `dist/ArcadiaStudio-Windows/arcadia-studio.exe`, SHA-256 `e2aec2ac935e270c6185729cbb76f8323b381654c04dbde7aae90c4628a98a20`.
- Actual application window 2560154. Startup client 1440×900; compact client 1100×700, changed through the native system-menu Size operation.
- Exercised startup demo, guide, New, first architecture view, entity creation/properties, allocated activity creation, minimum layout/Fit, model search, invalid-property rejection/Revert, native save/open and normal close.
- Disposable UI-authored fixture: `D:/CodexBuilds/Capella2-v2-01a06e2e/final-ui-review/release-native-audit-new-project.arcadia`.
- Original Capella window 3673208 was left untouched. The review app was closed using Alt+F4; a subsequent process query found no `arcadia-studio` process. Native session ownership is released.
- This pass did not launch the server or re-exercise all OA/SA semantics. It is additional first-release UX evidence, not a replacement for the V2 verification reports.
## Findings requiring first-release action
### R1 — Built-in help does not yet satisfy the new navigable tutorial requirement
**Priority: P1 requirement gap.** Clicked Engineering guide and read both its initial viewport and remaining content. It contains seven static cards plus Open coastal rescue example. The concepts are accurate and concise, but there is no table of contents, topic navigation, help search, practical sequence of controls for common modeling tasks, contextual topic access or shortcut/reference section. The sidebar Search is model-element search and does not search help. `views.rs::guide` confirms the seven-card implementation.
A first-time engineer is told to allocate activities, connect exchanges and review transitions without being shown the actual sequence of controls or the distinction between semantic ownership and a diagram placement. The new objective explicitly requests easy navigation/exploration and clear information on common modeling scenarios and application use.
**Feasible fix:** a small built-in article/topic browser with search and related topics, a first-project walkthrough, OA/SA boundary and allocation explanations, transition review tutorial, scenarios/states/data/interfaces, traceability, text/lint/recovery, files/shortcuts and API integration. Keep it native and available offline; reuse concise content instead of adding a general documentation framework. Add contextual links where the user already encounters these operations.
### R2 — Open/New/Demo forget the actual window size; Fit becomes wrong
**Priority: P2 reproducible functional defect.** At the minimum size, an authored entity with one allocated activity fits correctly at 95%. Saved the model through the native Save As dialog, then Ctrl+O reopened that exact file. The app immediately displayed 150%, with the nested activity and parent clipped under the right inspector and below the canvas. Clicked Fit and took an additional fresh screenshot: it remained 150% and clipped. Thus Fit itself no longer repairs the view until another physical resize event updates app state.
The fixture has two elements, one Allocation and two diagram nodes. File bytes confirm those records; no malformed geometry is involved. `app.rs::reset` replaces the complete application with `Self::with_project(project)`, whose `window_size` is the launch default 1440×900. `fit()` uses that field. The native window remains 1100×700 and does not need to emit another resize when a file opens.
**Fix:** preserve the current native `window_size` across project replacement, then fit. Apply this to every reset caller (New/Open/Demo). Add a regression that sends WindowResized, resets/loads a model, then checks Fit uses that preserved viewport. Reverify saved fixture opening at minimum and default sizes.
### R3 — At minimum size, search results are initially entirely below the visible sidebar
**Priority: P2 usability.** At 1100×700, the eight navigation rows and creation controls place Search at the very bottom. Typing `rescue` produces no visible result. Scrolling the entire sidebar then reveals Rescue coordinator, while the perspective switch and upper navigation disappear. This is functioning search, but a frequent navigation action gives no visible feedback until the user discovers the outer scroll. `views.rs` puts navigation, creation, search and all results into one scrollable column.
**Feasible fix:** reserve useful visible height for search results and provide a compact navigation treatment at short window heights, or separate the explorer from navigation. Also give an explicit no-results state. Preserve usable hit targets and verify both supported sizes. This matters more as the new release grows its modeling and help features.
## Observed strengths and recovery behavior
1. Startup is reliable and visually intentional: the rich demo opens with 39 objects, 23 links and zero checks; nesting is understandable.
2. New gives a useful empty-state instruction and Create architecture view button. Creating the view immediately produces an editable OA view.
3. Entity → At root creates and selects a visible node. Renaming it Rescue coordinator and Apply changes updates the diagram. Choosing Activity while that participant is selected changes the second create action to Allocated; clicking it creates an Allocation and visibly nests the activity. This is a clear, efficient interaction worth preserving.
4. At the minimum size before reopening, Fit renders the authored nested pair fully. The toolbar and inspector remain reachable with appropriate panel scrolling. There was no general overlap of controls.
5. Entered `bad alias` in Stable source alias. Apply rejected it without changing the accepted node (`invalid_alias: Invalid or reserved alias 'bad alias'.`). Revert restored `new_activity`. This recovery works. The feedback is currently only a small footer line; field-local guidance and valid alias examples would help but are lower priority than R1–R3.
6. Native Save As accepted the disposable absolute path, reported All changes saved/Project saved and produced canonical text containing the expected two elements, allocation and placements. Ctrl+O reopened the exact file with two objects/one link/zero checks; semantics were preserved despite R2's viewport regression.
## Review disposition
First-release UX completion is not yet proven. R1 is an explicit new requirement gap; R2 is a verified existing defect; R3 is a practical compact-layout navigation problem. No crash, accepted-model corruption or destructive recovery was observed in this bounded pass. Root was notified of R1 and R2 immediately; this report completes the independent audit and provides concrete next verification steps.
+63
View File
@@ -0,0 +1,63 @@
# R4 reusable scenario and message core milestone — 2026-09-05
Status: bounded core implementation and focused verification complete. Source/API migration, graphical authoring/rendering, native workflows and independent review remain integration gates. This provides explicit modeling semantics, not message execution or simulation.
## Frozen interface
- `ScenarioViewpoint`: OperationalActivity, ParticipantInteraction, Functional, BoundaryInterface, MixedLegacy. `SharedBody::Scenario` adds `viewpoint`. New OA scenarios default to OperationalActivity; new SA scenarios default to Functional. The demo explicitly uses BoundaryInterface because its lifelines represent participants.
- Work viewpoints use Activity/Function lifelines and the corresponding Interaction/FunctionalExchange. Participant viewpoints use OA Entity/Actor/Role or SA System/SystemActor lifelines; their exchanges can use participant ports or allocated work, with the existing endpoint/effective-performer agreement rules. Wrong declared viewpoint/layer or represented family rejects.
- `OccurrenceBody::Exchange` adds `message_kind: MessageKind`, `reply_to: Option<Id>` and `values: Vec<MessageValue>`.
- `MessageKind`: Asynchronous, Call, Reply, Create, Delete, Timer `{ expression: String }`. A timer is a local lifeline event: sender required as an editable reference; receiver absent or equal to sender; no global exchange or carried values. Missing duration/deadline expression warns.
- `MessageValue { field: Id, expression: String }`: contextual expression annotation bound to an actual carried DataField identity, including nested named-record fields. It is not a claim that expressions are evaluated or literal values type-checked. Duplicate/unrelated fields reject; empty expressions warn.
- `LifelineBinding { referenced: Id, local: Id }` and `OccurrenceBody::ScenarioUse { scenario: Option<Id>, bindings: Vec<LifelineBinding> }`: same-layer, same-viewpoint reuse with explicit one-to-one lifeline correspondence. Bound lifelines represent the same semantic object, or an explicitly realized operational role. This is reuse of existing semantics, not an implicit generic-template substitution. Missing target/bindings warn; wrong context/identity, duplicates and recursive reuse reject. MixedLegacy viewpoints remain reviewable without inventing a precise historical viewpoint.
## Behavioral rules
A Reply references a Call in the same scenario, reverses its sender/receiver, and follows it on a guaranteed containing branch path. A call inside one alternative or optional loop is not treated as an unconditional call after the fragment. A reply can reuse the call's exchange with reversed direction, or use a separate reverse-direction exchange. Sequential duplicate replies reject; mutually exclusive branches are not silently linearized. Only Reply has `reply_to`.
Create/Delete check structurally possible co-execution and order: a created receiver cannot already be used earlier on a possible path, and a deleted receiver cannot be used later. A conditional branch and a following sibling can co-execute, as can Parallel operands. Distinct Alternative operands are mutually exclusive. These checks do not solve arbitrary guards or execute traces. Call/reply/lifecycle/timer kinds belong to scenarios; ordinary process/chain exchange contributions remain Asynchronous.
Reuse and call/value references participate in the common visitor, reference closure, transition mapping and deletion. Scenario viewpoint maps OperationalActivity↔Functional and ParticipantInteraction↔BoundaryInterface. Reusing one scenario twice preserves one referenced scenario identity. Explicit loop fragments model repetition; recursion in scenario references is rejected.
Deleting a referenced scenario keeps its caller use as an incomplete draft and removes invalid lifeline bindings. Deleting a call clears reply correlation; deleting a bound lifeline prunes its binding. Deleting a carried payload/item also removes annotations for fields that cease to be carried, even if those fields survive in a shared record type. `validation::carried_fields(p, relation)` is the shared query for these direct/nested fields and graphical picker filtering.
## Compatibility during integration
Schema version stays 2 temporarily. Missing serialized Scenario viewpoint defaults to MixedLegacy; missing message kind/reply/value fields default to Asynchronous/None/empty. These defaults preserve old model information while clearly flagging unreviewed viewpoint semantics. The language/persistence owner is responsible for explicit lossless V2 migration and the eventual release schema/version change. The default factory and old-input compatibility behavior are intentionally different.
## Verification actually run
Using `CARGO_TARGET_DIR=D:/CodexBuilds/Capella2-01a06e2e`:
```
cargo check -p oa-core --all-targets --locked
cargo test -p oa-core --locked --test release_scenarios
cargo test -p oa-core --locked --test workflows --test review_regressions --test process_diagnostics --test release_capabilities --test release_topology
cargo clippy -p oa-core --all-targets --locked -- -D warnings
```
Observed **7 scenario tests plus 57 prior focused core tests passed**, strict core Clippy passed, edited Rust sources/tests formatted. Evidence includes both transition directions; shared reuse from two callers; wrong/recursive bindings; call/reply direction, branch order and correlation; lifecycle/timer contracts; carried-field and nested-record values; every conversation element/relation UUID reidentification/deletion with exact undo; reused-scenario/lifeline deletion retaining callers; and loops distinct from recursive reuse.
The annotation cleanup test initially failed when deleting a payload disconnected a surviving nested field. The core deletion path was corrected and the full scenario suite rerun successfully. No remaining failing focused test is waived. R3 full semantic-drift reconciliation, R5 states/events and R6 data contracts remain required; native authoring and rendering of these R4 constructs is not established by core tests.
## Independent review corrections — 2026-09-05
Reproduced all three findings in `release-semantic-review.md` by running its separately compiled reproduction package. The original implementation wrongly reused call-dominance ordering for conflict detection. It now keeps `guaranteed_before` for Call→Reply correlation and uses separate common-ancestor co-execution/order for conflicting replies and lifecycle operations. Optional/Alternative-branch reply followed by a second reply and conditional deletion followed by use reject. Two Parallel replies or parallel delete/use reject. Legal mutually exclusive Alternative replies and delete/use operands remain accepted.
Role endpoint compatibility now recognizes an explicitly assigned operational role. A distinct unassigned role realized by the same participant is incompatible; an assigned abstract role remains valid when concrete realizations are ambiguous. Three public helpers share these semantics between core validation, scenario-use binding checks and graphical pickers:
```
validation::message_endpoints(&Project, &OccurrenceBody) -> Option<(Id, Id)>
validation::lifeline_matches_endpoint(&Project, line: Id, endpoint: Id) -> Option<bool>
validation::semantic_representation_compatible(&Project, representation: Id, semantic: Id) -> Option<bool>
```
An unresolved reply correlation has no inferred endpoints. `None` compatibility means a missing reference or unresolved concrete performer, never an arbitrarily chosen realization.
Observed after fixes: **68 focused core tests passed** (11 scenario plus 57 prior), strict core all-target Clippy passed. The independent reproduction now reports `duplicate_reply_after_optional: 1 error (duplicate_reply)`, `use_after_optional_delete: 1 error (lifeline_lifetime)`, and `valid_role_lifeline: 0 errors, no diagnostics`. Four new regression tests cover conditional/parallel/exclusive paths, role assignment versus realization/ambiguity, and effective forward/reverse reply endpoints. Graphical picker changes and independent re-review belong to the lead's integration gate.
### Repetition follow-up
Fresh review exposed two remaining silent repeated-execution risks. Added `reply_repetition` warnings when a Reply has an enclosing Loop that does not also enclose its correlated Call, checking every nested scope. A Call and Reply inside the same repeating scope remain valid. Added `lifeline_repetition` warnings for repeated Create/Delete without an ordered complementary lifecycle message in the same operand. This preserves coherent create→use→delete per iteration while diagnosing `[use, delete]` on the next iteration, creation without deletion, and conditional cleanup that may be skipped. Free-text guards provide no proven iteration bound, so these are conservative warnings rather than simulated execution results or a blanket prohibition of loops.
Observed after this follow-up: **71 focused core tests passed** (14 scenario plus 57 prior), strict core all-target Clippy passed. The independently compiled reproduction now emits `reply_repetition` for `one_call_with_repeated_reply` and `lifeline_repetition` for `use_after_delete_next_loop_iteration`; both models remain editable with explicit warnings. The original conditional-path errors and valid Role scenario retain their corrected results. Three regression groups cover outside/same/nested call scopes, both missing lifecycle complements, balanced per-iteration lifetime and optional cleanup. No serialized shape changed.
+145
View File
@@ -0,0 +1,145 @@
# 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:
```powershell
$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:
```powershell
$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:
```text
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:
```text
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:
```text
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.
+135
View File
@@ -0,0 +1,135 @@
# First release OA/SA semantic audit — 2026-09-05
Read-only review of the new first-release objective in `81e84f53-2b51-4151-9e34-59414bda8b2d/goal-objective.md`, the current core, and official Arcadia/Capella references. This is a release planning audit, not a test pass or runtime assessment. No implementation files, builds, or native UI were touched. The old V2 scope exclusions are historical decisions, not authorization to omit OA/SA release functionality.
## Conclusion
The current implementation has a useful coherent foundation, but its 27 element kinds and 15 relation kinds are not yet feature-complete OA/SA. The largest holes are contextual process/chain topology, capability/mission relationships, meaningful iterative semantic updates, reusable/typed scenario behavior, and fuller state/data contracts. Keeping those absent while changing the version number would preserve the prototype boundary rather than fulfill the new objective.
“System Architecture” is interpreted as the System Analysis perspective containing the System of Interest, external actors, functions, exchanges and interface contracts. Internal logical components, physical implementation and deployment belong to the explicitly deferred later perspectives. The new objective does not require copying every Capella implementation class or every Eclipse extension.
## Already present, and worth retaining
- `model.rs` separates semantic elements, typed relationships, diagram placements, canonical cross-layer traces and artifact references. `session.rs` and `references.rs` centralize validation, identity remapping, deletion cleanup and undo. These are suitable release boundaries.
- OA entities/actors/roles, activity decomposition and allocation; SA System/actors/functions, missions/capabilities; typed items, records, ports/interfaces; basic nested scenarios and state machines are real model data, not presentation-only constructs.
- OA communication allocation already exists: `validation.rs:969–986` accepts BoundaryExchange → Interaction as well as the SA FunctionalExchange case; `1357–1403` checks allocated endpoint performers and carried items. Earlier SA-only wording in `RelationKind::hint` and `docs/language.rst:230` understates the implementation. This is a contract/discoverability correction, not grounds to add a duplicate OA relation.
- Work decomposition and performer allocation remain independent. Keep containment/allocation projections, stable placement identity and separate hide/delete operations. Do not introduce SA internal components just to make nesting more elaborate.
## Release-critical additions
### R1. Processes and chains must represent contextual paths, branching and reusable contributions
**Evidence.** Official Capella FunctionalAnalysis defines function involvements, chain references, control nodes and sequence links in OA and SA. Arcadia distinguishes the global dataflow from contextual paths. [FunctionalAnalysis schema](https://raw.githubusercontent.com/eclipse-capella/capella/master/m2/plugins/org.polarsys.capella.core.data.def/model/FunctionalAnalysis.ecore), [Arcadia Q&A](https://mbse-capella.org/arcadia-qna.html).
**Current limitation.** `OaBody::Process` and `SaBody::FunctionalChain` store only `steps: Vec<Id>` (`model.rs:187–205`). `validation.rs:944–952` expressly rejects every direct sequence occurrence except Exchange. `validate_sequence` at 769 only walks a linear list, checking consecutive exchange endpoints. There is no explicit function involvement to hold a context-specific contribution, no guarded split/join, no chain reference, and no sequence topology independent of global exchanges. A rescue path with parallel position assessment and asset preparation cannot be modeled as one process/chain without inventing a false linear order or moving the engineering information into a scenario.
**Minimal coherent design.** Preserve durable involvement IDs. Add work involvement, control node and reusable sequence-reference variants; add explicit contextual links with guard text and optional referenced semantic exchange. Links belong to one process/chain and connect its involvement records, never raw functions. Keep a simple linear authoring action that generates this same topology. Validate scope, endpoint correspondence, dangling refs and recursive sequence references; diagnose unreachable or ambiguous starts/ends while allowing incomplete editing. A scenario remains a distinct time-oriented representation. A flat `steps` list can remain a presentation order, but must not masquerade as branch topology.
**Release proof.** OA parallel/alternative process with a reused subprocess; transition to SA chain; edit branch guard and per-function contribution; graph/text/save/reopen/delete/undo preserve all involvement identities. No implicit changes to global dataflow.
### R2. Capability relationships and mission participation need first-class semantics
**Evidence.** Capella's Interaction schema has capability include, extend and generalization; ContextArchitecture has MissionInvolvement. Arcadia also names operational missions, although Capella's OA package does not expose a matching Mission class. [Interaction schema](https://raw.githubusercontent.com/eclipse-capella/capella/master/m2/plugins/org.polarsys.capella.core.data.def/model/Interaction.ecore), [ContextArchitecture schema](https://raw.githubusercontent.com/eclipse-capella/capella/master/m2/plugins/org.polarsys.capella.core.data.def/model/ContextArchitecture.ecore), [Arcadia metamodel, missions/capabilities section](https://mbse-capella.org/resources/arcadia-reference/Arcadia%20Language%20-%20MetaModel.pdf).
**Current limitation.** The complete `RelationKind` catalog (`model.rs:531–647`) has none of the three capability relationships or participant→mission involvement. `parent_permits` allows capability containment, which is not a replacement for inclusion, conditional extension or specialization. OA lacks a mission kind entirely. Engineers cannot express reusable common capabilities, conditional degraded behavior at capability level, or who participates in a mission independently of a capability.
**Minimal coherent design.** Add typed CapabilityInclude, CapabilityExtend (condition), CapabilityGeneralization and MissionInvolvement. Define direction precisely in UI and reST; same-layer/same-capability-family endpoints, no self-reference, inheritance/include cycle checks, and explicit extension-condition diagnostics. Add OperationalMission with mission→capability and participant→mission links, clearly documented as Arcadia method support rather than byte-for-byte Capella OA conformance. Keep visual group containment distinct. Transition these relationships using mapped endpoints; do not turn include into parenthood.
**Release proof.** Build a mission map with actor participation, common included capability and conditional extension in both layers; demonstrate cycle rejection and readable diagram/source relationship navigation.
### R3. Transition review must detect and handle semantic drift beyond names
**Evidence.** Capella documents conservative iterative transformations over ownership and related elements, with a proposed-result comparison against the target. The user additionally requires intuitive transitions in both directions. [Iterative transition concepts](https://raw.githubusercontent.com/eclipse-capella/capella/master/doc/plugins/org.polarsys.capella.transitions.doc/html/11.%20Iterative%20Transitions/11.1.%20Concepts.mediawiki).
**Current limitation.** `TransitionField` is only Name/Description (`transitions.rs:31–35`). `trace_drift` (`127–140`) reads `Project::properties`, which returns those same two strings. Existing typed bodies, referenced items, parentage, exchange endpoints, guards and sequence contents are not reviewed. Changing a traced data-field multiplicity or scenario body can leave the trace Unchanged. This is a material mismatch with an engineer's expectation of a reviewed model relationship, even though V2 documented the restriction.
**Minimal coherent design.** Extend baseline data to a normalized semantic snapshot, excluding diagram geometry and generated target IDs. Store mapped identity-aware references. Expose typed content, containment and relationship proposals separately, with Keep target/Take mapped source and explicit endpoint choices. Preserve the existing conflict gate, target-context resolution reset, stale-plan check, atomic undo and no cross-layer deletion cascade. Many-to-many merges and splits require engineer choices; never invent an automatic inverse. At minimum every supported semantic edit must mark drift, and every automatically mappable field must have a reviewed propagation path. Arbitrary structural replacement under an opaque “body” checkbox is insufficient if it can silently destroy independent target work.
**Release proof.** Change datatype, multiplicity, exchange items, parent, guard and process topology after initial transition. Show accurate drift and field/structure proposals both ways; keep one target divergence; repeat idempotently; undo; verify stale previews cannot apply.
### R4. Reusable scenarios and explicit message semantics
**Evidence.** Capella's Interaction schema distinguishes scenario/message kinds and InteractionUse references. [Interaction schema](https://raw.githubusercontent.com/eclipse-capella/capella/master/m2/plugins/org.polarsys.capella.core.data.def/model/Interaction.ecore).
**Current limitation.** `SharedBody::Scenario` has context, pre/postconditions and steps; Exchange occurrence has one relation and two optional lifelines (`model.rs:261–323`). Existing generic lifelines do support functions or participants, and ALT/PAR/LOOP/OPTIONAL branches are already implemented. Missing are scenario reuse, message call/reply/asynchronous distinctions and a declared viewpoint contract. A reusable start-up sequence must be copied, losing its single identity; a request/reply looks like two indistinguishable arrows.
**Minimal coherent design.** Add scenario-use occurrences with explicit referenced scenario and lifeline mapping, with same-layer and recursive-use checks. Add message kind and correlation to a call when applicable; define safe defaults for migrated generic exchanges. Add clear scenario viewpoint selection (operational activity, participant interaction, functional, boundary/interface), or an equally precise inferred viewpoint with visible diagnostics. Define source/target representation compatibility once in core. Add contextual exchanged-value annotations bound to stable data-field IDs rather than relying exclusively on prose. Do not claim message execution or simulation.
**Release proof.** Reuse one scenario from two capabilities; change it once and navigate both uses. Model a request, reply and unsolicited event, including a guarded branch; reject a wrongly mapped lifeline. Show equivalent rendered/source semantics and transition the whole reference closure.
### R5. State machines need more than four vertex kinds and string-only triggers
**Evidence.** CapellaCommon includes choice, junction, fork/join, shallow/deep history and entry/exit/terminate pseudostates, transition kinds and time/change events. [CapellaCommon schema](https://raw.githubusercontent.com/eclipse-capella/capella/master/m2/plugins/org.polarsys.capella.core.data.def/model/CapellaCommon.ecore).
**Current limitation.** StateKind supports State/Mode/Initial/Final only; StateTransition stores trigger/guard/effect strings (`model.rs:240–246`, `704–711`). Nested regions and linked state actions already exist and should be retained. Engineers cannot explicitly model conditional dispatch, parallel-state synchronization or resume-after-interruption history; a trigger naming an event is not a maintained semantic reference.
**Minimal coherent design.** Extend a single typed state-vertex enum with the standard pseudostates rather than separate unrelated frameworks. Add transition kind (external/local/internal), typed event references alongside optional descriptive expressions, and time/change event bodies. Validate each pseudostate's cardinality, region context, history fallback and initial/final direction rules. Rendering needs distinct readable symbols and nested-region visibility; a new enum shown as an ordinary state box does not meet the workflow.
**Release proof.** Degraded operation machine with choice, parallel regions/fork/join, recovery history and a timeout. Rename/reidentify the event without breaking triggers; test inappropriate endpoints; round-trip/transition/undo the nested machine.
### R6. General-system data/interface contracts need explicit reusable semantics
**Evidence.** Capella Information provides exchange mechanisms, structured typed content, data inheritance/associations and value constraints/defaults. [Information schema](https://raw.githubusercontent.com/eclipse-capella/capella/master/m2/plugins/org.polarsys.capella.core.data.def/model/Information.ecore).
**Current limitation.** Current records/enum/primitive data and field multiplicity/unit are useful. But `ExchangeItemKind` mixes physical nature with Event and has no independent interaction mechanism; DataTypeDefinition lacks constrained numeric/string types, defaults, inheritance or association. A quantity range or input/output operation parameter can only be prose. Functional and participant ports share unrestricted InOut (`model.rs:234–239`); `validation.rs:1082–1087` admits InOut on functional endpoints although Arcadia functional ports are exclusively input or output. [Arcadia metamodel, function-port section](https://mbse-capella.org/resources/arcadia-reference/Arcadia%20Language%20-%20MetaModel.pdf).
**Minimal coherent design.** Keep nature (information/material/energy) separate from mechanism (flow/event/operation/shared data); preserve legacy Event by explicit migration. Add typed parameter direction for operation items, type-level bounds/default/unit, record specialization and association with multiplicity. Define own-versus-reference semantics and recursive type rules. Warn on existing bidirectional function ports, provide a split migration/editor action, and prevent new ambiguous function-port contracts. Keep participant bidirectionality. A typed property/value facility for units and measurable non-functional constraints is appropriate; a general plugin metamodel is not needed.
**Release proof.** Physical flow, energy transfer and request/reply interface with reusable bounded quantity/enum/record types. Invalid defaults/ranges and direction mismatches are diagnosed; semantic types survive API, source, GUI and cross-layer review.
## Release usability and contract work tied to semantics
1. **Exchange categories and selective diagrams.** The official functional schema supports exchange categories; Arcadia recommends synthesis to reduce clutter. Current `Diagram` exposes four projections and nodes but no category/filter definitions. Add named exchange sets and persistent visible-layer/category/relation filters with equivalent text fields; optionally show aggregate edges with navigable members. Do not replace actual edges with fake semantic exchanges. This is strongly recommended for the user's explicit uncluttered-system-engineering requirement. [FunctionalAnalysis schema](https://raw.githubusercontent.com/eclipse-capella/capella/master/m2/plugins/org.polarsys.capella.core.data.def/model/FunctionalAnalysis.ecore).
2. **Completeness diagnostics.** Add actionable coverage for non-leaf work carrying exchanges, leaf work absent from capabilities/processes/scenarios, mission without capabilities and interface responsibilities. These are warnings during authoring, not a ban on incomplete projects. Current validation has allocation-leaf checks and sequence gaps, but no exchange-on-parent or path coverage diagnostic. Arcadia's leaf guidance is explicit. [Arcadia Q&A](https://mbse-capella.org/arcadia-qna.html).
3. **Normative parity cannot be inherited.** Correct the OA ExchangeAllocation table/hint now. For every added constructor/field, update language keywords, parsing, canonical writing, reference enumeration/remap/removal, schema migration, inspector creation/editing, diagrams, REST queries and OpenAPI examples together. `schema_version` and source version are currently 2; a deliberately versioned migration is safer than silently changing closed enum/record contracts under “arcadia 2”. Preserve all V2 UUIDs/aliases and explain generated involvement IDs.
4. **Built-in guide is explicit release scope.** The root/UI workstream must add navigable concepts, common workflows and application commands, including the distinction between dataflow, process/chain, scenario, containment, allocation and trace. A link to repository Markdown alone does not satisfy the requested in-app guide.
## Reasonably future, without redefining OA/SA completion
- LA/PA/EPBS components, deployment and physical paths: explicitly later layers, not a missing SA internal hierarchy.
- Executable simulation, scheduling or code generation: modeling guards and time constraints need unambiguous descriptive semantics, not an execution engine.
- Byte-compatible native Capella import/export and every Eclipse metamodel implementation detail: valuable interoperability work, but the user asks a modern general tool, not an exact Capella file adapter.
- SysML v2 conformance, full expression-language theorem proving, complete Capella viewpoint/plugin ABI, replicated collaborative storage: neither necessary to encode the OA/SA semantics above nor explicitly required for first release.
- Advanced reusable model libraries and semantic Git merge can follow after stable identities, source parity and the direct editing workflows are complete. They must not be used as substitutes for basic scenario/process reuse in R1/R4.
## Implementation order and acceptance boundary
1. Freeze additions in the normative reST and core interfaces. Keep the existing one-model/one-transaction design. Agree on the state/event, occurrence/topology and value representations before parallel desktop/API implementation.
2. Implement R2 as a small first observable milestone, alongside the existing OA allocation documentation correction and built-in help work.
3. Implement R1/R4 together because stable involvements, contextual references and reusable behavior share reference-maintenance requirements. Implement R5 and R6 as separately owned core modules/commits where practical; do not let several workers edit the same exhaustive match catalogs simultaneously.
4. Extend semantic transition snapshots/mapped proposals (R3) against the frozen typed bodies; prove drift coverage for all persistent semantic fields with a meaningful table-driven fixture, not only a rename test.
5. Integrate projection/filter/diagnostic polish, then exercise a complete general-system OA→SA workflow including degraded behavior, item/interface contracts, artifact links, source editing and REST transactions. All new persistent records must be graphically editable, safely deletable/reidentifiable, undoable, canonical and round-trip stable.
These findings identify necessary release work from inspected current source and primary semantics. They do not prove a specific implementation is correct and do not constitute permission to call the release complete before native runtime and independent verification.
## Proposed concrete core interface for integration discussion
This is a proposal, not an agreed API or implemented contract. Prefer extending existing typed records over adding independent object registries. Freeze the exact names with the language/desktop owners before coding.
| Existing location | Proposed addition/change | Key invariant |
|---|---|---|
| `Kind`, `OaBody` | `OperationalMission`; `OaBody::Mission` | OA-only; counterpart default is SA Mission, preserving an explicit Manual trace until a dedicated Mission trace is introduced. |
| `RelationKind`/`RelationBody` | `CapabilityInclude { source, target }`; `CapabilityExtend { source, target, condition: String }`; `CapabilityGeneralization { source, target }` | Include points including→included, Extend extending→extended, Generalization specific→general; same family/layer. |
| Mission links | `MissionInvolvement { source, target }`; widen existing `MissionCapability` to the corresponding OA/SA family | Involvement participant→mission; MissionCapability mission→capability. |
| `OccurrenceBody::Action` | Reuse its `action` reference as a work involvement in a process/chain; require `lifeline == None` outside scenarios | Avoid a redundant Work enum. The occurrence's existing description is its context-specific contribution. |
| `OccurrenceBody` | `Control { kind: ControlKind }` with Choice, Merge, Fork, Join, Loop; `SequenceReference { sequence: Option<Id> }` | Process/chain only; reuse target in same layer and sequence family; no recursive references. |
| `RelationBody` | `SequenceLink { source, target, guard: String }` | Both endpoints are occurrence records directly owned by the same process/chain. Contextual precedence never invents a global functional exchange. Exchange occurrences remain identifiable nodes between work/control nodes. |
| Existing `steps` vectors | Retain as stable presentation order/membership for all owned occurrences; explicit SequenceLinks encode topology | Migrating a linear V2 process preserves Exchange occurrence UUIDs, generates work occurrences and links deterministically, and does not renumber old references. |
| `SharedBody::Scenario` | `viewpoint: ScenarioViewpoint` (OperationalActivity, ParticipantInteraction, Functional, BoundaryInterface) | V2 generic scenarios migrate by inspected lifeline/exchange types; ambiguous legacy content has an explicit MixedLegacy value and diagnostic until resolved. |
| `OccurrenceBody::Exchange` | `message_kind: MessageKind` (Asynchronous, Call, Reply); `reply_to: Option<Id>` | Reply references an earlier compatible call in the same scenario; legacy asynchronous is a documented default. |
| `OccurrenceBody` | `ScenarioUse { scenario: Option<Id>, bindings: Vec<LifelineBinding> }`; `LifelineBinding { referenced: Id, local: Id }` | Unique referenced/local role mappings, compatible represented objects, same layer, acyclic scenario use. |
| `StateKind` | Choice, Junction, Fork, Join, ShallowHistory, DeepHistory, EntryPoint, ExitPoint, Terminate | Reuse the State typed body with an expanded vertex kind; entry/do/exit actions apply only to actual State/Mode vertices. |
| State transition body | `kind: StateTransitionKind` (External, Local, Internal); `events: Vec<Id>` alongside current descriptive trigger/guard/effect | Event references are maintained by ordinary delete/reidentify operations; internal transition has defined self/target policy. |
| Shared event kind/body | `Event { kind: EventKind }`; EventKind Signal { item: Option<Id> }, Time { expression: String, relative: bool }, Change { expression: String } | Same-layer typed references, not interpretation of arbitrary trigger strings. |
| Exchange item body | Preserve `kind`; add independent `mechanism: ExchangeMechanism` (Flow, Event, Operation, SharedData) | Physical nature and interaction mechanism remain independent; preserve all legacy category values when migrating. |
| Data field body | `direction: ParameterDirection` (Unspecified, In, Out, InOut, Return); `default: Option<DataValue>` | Operation parameter directions valid only in the correct item context; defaults match referenced type and range. |
| Data types | Add constrained numeric/string constructors plus record supertype, or introduce equivalent typed restriction fields | Existing unit/multiplicity fields retain meaning; ranges constrain values rather than collection cardinality. Reject cyclic specialization. |
| Relations | `DataAssociation { source, target, source_minimum, source_maximum, target_minimum, target_maximum }` | Record/type endpoints in one layer; multiplicity bounds valid. Reuse typed relation infrastructure. |
| Shared category body | `ExchangeCategory { exchanges: Vec<Id> }` | Same-layer exchange references; categories may overlap and do not change exchange endpoints. |
| Diagram | Typed persistent relation/category visibility configuration | Hiding a category changes presentation only, and source parity includes every persisted filter. |
For transition review, the smallest robust extension is a typed `SemanticSnapshot` containing the element parent/body or relation body in addition to name/description, stored independently for OA and SA. `TransitionField` can gain Parent and Content initially, provided Content previews expand all changed fields/references and require an explicit review; it must not be an opaque replacement button. Better per-property decisions can use a closed set of field paths derived from each typed body, validated against its schema rather than allowing arbitrary JSON writes. The mapped candidate resolves every source reference to an explicitly selected/unique traced target before comparison. Parent, content and incident-relationship proposals remain separate; a source's unselected unrelated relationships must not be silently copied.
Use `SemanticSnapshot` equality for complete drift coverage even where automatic mapping is not offered. Preserve V2 baselines as name/description-only historical reviews with an explicit semantic-unreviewed state, rather than pretending they certify content they never recorded. Preserve many-to-many traces; incompatible merging remains an explicit unresolved proposal.
Cross-cutting integration surface: `ElementBody::{new,kind,shared,steps}`, `RelationBody::{kind,endpoints,items}`, `Kind::{ALL,supports,label}`, `RelationKind::{ALL,permits,hint}`, `references::{element_references,relation_references,remap,cleanup}`, validation/parent/connect queries, Session transaction admission, counterpart mappings, language constructor catalogs, property-form variant selectors, behavior projection and migration fixtures. Do not consider enum additions done until these surfaces are wired and exercised.
+230
View File
@@ -0,0 +1,230 @@
# R5 state/event implementation contract proposal — 2026-09-05
Status: adopted by the lead after the focused R1/R2/R4 correctness review closed.
R5 core, source/API and graphical authoring implementation is in progress;
runtime acceptance is not yet claimed. The lead adopted the four Studio choices
at the end of this contract; current evidence and ownership are in STATE.md.
## Evidence and intended outcome
The native benchmark actually created an H* Deep History node inside
Maintenance's region. It also added `[AFTER]30 s` beside an existing function
trigger (`Load Digital Media`) in a transition inspector. It did not establish
history fallback connectivity or validate the resulting transition. Preserve
that distinction when writing acceptance evidence. See
`harness/release-capella-workflow-benchmark.md:71`.
The implementation currently has State/Mode/Initial/Final, nested regions,
StateAction links, availability, and trigger/guard/effect strings. Rendering
shows Initial/Final glyphs and ordinary boxes; creation only offers State and
Initial. Keep its one typed state payload and existing command/reference
boundary. R5 should let an engineer build degraded operation, parallel work,
recovery history and a timeout without creating unrelated custom objects.
Capella exposes typed time/change events, transition kinds and additional state
vertices. Its relative/absolute time choices distinguish AFTER from AT, and its
transition definition retains descriptive triggering text separately from
semantic trigger references. Those are the implementation features to retain.
[CapellaCommon schema](https://raw.githubusercontent.com/eclipse-capella/capella/master/m2/plugins/org.polarsys.capella.core.data.def/model/CapellaCommon.ecore).
## Exact model changes
1. Extend **both** `StateKind` and corresponding `Kind` entries with `Choice`,
`Junction`, `Fork`, `Join`, `ShallowHistory`, `DeepHistory`, `EntryPoint`,
`ExitPoint`, `Terminate`. Continue using
`SharedBody::State { kind, entry, exit, do_activity }`. No separate graph or
state-machine framework. Keep `is_state` as the vertex-family query, but add
`is_stable_state` (State/Mode only) and use it for behaviors, availability,
observation and composite ownership so expanding the family cannot grant
pseudostates inappropriate features. This is nine additional vertices.
2. Add one `Kind::Event`, shared in OA/SA:
```rust
SharedBody::Event { body: EventBody }
enum EventBody {
Signal { items: Vec<Id> },
Time { kind: TimeEventKind, expression: String },
Change { expression: String },
}
enum TimeEventKind { After, At }
enum TransitionKind { External, Local, Internal }
```
An Event is an ordinary root semantic record with durable name/alias/UUID.
Signal identifies a named occurrence with optional same-layer ExchangeItem
payloads. Time and Change are expression-based definitions. AFTER is relative
to activation of the transition's source state; AT names an absolute instant.
Change means the named Boolean condition becomes true. No expression evaluator,
timer runtime, event queue or signal transport is introduced. Empty time/change
expressions warn; invalid XML text, duplicates or invalid item references reject.
3. Extend existing `RelationBody::StateTransition` with
`transition_kind: TransitionKind`, `triggers: Vec<Id>`, `effects: Vec<Id>`.
Retain `source`, `target`, `trigger`, `guard`, `effect` exactly. `triggers`
accepts same-layer Event or Activity/Function IDs; the referenced kind resolves
their meaning without another wrapper object. `effects` accepts same-layer
work IDs. Duplicate references reject. The text fields remain authored prose,
not inferred UUIDs or executable code. Factory defaults are External and empty
lists. Entry/do/exit typed work stays in existing StateAction relations.
Multiple referenced triggers are alternatives (OR), not an implicit conjunction.
Work triggers identify that work's occurrence/completion as an engineering
trigger; no call to that work is executed. Do not require a trigger function to
be allocated to the machine's owner: an external participant's work can cause
the observed transition. Existing owner-relative StateAction checks remain.
## Activation, hierarchy and transition kinds
The following is the proposed Studio contract, not an execution engine:
- Nonempty `triggers`: semantic triggering references; `trigger` is additional
descriptive text. Empty references plus nonblank `trigger`: legacy/prose-only
triggering, with `unresolved_trigger` warning. Do **not** call this completion
or infer an Event by matching its name. Empty references and blank trigger:
completion transition from a stable state, or transient routing from a pseudo.
- Completion of a simple state means its entry/do behavior is complete; for a
composite, all its active regions must complete. Final completes its region;
it does not terminate every region or delete the modeled participant.
Terminate ends the whole containing state-machine activation. These meanings
are documented and rendered; the application never asserts they ran.
- External may leave/re-enter the source configuration. A stable self-transition
is permitted and includes exit and entry behavior. Internal requires equal
State/Mode endpoints; it preserves the active configuration, including nested
regions, and does not imply exit/entry actions.
- Local requires a composite State/Mode source and a proper descendant target;
the source remains active while the affected nested configuration changes.
Local from an EntryPoint is also permitted when it targets a vertex within
that point's boundary composite. Local to self or outside that composite rejects.
Pseudostates otherwise use External; outgoing EntryPoint routing uses Local.
The internal/self and local/composite distinction follows the primary UML2
transition model. Its entry-point and fork/join segment restrictions also prevent
the common mistake of treating every arrow as an interchangeable external
transition. [Transition constraints](https://download.eclipse.org/modeling/mdt/uml2/javadoc/5.5.0/org/eclipse/uml2/uml/Transition.html),
[transition kinds](https://download.eclipse.org/modeling/mdt/uml2/javadoc/5.5.0/org/eclipse/uml2/uml/TransitionKind.html).
Endpoints must be existing vertices in the same layer and StateMachine. A normal
transition may cross nested regions of that machine; do not impose a blanket
same-immediate-region rule. Stable self-edges remain possible; pseudo self-edges
reject. Regions remain directly owned by a StateMachine or State/Mode. Two or
more sibling regions represent orthogonal/concurrent regions, without adding a
parallel boolean that can disagree with the hierarchy.
## Pseudostate ownership and validation policy
All new vertices remain region-owned. For EntryPoint/ExitPoint, the boundary is
the containing Region's owner (State/Mode or StateMachine); rendering attaches
their symbols to that owner's border while retaining the explicit region
destination. This is a deliberate Studio encoding that reuses current ownership,
not a claim of byte-identical UML/Capella containment.
Reject invalid references, wrong owners, upper-cardinality contradictions and
forbidden directions/transition kinds. Warn about absent required connections,
unfinished guards/defaults and unreachable vertices, so insertion can be followed
by wiring in separate undoable edits. No pseudostate may own a nested region or
typed StateAction. Retained legacy entry/exit/do prose on Initial/Final warns and
is preserved, not silently discarded or advertised as executable behavior.
| Vertex | Proposed exact invariant | Incomplete-model warning |
| --- | --- | --- |
| Initial | At most one per Region; no incoming; at most one outgoing; outgoing has no triggers, trigger prose or guard, but may have effect | Missing initial/default-entry path or missing outgoing |
| Final | No outgoing; no nested region or behaviors | No incoming; unreachable |
| Terminate | No outgoing; no nested region or behaviors | No incoming |
| Choice | At most one incoming; outgoing edges are transient guarded alternatives | Missing incoming, fewer than two outgoing, empty branch guard, absent else |
| Junction | One or more incoming/outgoing transient segments; no implicit concurrency | Missing side; ambiguous unguarded alternatives |
| Fork | At most one incoming; outgoing targets are stable states in distinct orthogonal regions of one composite/machine | Missing input, fewer than two outputs |
| Join | At most one outgoing; incoming sources are stable states in distinct orthogonal regions of one composite/machine | Fewer than two inputs, missing output |
| ShallowHistory | At most one per Region; at most one outgoing fallback to a direct stable child in that Region; no fallback trigger/guard | Missing fallback/default-entry path |
| DeepHistory | At most one per Region; at most one outgoing fallback to a stable vertex inside that Region's subtree; no fallback trigger/guard | Missing fallback/default-entry path |
| EntryPoint | Incoming from outside its boundary, outgoing into it; at most one outgoing per destination region; outgoing Local | No outgoing or incomplete affected-region entry |
| ExitPoint | Incoming from inside its boundary; at most one outgoing to outside it; outgoing External | Missing input/output; top-machine exit without a caller is an exit endpoint, not automatic termination |
Fork outputs and Join inputs must not have guards or triggers: conditional
dispatch belongs at Choice/Junction, not in a partial synchronization. With more
than one arm, using the same immediate orthogonal region twice rejects. Compute
the first region below the nearest common composite, not simply each state's
immediate region, so deeper nesting does not create false concurrency.
Other pseudo outgoing edges have no new event trigger. Initial restrictions
retain the current strict rule. For the newly introduced pseudos, forbidden
triggers should be structural errors when committing a complete edge; the native
benchmark's accepted Choice trigger was **not validated** and does not prove a
different semantic rule. The UI should move the timed/function trigger onto the
incoming stable-state transition, retaining Choice guards on the alternatives.
This is an explicit resolution of that observed ambiguity, not hidden loss.
Choice has at most one literal `else` outgoing guard; duplicate else rejects.
Do not parse arbitrary guards to claim exhaustiveness/disjointness. Junction
chooses a compound path from guard conditions before traversing it; Choice is a
dynamic decision after incoming effects. Keep their symbols and labels distinct.
Shallow history remembers only the immediate state; deeper regions use default
entry. Deep history remembers the nested configuration. Fallback applies where
no resumable history exists; do not synthesize history IDs or running state.
The same-region history policy is a Studio choice supporting independent
orthogonal regions; top-level history is allowed, with no submachine-execution
promise. Primary sources have an acknowledged disagreement about top-level
history placement. [Pseudostate constraints](https://download.eclipse.org/modeling/mdt/uml2/javadoc/5.5.0/org/eclipse/uml2/uml/Pseudostate.html),
[OMG history issue](https://issues.omg.org/issues/UMLR-816).
## Reference lifecycle, source and REST
Extend the existing visitors for Event Signal items, transition triggers/effects.
Reidentification remaps every reference. Deleting a trigger/effect record removes
its reference but retains the transition and prose; return an actionable cleanup
notice. If removing the last typed trigger would make a transition appear to be
completion, retain a descriptive placeholder in `trigger` naming the removed
trigger (atomic command) so the edit does not silently change activation meaning.
Undo restores the exact original record and references. No transition deletion
cascades to shared Events or counterpart-layer state machines.
Use `oa_event` / `sa_event`, existing `oa_<vertex>` / `sa_<vertex>` declarations,
typed Event body constructors, `transition_kind External`, `triggers [@event,
@work]`, and `effects [@work]`. Reuse the existing typed parser/formatter/form
adapter; update reference/enum field catalogs and every closed selector/schema.
State traces allow matching new vertex kinds and Event definitions in opposite
layers. Required transition closure includes referenced Events, item payloads,
work and effects. R3 reviewed drift must include all new fields and mapped refs.
No REST route is added: current model, element, relation, transaction, validation
and transition routes expose these records. OpenAPI must enumerate every vertex,
Event body and transition field. A POST Event + EditRelation batch is atomic and
conditional; editing the Event name or UUID must not break trigger references.
Old V2 migration preserves all IDs and exact trigger/guard/effect strings. Missing
transition kind becomes External; missing lists become empty. Do not parse
`after 30s` prose into a Time Event, or invent function references by display-name
match. Old prose-only transitions warn until explicitly linked. No old pseudo
vertex is rewritten. Preserve golden V2 source/JSON, add these defaults to its
comparison allowlist only after schema migration is explicit and tested.
## UI and acceptance sequence
Behavior adds a region-context vertex palette with distinct Initial ●, Final ◉,
Choice diamond, Junction dot, Fork/Join bars, H/H* circles, entry/exit border
symbols and Terminate cross. Every symbol gets a readable text name and usable
hit target; nested regions must stay visible and selectable. Add State/Mode
internal-transition rows inside the state card rather than a misleading self-loop.
One transition editor shows kind, typed trigger chips, trigger notes, guard,
typed effects and effect notes. `Add timed event` opens one inline form with
After/At and expression, creates the Event and attaches it in one undo step.
Existing function/event selectors are searchable and filtered by layer. A full
inspector/list displays all trigger names; the edge shows a concise summary and
never clips the only accessible copy. `Completion` is visibly distinguished
from unresolved descriptive triggering. No nested modal stack is needed.
Implement/verify in observable milestones: (1) events + references + concise
editor and original `[AFTER]30 s`/function example; (2) nested vertex palette,
choice/history + completion; (3) parallel Fork/Join and transition-kind rendering;
(4) source/API/migration/transition parity and independent review. Meaningful
tests must cover every vertex insertion incomplete state, invalid endpoint and
upper-cardinality case; shallow/deep scope; nested orthogonal arms; internal vs
external self edges; local source retention; trigger/effect UUID edits/deletion
undo; old prose preservation; source/JSON/API equality. Personally exercise the
degraded machine, event creation/rename, H* fallback, branch guard, resize and
save/reopen in the native application. No execution/simulation claim is allowed.
Before implementation, lead should adopt or amend the explicit Studio choices:
region-owned entry/exit symbols, history per Region, pseudo-trigger strictness
despite the unvalidated benchmark edge, and preserving removed-trigger intent
as descriptive text. These are concrete design decisions, not additional user
permission questions.
+82
View File
@@ -0,0 +1,82 @@
# R5 core state/event milestone — 2026-09-05
Status: core implementation frozen for independent review and desktop integration.
This is the bounded R5 milestone, not a declaration of release completion. R3,
R6, native interaction review and final migration remain separately owned work.
## Concrete model and editing behavior
- `Kind::ALL` has 38 kinds. `StateKind` has 13 vertices: State, Mode,
Initial, Final, Choice, Junction, Fork, Join, ShallowHistory, DeepHistory,
EntryPoint, ExitPoint and Terminate. `is_state()` means vertex family;
`is_stable_state()` restricts behaviors, availability and composite ownership.
- Shared `EventBody` is Signal `{ items }`, Time `{ kind: After|At, expression }`,
or Change `{ expression }`. Time/change expressions are engineering annotations;
they are checked for valid text and missing content, never evaluated.
- StateTransition retains exact trigger/guard/effect prose and adds
`transition_kind: External|Local|Internal`, `triggers: Vec<Id>` and
`effects: Vec<Id>`. Triggers are same-layer Event/work alternatives; effects
are same-layer work. External participants' work may trigger a machine.
- Existing constructor/serde defaults remain External and empty typed lists.
`Project::relate` (therefore `Command::Connect`) and `can_connect` infer Local
for EntryPoint routing. Explicitly authored relation constructors remain exact.
- Empty trigger references with nonblank trigger prose warn `unresolved_trigger`;
they are not reinterpreted as completion. Removing the last typed trigger keeps
a descriptive replacement prompt naming the removed trigger, unless authored
trigger prose already exists. All reference cleanup is part of the undoable edit.
## Validation and ownership
`state_validation.rs` is one private structural-rule module called by the existing
validator; it introduces no new graph, framework or execution state. Existing
reference visitors handle Event payloads and transition trigger/effect lists.
The adopted contract in `release-state-contract.md` is implemented: same-machine
hierarchy, stable Internal/External self transitions, proper-descendant Local
routing, region-owned boundary points, strict pseudo triggers/directions,
upper cardinalities, literal Choice else uniqueness, per-region shallow/deep
history, and Fork/Join orthogonal arms measured at their nearest common composite.
Incomplete connections, guards, default entry and structural reachability warn.
Reachability includes nested default entry and conservatively ignores guard
evaluation and stored history. It does not claim machine execution.
State-machine Subtree transition closure now includes its state transitions and
typed StateActions; Required edge closure includes referenced Events, items and
work. Matching new vertices and Events get typed State traces in both directions.
Unrelated Availability relations are not pulled into a machine transition.
Demo still has no validation diagnostics. It now has 41 elements: the two added
Events resolve the existing timeout/report transition prose without rewriting it.
## Verification actually performed
Target directory: `D:/CodexBuilds/Capella2-01a06e2e`.
- `cargo check -p oa-core --all-targets --locked` passed.
- `cargo test -p oa-core --locked` passed **102 integration tests**:
language 16, language limits 4, process diagnostics 1, capabilities 7,
topology 6, scenarios 14, states 11, review regressions 15, workflows 28.
- After strengthening all-vertex OA↔SA coverage and atomic rejection assertions,
`cargo test -p oa-core --test release_states --locked` passed all 11 again.
- `cargo clippy -p oa-core --all-targets --locked -- -D warnings` passed after
the final focused test edits.
The 11 new tests cover every vertex as an editable draft, stable-only behaviors,
typed Event/transition refs and invalid refs, last-trigger cleanup/reidentify/
delete/undo, local/internal hierarchy, terminal/initial rules, Choice/Junction,
history, deep orthogonal Fork/Join, boundary routing and candidate filtering,
nested reachability, and complete typed transition closure in both directions.
R4 scenario regression tests remain passing. No native UI/Computer Use was
performed by this core worker; the lead owns native verification.
Initial broad regression found only the old demo element-count expectation (39);
it was corrected to 41 after adding the two typed Events. The no-diagnostics
assertion still passes. No failed check is being left unexplained.
## Handoff
Core signatures are frozen. Source/API integration owns `language.rs`, persistence,
OpenAPI, normative reST and schema migration. Desktop owns the state editor,
Event controls, distinct symbols and runtime interactions. Independent review
should check structural boundary/orthogonal edge cases against the adopted
contract, not infer simulation support from enum names.
+133
View File
@@ -0,0 +1,133 @@
# First-release text and service audit
Date: 2026-09-05. Scope: the new first-release objective in the goal attachment `81e84f53-2b51-4151-9e34-59414bda8b2d/goal-objective.md`, current text editor/language, graphical field adapter, REST/storage and deployment. Read-only source audit; no native UI operation. No source files changed. This report assesses release suitability and does not inherit the V2 prototype exclusions as release acceptance decisions.
## Material findings
### TS1 — High: rejected oversized source monopolizes every hosted model
**Observed on the actual Windows release server:** a 638,689-byte source request containing 12,000 nested OA activities returned `422 model_limit` after **26.163 seconds**. A concurrent `GET /api/v1/projects`, issued 0.5 seconds later, took **25.655 seconds** to return 200. The documented 5,000-object cap is applied only after this expensive work. The request is far below the 8 MiB body cap.
Evidence: `crates/oa-server/src/routes.rs:271` imports source inside `blocking`; `routes.rs:188` calls the unrestricted `language::parse`; `crates/oa-core/src/language.rs:1026` performs full structural validation; only afterward does `StoreInner::create` call `validate_model` / `check_model_size` (`store.rs:166`, `store.rs:280`). `crates/oa-server/src/lib.rs:203` holds the one store mutex throughout parsing and validation. Source replacement/candidate validation have the same ordering. JSON import calls `persistence::decode`, which also validates before the server size cap. Parent walks and several validation scans are quadratic. A longer request can exceed the 30-second response deadline while retaining its blocking worker and mutex; this latter consequence is source-derived, not separately timed.
Reproduction: launch the release binary with an isolated data directory and `--bind 127.0.0.1:18787`; POST `text/plain` to `/api/v1/projects/import` using:
```python
n = 12000
source = 'arcadia 2; project oversize "Oversize" { oa_activity a0 "Root" {}\n'
source += ''.join(f'oa_activity a{i} "Activity {i}" {{ parent @a{i-1}; }}\n' for i in range(1, n))
source += '}'
```
Concurrently query the catalog. The isolated audit process (PID 27728) was stopped after its requests completed. Its logs and probe are under `D:/CodexBuilds/Capella2-r1-text-service-audit`; stderr contains only the expected startup line.
**Fix before release:** enforce declaration/record/reference budgets before expensive full validation, including source and legacy import; move request parsing outside the store lock, keeping snapshot/revision capture and final conditional commit atomic. Validate size at the shared parsing boundary or introduce an explicit bounded parse option rather than duplicating lexical heuristics. Add a real HTTP regression proving a rejected large candidate does not stall an unrelated read. A mutex refactor alone does not bound CPU cost; an early cap alone still leaves accepted large model validation holding the catalog lock.
### TS2 — Medium: source lint executes expensive work on the GUI thread
`crates/oa-desktop/src/app.rs:936` schedules a 350 ms sleep, but the actual `language::lint` runs synchronously in `Message::Lint` at line 945. Source undo/redo also lints synchronously. The version check prevents stale results, but does not make analysis asynchronous. Every source edit additionally clones full before/after buffers and retains up to 100 full-document versions (`app.rs:923`). Highlighting rebuilds tokens for the entire source on update (`highlight.rs:19`, `highlight.rs:61`).
A release-linked core probe measured:
| Model | Canonical/source bytes | Full parse | Canonical lint |
| --- | ---: | ---: | ---: |
| 201 graph objects, flat allocation | 27,990 | 2 ms | 2 ms |
| 2,001 graph objects, flat allocation | 281,790 | 60 ms | 68 ms |
| 4,999 graph objects, flat allocation | 710,504 | 358 ms | 303 ms |
| 1,000 nested activities | 49,687 | 88 ms | not timed separately |
| 5,000 nested activities | 261,686 | 2,605 ms | not timed separately |
These are exact core timings, not claims that a GUI freeze was personally observed. The synchronous update call means equivalent analysis blocks native event handling. For a release aimed at working systems engineers, even an otherwise valid server-sized model introduces hundreds of milliseconds per pause in typing.
**Fix:** execute snapshot/versioned lint on a blocking worker, discard obsolete results, and keep source edit response independent from analysis completion. Bound/coalesce pending analysis; do not spawn an unbounded number of obsolete full parses. Cache model validation by committed revision where reused. Add a realistic model-size interaction check; do not silently reduce supported semantics to obtain a passing performance test.
### TS3 — Medium: textual lint omits engineering warnings and offers no diagnostic navigation
`crates/oa-core/src/language.rs:139` is `parse(source).err().unwrap_or_default()`. A valid draft `arcadia 2; project demo "Needs" { sa_function assess "Assess" {} }` produces **zero lint diagnostics**, while `validation::validate` returns both `missing_system` and `unallocated_leaf`. The parser intentionally returns only the first structural error; warnings are discarded. As a result, the source workspace does not provide the same immediate engineering feedback as Model checks, and warnings only become visible after applying the draft and changing pages.
`crates/oa-desktop/src/views.rs:853` renders the first eight diagnostics as plain text. There are no diagnostic click actions, source search, go-to-line input or line-number gutter in the text workspace. `app.rs:977` implements graphical selection → source declaration, but no general error navigation. An error at line 4,000 is located numerically without a practical way to reach it, undermining the explicit human/AI-editable modeling goal.
**Fix:** expose located syntax/semantic diagnostics, including warnings with severity and codes, and navigate/select the relevant source range on click. Add Ctrl+F / next/previous match or go-to-line; display cursor line/column. A line gutter is useful if it stays aligned during wrapping/scrolling; it is not a substitute for direct diagnostic navigation. Test draft warnings without applying, non-ASCII columns, stale analysis results and navigation after edits.
## Product decisions requiring explicit release disposition
- **Source comments are erased on Apply and any save after open.** Reproduced `language::format(language::parse(source))` removing an explanatory comment. This is honest in `views.rs:901` and README and does not currently violate the normative V2 contract. For first-release Git/AI use, preserving comment trivia or providing a deliberate canonicalize command would avoid surprising loss of engineering notes. At minimum, the guide should teach durable model `description` fields and make the actual loss behavior clear before a first destructive normalization. Do not describe whitespace/comment preservation as implemented.
- **No crash recovery/autosave exists.** This is a declared V2 boundary; it is now worth a release decision for long engineering sessions. Ordinary save uses atomic replacement and external-byte conflict detection, but it does not recover unsaved source/property/model drafts after process failure. This audit did not simulate a crash.
- **Hosted models are accessed by explicit import/export, not a desktop connection.** The objective explicitly requires a programmatic backend, so absence of direct connection is not automatically a violation. If the release promises editing shared stored models from the desktop, a connection/revision/conflict workflow must be implemented and verified; current shell transfer alone is insufficient for that stronger promise.
- **Deployment evidence is incomplete for the provided Docker builder.** Dockerfile pins Rust 1.90; current verification records Rust 1.98.1 and no Docker execution. Native standalone Rust deployment is real; remote deployment is not required merely because a deployable service was requested. Before calling the provided container workflow verified, build it or independently compile the exact declared toolchain/dependencies and clearly retain the unrun container limitation.
## Strong existing evidence and boundaries
- Language tests exercise strict fields/enums/references/duplicates, all relation kinds, stable aliases/identities, ordered repeated occurrences, explicit V1 migration, UTF-8 diagnostics, exact permitted strings/float values, and full canonical round trips. `complete_model` is broad but `every_demo_record_has_a_lossless_graphical_draft` verifies only records in the demo; it is not an exhaustive proof that every closed enum/optional combination is easily authorable.
- Graphical forms maintain temporary typed values, reject malformed edits atomically, expose optional/reference/ordered values and preserve current references even if temporarily invalid. Tests cover escaped strings, reference choices, identity remapping, draft preservation and modal command gates. This source audit found no new concrete field-loss counterexample.
- `crates/oa-server/tests/http.rs` uses actual loopback listeners and filesystem stores, covering ETags, competing writes, stale deletes, no-ops, dry runs, exact source/JSON round-trip, revision-qualified pagination, bounded graph closure, authentication/browser/Host/media/body limits, restart/corrupt store/lock checks, forced pre-install storage failure, transitions/artifacts and store capacity. The audit inspected coverage and ran the additional release HTTP responsiveness probe; it did not rerun the entire suite.
- Storage holds an OS directory lock, persists before successful return, keeps in-memory state consistent after post-install directory sync failures, and rejects corrupt startup envelopes. Timeout/503 uncertain-write behavior and lack of idempotency/history are documented accurately. No new data-corruption or authentication bypass was established in this bounded audit.
- Request body caps and command limits exist, but do not currently solve TS1. Tests named capacity/bounds mostly check final rejection/status, not prompt rejection or concurrent service responsiveness.
## Suggested release acceptance additions
1. Under-limit and over-limit source/JSON candidates are bounded before expensive validation; an unrelated model/catalog read remains responsive during rejected import.
2. A 5,000-object representative model remains editable while analysis runs; obsolete diagnostics cannot overwrite newer draft state.
3. A text-only author sees engineering warnings and can jump directly to the affected declaration; search/navigation works on Unicode source and large documents.
4. The release decision on comments, recovery, hosted editing and tested deployment platforms is reflected consistently in the guide, normative contract, README and acceptance record.
## TS1 / TS3 implementation and re-verification — 2026-09-05
The previously observed TS1 catalog stall is fixed at both boundaries. Shared
`ParseLimits` checks source declarations and decoded JSON record counts before
structural validation; V1 checks include generated placements and process
occurrences before migration. Source/model replacement and candidate checks use
the same budgets. Store access now captures an owned snapshot under the mutex,
prepares/validates outside it, then rechecks the exact ETag while atomically
installing a privately constructed `PreparedModel`. Catalog reads copy only
summaries. Capacity accounting, directory ownership and install-failure behavior
remain under the commit lock.
TS3 core diagnostics now carry severity, stable engineering code, object/field
identity and exact source location. Valid source drafts report engineering
warnings without becoming unparseable; syntax and structural errors remain
blocking. Unicode scalar columns are preserved. Semantic diagnostics index
source line starts once, avoiding a complete prefix scan per warning. Native
background analysis and diagnostic navigation are separately owned desktop
verification gates, not claimed by this worker.
Observed current R2 verification: all **67 core tests**, **14 HTTP tests** and
**1 deterministic prepared-candidate commit test** pass on Windows. Strict
core/server all-target Clippy and the optimized server build pass. The full
language fixture covers every element/relation kind, new OA mission and SA
mission links, conditional extension with quoted guards, and typed mission
trace. OpenAPI exposes the same new vocabulary. These counts describe the R2
checkpoint; subsequent R1 topology integration has its own verification gate.
New actual HTTP cases exercise over-budget source, native JSON and legacy JSON
imports, source/model replacement and non-mutating candidate checks. Every
rejected candidate preserves the existing revision/model. A within-budget
2,000-deep candidate is prepared concurrently with catalog reads and a winning
rename; the stale candidate returns 412 and cannot overwrite either memory or
the installed envelope. A deterministic store unit test separately ensures two
fully prepared candidates from one original head cannot both commit.
Optimized executable probe against an isolated Windows store, using the exact
original source shape:
| Candidate | Bytes | Candidate response | Concurrent catalog |
| --- | ---: | ---: | ---: |
| 12,000 nested activities, source | 638,689 | 422 `model_limit`, 0.050 s | 0.016 s |
| 12,000 nested activities, native JSON | 2,737,965 | 422 `model_limit`, 0.142 s | 0.0023 s |
| 12,000 activities, legacy JSON | 2,341,015 | 422 `model_limit`, 0.127 s | 0.0013 s |
| 2,000 nested activities, accepted-size source racing a rename | 102,698 | 412 `revision_conflict`, 0.883 s | 0.0014 s |
The source rejection completed before the catalog read began 50 ms later;
both JSON requests were confirmed still in flight during their catalog read.
The accepted-size source was confirmed in flight at 100 ms; the competing
rename committed in 0.024 s and remained revision 2 on disk and in memory.
Measurements are one native run, not throughput guarantees. Evidence JSON and
stderr are in `D:/CodexBuilds/Capella2-r1-text-service-audit/fixed-20260905-095047`.
The probe process was terminated after all requests completed; no server is
left running. Stderr contains only the expected startup line. Graceful restart
and draining behavior remain covered by the transport suite and prior native
platform verification, not this timing probe.
Remaining first-release work is not waived: comment/recovery/hosted editing
decisions, exact deployment toolchain verification, native large-draft
interaction, the R1–R6 engineering semantics and final independent review.
+36
View File
@@ -0,0 +1,36 @@
# R1 contextual process/chain core milestone — 2026-09-05
Status: bounded core implementation and focused automated verification complete. Native authoring/rendering, source/API integration and release migration remain separate gates. The original Capella benchmark is still incomplete; its actually observed path highlighting and semantic navigation inform the required UI work, not a claim of feature equivalence.
## Frozen contract
- Existing `OccurrenceBody::Action { action, lifeline }` is a contextual work involvement when directly owned by an OA Process or SA FunctionalChain. Its `action` points to same-layer Activity/Function; `lifeline` must be absent. Its name/description/precondition/postcondition retain contextual meaning independently of the referenced work.
- `ControlKind` is Choice, Merge, Fork, Join or Loop. `OccurrenceBody::Control { kind }` belongs directly to a process/chain.
- `OccurrenceBody::SequenceReference { sequence: Option<Id> }` reuses a same-layer process/chain of the same family. Direct/transitive recursive reuse is rejected. An absent target is an editable incomplete reference. Deleting the reused sequence clears this reference and preserves the occurrence; it does not delete callers or an unrelated reusable sequence.
- Existing process/chain Exchange occurrences continue to reference Interaction in OA or FunctionalExchange in SA; they do not use scenario lifelines. Boundary exchanges remain available to scenario occurrences.
- `RelationKind::SequenceLink` / `RelationBody::SequenceLink { source, target, guard: String }` connects distinct contribution occurrences directly owned by the same process/chain. That common owner determines contextual link ownership. Source is preceding; target is following. `can_connect` applies the same context and endpoint rules as committed transactions.
- Action→Exchange, Exchange→Action and Exchange→Exchange adjacency must match the referenced global exchange's source/target work. Other links express contextual precedence without manufacturing a global work exchange.
- `steps` remains stable membership/presentation order. Explicit links express topology; reordering steps does not alter links. A legacy exchange-only sequence without explicit links keeps the existing linear interpretation and sequence-gap diagnostics. No old IDs, schema version or stored sequence is silently rewritten.
## Diagnostics and transition behavior
Once explicit links or work/control/reuse contributions exist, validation checks graph starts/ends, isolated/unreachable contributions and ability to reach an exit. Ambiguous splits/merges on non-control contributions warn. Choice/Fork expect one incoming and at least two outgoing links; Merge/Join expect at least two incoming and one outgoing; Loop expects at least one incoming and two outgoing (repeat/exit). Missing Choice/Loop outgoing guards warn and can use explicit `else`. Incomplete topology remains editable. Guard strings use the ordinary text-validity validator. Loops are permitted; there is no blanket topology-cycle prohibition.
Required/Subtree transition closure of a process/chain includes contextual links as well as owned steps and referenced dependencies. The shared visitor maps reused sequence references and link endpoints; guards and contextual properties survive. New mapped process/chain occurrences use `TraceKind::Sequence`, admitted for paired direct Process/FunctionalChain owners. Legacy `TraceKind::Scenario` occurrence traces remain accepted. Existing name/description-only drift remains a required R3 extension, not a claim that edited topology is already fully reconciled on existing counterparts.
The enum additions are 2 occurrence variants and 1 relation variant; `Kind::ALL` stays 28 and `RelationKind::ALL` is now 20. Generic session creation/ownership, projection endpoints, identity remapping and deletion infrastructure were reused. No additional registry, command type or UI-only semantic store was added.
## Verification actually run
Target directory: `D:/CodexBuilds/Capella2-01a06e2e`.
```
cargo check -p oa-core --locked
cargo test -p oa-core --locked --test release_topology
cargo test -p oa-core --locked --test workflows --test review_regressions --test process_diagnostics --test release_capabilities
cargo clippy -p oa-core --all-targets --locked -- -D warnings
```
Observed: **6 new topology tests plus 51 prior focused core tests passed**, strict core Clippy passed, edited sources/tests formatted with Rustfmt edition 2024. Tests exercise valid parallel and alternative paths with a reused subprocess in both transition directions; mapped reference closure and guards; explicit Sequence traces; invalid adjacency/ownership/self/recursive reuse; loop and incomplete topology diagnostics; every fixture element/relation reidentification/deletion and exact undo; list reordering independent of topology; and unchanged legacy linear behavior. Initial zero-warning assertions were corrected to account explicitly for intentionally unallocated global work and an unspecified system boundary in topology-only fixtures; no topology warning is filtered out.
Language fixtures, source/API/schema migration and native UI are being integrated by separate owners. Do not treat this focused report as a final workspace or first-release completion result.
+107
View File
@@ -0,0 +1,107 @@
# R3 semantic transition review contract proposal
Status: read-only integration design, 2026-09-05; not implemented. The lead requested this while R5 topology was finishing. R5 final source/API verification takes precedence. R6 properties below refer to the proposed `release-data-contract.md` shapes and must follow the lead's final R6 freeze.
## Current boundary and concrete outcome
`transitions.rs` already supplies direction, SelectedOnly/Required/Subtree scope, explicit source→target/kind mappings, preview changes/conflicts, per-field resolutions, a snapshot fingerprint and atomic commands. `TraceBaseline` stores only OA/SA `TracedProperties { name, description }`; `TransitionField` is only Name/Description and `FieldChange` contains string before/after values. `trace_drift()` therefore cannot detect a changed body, parent, reference or ordered contribution. Creation already maps typed bodies; updating an existing counterpart does not review those bodies. Retain the current pipeline and extend its review surface rather than replace it with a general graph synchronization framework.
An engineer must see a changed range, item list, parent, guard, occurrence, event trigger or interface contract; inspect its mapped proposal; accept selected changes or preserve intentional target differences; apply once, undo, and repeat without overwriting independent work. Neither direction is an automatic inverse. The original Capella iterative transition reference already linked in `release-semantics-audit.md` motivates conservative target comparison; the detailed decisions here are Studio's own contract.
## Recommended exact public types
Keep Name/Description unchanged for existing callers. Add a closed-catalog semantic field selector and typed values:
```rust
enum TransitionField { Name, Description, Semantic(SemanticPath) }
struct SemanticPath { segments: Vec<String> }
enum SemanticValue {
Absent, Boolean(bool), Integer(i64), Unsigned(u64), Real(f64),
Text(String), Enum(String),
Reference(HistoricalRef),
List(Vec<SemanticValue>),
Record(BTreeMap<String, SemanticValue>),
}
struct HistoricalRef { uuid: Id, kind: SemanticRecordKind }
enum SemanticRecordKind { Element(Kind), Relation(RelationKind), Artifact }
struct ReviewedSemanticField { path: SemanticPath, value: SemanticValue }
struct ReviewedSemanticSide { fields: Vec<ReviewedSemanticField> }
struct SemanticBaseline { oa: ReviewedSemanticSide, sa: ReviewedSemanticSide }
// TraceBaseline retains existing oa/sa TracedProperties and adds:
// semantic: Option<SemanticBaseline>
enum FieldDecision {
TakeSource, KeepTarget, Value(String), // Value remains prose only
SemanticValue(SemanticValue),
}
// FieldChange.before/after become SemanticValue (Text for Name/Description).
// Add source_before/source_after and target_before so a reviewed delta is visible.
```
`SemanticPath` is not an arbitrary JSON Patch address. The core returns a finite catalog of valid paths for each supported record/variant and rejects unknown paths, duplicates, identity/header edits, invalid enum/value combinations and unsupported writes. The GUI displays human labels, not path strings. API/source uses the same catalog and typed value constructors. Represent missing optional values with Absent; distinguish it from an empty list or empty string. Finite numeric rules follow the actual R6 types.
Baseline field entries are sorted lexicographically by path and unique; the vector is intentional because JSON cannot use a structured SemanticPath as an object-map key. Internal lookup may use a BTreeMap. Types containing finite f64 values derive PartialEq rather than promising Rust Eq; validation rejects non-finite values before baseline storage.
Recommended path shape is `parent`, `body/<field>` and nested `body/<constructor>/<field>` as necessary; constructors are explicit read-only/switch proposals, never inferred from property names. Examples: `body/DataField/minimum`, `body/StateTransition/guard`, `body/StateTransition/triggers`, `body/Occurrence/Exchange/reply_to`. Use named stable identity selectors for collection-member proposals; never use a vector index as durable identity. Paths are arrays in JSON/source so no slash-escaping ambiguity exists. The exact path list is generated/tested from an exhaustive typed-model adapter after R6 freeze.
HistoricalRef values are baseline/proposal snapshots, not additional live graph edges. They retain deleted reference identities for detecting removals. They must not be pruned by ordinary target deletion or rejected as dangling live references. Reidentification explicitly remaps these historical UUIDs when it remaps an existing identity. Source prints `uuid "..."` inside a HistoricalRef; it cannot require an `@alias` for an object that no longer exists. Human preview labels resolve current names where available and mark removed references otherwise. This separation prevents deletion cleanup from erasing the evidence needed to show drift.
The release schema/API change to typed FieldChange is explicit; do not silently serve the new shape under documentation claiming old strings. Existing REST endpoint version can remain `/api/v1` with an explicitly updated OpenAPI/model schema contract, but version-2 source/JSON migration only concerns stored models, not undocumented old transition-plan compatibility. Old retained client plans are stale and must be regenerated.
## Snapshot coverage and drift
Every directly persistent semantic field of an element/relation is captured: name, description, parent, body kind/constructor and all typed body fields/references. Exclude identity, alias, layer identity, diagram placement/size/collapse and the trace baseline itself. Alias changes do not change engineering meaning. Type/layer changes are explicit counterpart mapping decisions, not an incidental editable field.
The implementation adapter must exhaustively cover:
- Existing data/interface/port, constraint, state behavior text, availability/allocation, exchange endpoints/ports/items and mission/capability relationships.
- R1 process/chain steps, control kinds, SequenceReference, SequenceLink guards/endpoints and contribution parentage.
- R2 mission/include/extend/generalization/involvement fields, especially Extend condition and endpoint mappings.
- R4 viewpoints, context/pre/postconditions, lifelines, message kind/timer expression/reply correlation/value annotations, scenario-use bindings, fragment/branch membership and guards.
- R5 StateKind, Event Signal items/Time kind and expression/Change expression, transition kind and both typed trigger/effect lists, with descriptive strings separate.
- R6 nature/mechanism, defaults/ranges/unit/direction/storage, supertypes, association roles/multiplicities/navigation, interface allocation protocols/order, and message value paths if accepted.
Owned-child membership and semantic incident-relation membership are also reviewed facets. Keep relation records separately identified; a parent→child relation is not a second opaque nested copy of an entire graph. Created/selected dependency records each get their own trace baseline. The parent review rolls up drift from owned descendants' traces and flags newly untraced descendants as unreviewed. Direct drift and inherited/related impact must be visually distinguished; a referenced shared type changing should show as a linked impact, not pretend the user's own field reference UUID changed.
For efficient storage, store each traced record's own fields once per side and direct ownership/relationship identity membership; do not embed the whole subtree into every ancestor baseline. A descendant removed from the live graph remains detectable from historical membership even when its child trace is removed. Aggregate drift walks current and recorded ownership with visited IDs and bounded work. Artifact links owned by the compared semantic record are reviewed separately (URI/revision/fragment/relation and membership); artifact content itself is not fetched or diffed. A trace's own rationale/artifacts are not recursively included in its baseline.
For a reviewed field, compare current OA with recorded OA and current SA with recorded SA, preserving intentionally unequal reviewed values. Drift is Unchanged/OaChanged/SaChanged/BothChanged as today. Any supported field lacking a semantic baseline is Unreviewed, never falsely Unchanged. Source change affecting only an unselected field remains drift after applying a Name-only review.
## Mapping, three-way proposals and target preservation
1. Freeze an explicit mapping table before generating proposals. Reuse a unique compatible trace or the engineer's exact mapping. Missing or multiple eligible mappings create actionable conflicts; no display-name matching. Resolve all references through the same table used by current creation. Mapping and source-selection changes invalidate all affected decisions, even if a string value happens to match.
2. Compare mapped source-before/source-now with target-before/target-now. A scalar source change can apply when the target still matches its recorded value. If both sides changed the same scalar incompatibly, or a baseline is absent, require TakeSource/KeepTarget/typed merged value. If target-now already equals mapped source-now, it is a no-op that may be acknowledged. Preserve independent fields automatically.
3. TakeSource for reference collections means apply the displayed source *delta*, not replace the entire target collection. Target-only members survive. Additions map by UUID and are shown individually. Removing a mapped source member proposes unlinking it; deleting the target semantic object is a separate explicit action with ordinary impact preview. Never cascade deletion across layers.
4. Ordered membership is a distinct proposal from presence. When unchanged target ordering maps directly to the source baseline, source reorder can apply. If target-only contributions or independent reorder make insertion anchors ambiguous, require an explicit final target ordering; do not guess placements or discard extra steps. New mapped members may insert after a uniquely mapped unchanged predecessor, with source order preserved. A proposed order must include every surviving target member exactly once.
5. A parent change is an explicit reparent proposal, with mapped destination and the actual affected target subtree visible. Changing a relation endpoint is an explicit endpoint proposal, validated against mapped kinds and allocation/scenario context. An unsupported layer-specific source relation has no destructive fallback. Keep target and explain the missing mapping.
6. Constructor changes (e.g. Asynchronous→Timer, Time→Change, Record→primitive) are grouped typed proposals with all added/removed fields and affected owned records visible. The whole group must be compatible with retained target-only work. If it would invalidate independent children, references or scenario observations, block until explicit resolutions exist; do not hide it behind one generic Body checkbox.
7. Many source records mapped to one target are allowed only when their resolved deltas agree for every touched facet. Incompatible merges/splits require explicit individual mappings/resolutions; no automatic reverse merge. Reuse remains idempotent and aliases/target IDs remain stable.
All retained independent work is still validated in the final candidate. Keeping an incompatible target field can make a chosen source proposal impossible; report that exact interaction rather than force either side to win silently. Creation of required dependency records remains supported, but the preview must name every creation and make existing mapped records' updates opt-in.
## Baseline acknowledgement and command safety
KeepTarget acknowledges the current source and the intentionally retained target only for the selected field/facet. It does not copy the source or refresh unrelated baseline fields. TakeSource acknowledges the source and successfully resulting target. A manually merged value records that pair. No-op acknowledgement can update a baseline without emitting an EditElement. Cancellation changes neither model nor baseline.
Applying a plan still checks the exact project fingerprint and HTTP ETag/base revision, builds one candidate and runs whole-model structural validation before one atomic history/disk commit. An invalid candidate leaves the project, baseline, revision and undo history unchanged. Baseline updates occur in that same transaction after successful resolved model changes. Keep the current documented stateless server plan contract: a client plan is a candidate, not a cryptographically trusted receipt. Do not bypass ordinary typed command validation because it came from a preview.
Identity/reference remapping, stale-plan rejection, duplicate resolutions, wrong field types, unsupported paths and removal impacts need focused tests. Fingerprints remain change detection, not authorization or an execution capability.
## Migration and integration sequence
V2 baselines retain exact name/description values and gain `semantic: None`. The first semantic review is explicitly Unreviewed and requires acceptance for differing typed values; do not fabricate historical body snapshots from today's model. Name/Description-only legacy behavior remains available without pretending semantic review happened. Golden V2 UUIDs/aliases/prose/artifacts remain unchanged. Historical reference values have explicit typed source constructors and OpenAPI definitions rather than escaped JSON blobs.
Implement after R6 shapes freeze: (1) exhaustive semantic snapshots and honest drift; (2) mapped scalar/parent/endpoint proposals with per-field decisions; (3) identified collection/ownership changes and order review; (4) native reviewer UX plus API/source/schema parity. Each milestone must have observable review behavior. These are one existing transition subsystem, not separate synchronization services.
GUI: show source and target labels, origin/current values and mapped proposal; group Properties, Ownership, Relationships, Ordered behavior and Artifacts. Include deliberate Keep target differences and unreviewed semantics. Selecting a reference opens its semantic record or mapping picker. Checkboxes control individual coherent proposals. A pending conflict identifies the field and affected target object. Do not show opaque UUID-only bodies, mark unchanged rows as changed, or advertise two-way automatic sync.
## Required proof before accepting R3
- Initial OA→SA transition of a complete process/state/scenario/data slice, then change datatype range/unit/default, field multiplicity, exchange items/ports, parent, guard, topology order, scenario binding and event triggers. Each produces exact drift/proposals; do the same in reverse.
- Intentionally retain a target guard and add a target-only branch, field and interface allocation. Apply unrelated source changes and verify these survive byte-for-byte. Remove source contributions and verify target records are retained until explicitly deleted.
- Exercise ambiguous endpoint mapping, constructor switch with dependent target children, simultaneous reorder, differing many-to-one proposals and absent V2 semantic baselines. No partial application or invented inverse.
- Apply the same accepted review twice (second has no further semantic changes), undo/redo exactly, edit after preview then reject the stale plan, and fail one resolved field validation without advancing any baseline.
- Prove exhaustive coverage by walking each actual supported typed payload and mutating one meaningful field/reference at a time against a reviewed baseline, including every R1/R4/R5/R6 property. The expectation is observed drift plus one justified proposal or explicit unsupported conflict, not just serialization equality.
- Verify JSON/source stored-baseline roundtrip with deleted historical references, reidentification, real HTTP preview/apply with ETag races, disk restart, and native inspect at compact and normal widths.
Lead choices to freeze: typed SemanticValue/closed path catalog; field-specific historical snapshots rather than whole-subtree copies; explicit collection deltas preserving target-only members; old semantic baselines remain Unreviewed; no source deletion automatically deletes a target record. R6 names must be reconciled with its final accepted contract before generating the exhaustive catalog.
+24
View File
@@ -0,0 +1,24 @@
# Independent architecture review — 2026-09-05
Scope: current integrated Rust core, language, persistence, desktop message/draft state, views, diagram, tests, architecture and execution documents. Read-only implementation review; no Computer Use or build/test execution by this reviewer.
## Material finding
**High impact: help navigation allowed two competing editable drafts. Resolved in source; runtime verification remains with the lead.**
`app.rs` deliberately lets `Page::Guide` open without applying source so that syntax help is available for invalid drafts. Previously `views.rs` also displayed the graphical inspector on Guide. A user could edit valid source, open help, edit an inspector property, then Apply or Save. `apply()` calls `apply_source()` first; successful source replacement calls `sync_selection()`, overwriting that inspector draft before `draft_dirty()` examines it. This was a reachable silent-loss path, not merely hypothetical state complexity.
The lead changed `views.rs:170` to omit the inspector on both Text and Guide. I reread the updated condition and confirmed the competing editor is no longer rendered on the exception route. Keep Guide read-only. Runtime regression: select an element, edit source without applying, open help, verify no inspector and unchanged draft, return to Text and apply; repeat with invalid source to verify help remains reachable and the draft survives. If a future guide adds editable controls, route them through the same apply boundary before exposing a second draft.
## Architecture assessment
- The two-crate boundary is appropriate: no Iced dependency in `oa-core`; parsing, shared structural validation, transactional history and persistence operate on the same model. Desktop mutation paths inspected use `Session::execute`, and loaded candidates pass persistence validation before session adoption.
- Whole-project text replacement is one transaction. This avoids an unnecessary second model store and synchronization framework. Human-readable aliases are presentation; persisted UUIDs retain identity. Neither a dynamic plugin ABI nor an incremental parser framework is warranted for the current prototype.
- Separate source-draft history and committed-model history have different jobs and are presented separately. Bounded snapshots are a defensible modest-model tradeoff. Large-model profiling and delta history remain future work, not prerequisites for the MVP.
- `App` is large, but its current event loop and a few explicit apply/sync helpers are understandable. A broad state-machine rewrite would add risk during integration. The discovered loss path needed a local ownership fix, now made. Future additions should group draft ownership and file-operation state only when a concrete new transition requires it.
- `Session::project` remains publicly mutable and `Session::new` assumes a valid candidate. Thus the mutation boundary is enforced by call-site convention rather than Rust privacy. Current desktop call sites inspected honor it; this is a nonblocking library-hardening opportunity, not evidence of an existing application defect.
- No blocking unnecessary abstraction or speculative infrastructure found. Native-platform file selection and renderer limitations are explicit implementation/platform tradeoffs and require the lead's runtime evidence; this review does not certify that evidence.
Result: no unresolved high-impact architecture finding in the inspected source after the Guide fix. Runtime re-verification of that fix and final build/test evidence remain separate completion gates.
Lead integration closure: the read-only Guide and invalid-draft recovery were subsequently exercised in the actual Windows application by the lead/UI reviewer. Final Windows/Linux checks and native runtime evidence are recorded in `docs/validation.md`; no architecture finding remains open.
+94
View File
@@ -0,0 +1,94 @@
# Independent correctness review — 2026-09-05
Scope: current core model, language parser/printer, JSON/text persistence,
transaction history, and desktop source/property/save/navigation state. Read the
attached goal and normative language specification. No implementation edits or
Computer Use were performed by this reviewer.
## Material findings
1. **P2: invalid property draft could trap the user in Getting started.**
Previously `Message::Page(Guide)` skipped `apply()` while the guide hid the
inspector. Select an element, enter `invalid` as X, enter Getting started,
then attempt Architecture or another selection: validation rejected every
return action and the correction/revert controls were inaccessible. Root
changed `app.rs` to apply property drafts before opening help when there is
no source draft. A temporary compiled update harness subsequently observed
that the invalid-X attempt stays on Diagram, preserving the draft and its
accessible controls. **Resolved in the inspected code; retain a regression
test and exercise the UI.** Invalid source still needs access to help.
2. **P2: accepted name strings could not all be authored graphically.**
`validation::valid_text` permits LF, CR and tab, and language tests explicitly
use these in names. Project, element and relationship names use Iced
`text_input` in `views.rs`; the installed Iced 0.14.2 implementation filters
control characters on paste (text_input.rs:970–975) and typing
(1022–1023). Thus a valid text-authored name was outside the graphical
editor's authoring capability. Root accepted the finding and is adding
an explicit exact-string inspector mode. **Resolved by the focused follow-up
review:** compiled state tests authored CR/LF/tab/quotes/backslashes/Unicode
in project, element and relationship names and element descriptions;
toggled both presentations; checked canonical source; executed the actual
Save tasks to `.arcadia` and `.json`; and loaded both files with complete
model equality. Invalid JSON literals and XML-forbidden decoded characters
in all four property cases preserved model, draft and mode, blocked Save,
and remained recoverable through Revert. Real-app visual verification
remains the lead's check.
3. **P2: noncanonical exact literals remain falsely dirty after Save/navigation.**
In exact-string mode, type `"\u0041"` as the project name and Save. The file
correctly contains the model name `A`, and the saved model baseline is
current; however, `project_name` retains its noncanonical spelling while
`draft_dirty()` compares it with `display_string(model.name)`, which yields
`"A"`. Save does not call `sync_selection()` after successful `apply()`, so
the UI continues reporting unsaved work and may show an unnecessary discard
guard. The same path affects element/relation names and descriptions.
Root now calls `sync_selection()` after a successful property command,
while leaving failed drafts intact. **Resolved and reverified:** the
compiled harness saved noncanonical literals in project, element and
relation names and descriptions, observed clean saved state in each case,
then edited another noncanonical literal and navigated to Text with clean
property state and matching canonical model. Before the fix this same
real-Save-task harness failed its clean-state assertion.
## Additional verification
- Compiled a focused parser harness against the current built core. Mutated
the valid document at every Unicode character boundary with punctuation,
quotes, escapes, comments, line breaks, control characters and extreme
exponents; also supplied 3,000 deterministic arbitrary Unicode strings.
All returned diagnostics or structurally valid models without panics, and
every accepted model round-tripped through the canonical printer.
- Compiled a focused Iced content harness: LF, CR, CRLF, trailing line endings,
U+2028 and U+0085 descriptions round-tripped through `text_editor::Content`
exactly. This potential description-normalization defect was not reproduced.
- Inspected duplicate-identity handling, forward reference resolution, strict
unknown-field rejection, UUID collisions, kind/endpoint edits, process step
references, failed replacement history, atomic persistence, and save guards.
No additional material correctness defect was established in these areas.
- Correction to the earlier review: treating identity entry as an explicit-only
action did not satisfy the specification's property-draft rule. The final
implementation treats IDs as ordinary property drafts: they contribute to
unsaved state, apply on Save/navigation, and commit atomically with the other
properties. The requirements reviewer identified and closed this gap.
- Temporary reproduction sources/binaries are outside the repository under
`D:/CodexBuilds/Capella2-01a06e2e/review-*`. Whole-workspace regression and
real-app verification remain the lead's integration checks; this report
does not claim those were independently rerun here.
- Follow-up complete: recompiled the current desktop modules in the isolated
harness and ran all 18 tests (15 repository desktop/diagram tests plus the
three independent exact-string tests); all passed. This covers real Save
task execution to private test files but does not replace Computer Use.
- Final identity follow-up: inspected `EditElement(old, record)`,
`EditRelation(old, record)`, `EditProject(id, name)`, the shared reference
update helper, identity-aware draft detection, and action remapping after
Apply. Recompiled the current modules and ran five focused identity tests;
all passed. Four repository tests cover failure preservation, references,
navigation, source parity, process actions, Delete and pending-ID movement.
An independent test executes real Save tasks for project, element and
relationship ID-plus-name drafts, reloads equal models, observes clean saved
state, then verifies one Undo restores both properties together. No material
issue was established in this bounded change; native drag verification is
assigned to the runtime reviewer.
No unresolved material correctness finding remains from this review.
+45
View File
@@ -0,0 +1,45 @@
# Independent requirements review
Reviewed 2026-09-05 against the complete attached user objective, `docs/language.rst`, current Rust implementation/tests, README, scope, acceptance, plan and state. No implementation edits or Computer Use were performed by this reviewer. Independent focused test execution is recorded below; parent-reported runtime results are distinguished from inspected code.
## Material finding
**R1 — identity edits are lost outside the dedicated button (fixed; focused re-review).**
`App::draft_dirty` in `crates/oa-desktop/src/app.rs` checks names, descriptions, kinds, endpoints and positions, but not `identity`. `Message::Identity` changes the input. From a clean project, entering a different UUID leaves `dirty()` false, so `Request(New)` resets the project without an unsaved-work guard. Selecting another object calls `apply()`, which sees no property draft, then `sync_selection()` overwrites the entered UUID. Even ordinary Apply discards the ID input without applying it. Only the separate Change ID button uses the entered value.
This contradicts specification section 6: edited property drafts contribute to unsaved work, failed edits preserve drafts, and Save first applies valid drafts. The identity field edits an existing persistent model field, unlike preparatory controls for creating a new relationship. Integrate identity into validated property application, or preserve and guard its pending state explicitly. Verify valid/invalid identity edits, Save, selection changes, New/Cancel and reference updates; avoid partially applying companion properties before an invalid identity is rejected.
The integrated fix adds identity to `draft_dirty`, parses it before any property command, and combines identity plus companion properties through `EditElement(old, value)`, `EditRelation(old, value)`, and `EditProject(id, name)`. Their shared reidentification helper rewrites references on a candidate before validation/adoption, making collision failures atomic and successful property/identity edits one history entry. Ordinary Apply, navigation and Save use this path; Change ID delegates to it. Inspected new desktop regressions cover all three object categories, guards, collision/invalid input, reference integrity and one-step Undo. Parent reports 49 full-workspace tests passing. This reviewer independently built the desktop tests with the D: target directory and ran the resulting test binary with `identity_ --nocapture`: all three identity/source-identity tests passed, exit 0. Valid Save captures the post-apply `session.project`, so the saved snapshot contains the new identity. R1 is closed by focused code/test review; GUI verification remains a separate gate.
**R2 — an action can retain the old target across identity auto-apply (P2, fixed).**
Select an object, edit its UUID, then click its Delete control. The rendered button carries `Command::Delete(old)`. `Message::Command` first applies the identity draft, then executes that old command. Delete is now a successful no-op, leaving the object present with a new identity. Process Remove/Up/Down controls likewise embed the old process ID and report a missing element after committing the new ID. `Connect` snapshots source/target choices before applying drafts and can submit an obsolete endpoint when that selected endpoint is being reidentified. Selecting the same canvas/explorer object first applies the ID then selects the obsolete ID, clearing selection.
These are concrete reachable single-click workflows, not asynchronous hypothetical races. They do not corrupt committed model data and can be recovered by repeating the action; severity is P2. Apply must either remap action targets after a successful identity change or resolve the user's target after application. Include both command targets and relation endpoint choices; preserve the intended selection as well.
Focused re-review: the fix remaps selected command targets across Apply, preserves same-item selection, remaps existing builder choices only for identity commands and resolves Connect choices after Apply. Independently ran `cargo test --locked -p oa-desktop identity_`: all four tests passed, including the new process reorder/remove, selection, delete and connection regression. These single-message paths are resolved.
The first fix left a residual drag path: ButtonPressed retained an old ID in `State.drag`, while Select auto-applied the new identity before ButtonReleased submitted Move(old). The final fix preserves a draft when reselecting the current object outside Text; that selection is a no-op, so drag identity remains valid until release. Move then applies the draft and remaps its old ID in the same message. Selection changes and leaving Text still apply drafts as required. The expanded regression sends Select(current), asserts the ID draft remains pending, then sends Move(old) and checks the surviving new-ID object's position. Independently reran `cargo test --locked -p oa-desktop identity_` after this fix: all four focused tests passed, exit 0. R2 is closed by code/test review; actual drag/identity operation remains part of the root's separate native GUI retest.
## Implementation coverage
- The Rust/Iced two-crate application implements the specified OA MVP: five element kinds, four typed directed relations, cardinality checks, ordered/repeated process interactions, history, model checks, diagram/explorer/narrative views, and durable files.
- The graphical and textual representations share `Project`, the validator and transactional session. Every persistent field has both a source representation and a graphical route, including exact strings, coordinates, kind/endpoint changes and identity. R1 affects the draft contract, rather than the existence of an identity operation.
- The normative reST document covers abstract values, lexical syntax/EBNF, structural/warning semantics, forward resolution, canonicalization, equivalence, graphical editing, transaction/draft guards, persistence, SVG export and examples. The language is explicitly an OA prototype language, with the same domain boundary in both representations.
- Inspected tests cover complete model round-trip, canonical idempotence, aliases/Unicode/coordinates, strict malformed input, process order/repetition, shared validation, identity reference updates, atomic replacement and JSON/text equivalence. Application state tests now include the R1 transition and action-after-identity paths described in R2, including the press/release message sequence.
- `cargo metadata --offline --locked --format-version 1` found no dependency declaring a Rust minimum above the workspace's stated 1.90. Actual 1.90 build verification is not claimed.
- Scope documents candidly list unsupported Capella concepts and remaining usability/performance tradeoffs. The objective requests an MVP and asks to try to address known downsides; the implementation makes concrete improvements without claiming complete Capella or SysML conformance. I found no additional explicit required OA feature silently available only in one representation.
## Open completion gates (expected pending verification)
1. Complete the native GUI retest of identity/drag changes and close material findings from the other independent reviewers. R1 and R2 focused code/test verification is complete.
2. Record real-app editing of existing relation kind/endpoints, process append/reorder/remove, and IDs/reference preservation. Source-created objects plus graphical rename alone do not establish these newly exposed workflows. Root reports Windows source authoring, graph synchronization/save/error guards and 1100×700/1440×900/maximized inspection; these are useful but narrower evidence.
3. Exercise the current Linux editor/file workflow on the actual native build, including text-to-graph-to-text and save/reopen. The 44-test native pass predates the latest focused fixes; run final checks after integration.
4. Complete the clean documented build, final full-workspace checks, refreshed Windows/Linux artifacts and reproducible startup guidance. Existing historical artifacts and CI configuration do not prove the final revision.
5. Reconcile `harness/STATE.md`, `docs/validation.md` and `docs/acceptance.md` with final commands/runtime/review outcomes. The inspected validation record still describes the earlier 18-test MVP; the updated README and scope correctly defer final acceptance.
The reported R1/R2 findings are closed by independent focused review. No unresolved blocking or high-impact requirement defect remains from this review. Overall completion remains unproven until the runtime/build/documentation gates have current evidence. No claim of actual rendered-UI quality is made by this reviewer.
## Lead integration closure — after the independent review
All five completion gates listed above now have final evidence in `docs/validation.md` and `docs/acceptance.md`. The independent UI reviewer exercised existing relation/process operations and the final release's pending-ID drag, closing all material UI findings. The lead completed the native Linux text Apply/save/reopen and process-view workflow. Windows and Linux each passed the final 50-test suite, strict Clippy, formatting and optimized builds; both refreshed archives were checked against executable hashes. Documentation is reconciled. This note records integration evidence and does not imply this reviewer personally performed the lead's GUI checks.
+112
View File
@@ -0,0 +1,112 @@
# Independent UI and runtime review
Reviewed 2026-09-05 using the actual Windows `target/debug/arcadia-studio.exe`
through the Computer Use skill and `@oai/sky`. This reviewer did not implement
the application or modify implementation files. The running executable was the
build supplied at review start; concurrent source fixes are not covered here.
## Original findings (resolved in final release below)
- **P2 — nearby horizontal interaction becomes invisible.** In Text, apply the
fixture below, open Architecture, and select Observe. At 60% zoom the Report
label appears inside Observe's card, while the line and arrow between Observe
and Respond disappear. `diagram.rs` draws a fixed 170-unit opaque label
background over the 76-unit gap between the cards. Text layering also makes
the label visible over the card. Selecting the relation reproduces the same
issue, as does changing it to a Contribution between equally spaced cards.
A normal close horizontal arrangement must retain a visible connection and
a label that does not impersonate card content.
```text
arcadia 1;
project "Review cycle" {
activity observe "Observe" { position (0, 0); }
activity respond "Respond" { position (300, 0); }
capability safe "Safe operation" { position (600, 0); }
interaction report "Report" from observe to respond;
}
```
- **P2 — inspector preserves an unrelated scroll position.** At minimum size,
select a process and scroll the inspector to Share & Explore. Load the rescue
example, select its process, or create New. The new selection/project's name,
kind and description may be above the visible inspector. New from the clean
example displayed Stable ID at the top instead of project properties. Reset
or intentionally anchor the inspector when its selection/project changes.
- **P3 — process continuity warnings omit the offending occurrences.** Move
the second rescue process step above the first. Model checks displays two
identical `Process 'Distress to recovery' has disconnected consecutive steps.`
messages. Include the adjacent step indexes/names so users can identify each
gap. Both warnings correctly disappear on Undo.
No crash, data loss, or blocked recovery was observed in the exercised workflows.
The three findings above were reported for the initial reviewed debug build.
Their resolution was independently verified against the final release below.
## Personally exercised behavior
| Workflow | Observed result |
| --- | --- |
| Launch latest Windows executable | Clean native window, built-in model rendered, 9 elements / 9 relationships / 0 checks. |
| Open `D:/CodexBuilds/Capella2-01a06e2e/harbour-ui.arcadia` through native Open dialog | Harbour response loaded with 6 elements / 5 relationships / 0 checks and All changes saved. Triage incoming report, description's two lines, and exact X=350.25 visible. |
| Invalid source + help navigation | Appended `invalid` after the project's closing brace. Getting started remained accessible without losing draft. Architecture returned to Text with line 40, column 1 diagnostic and preserved 6-element model. Revert restored clean source and saved status. |
| Invalid graphical property + help recovery | Replaced activity X with `invalid`. Getting started stayed on Architecture, with numeric error in footer and inspector still visible. Revert property edits restored 350.25 and clean status. |
| Window resizing | Inspected 1440x900 content (1442x932 outer) and 1100x700 content (1102x732 outer). Header, sidebar navigation, inspector, footer, text toolbar, source editor, help link and modal actions remained reachable without overlapping controls. |
| Fit at minimum size | Six harbour cards fit inside canvas at 46%; text is small at that zoom but no cards were clipped. |
| Process reorder and checks | Moved Incident assessment above Distress signal. Process narrative immediately reflected order, checks count became 2, and Model checks showed continuity warnings. Ctrl+Z restored order and All checks passed. |
| Process remove / append | Removed Rescue assignment occurrence: narrative became two steps, all 9 relationship records remained. Picked Rescue assignment and Append step: original three-step narrative and clean model state restored. |
| Empty project states | New produced zero records; diagram was empty with creation toolbar, Process page had Add process, Model checks reported consistent references, Text showed a valid empty project. |
| Authoring in minimum-size Text view | Entered Review cycle fixture above. Apply generated stable IDs/canonical source, graph showed all three elements and one relation, three expected incompleteness warnings. |
| Edit existing relation kind and both endpoints | Selected Report via Observe's Relationships list. Changed Interaction to Contribution, chose Respond source and Safe operation target, Apply. Inspector showed Contribution and updated endpoints, graph record counts updated, checks fell from 3 to 2. Text showed `contribution report ... from respond to safe_operation;` with the existing relation ID retained. |
| Unsaved-change modal | Loading built-in example from disposable Review cycle displayed Save/Discard/Cancel modal with legible minimum-size layout. Discard replaced only disposable in-memory review model. |
| Clean exit | After restoring the rescue process to original state, Alt+F4 exited; fresh `sky.list_windows()` confirmed no Arcadia window remained. |
No existing fixture was saved over. Review-created models were disposable
in-memory data. The original harbour fixture was opened read-only through UI.
## Scope and remaining verification
This pass covers Windows. Linux rendering/runtime, final packaging, full
automated checks, and edits to source after review started are outside this
review's evidence. Exact-string edge cases were not re-exercised here because
the primary independent focus was navigation, source/property failure recovery,
relation mutation, process editing, and responsive layout. Accessibility tree
for Iced exposed the native window rather than individual application controls;
app interaction therefore used inspected screenshots and keyboard input.
Computer Use ownership released to the lead agent after confirmed clean exit.
## Final release follow-up — 2026-09-05
Independently launched
`D:/CodexBuilds/Capella2-01a06e2e/release/arcadia-studio.exe` and personally
verified the following using Computer Use at the default 1440x900 content size:
- **Pending identity + same-card drag regression passed.** Selected Report
distress (position 360,250), typed stable ID
`00000000-0000-4000-8000-000000000123` without Apply, then dragged that same
card. The card moved to 390,570 and retained both relationships. Canonical
Text displayed the new UUID and `position (390, 570);`; both the allocation
and interaction still referenced `report_distress`. Counts remained 9
elements / 9 relationships / 0 checks. Undo first restored 360,250 while
retaining the new ID; a second Undo restored the original ID and clean state.
- **P3 contextual warnings resolved.** Moved Incident assessment above Distress
signal. The two Model checks messages now separately identified steps 1/2
and 2/3, the interaction names, and the incompatible ending/starting activity
names. Undo restored All checks passed.
- **P2 inspector scroll issue resolved.** Scrolled the process inspector to
Share & Explore, then selected Project properties. Inspector reset to its top,
with project name and Apply properties immediately visible.
- **P2 horizontal connection issue resolved.** Re-entered the exact Review
cycle fixture from the original finding. At 60%, Observe and Respond were
visibly joined by a continuous line and directional arrow; Report appeared
above the line in the gap, outside both cards. No background mask obscured
the connection.
All temporary changes were undone. Alt+F4 closed the clean release, and a fresh
window inventory confirmed it exited. No test fixture was saved or overwritten.
No unresolved material UI findings remain from this review. The final follow-up
does not replace the initial minimum-size coverage or the lead's Linux checks;
it specifically proves the reviewed fixes and pending-ID/drag regression in the
actual Windows release. Computer Use ownership released again after exit.
+60
View File
@@ -0,0 +1,60 @@
# V2 API/source/desktop transfer verification
Date: 2026-09-05. Integration worker: `v2_requirements_arch_review`. Native Computer Use was performed by the lead; this worker owns no CUA session. Code remained unchanged. Documentation changes: the new `RelocateNode` command schema in `docs/openapi.json`, a corrected title underline in `docs/api.rst`, and V2 README/scope/architecture updates.
## Checks completed
- After the core worker declared the final core changes stable, `cargo test -p oa-server --locked` passed all 12 actual HTTP/configuration/storage tests on Windows.
- `cargo clippy -p oa-server --all-targets --locked -- -D warnings` passed.
- `cargo build --release --locked -p oa-server` passed; the resulting optimized executable was used for the transfer below.
- `docs/api.rst` initially failed warning-as-error rendering at its too-short title underline. The authorized documentation fix was applied; Docutils HTML5 rendering then passed with `halt_level=2` and `report_level=2`. Output: `D:/CodexBuilds/Capella2-v2-01a06e2e/api-review.html`.
- OpenAPI parses as JSON, declares exactly one `RelocateNode {node, diagram}` command variant, and the actual release server serves that updated schema.
- Rewrote README, scope and architecture for V2. The README's new source example was parsed by the actual core. A focused independent `cargo test -p oa-desktop --locked forms::` pass ran all six form tests successfully after the membership/perspective fixes.
## Actual release transport workflow
The desktop executable's headless `--write-example` entry point generated `api-input-demo.arcadia`. This is a generated V2 example, not a claim that this worker saved it by operating the GUI. A fresh isolated loopback server imported the source with `Content-Type: text/plain`, preserving model identity while assigning a distinct hosted resource identity.
1. Import returned revision 1.
2. Conditional `PATCH /api/v1/projects/{id}` renamed the project and returned revision 2.
3. One conditional transaction edited the SA function name and CAD artifact URI/revision, returning revision 3.
4. Exact model comparison proved that all UUIDs, aliases, diagram placements, traces, occurrence lists and other fields remained unchanged apart from those intended values.
5. An actual HTTP dry run created a proposed diagram and applied `RelocateNode` into it. The candidate moved the intact placement; the accepted model and revision stayed unchanged.
6. `GET .../source` exported canonical source. Reimporting it into a separate hosted resource produced an exactly equal model, including all persistent identity and artifact metadata.
7. The server log contained only the expected startup line, with no runtime error. The verification process was terminated after requests completed; this is not a new graceful-shutdown claim.
| Property | Verified value |
|---|---|
| Hosted resource | `6e6204f4-6def-43b7-a7db-1c09e93c5775` |
| Hosted revision | `3` |
| Model UUID | `e0242a95-142d-4a44-8f27-1afd019e879b` |
| Project name | `Coastal rescue - API integration review` |
| SA function alias | `classify_incident_and_alert_operator` |
| SA function UUID | `b8a17e7e-d94b-429d-9899-5c1eca899efa` |
| SA function name | `Classify incident and coordinate rescue (API review)` |
| Artifact alias | `console_enclosure_cad` |
| Artifact UUID | `7a4eb9a9-6951-4d6a-aaea-fcf760bb8241` |
| Artifact URI | `cad/console-enclosure-reviewed.step` |
| Artifact revision | `CAD-REV-B-api-review` |
| Retained model contents | 39 elements, 23 relations, 3 diagrams, 10 traces, 2 artifacts |
GUI-ready source: `D:/CodexBuilds/Capella2-v2-01a06e2e/api-edited-demo.arcadia`.
Reproducible transfer script and structured result: `D:/CodexBuilds/Capella2-v2-01a06e2e/api-transfer.py` and `api-transfer-result.json`. Isolated store/log/result directory: `D:/CodexBuilds/Capella2-v2-01a06e2e/api-transfer-50d2b0c1-0035-4060-8afc-b37a9d4aa1a4`.
## Lead's native GUI verification
The lead reported personally opening the exported `.arcadia` through the Windows file picker. The actual running application displayed the changed project title, the API-renamed SA function with its preserved alias, and the CAD URI/revision in Traceability. Counts remained 39 elements and 23 relationships, with one expected review-drift warning caused by the independently renamed traced SA function. This closes the REST-export-to-native-desktop portion of the transfer. Further native editing/save/reopen is being performed by the lead and must be recorded after its result is observed.
## Reproducible build commands
The ordinary repository commands require no D: cache convention:
```sh
cargo test -p oa-server --locked
cargo clippy -p oa-server --all-targets --locked -- -D warnings
cargo build --release --locked -p oa-server
cargo run --locked -p oa-server --bin arcadia-server
```
This worker used the pre-existing D: build target to share available dependencies. Windows native tests/release are this pass's evidence. Previous native Linux service evidence remains in `docs/server.md`; this pass did not repeat Linux tests, Docker, a remote deployment or systemd installation. Docker was not retried because no daemon was available. Overall desktop workflow, package and multi-platform acceptance remains the lead's responsibility.
+67
View File
@@ -0,0 +1,67 @@
# Independent V2 correctness review
Review date: 2026-09-05. Read-only review of current core, text/persistence and desktop state flow against PLAN and language.rst; no Computer Use (separate UI reviewer owns it). Implementation-owner conclusions were not treated as proof. Review remains open until the findings below are independently reverified.
## Evidence actually run
- `cargo test -p oa-core --locked --offline` on Windows, D: target: 41 tests pass (12 language, 1 process diagnostics, 28 workflows). Existing tests do not cover the counterexamples below.
- Standalone executable probe outside the repository: `D:/CodexBuilds/Capella2-v2-01a06e2e/correctness-review/src/main.rs`, with Cargo manifest in its parent. Run using `cargo run --manifest-path D:/CodexBuilds/Capella2-v2-01a06e2e/correctness-review/Cargo.toml --offline` and the same D: target. It reproduces findings C1–C4 without modifying repository source.
## Material findings
### C1 — High: reviewed Keep Target value is overwritten on unchanged re-preview
Location: `crates/oa-core/src/transitions.rs`, field reconciliation around `let safe` (line 634 at review).
Reproduction: create OA Activity named `Operational assessment` and SA Function named `System classification`. Explicitly link them with Name = KeepTarget; apply. Without changing either object, preview the same OA source again with defaults.
Observed: no conflicts, action Update, Name before `System classification` -> `Operational assessment`. Apply overwrites the value the engineer just chose to preserve. The safe test checks only the destination against its baseline; it never compares the source against its own baseline. The existing conflict test stops immediately after KeepTarget and misses the second preview.
Expected: unchanged reviewed divergent values remain unchanged in either direction. Only a source change should trigger normal propagation; genuine subsequent competing changes should still conflict. Root assigned a worker fix and focused regressions; independent re-probe pending.
### C2 — High: normal Save overwrites external edits without a conflict
Location: `crates/oa-core/src/persistence.rs` unconditional atomic replacement, and desktop save/load snapshot flow.
Reproduction: save/open a model; change the disk model name externally to `External update to preserve`; change only the loaded in-memory description; save loaded snapshot to the original path.
Observed before fix: save returns success; external name is reverted to `Untitled mission`. This is ordinary Git/text-editor/second-instance use of the requested text-first workflow. Atomic replacement prevents partial files, but does not prevent lost updates. The language spec originally excluded conflict resolution from the storage contract; PLAN nevertheless explicitly requires file-conflict checks. Root accepted this as an application safety requirement and is adding a checked save path. Independent verification must exercise the desktop guarded path; the explicit low-level overwrite helper may remain available.
### C3 — Medium: same-parent Reparent changes behavior ordering
Location: `crates/oa-core/src/session.rs`, `Command::Reparent` (line 420 at review).
Reproduction: create a process with two distinct occurrences, then execute Reparent on its first occurrence with the exact existing parent ID.
Observed: `[first, second]` becomes `[second, first]`; revision 2 becomes 3. Unconditional detach/attach makes an idempotent ownership update silently alter sequence semantics. Fragment branches use the same mechanism and also require coverage.
Expected: unchanged ownership preserves order, history and revision. Root assigned worker fix; independent re-probe pending.
### C4 — Medium: primary child-creation control cannot populate a fragment
Location: `crates/oa-desktop/src/app.rs`, `add_element` (line 1095 at review).
Reproduction: select an Alternative Fragment occurrence, select Occurrence kind, then use `+ In selected`. The enabled state comes from `can_parent`, which returns true. Desktop constructs `make_element` followed by `CreateElement`, yielding the default Exchange occurrence under the fragment.
Observed via the exact core candidate path: `Err(ModelError("occurrence_owner: Nested occurrences belong to branches; branches belong to fragments."))`. The existing core AddElement command correctly creates Branch for this parent and succeeds. Thus the primary GUI workflow disagrees with its enabled state and shared command behavior; a multi-field manual workaround is not an adequate primary flow.
Expected: create an empty Branch under Fragment, and ordinary occurrences under Branch. Root notified; runtime confirmation and focused reducer regression remain required.
## Extension of a previously known finding
Root's same-kind data-reset fix also applies to the constructor pickers in `forms.rs`, not only ElementKind/RelationKind. The picker determines its selected entry using `same_variant`, but emits a fresh default payload even when the selected constructor is unchanged. Re-selecting Enumeration erases literals; Named data type clears the referenced type to nil; Exchange occurrence clears exchange/sender/receiver. Root notified; treat this as part of the existing same-kind fix rather than a duplicate independent issue.
## Review limits
No claims about native rendering, pointer behavior, Linux execution, service HTTP routes, or finished requirements coverage are made here. These belong to the parallel reviews. No additional blocking reference-cleanup or text round-trip defect was found in the reviewed paths; this does not supersede the findings above.
## Focused re-probe during integration
The final standalone probe was rebuilt and run again after the workers' current changes became visible (exit 0). Observed results:
- C1: unchanged re-preview now reports `Reuse`, empty fields, no conflicts; the SA name remains `System classification`.
- C2: `save_checked` with the exact bytes originally read returns `Err(Conflict)` after an external name edit; an assertion verifies the external name survives. The explicit low-level `save` still overwrites by design. Desktop wiring and its user-facing conflict workflow still need runtime verification.
- C3: unchanged-parent Reparent now preserves `[first, second]` and revision remains `2 -> 2`.
- C4: the exact make_element/CreateElement path now succeeds, as does core AddElement. GUI child creation still needs runtime verification.
These independent probes confirm the originally reported core counterexamples are fixed in this snapshot. The implementation worker's broader new regressions and the desktop constructor-picker fix still require the final focused review once source stabilizes. Per root request, this review turn is ending to free an implementation slot; it does not claim final application acceptance.
+24
View File
@@ -0,0 +1,24 @@
# Independent review of final desktop regressions
Reviewer: v2_ui_runtime_review. Scope: latest root-owned `App::apply`, `selected_behavior` StateTransition selection and the SelectNode-before-MoveNode regression. Read-only source review; no builds, tests or Computer Use were run in this pass. Forms implementation was explicitly excluded because this reviewer authored it.
**Result: no material correctness or maintainability finding in the reviewed changes.**
- `App::apply` adopts identity, active diagram, selection and layer only after the core transaction succeeds. Failed commands return before navigation mutation and retain the draft. For a selected placement, searching the committed diagram map finds its actual owner after relocation or UUID change, then sets `layer`, `active_diagram` and `selected_node` together. For an edited diagram, the same lookup adopts its committed layer and clears node selection. Subsequent `sync` retains that valid same-layer diagram and normalizes creation kind. This handles an OA element placed in an SA traceability diagram using the placement owner's perspective rather than the semantic element's perspective.
- The placement regression now sends the real canvas message sequence: SelectNode on press, then MoveNode on release. SelectNode's early return for the already selected placement deliberately keeps its identity draft pending. MoveNode records the original selected identity, applies once, and remaps the old node ID to the committed selection before the move. `DiagramCanvas::update` was inspected to confirm this event order. The test also checks that editing diagram identity before Arrange keeps the new active diagram.
- `selected_behavior` resolves a selected StateTransition to its source state before traversing semantic parents. A valid transition source is an existing state in its machine; core validation rejects dangling endpoints and containment cycles before models enter Session. The traversal therefore terminates at the StateMachine without falling back to an unrelated first scenario. The focused regression checks source and target belong to that returned machine. Ordinary sequence, occurrence, region and state traversal remains unchanged.
- The added placement relocation test checks actual model ownership, active diagram, selected node and layer after cross-layer traceability relocation, then checks a diagram perspective edit. These assertions cover the new navigation contract; no new abstraction or duplicate model state was introduced.
This source review is evidence for the narrowly scoped fixes, not a substitute for root's pending final automated and native runtime verification.
## Follow-up: merged-text focus stability
Read-only review of root's `workflow.rs` fix after the native Linux typing failure. No build, test or CUA in this pass.
The fix addresses the reported widget identity loss: changes and general conflicts now each occupy one unconditional outer column slot. Resolving a field may change their contents, but no longer shifts the later input's sibling index. Field cards use a sorted union of current conflicts and retained resolutions, so resolving the first field does not remove its card or reorder another focused card. Core planning retains a `TransitionChange` for reuse as well as update, so the mapping-card source set stays stable during merged-value typing. Each resolution card has a fixed child structure, and its text input reads the retained `FieldDecision::Value` for the same `(source, field)` key. No remaining focus-identity defect was found for consecutive Resolve events. Card geometry can still move when preview text wraps; continuous native typing/retyping still needs observation after rebuilding.
One existing decision-identity hazard remains outside that focus fix: `Event::MappingTarget` and `MappingKind` change the target mapping but retain earlier field resolutions for the same source. Enter merged text for counterpart A, then choose counterpart B: the old Value decision is reused when replanning B, without requiring a new resolution. Clearing that source's resolutions when its target/kind actually changes would prevent a reviewed decision from carrying into a different target context; selecting the same mapping should preserve it. Reported to root as a concrete follow-up, not as a regression caused by the stable-column change.
## Final disposition
The reported decision-identity hazard is fixed: resolutions now belong to the effective target/kind. The focused regression covers retargeting, same-target preservation, creation and kind changes. The separate requirements reviewer inspected the final fix and found no new material issue (`review-v2-final-ui.md`). The lead personally typed continuously, changed counterparts, observed the old decision clear and Apply block, then explicitly reviewed and committed the new values on the rebuilt native Linux application (`verification-v2-native.md`). The pending runtime checks above are therefore closed by those separate evidence records; this reviewer does not claim to have performed them.
+67
View File
@@ -0,0 +1,67 @@
# Independent final native UI review
Reviewer: requirements/architecture agent, independent of desktop implementation.
Date: 2026-09-05. Windows native Iced application operated through the Computer Use skill (`@oai/sky`). No desktop source edits.
## Build and fixtures
- Built current source with `cargo build --locked -p oa-desktop --bin arcadia-studio`, using `CARGO_TARGET_DIR=D:/CodexBuilds/Capella2-01a06e2e`. Build passed.
- Launched distinct copy `D:/CodexBuilds/Capella2-v2-01a06e2e/final-ui-review/arcadia-studio.exe`. Closed the previous throwaway test session through its normal unsaved-changes guard.
- Rebuilt and relaunched after the state-transition selection fix, numbered transition details, and Ctrl+O/Ctrl+N wiring. Second process session: 69649, native main window 1380574.
- GUI-authored scenario fixture saved at `D:/CodexBuilds/Capella2-v2-01a06e2e/final-ui-review/branching-reviewed.arcadia`.
- Additional isolated `controls-fixture.arcadia` loaded through the native Open dialog for focused trace/placement/perspective tests. This is disposable review data.
## Observed passes
- OA process renders participant lifelines and a message; SA repeated-report scenario renders two participants and two distinct occurrence arrows. Clicking a message selects its occurrence, highlights it, and opens the corresponding properties.
- Through actual controls: added an occurrence, changed its kind to Fragment, created a Branch with `+ In selected`, entered guard `sea_state > 4 && operator == "Ready"`, then created an owned exchange occurrence.
- Exchange choices were filtered to compatible exchanges; sender/receiver choices were filtered to the valid lifelines. Assigned the typed exchange and both endpoints. The resulting alternative fragment, guard text, and nested message rendered; model had 42 objects, 23 links, and zero checks.
- Saved the authored branch fixture through native Save As; the unsaved marker cleared and the application reported Project saved.
- Inspected default 1440×900 client, exact minimum 1100×700 client (native Size menu), and maximized 2560-wide layout. Primary navigation and action controls remained reachable. At minimum width, horizontal scrolling inside the scenario canvas actually revealed the other lifeline. No overlapping controls observed in these workflows.
- Rebuilt state view renders three numbered routes and matching numbered detail cards with source/target, trigger, guard, and effect. Selecting route 1 (`Signal restored`) retains the state-machine view, highlights the route, and selects the correct transition properties.
- At 150% architecture zoom, the parent function and both nested children have separated title and alias lines. The enlarged parent header keeps child content clear; no title/alias overlap observed in the reviewed decomposition.
- Ctrl+O opens the guarded native file picker; the focused review fixture loads successfully.
## Material finding and re-verification
**F1 — fixed and personally reverified:** selecting a state-transition route previously jumped the center pane back to the first scenario while selecting the transition in the inspector. Reported to the lead; the lead changed active-behavior resolution to follow the transition source through its region to its machine. On the rebuilt executable, selecting `Signal restored` retained `Reporting operation modes`, highlighted the correct route, and showed its matching guard/effect. The numbered transition detail cards also match the rendered route numbers.
## Remaining bounded review
Conflict resolution values/KeepTarget/merged text; manual trace explicit target; shared data perspective editing; placement diagram/UUID editing followed by actual dragging; and saved branch fixture reopening remain to be exercised by this reviewer. Native input paused because the application was being actively manipulated between observations and Computer Use twice reported user input detected. The lead was notified; no concurrent input attempted after the pause. CUA ownership was explicitly released to the lead. The copied Windows app remains open with disposable review data; the saved branch fixture is separate.
The lead subsequently identified a placement focus corner case by source inspection and is handling its fix and regression: moving a placement into an opposite-layer Traceability diagram must select the owning diagram's layer. This reviewer has not runtime-verified that later fix.
This report covers personally observed Windows behavior only. It does not assert Linux runtime acceptance, complete keyboard accessibility, large-model performance, or final product completion.
## Final bounded source follow-up
Independently inspected the final changes in `workflow.rs`, the target/kind decision regression in `tests.rs`, and the placement artifact label in `views.rs`. No builds or native inputs were run for this follow-up; the lead owns final native verification.
- **Merge-input focus fix:** changing preview rows and general conflicts are now contained in stable child columns. Conflict property cards include both unresolved fields and existing resolutions and sort by source identity and field, preserving their order after each replan. The input remains in the same card position while its status and preview change. No further source-level focus defect identified within this change; continuous typing still requires the lead's native confirmation.
- **Decision invalidation fix:** changing the effective counterpart clears that source's prior field decisions; choosing the same inferred or explicit counterpart preserves its draft. Moving from an existing counterpart to creation clears old decisions. Counterpart-kind changes also clear decisions while selecting the same effective kind preserves them. The inspected regression asserts retargeting restores an unresolved conflict and blocks Apply, then verifies a newly reviewed value updates only the second target. It also covers creation and kind changes. No new material issue found.
- **Placement artifact label:** artifact owners that are placements resolve through the containing diagram's node map and display `Placement of <element> · <diagram>`; other owners retain the existing semantic-object name path. This handles valid placement references without falsely labeling them as missing. No new material issue found.
These are source-review dispositions, not claims that the later fixes were personally exercised by this reviewer.
## Packaged Windows creation-placement acceptance
Built the final frozen source with `cargo build --release --workspace --locked` using the D: target directory; build passed. Copied both release executables to `dist/ArcadiaStudio-Windows` and launched that packaged `arcadia-studio.exe` through its normal entry point.
Personally exercised on the actual packaged Windows application:
1. Started the fresh 39-object demo, selected SA Architecture, and observed `SA functional decomposition`: one parent function and two child function placements.
2. Opened Behavior & scenarios, selected `Repeated distress reports`, clicked `+ Occurrence`, changed the new occurrence to Action, and named it `Review response readiness`.
3. Assigned `Classify incident and alert operator` and its compatible `Coordination system lifeline`. Committed the properties. The action rendered on the coordination lifeline after the two existing report messages; the model showed 40 objects, 23 links, and zero checks.
4. Returned to Architecture. The same three function placements remained; no occurrence card was added.
5. Used native Save As to write `D:/CodexBuilds/Capella2-v2-01a06e2e/final-ui-review/packaged-behavior-placement-reviewed.arcadia`, reopened it through Ctrl+O and the native file picker, and rechecked both the unchanged three-card decomposition and the rendered saved action.
6. Closed the packaged app normally with Alt+F4. A fresh native window inventory confirmed that it had closed. CUA ownership was released to the lead.
The saved source independently confirms `@new_occurrence` is an Action owned by `@repeated_distress_reports`, belongs to its ordered steps, refers to the selected function/lifeline, and has no architecture placement.
Source review found one shared `self.page == Page::Diagram` guard in `App::add_element`, used by both `Message::Add` and `Message::AddOwned`. It confines implicit placement to Architecture while retaining semantic creation/step updates on other pages. Explicit `PlaceSelected` remains available. This is simpler than duplicating guards in both message branches. The worker's new regression was inspected, but its execution is recorded by the worker/lead rather than claimed here. No new material finding in this bounded review.
Final packaged Windows SHA-256:
- `arcadia-studio.exe`: `E2AEC2AC935E270C6185729CBB76F8323B381654C04DBDE7AAE90C4628A98A20`
- `arcadia-server.exe`: `D33EDAE56308035781856AE54358DEF59818CC93242380BC29C874F7DC7C53E4`
@@ -0,0 +1,76 @@
# V2 independent requirements and architecture review
Date: 2026-09-05. Reviewer: fresh `v2_requirements_arch_review` agent. Scope: user objective, PLAN/STATE, normative `docs/language.rst`, current core/desktop/service implementation, research and deployment docs. Source was read-only; no Computer Use was performed because the lead owns the desktop. This is not a substitute for the separate runtime acceptance pass.
## Latest disposition after integration
R1–R7 are addressed in the current implementation/contract. Independently re-read the changed code: conflict cards now identify the object pair/field and both values, keep resolution controls after selection, accept merged text and display warning messages; the source caption explains comment loss; the role rule explicitly describes its advisory warning; and root StateMachine choices agree with incomplete-model validation. The core now exports counterpart-kind choices rather than requiring a divergent desktop policy.
An independent executable rerun confirms the offered Capability→Mission mapping has no conflicts. `cargo test -p oa-desktop --locked forms::` passed all six focused form tests, including placement relocation plus UUID change with one-step undo, shared perspective movement preserving payload, incompatible-dependency rejection and filtered references. The README V2 source example was also parsed successfully. The Branch constructor fix remains independently verified.
No unresolved source-level blocking requirements or architecture finding remains from this review. Native interaction/visual acceptance of the updated conflict and membership controls belongs to the lead's runtime pass; this reviewer does not infer it from passing reducer tests. The original findings below remain as the audit trail, with their initial pending language superseded by this disposition. Manual desktop/API transfer is now documented and was exercised over real HTTP; the lead confirmed the exported changes in the native GUI, recorded in `review-v2-api-transfer.md`.
## Findings requiring disposition
### R1 — P1: counterpart conflicts cannot be meaningfully reviewed in the dialog
`crates/oa-desktop/src/workflow.rs`, conflict rendering around line 450, displays only the generic conflict message plus **Keep target / Take source**. It does not identify the source, target, field, or either value. Conflicted fields are omitted from `plan.changes`, so the separate change list does not supply the missing comparison. Two simultaneous Name/Description conflicts are indistinguishable. This undermines the primary reviewed bidirectional update workflow and can lead an engineer to overwrite the wrong property. Show labeled source/target values and field identity, with the existing core merged-value decision if practical. Also display actual warning messages; the present dialog shows only their count.
Verification: independently traced `plan_transition` conflict generation and `Workflow::view`; reported promptly to lead. Pending implementation and actual GUI verification.
### R2 — P1: advertised capability/mission transitions are rejected by core
`workflow::counterpart_kinds` offers OA Capability -> SA Mission and SA Mission -> OA Capability. `transitions::compatible_kinds` only supports Capability <-> SystemCapability, participant choices, and inferred same-kind shared mappings. Choosing Mission therefore yields an unrecoverable automatic-mapping conflict. Implement the offered method mapping (a Manual trace can express the special correspondence), or remove unsupported menu choices and disclose scope consistently.
Verification: external executable probe constructed an OA Capability and an explicit Mission mapping; `plan_transition` returned `Counterpart kind is not valid for this automatic transition.` Probe is at `D:/CodexBuilds/Capella2-v2-01a06e2e/requirements-review`, outside repository sources. Pending fix/reverification.
### R3 — P2: two stored membership choices lack direct graphical editing
- `forms::Draft::from_project` stores a Node's containing diagram in `RecordKind::Node(diagram)` out of band. `Draft::command` always edits the node within that diagram. There is no graphical destination-diagram property or move-placement operation. In source, changing the node's `diagram @alias` preserves node UUID and artifact references while moving its membership.
- Shared elements derive perspective from the Oa/Sa body wrapper. The inspector offers kinds only in the current layer and hides those wrappers. A source edit can move an isolated shared element to the opposite layer while preserving its identity, but no corresponding graphical operation is exposed.
The normative contract explicitly promises every persistent property in both editing forms. Add explicit validated move operations, preserving references and identity. This is about stored membership parity, not automatic cross-layer realization or silent drag semantics. Pending disposition.
### R4 — P2: source editor does not explain comment loss
`docs/language.rst` section 7 requires the editor to explain that canonical Apply discards comments/whitespace. Neither the Text workspace caption nor the Engineering guide currently mentions this. A short source caption is sufficient; comments are especially plausible for the promised human/AI/Git authoring workflow. Pending UI copy fix.
### R5 — P2: normative role-allocation rule disagrees with diagnostic severity
Section 4 says a direct allocation must not contradict role-realizing performers. `validation::validate_relation` reports `role_allocation_conflict` as a Warning, allowing the candidate to commit/save. Advisory diagnosis can be a reasonable authoring decision, but specify it as such instead of an unconditional prohibition. Pending contract or behavior alignment.
### R6 — P2: state-machine parent-choice predicate excludes a valid incomplete model
`validation::can_parent(... StateMachine, None)` returns false, disabling **At root** and potentially hiding a valid parent choice from filtered forms. Normative section 4 and `validate` permit an unowned machine with a warning. Align the creation/reference predicate with that explicit policy. Pending fix.
## Finding already fixed during review
R7 — Initial Branch creation under a Fragment previously used `make_element`'s default Exchange body in the desktop, while only `Command::AddElement` converted it to Branch. The UI enabled **In selected**, then validation rejected creation before the user could change the variant. The lead/core worker moved the context-sensitive construction into `Project::make_element` during this review. The independent executable probe now confirms both the desktop-style `CreateElement(make_element(...))` and `AddElement` accept a Branch under a Fragment. Actual scenario UI authoring must still be exercised after integration.
This fix is also a concrete architecture improvement: one context-aware constructor avoids desktop/core command divergence.
## Coverage and scope assessment
- Core exposes OA participants/roles/work/goals/processes and SA System/Actors/functions/missions/capabilities/chains, with typed relations, decomposition, leaf allocation, independent diagram placements and traces. Shared payloads cover data/items/interfaces/ports, rich scenario occurrences/fragments, state-machine regions/transitions/actions/availability and constraints. These are substantive OA/SA semantics, beyond renamed V1 enums.
- Text has a closed versioned language, stable aliases/UUIDs, typed constructors, reference resolution, canonical ordering, tolerant tokens/lint, strict validation and explicit deterministic V1 migration. The normative contract is detailed enough to assess supported field parity, but the inconsistencies above must be corrected before calling it satisfied.
- Desktop source exposes creation/editing for element/relation/diagram/placement/trace/artifact record families, ordered occurrence lists and typed variant controls. Source editing and graphical edits share the Session boundary. Behavior graphics are actively being replaced by the lead; old flat lists are a known pending milestone, not an independently verified completed behavior view.
- REST uses the same Project/Command/language/validator, with resource identity separate from editable model identity, ETag preconditions, atomic envelopes, bounded requests and a single-owner local store. Query, source, validation, transaction, transition and artifact routes exist. Deployment recipes are concrete; Docker and installed remote service execution remain unverified, as documented.
- Desktop hosted-model editing is absent: no API endpoint/open/save client exists. This is not automatically a demand for collaboration. The literal backend requirement can be met by the independent hosted model service, but final limitations must say that desktop and hosted models transfer by import/export. Acceptance should exercise desktop export -> REST import/edit/export -> desktop reopen so the claimed integration is demonstrated.
- Transition scope is a reference/ownership closure, not all related content. An independent probe confirmed **Whole subtree** with two selected activities does not include their connecting interaction. Allocation relationships and allocated work are likewise not implicit ownership children. Explain this in user-facing scope/help rather than promising a complete architectural copy. Existing-target updates deliberately compare names/descriptions only, not structural synchronization; the normative spec discloses this boundary.
- LA/PA components/deployment, simulation, native `.capella/.aird` interchange, complete SysML/Capella conformance, advanced capability include/extend/generalization, distributed collaboration and retained service history are legitimate declared prototype boundaries. This review does not request those systems as speculative extensions.
## Architecture and simplicity assessment
The three-crate boundary is appropriate: one renderer-independent typed core, an Iced interaction/draft layer, and a headless transport/persistence layer. Candidate validation before adoption is shared by all editing paths. UUID references and persisted aliases serve separate clear purposes. Diagrams do not own semantics. Projection reuse for canvas/Fit/SVG avoids duplicate layout meaning. Full snapshot history and whole-envelope persistence are reasonable for the explicit bounded prototype; no speculative plugin ABI/database/event framework is needed.
The material maintainability risk is duplicated domain-choice policy in desktop helpers, evidenced by R2 and R7. Expose a small core query for permitted transition target kinds, analogous to `can_parent`/`can_connect`, rather than maintaining a separately diverging match. Keep generic JSON only as a closed temporary form adapter; future additions need a graphical reachability test, not just a lossless no-op serialization test. The existing `every_demo_record_has_a_lossless_graphical_draft` proves preservation but cannot prove that every control/action exists.
No additional architecture blocker was found. Avoid broad module rearrangement solely for line-count/style preferences. Final README/architecture/scope/acceptance documents are still V1 and must be rewritten as the lead already plans; they currently contain false V2 statements about one diagram, transient aliases, process exchange IDs and absent roles/hierarchies.
## Verification performed by this reviewer
- Read the user objective and authoritative plan/contract, inspected core model/session/references/projection/transitions/validation plus graphical drafts/builders/views and service routes/store/deployment boundaries.
- Ran a standalone Rust executable against the current `oa-core`: reproduced R2; verified the integrated R7 constructor fix; established actual transition scope behavior for connected work endpoints.
- Did not run the native GUI, Linux application, full regression suite, service HTTP tests or packaging. Those are separate lead/runtime/QA responsibilities and remain required completion evidence.
Initial review status was incomplete; the latest disposition above records the subsequent fixes and independent focused verification. Overall product completion still depends on the lead's final runtime/platform/package evidence.
+54
View File
@@ -0,0 +1,54 @@
# Independent V2 UI/runtime review
Reviewer: v2_ui_runtime_review. Completed 2026-09-05 03:30 +03:00. This is a diagnostic review of a fixed integration snapshot, **not final V2 acceptance**. Root continued editing after the build; subsequent fixes need a fresh runtime pass.
## Evidence and scope
- Read current goal, PLAN, STATE and Computer Use skill/guidance/API/confirmations. No source files edited.
- Ran `cargo build -p oa-desktop --locked` with `CARGO_TARGET_DIR=D:/CodexBuilds/Capella2-01a06e2e` and TEMP/TMP on D. Build passed.
- Copied binary to `D:/CodexBuilds/Capella2-v2-01a06e2e/ui-review/arcadia-studio.exe`; SHA256 `E54E2A6673E5D814F04D1B06BFCAA1C0F00C3DC7CA6F259AEB4472FB70244ED2`.
- Launched copied native Windows executable and operated it through `@oai/sky` using screenshot observations after each input. Target window was 1839418, title Coastal rescue — operational need to system behavior — Arcadia Studio. Original Capella was left untouched.
- Captured and personally inspected default 1440×900 client, minimum 1100×700 client and maximized 2560-wide layout. Screenshots are in the Computer Use transcript; no duplicate screenshot payloads were saved. Native menu Size → Right → Down → click lower-right target produced exact minimum size; maximize/restore worked.
- `ui-review/stderr.log` remained empty through shutdown. No crash was observed. All test edits were in the unsaved demo; close guard appeared and Discard closed only the review copy. CUA ownership is released to root.
## Material findings
### P1: modal allows background navigation
Reproduction at 1100×700: Traceability → select the SA Rescue coordination system endpoint → Create/update counterpart → System → Operational modal. Click dimmed Architecture sidebar at approximately (70,206). Underlying page switches from Traceability to Architecture and sidebar highlight changes while transition modal remains open. Confirmed visually, not inferred from code. Pointer input must be captured by the overlay and background state-changing messages gated. Root was notified immediately and reports a source fix; this snapshot did not include that fix.
### P1: behavior workspace omits primary behavioral relationships
At both compact and wide sizes, SA Reporting operation modes shows three flat rows with identical circular glyphs: Degraded reporting, Initial Start reporting and Normal reporting. The overview does not depict transitions, their source/target, guards, initial destination, actions or availability. Repeated distress reports is two identical Validated distress report rows without visible lifelines, message sender/receiver or fragments. These are record browsers rather than usable scenario/state views. Root acknowledged and is implementing behavioral visuals. Those changes require separate review.
### P2: automatic layer switching leaves incompatible create kind
Reproduction: apply System → Operational counterpart update on Rescue coordination system. Application selects the OA entity and OA layer, but CREATE ELEMENT still displays Function from SA. Undo also retains this inconsistency. Explicitly clicking a layer tab later resets the selection. Normalize creation kind whenever navigation/transition changes the current layer. Root reports a source fix; not reverified in this snapshot.
### P2: architecture edge/label overlap reduces readability
Default 1440×900 → SA allocation → select nested Classify incident and alert operator. Straight edge portions traverse System/Actor header text; selected-edge captions including System capability support, chain and functional-exchange labels overlap around the central chain/actor region. The dense overlap persists at minimum size after Fit. Different relations should have distinguishable routes/label positions; parent/performer headers should remain legible. No routing fix was observed in this snapshot.
### P2: property forms expose raw storage labels
Selecting Backup electrical energy exposes consecutive Shared / ExchangeItem / Kind headings. Selecting the created Functional exchange exposes FunctionalExchange twice, before Items and Source. These duplicate raw type names add clutter and do not help engineers make a choice. Use user-facing semantic field groups. Selected catalog/sidebar rows use dark blue-gray backgrounds with gray secondary labels; contrast is visibly poor compared with unselected labels.
### P3: narrow diagram selector clips title
At 1100×700, current diagram selector becomes roughly 108px wide and wraps SA system boundary and functions across more text than its fixed height shows. Remaining toolbar controls fit. A compact ellipsis/tooltip or second toolbar row would communicate the chosen view more clearly.
## Workflows actually observed passing
- Rich 39-object/23-link demo launches with zero checks. OA participants show activity allocated within entity/actor; SA shows function inside system and external actor. Layer navigation and model selection work.
- Fit adapts graph to reduced center width; app navigation, property inspector, data list, source editor and counterpart/relationship modals remain reachable at 1100×700. Wide layout does not clip inspector or task navigation.
- Source action from Classify incident and alert operator opens its declaration. Source action from late-ID Backup electrical energy scrolls substantially down to the correct declaration. Syntax colors visibly distinguish keywords/references/strings. The target declaration can land at the bottom of the editor rather than top, but it is visible.
- Created SA Function at root; renamed it to `Review "quoted" function`; Apply saved the literal quote-bearing name while stable alias stayed `new_function`.
- Created Functional exchange through explicit modal, source new function, chosen compatible target Classify incident and alert operator, name Review outcome. Apply committed it, selected the relation and showed the new canvas edge; link count increased 23→24. Missing target/name correctly left Apply disabled before completion.
- Reverse counterpart preview displayed OA Rescue coordination → Rescue coordination system descriptive change. Apply committed it atomically and selected OA entity. Ctrl+Z restored the name and showed Model change undone. No counterpart duplication was observed for this update.
- Artifact action created an editable reference owned by the selected Review outcome exchange. Inspector exposed owner, relation, URI, optional revision and fragment. Arbitrary URI editing/save/reopen was not completed in this bounded pass.
- Inserted `?` at source beginning. Live lint displayed `1:1 Invalid token '?'`. Apply rejected the draft, retained visible `?`, and displayed Source contains errors. Your draft is preserved. Revert restored accepted source and removed lint. Model counts remained unchanged.
- Close with unsaved edits displayed Keep your changes? with Cancel, Discard changes and Save & continue. Discard closed the temporary review application; fresh window inventory confirmed it absent.
## Required follow-up / not claimed
Reverify fixed overlay capture and layer-kind normalization; inspect new state/scenario views and routing at all sizes. This pass did not complete forward transition creation, conflict choices, manual trace editing, graphical decomposition editing, node/placement UUID drag remapping, exact CR/LF/tab round trip, save/reopen, artifact URI/revision edits, or native Linux runtime. Existing reducer tests are not substitutes for those real-app workflows. Initial post-input screenshots occasionally preceded the next rendered frame; fresh observations were used before declaring behavior broken.
+156
View File
@@ -0,0 +1,156 @@
# V2 native Linux verification — 2026-09-05
Status: **passed**, including the focused desktop refresh verified at 04:54
Moscow time on 2026-09-05. This report covers native Linux compilation, tests, linting, and
the headless example command. It does not claim graphical runtime acceptance;
the root agent owns that separate WSLg check.
## Environment and reproducible commands
- Distribution: WSL `Ubuntu-24.04`, Ubuntu 24.04.2 LTS, x86_64.
- Kernel: `6.6.87.2-microsoft-standard-WSL2`.
- Native compiler: `rustc 1.98.1 (48a229cea 2026-09-01)`.
- Native Cargo: `cargo 1.98.1 (797e8a9bc 2026-08-05)`.
- Workspace: `/mnt/c/Users/sorok/OneDrive/Documents/ChatGPT/Capella 2`.
- Native Rust binaries: `/home/sorokinoleg/.cache/arcadia/rust/bin`.
- Native target cache: `/mnt/d/CodexBuilds/Capella2-01a06e2e/linux-target`.
- Vendor directory: `/mnt/d/CodexBuilds/Capella2-01a06e2e/vendor`, selected by
the existing ignored `target/linux-cargo.toml` source-replacement config.
- `Cargo.lock` SHA-256:
`eb3b55fe34920d5d9e069e2f4c80ee130eb85ec2ca12fddd7fc880b8ccfe062d`.
Run inside this WSL distribution:
```sh
cd '/mnt/c/Users/sorok/OneDrive/Documents/ChatGPT/Capella 2'
export PATH=/home/sorokinoleg/.cache/arcadia/rust/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
export CARGO_TARGET_DIR=/mnt/d/CodexBuilds/Capella2-01a06e2e/linux-target
cargo fmt --all -- --check
cargo test --workspace --locked --offline --config target/linux-cargo.toml
cargo clippy --workspace --all-targets --locked --offline --config target/linux-cargo.toml -- -D warnings
cargo build --release -p oa-desktop -p oa-server --locked --offline --config target/linux-cargo.toml
```
The Windows orchestration uses `wsl.exe -d Ubuntu-24.04 --cd <workspace>
--exec /usr/bin/env PATH=<path-above> CARGO_TARGET_DIR=<target-above> cargo ...`.
No cross-compilation target is selected: Cargo and Rust execute natively in
Ubuntu and generate Linux executables.
## Results
`cargo test --workspace --locked --offline --config target/linux-cargo.toml`
passed on the full-workspace baseline: **91 tests**, zero failures (incremental
test build completed in 12.05s). This includes the root agent's 64-unit nested
header allowance, canvas text width correction, counterpart diagram focus,
StateTransition behavior context, numbered transition details, diagram/layer
focus after placement relocation, and actual SelectNode-before-drag regression.
| Suite | Passed |
| --- | ---: |
| Core language | 12 |
| Core process diagnostics | 1 |
| Core review regressions | 15 |
| Core workflows | 28 |
| Desktop reducer/property forms | 23 |
| Server actual HTTP/storage | 12 |
The core tests include reviewed divergent transitions in both directions,
Capability/Mission mapping, same-parent sequence/branch preservation,
placement relocation/artifact survival/invalid rollback, unowned-machine
warnings, and checked external-save conflicts. Desktop tests include shared
perspective and placement ownership forms, plus counterpart creation focus
and existing-view reuse. The server suite exercises actual
HTTP, atomic writes, restart, auth, bounded bodies, and concurrent ownership.
Native `cargo fmt --all -- --check` passed. Strict
`cargo clippy --workspace --all-targets --locked --offline --config
target/linux-cargo.toml -- -D warnings` passed on that full-workspace snapshot
(12.44s).
The optimized desktop/server build passed (initial build 3m53s, workspace
refresh 31.69s). `file` identifies both
outputs as native x86-64 ELF PIE executables. `ldd` resolves every linked
library; runtime-loaded graphics drivers are covered by the separate GUI check.
A preliminary test invocation caught the same renamed legacy-fixture include
path that Windows caught. The root agent corrected the two language-test paths
to `examples/legacy-v1-coastal-rescue.*`; the complete rerun above passes.
No Linux-specific source changes were needed or made by this worker.
## Focused desktop refresh after native GUI review
Native GUI review prompted four desktop-only corrections: stable merge-input
widget placement while preview rows change, readable artifact owner labels for
placements, and clearing prior merge decisions when the effective counterpart
or target kind changes, and automatic node placement only while authoring on
the Architecture page. Behavior and Data authoring no longer inserts nodes
into an unrelated active architecture diagram. The latest source passed:
- `cargo test -p oa-desktop --locked --offline --config target/linux-cargo.toml`:
**25 tests**, zero failures (19.29s build). The focused regressions include
`transition_resolutions_belong_to_the_effective_target_and_kind` and
`behavior_and_data_authoring_do_not_place_nodes_in_unrelated_architecture_views`.
- `cargo clippy -p oa-desktop --all-targets --locked --offline --config
target/linux-cargo.toml -- -D warnings`: passed (10.71s).
- `cargo fmt --all -- --check`: passed.
- The established locked/offline release command for desktop and server:
passed (22.40s), recompiling only `oa-desktop`.
Core and server source were unchanged; their earlier 56 and 12 passing native
tests remain the evidence for those crates. Together with the current desktop
suite, this covers 93 tests across these native runs; a new full-workspace
93-test invocation was not performed for the desktop-only corrections.
The refreshed desktop's `ldd` output still has no unresolved libraries.
## Headless examples and release artifacts
The native optimized desktop command below exited successfully and produced
a 29,222-byte canonical `arcadia 2` example without launching a window:
```sh
/mnt/d/CodexBuilds/Capella2-01a06e2e/linux-target/release/arcadia-studio --write-example /mnt/d/CodexBuilds/Capella2-v2-01a06e2e/linux-verification/linux-demo.arcadia
```
Before the focused UI-only refresh, the headless example was checked by a temporary native Rust assertion
program linked to the current `oa-core`. It confirmed:
- Packaged `examples/coastal-rescue.arcadia` and `examples/coastal-rescue.json`
deserialize to equal projects, with zero validation checks.
- Native-generated source exactly equals canonical formatting of its parsed
model, reparses to an equal project, and equals its saved/reloaded JSON.
- The native-generated example has zero validation checks: 39 elements,
23 relations, three diagrams, ten traces, and two artifact links.
The assertion source and executable are `verify_examples.rs` and
`verify_examples` in the evidence directory below. Their assertions compare
each example's representations; independently generated demo instances have
fresh identities and are not claimed byte-identical to one another.
Final native binaries are in
`D:/CodexBuilds/Capella2-01a06e2e/linux-target/release/` (the same directory is
`/mnt/d/CodexBuilds/Capella2-01a06e2e/linux-target/release/` inside Ubuntu):
| Binary | Bytes | SHA-256 |
| --- | ---: | --- |
| `arcadia-studio` | 23,344,152 | `df88c9dd2f4759c95514c32c0c50ad225642fff085b67162e6bebafafad01b04` |
| `arcadia-server` | 7,180,464 | `0df8a6eaaa9bb548669cf38d9b7e452d11171affe075652b9d561ddef2281814` |
Raw logs are stored outside the source tree at
`D:/CodexBuilds/Capella2-v2-01a06e2e/linux-verification/`.
The full-workspace baseline logs are `release-ready-fmt.log`,
`release-ready-tests.log`, `release-ready-clippy.log`,
`release-ready-build.log`, `release-ready-examples.log`, and the two
`release-ready-ldd-*.log` files. The latest focused desktop logs are
`context-fix-desktop-tests.log`, `context-fix-desktop-clippy.log`,
`context-fix-fmt.log`, `context-fix-release-build.log`, and
`context-fix-ldd-studio.log`. Other earlier logs cover superseded snapshots.
## Scope and refresh
Only this report was edited by the Linux verification worker. The root agent
declared the tested source stable before the 91-test workspace pass and before
the focused 25-test desktop/Clippy/release refresh.
No GUI was launched and no server daemon was started by this worker. Later
source changes require another incremental refresh before packaging.
The root agent received the native release-ready path immediately after the
build completed, before hashes/report work, for its separate WSLg GUI run.
+37
View File
@@ -0,0 +1,37 @@
# Lead native acceptance — 2026-09-05
The lead personally operated the Windows Iced application and three packaged native Linux releases through the Computer Use skill (`@oai/sky`). This record supplements the independent Windows reports, automated Linux report and API transfer report. It records observed behavior, including unsuccessful attempts, rather than inferring GUI success from tests.
## Windows
- Operated repaired Capella 7.0.1 in an isolated imported IFE example: OA/SA nesting, semantic browser/properties and Functional Transition comparison. Cancelled that preview; the original model was not transitioned. Findings informed `docs/research-v2-ui.md`.
- In Studio, inspected syntax colors, inserted invalid `?`, observed located live lint, rejected Apply with draft/model retained, then recovered with Revert. Navigated OA processes, SA chains/scenarios and state views; selected the second repeated message occurrence and confirmed its inspector/highlight.
- Opened the actual REST-exported `api-edited-demo.arcadia` through the native picker. Project/function name and alias, CAD URI and revision reflected the API edits. Edited CAD revision to `CAD-REV-C-native-review`, used Ctrl+S and verified persisted source. After an external comment append, Ctrl+S refused overwrite and retained the external bytes.
- New produced an empty model. Created a view and `Assess sea conditions` OA activity, previewed/created its SA Function, and observed target-view focus and creation-kind normalization. Preview blocked background Text navigation and Ctrl+Z. Explicit reverse creation and single-step Undo preserved the other layer.
- Found and fixed 150% nested-caption overlap and counterpart focus. The fresh reviewer personally reverified rebuilt nested typography, state-transition selection, minimum/default/wide layouts, fragment/branch creation and saved action rendering; see `review-v2-final-ui.md`.
- Launched the staged Windows release directly and inspected the default 1440×900 zero-check demo, then closed normally. The fresh reviewer subsequently rebuilt the final release, operated that exact packaged executable, created/saved/reopened an Action and confirmed Architecture retained its original three cards. Final binary hashes are in that report.
## Native Ubuntu 24.04 / WSLg
Both sessions used the staged Linux executable with `WGPU_BACKEND=vulkan` and `VK_DRIVER_FILES=/usr/share/vulkan/icd.d/lvp_icd.x86_64.json`. The client rendered at 1440×900 with Mesa software Vulkan. The remote window's `[WARN:COPY MODE]` title is a compositor label; application stderr was empty and both processes exited 0 on normal close (sessions 58001 and 57111).
The native Open path dialog loaded the isolated `controls-fixture.arcadia` used by Windows review. The lead then:
1. Changed `Independent energy` from OA to SA through its graphical engineering-perspective control. The saved record preserved Energy kind and UUID `20000000-0000-4000-8000-000000000004`.
2. Opened Manual trace. Apply remained disabled until explicitly choosing `Other operational need`; committing created a trace with canonical OA/SA endpoints and did not create another semantic element.
3. Changed a Traceability diagram's layer SA→OA→SA and confirmed that active diagram and editing perspective followed the committed owner.
4. Changed a function placement UUID to `60000000-0000-4000-8000-000000000099` and dragged the placement. The first gesture selected the parent without movement; the subsequent actual function drag succeeded. Saved source confirmed the new UUID and position `(90,250)`, size `(224,94)`. The automated regression separately sends the real SelectNode→MoveNode sequence with the pending UUID draft.
5. Relocated OA `work_card` into the SA Traceability diagram through Placement properties. The UI selected the destination diagram and SA context; saved source preserved placement identity and its artifact owner.
6. Saved through Ctrl+S, closed, refreshed the executable and reopened the saved fixture. All edits persisted. The artifact card correctly displayed `Placement of OA "Rescue" updated · SA existing architecture`.
7. Exercised the actual counterpart conflict dialog showing source/target names and current/proposed field values. Initial continuous typing exposed lost input focus during replanning; fixed stable widget grouping/order and rebuilt before repeating.
8. In the rebuilt dialog, typed successive name fragments and punctuation without refocusing; all remained in the same input. Changed counterpart to `Other System Service`: the previous merged value cleared and Apply became disabled pending review. Returning to the original counterpart did not revive the old decision.
9. Entered `Reviewed rescue function`, chose **Keep target** for description, and applied with no unresolved decisions. Saved source confirmed that name and the retained description `System design deliberately changed.`. Traceability displayed Reviewed. Reverse preview reused the counterpart with no field proposals or conflicts, then was cancelled.
10. Reopened the graphical `branching-reviewed.arcadia` fixture. Behavior rendered two repeated messages plus an Alternative fragment, a branch with guard `sea_state > 4 && operator == "Ready"`, and its nested validated-report message. The fixture showed 42 elements, 23 relationships and zero checks.
The last fixture also exposed unwanted Architecture placements from Behavior creation. The fix confines automatic placement to the Architecture page; Behavior/Data still create semantic records. A meaningful regression checks Fragment→Branch→Exchange ordering, Data creation and exact preservation of every diagram, plus ordinary Architecture placement. The fresh independent reviewer verified the final Windows packaged Action/create/save/reopen workflow and unchanged architecture.
After Linux compilation/tests/release were refreshed, the lead launched that exact final staged executable (SHA-256 `df88c9dd2f4759c95514c32c0c50ad225642fff085b67162e6bebafafad01b04`). Ctrl+O opened the Windows-authored `packaged-behavior-placement-reviewed.arcadia`. SA Architecture showed the three original nested function cards at 150%, with no occurrence placement. Behavior → Repeated distress reports rendered the saved `Review response readiness` Action on the coordination lifeline after both messages. The model had 40 objects,23 links,zero checks and all changes saved. Normal Alt+F4 closed the process (session74334,exit0,empty stderr); a fresh window inventory confirmed closure. Creation itself was exercised in Windows, with this final Linux pass verifying cross-platform reopening/rendering.
## Boundaries
No test server or Studio acceptance window is intentionally left running. Raw fixtures/logs are outside source under `D:/CodexBuilds/Capella2-v2-01a06e2e/`. Reports retain the evidence needed to understand them without that directory. Native Linux runs cover this Ubuntu/WSLg/Mesa environment, not all graphics drivers. Remote CI, Docker execution/remote installation, actual Rust 1.90, assistive-technology certification and production-scale performance were not exercised.
+26
View File
@@ -0,0 +1,26 @@
# V2 release package verification — 2026-09-05
Release: Arcadia Studio 0.2.0, native x86_64 Windows and Linux. The Linux build targets the tested Ubuntu 24.04.2 runtime. Both final desktop executables were launched from their staging bundles and operated through Computer Use; their normal closes completed without application stderr. The Linux final pass reopened the Windows-authored Action fixture. See `verification-v2-native.md` and `review-v2-final-ui.md`.
## Outputs
- `dist/ArcadiaStudio-Windows.zip`
- `dist/ArcadiaStudio-Linux.tar.gz`
- `dist/SHA256SUMS.txt` — SHA-256 of the final archives (kept outside them to avoid a self-referential hash).
Each bundle contains the two platform executables, START-HERE, README, LICENSE, all current docs (including both rendered/source reST contracts and OpenAPI), examples, deployment recipes, and V2 harness state/review/verification records. It is a binary bundle; repository source is required for the documented Cargo/Docker build commands. Historical V1 release executables are absent. Explicitly named legacy examples are retained for migration.
## Verification
The archive builder checks every staged regular file against its repository source or final build output before assembling. It reads and SHA-256 compares every archived regular file against staging, checks duplicate names and required contents, and checks ZIP CRC integrity. Linux tar headers use executable mode 0755 for binaries/directories and 0644 for other files, with root ownership metadata. No extraction or elevated installation is required for these integrity checks.
An initial staging check correctly rejected outdated copies of `server.md`/`validation.md` after the independent reviewer improved their quickstart/evidence attribution. Those files were recopied; assembly and full inventory verification passed. The final pass includes this package record and finalized PLAN/STATE and repeats the complete comparison. Raw structured results are at `D:/CodexBuilds/Capella2-v2-01a06e2e/release-packages.json`; archive hashes are available directly in dist.
| Platform binary | SHA-256 |
|---|---|
| Windows desktop | `e2aec2ac935e270c6185729cbb76f8323b381654c04dbde7aae90c4628a98a20` |
| Windows server | `d33edae56308035781856ae54358def59818cc93242380bc29c874f7dc7c53e4` |
| Linux desktop | `df88c9dd2f4759c95514c32c0c50ad225642fff085b67162e6bebafafad01b04` |
| Linux server | `0df8a6eaaa9bb548669cf38d9b7e452d11171affe075652b9d561ddef2281814` |
The binaries in both archives equal these final release outputs. Earlier service process checks still apply because both server binaries are unchanged. This verification does not claim signed installers, a fresh-machine runtime installation, broad Linux distribution/GPU compatibility, Docker execution or remote deployment.