Isolation Planner

Input Parameters

| Name | Type | Required | Description | |------|------|----------|-------------| | rundir | string | Yes | Workspace root directory for file passing between agents | | sshkey_path | string | No | SSH key path for cloud provider access | | environment | string | Yes | Target environment for isolation method selection |

Execution Flow

Task Context

Before starting execution, initialize task_context.json:

{
  "task_id": "",
  "current_step": 0,
  "current_step_id": null,
  "status": "running",
  "steps": {
    "phase3_plan_generation": "pending",
    "phase3_batch_planning": "pending",
    "phase3_review_gate": "pending"
  },
  "updated_at": ""
}

Update this file after each step completes. On error, set step status to "failed" and overall status to "failed".

Step 1: phase3plangeneration

Type: inline Description: Read Phase 1/2 output and generate per-resource isolation plans

Execution

Follow these instructions:

Read Phase 1/2 output files from {run_dir}/analysis/:

• suspect_assessment.json
• zombiesuspect{resource_id}.json (per resource, from Phase 1 resource-screener)
• deepscan{resource_id}.json (per resource, from Phase 2 deep-scanner)

For each resource with suspect_level in {high, medium}:

1. Data Extraction:

• suspectlevel, zombiescore, priority, ownerdetail: from zombiesuspect{resourceid}.json
• owner name, team: from deepscan{resource_id}.json business.owner
• relatedresources (blastradius / dependency graph): from deepscan{resource_id}.json business.related_resources

1. Method Selection: Use the isolation strategy matrix (by resource_type x environment)

to select the primary isolation method. If preconditions fail, use fallback.

Isolation Strategy Matrix:

• CloudVM: iptables DROP (all envs) | Fallback: stop_instance
• CloudRDS: denysgall_inbound (all envs)
• CloudCache: clearipwhitelist (all envs)
• K8sWorkload: scaletozero (all envs)
• K8sService: unmatchable_selector (all envs)
• K8sCronJob: suspend (all envs)
• CloudLoadBalancer: removeallbackends (all envs)
• CloudEIP: unbind (all envs)
• K8sConfig: label_isolated + backup (all envs)
• ServiceMesh: removefrommesh + sidecardisable (staging/prod) | removefrom_mesh (dev)
• AppConfig: config_snapshot + deactivate (all envs)

1. Per-Resource Plan Generation: For each candidate, create {rundir}/analysis/isolationplan{resourceid}.json with:

• metadata: resourceid, resourcetype, entitytype, environment, suspectlevel, zombie_score, priority
• isolationstrategy: methodid, method_name, description, rationale
• isolation_steps: [list of human-executable steps with verification commands]
• prechecklist: [resource-type-specific pre-checks with MUSTPASS/SHOULD_PASS status]
• rollbackplan: methodid, methodname, estimatedtime, steps
• observationconfig: observationperioddays, metricstomonitor, successcriteria, autorollbacktriggers
• riskassessment: criticaldependencies, blastradiussummary, isolationsideeffects, special_warnings
• quality_checks: completeness and consistency validation results

1. Data Validation: Before generating plans, validate:

• All candidates have resourceid, resourcetype, environment
• resourcetype is in SUPPORTEDTYPES
• suspect_level is high or medium
• blastradius is populated (from deepscan business.related_resources)
• ownerdetail is populated (from deepscan business.owner)

1. Pre-Checklist Generation: Create resource-type-specific pre-checks:

• Universal checks: backup availability, rollback dependencies, no ongoing changes, on-call notification
• CloudVM: SSH connectivity, iptables availability, rules backed up, not in Auto Scaling group
• CloudRDS: security group modifiable, no ongoing maintenance, backup available
• CloudCache: active connections count checked (do not isolate if serving traffic), persistence config verified (RDB/AOF backup status), confirmed not a shared cluster
• K8sWorkload: HPA status confirmed, replicas recorded, no PDB conflicts
• K8sService: endpoint count checked, headless service verified, external traffic policy recorded
• K8sCronJob: active jobs count checked, suspend status verified, concurrency policy recorded
• Load balancer / Elastic IP: backend configuration recorded, DNS records checked
• K8sConfig: backup created, no active mounts
• ServiceMesh: control plane accessibility confirmed, sidecar injection status recorded, traffic policies backed up
• AppConfig: config backup created, no active deployments using this config

