# LLM Repair Command Instructions

## Goal
Verify integrity of the registry and site artifacts, list bad-status sites, then report issues or perform approved repairs using existing scripts only. Repairs MUST target new `*-vN.fix` versions and NEVER overwrite the original `*-vN` directory.

## Inputs
- `.smbatcher/REGISTRY.md` and `.smbatcher/batches/`
- Site directories: `sites/<domain-vX>/`
- Target files: `DESIGN.md`, `index.html`, `styles.css`, `script.js`, assets

## Fix Versioning Rules
- Never overwrite or delete `sites/<domain>-vN/` when repairing.
- All repaired outputs go to `sites/<domain>-vN.fix/`.
- The fix version inherits the same base version `vN` as the bad site.

---

CRITICAL: READ ALL RULES BEFORE ANY ACTION

## General Rules (Main Agent AND Subagents)

### G1. Script Execution
Run shell scripts directly (all Python scripts have .sh wrappers):
- All shell scripts have shebangs (`#!/bin/bash`).
- Execute them directly: `tools/script.sh`
- **Do NOT** add `sh` or `bash` prefix (e.g., `bash tools/script.sh` is WRONG).

**NEVER run Python directly or create Python scripts:**
- Do NOT use `python3`, `python3.12`, `uv run python`, or any Python interpreter
- Do NOT create `.py` files for debugging, inspection, or any purpose
- ALL functionality is accessible via `.sh` wrappers — use those instead

```bash
# CORRECT
tools/check/status-report.sh
tools/check/verify-site.sh sites/example.com-v1
tools/design/check-design.sh sites/example.com-v1/DESIGN.md
tools/check/design-compliance.sh sites/example.com-v1

# WRONG - DO NOT call Python directly
python3 tools/check/some_script.py ...      # WRONG
python3.12 tools/xxx.py ...                 # WRONG
uv run python3.12 tools/xxx.py ...          # WRONG
```

AVOID - Absolute paths add unnecessary directory prefix:

```bash
# WRONG
/Volumes/Common/QJoon/llm/wdmaker/tools/check/status-report.sh
/Volumes/Ephemeral/CMassK1/tools/check/verify-site.sh /Volumes/Ephemeral/CMassK1/sites/example.com-v1

# CORRECT
tools/check/status-report.sh
tools/check/verify-site.sh sites/example.com-v1
```

Scripts are symlinked into the repo; always use relative `tools/...` and `sites/...` paths.

### G2. No Invented Commands
- DO NOT create new bash commands or scripts
- DO NOT use ad-hoc shell commands (cat/ls/find/grep/wc/for-loops)
- Use ONLY the provided assist scripts listed below

AVOID - Ad-hoc file inspection:

```bash
# WRONG
cat .smbatcher/REGISTRY.md
ls sites | grep example.com

# CORRECT
tools/check/status-report.sh
tools/check/tree-view.sh sites/example.com-v1
```

AVOID - Ad-hoc searching:

```bash
# WRONG
grep "TODO" sites/example.com-v1/index.html

# CORRECT
Use the Read tool to inspect files when needed.
```

### G3. No HEREDOC Pattern
- NEVER use HEREDOC (`<<EOF`, `<<'EOF'`, etc.) for ad-hoc file writing
- Use Write tool or Filesystem MCP server when writing new files

```bash
# WRONG
cat <<EOF > index.html
...
EOF
```

### G4. Temp Directory
- Use `${TMP}` from `.wdmaker/config.toml` for temporary files
- NEVER use `/tmp`

### G5. Directory Creation
- Use provided scripts for creating/preparing directories (e.g., `tools/prepare/batch.sh`)
- NEVER use `mkdir` directly
- DO NOT create `.gitkeep`, `.keep`, or placeholder files

### G6. Preserve Reports
- DO NOT delete generated reports (batch reports, run logs)
- Reports in `.smbatcher/batches/`, `.smbatcher/runs/`, `${TMP}/` are historical records

### G7. Ignore Accessibility and Performance
- **DO NOT repair for accessibility** — skip ARIA attributes, screen reader support, keyboard navigation, focus styles
- **DO NOT repair for performance** — skip lazy loading, code splitting, minification, caching strategies
- Focus purely on **visual implementation, creativity, and design fidelity**

### G8. Registry Updates
- NEVER edit `.smbatcher/REGISTRY.md` or batch tracker files directly
- Use existing status scripts (design/implement/prepare) only when user requests a fix

---

## Claude Code Specific Rules

These rules are specific to Claude Code orchestration.

### C1. Model Restriction
- **DO NOT use Sonnet model** for repair tasks
- Use Opus for repair work (higher quality, better code generation)

### C2. Maximum Effort — Ignore Token Budget
- **ALWAYS ignore token budget constraints** — prioritize quality over efficiency
- Put **maximum creative effort** into every repair
- Write complete, detailed code with rich visual effects
- Never truncate or abbreviate to save tokens
- The goal is the **best possible visual output**, not the shortest response

---

## Assist Scripts Reference

### `tools/check/status-report.sh`
Purpose: Summarize registry entries and batch trackers.

```bash
tools/check/status-report.sh
```

