7. Deployment View

This view maps logical building blocks to execution and storage boundaries. It describes the selected local arrangement and optional integrations, not a verified installation topology for every operating system.

7.1 Application and execution boundaries

The host embeds Rukh and trusted integrations. Foreground extensions use supervised child processes; scripts use exact verified runtimes. Managed process IPC has a private control channel separate from stdin/stdout/stderr. Only the core renders terminal recipients; redirected streams preserve bytes. ADR-0003, ADR-0010

Components and decisions

CLI user · Named CLI application · Profile and resource state · Extension process · Approved artifact sources · External identity service · External permission service · Protected resources · Agent or machine client

ADR-0001 · ADR-0002 · ADR-0003 · ADR-0004 · ADR-0005 · ADR-0007 · ADR-0009 · ADR-0011 · ADR-0012 · ADR-0013 · ADR-0015

Logical element	Placement and boundary
Branded host, embedded core and admitted integrations	Application code assembled by the owner; logical responsibilities do not imply separate services
CLI and optional local MCP adapter	Entry paths in that application; MCP stdio is distinct from the private extension channel
Ordinary native or scripted extension	Supervised process for one foreground invocation; script runtimes and dependencies use a verified selected environment
Profile and coordination state	Owner-controlled storage shared by the core processes that use the same authority; credentials use their supported protected storage binding
Artifact, identity, permission and resource systems	External dependencies reached only through selected bindings; identity and permission servers are optional

This placement follows ADR-0001, ADR-0008, ADR-0010 and ADR-0013. It does not prescribe service replicas, containers, network subnets or an implementation package layout.

7.2 Persistent state and resource ownership

Persistent credentials require a supported protected store and coordinated metadata. Explicit volatile mode is process-local; an unavailable required store never silently selects it. Shared profile coordination does not require a new daemon. Managed environments can coexist; borrowed tools are not deleted by Rukh. ADR-0007, ADR-0008, ADR-0011

Credential, task, budget and effect records have different meanings even when backed by the same protected local store. The store does not require a server. Durable effect records preserve uncertainty across host restart; they do not resume or repeat the original command. ADR-0011, ADR-0014, ADR-0016

Local files still need an actual storage contract: OS-held locking, durable publication and recovery, with capture/reference acquisition coordinated against collection. A shared or network filesystem is not implicitly supported merely because it exposes paths. Its adapter must demonstrate the same guarantees. Staging and retained old versions count toward capacity; exhaustion refuses new work rather than deleting a running invocation’s files. Incomplete preparation and uncertain termination remain visible across restart. ADR-0007, ADR-0008

7.3 Local configuration and optional integrations

The local baseline can host CLI and MCP stdio in one branded application with file-backed catalogs, policy and protected coordination records. Identity services, remote authorization and HTTP hosting are independently selected integrations. Shared state requires actual locking and crash consistency; several processes do not receive independent copies of a shared task budget. ADR-0009, ADR-0013, ADR-0014

Selected arrangement	Required resources and dependencies
Local catalog, local rules and native or preinstalled execution	The branded application, approved release files, a compatible executor/environment and the selected local state bindings; no mandatory runtime manager, remote identity service or client-side KCL compiler
Lazy runtime preparation	An owner-registered provider, approved source access, staging capacity and the exact preparation plan. Its network and storage needs belong to preparation, not to every native invocation
Organization-integrated configuration	The selected protected credential store and identity, discovery or authorization providers, each only where required by its binding. Artifact delivery uses approved origins and credentials independently of command authorization

An unavailable mandatory integration prevents startup, candidate application or the affected operation as its registered contract requires. A lazy connection is possible only where that contract permits it; availability failure does not turn a required provider into an optional one. Thus the same local architecture can run with few dependencies or depend on organizational services without hiding that operational difference. ADR-0005, ADR-0007, ADR-0008, ADR-0010, ADR-0011

7.4 Platform requirements and enforcement limits

Actual OS/runtime support depends on verified adapters. Corporate process, filesystem, certificate and identity restrictions can prevent preparation or launch. Failure does not automatically request elevation or weaken trust. The process/IPC experiments retain their recorded scope; they are not a general platform support matrix. ADR-0003, ADR-0007

The owner explicitly chooses host-trusted execution or a verified confinement profile. Host trust retains the process account’s OS authority. Confined execution must establish all required dimensions before any extension code starts; a missing platform mechanism cannot trigger a weaker fallback. Runtime preparation has its own authority and is not automatically enclosed by the later extension’s boundary. ADR-0008, ADR-0015

For an actual deployment, the selected bindings need evidence for the following boundaries, rather than a claim that the OS name alone establishes compatibility:

Boundary	Deployment evidence required by the contract
Process and runtime	Exact OS/architecture/runtime adapter; permitted executable launch, connected control-handle transfer and descendant supervision under that account
Files and managed environments	Writable owner-approved paths, safe extraction and the storage adapter’s locking/recovery behavior; preparation cannot silently change global PATH or a system-default runtime
Source access	Reachable approved origins and valid TLS or SSH host verification; redirects recheck destinations and do not forward credentials to another origin
Credentials and interaction	Supported protected storage and the selected interactive/noninteractive binding; an unavailable store or terminal cannot be replaced by plaintext storage or a hidden OS prompt

ADR-0003, ADR-0007, ADR-0008 and ADR-0011 define these requirements. The support matrix and measurements for a production distribution remain implementation evidence to obtain; this table does not certify corporate Windows policies or any other deployment environment.