---
name: vibe-goal
description: 요청부터 리뷰를 거쳐 commit된 코드까지 목표 전체를 완료한다. `/vibe-plan`(또는 `/vibe-deep-plan`)으로 라우팅해 발행된 티켓을 받아, 티켓마다 새 서브에이전트를 각자의 할당된 branch와 worktree에 파견하고, 리뷰를 거친 티켓 결과를 단일 통합 작업공간에 재생한 뒤, 리뷰되고 게이트를 통과한 결과만 안전하게 반영한다. 사용자가 기능을 처음부터 끝까지 원할 때, "이거 전부 다 해줘"라고 말할 때, 또는 계획부터 리뷰까지 한 번에 실행해 달라고 할 때 쓴다.
disable-model-invocation: true
metadata:
  argument-hint: "목표: 아이디어, 요청, 명세, 또는 이슈 참조"
---

# 목표를 완료하기

목표 하나를 리뷰를 거쳐 commit된 코드까지 한 번에 실행한다. 이 스킬은 **오케스트레이션한다**. 직접 구현하지 않고 직접 계획하지 않는다. `/vibe-plan`과 `/vibe-deep-plan`은 사용자 전용이므로 직접 로드하지 않고, 사용자에게 실행을 안내하는 방식으로 라우팅한다.

**계획 작업은 직접 하지 않는다.** 트리아지는 요청을 분류해 다음 처리 경로를 정하는 절차다. 트리아지, 탐색, 명세 작성이나 수정, 분해, 티켓 설계, 티켓 발행은 그 두 스킬의 책임이다. `/vibe-plan`이 계획을 세운다. 일이 너무 크면 먼저 `/vibe-deep-plan`을 쓴다.

`/vibe-implement`를 실행하는 **새 서브에이전트**가 각 티켓을 구현한다. 목표 전체는 표준 리뷰로 마무리하고, `/rq`가 있으면 정식 요구사항 품질 게이트를 덧붙인다.

각 티켓은 자신만의 **할당된 branch와 worktree**를 갖는다. 이것은 다른 모든 티켓과 격리된 티켓별 작업공간이다. 서로 다른 티켓은 병렬로 실행할 수 있다. 같은 티켓의 구현, 리뷰, 발견사항 수정, 재개는 그 티켓의 정확히 하나의 할당된 작업공간을 재사용한다.

목표는 할당된 작업공간과 분리된 단일 **통합 작업공간**을 유지한다. 전체 목표를 검증하려고 리뷰를 거친 티켓 결과를 여기에 재생한다. 티켓 서브에이전트는 여기에 직접 commit하지 않는다. 재개는 기록된 통합 작업공간과 각 티켓의 기록된 할당된 작업공간을 정확한 기록으로 재사용한다. 같은 목표나 같은 티켓의 두 번째 작업공간을 열지 않는다.

이 오케스트레이터는 원장이나 인계 기록으로 할당 정보를 전달해 `vibe-implement`를 호출한다. `vibe-implement`는 모드를 나누지 않고 티켓 1개를 원자적으로만 실행한다. 이 실행은 직접 호출한 원자 실행과 같다. 실행 시점의 worktree 경로나 branch 이름만으로 상태를 추측하지 않는다.

[설정 문서와 기본값](../vibe-init/references/defaults.md)을 읽는다. 설정이 없으면 초기화를 요구하지 않고 로컬 Markdown으로 진행한다. 하위 계획·구현·리뷰에도 같은 트래커 규칙과 로컬 산출물 경로를 전달한다.

## 반영과 트래커 상태

`/vibe-review`는 읽기 전용이다: 발견사항을 보고할 뿐 트래커 상태를 절대 바꾸지 않는다. 리뷰 통과는 이슈를 닫을 권한이 아니다. 부모 명세 이슈는 읽기 전용이다: 트래커 변경 미리보기에 절대 포함하지 않고 수정하지도 않는다. 호스티드 트래커에서 명세와 유일한 티켓이 같은 이슈이면 그것은 티켓이지 부모가 아니다.

목표는 통합과 최종 반영을 책임진다. 인수 체크리스트와 이슈 닫기는 별개다. **호스티드** 트래커의 인수 체크박스는 `/vibe-implement`가 깨끗한 리뷰 뒤에, 사람이 머지하기 전에 켠다. 오케스트레이터는 인수 체크박스를 머지 후로 미루지 않는다. 오케스트레이터는 Stage 3에서 이슈를 닫지 않는다.

