Spec: Capability statements across the extension lifecycle

[DamianReeves]

Working spec. This is the agent-style working specification for how an extension's capabilities travel from the guest through packaging, publication, installation and a session. The durable form goes into the MEP draft (docs/design/draft/extensions/protocol.md and distribution-and-acquisition.md) and the morphir-extensions knowledge-base bundle. Where this thread and those documents disagree, this thread is newer until they are updated.

Related: #915 (working thread for "a single file is a synthesized project"), #917 (its spec). This work came out of step 5 of #917, when the Elm MEP extension gained morphir.workspace.discover and needed a way to declare it.

Problem

An extension's capabilities are stated in three places, and two of them must agree:

1. the guest, which reports them at morphir.initialize;
2. the release descriptor, written by hand: .github/extensions.toml flags in morphir-rust, extension.json in morphir-elm;
3. the host's parsers for the bundle descriptor, the repository index record and the installed catalog.

The host compares (1) with the installed record built from (2) at every session, and refuses the session when the capability kinds differ ("capability kinds changed"). So every new capability means editing the descriptor, the writer in each language, and the host parser. Every parser uses deny_unknown_fields, so a released CLI rejects the new key until a new CLI ships. That is why TRANSITIONAL_FIELDS exists in .mise/tasks/test/cli-release.

Two more facts found while working on step 5:

• morphir extension repository publish accepts only a single-artifact WASM bundle ("local repository publication currently requires a WASM bundle"). It also rejects any file in the bundle directory other than release.json, the artifact and its checksum.
• The Elm MEP extension publishes six process archives and one .release.json with an artifacts[] list. That shape is not the bundle format, and process bundles are refused anyway. No tool turns an Elm release into an installed record. The only installed Elm records today come from hand-written index lines in tests.

The existing MEP draft already says "Receivers must ignore unknown object fields" for protocol messages. The distribution formats do the opposite.

Decisions

#	Decision
1	The guest is the only author of its capabilities. Packaging captures the guest's own capability statement and carries it unchanged. No capability is declared by hand in a TOML or JSON manifest.
2	repository publish accepts process bundles as well as WASM bundles.
3	A new protocol method, morphir.extension.describe, returns the capability statement. It is allowed before morphir.initialize and has no side effects.
4	Install probes the artifact it selected with describe and refuses on a mismatch. extension install --no-probe skips the probe.
5	Each artifact carries its own statement. Artifacts of one release may differ, under two guards: a difference must be declared at release time, and install and extension info show it.
6	Readers ignore unknown members unless they are marked critical, at every boundary.
7	Formats carry a SemVer version, and readers accept a range: the current and previous released major, plus the exact drafts they list.
8	An extension may state the minimum host it needs, as a critical member.
9	describe is optional for guests. A host falls back to initialize, capabilities, shutdown.
10	A record without a statement is converted, not refused. The host builds a statement from the old flat keys and marks it declared rather than probed.
11	There are three release paths: host only, extension only, and both (host first, then extension). One bootstrap host release is unavoidable.
12	SemVer is the default contract versioning scheme (added 2026-09-22). Every versioned contract uses SemVer 2.0 strings; drafts match only exactly; on 0.y.z the minor acts as the major. A new contract starts at 0.1.0-draft.1 and moves to the 1.0.0-draft line once settled; a revision of a shipped format starts at its next major's first draft. MEP keeps 0.1 until its next protocol change; Morphir IR formatVersion is not affected. Recorded in AGENTS.md and morphir-cli decision 0003.

The capability statement

A statement is what the guest says about itself. It has the same content in every phase:

{
  "statementVersion": "0.1.0-draft.1",
  "protocolVersions": ["0.1"],
  "extension": {
    "id": "morphir-elm",
    "name": "Morphir Elm frontend",
    "version": "0.3.0",
    "types": ["frontend", "workspace"]
  },
  "capabilities": {
    "frontend": {
      "languages": [{ "id": "elm", "fileExtensions": [".elm"] }],
      "irVersions": ["3"],
      "compile": true,
      "incremental": false,
      "multiDocument": false
    },
    "workspace": { "protocolVersions": ["0.1.0-draft.1"], "discover": true }
  },
  "requires": { "host": [">=0.4.0-alpha.7"] },
  "critical": ["requires.host"]
}

