libraryPackage manifestv2.1.4

lib.lssm-os-runtime

Deterministic, provider-neutral planning and execution kernel for LSSM OS.

@lssm-tech/lib.lssm-os-runtime
Source, release and verification context

Source snapshot bcc79fcc · Declared package version 2.1.4. This page combines the checked-in package guide and manifest; commands and runtime behavior were not executed in this review.

Package source ↗ Manifest ↗
webserverbunnodebrowser
EXPLORE THE PACKAGE

See where this package fits.

Follow a declared connection, inspect an import, then open the source guide when you need the detail.

THIS PACKAGElib.lssm-os-runtimeplatform

Arrows point from a package to its direct dependency. Each count is derived from the captured manifests.

8 déclarations · les 6 premières affichéesSELECT TO INSPECT

@lssm-tech/lib.lssm-os-runtime

Provider-neutral deterministic planning and execution kernel for LSSM OS.

The runtime compiles desired and observed revisions into canonical plans, binds them to SHA-256 digests, verifies exact non-stale Connect authorization, and executes idempotent steps under fenced leases. It also provides drift, reconciliation, rollback, decommission, recovery, receipt, and replay primitives.

Every compiled plan carries an exact/range/stale/unavailable minor-unit cost record. Unknown or stale costs add a mandatory economic review requirement. When a coordinated execution program is supplied, exact integration-SHA and evidence-bundle references are copied into the plan digest.

It does not call provider SDKs, own credentials, or issue authorization. Concrete providers and durable state backends implement injected ports.

Public entrypoints

  • @lssm-tech/lib.lssm-os-runtime
  • @lssm-tech/lib.lssm-os-runtime/planning
  • @lssm-tech/lib.lssm-os-runtime/execution
  • @lssm-tech/lib.lssm-os-runtime/state
  • @lssm-tech/lib.lssm-os-runtime/authorization
  • @lssm-tech/lib.lssm-os-runtime/ports
  • @lssm-tech/lib.lssm-os-runtime/runtime-node
  • @lssm-tech/lib.lssm-os-runtime/runtime-node/scalability
  • @lssm-tech/lib.lssm-os-runtime/runtime-node/v3-execution-service

Runtime Node V3 execution service

createRuntimeNodeV3ExecutionServiceV1 is the frozen exactly-once V3 execution composition over injected ports (dispatch authority, operation state, provider receipts, provider router, clock): an exact provider-receipt replay finishes without a new effect; otherwise authorizeDispatch gates one executeProviderStepV2 call, the receipt is appended and verified, and the operation completes with a digest-bound receipt under version, attempt, claim and fencing CAS. Terminal replays return the existing receipt; any ambiguity moves the operation to indeterminate custody with a deterministic recovery ref. Result codes keep their existing agent_host.* valeurs.

Runtime Node V2 additive trust surface

The runtime-node subpath adds signed, node-bound and tenant-bound work orders without changing any V1 planning or execution API. It exposes canonical Zod schemas and digest helpers for node descriptors, registrations, heartbeats, attestations, qualification bindings, provider bindings, claims, provider receipts, and completions.

It also exports the provider-neutral LssmOsOperationClientV1 port and its scope, request, result, and error-surface types. UI libraries depend on this lower-layer port; HTTP clients implement it in integration packages.

Execution is fail-closed:

  • Connect remains the only signed work-order issuer and verifier.
  • Eligibility requires exact current registration, heartbeat, attestation, qualification, source, environment, provider, adapter, profile, and capability digests.
  • The deterministic eligibility evaluator produces an unsigned proposal only. Claim persistence requires a signed, current authority decision through a mandatory injected RuntimeNodeEligibilityVerifierPort.
  • Provider routing is exact and deterministic; it never falls back to a nearby adapter or profile.
  • Claims are atomic, leased, fenced, replay-bound, and safe across process restart when the injected state implementation is durable.
  • Receipt V2 binds tenant, workspace, environment, node, provider, order, claim, lease, fence, attempt, plan, authorization, and effect identities.
  • Durable receipt append requires a mandatory external ProviderStepReceiptVerifierPort. Verification happens before mutation, followed by a fresh trusted-clock sample and exact authority-state recheck. Synchronous failures, invalid return values, hostile thenables, timeouts, and late settlements fail closed without mutating receipt state.
  • Exact replay is offline only after the complete durable receipt/index tuple, stored order, and preserved claim snapshot revalidate. Takeover claims may continue a prerequisite DAG from those trusted historical receipts, while a stale claimant cannot append.
  • Completion binds the exact ordered durable receipt digests and their deterministic unique evidence projection. Success requires every ordered step to succeed; other terminal statuses require exact partial evidence. Provider receipt time is nondecreasing across the step DAG, and completion cannot predate any durable receipt.
  • Public wire schemas reject unknown fields, non-canonical timestamps, credential-shaped material, and raw secrets.