### `tools/check/batch-manage.sh list`
Purpose: List raw registry entries for integrity checks.

```bash
tools/check/batch-manage.sh list
```

### `tools/check/verify-site.sh`
Purpose: Comprehensive site verification (files, HTML structure, JS syntax, file stats).

```bash
tools/check/verify-site.sh sites/example.com-v1
```

### `tools/check/html-check.sh`
Purpose: Validate HTML structure requirements.

```bash
tools/check/html-check.sh sites/example.com-v1
```

### `tools/check/js-syntax.sh`
Purpose: Validate JavaScript syntax for site JS files.

```bash
tools/check/js-syntax.sh sites/example.com-v1
```

### `tools/check/file-stats.sh`
Purpose: Content richness proxy via line counts and file sizes.

```bash
tools/check/file-stats.sh sites/example.com-v1
```

### `tools/design/check-design.sh`
Purpose: Validate DESIGN.md structure and quality.

```bash
tools/design/check-design.sh sites/example.com-v1/DESIGN.md
```

### `tools/design/read-design.sh`
Purpose: Read DESIGN.md sections for manual review.

```bash
tools/design/read-design.sh sites/example.com-v1/DESIGN.md --summary
```

### `tools/check/design-compliance.sh`
Purpose: Check implementation compliance against DESIGN.md.

```bash
tools/check/design-compliance.sh sites/example.com-v1
```

### `tools/check/tree-view.sh`
Purpose: Show directory structure and file sizes.

```bash
tools/check/tree-view.sh sites/example.com-v1
```

---

## Prohibited vs Alternatives

| Prohibited | Use Instead |
|------------|-------------|
| `cat/less/head/tail` for file inspection | `tools/design/read-design.sh <path> --summary` or Read tool |
| `ls/find/wc/globs` for directory listing | `tools/check/tree-view.sh <site-dir>` |
| `grep "pattern"` for searching | Read tool or dedicated scripts |
| `for ...; do` loops | Run scripts per site explicitly |
| `mkdir -p` for directory creation | `tools/prepare/batch.sh --version v1 --batch-size 20` |
| `python3 script.py` | `tools/.../<script>.sh` wrappers |
| `cat <<EOF` HEREDOC | Write tool or Filesystem MCP |
| Manual registry edits | Use provided status scripts only |

---

## Required Checks
- Registry integrity: entries, batch trackers, status codes
- Site status: required files exist and pass syntax checks
- Content richness: file sizes/line counts are not trivially small
- Non-templated content: no placeholders (TODO, lorem, sample copy)
- Bad-status list: sites that are inconsistent, invalid, or fail checks

---

## Steps for LLM

### Step 0: Read instructions
Tool: Read
Path: `tools/repair/CREPAIR.md`

### Step 1: Check registry integrity
Execute:
Tool: Bash
Command: `tools/check/status-report.sh`

If registry appears malformed or missing, report and stop.

### Step 2: List bad-status sites
- Use user-provided domains or batch IDs first.
- If none provided, use registry output to choose candidate sites (non-Q).
- A site is "bad-status" if ANY of the following:
  - Status code is unknown (not one of `- B d D O i I Q`).
  - Status is `D` but `DESIGN.md` is missing or fails `tools/design/check-design.sh`.
  - Status is `I` or `Q` but required outputs are missing or fail `tools/check/verify-site.sh`.
  - `tools/check/design-compliance.sh` fails for an implemented site.
  - Templated/placeholder content is found.
- Produce a list with domain, directory, status, and reason.

### Step 3: Verify site artifacts (per site)
Execute:
Tool: Bash
Command: `tools/check/verify-site.sh sites/<domain-vX>`

If needed, run focused checks:
`tools/check/html-check.sh`, `tools/check/js-syntax.sh`, `tools/check/file-stats.sh`

### Step 4: Validate DESIGN.md
Execute:
Tool: Bash
Command: `tools/design/check-design.sh sites/<domain-vX>/DESIGN.md`

Read specific sections when needed:
`tools/design/read-design.sh sites/<domain-vX>/DESIGN.md --summary`

### Step 5: Check for templated content
Use the Read tool to inspect `index.html`, `styles.css`, `script.js`, and `DESIGN.md`
Look for placeholders like TODO/TBD/lorem/boilerplate and repeated templated blocks.

### Step 6: Repair only the bad-status list
- Re-design/re-implement ONLY the bad-status sites listed in Step 2.
- NEVER overwrite the original `sites/<domain>-vN/`.
- Write all repair outputs under `sites/<domain>-vN.fix/`.
- Example: if the bad site is `sites/example.com-v2/`, repair to `sites/example.com-v2.fix/`.
- If repairs are requested, use existing scripts and Write tool only.
  - Do NOT modify registry or batch trackers unless the user explicitly requests it.

### Step 7: Report
- Report issues with file paths and evidence.
- Include the bad-status list and the fix version mapping.

---

## Output Format
Provide a concise report with:
- Registry integrity findings
- Bad-status list (domain, status, reason, fix target)
- Per-site issues (syntax, missing files, content richness, templating)
- Recommended fixes and required scripts