• types are the capability kinds. Readers check them strictly: a kind a reader does not know is an error.
• capabilities members are carried unchanged by every reader. A reader uses the members it knows and ignores the rest.
• critical lists member paths that change meaning. A reader that does not understand a listed path refuses and names it.
• requires.host is a list of single SemVer comparators over the host version, such as [">=0.4.0-alpha.7", "<0.5.0"], all of which must hold. Single comparators parse the same way in the Rust semver crate and in @std/semver. A host outside the range refuses with a message that names the range.

morphir.extension.describe

Kind	request
Allowed	before morphir.initialize, and in any later state before shutdown
Params	{ "protocolVersions": ["0.1"] }, the versions the caller understands
Result	the capability statement
Side effects	none. The guest must not read a workspace, open a network connection, write files or depend on environment values other than those the host passes

After describe the caller may send morphir.exit without a session. A guest that does not implement describe answers -32601, or refuses the request because it was sent before initialize. In both cases the host falls back to a session that follows the lifecycle: initialize, the initialized notification, morphir.extension.capabilities, shutdown, exit. A session reports less than a statement, so the statement rebuilt from it lists only the negotiated protocol and has no requires or critical.

When a session agrees with a statement

An initialization result is not a statement: it carries one negotiated protocolVersion and the capabilities of that session. The host does not test the two for equality. The result agrees with the statement when the extension's id, name and version are equal, the negotiated protocolVersion is one of the statement's protocolVersions, every capability kind the session reports is among the statement's types, and every member it reports has the statement's value. A session may offer less than its statement; it may never offer more, or something different. Publication and installation compare two statements, which must be equal.

Lifecycle phases

Phase	Who acts	What the guest answers	Guest side effects
package	release tooling, per platform	describe	none
publish	repository publish, where the artifact runs on the publishing host	describe	none
install	extension install, for the selected artifact	describe (skipped with --no-probe)	none
session	host	initialize, whose result must agree with the statement	none until an operation is called
operate	host	compile, generate, discover, validate, transform	only through host functions or within the sandbox
shutdown	host	shutdown, then exit	release resources

Publish, install, update and uninstall remain host operations. The guest takes part in them only through describe, so it cannot change anything while being published or installed.

What "probe" means per runtime

A probe starts the artifact and sends describe.

• process: spawns the native executable with the same launch rules as a session: a cleared environment with an allow-list, an explicit working directory, a request timeout, and kill on drop. There is no operating-system sandbox, so the process has the user's rights. It would have the same rights at first compile; the probe moves the first execution from first compile to install. --no-probe exists for users who do not accept that.
• wasm: instantiates the module in the WASM engine. It is memory-isolated and has no direct file or network access.

Bundle descriptor, version 2

One descriptor per release, with one entry per artifact:

{
  "schemaVersion": "2.0.0-draft.1",
  "extensionId": "morphir-elm",
  "shortId": "elm",
  "version": "0.3.0",
  "gitCommit": "…40 hex…",
  "platformDifferences": "none",
  "artifacts": [
    {
      "platform": "aarch64-apple-darwin",
      "runtime": "process",
      "filename": "morphir-elm-extension-0.3.0-aarch64-apple-darwin.tgz",
      "sha256": "…",
      "statement": { "…": "as returned by describe on that platform" }
    }
  ]
}

• A WASM bundle is the case with one artifact and no platform.
• platformDifferences is "none" or "declared". When the probed statements differ across artifacts and this is "none", the release job fails. An accidental platform bug is caught; a deliberate difference is written down.
• A bundle directory holds the descriptor, every artifact it lists, and one checksum per artifact. Nothing else.

Flows

Today: WASM extension

