12. Glossary
These terms have the same meaning across the architecture views and accepted decisions. The glossary explains domain distinctions; component responsibilities remain in the generated directory in section 5, and exact fields and limits remain in ADRs.
12.1 Participants and authority
Section titled “12.1 Participants and authority”The role and identity contracts are defined by ADR-0005, ADR-0009, ADR-0010, ADR-0011 and ADR-0014.
| Term | Meaning |
|---|---|
| CLI owner | Party assembling the named application and establishing trusted code and configuration authority |
| Extension publisher | Party distributing an extension’s declarations and exact artifacts; publisher identity and code trust require owner-approved evidence |
| CLI operator | Person using or maintaining an installation within delegated rights; not automatically its owner or an authenticated corporate subject |
| Subject | Principal whose rights apply, qualified by its verifying authority; an explicit local context does not invent a verified subject |
| Actor | Independently bound person or application making a request on a subject’s behalf; a claimed client name is not this binding |
| Service credential | Credential a trusted adapter uses for a bound service operation; not automatically the caller’s identity or permission |
| Access domain | Owner-bound authority and policy namespace; not an endpoint selected by an extension |
| Authentication session | Core-owned verified identity context; its lifetime is separate from token rotation and permission validity |
| Security Broker | Integration boundary for identity, permissions and permitted discovery; it does not require a remote server |
12.2 Packages, commands and configuration
Section titled “12.2 Packages, commands and configuration”The publication, routing and configuration contracts are defined by ADR-0006, ADR-0007, ADR-0009 and ADR-0013.
| Term | Meaning |
|---|---|
| Extension | Independently published package with declared commands and execution requirements |
| Descriptor | Static validated publisher data describing an extension; exported from KCL, without executable configuration |
| Release | Exact envelope, descriptor and payload set bound by package identity, version and verified digests; a mutable tag is not an exact release binding |
| Catalog | Owner-admitted candidate identities, release references and source bindings; neither the artifact store nor a grant to every resource |
| Artifact trust | Approval of the publisher/package/content binding; integrity from a checksum alone is insufficient |
| Canonical command identity | Authority, package and stable command ID used across routes, aliases and interfaces |
| Command route / mount | Visible token path and its placement in the branded CLI tree; spelling is separate from canonical identity |
| Group / subcommand | A group organizes routes without a handler; an executable subcommand is a separately declared command with its own ID |
| Alias | Another direct route to the same command, with the same inputs, requirements and rights |
| Installation / activation | Installation records complete verified artifacts; activation publishes a validated configuration and command set |
| Command generation | Immutable complete set of built-in and extension bindings, targets and routes |
| Active profile | Published binding of one owner-configuration revision and one command generation; not a permanent access grant |
| Configuration as code | Reviewed, versioned configuration data; its authority comes from the approved publisher, not the repository or authoring language alone |
| Command projection | CLI or MCP representation of the same active command model, not another implementation |
| Machine eligibility / exposure | Eligibility declares machine compatibility; exposure is the owner’s separate choice to provide that command through MCP |
| Tool binding | Exact association of a machine tool name with a command and profile revision; an old name does not remap to a new release |
12.3 Execution and environment
Section titled “12.3 Execution and environment”These meanings follow ADR-0001, ADR-0002, ADR-0004, ADR-0008 and ADR-0015.
| Term | Meaning |
|---|---|
| Invocation | One immutable command or contextual-help request with pinned identity, inputs and context; its execution attempt has one final outcome |
| Executor | Mechanism running and supervising an execution instance; different from the environment needed by its code |
| Language runtime / environment | Exact selected interpreter or engine and verified dependencies; not the lifecycle or arc42 runtime view |
| Runtime provider | Trusted integration resolving and preparing that environment within its own authority |
| Foreground execution | Work whose lifecycle belongs to the requesting scope through finalization; a persistent MCP host does not make it a detached job |
| Execution profile | Explicit host-trusted execution or a verified set of enforced resource/process restrictions; different from the active configuration profile |
| Host-trusted execution | Admitted code runs with its OS account’s ambient authority; core checks do not sandbox direct system calls |
| Final outcome / command result | The core’s committed execution outcome and the command’s optional or required typed data are different records; valid result data alone is not final success |
12.4 Protected actions and effects
Section titled “12.4 Protected actions and effects”These terms follow ADR-0005, ADR-0012, ADR-0014 and ADR-0016.
| Term | Meaning |
|---|---|
| Core operation / access action | An operation provides a registered facility; an action expresses required authority over an actual resource |
| Admission | Final core check before protected work begins; earlier discovery or an advisory permission query does not replace it |
| Task authority | Trusted bounded authority for a task; not a process scope, prompt, statement of purpose or arbitrary tool argument |
| Delegation | Authorized narrowing to a bound child actor while retaining root and ancestor constraints |
| Reservation | Atomic holding of finite task allowance before admitted work; uncertain effects retain the outstanding hold |
| Controlled effect | Concrete external action governed by an admitted operation’s binding and commitment contract; not every direct side effect of an ordinary process |
| Effect identity | Core-owned identity for one intended effect, separate from transport request and invocation IDs |
| Effect uncertainty | No authoritative evidence of whether an admitted action happened or what it consumed; neither failure nor rollback can be assumed |
| Reconciliation | Authorized determination of a recorded effect’s status using supported evidence; it does not replay or reopen the original invocation |