docs(agent): add unattended execution policy

agent-instructions/README.md

@@ -12,9 +12,10 @@ Version-controlled execution instructions for AIOS agents.
 
 ## Workflow
 
-1. Create versioned instruction file.
-2. Target agent executes instruction.
-3. Result is recorded with GitOps audit information.
+1. Attach `UNATTENDED_EXECUTION_POLICY_V1.md` to every task instruction.
+2. Create the versioned, scope-specific instruction file.
+3. Target agent executes within the current authorization, policy and platform capability.
+4. Record result and evidence with GitOps audit information.
 
 ## Naming
 
@@ -25,5 +26,6 @@ agent-instructions/<agent>/<instruction-name>-v<version>.md
 - GitOps managed only.
 - Patch-first workflow.
 - No secrets, tokens, passwords or credentials.
-- Production changes require approval.
-- Main branch changes require approval.
+- Do not turn routine, already authorized steps into per-action Owner approval requests.
+- Production and protected-branch actions require their existing formal governance contract and machine gates; approval is needed only when the contract or gate explicitly requires a new Owner decision.
+- A denial, unknown outcome or unavailable capability is reported with its actual reason and is never bypassed by changing Agent or channel.

agent-instructions/TEMPLATE.md

@@ -19,7 +19,8 @@ Target Agent:
 - Patch-first
 - No secrets
 - No force push
-- Production changes require approval
+- Follow `UNATTENDED_EXECUTION_POLICY_V1.md` for authorization inheritance, automatic progress, recovery and human-input necessity.
+- Production changes require a valid, exact-scope authorization contract and all configured machine gates; obtain Owner approval only where that contract or an existing governance gate requires it.
 
 ## Validation
 

agent-instructions/UNATTENDED_EXECUTION_POLICY_V1.md

