Remove final active-runtime governance claims

Author: ProfRandom92

docs/ANTIGRAVITY_CLI_INTEGRATION.md

@@ -26,7 +26,7 @@ flowchart TD
     agent[Antigravity Orchestrator]
     ctxt[CompText CLI]
     repo[(Repository Codebase)]
-    policy[Policy Gate / Hook]
+    policy[Policy Gate / Target Hook]
 
     agent -->|1. context inspect| ctxt
     ctxt -->|2. harvest & redact| repo
@@ -36,8 +36,8 @@ flowchart TD
     agent -->|6. invoke reviewer| subagent
     subagent -->|7. audit proposal| prop
     agent -->|8. apply gate| ctxt
-    ctxt -->|9. policy hook validation| policy
-    policy -->|10. sandboxed write execution| repo
+    ctxt -->|9. planned policy target| policy
+    policy -->|10. validated write execution| repo
 ```
 
 ---

docs/PERMISSIONS_MODEL.md

@@ -12,7 +12,7 @@ Permissions do not serve as the primary policy compiler. Instead, they act as lo
 2. **Hook Interceptors (`docs/HOOK_GOVERNANCE.md`)**: Contextual software gates executing within the workspace.
 3. **Permissions Model**: Orchestrator-enforced runtime restrictions acting as a defense-in-depth policy layer.
 
-If a hook fails or an agent attempts to bypass logical constraints, the orchestrator's runtime permissions model acts as a secondary layer to block unauthorized actions.
+In the target architecture, if a hook fails or an agent attempts to bypass logical constraints, the orchestrator's runtime permissions model is intended to act as a secondary layer to block unauthorized actions. Note that this runtime enforcement represents a design target and is not a Rust-level guarantee.
 
 ---
 
@@ -29,4 +29,4 @@ The target host policy baseline for the runtime environment is partitioned into
 
 ## 3. Explicit Phase Approval
 
-If a task requires a restricted operation (e.g., querying a local Ollama socket), the permissions must be upgraded using explicit, phase-scoped approvals in the task definition. Once the phase transitions, permissions automatically downgrade back to the default-deny baseline.
+If a task requires a restricted operation (e.g., querying a local Ollama socket), the host/orchestrator permission profile should be explicitly approved using phase-scoped configurations in the task definition. Once the phase transitions, the intended host policy should return to the default-deny baseline. This configuration acts as orchestrator-level governance, not a Rust-level compilation check.

reports/phase_12_status.md

@@ -55,5 +55,5 @@
 1. **Operating Model**: Created structural guidelines clarifying the relationship between Antigravity as the agent execution surface and CompText CLI as the policy control plane.
 2. **Token Economy**: Defined rules including read-first minimalism, one-skill-at-a-time loading, model effort selection logic, and skill-based prompt referencing.
 3. **Skill registry**: Established standardized layout directives and trigger rules for skill files. Added starter skill `.agent/skills/ctxt-antigravity-governance/SKILL.md`.
-4. **Hook Governance**: Outlined interceptor target endpoints enforcing security boundaries (blocking `.env`, network, and out-of-bounds writes).
+4. **Hook Governance**: Outlined interceptor target endpoints intended to support future security enforcement (blocking `.env`, network, and out-of-bounds writes).
 5. **Permissions & Subagents**: Positioned permissions as defense-in-depth and restricted subagents to specialized read-only audit roles.