sequenceDiagram
    autonumber
    actor Author
    participant Pack as Packager
    participant GH as GitHub release
    actor User
    participant Repo as repository publish
    participant Inst as extension install
    participant Host as morphir compile
    participant Guest

    Author->>Pack: extensions.toml (capability flags by hand)
    Pack->>GH: release.json (flags copied) + artifact + checksum
    Note over Pack,Guest: the guest is never asked
    User->>Repo: publish --bundle
    Repo->>Repo: strict parse, WASM only, kinds from keys
    User->>Inst: install
    Inst->>Inst: verify digest, strict catalog record
    User->>Host: compile
    Host->>Guest: initialize
    Guest-->>Host: types + capabilities
    Host->>Host: kinds differ → "capability kinds changed"

Loading

Today: Elm process extension

sequenceDiagram
    autonumber
    actor Author
    participant Rel as release task
    participant GH as GitHub release
    actor User
    participant Repo as repository publish

    Author->>Rel: extension.json (capabilities by hand)
    Rel->>GH: 6 archives + .release.json (artifacts[])
    User-xRepo: publish --bundle
    Note over Repo: other schema, and process bundles are refused

Loading

Proposed

sequenceDiagram
    autonumber
    actor Author
    participant CI as Release matrix (one job per platform)
    participant Guest
    participant Asm as Release assembly
    participant GH as GitHub release
    actor User
    participant Repo as repository publish
    participant Inst as extension install
    participant Host as morphir compile

    Author->>CI: tag
    CI->>Guest: describe
    Guest-->>CI: statement for this platform
    CI->>Asm: artifact + sha256 + statement
    Asm->>Asm: compare statements across platforms<br/>differ and platformDifferences = none → fail
    Asm->>GH: descriptor (version 2) + artifacts + checksums
    User->>Repo: publish --bundle (WASM or process)
    Repo->>Repo: verify every digest and checksum
    opt an artifact runs on this host
        Repo->>Guest: describe
        Repo->>Repo: equal to its statement, else refuse
    end
    Repo-->>User: index record: kinds strict, statements kept
    User->>Inst: install
    Inst->>Inst: select artifact for this platform, verify digest
    Inst->>Guest: describe (unless --no-probe)
    Inst->>Inst: equal to the record, else refuse
    Inst-->>User: note when this artifact differs from others
    User->>Host: compile
    Host->>Host: registry reads the stored statement
    Host->>Guest: initialize
    Host->>Host: agrees with the installed statement
    Host->>Guest: discover / compile

Loading

Compatibility rules

1. Must-ignore unless critical. At every boundary (descriptor, index record, installed record, statement, describe result) a reader ignores an optional member it does not understand, and refuses a member listed in critical that it does not understand.
2. Version ranges. A host reads the current and previous released major of each format, plus the exact drafts it lists. A publisher writes the highest version that the oldest host it targets reads. A draft such as 2.0.0-draft.1 matches only exactly.
3. Minimum host. An extension that needs a newer host states requires.host and lists it in critical.
4. describe is optional. On -32601, or on a refusal before initialize, the host falls back to a session.
5. Old records are converted. A record without a statement becomes a statement built from its flat keys, marked declared. Install and the first session verify it as usual.

Release paths

Path	What must hold	Gate
Host only	the new host reads every supported older descriptor, record and guest (rules 2, 4, 5)	a host compatibility suite: the new CLI publishes, installs and compiles with the latest released bundle of each first-party extension
Extension only	works with the released host it targets, or states requires.host (rules 1, 3)	test:cli-release against the pinned CLI, extended to the Elm process bundle
Both	host first, then extension; never both at the same time	the host suite passes, the host releases, the extension pin moves, then test:cli-release passes

"Both" is needed only for a critical change. Everything else goes out on one side alone.

Bootstrap

Released hosts follow none of the rules above. The first step is a host-only release that implements rules 1 to 5 and still reads version-1 descriptors and records. Until it ships, extensions keep writing the flat version-1 keys. After it ships and the pins move, extensions adopt statements and version 2.

The same release also satisfies the removal condition of the three transitional mechanisms from #915: the legacy compile envelope in the Rust SDK, compile_wire_request in the CLI, and the TRANSITIONAL_FIELDS skip. They retire at the same time, when the pins move.

Consequences for work in flight

