AI/Tasks/OrchestratorUpgrades/Orchestrator_Phase03_ToolPolicyAuthorization_Strict.txt
|
STRICT MODE: Centralize tool policy and authorization decisions.
Mission: - Complete this phase with bounded steps and deterministic fallback behavior. - Apply changes ONLY within tool-policy ownership, tool validation, authorization, and directly related execution guards. Concrete scope: - AI/Tasks/OrchestratorUpgrades/Overview.txt - AI/Tasks/OrchestratorUpgrades/Orchestrator_Phase03_ToolPolicyAuthorization_Strict.txt - Tool registry, authorization policy, path checks, structured tool result models, and enforcement seams that gate mutation and side effects. Requirements: - Create a central `ToolPolicy` model that defines tool names, categories, mutation type, execution mode, validation schema, path requirements, and output constraints. - Centralize validation and authorization before execution so every mutation passes through one consent path. - Enforce path-root and workspace policies using fail-closed behavior. - Convert exceptions and tool failures into structured execution results with codes, retryability, side-effect status, and redacted diagnostics. - Define the minimum `ToolPolicy` schema, including name, aliases, category, destructive classification, mode restrictions, validation rules, timeouts, output caps, path enforcement, postcondition verifier, and authorization requirement. - Require unknown tools and missing policy entries to fail closed. - Define the exact ordering of argument normalization, path resolution, schema validation, confirmation, authorization, execution, and postcondition verification. - Preserve current behavior where the task is only to unify policy enforcement and reduce drift. - Keep the model deterministic, centralized, and mechanically testable. - Add characterization or phase-specific tests before or alongside each major change. - Do not expand into decision schema redesign, loop tracking, weather-specific validation, or memory privacy changes beyond what is required to centralize tool policy and authorization. - Enforce sensitive-data redaction and resource-limit checks in any diagnostics or logging introduced here. - Do not weaken authorization, confirmation, sandboxing, or execution safety requirements. - Define compatibility and rollback rules for tool-policy schema or alias changes that alter authorization behavior. Step budget (hard limits): 1) Discovery: <= 6 read/search tool calls. 2) Edits: <= 8 file edits total. 3) Validation: 1 build + 1 targeted test run; allow exactly 1 repair cycle if failures are phase-related. 4) Stop once acceptance criteria pass. Loop guards: - If policy ownership starts to overlap with state-model transitions or finalization logic, stop and re-establish the owning abstraction. - If repeated policy refactoring becomes a broader rewrite than tool authorization consolidation, stop and keep the phase boundary explicit. Fallback behavior: - Fallback A: establish the registry and authorization gate first, then tighten validations and result models around it. - Fallback B: preserve current tool checks and add an explicit policy wrapper instead of replacing them all at once. - Fallback C: after one failed repair cycle, emit FAILED_VALIDATION with the exact failing assertions. Acceptance criteria: - A single tool-policy registry owns tool metadata and routing behavior. - Mutation authorization is centralized and fail-closed. - Path and workspace restrictions are enforced before mutation. - Structured tool execution results replace raw exception flattening. - Characterization or phase-specific tests cover registry membership, authorization decisions, and redacted failure diagnostics. - Logging and diagnostics redact sensitive data and respect resource limits. - The orchestration layer does not weaken authorization, confirmation, sandboxing, or execution safety requirements. Validation commands: - dotnet build src/TechToolbox.Agent/TechToolbox.Agent.csproj -c Release - dotnet test src/TechToolbox.Agent/Tests/TechToolbox.Agent.Tests.csproj -c Release --filter "Orchestrator|Tool|Policy|Authorization|Safety|Strict" Output results in markdown using this structure: 1) Summary 2) Files changed 3) Tool policy and authorization contract 4) Tests added/updated 5) Validation results 6) Step-budget report (planned vs actual counts) |