Stage 4에서 정확한 리뷰된 통합 commit SHA가 원본 대상 branch에 있다는 권위 있는 증거가 나온 후에만, 닫기·상태·코멘트의 정확한 미리보기를 보여준다. 그다음 쓰기 직전에 별도의 명시적 승인을 기다린다. 거절하거나 응답이 없으면 이슈를 열린 채로 둔다.

**버전 관리되는 local Markdown** 트래커의 경우 미리보기할 것이 없다. 각 티켓의 인수 체크박스는 그 티켓 자신의 구현 commit에 들어 있다. 그래서 통합과 반영이 코드와 인수 체크리스트를 함께 옮긴다. 어느 쪽이든 오케스트레이터는 티켓 파일을 직접 수정하지 않고, 대상 branch에 트래커 전용 commit을 추가하지 않는다.

## 오케스트레이터는 계획하거나 프로덕션 코드를 작성하지 않는다

문맥은 목표 전체를 파악하는 유일한 자료다. 문맥에는 티켓 그래프와 반영된 내용, 남은 내용을 기록한다. 문맥을 구현에 쓰면 실행이 중단된다.

- **직접 소스 파일을 편집하지 않는다.** 모든 코드 변경은 티켓 서브에이전트를 거친다.
- **diff를 전체 읽지 않는다.** 서브에이전트의 보고와 리뷰 판정을 읽는다. 특정 이견을 판정할 때만 코드를 연다.
- **하나의 컨텍스트 창에 머문다**(Stage 1 라우팅부터 마지막 티켓까지). 그래도 성능이 떨어지면 사용자에게 `/vibe-handoff` 실행을 요청한다. 이력이 아니라 원장을 넘긴다.

예외는 없다. 계획 단계는 `/vibe-plan`과 `/vibe-deep-plan`의 것이다. 라우팅하면 그 스킬들이 티켓을 만들고, 당신은 그들이 발행한 티켓을 받는다. 나중에 계획을 바꿔야 하면 Stage 1과 계획 스킬로 다시 라우팅한다. 직접 계획을 수정하지 않는다.

## Stage 1: 목표 라우팅

사용자가 가져온 것을 읽고, 한 줄로 진입점을 고른 뒤, 행동한다:

- 한 계획 세션에 담기엔 너무 큰 일(여기서 목적지까지 안개가 낀 상태): 먼저 `/vibe-deep-plan`으로 라우팅한다. 지도가 명확해지면, 그 Destination과 Decisions-so-far가 `/vibe-plan`의 **명세** 단계에 들어간다.
- 그 외(외부 요청, 느슨한 아이디어, 마무리된 대화, 명세, 이슈 참조): `/vibe-plan`으로 라우팅한다. `/vibe-plan`은 같은 입력에서 자기 진입 단계를 고른다.
- 이전 실행에서 발행된 티켓 세트: **Stage 2**로 건너뛴다.

두 라우팅은 실행을 일찍 끝내며, 이는 실패가 아니라 성공이다:

- Triage 결과가 `wontfix` 또는 `needs-info`이면 그 결과를 보고하고 멈춘다. 구현할 것이 없다.
- Triage 결과가 `ready-for-human`이면 위임할 수 없는 이유를 보고하고 멈춘다.

`/vibe-deep-plan`은 **다중 세션** 스킬이다. 거기로 라우팅하면, 세션이 지도를 만드는 도중에 가득 차서 이 실행이 끝날 것으로 예상한다. 그 경우 인계하고 재개한다. 전체 결정 지도와 그 구현을 한 창에 억지로 끼워 넣지 않는다.

## Stage 2: 원장과 통합 작업공간을 만들거나 재개

`/vibe-plan`이 티켓을 발행하면, 먼저 **정규 목표 ID**를 확립한다. 정규 목표 ID는 이 목표의 작업이 연결되는 내구 식별자다. 이 식별자는 발행된 명세 이슈나 경로이고, 재개할 때는 이전 실행이 원장에 기록한 같은 식별자다. 이 ID는 논리적 목표를 세션, 재개, 인계에 걸쳐 하나의 통합 작업공간에 연결한다. 이 ID 외에는 어떤 것도 그 목표를 그 통합 작업공간에 연결하지 않는다.

### 재개 또는 생성

무엇이든 만들기 전에, 먼저 이것이 **재개**인지 **새 목표**인지 결정한다. 재개는 사용자가 이전 목표 실행을 계속, 마무리, 또는 이어서 해 달라고 명시적으로 요청할 때다. 진입이 이전 실행을 명명하는 발행된 티켓 세트나 인계에서 올 때도 재개다. 그 외는 새 목표로 처리한다.

