Morphir.Compilation 0.4.0-alpha.5

• net10.0

  • FSharp.Core (>= 10.1.403)
  • Morphir.Models (>= 0.4.0-alpha.5)

• net11.0

  • FSharp.Core (>= 10.1.403)
  • Morphir.Models (>= 0.4.0-alpha.5)

### Added

- Releases attach the Windows toolchain for `win-arm64` as well as `win-x64`: the self-contained host, the F# frontend and backend archives, the candidate, the extension selection and the bundle, with one `SHA256SUMS` over both platforms' files, so `morphirup-win-arm64.exe setup` installs from the release. Each Windows toolchain is built once, by the same job as its manager, after `CheckBuildMachine`; the separate win-x64 toolchain job is gone. Pull requests build and check the `win-arm64` toolchain in `morphirup.yml` and keep it downloadable for seven days.
- `deployment.yml` has a `dry-run` input for a manual run: it builds every platform, assembles the release assets and checksum files, uploads them as the `dry-run-release-assets` artifact, and publishes nothing to NuGet or GitHub releases.
- Windows ARM64 (`win-arm64`) is a released platform. The release workflow builds `morphir-win-arm64.exe`, `morphir-win-arm64-v<version>.tar.gz`, `morphirup-win-arm64.exe` and `morphirup-win-arm64-v<version>.tar.gz` on the hosted `windows-11-arm` runner, natively, and the morphirup checksum file lists the morphirup ones; the pull request workflow `morphirup.yml` builds and checks `morphirup` there too. The names, contents and checks of the other platforms' assets are unchanged. Earlier releases have none of these files ([#611](https://github.com/finos/morphir-dotnet/pull/611)).
- Experimental Windows release setup with `morphirup`: in a project, `morphirup setup --yes` downloads the runtime-bundled Morphir host and the independent F# frontend and backend from the exact `finos/morphir-dotnet` release of the manager's own version (or the exact version `.morphir/toolchain.toml` requests), checks each file's byte count and SHA-256 against the release's `SHA256SUMS`, installs the complete folders into the content-addressed store, runs the fixed readiness workflow and selects the completed generation last. `morphirup run -- compile` and `morphirup run -- generate` then use the installed folders with no network access. `setup --dry-run` creates nothing. This is release-checksum delivery, not publisher-authenticated: HTTPS and a matching checksum do not authenticate the publisher, and trust commands are not included. The release transport starts at the exact repository and version tag and follows at most three HTTPS redirects to `github.com`, `release-assets.githubusercontent.com` or `objects.githubusercontent.com`. The release attaches the setup bundle for Windows x64 and Windows ARM64. `Morphir.Extensions.Installation` is a new library package ([#608](https://github.com/finos/morphir-dotnet/pull/608)).
- Build: `CheckBuildMachine --rid <rid>` fails unless the machine's operating system and architecture are the RID's and the .NET SDK runs natively (not x64 under emulation on ARM64), and logs the machine. The CLI release jobs and `cli-offering.yml` run it before they build.
- Build: `FlattenReleaseAssets` copies each downloaded platform output into the release assets once, accepting byte-identical duplicates and failing on two different files under one name instead of overwriting; the morphirup checksum jobs use it. `WindowsToolchainChecksums` writes one `SHA256SUMS` over both Windows toolchain outputs, and writes nothing when a Windows RID's bundle or manager is missing, or an asset its bundle names is missing or differs.
- `scripts/install-windows.ps1` and the proto plugin choose `win-arm64` on Windows ARM64, where they refused before. The Windows installer now reads the machine's architecture, so an x64 PowerShell under emulation on ARM64 also chooses `win-arm64`. Releases before this one have no `win-arm64` file, so asking either for an earlier version fails on Windows ARM64.
- Experimental configured Python WASM commands: `morphir compile --language python` and `morphir generate --target python` use `extensions.python.path` through the existing MEP model adapters and owned WASM sessions. Includes a pinned Python 0.6.0 walkthrough; Windows x64 retains its named runtime refusal ([#610](https://github.com/finos/morphir-dotnet/pull/610)).
- Experimental WASM host-kit reports adopt the pinned parent report schema, computed ordered verdict reasons, per-profile guest-kit citations and eight named refusals. All 22 fixed policy controls are checked independently; the runner retains observation recomputation and exact report rebuilding. Citation-bearing runs fail closed with an explicit unavailable-checker result until the actual generic-kit report checker is integrated. This does not qualify a host, guest, artifact or platform ([#564](https://github.com/finos/morphir-dotnet/issues/564)).
- Internal current-family standalone and embedded claim reader, retaining supplied JSON beside existing MEP values and an understood-member projection, with recursive metadata checks, critical paths and host comparators reused from Toolchain. Claims 27/27 and affected SharedReaders 19/19 pass on Windows, repeated after pinned formatting. Public codecs, full corpus conformance, probes and installation lifecycle remain unfinished ([#558](https://github.com/finos/morphir-dotnet/issues/558)).
- Internal extension-family reader increment with pinned, offline hash-checked schemas and case data from parent `0439c4c0`. The focused Windows SharedReaders suite passes 19/19, including six parent release/schema cases and two I-JSON refusal cases with valid parse controls. Full claim/package semantics, state codecs, inventory, probes and command lifecycle remain unfinished; the 137 identity and 66 package cases have not all been executed ([#558](https://github.com/finos/morphir-dotnet/issues/558)).
- Extension installer security corrections: descriptor-bound single-file publication, interprocess run-directory ownership coordination, directory/owner identity checks, and gzip metadata/padding budgets with cancellation below the tar reader. Windows regression evidence is 131 passed with three Unix-only cases ignored. Independent security/interop re-review of `b6936ba5` found no concrete remaining finding under the approved cooperating Home boundary; Unix runs and AOT remain pending. Recorded the approved selection, command, provenance and explicit developer-consent decisions; inherited default staged `auto` grants no automatic install consent. Shared readers use parent source `0439c4c0`; portable pin/overlay formats remain parent toolchain work ([#558](https://github.com/finos/morphir-dotnet/issues/558)).
- Extension installation library foundations: portable distribution identifiers over the existing domain types, RID/descriptor/index mappings and exact implemented MEP eligibility within the supported 0.2 line. Includes an Expecto suite and C# probe; CLI installation and Native AOT qualification remain unfinished ([#558](https://github.com/finos/morphir-dotnet/issues/558)).
- Extension installation I/O: a single-file content-addressed store that hashes while copying, rehashes reuse and refuses corrupt objects without replacement; ZIP and tar-gzip inspection with the recorded path, type and resource limits; and exclusive ownership and stale cleanup of .NET run directories. Windows tests and the C# JIT probe cover these APIs. Package formats, extraction, inventory, activation and CLI installation are unfinished; Unix filesystem runs and Native AOT qualification remain pending ([#558](https://github.com/finos/morphir-dotnet/issues/558)).
- `morphir mck <args>` runs the separately installed Morphir Compatibility Kit, `morphir-mck <args>`, a development tool from finos/morphir, in every entry point (`morphir`, the managed `morphir`, `dotnet-morphir`). The arguments, working directory, environment and standard streams are passed on unchanged, and the exit code is the tool's. `MORPHIR_MCK` names the tool's absolute path; otherwise only absolute `PATH` folders are searched, never the current directory, and on Windows only `morphir-mck.exe` is a candidate. With no tool, the CLI writes a diagnostic to stderr and exits with 127. On Windows, killing `morphir` also stops the tool and its children (a kill-on-close job object); on Linux and macOS, SIGTERM or SIGHUP stops the tool's tree. `mck` is the only command routed to another executable, and the CLI includes no kit of its own ([#589](https://github.com/finos/morphir-dotnet/issues/589))
- `morphir extension list --json` and `dotnet-morphir extension list --json` say which offering is running and what it needs from the machine: `deployment` (`native-aot`, `self-contained`, `framework-dependent` or `dotnet-tool`), set at build time by the named release profile and never inferred from how the process runs; `execution` (`native-aot` or `jit`); `platform` (the runtime identifier, left out for the portable tool package); and `prerequisites` (`runtime`, `sdk` with its `phase`, and `native`). A build that no named profile produced, such as `dotnet run`, a test host or the legacy `morphir-<rid>` single-file assets, leaves out `deployment`, `platform` and `prerequisites`. Each extension entry gains `deployments`, `prerequisites` and, when it is not available, a `reason`. The `host` member keeps its meaning as the command name ([#558](https://github.com/finos/morphir-dotnet/issues/558))
- The built-in F# frontend is listed as `morphir-dotnet.fsharp`, available in the self-contained and framework-dependent `morphir` and in `dotnet-morphir`. The Native AOT `morphir` lists it as not available, with the reason; the registry and `compile` take the claim from the same declaration ([#558](https://github.com/finos/morphir-dotnet/issues/558))
- `Morphir.Toolchain`: the recipe binding checks of the toolset recipe page, as pure functions over a recipe, the authenticated targets and their bytes. `RecipeBindings.check` runs every host row (a `tool-release` offering's v1 release descriptor is authenticated, not revoked, served with its length and digest and readable, and lists each bound artifact for its platform with matching `tool-artifact` metadata) and every provider row (the extension release descriptor is bound, served, readable and names the provider's identity; each artifact or package is bound and listed with the delivery's runtime, digest and platform; and the claims name the capability kind, MEP version, language or target and model tuple), each with the row's code and path. It reads tool release metadata v1 release descriptors (`ToolReleaseDocument`), extension release descriptors at `2.0.0-draft.2` (`ExtensionReleaseDocument`) and capability claim sets at `0.1.0-draft.2` (`ClaimSetDocument`), and nothing earlier. `ToolResolver.resolve` selects a tool release by the v1 channel, CLI compatibility and platform rules. No command uses them, nothing is downloaded, and none of it has had a security review ([#558](https://github.com/finos/morphir-dotnet/issues/558))
- `morphirup setup --dry-run`: the same request as `setup --plan`, with the same plan, `planSha256`, result, refusals and exit codes, and nothing created, changed or removed. `--plan` is unchanged; both may be given; neither permits `--yes`. Every later `morphirup` command that creates, updates, repairs or removes persistent state will have `--dry-run` on its own planning and validation path ([#558](https://github.com/finos/morphir-dotnet/issues/558))
- `Morphir.Toolchain`: `Comparator.allMet`, which says whether an installed version meets a list of comparators by the Rust `semver` and npm rule (a prerelease matches only when a comparator names its own major, minor and patch with a prerelease; an empty list is always met), and `Discovery.requestIn` with `Discovery.PathCase`, which compares names without case on Windows, and `Discovery.within`. The suite also runs the contract's `nfc`, `setup-platforms`, `prerequisite-versions` and `version` binding cases and its Windows discovery case ([#558](https://github.com/finos/morphir-dotnet/issues/558))
- `Morphir.Toolchain`: the verification part of a TUF client for the tool release metadata v1 profile, as pure functions over supplied bytes and one trusted start time: strict readers for root, timestamp, snapshot and targets metadata, Ed25519 threshold verification with BouncyCastle, root rotation with both thresholds and a retry after 32 roots, timestamp, snapshot and targets checks with rollback, link and expiry, and typed failures mapped to the stable codes. A refresh returns a `RefreshResult` whose every outcome (`Refreshed`, `NothingNew` for a timestamp at the trusted version, `RootRotationPaused` and `Failed`) carries the newest trust state accepted, so a root accepted before a failure is kept. No exception leaves the client: a defect is a `Failed` with `TufFailure.Internal`. A trust anchor carries its purpose, and a `Production` anchor must be the repository identity the caller names; every root accepted later meets the same rules. Text inside `signed` that is not NFC, a member differing from a known member only in letter case, a prerelease `spec_version` and an integer above 253 - 1 are refused. It does no I/O and no command uses it. It has not had a security review and must not be used to authenticate a production release until it has. Where the profile is silent it takes the stricter reading, marked provisional ([#558](https://github.com/finos/morphir-dotnet/issues/558))
- `morphir generate --extension` and the configuration key `[codegen.<target>].extension` select a MEP backend extension (a command name, a path, or a `.dll`, as for `compile --extension`), for example `morphir-fsharp-backend`. The option wins over the key; without either, the built-in backend runs as before. Every entry point has the option. The generate report names the extension by its own id and adds `backendTransport` (`mep`) and `backendVersion`. Failures have the codes `extension.unavailable`, `extension.protocol_error`, `extension.timeout`, `extension.tuple_unavailable`, `extension.not_admitted`, `extension.unsafe_artifact` and `invalid-extension`. An extension cannot be selected by an installed extension id yet
- `MepGenerationBackend` in `Morphir.Tooling`: an `IGenerationBackend` over a MEP guest's `morphir.backend.generateModel`. It sends the model's JSON IR (IR `4.0.0` or `3.0.0`) only within the limits that the session agreed (`MepBackendOptions.OfferLimits`), accepts at most 10,000 artifacts in one result, and checks every returned artifact path before publication, including Windows-equivalent names, reserved device names and file/directory conflicts. `MepBackendOptions.Environment` sets the guest's whole environment. A guest that gives the id of a built-in backend is refused
- `MepGuestProcess` in `Morphir.Compilation.Mep`: the guest-process lifecycle (start, initialize, describe, request with a deadline, shutdown or kill of the process tree) that `MepFrontend` and `MepGenerationBackend` share. `MepGuestOptions.Environment`, and an additive `MepFrontend.ConnectAsync` overload, set the guest's whole environment
- `Morphir.CodeGeneration.FSharp`, for C# callers: the public union `FSharpFormatting` (`Applied`, `Off`, `Unavailable`, with `WireValue`), which `Transpiler.formatting` now records; `FSharpGeneration.TryGetFormatting(tree, out formatting)` and `FSharpGeneration.WithRequiredSemantics(context, semantics)`; and `GenerationOptions.WithOptimize` and `WithFormat`. The project now sets nullable metadata, warnings as errors, and the trim and AOT properties
- `morphir generate --target fsharp --option format=false`: the F# backend option `format` (Boolean, `true` by default, beside `optimize`) turns Fantomas formatting off. The files are the generator's own text, with LF line endings only and exactly one final LF, the same bytes on every operating system, under JIT and Native AOT, and in every culture. The external backend `morphir-fsharp-backend` accepts the same option through the `generateModel` options. `GenerationOptions.Format` and `Transpiler.formatting` carry it in `Morphir.CodeGeneration.FSharp`
- The generate report member `formatting`: `applied`, `off` or `unavailable`, written for a built-in backend only: an external backend (`backendTransport` `mep`) has no `formatting` member, even with `format=false`, because a MEP generate result does not say whether the guest formatted. `compile --target` writes the same member in its `generation` report member. Under the default, a host that cannot run the formatter (the Native AOT `morphir`) writes a warning on stderr from `generate` and from `compile --target`, never on stdout or in the JSON output; its bytes are unchanged

### Changed

- Build: the repository builds with the .NET 11 SDK (`11.0.100`) and C# 15. `morphir`, `dotnet-morphir`, `morphirup`, the F# extension tools and the tests target `net11.0`, so the framework-dependent `morphir` and `dotnet-morphir` need `Microsoft.NETCore.App` 11.x, and installing `dotnet-morphir` needs a .NET SDK 11.0.100 or later. The library packages target `net11.0` and `net10.0`, so .NET 10 applications can still use them. .NET 8 and .NET 9 reached the end of support on 2026-11-10, so .NET 10 is the lowest target. The MSBuild tasks and Myriad plugins in `Morphir.Myriad` and `Morphir.Myriad.SystemTextJson` stay on `net10.0`, so the .NET 10 SDK can load them. Their MSBuild reference packages return to the 18.0 line, because 18.1 and later have no `net10.0` assets. `Microsoft.Extensions.*` and `System.Text.Json` move to 11.0.0, which also supports `net10.0`. The target frameworks are set in one place, `Directory.Build.props`
- Build: the Native AOT publish of `morphir` treats IL3050 as an error. The F# formatter (`Emit.formatCore`, Fantomas) is `[RequiresDynamicCode]` and is called only behind `RuntimeFeature.IsDynamicCodeSupported`, so if that guard goes, ILC refuses the publish instead of putting Fantomas (about 20 MB) into an image that cannot run it
- Release process: finos/morphir now builds, qualifies and publishes the official Morphir CLI from a pinned commit of this repository. The deployment workflow here publishes the library packages and the F# extension tools, and builds and publishes the CLI (the `morphir-<rid>` executables, the `morphirup-<rid>` assets and the `Morphir.Tool` package) only when the repository variable `MORPHIR_DOTNET_CLI_PUBLICATION` is `enabled`, as a rollback. The reusable workflow `cli-offering.yml` builds one of the four offerings for one platform at a given commit with `PackRelease`, starts the produced executable (or the installed `dotnet-morphir`) with `--version`, and uploads the file, its launch metadata and its SHA-256. `PublishTool` is now `PublishCliTool` plus `PublishExtensionTools`, and `PublishTool` and `PublishAll` publish what they did. See `docs/contributing/cli-build-interface.md` ([#589](https://github.com/finos/morphir-dotnet/issues/589))
- In the Native AOT `morphir`, the hint of `compile.frontend_unavailable` for F# now names the offerings that have a built-in F# frontend and the process delivery `morphir-fsharp-frontend` ([#558](https://github.com/finos/morphir-dotnet/issues/558))
- `Morphir.Toolchain` and `morphirup` follow the finos/morphir toolchain contract at `9e1f853b7` (the draft finos/morphir#1147), re-pinned from `1451c081f`. The same input now gets another code or path:
- Documents that were read before are now refused with `inconsistent_document`: a built-in with `protocolVersion` or `modelTuple` in a recipe, lock or receipt, at that member; an offering that lists a MEP version or a WASM ABI twice, at the repetition; a plan whose host source is `recipe-digest` or whose provider source is `repository-target`, at its `source`; and a diagnostic with `document` or `path` but not both, at the one present
- `morphirup` results: an `unsupported-artifact` diagnostic from `setup --plan` names the request member it concerns with `document` `request` and `path`, such as `toolset.providers[1]`, and a `repository_mismatch` diagnostic names the recipe member (`setup --plan`) or lock member (`doctor`) that names another repository. A recipe, lock or request that `0.4.0-alpha.4` accepted and that is now refused turns a `planned` or `succeeded` result (exit 0) into a `failed` one (exit 1); for example, a recipe that lists a MEP version twice in one offering. Exit code 2 (the command was not run) and exit code 3 (an internal error) mean what they did, and the plan digest of any input both read is unchanged. The version bound (256 characters, 15 digits per numeric identifier) is the contract's rule and no longer provisional
- `Morphir.Toolchain` API, for F# callers: `DiagnosticDetail.UnsupportedArtifact` and `DiagnosticDetail.TrustFailure` have a last field `concerns: DocumentMember option`; `BindingFailure.RepositoryMismatch` carries the document whose member its path names; `Diagnostics.ofTargetRefusal` takes that document; and `RecipeTargets.checkLockedGeneration` takes the generation's recipe as a function `unit -> Result<Recipe, TargetRefusal>`, asked for only for the host release row (a refusal it returns is the check's, and an exception it throws is `invalid_document` at `recipe.target`), and refuses a generation whose recipe target the trust state does not list with `target_not_authenticated` at `recipe.target`, before reading the recipe ([#558](https://github.com/finos/morphir-dotnet/issues/558))
- `morphir generate --input` now loads the project configuration (from `--project`, `--config` or discovery) to read `[codegen.<target>].extension` when `--extension` is absent. With `--project` or `--config`, a configuration that fails to load fails the command with exit code 2. With neither, a discovered configuration that does not load is a warning on stderr and the built-in backend runs, as before
- `compile --extension`, from the shared guest-process lifecycle: a user cancellation (Ctrl+C) while the guest initializes is now a cancelled compile (exit code 130) instead of `extension.unavailable`, and a guest that honors `$/cancelRequest` at the deadline now gives `extension.timeout` instead of `extension.protocol_error`
- `compile --target` does not run a backend extension: it runs the built-in backend of the target, as before. When the project configuration sets `[codegen.<target>].extension` for that target, it now prints a note on stderr saying so
- `GenerationOptions` (`Morphir.CodeGeneration.FSharp`) has the new field `Format`, so a record expression that sets every field needs it, and C# that calls its two-argument constructor must pass both; `{ GenerationOptions.Default with Optimize = ... }` and `GenerationOptions.Default.WithOptimize(...)` keep working

### Fixed

- `morphirup setup`: a `setup.readiness_failed` refusal now includes the host's own diagnostic code and message; a completed attempt removes its staging folders under Home, on success and on refusal; `run -- generate --target csharp --output fsharp` keeps the built-in C# backend, because installed F# providers are chosen from the `--target` and `--language` values only; and on Windows, dry run and apply refuse before creating Home when an installed host or provider executable path would reach 260 characters, naming Home, the executable and the 259-character limit ([#616](https://github.com/finos/morphir-dotnet/pull/616)).
- WASM execution now refuses Windows x64 with `win_x64_trap_unsupported` before loading the engine or a module. Other CLI capabilities remain available; the CET/Spectre-preserving fix is tracked in #609. The diagnostic signal-trap override is removed.
- Corrected Darwin ARM64 variadic mode placement for installer `open`/`openat`, preserving no-follow/exclusive flags and descriptor identity. Hosted macOS failures at `4c908047` are the regression evidence. Focused Windows Store 15/15 and RunCopies 5/5 pass, with three Unix-only tests ignored; exact-head macOS/Linux verification remains pending ([#593](https://github.com/finos/morphir-dotnet/pull/593)).
- Configuration: a member of `[frontend]` that is not a table (for example `[frontend]` `note = "x"`) is no longer refused as an invalid language table. Only an object-valued member is a `[frontend.<language>]` table with `project_file` and `extension`; any other member stays unconstrained, as the upstream schema leaves it
- `compile --extension`: a frontend guest that never answers `compileModel` now fails with `extension.timeout` at the deadline, and a guest that does not answer `shutdown` or take `exit` within the deadline (for example one whose handler blocks its read loop) has its process tree stopped. Before, the host could wait indefinitely in both cases. The same holds for `generate --extension`, so a timed-out request ends within about two deadlines
- A frontend or backend guest that fails to start or initialize no longer leaves its stderr reader or process handle behind
- `compile`: for a language id with a dot, `[frontend."acme.lang"].extension` and `project_file` are now read from that quoted table; before, the id was split at the dot, so the keys were looked up under `[frontend.acme.lang]` and the quoted table was ignored. A project file key that is not read for lack of a language is now named with the quotes too

### Security

- Morphir.Live: centrally pin the transitive `Microsoft.AspNetCore.WebUtilities` dependency to 9.0.23 for [CVE-2026-114149 / GHSA-x33c-w48q-qrgc](https://github.com/dotnet/announcements/issues/511), replacing the affected 9.0.19 selected through Fun.Blazor.
- `compile --extension`, `generate --extension` and the `extension` configuration keys refuse a guest that reports an extension id that starts with `morphir.`, which is reserved for the built-in frontends and backends, including built-ins that do not ship yet (`extension.unavailable`). Before, `generate` refused only the id of a registered built-in backend, and `compile` checked no id. `org.finos.morphir.*` ids are not reserved. `Morphir.Mep.ReservedExtensionIds` and `ExtensionId.ReservedForBuiltIns` hold the rule
- `compile --extension`, `generate --extension` and the `extension` configuration keys: a command name without a directory (for example `morphir-fsharp-backend`) is now searched only in the absolute `PATH` directories, and the resolved absolute path starts. Before, process start also looked in the directory of `morphir` and in the current directory first (CreateProcess on Windows, and .NET on Unix), so a checkout could plant a binary of that name and have it run. A `.dll` extension's `dotnet` host is resolved the same way when `DOTNET_HOST_PATH` is not set. A name that is not on `PATH` now fails with `extension.unavailable` before any process starts. `MepFrontendExtensionConnector.Resolve` throws `FileNotFoundException` for such a name instead of returning it unchanged