About the loader
The loader is the part of the harness that validates, installs, selects and pins process packages. It enforces namespaces and compatibility, refuses collisions, and resumes a Run with the version it was pinned to.
The default process ships as its own, separately versioned package and goes through the same public loader as any other process. Installing the product alone works.
How it works
- 1
Install
A trusted administrator installs a package with its identity, version and digest. The loader validates its schema and API compatibility and resolves its namespaced roles, facts, predicates and extensions. If a contract is unmet, it refuses activation and says precisely which.
- 2
Select
A process is selected explicitly and deterministically. Collisions are refused. There is no hidden default.
- 3
Pin
A Run in flight keeps the process version and digest it started with.
- 4
Upgrade
A new version applies to new Runs. Runs already under way stay pinned.
- 5
Resume
A paused Run resumes with its pinned version.
- 6
Uninstall
The process is removed without editing the product. Commands that depend on the process report that the package is missing.
Safety rules
- Workers cannot alter their own governing package or trust configuration. See Process contract.
- Process packages that carry code are trusted extensions, not sandboxed uploads.
- The loader defends against path traversal, runs hooks scoped and in order, and gives actionable errors when a capability is missing.
- It is not a native Claude plugin. The loader implements its own behaviour.
Configuration
A process entry in vinaya. is planned, naming the package and its version.
What gets logged
Events record meta.vinaya (the CLI version), meta.doctrine (the doctrine digest) and flow.version. See Event contract.