이 결정에 따라 기존 **작업공간 기록**을 찾는다. 작업공간 기록은 원장, 인계, 또는 호출자 기록이다. 이 기록은 정규 목표 ID를 기록된 원본 대상, 원본 고정점, 통합 branch, worktree 경로, 현재 소유자와 상태와 함께 통합 작업공간에 연결한다. **branch 이름, 번호, slug, 최신 `vibe/*` branch, 또는 비슷해 보이는 이름으로 매칭하지 않는다.** 맞아 보이는 이름은 매칭이 아니다. 정확히 하나의 기록만 재사용을 권한 부여한다.

- **정확한 기록, 활성 소유자 없음, worktree 존재하고 깨끗함**: 그 통합 작업공간을 있는 그대로 재사용한다.
- **정확한 기록, 활성 소유자 없음, worktree 없어졌지만 기록된 통합 branch는 존재**: 같은 통합 branch에 worktree를 다시 붙인다(`git worktree add <path> <recorded-branch>`). 새 branch는 만들지 않는다.
- **새 목표, 일치하는 기록 없음**: 이것은 진짜 **새 목표**다. 원본 대상 branch 또는 ref와 전체 목표에 걸쳐 유지할 **원본 고정점**을 기록한다. 정확히 그 고정점에서 시작하는 깨끗한 목표별 통합 branch와 별도 worktree를 만든다. 이것이 **통합 작업공간**이다.
  
  사용자의 원본 checkout은 checkout, reset, clean, stash, stage 또는 다른 작업으로 변경하지 않는다. 별도 작업공간은 commit object에서 만든다. 원본 checkout의 변경은 추적 여부와 관계없이 사용자 소유다. 더러워도 원본 checkout은 그대로 둔다. 깨끗한 별도 worktree를 만들 수 없으면 멈추고 보고한다. 원본 checkout과 공유 worktree를 재사용하지 않는다.

- **재개지만, 일치하는 기록을 찾을 수 없음**: 기록이 없으면 기존 작업공간을 안전하게 재사용할 수 없다. 새 형제 통합 작업공간을 만들면 같은 목표에 통합 작업공간이 둘 생기므로 만들지 않는다. 이 정규 목표 ID의 재개 기록이 없다고 보고하고 멈춘다. 사용자는 기록을 찾거나 새 시작을 명시적으로 허용한다. 그때까지 추측하거나 작업공간을 새로 만들거나 재사용하지 않는다.

- **재사용 조건이 맞지 않음**: 후보가 둘 이상이면 작업공간을 재사용하지 않는다. 다른 실행이나 서브에이전트가 기록된 작업공간을 점유해도 재사용하지 않는다. branch head 또는 worktree의 깨끗한 상태가 기록과 다르면 재사용하지 않는다. 새 형제 통합 작업공간을 만들거나 추측하지 않는다. 무엇을 찾았고 재사용을 막는 이유를 보고한다. 사용자가 충돌을 해결한다.

재사용할 때, 연속 실행의 고정점은 **최초 실행에서 기록한 원본 고정점**이지 현재 head가 아니다. Stage 4에서는 전체 목표 리뷰도 여전히 그 첫 고정점을 기준으로 실행한다.

### 원장

**원장**을 작성한다: 실행의 나머지 동안 문맥에 보관하는 유일한 산출물이다. 작업공간 기록이면서, 모든 티켓의 상태를 계속 갱신해 적는 문서다. 티켓은 제목으로 참조하고, 번호만으로는 절대 참조하지 않는다.

```markdown
## 목표

<한 줄: 이 실행에서 "완료"가 무엇을 의미하는지>

## 정규 목표 ID

<발행된 명세 이슈 / 경로, 또는 재개 시 이전 실행이 기록한 같은 식별자>

## 원본 대상

<최종 반영을 위해 선택한 branch 또는 ref; 사용자 checkout은 그대로 둔다>

## 원본 고정점

<최초 실행에서 잡은 commit SHA, `git rev-parse HEAD`에서; 전체 목표 리뷰가 이것을 기준으로 실행>

## 통합 작업공간

<목표별 통합 branch>; <별도 worktree 경로>; <원본 고정점>에 뿌리; 깨끗함; 소유자: <이 실행 / idle>; 상태: <new / resumed>

## 명세

<발행된 명세 이슈 / 경로 링크>

## 티켓

| 티켓 (정규 ID) | 할당된 branch / worktree | 블로커 | 상태 | Wave base (파견 시 통합 head) | 소유자 / 상태 | 반환된 리뷰된 SHA | 검증 | 재생 증거 |
|---|---|---|---|---|---|---|---|---|
| <제목> (링크) | `vibe/<id>` ; `.agents/worktrees/<id>` | 없음 | pending | 없음 | 없음 / idle | 없음 | 없음 | 없음 |
| <제목> (링크) | `vibe/<id>` ; `.agents/worktrees/<id>` | <제목> | running | <base SHA> | 서브에이전트 / active | <리뷰된 SHA> | <판정> | 없음 |
| <제목> (링크) | `vibe/<id>` ; `.agents/worktrees/<id>` | <제목> | integrated | <base SHA> | 없음 / idle | <리뷰된 SHA> | <판정> | 통합 작업공간에 재생 @ <head> |
```