The included in-memory work-order and receipt ports are reference adapters for local use and tests. Their restart-sharing state is a frozen opaque token; durable maps and authority snapshots are adapter-private and cannot be caller-populated. The ports require eligibility/receipt verifiers and a trusted runtime clock; claim, receipt, renewal, and completion authority time never comes from caller or provider payloads. Production compositions must inject transactional durable implementations of RuntimeWorkOrderPort and RuntimeWorkOrderReceiptPort.

The runtime-node entrypoint also exports a backend-neutral SQL state machine for those ports. It owns canonical serialization, hydration, verifier/clock TOCTOU checks, claim and receipt CAS behavior, and completion validation; concrete SQLite, PGlite, and Postgres adapters retain transaction and migration authority. SQL rows are never trusted merely because their digests can be recomputed.

The additive RuntimeNodeRegistryPortV2 scopes descriptor reads to the full tenant/workspace/environment/node tuple. Its SQL implementation stores registration, heartbeat, attestation, and provider-qualification histories as immutable evidence. Writes serialize through a per-scope lock, validate every canonical digest and cross-record binding, reject sequence or timestamp rewinds, and make evidence from an older registration unavailable until the new registration is freshly attested and qualified. V1 remains available for source compatibility but must not bypass tenant isolation in a multi-tenant durable adapter.

Every published entrypoint resolves only to files shipped under dist for Node, Bun, browser, and declaration consumers. Maintainers run bun run pack:verify before publishing; it installs the real npm tarball and its strict dependency closure in a clean temporary consumer, requires a clean npm ls --all, imports every entrypoint, compiles a clean consumer against every public declaration target, replays the canonical SHA-256 vector, and rejects workspace links, source exports, test artifacts, or private state/resolver declarations. The optional coordinated-program input is a minimal structural evidence view, so a complete CoordinatedProgramSpecV1 remains assignable without pulling the agent runtime and evaluation peer graph into production installs.

Runtime Node V3 qualification authority

V3 is additive to V2 and introduces strict purpose: "standard" and purpose: "emergency_cleanup" work orders for isolated live canaries. Standard orders bind one exact preallocated claim, lease, fence, attempt, provider binding, singleton step, plan, and Connect evidence tuple. Cleanup orders are decommission-only and bind the immutable provider resource identity, ownership, generation, creation observation, and separate cleanup reservation.

QualificationAuthorityStatePort is the single transactional seam for V3 reservation, permit, settlement, and custody transitions. Amounts are integer EUR micros with fixed daily caps of 800,000 normal, 200,000 cleanup, and 1,000,000 total. CleanupObservationAttestationV1 expires within 30 seconds; reservation digests identify immutable scope, operation, day, kind, amount, and pricing. Mutable held, dispatched, provisional, settled, evidence, and state fields evolve under that stable identity and are never part of the digest. observer and mutator trust keys must differ and its nonce is single-use. LssmOsOperationStatePort creates durable operation records before fallible authority or queue I/O; indeterminate remains recoverable, never an error wire variant. The included in-memory authority is reference-only.

projectLssmOsOperationSurfacesV1 is the canonical F3 read projection for REST, CLI, MCP, SDK, and UI shells. Every nonterminal durable operation maps to HTTP 202 and CLI exit 5, carries the same request and receipt digests, and includes a scope-qualified operation URL. Terminal results and closed errors retain one canonical projection or error digest across every surface. readLssmOsOperationSurfacesV1 bounds and validates the injected durable read, rejects substituted scope or operation identity, and contains missing, malformed, timed-out, and failed dependencies without inventing completion. Application shells remain responsible for authentication and transport; they must consume this projection rather than redefine status or error mappings. Transport clients must pass untrusted success and error bodies through parseLssmOsOperationSurfaceV1 or parseLssmOsOperationSurfaceErrorV1. These parsers revalidate the closed shape, canonical digest, terminal posture, retry posture, and exact scope-qualified operation URL before recreating the five surface wrappers.

QualificationAuthorityOrderReadPortV1 is the deliberately smaller runtime surface for loading an already-issued standard order by its full scope, operation, ID, and digest. Its additive V2 surface also dereferences the exact emergency cleanup order so restart/recovery does not depend on process memory. Agent Host may receive this reader, but never the issuer or mutable qualification authority.

Runtime scalability ports

The additive runtime-node/scalability subpath freezes nine provider-neutral ports for distributed cache, coordination, durable queues, event streams, ingress, topology state, capacity observation, scale planning, and one-step topology execution. Every stateful call repeats the exact topology generation, component/profile, and adapter/server/client digest binding. Queue claims and coordination fences are transport evidence only and can never authorize a Runtime Node effect.

