Fix Container
Systematic container-level validation pipeline that analyzes each container's responsibilities, creates test descriptions, implem…
# Fix Container Command
Systematic container-level validation pipeline that analyzes each container's responsibilities, creates test descriptions, implements and runs tests, and fixes issues per container. Runs BETWEEN `/validate-e2e-integration` and `/fix-e2e` to reduce E2E complexity by ensuring each container works correctly in isolation first.
---
## Purpose
This command validates that **each container works correctly in isolation** before attempting cross-container E2E testing. By testing containers individually first:
1. Issues are easier to identify and fix (container-scoped)
2. E2E test failures are more likely to be actual integration issues, not container bugs
3. Each container's responsibilities are validated against specifications
**Position in Pipeline**:
/validate-e2e-integration → Validates cross-container communication works ↓ /fix-container → Validates each container's responsibilities (YOU ARE HERE) ↓ /fix-e2e → Tests full user journeys, requirements, AI capabilities
---
## What This Command Does
### Phase 1: Discovery
Read `.arch-registry/README.md` to discover all containers in the system.
### Phase 2: Test Strategy Design (Parallel, Batched)
Spawn strategy agents for ALL containers in parallel (max 2 concurrent):
- Each agent analyzes container responsibilities from `.arch-registry/README.md`
- Identifies Requirements (FR-xxx), AI capabilities (AI-xxx), User journey steps (UJ-xxx)
- Creates test description files in `{container}/tests/requirements/`
### Phase 3: Consolidate Test List (Ordered by Dependency)
After ALL strategy agents complete:
- Read all test description files across all containers
- Classify containers by type (infrastructure → worker → api → frontend)
- Build ordered list: backend/API tests run BEFORE frontend tests
### Phase 4: Test Execution & Fixing (Sequential)
For each test case in the consolidated list (one at a time):
- Implement the test (shell script or Playwright)
- Execute against running container
- If fails: spawn fix-agent, retry (max iterations)
- Persist passing tests
### Phase 5: Reporting
Generate comprehensive report showing:
- Tests passed/failed per container
- Issues fixed
- Remaining blockers
---
## Prerequisites
Before running this command:
1. **`/local-setup` has completed** - `docker-compose.local.yml` exists at project root
2. **Docker is available** - Containers can be built and run
3. **Playwright MCP is configured** - For frontend container testing
4. **Architecture registry exists** - `.arch-registry/README.md` with container list
---
## Usage
```bash
/fix-container # Test all containers
/fix-container --container=api # Test specific container
/fix-container --container=api,frontend # Test multiple containers
/fix-container --max-iterations=5 # Limit fix iterations per test
/fix-container --report-only # Generate test descriptions without executing
Instructions
You are orchestrating the container-level validation pipeline. This command:
- Discovers all containers from
.arch-registry/README.md - Spawns test strategy agents for ALL containers in parallel (batched, max 2 concurrent)
- After ALL strategy agents complete, collects all test descriptions into a consolidated list
- Sequentially processes each test case with test developer/fix agents
- Generates final report
CRITICAL: All testing happens against running Docker containers using docker-compose.local.yml.
Execution Flow
Phase 1: Discovery
│ Read .arch-registry/README.md
│ Parse Container Summary table
│ Build list of containers to process
▼
Phase 2: Test Strategy Design (PARALLEL, BATCHED - max 2 concurrent)
│ ┌─────────────────────────────────────────────────────────────────────┐
│ │ Batch 1 (up to 2 containers): │
│ │ ├── container-1 → Strategy Agent (creates test descriptions) │
│ │ ├── container-2 → Strategy Agent (creates test descriptions) │
│ │ ├── container-3 → Strategy Agent (creates test descriptions) │
│ │ └── container-4 → Strategy Agent (creates test descriptions) │
│ │ Wait for ALL in batch to complete │
│ │ │
│ │ Batch 2 (remaining containers, up to 4): │
│ │ ├── container-5 → Strategy Agent │
│ │ └── ... (continue until all containers processed) │
│ │ Wait for ALL in batch to complete │
│ └─────────────────────────────────────────────────────────────────────┘
▼
Phase 3: Consolidate Test List (Ordered by Dependency)
│ Read all test description files from ALL containers
│ Classify containers by type:
│ ├── Priority 1: Infrastructure (first)
│ ├── Priority 2: Processing/Worker
│ ├── Priority 3: API/Backend
│ └── Priority 4: Frontend (last)
│ Build ordered test list (backend before frontend)
▼
Phase 4: Test Execution & Fixing (SEQUENTIAL per test case)
│ For EACH test case in consolidated list:
│ ┌─────────────────────────────────────────────────────────────────────┐
│ │ 1. Spawn Test Developer Agent │
│ │ - Implements test from description │
│ │ - Runs test against container │
│ │ │
│ │ 2. If PASS: persist test, move to next │
│ │ │
│ │ 3. If FAIL: │
│ │
Maintain Fix Container?
Let people know it's listed here — add the badge (live metrics, light/dark aware) or a plain link to your README or docs.
[Fix Container on getagentictools](https://getagentictools.com/loops/wtah-fix-container-command?ref=badge) npx agentictools info loops/wtah-fix-container-command The second line is the CLI lookup for this page — handy in READMEs and docs.