상태는 `pending`, `running`, `integrated`, `landed` 순서로 바뀌거나, `blocked` 또는 `failed`가 된다. `integrated`는 리뷰를 거친 티켓 결과가 통합 head에 재생되고 그 head에서 티켓 귀속 검증을 통과했음을 의미한다. 이 상태는 의존 티켓의 블록을 푼다. Stage 4가 리뷰된 통합 결과가 원본 대상 branch에 있음을 증명한 후에만 오케스트레이터가 `landed`로 기록한다. 원장 상태는 이슈를 닫을 권한이 아니다.

첫 티켓 서브에이전트가 시작하기 전에 원본 고정점과 깨끗한 통합 작업공간을 기록한다. 재개할 때 원본 고정점은 최초 실행의 값으로 유지되며, 현재 head가 아니다.

무엇이든 파견하기 전에 원장을 사용자에게 보여주고 실행 순서를 확인받는다.

## Stage 3: 프런티어를 병렬로 처리하고, 결과를 통합 작업공간에 재생

**프런티어**는 블로커가 모두 `integrated` 또는 `landed`인 모든 티켓이다. **전체 프런티어를 한 번에** 파견한다. 준비된 모든 티켓은 병렬로, 각자 자신의 할당된 branch와 worktree에서 실행한다. 프런티어는 정의상 독립적이므로 준비된 티켓을 직렬화하지 않는다. 프런티어 안에서 서로 다른 티켓은 별도의 할당된 작업공간에서 동시에 실행된다. 다른 티켓에 의존하는 티켓은 블로커가 `integrated`될 때까지 기다린 뒤 다음 wave에 합류한다.

### 파견

프런티어의 각 준비된 티켓마다 티켓별 **할당된 작업공간**을 만든다: 통합 head에서 시작하는 전용 branch와 worktree. 그 head를 티켓의 **wave base**(리뷰가 그것을 기준으로 실행될 고정점)로 기록한다. 각 할당된 작업공간을 사용자의 원본 checkout이나 통합 작업공간을 checkout, reset, clean, stash, 또는 그 외 변경 없이 commit object에서 만든다. 할당된 branch, worktree 경로, wave base, 소유자, state를 서브에이전트가 시작하기 전에 원장에 기록한다. 티켓마다 **새 서브에이전트**를 동시에 파견한다. 각자 받고 오직 받는 것:

- 티켓 참조와 트래커에서 가져온 전체 본문. 서브에이전트가 티켓 위치를 추측하게 하지 않는다.
- 명세 링크, 필요하면 읽을 수 있는 문맥용.
- 할당된 작업공간 공급: 티켓 자신의 할당된 branch와 worktree, 그리고 정확한 wave base SHA.
- 지시: **이 티켓을 할당된 작업공간에서 원자적으로 구현한다. 구현 스킬의 테스트 주도 개발(TDD), 검증, 읽기 전용 리뷰 핵심을 따르고, 그 외에는 아무것도 하지 않는다.**
- 경계: **오직** 이 티켓만 구현한다. 범위 밖 문제는 고치지 않고 보고한다.
- 선형성 규칙: worktree에서 **할당된 티켓 branch에 직접** commit한다. wave base에서 선형을 유지한다. 원본 대상이나 통합 branch를 머지하지 않고 추가 branch나 worktree를 만들지 않는다. wave base가 옮겨갔으면 rebase나 머지 대신 보고한다.

원장의 각 티켓은 **정규 티켓 ID**, **할당된 branch와 worktree**, **wave base**(파견 시 통합 head), **소유자와 상태**, 그리고 **상태**를 가진다. **상태**는 `pending`, `running`, `integrated` 순서로 바뀌거나 `failed`가 된다.

