alkdev/alknet
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(architecture): update ADR-015 scoped env API — resolved by ADR-022

Browse Source 
ADR-015 L171 said the scoped env API was 'a two-way door for
implementation.' ADR-022 has now resolved it: ScopedOperationEnv with
operation-level granularity (HashSet<String>), not namespace-level.
Update the stale text to point to the resolution.
This commit is contained in:
glm-5.2
2026-06-21 10:51:42 +00:00
parent 6a7f8f91ad
commit 3f529df367
1 changed files with 6 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
docs/architecture/decisions/015-privilege-model-and-authority-context.md
View File

@@ -168,11 +168,12 @@ but it only gives the sandbox `fs:read` (not `bash:exec`), because the sandbox
runs untrusted LLM-generated code. This is the "privileges flow downstream"
principle: the principal delegates a subset.
The specific API for declaring the scoped operation set (allowed-operations
list, allowed-namespaces, or a trait-based filter) is a two-way door for
implementation. The TypeScript `@alkdev/operations` `buildEnv()` used an
`allowedNamespaces` filter; the Rust implementation may be finer-grained
(operation-level, not just namespace-level) to be safe.
The specific API for declaring the scoped operation set is specified in
ADR-022: `ScopedOperationEnv { allowed_operations: HashSet<String> }`,
operation-level granularity (not just namespace-level). This is finer-grained
than the TypeScript `@alkdev/operations` `buildEnv()` which used
`allowedNamespaces` — operation-level scoping is safer for the
parameterized-dispatch use case.
### 5. The three controls together