8. Crosscutting Concepts

These concepts govern several building blocks and scenarios. They explain how the accepted decisions work together; exact data contracts, limits and error codes remain in the defining ADRs.

8.1 Command model, CLI and MCP

An extension declares a command once. Rukh validates its canonical identity, inputs, requirements and result contract, then constructs the supported presentations: CLI routes for people and explicitly approved MCP tools for agent applications. Both use the same semantic validator, invocation admission and execution contract. MCP supplies typed values directly; it does not construct a shell command or infer a result from terminal output. ADR-0002, ADR-0006, ADR-0013

Components and decisions

CLI user · Command model and dispatcher · Extension loader · Lifecycle owner · Profile and resource state · Agent or machine client · CLI adapter · MCP adapter

ADR-0002 · ADR-0004 · ADR-0007 · ADR-0009 · ADR-0010 · ADR-0013 · ADR-0014

Publisher-side KCL produces a static JSON descriptor independently checked by the client. Static inspection, base help and tool listing do not execute extension code or prepare a runtime. CLI aliases preserve one command identity and cannot change its rights. Existing CLI-only declarations remain usable without automatic conversion into tools; passthrough programs need a separately declared, admitted machine contract. ADR-0002, ADR-0006, ADR-0013

Transition	Shared rule
Discovery → installation	Visibility is not publisher approval or permission to run code
Installation → MCP exposure	Only compatible active commands selected by owner policy become tools
Listing → invocation	Current caller, task, input, access and execution requirements are checked again
Update → next call	An exact tool binding cannot silently select another release or contract

Exposure is separate from authority. Tool descriptions, result text and client-supplied names cannot become owner instructions. Administrative actions such as installing code, changing policy or issuing authority are not automatically exported as ordinary agent tools. ADR-0007, ADR-0013

8.2 Identity, credentials, access and task authority

The core binds the subject whose permissions apply, the actor making the request, the command and its exact release. These bindings come from trusted entry points and registered integrations. Authentication establishes identity; it does not itself authorize a command. Protected credential references stay under core control, and token rotation neither changes the invocation’s subject nor extends its authentication horizon. ADR-0005, ADR-0011, ADR-0014

Security Broker is the common integration boundary for identity, access decisions and permitted extension discovery. A small CLI can use a static catalog and explicit local rules; organizational protocols and owner-registered custom adapters preserve the same boundary. A required authority that fails or becomes unavailable never causes a permissive local fallback. ADR-0005, ADR-0009

Task authority narrows the subject’s current rights to an approved purpose expressed as enforceable actions, resources and limits. Trusted presets, an authorized person’s approval or registered issuers establish it; free-form purpose text and agent claims do not. Delegation can only narrow authority. Calls, descendants and participating cores share the task’s accounting rather than receiving fresh allowance through a new process or connection. ADR-0014

Final admission combines the pinned invocation with current policy, identity, task validity and required audit. Revocation prevents new admission; a stale response cannot clear an observed invalidation. A still-running invocation does not retain revoked access, and revocation cannot undo an external action already admitted. ADR-0012, ADR-0014

8.3 Execution, environments and confinement

Executor kind, execution lifetime and language runtime are independent choices. The initial mapping supervises foreground processes; a longer-lived MCP application can own several such invocations without detaching extension jobs. Known compatibility and access checks precede environment preparation. A trusted runtime provider obtains an exact authorized plan and a verified environment; an extension cannot supply an arbitrary installer. ADR-0001, ADR-0004, ADR-0008

Publisher trust admits code; it does not restrict its direct OS access. An explicitly selected host-trusted profile keeps ordinary trusted native programs useful for small teams. A confined profile requires its declared restrictions to be established before extension or interpreter startup. Missing enforcement rejects the invocation instead of selecting a weaker profile. Permissions on mediated core operations remain necessary in either case. ADR-0015

Environment preparation has its own authorization and ownership. Sharing a prepared environment does not share another caller’s rights. Releases and environments remain referenced through execution and cleanup; uncertain termination retains protective references until authorized reconciliation proves that use ended. ADR-0007, ADR-0008

8.4 Results, interaction, logs and audit

Completion data, the final invocation outcome and delivery to a caller are different facts. A success report becomes a successful outcome only after required execution evidence, audit and cleanup agree. The negotiated machine-result contract supplies bounded text or structured data; stdout and stderr are not parsed as control messages or guessed to contain that result. Losing a reply does not prove that the command or its effects failed. ADR-0002, ADR-0003, ADR-0013

The core owns terminal rendering and interactive input. Standard dialogs and managed views use the same ownership and cancellation rules; redirected command output preserves its byte semantics. The initial MCP path is noninteractive: a required unsupported interaction prevents exposure or admission, while an optional request receives its defined unavailable result. The host never invents an answer or borrows protocol stdin as terminal input. Its MCP streams and the extension’s private control channel remain separate. ADR-0002, ADR-0013

Information	Handling
Command data	Delivered through the declared data/result path; never interpreted as authority
Diagnostic logs	Bounded, attributed by the core and separate from command/protocol stdout; overload may cause counted loss
Mandatory audit	Trusted evidence required by policy; failure can prevent an action or a successful outcome
Interaction responses	Bound to their intended request; uncertain delivery does not permit replay, and answers are not lossy log events