**같은 티켓의 재시도**(리뷰 발견사항 수정 또는 정정 재파견)는 그 티켓의 **정확한 할당된 작업공간**을 재사용한다: 그 정규 티켓 ID에 기록된 같은 할당된 branch와 worktree다. 새 서브에이전트는 허용된다. 새 branch, worktree, 또는 티켓 ID는 금지된다. 할당된 작업공간이 최신 상태가 아니거나 commit하지 않은 변경사항이 있거나 head가 기록된 상태와 불일치하면, 그것은 멈추고 보고하는 조건이지 reset 단축키가 아니다. 정확한 작업공간을 보존하고, 불일치를 보고한 뒤 명시적인 해결을 기다린다.

이름, slug, 번호, 또는 최신 `vibe/*` branch로 작업공간을 절대 추측하지 않는다. 오직 정확한 기록으로만 재사용한다. 진짜 **새** 티켓(자체 정규 ID를 가진 split slice, 또는 Stage 4의 수정 티켓)만 자체 새 할당된 작업공간과 원장 항목을 얻는다.

모든 목표 파견 구현자는 이 **공유 반환 계약**을 따른다. 구현자는 할당된 작업공간에서 원자적으로 worktree의 할당된 티켓 branch에 직접 commit하고 wave base에서 선형을 유지한다. 구현자는 할당된 branch 이름, 정확한 wave base SHA, 정확한 리뷰된 head SHA, 검증 증거, 읽기 전용 `/vibe-review` 판정을 반환한다. 티켓 branch에 원본 대상이나 통합 branch를 머지하거나, 추가 branch나 worktree를 만들거나, 원본 checkout이나 통합 작업공간을 변경하거나, 할당된 작업공간을 clean하거나 delete하거나, 호스티드 이슈를 닫아서는 안 된다.

인수 체크박스는 `/vibe-implement` 트래커 갱신에 따라 켤 수 있다. 버전 관리되는 local Markdown 트래커의 경우 자기 티켓 파일은 branch content이며 같은 commit에 속하지, 별도 commit이 아니다. wave base가 옮겨갔으면 rebase나 머지 대신 그것을 보고한다. 빠진 branch, head SHA, wave base SHA, 검증 기록, 또는 리뷰 판정은 불완전한 반환으로, 완료된 티켓이 아니다.

대화, 다른 티켓, 또는 계획 이력을 붙여넣지 않는다. 자기 본문만으로 이해할 수 없는 티켓은 계획 결함이다: 계획 스킬로 다시 라우팅해 고치게 하고, 프롬프트에서 보완하지 않는다.

### 각 반환을 검증하고 통합 작업공간에 재생

서브에이전트의 `completed`는 주장이지, 사실이 아니다. 리뷰 통과는 보고 증거이지, 트래커 권한이 아니다. 반환된 결과가 받아들여지려면, 저렴하고 독립적으로 확인한다:

- 할당된 티켓 branch가 존재하고, head SHA가 반환된 리뷰된 SHA이며, 반환된 wave base SHA에 기반해 있다. 이 wave base는 파견 시 기록된 base와 일치해야 한다.
- 인수 조건이 충족됐다: 서브에이전트의 검증 증거와 읽기 전용 `/vibe-review` 판정에 따라.
- 리뷰 발견사항은, 있으면, 수정됐거나 사용자가 명시적으로 받아들였다.

같은 티켓 안에 머무는 실패나 리뷰 발견사항은 그 티켓의 **같은 할당된 작업공간**에서 실행된다: 같은 정규 티켓의 재시도이지, 새 작업공간, branch, 또는 티켓 ID가 아니다. 새 Stage 4 수정 티켓은 먼저 `/vibe-plan`이 설계하고 발행해야 한다. 그 후에만 `/vibe-goal`이 정규 ID와 할당된 작업공간을 추가할 수 있다. 할당된 작업공간에 commit하지 않은 변경사항이 있거나 상태가 모호하면, 멈추고, 보존하고, 보고한다. reset하거나 추측하지 않는다.

이 검증을 통과하면, 리뷰를 거친 티켓 결과를 통합 작업공간에 **재생**한다. 티켓은 **한 번에 하나씩** 재생한다. 재생 순서는 다음과 같다.

1. 통합 작업공간이 깨끗하고 head가 예상 통합 head와 일치하는지 확인한다.
2. 리뷰를 거친 티켓 commit을 그 head에 rebase 또는 cherry-pick한다.
3. fast-forward only(`--ff-only`)로 진행한다.
4. 패치 동등 포함을 검증한다. 패치 동등 포함은 리뷰를 거친 티켓 commit이 새 통합 head에 추가·누락·변경 없이 온전히 있다는 뜻이다.
5. **새 통합 head에서 티켓 자체 검증을 재실행한다.** 격리 상태에서 통과했던 패치도 합친 뒤에 깨질 수 있으므로, 통합 작업공간의 그 head에서 티켓의 테스트 명령이나 검증 명령을 실행하고 여전히 통과하는지 확인한다.

