2. Architecture Constraints
These constraints come from Rukh’s product scope and the systems around it. They limit design choices without prescribing their implementation. The accepted responses belong in 4. Solution Strategy and the ADRs.
2.1 Product and organizational constraints
Section titled “2.1 Product and organizational constraints”| Constraint | Consequence for the design | Requirement / source |
|---|---|---|
| The CLI owner and extension publishers release independently | Adding ordinary commands cannot require rebuilding the branded application or using the core’s implementation language. Independent publication still requires an explicitly supported integration contract. | REQ-01, REQ-02; ADR-0001, ADR-0010 |
| The same product serves small teams and organizations | A useful local configuration cannot depend on operating identity, permission or database services. Adding those services cannot require rewriting extension identity and command contracts. | REQ-04; ADR-0009 |
| Organizations retain existing identity and resource authorities | Rukh must connect to their supported standards or custom integrations. It cannot create corporate permission merely by admitting a package or editing a local file. | REQ-03, REQ-04; ADR-0005 |
| People and agents need the same installed domain capabilities | Agent integration cannot depend on a second implementation of every command, or replace declared input with arbitrary shell text. Command publication and the rights of each caller remain distinct. | REQ-05; ADR-0013 |
| A CLI participates in other programs’ input and output | Pipelines, redirected data, terminal interaction, exit status and cancellation constrain execution mappings. A transport cannot appropriate the command’s standard streams for incompatible purposes. | REQ-02, REQ-06; ADR-0001, ADR-0002 |
These requirements do not mandate separate departments, continuous integration, a specific source host or a commercial identity product. An owner may maintain approved catalogs and rules as reviewed files, including manual publication. ADR-0009
2.2 Constraints of the execution environment
Section titled “2.2 Constraints of the execution environment”| External condition | Boundary Rukh must respect | Source |
|---|---|---|
| OS accounts, process rules and installed runtime capabilities differ | A supported command still may be unable to launch in a particular environment. The core must determine actual compatibility and permissions rather than infer them from a language or platform name. | ADR-0001, ADR-0008 |
| A program can access resources directly under its OS account | Supervising the program and checking core operations cannot by themselves restrict its direct file, network or child-process activity. Stronger required restrictions need enforceable platform mechanisms. | ADR-0015 |
| Catalogs, policies and external accounts change independently of a running command | A saved description, an earlier sign-in or a previously allowed request cannot establish indefinitely valid permission. Local records cannot freeze another system’s state. | ADR-0005, ADR-0011, ADR-0012 |
| External operations can complete before their reply is lost | The core cannot generally prove rollback, deduplicate legitimate repeated requests by their arguments or provide exactly-once effects across arbitrary resources. Resource-side evidence and supported contracts determine what can be reconciled. | ADR-0016 |
| An agent’s inputs and reasoning do not establish authority | Tool descriptions, returned content and a stated purpose may influence the caller but cannot confer rights. Rukh controls its own invocation paths, not the agent’s other tools or behavior outside them. | ADR-0013, ADR-0014 |
2.3 Decisions and unresolved deployment requirements
Section titled “2.3 Decisions and unresolved deployment requirements”The process baseline, static descriptor format, KCL authoring, private IPC and selected identity protocols are chosen solutions, not externally imposed technology constraints. Their alternatives and limits remain in section 9.
The accepted records do not establish a complete supported OS/runtime matrix, certify platform confinement adapters or specify organization-specific legal obligations and service availability commitments. An integration requiring such a guarantee must establish it for its actual deployment; a reference experiment is not that evidence. The current verification gaps are in 11. Risks and Technical Debt.