• morphir-elm feat/mep-workspace-discovery writes workspaceDiscovery: true as a flat key. It is the old shape, but it is correct under version 1 and the bootstrap host converts it (rule 5). The branch keeps it. The PR waits until this spec is agreed.
• multiDocument (added in step 5) is not in any installed record today, so an installed provider always reads as single-document. Statements fix that without a new record field.
• The bootstrap host is the release that carries steps 5 and 6 of Spec: A single file is a synthesized project #917.

Rejected alternatives

Option	Why not
Keep adding boolean keys to the descriptor	Every capability needs a descriptor key, a writer in each language, a host parser change and a CLI release
Probe only at publish	A process release has platforms the publisher cannot run; the artifact that runs is only on the user's machine
Reuse initialize for the probe	A session is heavier than needed, and "no side effects" would be a convention rather than the contract of a method
One statement shared by every artifact	Hides real differences, for example between a WASM and a process artifact of one release
A merged statement in the index record	Would claim a capability that some installed artifact lacks
No install probe	A mismatch is found only at first compile

Open questions

1. What canonical form do two statements take before they are compared (key order, number spelling)?
2. Does publish also probe WASM artifacts that it can always run, and should that be required?
3. Should the statement be covered by the artifact's provenance or signature once publisher authenticity exists (distribution open question 4)?
4. Can a process probe get an operating-system sandbox where one is available, for example a restricted profile on macOS or a namespace on Linux?

[DamianReeves]

Update, 2026-09-22: SemVer versions, as the default

Decision 12 is added and the body is updated to match. Every versioned contract Morphir defines uses SemVer 2.0 version strings by default.

• A released version is compatible within its major. Unknown members are ignored unless critical names them. A breaking change takes a new major.
• A prerelease such as 1.0.0-draft.1 matches only exactly. Drafts are refined in place and promise no compatibility with each other, so a released host never misreads a later draft.
• A reader supports the current released major, the previous released major, and the exact drafts it lists. This replaces the earlier "schema N and N-1" rule.

In this spec that gives: statementVersion "1.0.0-draft.1", release descriptor schemaVersion "2.0.0-draft.1" (the existing integer and "1.0" values are read as version 1), and the workspace discovery protocol "1.0.0-draft.1" in place of the integer 1.

Recorded exceptions: MEP keeps 0.1 until its next protocol change, which adopts SemVer. Morphir IR formatVersion keeps its own IR decisions; this does not supersede them.

The default is in AGENTS.md, so it applies without being decided again, with the reasoning in the morphir-cli knowledge-base decision SemVer is the default contract versioning scheme. Both are in #922.

[DamianReeves]

Correction: new contracts start at 0.1.0-draft.1

Refining decision 12, and the body is updated:

• A new contract starts at 0.1.0-draft.1 and moves to the 1.0.0-draft line once its shape is settled enough to aim at a stable release. The capability statement (statementVersion) and the workspace discovery protocol are new, so both start at 0.1.0-draft.1, not 1.0.0-draft.1 as the previous comment said.
• A revision of a format that already shipped in a released host continues from its next major: the release descriptor and the index and installed records shipped as 1 and "1.0", so their next shape stays 2.0.0-draft.1. Restarting them at 0.1.0 would sort below what released hosts already read.
• On the 0.y.z line the minor acts as the major, as in Cargo: 0.1.x releases are compatible, and 0.2.0 breaks. Drafts still match only exactly.

[DamianReeves]

Implementation note: use the semver crate

Code never implements its own version type. In Rust, contract versions are semver::Version and ranges are semver::VersionReq, from the semver crate that is already a workspace dependency. Other languages use their established SemVer library.

• Compatible within the major, with the minor as the major on 0.y.z: a caret requirement such as ^0.1.0. The crate follows Cargo's rules exactly.
• A draft matches only exactly: an exact requirement such as =0.1.0-draft.1. A caret is not enough for drafts, because the crate lets ^0.1.0-draft.1 also match 0.1.0-draft.2.
• A reader's supported set is therefore a list of requirements: carets for released lines, exact requirements for drafts.

This settles open question 2: requires.host is a VersionReq, checked against the host's own Version, with the crate's prerelease matching. The rule is in AGENTS.md and the morphir-cli decision in #922.

[DamianReeves]

Implementation note: TypeScript uses @std/semver; requires.host is a list

