Safe Ops
Make the safe path easy. Check authority, preview material effects, execute the
named operation, and read back the result. No ritual approval loops.
One authorization policy
- A clear request naming an operation and a resolvable target authorizes that
scope. "Commit and push this branch" and "open the PR" do not need another
generic "proceed?". Show a compact preview and continue.
- A review, diagnosis or QA request does not authorize publishing or fixing.
"Ship it" does not silently authorize merge, tag, deploy or database changes.
- Ask when the action/target is ambiguous, blast radius exceeds the request,
or new evidence materially changes the risk. Do not turn an inferred goal
into authority for a remote mutation.
- Destructive/history-rewriting actions require approval of the exact
preview: targets, old/new state, losses, recovery and its limits.
An earlier explicit approval of that unchanged preview remains valid.
- Higher-priority and environment-specific gates still apply, including
production restrictions and the user's exact-diff approval for global
Codex instructions/configuration/skills. Unknown environment = production.
Never infer ST/PROD write authorization from local-development permission.
Risk, proportional ceremony
| Level |
Typical action |
Handling |
| L1 |
Status, diff, bounded read-only query |
Proceed within read-access rules |
| L2 |
Authorized local commit, topic-branch fast-forward push |
Short preview, execute, read back |
| L3 |
Shared branch push/merge, PR publication, infrastructure/API writes |
Verify named target, effects and existing authorization; ask only if missing |
| L4 |
Force push, hard reset, destructive deletion, schema/data loss |
Exact reviewed preview, explicit approval and recovery plan |
A topic push can trigger CI or preview deployment; discover meaningful side
effects before treating it as L2. "Reversible" does not mean cost-free.
References
The policy above is canonical. Read only the relevant domain; "confirm" in a
recipe means establish authorization under this policy, not automatically ask
again. Examples are not authority.
- Git, CI and PRs: dev-workflow.md.
- Infrastructure: infrastructure.md.
- Databases/APIs: data-services.md.
- Files/processes/secrets: local-system.md.
- Multi-step or uncertain operations: safety-protocol.md.
Report one compact outcome per coherent operation: changed scope, observed
result, important residual effects and recovery when material. No audit block
for every file or command. Stop on unexpected state and inspect before retrying.
1---2name: safe-ops3description: Safely perform authorized remote, destructive or security-relevant operations, including Git push/merge, releases, infrastructure and data mutations, credential changes and bulk cleanup. Not required for routine read-only inspection or ordinary scoped repository edits.4---56# Safe Ops78Make the safe path easy. Check authority, preview material effects, execute the9named operation, and read back the result. No ritual approval loops.1011## One authorization policy1213- A clear request naming an operation and a resolvable target authorizes that14 scope. "Commit and push this branch" and "open the PR" do not need another15 generic "proceed?". Show a compact preview and continue.16- A review, diagnosis or QA request does not authorize publishing or fixing.17 "Ship it" does not silently authorize merge, tag, deploy or database changes.18- Ask when the action/target is ambiguous, blast radius exceeds the request,19 or new evidence materially changes the risk. Do not turn an inferred goal20 into authority for a remote mutation.21- Destructive/history-rewriting actions require approval of the **exact22 preview**: targets, old/new state, losses, recovery and its limits.23 An earlier explicit approval of that unchanged preview remains valid.24- Higher-priority and environment-specific gates still apply, including25 production restrictions and the user's exact-diff approval for global26 Codex instructions/configuration/skills. Unknown environment = production.27 Never infer ST/PROD write authorization from local-development permission.2829## Risk, proportional ceremony3031| Level | Typical action | Handling |32|---|---|---|33| L1 | Status, diff, bounded read-only query | Proceed within read-access rules |34| L2 | Authorized local commit, topic-branch fast-forward push | Short preview, execute, read back |35| L3 | Shared branch push/merge, PR publication, infrastructure/API writes | Verify named target, effects and existing authorization; ask only if missing |36| L4 | Force push, hard reset, destructive deletion, schema/data loss | Exact reviewed preview, explicit approval and recovery plan |3738A topic push can trigger CI or preview deployment; discover meaningful side39effects before treating it as L2. "Reversible" does not mean cost-free.4041## References4243The policy above is canonical. Read only the relevant domain; "confirm" in a44recipe means establish authorization under this policy, not automatically ask45again. Examples are not authority.4647- Git, CI and PRs: [dev-workflow.md](cookbook/dev-workflow.md).48- Infrastructure: [infrastructure.md](cookbook/infrastructure.md).49- Databases/APIs: [data-services.md](cookbook/data-services.md).50- Files/processes/secrets: [local-system.md](cookbook/local-system.md).51- Multi-step or uncertain operations: [safety-protocol.md](cookbook/safety-protocol.md).5253Report one compact outcome per coherent operation: changed scope, observed54result, important residual effects and recovery when material. No audit block55for every file or command. Stop on unexpected state and inspect before retrying.
CassioRoos