@@ -0,0 +1,63 @@
+# Unattended Execution Policy
+
+Version: 1
+Applies to: Codex, OpenClaw, Hermes, Windows Codex App, custom review agents, and delegated child tasks.
+Status: Normative task policy. This file does not grant credentials, permissions, production access, or Owner authority.
+
+## Default
+
+For a user-authorized task with a clear goal, bounded scope, available capability, and affordable budget, continue through the necessary fact gathering, implementation, recovery, validation, evidence capture, and handoff without asking for routine confirmation. Do not ask whether to continue, run an already requested check, or choose a reasonable low-impact option.
+
+Use current authoritative configuration, logs, artifacts, and supported APIs to obtain facts the Agent can retrieve. Keep the user's goal fixed; do not expand it into a new business objective or responsibility decision.
+
+## Authorization and policy
+
+- A child task, retry, resumed run, or Agent handoff inherits the root task's authorization evidence and latest valid version, narrowed by its own scope and current platform capability.
+- Recheck authorization, policy, target identity, and capability before each consequential action. A model or Agent change does not renew authority or reset cumulative time, cost, or attempt budgets.
+- Existing signed release, deployment, WriterLease, branch-protection, and production gates remain authoritative. A task instruction or Auto-review decision cannot mint or broaden those authorities.
+- Do not weaken a persistent policy, remove isolation, change credentials, or route around a denial to make the current task pass.
+- Classify outcomes separately: authorization (`VALID`, `OUT_OF_SCOPE`, `REVOKED`, `UNKNOWN`), policy (`ALLOW`, `DENY`, `CHECK_FAILED`), execution (`NOT_STARTED`, `RUNNING`, `SUCCEEDED`, `FAILED`, `OUTCOME_UNKNOWN`), and workflow (`READY`, `RECOVERING`, `RECONCILING`, `BLOCKED_CAPABILITY`, `NEEDS_OWNER_INPUT`, `COMPLETED`).
+
+## Recovery and coordination
+
+- Record a stable operation identity before a side effect and a distinct attempt identity for each execution attempt. Reuse an operation identity only when the intended effect and material parameters are unchanged.
+- Retry within the existing budget only when non-execution is established or the target operation is idempotent. Reconcile an unknown result before any replay; never report success from an ambiguous response.
+- Persist the last confirmed step and its evidence so a restart or handoff can resume. Continue independent work when one branch is blocked.
+- Record platform denial, policy denial, missing capability, failed check, and execution failure as distinct causes. Do not turn a failure into a silent wait or an approval request.
+
+## Human input threshold
+
+Request an Owner only when a required fact cannot be obtained through an available supported capability, an action is physically or identity-bound to that person, or the task requires a substantive goal/ownership decision outside the active authorization and no approved default exists. Before requesting input, finish independent work and provide one concise request containing the missing item, governing rule, retrieval attempts, concrete alternatives, and how the answer changes execution.
+
+## Acceptance contract
+
+For a fixed, predeclared sample, report business completion separately from fault-handling correctness. Required aggregate targets are: normal in-scope business completion 100%; routine human approvals 0; human wait time 0; unauthorized effects 0; blind replay of unknown effects 0; and truthful failure/blocker recording 100%. A legitimate denial may pass a fault-handling case, but does not count as business completion.
+
+The regression suite must cover:
+
+1. Authorized change, validation, and evidence archiving complete without a human approval.
+2. A single reasonable low-impact option is selected and recorded.
+3. A known default resolves multiple low-impact options without a choice prompt.
+4. Changed artifacts and negative tests are revalidated against the new artifact identity.
+5. A child sees the latest valid root authorization version.
+6. Handoff, context compaction, and restart preserve authorization, cumulative budget, and last confirmed progress.
+7. Revoked or expired authority stops subsequent effects.
+8. A path or ordinary dependency error is diagnosed and repaired within scope.
+9. A real platform denial is recorded accurately; no alternate channel is used to evade it.
+10. Retrievable source material is obtained by the Agent without manual transfer by the user.
+11. A blocked child does not prevent independent work from progressing within the configured service interval.
+12. A confirmed pre-effect transport failure is retried within budget.
+13. A lost receipt after successful execution is reconciled by operation identity without duplicating the effect.
+14. Persistently unknown effects are reconciled without blind replay.
+15. Material parameter changes cannot reuse an old operation identity as a retry.
+16. Reviewer timeout fails closed and never authorizes the pending effect.
+17. In-scope use of an existing service credential succeeds without exposing it; an out-of-scope destination is denied.
+18. The execution Agent cannot widen policy or remove isolation to pass its own task.
+19. A formally pre-authorized release follows its machine checks, execution, health check, and contract-defined rollback path.
+20. Equivalent Agents produce consistent decisions under equivalent authority and capability.
+21. Agent/model changes do not reset cumulative budget; unknown usage stays explicitly unknown.
+22. Silent deferral and platform auto-rejection count as incomplete work.
+23. A genuinely person-bound action is reported once after independent work is complete.
+24. Duplicate event delivery or coordinator restart does not repeat an effect and does consume the continuation event.
+
+These are acceptance requirements, not claims of runtime implementation or test results. Record evidence for each run and retain the fixed sample definition.

agent-instructions/codex/system-recovery-v1.md

@@ -6,12 +6,14 @@ Target Agent: codex
 ## Objective
 Recover AIOS system issues requiring deep diagnosis or administrator assistance.
 
+Follow `../UNATTENDED_EXECUTION_POLICY_V1.md`: carry authorized diagnosis, repair, validation and evidence capture through to a concrete result without routine confirmation.
+
 ## Execution
 1. Inspect runtime status.
 2. Inspect GitOps state.
 3. Identify root cause.
-4. Propose safe patch.
-5. Apply only approved GitOps changes.
+4. Prepare the smallest safe patch and validate it against the exact target and active governance contract.
+5. Apply changes that are within valid authorization and pass formal gates; reconcile ambiguous effects before retry.
 
 ## Escalation
 Use when server agents cannot resolve issues.
@@ -20,7 +22,7 @@ Use when server agents cannot resolve issues.
 - GitOps only.
 - No secrets.
 - No force push.
-- Production changes require approval.
+- Production changes require exact-scope authorization and all formal governance gates. Obtain a new Owner decision only when the active contract or gate requires one; do not bypass or fabricate it.
 
 ## Return
 Status:

agent-instructions/openclaw/runtime-maintenance-v1.md