TypeScript code uses @std/semver from JSR. It is pure ESM with no runtime APIs, so it runs in Node, Deno, Bun, browsers and other WinterTC runtimes, and npm projects install it through JSR. From its source (1.0.8), it follows Cargo's caret rules (^0.1.3 is >=0.1.3 <0.2.0) and the same prerelease rule as the Rust semver crate: a prerelease satisfies a range only through a comparator with a prerelease on the same major.minor.patch. Readers in both languages therefore accept the same versions, and drafts still need an exact = requirement.

The two libraries separate comparators differently. Rust uses commas (>=0.4.0, <0.5.0); @std/semver uses npm syntax (a space for "and", || for "or"). A range string written for one does not parse in the other. So a range that crosses languages on the wire is a list of single comparators, all of which must hold:

"requires": { "host": [">=0.4.0-alpha.7", "<0.5.0"] }

The body, AGENTS.md, the morphir-cli versioning decision and the MEP draft in #922 are updated.

[DamianReeves]

Refinements from implementing describe, 2026-09-23

The first slice, morphir.extension.describe with a session fallback, is in finos/morphir-rust#223. Implementing it settled three points.

1. A refusal before initialize has its own error code: -32014 (not initialized). Before this change, the draft said a host falls back when a guest refuses "because the request came before initialize", but gave that refusal no code. A host now falls back on -32601 or -32014, and on no other error. Guests released before the code may refuse with another code, so a host may also recognize their refusal messages. The MEP draft lists -32014 with the other server errors, and the lifecycle section tells an extension to use it before initialization and after shutdown.
2. A fallback statement holds only what a session reports. Decision 9 above says the host "reads the same information from that session". It reads less: the identity, the one negotiated protocol version and the capabilities, with no requires and no critical. The protocol draft already said this, and the implementation follows the protocol. The result records whether it came from describe or from the fallback.
3. multiDocument: false is omitted on the wire, as the protocol requires. The example above writes it out. Read the example as illustration only.

Recorded as kb decision 0006 in the morphir-extensions bundle. It refines decision 9 of 0004 and does not supersede it. The MEP draft change and the decision are in #932.

The work is tracked as beads epic morphir-qjvu, with slices in this order:

1. describe;
2. must-ignore readers with critical lists and schema versions;
3. publish of process bundles;
4. the install probe;
5. the host compatibility suite;
6. the bootstrap host release, which retires the three transitional mechanisms.

[DamianReeves]

Status: slice 6 (bootstrap host release) is done.

• v0.4.0-beta.5 is released from chore: prepare v0.4.0-beta.5 release #947. It has 12 assets and is a prerelease. It is the first CLI with capability statements across publish, install and the must-ignore readers.
• ci: check bundles against morphir 0.4.0-beta.5 and drop the transitional skip morphir-rust#232 pins test:cli-release to 0.4.0-beta.5 and removes the TRANSITIONAL_FIELDS skip. All five bundles (avro, openapi, gleam, python, rust) publish, install and run through beta.5 in CI; Gleam is no longer skipped.

The legacy compile envelope cannot be retired yet. The CLI sends process and WASM frontends the legacy request (top-level documents), and three pinned frontends read only that shape: morphir-scala-elm v0.5.0-M08 (CompileRequest has no sources), and the python v0.2.0 and rust v0.1.0 guests, whose SDK predates SourceEnvelope. The Elm extension v0.3.1 reads both. The remaining order:

1. Release those three frontends so they read sources, and move the pins.
2. The CLI sends sources to every frontend, and compile_wire_request goes. This ships in a later CLI release.
3. After that release, the Rust SDK drops the legacy envelope.

[DamianReeves]

Status: #921 is delivered, and the three transitional mechanisms from #915 are retired.

