Auto Fix

---
name: auto-fix
description: 버그 수정 — 재현과 최소 수정 중심으로 문제를 해결합니다
compatibility: omp
---

# auto-fix — 버그 수정 스킬

## OMP Invocation

- `/auto fix ...`
- `/auto-fix ...`
- Load detail skill `auto-fix` for either entrypoint.


**프로젝트**: autopus-adk | **모드**: full

## 설명

버그를 재현하고 최소한의 변경으로 수정합니다. 재현 테스트를 먼저 작성합니다.

## 사용법

```
/auto fix "버그 설명"
/auto fix --file path/to/file
/auto fix "회귀 버그" --auto
```

### 플래그

| Flag | Description |
|------|-------------|
| `--file <path>` | 수정 범위를 특정 파일로 좁힙니다. |
| `--auto` | 확인 단계 없이 바로 수정 흐름을 진행합니다. |

## 절차

1. 버그 재현 테스트 작성 (먼저)
2. 테스트 실패 확인 — 컴파일되고 버그 단언에서 실패하면 수정 전에 재현 테스트를 잠급니다 (아래 재현 테스트 잠금)
3. symptom location, owning function/path, caller 목록 또는 grep evidence 확인
4. caller/shared root-cause path 확인 후 패치 위치 결정
5. 최소 코드 변경으로 수정
6. 테스트 통과 확인
7. 영향받은 회귀 테스트 실행. 공통 전체 검증은 통합 후 한 번 수행하고, 입력·환경 변경이나 열린 finding이 있을 때만 관련 검사를 반복합니다.
8. 완료: 재현 테스트 잠금을 풀고 판정을 확인합니다 (아래 재현 테스트 잠금)

## 재현 테스트 잠금

Step 번호는 `/auto fix` 라우터 본문의 단계입니다. Step 1 재현은 절차 1-2, Step 4 검증은 절차 6-7입니다.

- 2단계에서 테스트가 컴파일되고 버그 단언에서 실패하면 코드를 고치기 전에 잠급니다. `<test-path>`는 현재 디렉터리 기준 테스트 파일 경로이며, 공백이나 셸 메타문자가 있으면 작은따옴표로 감쌉니다. exit 1이면 아무것도 잠기지 않았으니 경로를 확인하고 다시 실행합니다. 잠금과 해제는 테스트에서 가장 가까운 프로젝트 루트, 곧 테스트 위로 처음 만나는 `autopus.yaml`이 있는 디렉터리에서 실행합니다. 바깥 프로젝트에서 실행하면 둘 다 exit 1로 끝나고 그 루트를 알려 줍니다.

  ```bash
  auto fix lock -- <test-path>
  ```

- 잠금 중에는 edit guard가 그 테스트를 고치는 파일 편집 호출을 `[fix_lock]`으로 거부합니다. 테스트 대상 코드를 고치고, 테스트 자체가 틀렸다면 멈추고 사용자에게 묻습니다.
- Do NOT run auto fix unlock before Step 4 verification passes.
- 완료 단계(절차 8)에서 잠금을 풀고 판정을 읽습니다.

  ```bash
  auto fix unlock --json -- <test-path>
  ```

- exit 0은 모든 판정이 `unchanged`라는 뜻입니다. exit 3(`modified`, `missing`, `unverifiable`)은 잠근 뒤 어떤 경로로든 테스트가 바뀌었다는 뜻이므로 수정이 끝나지 않은 것입니다. 판정을 보고하고 멈춘 뒤 사용자에게 묻습니다. `unchanged`를 얻으려고 다시 잠그거나 테스트를 고쳐 쓰지 않습니다.
- unlock exit 1은 해제가 끝나지 않았다는 뜻입니다(경로에 잠금이 없거나, 제거 오류로 잠금이 남음). 이것도 수정이 끝나지 않은 것이므로 오류를 보고하고 멈춘 뒤 사용자에게 묻습니다.
- 완료 보고 전 확인: Lock verdict is unchanged (any other verdict: not complete, stop and ask the user)
- 테스트를 만들 수 없는 수정(CLI 전용 등)은 재현 절차를 문서로 남기고, 잠금과 판정 대신 보고에 `lock: not applicable`을 적습니다.
- edit guard가 편집을 막지 못하는 플랫폼에서도 unlock 판정은 잠근 뒤 남아 있는 변경을 보고합니다.

## Change Contract Boundary

- 기존 계약 안의 버그 수정은 `bugfix_existing_contract`입니다. 저위험이며 SPEC 세트가 필요 없습니다. 승인된 SPEC이 해당 동작을 담고 있으면 `auto spec change <SPEC-ID> --class bugfix_existing_contract --ac <AC-ID,...> --surface <path,...> --verify "<command>"`로 계약을 기록해 참조 acceptance ID와 검증 계획을 남깁니다.
- auth/billing/data/migration/security 경로를 건드리거나, production code가 두 module root에 걸치거나, 새 exported API/contract를 바꾸면 `auto spec change`가 `escalate_to_full_spec`을 보고하고 계약을 쓰지 않습니다. 이때는 `/auto plan`으로 승격합니다. 안전 게이트는 두 경로 모두 `required`로 유지됩니다.

## 규칙

- 재현 테스트 없이 수정하지 않음
- 버그 범위 외 코드 변경 금지
- caller/shared root-cause evidence 없이 증상 위치만 고치는 계획은 `revise-target`으로 표시
- focused patch는 증상 위치가 root cause이거나 affected caller가 하나뿐이라는 근거가 있을 때만 허용
- final response에는 caller/shared root-cause checked, focused patch target, minimum sufficient verification을 receipt로 요약
- 전체 복구/후속 가이드는 `/auto fix ...` 라우터 본문을 우선합니다.

## Branding Formats

### Error Recovery (show on fix failures)

```
✗ {subcommand} 실패: {error description}
  복구 옵션:
  1. 오류 내용을 확인하고 재시도: /auto fix {args}
  2. /auto doctor  (시스템 상태 진단)
```

### Next Step Auto-Detection (show after fix completes)

```
다음 단계: {recommendation}
```

Detection order:
1. SPEC status `implemented` → `✓ 구현 완료 → /auto sync {SPEC-ID}`
2. SPEC status `approved` → `✓ SPEC {SPEC-ID} 승인됨 → /auto go {SPEC-ID}`
3. No SPEC context → recommend running `/auto review` to verify the fix