Logs cannot forge core metadata or prolong shutdown. An ordinary dialog answer is not authorization for an effect, and a client claiming human confirmation does not establish a trusted approval. ADR-0002, ADR-0016

8.5 Configuration, publication and compatibility

The CLI owner fixes trusted implementations when assembling the application. Profiles select and narrow admitted implementations; ordinary extension data, environment variables and non-delegated flags cannot register privileged code or replace access policy. The local baseline needs no corporate identity or separate database service. Additional integrations do not change this authority hierarchy. ADR-0009, ADR-0010

One active profile revision binds owner configuration and the complete command generation. CLI routes and the approved MCP projection are validated and published together. Calls capture exact bindings and protective references; updating a profile changes new lookups without rewriting a running invocation. An obsolete MCP name is rejected rather than routed to a replacement. Current authorization still applies to further protected actions of an existing call. ADR-0007, ADR-0012, ADR-0013

Descriptor formats, release envelopes, interaction contracts, process bindings, core operations, runtimes and MCP adapters have independent compatibility checks. A package version match does not prove that required features are supported. Unknown mandatory requirements cause a defined refusal; neither an update nor a provider failure silently changes the selected command or weakens its requirements. ADR-0002, ADR-0003, ADR-0006, ADR-0008, ADR-0013

8.6 Effects, uncertainty and recovery

A consequential operation governed by the effect contract binds its actual implementation, inputs, resource, recipient and conditions to trusted authority. Final admission atomically consumes the one-use permit, reserves the applicable task budget and records dispatch intent before the external action begins. Invocation IDs and transport request IDs are correlation values, not effect identities or permission to repeat work. ADR-0014, ADR-0016

Cancellation has one accepted cause, and finalization has one non-renewable budget. Neither a late message nor a second failure restarts cleanup or replaces a committed outcome. Uncertain publication, termination and external effects remain explicit and retain their necessary records, reservations and references. Recovery inspects the existing bound state; it does not automatically repeat a command, issue replacement authority or claim rollback. ADR-0003, ADR-0004, ADR-0007, ADR-0016

An authorized reconciliation operation may later establish effect evidence, including through a service contract that demonstrably prevents a second effect. It cannot reopen the original invocation or rewrite its outcome. These guarantees apply to the controlled boundary; arbitrary direct actions of host-trusted native code are not covered merely because the process is supervised. ADR-0015, ADR-0016

8.7 Data ownership and lifetime

Data has different authority and retention rules even when stored on one machine. Publishing a catalog is not permission to publish its private identity mappings, and retaining an effect record is not permission to retain its secret payload.

Data	Authority, handling and lifetime
Release declarations, catalog entries and artifacts	Publisher or owner-supplied data, validated before use. Public distribution is possible, but discovery still obeys the selected visibility policy; cached bytes do not establish current trust or access
People, groups and access rules	Owner-controlled declarations or private provider data. Public catalog distribution does not require publishing group membership or private policy; passwords and tokens are not configuration content
Credentials and secret input	General sign-in, service and registry credentials remain core-owned; issuing a limited credential to an extension requires a separate authorized operation. Secret input reaches only its authorized invocation and stays out of core logs and persisted view state; ordinary native code must also honor the secret-handling contract
Command input, output and diagnostics	Invocation data, not instructions to the core or a grant. Arguments and environment values are not captured in logs by default; known-secret redaction cannot reliably recognize every sensitive string emitted by an extension
Profile, task, budget and effect records	Protected coordination evidence with its own ownership and recovery rules. Retain live and uncertain records/references; corruption or unavailable required state prevents affected admission instead of creating fresh allowance

These distinctions follow ADR-0002, ADR-0006, ADR-0007, ADR-0009, ADR-0011, ADR-0014 and ADR-0016. A sensitive parameter marker suppresses diagnostic disclosure; it cannot hide command-line arguments from the OS. The effect ledger stores bounded safe metadata and protected references; sensitive reconciliation payloads, if needed, require separately protected immutable storage with its own access and retention. No general archival or compliance policy is implied.

8.8 Bounded work and capacity

Limits apply at their declared ownership boundary: invocation handles per core, installation and preparation work per profile, transport queues per session, and task costs across the task’s shared hierarchy. These are different controls. Starting another core does not grant a second copy of a shared task budget, while a per-core concurrency limit is not a machine-wide resource quota. ADR-0003, ADR-0007, ADR-0008, ADR-0010, ADR-0014

Reserve capacity before admitting work or writing prepared state. Apply the smallest relevant deadline and preserve the original finalization budget. Logs and replaceable visual updates have their declared overload behavior; cancellation, completion, answers and mandatory audit cannot be discarded as ordinary logs. Full storage refuses new preparation or effects without collecting live resources or unresolved effect records. Larger limits require an explicitly supported and tested profile, not a package’s request for more capacity. Exact bounds remain in their ADRs. ADR-0002, ADR-0003, ADR-0008, ADR-0010, ADR-0016