• TRANSITIONAL_FIELDS skip: removed in ci: check bundles against morphir 0.4.0-beta.5 and drop the transitional skip morphir-rust#232. test:cli-release checks every bundle and skips nothing.
• Providers accept sources: extension/python/v0.3.0 and extension/rust/v0.2.0 (chore: release python extension 0.3.0 and rust extension 0.2.0 morphir-rust#234), and morphir-scala-elm v0.5.0-M09 (feat(elm-mep): accept the sources compile envelope morphir-scala#1077). chore: pin frontends that accept the sources compile envelope #955 pins them. The Elm extension v0.3.1 already read both envelopes.
• compile_wire_request: removed in feat(cli): send every frontend the sources compile envelope #956. The CLI sends sources to every frontend. This shipped in v0.4.0-beta.6. A process or WASM frontend that reads only the legacy documents no longer compiles with beta.6; the CHANGELOG names the affected versions and their replacements.
• SDK legacy envelope: removed in feat(sdk)!: accept only the sources compile envelope morphir-rust#249. SDK-built extensions now need CLI 0.4.0-beta.6 or later, and all five bundles pass test:cli-release through beta.6.

[DamianReeves]

Status: capability statements are now capability claim sets, made of claims. The reasons are in kb morphir-extensions decision 0007, "Extensions make capability claims": an extension makes claims about itself, and the host checks them at install.

• Rust side: feat(sdk,distribution)!: capability statements become capability claim sets morphir-rust#253 renames the SDK, distribution and daemon. The version-2 formats move to the next draft:

  Before (draft.1)	After (draft.2)
  statementVersion 0.1.0-draft.1	claimsVersion 0.1.0-draft.2
  statement	claims
  statementSource declared/probed	claimCheck unchecked/probed
  critical-path prefix statement.	claims.
  schemaVersion 2.0.0-draft.1	2.0.0-draft.2

  Writers emit draft.2. Readers still accept draft.1, including the shapes that 0.4.0-beta.5 and beta.6 wrote, and a mixed record is refused.

• Host side: feat!: capability statements become capability claim sets #979 updates the CLI output (Claims: unchecked / Claims: probed (...)) and the MEP draft docs. It also renames the kb design note to design/capability-claims.md and refreshes its "work in flight" section.

• Compatibility: hosts 0.4.0-beta.6 and earlier cannot read draft.2. Drafts promise no compatibility with each other, so decision 0007 accepts this.

Next, now that the old names cannot reach a bundle: the Elm extension publishes a real version-2 process bundle, and first-party bundles publish version-2 descriptors that carry claim sets, so multiDocument reaches installed providers.

The title of this discussion keeps the old name, for link stability.

[DamianReeves]

Status: v0.4.0-beta.7 is released. It is the first CLI that reads capability claim sets (draft.2), so the version-2 bundles work with a released CLI.

• The Elm extension v0.4.0 (feat(mep): answer describe and release a version-2 process bundle morphir-elm#1305):
  • It answers morphir.extension.describe from one source of truth.
  • It refuses lifecycle violations with -32014.
  • It ships a version-2 process bundle: raw executables, their .sha256 files, and morphir-elm-extension-0.4.0.bundle.release.json with the draft.2 claim set.
  • End to end, repository publish --bundle, then install (Claims: probed (describe)), then compile works.
  • beta.7 pins it. The host compatibility suite expects the describe probe for Elm and the session fallback for morphir-scala-elm.
• An install bug the release gates found (fix(cli): check a describe answer against version-1 claims like a session #984, fix(distribution): check a describe answer against converted claims like a session morphir-rust#261): a describe answer was compared exactly with claims the host converted from a version-1 index record. The converted claims carry host defaults for members the flat format cannot express, so Elm 0.4.0 installed through its version-1 descriptor was refused with incremental differs. Converted claims are now checked by the session rules, over a protocol version that both sides list. Supplied claims are still checked exactly. Released CLIs up to 0.4.0-beta.6 have the old strict check.

Remaining under this thread: first-party morphir-rust bundles (and morphir-scala-elm) publish version-2 descriptors that carry claim sets, so that multiDocument reaches installed providers.

[DamianReeves]

Status: first-party bundles carry capability claims (CLI v0.4.0-beta.8)

The follow-on work after the rename to capability claim sets is done. Every first-party extension now publishes a version-2 release descriptor. Each artifact in it carries the claim set (claimsVersion 0.1.0-draft.2).

Releases

• Morphir CLI v0.4.0-beta.8 (chore: prepare v0.4.0-beta.8 release #993):
  • An installed extension keeps frontend.multiDocument and the other nested members from its claims (fix(distribution,host): installed claims keep multiDocument and fragments morphir-rust#266). Before this, the CLI refused a selection of several files for an installed provider that claimed multi-document compilation.
  • The install lock pins the supplied claims at index.claims.
• WASM bundles from finos/morphir-rust (feat(packaging): extension bundles carry version-2 descriptors with capability claims morphir-rust#268, Bump braces and gulp in /morphir-elm #269): extension/avro/v0.2.0, extension/openapi/v0.2.0, extension/python/v0.4.0, extension/rust/v0.3.0, extension/elm-native/v0.2.0 and extension/gleam/v0.3.0.
  • Packaging reads the claims from the exact guest bytes that ship (mise run extension:claims <id>). Then it checks them against .github/extensions.toml.
  • The host never probes a WASM artifact, so it installs these with claimCheck unchecked.
  • Publishing these bundles needs CLI 0.4.0-beta.7 or later.
• Elm extension extension/elm/v0.4.0 (finos/morphir-elm): a version-2 process bundle, probed by morphir.extension.describe at install.
• morphir-scala-elm (feat(elm-mep): answer describe and release a version-2 bundle descriptor morphir-scala#1081): the provider answers describe. Before initialize and after shutdown it refuses requests with -32014. Each release writes a version-2 descriptor with five process artifacts. This ships with the next morphir-scala release (0.5.0-M10).

Verification

• finos/morphir CI runs CLI beta.8 against the pinned version-2 bundles. It checks the installed catalog claims, and it runs the Avro and OpenAPI example scenarios.
• finos/morphir-rust test:cli-release now pins beta.8 and covers elm-native (test(ci): run elm-native through the released CLI with a multi-file selection morphir-rust#272). It compiles a two-file --input selection in one request, where one module refers to a type in the other.
  • beta.8 compiles the selection and resolves the reference.
  • beta.7 refuses it: does not declare frontend.multiDocument.

Update, 2026-09-25: morphir-scala v0.5.0-M10

• morphir-scala v0.5.0-M10 is released on GitHub and Maven Central.
  • It is the first Scala release with morphir.extension.describe and a version-2 bundle descriptor, morphir-scala-elm-0.5.0-M10.bundle.release.json (feat(elm-mep): answer describe and release a version-2 bundle descriptor morphir-scala#1081).
  • With CLI beta.8, extension repository publish --bundle accepts it, and extension install --version 0.5.0-M10 reports Claims: probed (describe).
• The finos/morphir pin moves to M10 on the milestone branch for CLI v0.4.0-beta.9 (draft chore: prepare v0.4.0-beta.9 release #994). The host compatibility suite now expects the describe probe for morphir-scala-elm.
• The CLI now publishes and installs version-2 process bundles, for Elm and Scala. So the earlier gap, "process-bundle publish and install", is closed.

Open

• Release CLI v0.4.0-beta.9. This is the last delivery step. It brings the M10 pin to users, and it goes out when the release is ready.
• Spec open questions:
  • Questions 1 and 2 are answered in practice, but the spec does not say so yet. The host compares claims as JSON values. Publish never probes a WASM artifact; it is recorded as unchecked.
  • Questions 3 (claims covered by provenance or a signature) and 4 (an operating-system sandbox for process probes) wait on publisher authenticity and sandbox work.
• The claims format is still a draft: claimsVersion 0.1.0-draft.2 and descriptor schemaVersion 2.0.0-draft.2. Declaring it stable is a separate decision.

[DamianReeves]

Closing: this spec is delivered.

• The host, the SDKs and every first-party extension use capability claim sets.
• CLI v0.4.0-beta.9 (draft chore: prepare v0.4.0-beta.9 release #994) brings the morphir-scala-elm v0.5.0-M10 pin, with its describe probe, to users.

The items still open are tracked as release gates for Morphir CLI v0.4.0-beta.10, which cannot be cut until each one is resolved or formally postponed:

• open questions 1 to 4 above;
• whether the claims format (0.1.0-draft.2) stays a draft or becomes stable.

Each outcome is recorded as a Decision Record in the morphir-extensions knowledge base, or as a dated postponement with the condition that reopens it.