/execute

/dev:execute — 명세 기반 코드 구현

★ 최우선: .dev/DEV.md 가이드라인 확인

이 명령을 실행하기 전에 반드시 .dev/DEV.md 파일이 존재하는지 확인한다.

• .dev/DEV.md가 존재하면: 먼저 이 파일을 읽고, 그 안에 기록된 가이드라인에 따라 동작한다. DEV.md의 지시사항은 이 스킬 문서의 기본 동작보다 우선한다.
• .dev/DEV.md가 존재하지 않으면: 이 스킬 문서의 기본 동작 그대로 진행한다.

DEV.md는 프로젝트별 커스텀 가이드라인이다. 예를 들어 execute 시 특정 코딩 규칙, 테스트 요구사항, 배포 절차 등의 지시가 있을 수 있다.

---

0. 필수 입력: ARGUMENTS

이 명령을 사용하려면 반드시 ARGUMENTS를 제공해야 한다.

ARGUMENTS가 없으면 사용자에게 다음을 요청하라:

/dev:execute를 사용하려면 다음 정보를 프롬프트에 포함해 주세요:

필수:
  - 실행할 계획의 경로: .dev/<폴더이름>
    (해당 폴더에 plan.md가 있어야 합니다)

선택:
  - 실행할 Phase 범위 (예: "Phase 1만", "Phase 1~2")
  - 특별 지시사항

ARGUMENTS 예시:

예시 1: "/dev:execute 게시판"
예시 2: "/dev:execute 채팅 Phase 1만 실행해줘"
예시 3: "/dev:execute 인증리팩토링 Phase 2부터 이어서"

---

1. 이 명령의 목적

/dev:execute는 .dev/<폴더>/plan.md 명세서를 읽고 그대로 코드를 구현한다.

핵심 원칙 — SEDAI의 절대 실행 규칙:

"AI executes exactly what is specified—no interpretation, no improvisation, no assumptions." (명세서에 적힌 것만 정확히 실행한다. 해석, 즉흥, 가정은 금지.)

원칙	출처	적용
명세대로만 실행	SEDAI	명세서에 없는 기능을 추가하지 않는다. 명세서에 있는 것은 빠짐없이 구현한다
제약 기반 구현	AI Lang	constraints의 must/should/must_not을 코드에 정확히 반영한다
아키텍처 강제	Harness	명세서의 계층 구조와 의존성 방향을 위반하지 않는다

---

2. 실행 전 검증

코드를 작성하기 전에 반드시 다음을 확인한다:

2.1 명세서 존재 확인

.dev/<폴더>/plan.md 가 존재하는가?

없으면:

• 사용자에게 "먼저 /dev:plan <폴더이름>으로 명세서를 작성해 주세요."라고 안내한다.
• 명세서 없이 코드를 작성하지 않는다.

2.2 명세서 점수 확인

plan.md의 명세 완전성 점수를 확인한다.

• 95점 이상 (Ready): 바로 실행
• 80~94점 (Reviewed): 사용자에게 부족한 부분을 알리고 실행 여부를 확인
• 80점 미만 (Draft): 실행하지 않는다. 사용자에게 /dev:plan으로 보완을 요청

2.3 참조 문서 확인

plan.md의 Context에 참조 문서가 명시되어 있으면 반드시 읽는다:

• .dev/<다른폴더>/ 참조 문서
• 기존 코드베이스의 관련 파일

2.4 현재 코드 상태 확인

• plan.md의 Current State와 실제 코드가 일치하는지 확인
• 불일치가 있으면 사용자에게 보고하고 어떻게 처리할지 확인

---

3. 실행 규칙

3.1 SEDAI 절대 실행 원칙

하라:

• 명세서의 Entities에 정의된 모든 필드를 구현하라
• 명세서의 Key Flows에 정의된 모든 단계를 구현하라
• 명세서의 Constraints의 must 항목을 반드시 지켜라
• 명세서의 Architecture에 명시된 파일 구조를 따르라
• 명세서의 핵심 구현 코드가 있으면 그 패턴을 따르라

하지 마라:

• 명세서에 없는 기능을 "있으면 좋을 것 같아서" 추가하지 마라
• 명세서의 데이터 모델을 임의로 변경하지 마라
• 명세서의 제약사항(must_not)을 위반하지 마라
• 명세서에 명시되지 않은 라이브러리를 임의로 추가하지 마라

3.2 참조 문서 코드 보존 (SEDAI 원칙)

.dev/ 참조 문서에 핵심 소스코드가 있으면:

• 해당 코드의 패턴과 로직을 정확히 따른다
• 기존 코드를 실수로 변경하지 않는다
• 변경이 필요한 경우 명세서에 명시된 변경사항만 적용한다

3.3 아키텍처 강제 (Harness 원칙)

명세서의 Architecture 섹션에 정의된:

