4. Solution Strategy
The strategy connects the quality goals and constraints to the accepted architecture. Details belong in the relevant views and ADRs.
| Goal or requirement | Chosen approach and reason | Details | Quality scenarios |
|---|---|---|---|
| A branded application without maintaining a fork | Embed the core as a library; the owner selects trusted implementations and built-in commands | ADR-0010 | Q15, Q19 |
| Independent extension teams and languages | Separate static KCL-exported declarations from code; use a common executor and lifecycle, initially supervised foreground processes | ADR-0001, ADR-0004, ADR-0006 | Q01, Q19 |
| Reliable installation and updates | Verify immutable releases and atomically publish an active profile so updates cannot rebind running invocations | ADR-0007 | Q03, Q11 |
| Simple local use with optional organization integration | Use the same Security Broker boundary for local rules and registered external providers; do not require a server | ADR-0005, ADR-0009 | Q05, Q15 |
| Environment preparation only when needed | A trusted provider resolves an exact plan; authorized lazy preparation remains separate from command execution | ADR-0008 | Q14 |
| One capability for people and agents | Project one canonical command contract into CLI and explicitly exposed MCP tools, sharing validation and invocation semantics | ADR-0013 | Q07, Q12 |
| Bounded authority with explicit enforcement | Bind subject, actor and task; narrow delegation and coordinate shared budgets; require verified confinement where selected | ADR-0012, ADR-0014, ADR-0015 | Q02, Q08, Q09 |
| Predictable failure and external effects | Preserve one final outcome and a bounded shutdown; bind consequential effects and retain uncertainty without automatic replay | ADR-0002–ADR-0004, ADR-0016 | Q04, Q10, Q18 |
4.1 Consequences of the main choices
Section titled “4.1 Consequences of the main choices”The same contracts serve a small team’s local CLI and an organization-managed workstation. The difference is the owner’s selected dependencies and required guarantees, not a second command model or an enterprise-only core. A native extension need not require a language manager; a script can use a verified preinstalled environment. Adding a mandatory remote authority deliberately makes the affected operations depend on that authority. ADR-0005, ADR-0008, ADR-0009
| Choice | Accepted cost or trade-off |
|---|---|
| Supervised processes rather than loading ordinary extension code into the core | Startup cost and platform-specific launch/IPC adapters; language independence does not mean every runtime is already supported |
| Immutable releases and exact environment references | Updates need staging and temporary coexistence of versions; lack of capacity rejects new preparation instead of deleting resources still in use |
| Bounded work, streams and queues | Overload produces an explicit refusal or the defined bounded failure; the core cannot promise to queue every installation, invocation or interaction |
| Explicit trust and optional stronger confinement | Ordinary trusted programs remain usable; operations requiring unavailable OS enforcement cannot run under a silently weaker profile |
These costs follow ADR-0001, ADR-0003, ADR-0007, ADR-0008, ADR-0010 and ADR-0015. Selected limits constrain implementations; they are not a measured throughput or cold-start promise for a corporate workstation. Section 10 separates the quality scenarios from the available evidence.
5. Building Block View describes responsibilities, 6. Runtime View explains their interaction, and 8. Crosscutting Concepts collects the shared rules.
The core’s implementation language and package layout remain unselected. Website tooling and reference experiments do not determine them. Additional executors, background ownership and concrete confinement mechanisms require compatible contracts and implementation evidence; extensibility alone does not establish support.