패치 포함과 재실행이 모두 통과할 때만 재생이 받아들여진다. 새 통합 head를 재생 증거로 기록한다. 이 재생과 무관한 더티 상태, 예상 밖 파일, 또는 통합 head 변경은 안전한 멈춤이다. 이 경우 보고하고, 사용자의 원본 checkout, 통합 작업공간, 또는 할당된 작업공간을 clean, reset, stash, delete, 또는 건드리지 않는다. 검증이 실패하면, 티켓은 `integrated`가 아니다. 두 작업공간 모두 보존하고 블로커를 보고한다.

재생 성공 후, 티켓의 반환된 리뷰된 SHA, 검증, 재생 증거를 원장에 기록하고, 소유자를 idle로 표시하고, 티켓을 `integrated`로 표시한다. 목표가 반영될 때까지 **할당된 티켓 branch와 worktree를 유지**: 같은 티켓 리뷰 수정이나 재개는 기록으로 그 정확한 branch와 worktree에 다시 붙으며, 새 것이 아니다. `integrated`는 통합 head 증거이지, 원본 대상 반영 증명이 아니다. Stage 3 동안 오케스트레이터는 이슈를 닫지 않는다. 호스티드 인수 체크박스는 구현자가 이미 켠다. 버전 관리되는 local Markdown 티켓 파일은 자기 티켓 commit 안에 도착하며, 오케스트레이터 편집으로가 아니다.

### 티켓이 실패할 때

이 중 어느 것인지 진단한다:

- **한 컨텍스트에 담기엔 티켓이 너무 큼**: 계획 스킬로 다시 라우팅한다. 그 스킬이 blocked slice로 쪼개 발행한다. 발행된 slice가 새 티켓으로 원장에 들어오며, 각자 자신의 할당된 작업공간을 갖는다. 쪼개진 부분은 의존성 순서대로 다음에 실행된다.
- **티켓 명세 불충분**: 구현을 멈추고 빠진 결정을 채우고 티켓을 고치도록 사용자에게 `/vibe-plan` 실행을 요청한다. `/vibe-goal`은 사용자를 심문하거나 티켓을 직접 수정하지 않는다. 계획 스킬이 다시 발행한 후에만 재시도한다.
- **코드베이스에 진짜 무언가 망가진 경우**: 블로커를 `/vibe-plan`에 보고한다. 계획 스킬이 발행한 블로커 티켓만 원장에 들어와 자기 할당된 작업공간에서 `vibe-debug` 스킬을 로드해 실행될 수 있다.
- **계획이 틀린 경우**: 실행을 멈추고, 보고하고, Stage 1로 돌아간다: 계획 스킬이 수정을 책임지고, 직접 계획을 수정하지 않는다. 틀린 계획을 바탕으로 만든 하위 티켓은 재시작보다 더 낭비다.

같은 티켓 안에 머무는 실패나 리뷰 발견사항은 그 티켓의 **같은 할당된 작업공간**에서 실행된다: 같은 정규 티켓의 재시도이지, 새 작업공간, branch, 또는 티켓 ID가 아니다. 새 Stage 4 수정 티켓은 먼저 `/vibe-plan`이 설계하고 발행해야 한다. 그 후에만 `/vibe-goal`이 정규 ID와 할당된 작업공간을 추가할 수 있다. 할당된 작업공간이 변경된 상태이거나 상태가 모호하면, 멈추고, 보존하고, 보고한다. reset하거나 추측하지 않는다.

## Stage 4: 리뷰, 게이트, 그리고 통합 결과를 안전하게 반영

모든 티켓이 `integrated`이고 `pending`, `running`, `blocked`, 또는 `failed`가 없으면, 통합 branch와 정확한 현재 head SHA를 리뷰 후보로 기록한다. 통합 작업공간이 깨끗한지 확인한다. 설명할 수 없는 더티 상태나 파일은 실행을 멈추고 그 branch와 SHA를 보존한다.

1. **전체 suite 한 번.** 타입 검사, 테스트, 저장소의 모든 검사를 티켓별이 아니라 통합 작업공간의 기록된 후보에서 실행한다. 사용자 checkout에서는 실행하지 않는다.