1. Observation Period Configuration:

• dev: 3 days
• staging: 7 days
• prod: 30 days
• Include metricstomonitor per resource type
• Include autorollbacktriggers with P0/P1/P2 severity levels
• Include success_criteria for phase transition

1. Quality Checks: Validate each plan:

• methodassigned: isolationstrategy.method_id is not null
• stepsdocumented: isolationsteps has >= 3 items with descriptions
• rollbackcomplete: rollbackplan.steps has >= 2 items
• observationconfigured: observationconfig has metrics + period + triggers
• dependencyanalyzed: riskassessment.blastradiussummary is populated

Write each plan to {rundir}/analysis/isolationplan{resourceid}.json

Write the output to the specified output file.

Output

• Schema: schemas/isolation-plan.schema.json
• File: analysis/isolationplan{resource_id}.json

Progress Tracking

After completing this step, update task_context.json:

• Set current_step_id to "phase3_plan_generation"
• Set steps.phase3_plan_generation to "completed"

Step 2: phase3batchplanning

Type: inline Description: Analyze dependencies and group resources into safe execution batches

Execution

Follow these instructions:

Read all isolationplan{resourceid}.json files and deepscan{resourceid}.json files.

Dependency Graph Construction (from deep_scan files):

• For each candidate, extract business.related_resources from its deepscan{resource_id}.json
• Build a directed graph: resource_id -> each related resource in business.related_resources
• Cross-reference: if resource A lists B in related_resources, and B is also a candidate, edge A -> B exists

Batch Grouping Algorithm:

1. Detect Strongly Connected Components (SCCs): Use Tarjan's algorithm to find circular dependencies

• Zombie chains (circular dependencies) must be grouped as single atomic batches
• Each SCC becomes a batch or part of a batch

1. Build SCC DAG: Create a directed acyclic graph of SCCs

• Edge A -> B means SCC(A) must be isolated before SCC(B)

1. Topological Sort: Order SCCs by dependency

• Resources with no upstream dependencies come first
• Resources with dependencies come after their dependencies

1. Batch Creation: For each SCC in topological order:

• batch_id: sequential number (1, 2, 3, ...)
• resource_ids: list of resources in batch
• parallelizable: true if no internal edges, false if sequential ordering needed
• ordering: if sequential, provide step-by-step ordering with rationale
• rationale: plain-English explanation of grouping

1. Batch Categories:

• Independent Leaf Resources: No dependencies; can parallelize
• Sequential Chains: A -> B -> C; must execute in order
• Zombie Chains: Circular dependencies; treat as atomic group
• Manual Review: [UNKNOWN] dependencies; require human validation

1. Global Execution Plan:

• recommended_sequence: ordered list of batch execution
• totalestimatedtime: sum of batch execution times
• critical_path: longest single-threaded path
• parallelization_opportunities: which batches can run in parallel

1. Safety Validations:

• nocriticaldependency_violations: true if no batch isolates a dependency before its dependent
• allblastradiusanalyzed: true if all resources have blastradius
• zombiechainsgrouped: true if all circular dependencies are in same batch
• batchordersafe: true if topological order is respected

Write result to {rundir}/analysis/isolationbatchplan.json with: metadata: generatedat, environment, totalcandidates, highprioritycount, mediumprioritycount, totalbatches batches: [array of batch objects] globalexecutionplan: sequence, timing, critical path dependencygraphsummary: total resources, edges, SCCs, circular groups safety_validations: all checks passed/failed

Write the output to the specified output file.

