Autonomy is a rollback problem.

MISSION: DESIGN AND IMPLEMENT A REVERSIBLE AUTONOMY LADDER

Act as the principal engineer and safety owner for an agent workflow. Convert an existing manual or agent-assisted process into explicit authority tiers. The result must let the system expand, pause, and revoke permissions independently by tool, environment, tenant, and action class.

INPUTS I WILL PROVIDE
- Workflow map, actors, systems, credentials, existing controls, and known incidents.
- Candidate tools with read/write behavior and external side effects.
- Risk policy, approval roles, budget limits, recovery objectives, and audit requirements.
- Repository, test fixtures, deployment target, and observability stack.

OPERATING CONTRACT
1. Inspect the actual workflow and integrations before proposing permissions.
2. Separate read, draft, sandbox, reversible live, and consequential action capabilities.
3. Never label an action reversible without a tested inverse and post-recovery check.
4. Bind high-risk approvals to an immutable action digest, exact target, artifact version, environment, expiry, and named approver.
5. Give every external mutation an idempotency strategy and explicit partial-success behavior.
6. Store observable traces and concise decisions; do not store private chain-of-thought.
7. Do not grant the agent the ability to change its own role, credentials, budgets, approval policy, or promotion evidence.

BUILD THESE ARTIFACTS
- Typed action catalog with scope, reversibility, authority, data class, financial/reputational impact, and owner.
- Permission matrix across roles, tools, environments, tenants, and action classes.
- Promotion state machine with evidence thresholds, expiry, pause, revoke, and emergency freeze transitions.
- Approval payload schema with digest, diff, preconditions, expected effect, validation, rollback, and idempotency key.
- Recovery runbook and machine-checkable post-recovery assertions for each live mutation.
- Operator view showing current authority, pending approvals, recent actions, incidents, and contraction controls.

IMPLEMENTATION ORDER
A. Inventory actions and credentials; identify hidden write paths and shared identities.
B. Define types, invariants, state transitions, and authorization tests before UI work.
C. Ship read-only and draft tiers using realistic fixtures.
D. Add sandbox execution with reset and failure injection.
E. Add one reversible live action with idempotency, exact approval, telemetry, and rehearsed recovery.
F. Add promotion and revocation controls only after the thin path passes adversarial tests.

ACCEPTANCE TESTS
- A draft-capable role cannot discover or invoke the submit credential.
- A changed payload invalidates its prior approval.
- Duplicate delivery produces one external effect and one legible result.
- Cancellation prevents new child actions and reports any effect already committed.
- Failed recovery leaves the system frozen and escalates with exact inconsistent state.
- The operator can revoke one permission without disabling unrelated low-risk work.

FINAL HANDOFF
Provide the decision record, action catalog, permission matrix, state diagram, authorization tests, failure-injection results, operator walkthrough, known limitations, and rollback. Identify which promotion decisions remain human-owned and why.

MISSION: REHEARSE FAILURE BEFORE AN AGENT WORKFLOW REACHES PRODUCTION

You are the reliability lead for an agent that reads context, reasons, calls tools, and may change external systems. Build a deterministic rehearsal that exposes failures at every boundary and produces an evidence-backed go, restrict, or stop recommendation.

DISCOVERY
- Trace the workflow from trigger through context assembly, model calls, tool calls, persistence, external effects, approvals, and completion.
- Identify idempotency boundaries, retry owners, timeout values, concurrency assumptions, and cancellation propagation.
- Classify state as source-of-truth, cache, derived view, pending intent, or external authority.
- List every place where a request can fail after the external system has already committed.

FAULT MATRIX
Inject at minimum: provider timeout, malformed model output, tool permission loss, stale read, duplicate webhook, concurrent mutation, partial batch, approval expiry, operator cancellation, dependency outage, telemetry loss, and rollback failure. Add domain-specific faults from real incidents and near misses.

TEST CONTRACT
1. Use fixtures or isolated accounts; do not experiment on production records.
2. Seed and record the exact initial state for every scenario.
3. Assert state transitions, external effects, retry count, emitted evidence, and terminal status.
4. A completion status is forbidden while any required effect or verification is unknown.
5. Retries are bounded and cannot duplicate an external mutation.
6. Cancellation stops new work, preserves receipts, and reports effects already committed.
7. Recovery must include an independent post-condition check, not only a successful command exit.

DELIVERABLES
- Versioned scenario catalog and risk coverage map.
- Deterministic fixture builders and fault adapters.
- State-transition assertions and idempotency tests.
- Timeline for each failure showing detection, containment, recovery, and verification.
- Release thresholds for failure rate, recovery time, inconsistent-state duration, and review burden.
- Residual-risk register with owner and next rehearsal date.

Begin with the workflow diagram and the five failures most likely to create an invisible or duplicated side effect. Explain why those five come first before writing the harness.

MISSION: BUILD A VERSION-AWARE CANARY AND RECOVERY CONTROL PLANE

Act as the release engineer for an application with agent-driven changes. Design the path from isolated branch to preview, canary, promotion, pause, and rollback. Treat application artifacts, configuration, credentials, and data migrations as separate versioned concerns.

INPUTS
- Repository protections, CI checks, deployment platform, environments, and current release history.
- Runtime telemetry, SLOs, business invariants, data schema, migrations, bindings, and external integrations.
- Approval policy, incident roles, recovery objectives, and allowed automation boundary.

DESIGN RULES
1. Every candidate is identified by immutable source commit and build artifact.
2. Required checks come from trusted identities and cover type, lint, unit, integration, accessibility, and security risks appropriate to the change.
3. Canary observations are attributable to the deployed version.
4. Promotion and rollback thresholds are declared before exposure begins.
5. A code rollback never claims to restore data or deleted platform resources.
6. Migrations remain compatible with the currently deployed application until rollback is no longer required.
7. Production promotion remains human-approved unless a separate policy explicitly authorizes a narrower action.

BUILD
- Release manifest with source, artifact, config, bindings, migrations, approvals, checks, and rollback target.
- Preview verification script that a non-author can run.
- Canary controller with staged exposure, version affinity where required, pause, promote, and rollback.
- Version-specific dashboard for errors, latency, invariant breaches, dependency failures, and cost.
- Compatibility matrix across application, schema, configuration, and dependent services.
- Recovery runbook with exact commands, authority, evidence capture, and post-rollback checks.

FAILURE TESTS
- Canary error threshold breaches during promotion.
- Telemetry disappears or cannot attribute traffic to a version.
- Old application code reads the new schema after rollback.
- A required binding or resource is missing from the rollback target.
- Two operators issue conflicting promote and rollback commands.
- The agent proposes promotion without the named human approval.

FINAL HANDOFF
Provide architecture, release manifest schema, CI and deployment changes, compatibility tests, failure evidence, operator rehearsal, residual risks, and a one-command or one-control rollback path whose post-conditions have been verified.