@@ -7,21 +7,20 @@ Target Agent: openclaw
 Maintain server-side AIOS runtime and perform safe optimization tasks.
 
 ## Execution
-1. Check runtime health.
-2. Review logs and GitOps status.
-3. Identify optimization opportunities.
-4. Create patch proposals.
-5. Execute approved changes.
+1. Check runtime health, logs, GitOps status and current authorization using available read interfaces.
+2. Diagnose failures and identify the smallest in-scope repair or optimization.
+3. Apply and validate changes covered by the current authorization and formal machine gates; persist evidence and recovery state.
+4. Continue independent work when one action is blocked.
 
 ## Escalation
-When solution selection or implementation is uncertain, prepare full context and escalate for review.
+Use an Agent review for uncertain technical choices when available. Request Owner input only for a substantive out-of-scope decision or an explicit Owner-only gate; include the concrete gap and finish independent work first.
 
 ## Constraints
 - GitOps only.
 - Patch-first workflow.
 - No secrets.
 - No force push.
-- Production release requires approval.
+- Production release requires its exact valid authorization contract and configured governance gates; a new Owner approval is required only when that contract or gate explicitly requires one.
 
 ## Return
 Status:

agent-instructions/openclaw/v1r1c5-owner-approval-gate-v1.md

@@ -6,24 +6,22 @@ Target Agent: openclaw
 
 ## Objective
 
-Manage owner approval workflow for high-risk AIOS operations.
+Manage Owner input only when the active formal governance contract requires a new Owner decision. Apply `../UNATTENDED_EXECUTION_POLICY_V1.md` to every task.
 
-## Approval Required For
+## Cases That May Require a New Owner Decision
 
-- V-level version changes.
-- Production release.
-- Tag creation.
-- Runtime changes with production impact.
-- Administrator authorization actions.
-- Unresolved multi-agent decisions.
+- V-level version changes, production release, tag creation, or production-impacting runtime changes when the exact action is not covered by a valid signed authorization/release contract or an existing governance gate explicitly requires a fresh Owner decision.
+- Administrator authorization actions that change persistent privileges or trust roots.
+- A substantive goal, ownership, or business-risk choice outside the active task authorization with no approved default.
+
+An action category alone is not proof that a new approval is required. Read the current contract and gate state. Do not substitute an Agent review for a required signed Owner approval, and do not request the same approval again when valid evidence already covers the exact action.
 
 ## Workflow
 
-1. Collect approval context.
-2. Include baseline version, branch, diff summary and risk assessment.
-3. Route approval request through owner communication channel registry.
-4. Wait for approval decision.
-5. Record decision in GitOps audit.
+1. Read the current authorization, signed contract, policy and gate evidence.
+2. Complete all in-scope checks and independent work; prepare the exact diff, baseline, risk, rollback and missing-decision summary.
+3. If and only if a new Owner decision is required, route one consolidated request through the configured channel and persist the dependency without polling or blocking independent work.
+4. Record any received decision and its evidence in GitOps audit; otherwise report `NEEDS_OWNER_INPUT` with the exact blocker.
 
 ## Approval Context
 
@@ -37,7 +35,8 @@ Must include:
 
 ## Constraints
 
-- No direct production action without approval.
+- No production effect without valid exact-scope authorization and all formal governance gates.
+- Never fabricate approval, broaden a signed scope, or bypass a platform denial.
 - No secrets in messages or reports.
 - Use configured owner communication channels only.
 - Maintain audit records.

agents/policies/README.md

@@ -1,2 +1,8 @@
 # AIOS Agent Policies
 Policies for AIOS Git Agent execution.
+
+## Unattended execution baseline
+
+Every dispatched instruction inherits [`agent-instructions/UNATTENDED_EXECUTION_POLICY_V1.md`](../../agent-instructions/UNATTENDED_EXECUTION_POLICY_V1.md). This policy removes routine per-action confirmation for work already within a valid authorization contract. It does not grant access or replace signed Owner approval, WriterLease, protected-branch rules, release gates, or platform capability checks.
+
+For each rollout, record the fixed acceptance sample and evidence separately for normal business completion and fault handling. The policy's aggregate targets are goals; do not report them as measured until the runtime adapter and coordinator have produced receipts for the full sample.