• 계층 구조: 의존성 방향을 위반하지 않는다
• 파일 구조: 명시된 위치에 파일을 생성한다
• 네이밍 규칙: 명시된 규칙을 따른다

3.4 제약사항 적용 (AI Lang 원칙)

명세서의 Constraints를 코드에 반영한다:

must:     → 반드시 구현. 빠지면 실패.
should:   → 가능하면 구현. 합리적 이유가 있으면 생략 가능.
must_not: → 절대 금지. 위반하면 실패.

---

4. 실행 프로세스

4.1 Phase 단위 실행

명세서의 Work Phases를 순서대로 실행한다.

각 Phase마다:

1. Phase 내용을 읽는다
2. 해당 Phase의 코드를 작성한다
3. 해당 Phase의 검증 방법을 수행한다
4. 진행 상태를 업데이트한다

4.2 진행 상태 기록

실행 중 .dev/<폴더>/progress.md에 진행 상태를 기록한다:

# 실행 진행 상태

## Phase 1: <이름> — ✅ 완료
- 완료일: YYYY-MM-DD
- 생성된 파일:
  - `src/models/Post.php`
  - `src/controllers/PostController.php`
- 검증 결과: 통과
- 비고: 없음

## Phase 2: <이름> — 🔄 진행중
- 시작일: YYYY-MM-DD
- 현재 작업: 댓글 CRUD 구현 중
- 남은 작업: 대댓글, 좋아요

## Phase 3: <이름> — ⏳ 대기

4.3 문제 발생 시 처리

실행 중 명세서와 충돌하는 상황이 발생하면:

명세서가 현재 코드와 충돌할 때:

1. 작업을 중단한다
2. 충돌 내용을 사용자에게 보고한다
3. 사용자의 결정을 기다린다
4. 결정 사항을 plan.md의 Decision Log에 기록한다

명세서에 명시되지 않은 판단이 필요할 때:

1. 가정으로 진행하지 않는다 (SEDAI 원칙)
2. 사용자에게 구체적으로 질문한다
3. 답변을 받으면 plan.md를 업데이트하고 계속한다

기술적으로 불가능한 부분이 있을 때:

1. 왜 불가능한지 근거를 설명한다
2. 대안을 제시한다
3. 사용자가 선택하면 plan.md를 업데이트하고 계속한다

---

5. 실행 완료 후

5.1 Acceptance Criteria 검증

plan.md의 Acceptance Criteria 체크리스트를 하나씩 검증한다.

## Acceptance Criteria 검증 결과
- [x] 비회원은 글 목록과 글 내용을 볼 수 있다 — 확인
- [x] 회원은 글을 작성/수정/삭제할 수 있다 — 확인
- [ ] 이미지 업로드가 동작한다 — Phase 3에서 구현 예정

5.2 문서 업데이트

실행 완료 후 다음을 업데이트한다:

1. plan.md: 상태를 Active → Completed로 변경
2. progress.md: 최종 상태 기록
3. 생성/수정된 파일 목록: progress.md에 기록

5.3 결과 보고

사용자에게 다음을 보고한다:

## 실행 완료 보고

### 실행한 명세서
- .dev/<폴더>/plan.md

### 완료된 Phase
- Phase 1: <이름> ✅
- Phase 2: <이름> ✅

### 생성/수정된 파일
- `src/models/Post.php` (신규)
- `src/controllers/PostController.php` (신규)
- `routes/web.php` (수정)
- ...

### Acceptance Criteria
- 10개 중 8개 통과, 2개 Phase 3 대기

### 주의사항
- (있으면 기록)

---

6. 실전 작업 흐름

1. ARGUMENTS에서 실행할 .dev/<폴더>를 파악한다
2. plan.md를 읽는다
3. 명세 점수를 확인한다 (95점 이상인지)
4. 참조 문서와 현재 코드를 확인한다
5. Work Phases를 순서대로 실행한다
   5a. 각 Phase의 코드를 작성한다
   5b. 검증 방법을 수행한다
   5c. progress.md에 기록한다
6. Acceptance Criteria를 검증한다
7. 문서를 업데이트한다
8. 결과를 보고한다

---

7. 완료 기준

• 명세서의 모든 Phase가 실행되었는가 (또는 지정된 Phase 범위)
• 명세서의 Entities가 모두 구현되었는가
• 명세서의 Key Flows가 모두 동작하는가
• 명세서의 Constraints (must)가 모두 지켜졌는가
• 명세서의 Constraints (must_not)을 위반하지 않았는가
• Acceptance Criteria가 검증되었는가
• progress.md에 진행 상태가 기록되었는가
• 명세서에 없는 기능을 임의로 추가하지 않았는가

명세서에 적힌 것을 빠짐없이, 명세서에 없는 것을 추가하지 않고 구현했을 때 실행이 완료된 것이다.