Fix Container

Systematic container-level validation pipeline that analyzes each container's responsibilities, creates test descriptions, implem…

wtah updated 5mo ago
Claude CodeGeneric
View source ↗
# 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:

  1. Discovers all containers from .arch-registry/README.md
  2. Spawns test strategy agents for ALL containers in parallel (batched, max 2 concurrent)
  3. After ALL strategy agents complete, collects all test descriptions into a consolidated list
  4. Sequentially processes each test case with test developer/fix agents
  5. 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.