2. **분리된 리뷰 축.**

   1. Standards는 항상 실행한다. 목표가 보안, 인증, 권한, 영속성, 트랜잭션, 외부 연동을 건드렸거나 위험 감사를 요청했다면 Risk도 실행한다.
   2. 3단계에서 `/rq`를 실행할 수 있으면 Spec은 게이트가 처리하므로 리뷰 축에서 생략한다.
   3. `/rq`가 없으면 Spec을 유지한다. 고위험 목표라면 Standards + Spec + Risk를 실행한다. 저위험 목표라면 Standards + Spec을 실행한다.
   4. Stage 2 고정점부터 기록된 통합 branch와 commit까지 `vibe-review` 스킬을 로드해 실행한다. 티켓별 리뷰는 각자 한 slice만 봤다.
   5. 이 리뷰는 티켓 결과 사이의 연결을 살핀다. 추가 발견사항도 이 부분에서 찾는다.

3. **Spec 판정.**

   1. 이 세션에 `/rq` 스킬이 있으면 `/rq`를 실행한다. Stage 2 고정점을 change 경계로 쓰고, 기록된 통합 결과를 head로 쓴다. 구현 도메인으로 범위를 좁힌다. 구현 도메인은 `CODE`이며, 목표에 필요하면 `MIGRATION`을 추가한다.
   2. 소스 요구사항은 목표의 **완료 정의**다. 실행이 실제로 약속한 인수 조건을 완료 정의로 쓴다. 명세에 인수 조건이 없으면 원장의 목표 줄을 쓴다.
   3. 그 너머의 user stories는 추적 행으로 남으며, 범위 밖이다.
   4. 큰 명세의 모든 story를 게이팅하면 티켓별 리뷰가 이미 다룬 것을 중복한다. 게이트는 항목별 상태와 집계된 `PASS` / `WARNING` / `NEEDS_REVIEW` / `FAIL`을 반환한다.
   5. 기본으로 게이트의 `LIGHT` tier를 쓴다.
   6. 목표가 보안, 인증, 권한, 영속성, 트랜잭션, 외부 연동처럼 항상 무거운 tier가 필요한 영역을 건드렸을 때만 `HEAVY`를 쓴다.
   7. 이 영역은 Risk를 켜는 고위험 신호와 같다. 직접 `/vibe-review`가 `/rq`를 자동 호출한다는 뜻은 아니다.
   8. Operation, deployment, 데이터 의무는 **별도 게이트**다. 별도 게이트는 구현 판정을 낮추지 않는다. 사용자가 요청하지 않으면 여기서 실행하지 않는다.
   9. `/rq`가 없으면 **이 단계를 건너뛴다.** 정식 명세 게이트를 건너뛰었다고 밝힌다. `PASS`/`FAIL`을 지어내지 않는다. `/rq`가 없다는 이유만으로 반영을 불안전하다고 보지 않는다.

4. **판정하기.**

   1. Standards 발견사항, 켰다면 Risk 발견사항, 그리고 게이트를 실제로 돌렸다면 그 보고를 하나로 합치지 않고 나란히 보여준다.
   2. 실제로 실행한 게이트가 `not satisfied` 또는 `unknown`으로 표시한 항목과 사용자가 고치기 원하는 Standards 또는 Risk 발견사항은 **수정**이다.
   3. **수정**이 있으면 계획 스킬로 다시 라우팅한다. 직접 inline patch하지 않는다.
   4. 계획 스킬이 새 티켓을 설계하고 발행한다.
   5. 수정 티켓은 자체 정규 ID와 자체 할당된 작업공간을 가진 진짜 새 정규 티켓이다.
   6. 수정 티켓을 Stage 3에서 다른 티켓처럼 파견하고 재생한다.
   7. 수정 티켓이 통합된 후, 게이트를 돌렸다면 게이트를 다시 실행하고 돌리지 않았다면 `/vibe-review`를 다시 실행한다. `FAIL`에서 목표가 닫히지 않는다.

5. **안전할 때만 반영.**

   1. 깨끗하고 독립된 반영 context를 쓴다. 사용자의 원본 checkout에서 checkout, reset, clean, stash, 또는 머지하지 않는다.
   2. 대상이 기록된 고정점에서 옮겨갔으면 통합 branch를 대상의 최신 head에 rebase한다.
   3. 대상이 옮겨갔으면 새 후보에서 Stage 4 전체 suite을 다시 실행한다.
   4. 대상이 옮겨갔으면 새 후보 SHA를 기록한다.
   5. **fast-forward only**(`--ff-only`)로 원본 대상에 정확한 리뷰된 통합 commit을 반영한다.
   6. 대상에 merge commit을 만들거나 force-push하지 않는다. 대상을 reset하거나 다시 쓰지 않는다.
   7. 작업공간 더티 상태, 예상 밖 파일, 불분명한 충돌, 실패한 재실행, 또는 반영 증명 누락이 반영을 안전하지 않게 하면 반영하지 않는다. 그 경우 리뷰된 통합 branch와 SHA를 보존하고 보고한다. 트래커 상태를 그대로 둔다.
   8. 명확히 의도된 반영 충돌은 명시적이고 의도된 충돌 path만 스테이징해 해결한다. 전체 worktree, 사용자 파일, 비밀 파일, 또는 예상 밖 파일을 스테이징하지 않는다.

