Skip to main content
The modules.v1 capability distributes modules: the adapter and environment modules Cyrnel loads at runtime. Modules travel as zstd-compressed tar archives and are verified by hash and manifest before registration.

Module types

See Module interfaces and the Module Specification tab for the module runtime contracts - a registry only affects their distribution, not their implementation.

Browse page

GET <capability URL> (e.g. /modules/v1):

Entry schema

An invalid entry fails the whole page with 400.

Query parameters

Cyrnel forwards query, type (adapter | environment), cursor, and limit. Filtering is advisory; Cyrnel never filters client-side.

Version descriptor

GET <entry.source>:
Version selection matches the definitions semantics: latest by default, maxSatisfying for a range, 404 ... no version satisfying '<constraint>'. on no match.

Archive format

The artifact is a zstd-compressed tar (conventionally .tar.zst) of at most 10 MiB, containing at least a module.json manifest and the module’s entry file(s):
module.json:
Required fields: id, name, version, description, type, main. Optional: engines, compatibility, summary. main must exist inside the archive.

Install & integrity checks

Cyrnel verifies, in order:
  1. Engine compatibility: engines.cyrnel must satisfy the running core version.
  2. Archive hash: downloaded bytes sha-256’d and compared to the descriptor hash: 400 Archive content hash does not match registry metadata hash.
  3. Manifest equality: manifest.version must equal the resolved descriptor version, and later manifest.id/manifest.type must match the stored record on updates.
  4. Id collision: installing an already-registered module id yields 409.

Updates

Updates re-resolve the stored source URL with the stored constraint (or latest for a manual update). The descriptor URL must therefore stay stable and serve an accurate latestVersion for the module’s lifetime on a server. On update Cyrnel re-downloads, re-verifies, swaps the module directory (keeping a .bak and rolling back on failure), and regenerates any adapter-generated services. Failed regenerations mark affected services stale: stale services can’t be enabled or invoked until re-synced. Modules that disappear can be marked missing; services from them become effectively disabled. See Install & update for the full behavior.
Last modified on August 25, 2026