zman27/ai_ops
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Enforce resolved execution context for deterministic actor policy

Browse Source
This commit is contained in:
Josh Rzemien
2026-02-23 17:51:09 -05:00
parent 94c79d9dd7
commit 4f5ff16b45
9 changed files with 371 additions and 93 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/orchestration-engine.md
View File

@@ -25,6 +25,17 @@ The orchestration runtime introduces explicit schema validation and deterministi
Node payloads are persisted under the state root. Nodes do not inherit in-memory conversational context from previous node runs. Fresh context is reconstructed from the handoff and persisted state each execution. Sessions load project context from `AGENT_PROJECT_CONTEXT_PATH` at initialization, and orchestration writes project updates on each node completion.
## Resolved execution contract
Before each actor invocation, orchestration resolves an immutable `ResolvedExecutionContext` and injects it into the executor input:
- `phase`: current pipeline node id
- `modelConstraint`: persona-level model policy (or runtime fallback)
- `allowedTools`: flat resolved tool list for that node attempt
- `security`: hard runtime constraints (`dropUid`, `dropGid`, `worktreePath`, violation handling mode)
This keeps orchestration policy resolution separate from executor enforcement. Executors do not need to parse manifests or MCP registry internals.
## Execution topology model
- Pipeline graph execution is DAG-based with ready-node frontiers.
@@ -52,6 +63,7 @@ Security enforcement now lives in `src/security`:
- Zod-validated shell/tool policy schemas.
- `SecurityRulesEngine` for binary allowlists, path traversal checks, worktree boundaries, and tool clearance checks.
- `SecureCommandExecutor` for controlled `child_process` execution with timeout + explicit env policy.
- `ResolvedExecutionContext.allowedTools` is used to filter provider-exposed tools before SDK invocation, including Claude-specific tool gating where shared `enabled_tools` is ignored.
`PipelineExecutor` treats `SecurityViolationError` via configurable policy:
- `hard_abort` (default): immediate pipeline termination.

7
docs/pipeline-policies.md
View File

@@ -15,6 +15,7 @@
- Coordinates DAG traversal and retry behavior.
- Computes aggregate run status from executed terminal nodes plus critical-path failures.
- Applies dedicated `SecurityViolationError` handling policy (`hard_abort` or `validation_fail` mapping).
- Resolves per-attempt `ResolvedExecutionContext` (phase/model/tool/security contract) and injects it into actor executors.
## Aggregate status semantics
@@ -29,3 +30,9 @@ Otherwise status is `failure`.
State and project-context writes are now atomic via temp-file + rename.
Project-context patch/write operations are serialized both in-process (promise queue) and cross-process (lock file).
## Tool enforcement guarantees
- Pipeline resolves a flat `allowedTools` list per node attempt.
- MCP config exposed to executors is pre-filtered to `allowedTools`.
- Claude tool callbacks are expected to use the provided policy handler so unsupported shared MCP tool filters cannot bypass enforcement.