Integrate release recovery, semantic review, coverage and Windows packaging
This commit is contained in:
Codex
+50
-1
@@ -286,7 +286,7 @@ references. Their kind is the declaration keyword:
|
||||
- Work, participant, capability, or process/chain → state/mode
|
||||
- None
|
||||
* - ``exchange_allocation``
|
||||
- Boundary-exchange relation → SA functional-exchange relation
|
||||
- Boundary-exchange relation → same-layer interaction (OA) or functional exchange (SA)
|
||||
- None
|
||||
* - ``interface_provision``, ``interface_requirement``
|
||||
- Participant/port → provided/required interface
|
||||
@@ -1662,6 +1662,55 @@ the line. Structural errors and engineering warnings point to a relevant
|
||||
declaration or field when available. Clients MUST use severity/code rather than
|
||||
parse the human message; diagnostic wording is not a stable machine API.
|
||||
|
||||
.. rubric:: Explicit behavior coverage diagnostics
|
||||
|
||||
The following shared engineering checks are advisory ``Warning`` diagnostics.
|
||||
They MUST NOT reject graphical Apply, source compilation, Save, or an API
|
||||
transaction solely because the model is incomplete. They run only after the
|
||||
structural pass reports no ``Error``, avoiding cascades from invalid ownership,
|
||||
references, layers, or recursion. Their policy concerns explicit evidence in
|
||||
the authored model, not proof that no engineering behavior exists.
|
||||
|
||||
* ``non_leaf_work_exchange`` locates each ``source`` or ``target`` of an
|
||||
Interaction or FunctionalExchange that has direct same-kind child work.
|
||||
Repair the exchange to name its responsible leaf Activity/Function, keeping
|
||||
SA function-port ownership consistent.
|
||||
* ``work_without_behavior_context`` locates a leaf Activity/Function lacking
|
||||
an included Action or an included Interaction/FunctionalExchange occurrence
|
||||
that explicitly names it as an endpoint.
|
||||
* ``exchange_without_behavior_context`` locates an Interaction or
|
||||
FunctionalExchange lacking an included Exchange occurrence. It is suppressed
|
||||
while a more specific non-leaf endpoint warning applies to that exchange.
|
||||
* ``mission_without_capability`` locates an OperationalMission/Mission lacking
|
||||
a valid same-layer outgoing MissionCapability. Participant responsibility
|
||||
through MissionInvolvement does not satisfy this check.
|
||||
* ``capability_without_behavior_context`` locates a supported leaf
|
||||
Capability/SystemCapability lacking either an incoming ChainInvolvement or
|
||||
a same-layer Scenario explicitly naming it as ``context``. It MUST NOT
|
||||
duplicate ``unsupported_capability`` on the same record.
|
||||
|
||||
Record-level checks have no invented field path. Coverage traverses all Process,
|
||||
FunctionalChain and Scenario roots, following only their explicitly listed,
|
||||
correctly owned occurrences and Fragment branches. Reusable sequence/scenario
|
||||
contents are traversed with identity-based cycle guards. Known work/exchange
|
||||
references count despite unfinished lifelines; unordered occurrences do not.
|
||||
Repeated exchanges and correlated replies contribute the same identity once.
|
||||
Parent work does not cover its children. Bare lifelines, state observations,
|
||||
StateAction/Availability links, timer-only occurrences, and participant/boundary
|
||||
messages do not imply work/exchange coverage. Allocation does not imply that
|
||||
every exchange carried by a boundary message occurs. Diagram layout is irrelevant.
|
||||
|
||||
As an explicit Studio completeness policy, same-kind capability grouping parents
|
||||
are excluded from both capability support warnings; their leaf capabilities are
|
||||
checked independently. A valid direct Scenario context also satisfies existing
|
||||
``unsupported_capability`` support. An empty linked process/chain or scenario
|
||||
satisfies explicit context presence while retaining its own ``empty_sequence``
|
||||
warning. Include/extend/generalization, parent containment, and shared performers
|
||||
MUST NOT manufacture a context. These advisory checks follow the distinction
|
||||
between dataflow and its usage contexts described in the official
|
||||
`Arcadia Questions and Answers <https://mbse-capella.org/arcadia-qna.html>`_;
|
||||
they are not a declaration of full Capella conformance.
|
||||
|
||||
``parse_limited`` and ``decode_limited`` accept caller admission budgets for
|
||||
input bytes, graph objects, total persistent records and ordered step references.
|
||||
Counts MUST be checked before expensive structural validation; migration budgets
|
||||
|
||||
+12
-6
@@ -1,6 +1,6 @@
|
||||
# Current scope and tradeoffs
|
||||
|
||||
Arcadia Studio implements a systems-engineering workbench spanning Operational Analysis and System Analysis. The normative [language and editing contract](language.rst) defines the supported Studio profile. It does not claim full Arcadia, Eclipse Capella or SysML conformance. The [first-release plan](../harness/PLAN.md) remains incomplete; [current state](../harness/STATE.md) records current implementation and verification. The [V2 acceptance](acceptance.md) and [validation](validation.md) records describe the earlier baseline, not acceptance of every subsequent change.
|
||||
Arcadia Studio implements a systems-engineering workbench spanning Operational Analysis and System Analysis. The normative [language and editing contract](language.rst) defines the supported Studio profile. It does not claim full Arcadia, Eclipse Capella or SysML conformance. The [first-release plan](../harness/PLAN.md) remains incomplete; [current state](../harness/STATE.md) and the [2026-09-06 coverage audit](../harness/release-current-coverage-20260906.md) distinguish implementation, verification and remaining requirements. The [V2 acceptance](acceptance.md) and [validation](validation.md) records describe the earlier baseline, not acceptance of every subsequent change.
|
||||
|
||||
## Supported modeling profile
|
||||
|
||||
@@ -11,9 +11,9 @@ Arcadia Studio implements a systems-engineering workbench spanning Operational A
|
||||
| Data and interfaces | Information/material/energy nature and Flow/Event/Operation/SharedData mechanisms, bounded primitive/enum/record types, typed defaults, field multiplicity/units/direction/storage, specialization, identified interface allocations and reference associations, separate function input/output and Standard/Flow component ports, interface provision/requirement, port and exchange allocations |
|
||||
| Behavior | Process/chain work and exchange contributions, control topology and sequence reuse; scenario lifelines, correlated calls/replies, timers, action/state occurrences, ALT/PAR/LOOP/OPTIONAL fragments, scenario reuse and pre/postconditions |
|
||||
| States and conditions | Participant-owned state machines, nested regions, states/modes and typed pseudostates, signal/time/change events, trigger/guard/effect transitions, linked entry/do/exit work, availability and constraints |
|
||||
| Perspectives and evidence | Bidirectional counterpart creation/linking, reviewed name/description updates, many-to-many typed/manual traces, arbitrary artifact URI/revision/fragment references |
|
||||
| Perspectives and evidence | Bidirectional counterpart creation/linking, reviewed descriptive and typed semantic changes, many-to-many typed/manual traces, arbitrary artifact URI/revision/fragment references |
|
||||
| Views and editing | Independent diagrams, decomposition/allocation nesting, collapse, pan/zoom/Fit/Arrange, editable connection routes and labels, four-side port positioning, direct interaction/functional/boundary exchange tools, contextual menus, SVG export, model explorer and typed properties |
|
||||
| Text and storage | `arcadia 4` source projects with relative includes and nested declarations, stable aliases/UUIDs, a source-file tree, per-file drafts and diagnostics, comment-preserving graphical updates, exact model/source Undo/Redo, legacy migration, atomic saves and interrupted source-save recovery |
|
||||
| Text and storage | `arcadia 5` source projects with relative includes and nested declarations, stable aliases/UUIDs, a source-file tree, per-file drafts and diagnostics, comment-preserving graphical updates, exact model/source Undo/Redo, legacy migration, atomic saves, interrupted source-save recovery, Home/recents and private unsaved-work checkpoints |
|
||||
| Automation and hosted editing | Rust REST service for project/source-bundle/query/validation/transaction/transition/artifact workflows; optional desktop catalog/open/publish, explicit conditional Save, server review and local Save as; ETag preconditions, bounded requests and atomic current-revision storage |
|
||||
|
||||
Graphical and textual parity applies to the persistent fields of this profile. Diagram placements are model data; camera, selection, source cursor and undo history are session state. Canvas gestures need not match textual operations one for one: typed inspectors and explicit commands expose precise semantics. Full source replacement must repair dependencies in its candidate, while graphical delete/reidentify commands maintain references automatically.
|
||||
@@ -23,7 +23,7 @@ Graphical and textual parity applies to the persistent fields of this profile. D
|
||||
- OA captures operational needs; SA defines the selected system contribution. SA contains no internal logical/physical components, and Studio does not decompose SA Actors. The System may be absent while authoring, with a completeness warning.
|
||||
- Work decomposition and performer allocation are independent. Only leaves have direct allocations. A parent drawn within one performer can be a computed leaf summary, not an additional allocation. Role sharing does not create several direct performers for one function.
|
||||
- Nesting expresses semantic containment or the selected allocation projection. Placement movement does not change ownership or allocation. Hide and delete have different effects.
|
||||
- Counterpart creation copies mapped typed content and required references; existing-target updates compare only names/descriptions against a reviewed baseline. They do not synchronize arbitrary structure, reverse-engineer operational needs or automatically overwrite the other perspective. Scope follows ownership/reference dependencies, not every incident relationship.
|
||||
- Counterpart creation copies mapped typed content and required references. Existing-counterpart semantic review compares typed facts and prior observations, with explicit keep, take or final-value decisions for supported scalar, structural, constructor and individual collection-row changes. Reference mapping and candidate validation apply before an undoable transaction. Ordered collections, attachment/artifact and multi-source GUI reconciliation remain unfinished. Review does not automatically synchronize arbitrary structure or overwrite the other perspective. Creation scope follows ownership/reference dependencies, not every incident relationship.
|
||||
- Processes/chains use contributions and explicit sequence links; imported ordered exchange paths retain their implied order until topology conversion. Rich fragments belong to scenarios. Guards, expressions and state behavior text are descriptive; there is no execution engine. Mixed states and modes are permitted by this Studio profile.
|
||||
- Preserved OA boundary exchanges use Legacy ports. Capability grouping is containment; include, extend and generalization use separate typed relationships in OA and SA. Data/item references remain within their layer and can have explicit transitioned counterparts.
|
||||
- Applying a source project preserves authored comments and formatting while assigning missing identities. Graphical updates preserve unaffected source bytes; canonical export is a separate operation. JSON does not preserve comments or source-file organization. See the [source contract](language.rst) for comment ownership and update rules.
|
||||
@@ -36,7 +36,7 @@ These are concrete design responses, not claims that every Capella user experien
|
||||
|
||||
| Concern | Studio response | Remaining tradeoff |
|
||||
|---|---|---|
|
||||
| Dense workbench and difficult onboarding | Task workspaces, OA/SA context, contextual menus, direct architecture connections, searchable guidance and relation/transition builders | Direct behavior gestures and Home/recent-project workflows remain release work |
|
||||
| Dense workbench and difficult onboarding | Task workspaces, OA/SA context, contextual menus, direct architecture and behavior gestures, searchable guidance, Home/recents and relation/transition builders | Current Home/recovery and expanded review controls still need native acceptance |
|
||||
| Noisy architecture pictures | Nested ownership/allocation views, independent placements, collapse, automatic routing, editable bends/labels and port positions | Dense diagrams may need manual adjustment; routing has a bounded solve budget |
|
||||
| Hard-to-review model files | Modular typed source, stable aliases/UUIDs, preserved comments/formatting and source-aware history | Semantic merges, completion and an LSP are absent |
|
||||
| Hidden mutation effects | Validated atomic commands, dependency cleanup, identity maintenance, previewed counterpart changes and undo | No distributed editing or automatic structural reconciliation |
|
||||
@@ -45,7 +45,13 @@ These are concrete design responses, not claims that every Capella user experien
|
||||
|
||||
## Required first-release work
|
||||
|
||||
Direct scenario/process canvas authoring, semantic-content drift and reviewed counterpart reconciliation, native acceptance of expanded data contracts, persistent coverage/filter views, Home/recent-project and unsaved-work recovery, guidance and final acceptance remain in the [release plan](../harness/PLAN.md). These are unfinished requirements, not exclusions from the release. Hosted desktop editing is implemented; its remaining native acceptance is tracked in the release plan and current state. Direct state editing has scoped Windows/Linux acceptance recorded in [state evidence](../harness/release-state-editing.md). Interrupted source-save recovery restores a save transaction; it does not checkpoint unsaved models or drafts.
|
||||
Direct process/scenario/state authoring, typed semantic drift/reconciliation, Home/recents and unsaved-work checkpoints are implemented. Their evidence and outstanding acceptance cases are separated in the [current coverage audit](../harness/release-current-coverage-20260906.md). Direct state editing has earlier scoped Windows/Linux acceptance recorded in [state evidence](../harness/release-state-editing.md); that does not accept every current change.
|
||||
|
||||
Required unfinished implementation includes ordinary OA CommunicationMean authoring with an accurate participant-level contract; persisted selective relation/category/coverage views; completeness checks for exchanges on non-leaf work, behavior-context coverage and missions without capabilities; and ordered-collection, attachment, artifact and multi-source semantic-review GUI controls. Existing Legacy OA boundary exchanges and their Interaction allocations remain supported, but do not close the CommunicationMean requirement.
|
||||
|
||||
The desktop attempts a private checkpoint every 10 seconds while work is unsaved. It retains accepted source, raw source buffers, pending property/behavior forms and supported workflow drafts, including semantic-review input. Home recovery opens a detached unsaved copy requiring Save as; it restores no undo stack and writes neither the original model nor a hosted destination. Interrupted source-save recovery is a separate mechanism for an incomplete save transaction.
|
||||
|
||||
Remaining release gates include current-tree automated checks, expanded data/semantic-review and Home/recovery native acceptance, outstanding behavior and hosted workflow cases, default/minimum-window Windows/Linux acceptance, fresh build/MSRV and specification/OpenAPI checks, real REST/restart/parity verification, packages/checksums and independent final review. Guidance must follow the accepted controls. These are unfinished release requirements, not exclusions or release-acceptance claims.
|
||||
|
||||
## Remaining boundaries
|
||||
|
||||
|
||||
@@ -0,0 +1,69 @@
|
||||
# Portable Windows packaging
|
||||
|
||||
The standard build target is x86_64 MSVC. The optional gnullvm build uses LLVM-MinGW UCRT and currently needs `libunwind.dll` alongside both executables. Packaging is a separate operation on already-built inputs; it neither builds nor launches applications and does not confer release acceptance.
|
||||
|
||||
Run from a Git checkout with Windows PowerShell 5.1 or PowerShell 7. Build and test first using the [README](../README.md). Select the actual output directory explicitly; a native-host Cargo build normally uses `target/release`, while an explicit `--target` uses `target/<target>/release`.
|
||||
|
||||
Packaging also needs the build's matching `cargo` and `rustc` on the packaging process PATH, the locked dependency sources/archive cache, and installed Rust target libraries and copyright reports. The script invokes only read-only `cargo metadata --locked --offline --filter-platform <target>` and Rust version/sysroot queries. It does not download dependencies or build. These tools are packaging prerequisites; the extracted application does not require them.
|
||||
|
||||
```powershell
|
||||
# Standard MSVC outputs, already built:
|
||||
./scripts/package-windows.ps1 -Target x86_64-pc-windows-msvc `
|
||||
-Version 0.2.0-rc1 -BinaryDirectory ./target/release
|
||||
|
||||
# Optional LLVM-MinGW outputs, already built in a separate target directory:
|
||||
./scripts/package-windows.ps1 -Target x86_64-pc-windows-gnullvm `
|
||||
-Version 0.2.0-rc1 -BinaryDirectory ./target-gnullvm/release `
|
||||
-LlvmMinGWRoot C:/Tools/llvm-mingw-20260826-ucrt-x86_64
|
||||
```
|
||||
|
||||
The caller must supply the matching build target, version, and final binaries. PE headers establish x86_64 architecture, but do not prove a source revision or Cargo profile. `package.json` records input hashes and inspected imports; retain build/test evidence tied to those hashes separately. The version labels the package and does not change the embedded application version.
|
||||
|
||||
The script creates a fresh `dist/ArcadiaStudio-<version>-<target>/`, matching ZIP, and ZIP `.sha256` file. `-OutputRoot` selects another location. Existing output names are refused; no directories are deleted or overwritten. A `.packaging.lock` claim and partial outputs remain after failure for inspection; retry under a fresh version/output location. ZIP file order and timestamps are fixed so unchanged inputs can be compared across runs; this is not a reproducible compiler-build guarantee.
|
||||
|
||||
Each package includes desktop and server executables, README, MIT license, built-in Help in the application, tracked docs (including language/API specifications and OpenAPI), tracked examples and deployment recipes, current coverage/runtime notes, START-HERE, provenance, and SHA-256 inventory. It includes current working-tree contents of tracked files, so review uncommitted documentation edits before packaging. Untracked sample/user files are excluded. Repository sources are needed separately for the documented Cargo and Docker build recipes.
|
||||
|
||||
For gnullvm, the exact selected toolchain's x86_64 `libunwind.dll` and full distribution `LICENSE.TXT` are included; both are hashed. Standard MSVC packaging has no LLVM-MinGW coupling. The script reads ordinary PE imports recursively for packaged runtime DLLs, accepts a bounded list of Windows system components/API sets, and fails on unknown imports. For example, a build importing a VC redistributable DLL must have its redistribution and dependency handling resolved before packaging; it is not silently treated as part of Windows. Do not copy arbitrary DLLs from System32. Dynamically loaded graphics libraries and delay-load imports require the runtime check below.
|
||||
|
||||
Every staged copy is SHA-256 compared with its source; all ZIP entries are read back and SHA-256 compared with staging, and names/counts are checked. `SHA256SUMS.txt` covers every package file except itself; the separate archive hash covers the ZIP including that inventory. Integrity success establishes transport contents, not application behavior.
|
||||
|
||||
## Dependency and asset notices
|
||||
|
||||
`THIRD-PARTY-NOTICES.txt` indexes the collected texts. `dependency-notices.json` records exact package versions and license expressions, the Cargo.lock hash, registry archive checksums verified against the lock, hashes of actual local source files, resolved features, embedded font identities, and staged notice paths/hashes. The selected graph starts at `oa-desktop` and `oa-server` and follows transitive normal/build dependency edges; dev-only edges are excluded. Cargo workspace feature unification can retain a conservative superset. This inventory is tied to packaging inputs and is not proof that caller-supplied binaries were built from them. Keep matching compiler/build evidence separately.
|
||||
|
||||
Available LICENSE, COPYING, NOTICE, COPYRIGHT, OFL and equivalent named files are retained from each selected crate, including nested notices. Workspace crates receive this repository's license. Published crates that omit required texts need supplements in `scripts/windows-notices/manifest.json` (or `-NoticeManifest <path>`), bound to their exact version and locked registry checksum. Supplemental files must be local, stay inside that manifest's directory, and match the recorded SHA-256 and upstream HTTPS source URL. This manifest is deliberately reviewed input; the packaging script does not fetch notices or substitute a generic SPDX license text. Updates to dependencies can require new reviewed supplements.
|
||||
|
||||
Literal `include_bytes!` font references in production/build Rust files receive separate exact asset hash and notice mappings, conservatively including feature-gated references; dependency test/example font files are not assumed to ship. This scan is not a complete binary asset detector: generated, indirect or non-font embeds need deliberate review. Rust's installed `COPYRIGHT-library.html` and full `COPYRIGHT.html` are included, with available distribution runtime copying notices, compiler identity, and target-library hashes. LLVM-MinGW includes its distribution LICENSE plus a component notice mapping bound to the exact `libunwind.dll` hash. Missing sources, unsupported source types, missing required notices, unknown embedded font mappings, or changed supplemental hashes stop packaging before creating an output claim.
|
||||
|
||||
Notice collection is an auditable aid and does not constitute a universal license audit. An unresolved item requires source/provenance review; do not remove the check merely to produce a ZIP.
|
||||
|
||||
## Clean-environment verification
|
||||
|
||||
Use an ordinary Windows account with a supported graphical desktop/driver. Extract the ZIP to a fresh user-writable directory, keep the DLL beside both executables, verify hashes, and test from an unrelated working directory. Record exact binary/runtime/ZIP hashes, Windows version and graphics adapter, stdout/stderr, exit codes, and native screenshots. A second Windows machine without development tools remains the stronger portability check.
|
||||
|
||||
For a controlled smoke, set **only the current PowerShell process's** PATH to Windows system paths, launch hidden with absolute executable paths, then restore PATH in `finally`. This does not change machine/user environment settings. Use a fresh temporary server data directory and an unused loopback port. Example setup (replace `$bundle` with the actual extracted directory):
|
||||
|
||||
```powershell
|
||||
$bundle = 'C:/Users/YourName/Downloads/ArcadiaStudio-0.2.0-rc1-x86_64-pc-windows-gnullvm'
|
||||
$qa = Join-Path $env:TEMP ('arcadia-package-smoke-' + [guid]::NewGuid().ToString('N'))
|
||||
[void][IO.Directory]::CreateDirectory($qa)
|
||||
$savedPath = $env:PATH
|
||||
try {
|
||||
$env:PATH = "$env:SystemRoot/System32;$env:SystemRoot"
|
||||
$server = Start-Process -FilePath (Join-Path $bundle 'arcadia-server.exe') `
|
||||
-ArgumentList @('--bind', '127.0.0.1:18787', '--data-dir', ('"' + (Join-Path $qa 'store') + '"')) `
|
||||
-WorkingDirectory $qa -WindowStyle Hidden -PassThru `
|
||||
-RedirectStandardOutput (Join-Path $qa 'server.stdout.log') `
|
||||
-RedirectStandardError (Join-Path $qa 'server.stderr.log')
|
||||
$desktop = Start-Process -FilePath (Join-Path $bundle 'arcadia-studio.exe') `
|
||||
-WorkingDirectory $qa -WindowStyle Hidden -PassThru `
|
||||
-RedirectStandardOutput (Join-Path $qa 'desktop.stdout.log') `
|
||||
-RedirectStandardError (Join-Path $qa 'desktop.stderr.log')
|
||||
} finally {
|
||||
$env:PATH = $savedPath
|
||||
}
|
||||
```
|
||||
|
||||
This snippet only starts processes; it does not verify readiness. Check the server's health route documented in [server setup](server.md), import/read/update a model, restart with the same temporary store, and verify persistence. Close only the processes started for this smoke. Exercise the desktop's Home/example/open/save/reopen and Help, inspect real diagrams, and perform the [Save-as Undo/Redo recheck](../harness/release-save-as-runtime-packaging.md). Close normally and check stderr/exit state. A process that survives a few seconds alone is not adequate GUI evidence.
|
||||
|
||||
Acceptance is pending until these checks are actually performed against the packaged final binaries. Historical V2 bundles, this machine's Cargo checks, and a successful development launch with compiler PATH are separate evidence.
|
||||
Reference in New Issue
Block a user