6. **반영을 증명한 뒤, 닫기 승인을 구한다.**

   1. 정확한 리뷰된 통합 commit SHA가 원본 대상 branch에 있음을 권위 있는 증거로 확인한 후에만 영향받은 티켓을 `landed`로 기록한다.
   2. 버전 관리되는 local Markdown 트래커는 반영할 때 각 티켓의 체크된 인수 체크리스트도 옮긴다. 미리보기하거나 쓸 것이 없다. 대상에 트래커 전용 commit을 절대 추가하지 않는다.
   3. 호스티드 트래커의 인수 체크박스는 구현 처분에서 이미 켜져 있다.
   4. 각 티켓의 닫기, 상태, 코멘트 제안만 미리 보여준다. 부모 명세 이슈는 제외한다. 명세이자 유일한 티켓인 이슈는 제외하지 않는다.
   5. 미리보기한 변경만 적용하기 전에 별도의 명시적 승인을 기다린다. 거절하거나 응답이 없으면 이슈를 열린 채로 둔다.

7. **보고.** 다음을 보고한다.

   - 목표
   - 링크와 함께 반영된 티켓
   - 통합 branch와 리뷰된 commit
   - 최종 반영 증거
   - 게이트를 돌렸다면 그 전체 상태, 돌리지 않았다면 건너뛴 사실
   - Standards 발견사항, 그리고 켰다면 Risk 발견사항
   - 의도적으로 남긴 미완료 사항

반영 증명과 승인 후에도 부모 명세 이슈를 어떤 트래커 변경 미리보기에서도 절대 닫거나, 수정하거나, 포함하지 않는다.

## 실행 종료: 정확히 하나의 산출물만 남긴다

유일한 최종 반영·발행 대상은 **목표 통합 결과**다. 이 결과는 원본 대상 branch 위에 있는 리뷰된 통합 commit을 가리킨다. 할당된 티켓 branch는 호출자가 소유하는 임시 작업용 branch이며, 티켓의 구현, 리뷰, 수정, 재개에 걸쳐 재사용한다. 이 branch는 결코 standalone 발행 대상이 아니다. 호스티드 트래커에서 티켓별 PR이나 MR을 열지 않는다.

최종 보고 후 실행은 **정확히 하나의 생존 산출물**만 남기고 나머지를 정리한다. 정리 순서는 worktree 먼저, branch 나중이다.

- **반영 증명이 있는 경우**: 생존자는 원본 대상 branch다. 이 실행이 만든 티켓 할당 산출물과 통합 작업공간을 정리한다. 각 산출물은 먼저 `git worktree remove <path>`로 worktree를 지우고, 그다음 `git branch -D`로 branch를 삭제한다. 원본 대상만 남긴다.
- **반영 증명이 없는 경우** (반영이 안전하지 않거나 승인되지 않음): 생존자는 리뷰된 통합 branch와 기껏해야 그 자체 worktree다. 통합된 티켓의 할당 산출물은 다음 두 조건을 모두 만족할 때만 정리할 수 있다. 첫째, 그 패치 동등 포함이 통합 생존자에서 증명되어야 한다. 둘째, 같은 티켓 리뷰 수정이나 재개에 더 이상 필요하지 않다. 둘 중 하나라도 불분명하면 보존하고 명명된 예외로 보고한다. 반영이 증명되지 않은 branch를 절대 force-delete하지 않는다.

branch를 삭제하기 전에 항상 worktree를 먼저 지운다. worktree가 checkout한 branch는 그 worktree가 있는 동안 삭제할 수 없다. branch를 먼저 삭제하면 실패만 한다. 사용자 소유 또는 무관한 branch나 worktree를 절대 삭제하거나 변경하지 않으며, 절대 clean, reset, 또는 stash하지 않는다. 실행이 블로커에서 멈추면, 영향받은 산출물을 보존하고 보고한다. 티켓의 할당된 작업공간은 같은 티켓 리뷰 수정과 재개(Stage 3) 동안 유지되며, 목표가 반영될 때까지 삭제하지 않는다.