Topology transition state begins only through recordObservedTransition; later lifecycle movement uses exact-state CAS. This makes transition initialization an explicit durable operation instead of an adapter-specific method hidden outside the frozen port.

verifyAuthorizedTopologyIntentV1 rechecks the exact V3 operation tuple, signed work order, trusted deadline, and Connect decision before a controller may persist topology authorization evidence. It deliberately does not consume the dispatch fence; executeAuthorizedTopologyStepV1 rechecks the same authority and remains the only boundary that atomically consumes dispatch and invokes one observable effect.

TopologyExecutorPortV2 adds the exact prior transition receipt to that boundary, while retaining TopologyExecutorPortV1 for compatibility. The provided createProviderTopologyExecutorV1 implementation projects the signed V3 order into the existing exact provider router, accepts only the plan step's component, sequence, prerequisites, and compatible lifecycle action, and returns one digest-bound topology receipt that appends exactly that step. Provider failures and uncertain calls remain indeterminate provider evidence; they never become fabricated topology completion.

All adapters return a closed ok | already_applied | conflict | unavailable | indeterminate result. The operation-specific conformance wrappers own and freeze dependency outputs, verify canonical contract digests and exact scope bindings, contain synchronous errors and hostile thenables, and enforce a bounded deadline without returning upstream error text. Topology execution also reloads the durable running operation and verifies its existing Connect authority before and after the external verifier call. SQL remains authoritative; cache misses and transport uncertainty stay recoverable through durable state rather than being promoted to authority.

QueueClaimEnvelopeLookupPortV1 is the additive fenced read boundary for a consumer that already holds a current Queue Claim. It returns the immutable envelope only when the stored claim digest, queue fence, visibility lease, scope, topology, and capability binding still match. The envelope and queue claim remain transport context; neither authorizes an effect.

Authority flow

  1. Stamp and validate desired and observed state.
  2. Compile a deterministic plan and expose its exact digest for review.
  3. Obtain a decision from ContractSpec Connect outside this package.
  4. Apply only when decision, scope, revisions, expiry, and digest match.
  5. Persist append-only receipts and replay them to verify the outcome.

The ports surface owns ProviderDiscoveryPortV1, ProviderDiscoveryScopeV1, ProviderResourceSnapshotV1, and ProviderDiscoveryPageV1. These extract the existing provider-neutral discovery shape; typed provider adapters specialize family, scope and ownership without granting effect authority.

The additive QualificationAuthorityOrderReadPortV3 can discover the single issued standard order for an exact tenant/workspace/environment/operation tuple. This allows server recovery after issuance without accepting an authority digest from a member request. Absence, ambiguity and malformed or cross-scope payloads return no order. A recovered order still requires current Connect verification and dispatch authority before execution.

Connect-owned V3 lifecycle drafts

The runtime-node surface exports RuntimeV3LifecycleDraftV1 and RuntimeV3IssuedLifecycleV1. A draft contains unsigned standard and cleanup orders, canonical reservations and the accepted operation. Connect supplies issuer, signature, authorization and issuance-time fields, including the standard step's bound authorization/effect digest. The provider-neutral Connect library implements issuance and verification; Runtime state remains the owner of budget, issued-order, claim and completion transactions. Cleanup custody has no standard-order expiry.

The additive ./planning-handoff-digest subpath supplies stable serialization, raw SHA-256 planning-payload digests and derived IDs for the metadata-only handoff protocol. Builder planning compatibility exports forward to these exact functions; these helpers perform no execution or authority resolution.

Generic control-plane services

The control-plane entry owns existing generic scheduling, workers, state ports, topology controllers and pure handoff acceptance. Its narrow subpaths preserve the original module surfaces. Builder candidate and governed patch orchestration belong to the Builder ControlPlane module; this runtime does not depend on that module or Builder/Connect implementations.

The canonical subpath forwards its existing synchronous JSON digest helpers to @lssm-tech/lib.crypto-utils/canonical, preserving runtime imports and digest meaning while allowing domain contracts to use the pure foundation implementation.

The ./catalog-locator-node subpath owns validateLssmCanonicalLocatorInWorkspace, which applies the spec's lexical locator gate and then confirms through realpath that a catalog locator stays inside the supplied workspace root. Its browser condition returns locator.node_only. It moved here unchanged from @lssm-tech/lib.lssm-os-spec/context/catalog-locator-node so the spec stays free of I/O.

Control-plane skill verification

The control-plane/skills entry and its signer and verifier leaves own the existing supplied-key WebCrypto signing and manifest trust verification. Canonicalization, publisher trust, version bounds, artifact digests and expiry checks are unchanged. Keys are caller supplied; verification does not issue an installation grant. Pure schemas and validators remain in lssm-os-spec.

Hook Authority

The four control-plane/hook-authority leaves (base, -digest, -validation and -reference-adapter) own the original V1 protocol and supplied-port reference adapter. Legacy contracts-spec leaves forward these same objects, including the opaque in-process restart token. No registration or verification grants authority.

