Manifest and distribution reference

Contract versions

The public guest manifest is glixo.extension.json and follows the version 2 extension schema (schemaVersion: 2). It carries guest package identity, contribution declarations, requested grants, configuration, and component metadata. A manifest version is independent from CLI, SDK, catalog API, distribution metadata, and provider HTTP/WIT ABI versions.

The current distribution metadata envelope is glixo.module.json version 1; publisher signature canonicalization is version 2. These remain separate from manifest version 2 and provider HTTP/WIT ABI 3.0.0. The envelope may describe package bytes containing a v2 manifest and component, but it does not replace or redefine that manifest.

The field names differ by object: the guest manifest uses schemaVersion: 2, the outer glixo.module.json uses manifestVersion: 1, and publisher signatures use canonicalizationVersion: 2. The generic contribution WIT world is 1.0.0; the provider HTTP/WIT ABI is 3.0.0. These independent axes must not be substituted for one another. The generated reference links the exact schema and source identities. Treat generated files as read-only snapshots; regenerate them from their pinned source instead of editing the portal copy.

Host-issued handles

Public guests receive narrowly scoped handles for approved network endpoints, secrets, state, events, and invocation context. The host validates endpoint, package identity, account, contribution, grant, resource limits, cancellation, and lifecycle. Guests do not receive ambient filesystem, environment-secret, process-launch, or unrestricted network access.

Workflow extension nodes (development preview)

A workflow extension node binds an installed tools[] contribution into a workflow graph. The guest package still uses the existing signed manifest contract: each tool declares inputSchema, outputSchema, a safety class, and its component export. It requests the scoped tool.invoke permission for the specific tool ID. The Workflow Designer does not add a new manifest contribution kind.

Designer host API

The host derives the palette from verified, active tool installations that are eligible for the current account and workflow designer. Palette and configuration reads require WorkflowsRead; binding and configuration writes require WorkflowsManage. All routes require a Designer context.

The graph stores the node kind workflow-extension-node, host-issued bindingId, and optional inputBindings; it does not store display labels, package metadata, or node configuration. A binding entry maps a tool input property to a scalar value path, for example { "text": "$.text" }. Up to 32 distinct tool properties may be bound. Paths select scalar data from the current run input or an immediately preceding node's output; the host does not coerce missing or non-scalar values.

Node configuration is a host-managed resource, not graph data. The current schema exposes vault-backed inputs only for top-level string properties annotated x-secret; the host returns their slots redacted. Nested or non-string secret fields are not supported by this editor.

Drafts may be saved before every required input is connected. Publish validates that required inputs are provided by non-secret static configuration, bindings, or current secret-slot metadata. At execution, a missing or non-scalar path value fails that node with workflow_extension_input_binding_missing. Each published workflow revision freezes the selected package digest, contribution and schema, and configuration revision. A later package update does not rewrite an existing published revision; republish to select a newer version. Before invocation the host checks the current installation, grant, and pinned digest, then dispatches through the installed contribution invoker.

The current hosted workflow path has no per-invocation confirmation presenter. A tool that requires confirmation on every call—because its confirmation is invoke or its safety class is not readonly—cannot run automatically here until a workflow approval step exists. Read-only tools without per-call confirmation can use this path after the required installation and scoped tool grant are approved.

Text Stats source identity

The workflow-text-stats C# project README describes the read-only tools[] reference using the generic contribution world; corresponding READMEs and source paths for all four languages are listed in Source identities. Its text-stats tool accepts required text plus optional counting settings and returns word and character counts. All four signed language packages passed installed workflow tests using a source-built protocol-2 runner. Tests covered published configuration, grant revocation, package changes, secrets, cancellation, and checkpoints. Stable Glixo 0.7.8 ships protocol 1, so a newer app release is needed to run this example.

Support status

Support is qualified per language, contribution, host, platform, and package revision. A green compiler build proves that a component can be produced; it does not prove that Glixo can install and invoke it. See the pinned source and evidence table below.

SDK source and build matrix

The public SDK support matrix is the source of truth for language status and build recipes. Its companion runtime version contract lists the host protocol and WIT worlds. The generated source-identity table below links the pinned source and paths. Public main is pinned at 7052b3f954418cff91439236942a6623d75e8907; its latest official GitHub run, 36995827686, passed all five workflows and validated receipts for all 40 language components. The report SHA-256 is a2c8920a4ff588ab7d2f41b4762f0026011514dbc219e71fa5c65a3ae4ee4784. This verifies source builds, not app-release support.

Published CLI and SDK packages

TeamCity publication builds 4918 (CLI) and 4920 (SDK) used tested producer snapshots 4914 and 4916. Registry metadata, latest tags, package sizes, and digests were checked. Fresh consumers installed CLI 0.3.3 and scaffolded and checked examples in C#, Go, Rust, and TypeScript. Each check correctly reported artifact_not_built: the test stops after glxdev check, so this proves fresh install, scaffold, and check, not a fresh language build. The durable receipt is scripts/extensions-vnext/evidence/glxdev-0.3.3-teamcity-publication.json at app source commit 103c08ceee28c16e032d90726d0f1b928eff5f44.

The Go module and npm package are published. A fresh, unauthenticated npm consumer install passed with Node.js 22.14.0 and npm 10.9.2 using a new cache and blank npm configuration; the root, HTTP, and WIT imports exposed the expected symbols. The Go module also passed its public-proxy consumer test. The SDK remains Preview overall and is not yet supported in a released app. CLI versioning is separate from the SDK and compiler pins.

Source identities

This section is populated by the canonical export with full repository commits and source paths for the executable contribution references, SDK recipe matrix, and shared UI authoring assets. A source commit does not imply an accepted SDK, installed-host integration, or live provider/account acceptance. If an acceptance artifact is absent, the feature remains Preview source or Planned.

UI and shared controls

The Accessible Theme example has four language guests and a sandboxed settings panel at the supported web settings.extensions placement. Its preference state uses extension-scoped storage, and it does not apply a theme to Glixo Code. Windows isolation checks passed 7/7 in a source-built app. The signed package, account grant, and full action journey are still being checked. Linux custom panels are unavailable; mobile is unsupported.

The shared @glixo/extension-ui controls and theme bridge are authoring helpers, separate from the example extension. Native/shared host controls inherit the active Glixo theme. Isolated custom surfaces receive a versioned theme bridge, but arbitrary authored pixels remain under extension control. Mobile WebView support is listed only after the platform-specific isolation and lifecycle tests pass.