Output

• Schema: schemas/isolation-batch-plan.schema.json
• File: analysis/isolationbatchplan.json

Progress Tracking

After completing this step, update task_context.json:

• Set current_step_id to "phase3_batch_planning"
• Set steps.phase3_batch_planning to "completed"

Step 3: phase3reviewgate

Type: inline Description: Present isolation plans to user for approval before Phase 4 execution

Input Files

• analysis/isolation_batch_plan.json (from Step phase3batchplanning, schema: schemas/isolation-batch-plan.schema.json)

Execution

Follow these instructions:

Read {rundir}/analysis/isolationbatch_plan.json.

Pre-Review Validation:

• Verify all isolationplan{resource_id}.json files exist for all candidates
• Check isolationbatchplan.json has complete batch definitions
• Confirm all quality checks passed or are documented as warnings

Present to user:

1. Summary:

• Total resources to isolate: {total_candidates}
• High priority: {highprioritycount} | Medium: {mediumprioritycount}
• Total batches: {total_batches}
• Estimated total time: {totalestimatedtime}

1. Batch Plan:

• For each batch: batchid, description, resourceids, parallelizable, estimatedexecutiontime
• Dependency ordering: which batches must run sequentially, which can parallelize
• Critical path: longest single-threaded path

1. Per-Resource Details (top 5 by priority):

• resourceid, resourcetype, environment, suspectlevel, zombiescore
• isolationmethod, observationperioddays, rollbackestimated_time
• blastradiussummary: affectedservicescount, criticalpathdetected
• special_warnings: any resource-specific risks

ASK user:

• Approve all isolation plans? Or review per-resource?
• Any resources to skip or adjust isolation method?
• Confirm observation period duration per environment?
• Any concerns about batch ordering or parallelization?

WAIT for user response. This is a BLOCKING GATE. DO NOT execute any isolation without explicit user approval.

After user responds, write {rundir}/analysis/userapprovaldecision.json: metadata: decisiontimestamp: ISO8601 timestamp approvalstatus: approved/rejected/partialapproval approvedresources: [list of resourceids approved for isolation] skippedresources: [{resourceid, reason}] adjustedobservationperiods: {resourceid: newdays} batchplanapproved: true/false user_notes: string

Only proceed to Phase 4 if batchplanapproved == true and approved_resources is non-empty.

Write the output to the specified output file.

Output

• Schema: schemas/user-approval-decision.schema.json
• File: analysis/userapprovaldecision.json

Progress Tracking

After completing this step, update task_context.json:

• Set current_step_id to "phase3_review_gate"
• Set steps.phase3_review_gate to "completed"

Error Handling

Phase 3 finds 0 high/medium candidates

Normal termination: no resources require isolation. Present summary and exit.

Isolation method not found for resource type

Mark resource as method_missing, flag for manual isolation, skip in batch plan.

Dependency topology incomplete ([UNKNOWN] entries)

Isolate resource in separate manual-review batch, require human validation before execution.

Circular dependency detected (zombie chain)

Group all resources in cycle as single atomic batch for synchronized observation and rollback.

Pre-checklist validation fails for resource

Mark resource with failed_preconditions, include in plan with warning, require manual review before execution.

Quality check blocks plan

Return plan for revision. Max 3 revision rounds. If still failing, escalate to admin.

User rejects isolation plan at review gate

Save user decision to userapprovaldecision.json. Skip Phase 4 for rejected resources. Proceed with approved resources only.

Rollback time estimate > 30 minutes

Flag as warning in quality check. Proceed if user approves, but require extended observation period.

Critical dependency detected in blast_radius

Flag in riskassessment.criticaldependencies with HIGH risk_level. Include mitigation steps in plan.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: KnoxOps
• Source: KnoxOps/open-devops-skills
• License: Apache-2.0
• Homepage: https://knoxops.app?invite_token=GITHUB26

Install and usage instructions live in the source repository linked above.