Build preparation bundles the four runtime entries, strips private Hook Authority JavaScript and limits declarations to the public closure plus records and opaque restart-token support. Mutable maps and test helpers cannot ship. Historical private development-only helper paths remain source-only and are omitted from publishConfig. Packed consumers must verify both canonical and facade identity.

Declared capabilities.

Lib Lssm Os Runtime

Deterministic, provider-neutral planning and execution kernel for LSSM OS.

Use it to

  • Adopt deterministic, provider-neutral planning and execution kernel for lssm os

Requires

  • TypeScript

Choose another boundary when

  • The @lssm-tech/lib.lssm-os-runtime package constraints do not match the target runtime or platform.

@lssm-tech/lib.lssm-os-runtime

@lssm-tech/lib.lssm-os-runtime/authorization

@lssm-tech/lib.lssm-os-runtime/canonical

@lssm-tech/lib.lssm-os-runtime/catalog-locator-node

@lssm-tech/lib.lssm-os-runtime/execution

@lssm-tech/lib.lssm-os-runtime/planning

@lssm-tech/lib.lssm-os-runtime/ports

@lssm-tech/lib.lssm-os-runtime/runtime-node

@lssm-tech/lib.lssm-os-runtime/state

@lssm-tech/lib.lssm-os-runtime/runtime-node/v3-execution-servicecreateRuntimeNodeV3ExecutionServiceV1

Imports and export paths.

42 entries

These are package-manifest entry points. Named symbols listed above come from the capability catalogue; this is not an exhaustive TypeScript symbol reference.

42 imports · 35 affichés

Dependencies and related packages.

Runtime dependencies 8
compare-versions
catalog:data
zod
^4.5.4
Development dependencies 7
typescript
^7.0.2

Package scripts.

Commands declared by this package. Review its setup requirements before running them; no command here was executed by this review.

publish:pkgbun run pack:verify && bun publish --tolerate-republish --ignore-scripts --verbose
publish:pkg:canarybun publish:pkg --tag canary
buildbun run clean && bun run build:bundle && bun run build:types
build:bundlecontractspec-bun-build transpile && bun scripts/prepare-hook-authority-package.ts --javascript-only
build:typescontractspec-bun-build types && bun scripts/prepare-hook-authority-package.ts --declarations-only
cleanrimraf dist .turbo
lintbun run lint:fix
lint:fixnode ../../../../scripts/biome.cjs check --write .
lint:checknode ../../../../scripts/biome.cjs check .
pack:verifybun run build && node ./scripts/verify-pack.mjs
testbun test
typechecktsgo --noEmit
Votre vue

Make room for your context.

Shape the presentation around this moment. You can change it whenever you need.

Votre contexte

The different parts of you

Choose a starting point

Un mélange utile de contexte, de visuels et de guidage discret.

Tune each dimension
Each dimension can change independently. Product permissions and available actions stay unchanged.

Support the way you begin and return

Tune your support

Confort de lecture

Choisir votre langue

La langue de l’interface change uniquement le texte. Les marchés, les prix et les parcours conservent leurs propres paramètres.

Couverture des traductions

Une partie du contenu est affichée en anglais.

Navigation151
Graphe616
Catégories378
Portfolio833
Exemples2 035
Aperçu de la source1 542

D’autres traductions seront ajoutées à mesure que le contenu sera relu.

Cette préférence est enregistrée dans ce navigateur.

Rechercher sur le site

Des points de départ utiles

Aucun résultat. Essayez une expression plus courte, un nom d’opération ou un autre périmètre de recherche.

UN PEU DE PLACE POUR EXPLORER

Trouvez quelque chose à explorer.

Ouvrez un aperçu détaillé sur cette page, essayez une autre perspective ou suivez le détail vers sa propre page.

Fonctionnement des aperçus et des commandes
01

Regarder avant de partir

Survolez un lien ou sélectionnez-le avec Tab pour voir un aperçu. Cliquer sur le lien d’origine ou appuyer sur Entrée ouvre toujours sa destination.

02

Rester dans le contexte

Entrez dans l’aperçu pour explorer ses sections. Depuis un lien sélectionné, utilisez Alt + ↓ pour y entrer au clavier. Échap le ferme.

03

Ouvrir les possibilités

Les lignes dépliables, les choix de perspective et les commandes mises en évidence révèlent davantage. Votre vue adapte le confort de lecture et le contexte exploré.

Un bouton séparé pour voir de plus près

Affichez de petits boutons d’aperçu à côté des liens quand l’espace le permet. Touchez l’œil pour examiner ou le lien pour y aller directement. Ce choix reste dans cet onglet.

Aucun historique de navigation n’est collecté. La réduction des animations suit votre appareil et Votre vue.