런치

런치은(는) 무엇을 하나요?

런치는 선착장의 인도 실행입니다: 미션 브리핑부터 출하되고 검증된 변경까지입니다. 이는 검증 가능성 경계에 서 있습니다 — 에이전트는 반복 가능하고 증거로 수용 가능한 모든 것을 지속적으로 실행합니다; 인간은 시스템이 판단할 수 없거나 비용이 많이 드는 실패가 발생하는 것을 결정합니다. 목표는 최대 자동화가 아니라 검증 가능한 작업의 최대 위임이므로, 인간의 시간은 오직 인간만이 내릴 수 있는 결정에만 사용됩니다.

모든 단계에 적용되는 검증 가능성 테스트: 이것이 잘못 수행되면 시스템이 감지할 수 있습니까? 자동으로 재실행하거나 롤백할 수 있습니까? 둘 다 예 → 에이전트. 고유한 답변 없음, 시스템이 판단할 수 없음, 또는 잘못될 경우 비용이 많이 듦 → 인간.

런치는 선착장이 존재한다고 가정하며, 존재하지 않으면 실행을 거부합니다. 선착장 게이트는 모든 호출의 첫 번째 작업으로, 문서 언어 해석 및 제공된 사양 읽기 전에 수행됩니다:

• 전체 드라이독 --check 감사 실행 — 누락된 표면, 누락되거나 유효하지 않은 CONTEXT.md 프론트매터 documentLanguage, 끊어진 경로, 코드에서 사용되지 않은 용어집 용어, 참조되지 않은 표준. 이것이 단일 기준입니다: Launch는 자체적인 별도 시설 인벤토리를 수행하지 않습니다.
• 실행 가능/신뢰도 높은 발견 사항은 실행을 하드 블록합니다: 각 발견 사항을 그대로 나열하고, /oh-my-claudecode:drydock을 가리키며, 실행이 시작되지 않았고 아티팩트가 생성되지 않았다고 명시하고 중지합니다. 명시적 재정의 없이는 모든 발견 사항을 차단하는 것으로 처리합니다.
• 좁은 재정의(명시적 의도만): 신뢰도 낮은 발견 사항, 드라이독 보고서에서 명시적으로 오탐(false positive)으로 분류된 발견 사항, 또는 사용자가 명시적으로 선언한 스크래치/임시 저장소는 의도적이고 호출별 사용자 의도가 있는 경우에만 재정의될 수 있습니다 — 재정의는 발견 사항 또는 스크래치 범위를 명명해야 하며, 신뢰도 높은 실행 가능한 발견 사항을 무음으로 무시해서는 안 됩니다. 일반 우회 플래그는 없습니다.
• 현재 감사 한계: 현재 --check는 기계 판독 가능한 발견/심각도 계약 또는 실행 파일이 없는 스킬 명령 체크리스트입니다 — 구조화된 계약이 존재할 때까지 심각도 분류는 드라이독 보고서의 문구에 의존합니다. 기계 판독 가능한 발견/심각도 종료 계약이 의도된 후속 조치입니다; 게이트 문구는 기계적으로 의존할 수 있는 것과 의존할 수 없는 것에 대해 정직하게 유지됩니다.
• 깨끗한 감사(또는 명시적으로 재정의된 신뢰도 낮음/오탐/스크래치 범위)는 실행을 허용합니다. 모든 증적 슬롯(CONTEXT.md, docs/adr/, docs/business/)과 시설 표면은 그 시점에 이미 존재합니다; Launch는 결정이 확정됨에 따라 증적을 채우지만 슬롯을 생성하지는 않습니다.
• 규칙 항목은 CLAUDE.md입니다 — 선착장 지도는 대체재를 인정하지 않습니다.

경계

인간 체크포인트(중요한 20%)	에이전트 지속 실행(기계적인 80%)
C1 미션 브리핑 작성(목표 + 범위)	사실 조사 및 저장소 탐색, 자체 수행
C2 수락 기준 + 테스트 심 목록 승인	인터뷰 준비: 권장 답변이 포함된 프론티어 질문 일괄 처리
C3 티켓 분해 승인(세분성, 차단 에지)	사양 및 티켓 작성, 기계적 검증(독립성, 입증 가능성, 하나의 컨텍스트에 적합)
C4 실행 중 발생하는 불가역적 결정에 답변(일괄, 비동기)	합의된 심에서의 tdd 구현, 빌드, 테스트, 회귀
C5 완료 보고서 수락; 공개 가정 및 라인별 침전물 목록을 통해 거부권 행사	코드 리뷰, 변경 사항 전반 검증, 팀 프론티어 스케줄링, 전체 증적

체크포인트 사이에 파이프라인은 유휴 상태가 되지 않습니다: 에이전트는 보류 중인 인간 답변에 의존하지 않는 모든 프론티어 티켓을 계속 작업합니다.

생애주기 태세

런치는 OMC의 기존 생애주기에 대한 상태 비저장 구성입니다 — 자체 런타임 상태 머신을 소유하지 않습니다:

• 팀은 작업 상태, 전환, 취소 및 런타임 정리를 소유합니다; Launch는 팀의 계약 외부에서 이를 변경하지 않습니다.
• 표준 plan → execute → review → verify 표면은 기존 생애주기 동작을 소유합니다. Launch가 작성한 아티팩트는 .omc/specs/<feature-slug>/, CONTEXT.md, docs/adr/, 및 docs/business/로 제한됩니다 — 또한 C5 승인 후에만 5단계 테이블에 명명된 침전물 슬롯이 있습니다.
• Launch에는 자동 재개가 없습니다. 중단 후 아티팩트와 현재 팀 상태를 다시 읽지만, 소유 팀 생애주기가 지원되는 종료/정리 경계에 도달한 후에만 새로운 명시적 Launch 호출을 통해 계속합니다. 인간 승인을 추론하거나 in_progress 작업을 재생하지 마십시오.
• 모호한 노력은 항해사의 관할권입니다: 안개 게이트가 /oh-my-claudecode:ask-navigator로 라우팅되면 실행이 시작되지 않습니다 — 아티팩트 없음, 부분 상태 없음. 항해사의 지도가 세션 간 유일한 전달자입니다; 런치는 항해사가 반환하는 미션 브리핑에서만 재개됩니다.
• Launch는 자체 승인 영수증, 개정 카운터, 재생 로그, 취소 경로, 롤백 메커니즘 또는 정리 생애주기를 추가하지 않습니다.

이 스킬의 모든 내구성 주장은 숨겨진 런타임이 아닌 디스크의 파일에 대한 주장입니다.

0단계 — 진입

깨끗한 선착장 게이트를 통해서만 실행이 이 단계에 도달합니다. 제공된 사양을 읽거나 1단계에 진입하기 전에 문서 언어를 확인합니다. 현재 호출에서 명시적인 인간 선택이 우선합니다; 그렇지 않으면 CONTEXT.md 프론트매터의 정확한 안정 키 documentLanguage에서 유효한 BCP-47 스타일 태그를 읽습니다; 그렇지 않으면 CLAUDE.md에서, 그 다음 README.md에서 만장일치의 높은 신뢰도 추론이 필요합니다. 지속된 베어 또는 지역 전용 중국어 태그는 스크립트가 모호하므로 해당 권한 계층에서 한 번 질문해야 하며, 추론으로 우회해서는 안 됩니다. 누락, 혼합, 충돌, 낮은 신뢰도, 유효하지 않은 명시적 또는 스크립트가 모호한 중국어 증거는 한 번의 일괄 언어 질문이 필요합니다; 추측하지 마십시오. 중국어는 명시적인 zh-Hans 또는 zh-Hant 스크립트 태그로 확인되어야 합니다. zh-Hans-*는 간체 동반자를 선택하고 zh-Hant-*는 번체 동반자를 선택하며 전체 정규화된 태그는 유지됩니다. 확인된 정규화된 태그를 CONTEXT.md에 다시 저장하여 새로운 명시적 호출이 숨겨진 대화 상태 없이 읽을 수 있도록 합니다. 인간은 이러한 아티팩트를 읽고 유지 관리합니다; 에이전트는 언어에 구애받지 않습니다.

산문과 인간 대상 레이블/지역화 가능한 스칼라 값만 지역화합니다. 경로, 슬래시 명령, 플래그, 코드 펜스, 플레이스홀더, 프론트매터 키 및 기계 의미 값, YAML/JSON 키, 생애주기 토큰(plan, execute, review, verify), 상태 열거형(pending, in_progress, completed, failed, ready-for-agent), ID, 티켓 blockedBy, 공개 Team blocked_by, 및 모든 파서/제어 토큰은 바이트 단위로 안정적으로 유지됩니다. 참조 언어 동반자는 상호 배타적입니다: 정확히 하나의 선택된 렌더링을 내보내고, 이중 언어 중복 제목이나 레이블은 사용하지 않습니다.

• 다른 모든 것보다 먼저 간단한 자체 확인: 브리핑에 목표, 범위 경계 및 비목표가 명시되어 있습니까? 두 개 이상 누락된 경우 이를 알리고 한 번의 다듬기 패스를 요청하십시오 — 부드러운 브리핑에서 파이프라인을 실행하면 모호성이 자신감 있는 출력으로 변환됩니다.
• 안개 게이트: 다듬기 패스 후 항해사의 안개 테스트를 적용합니다 — Q1: 목적지를 한 문장으로 말할 수 있습니까(이 노력이 찾고 있는 사양, 결정 또는 변경)? Q2: 처음 세 가지 결정을 지금 바로 정확하게 말할 수 있습니까, 아직 답할 수 없더라도? 어느 하나라도 아니오 → 실행이 시작되지 않습니다: 이를 명확히 명시하고, 아티팩트가 생성되지 않았다고 기록하고, /oh-my-claudecode:ask-navigator(선착장의 항해사는 안개를 결정 티켓 지도로 작성하고 미션 브리핑을 반환함)를 권장하고 중지합니다. 남은 질문과 이미 확정된 어휘를 전달하여 항해사의 W1이 다시 질문하지 않도록 합니다.
• 지도 확인: 제공된 사양을 읽거나 1단계에 진입하기 전에 열려 있는 navigator:map(트래커 레이블 또는 .omc/wayfinder/ 아래)을 찾습니다. 존재하고 이 호출이 새 브리핑을 제공하지 않는 경우 → /oh-my-claudecode:ask-navigator를 권장하여 해당 지도의 다음 결정을 작업하고 중지합니다. 존재하고 새 브리핑이 제공된 경우 → 진행하기 전에 한 가지 질문을 합니다 — 기존 지도를 계속할지, 아니면 새 노력을 시작할지.
• 사양 경로 제공됨 → 읽고 2단계로 이동합니다.
• 미션 브리핑 → 1단계.
• 단일 포인트 수정 → 실행에 넘기고 종료합니다.

1단계 — 수렴(인간이 결정하고 에이전트가 준비)

설계 트리 프로토콜로 인터뷰를 실행합니다: 결정과 그 종속성을 매핑한 다음 프론티어 라운드로 작업합니다 — 현재 질문 가능한 모든 질문을 한 라운드로 일괄 처리하고, 번호를 매기고, 각각 권장 답변을 제공합니다. 인간이 답변합니다; 트리가 재구성됩니다; 프론티어를 다시 계산합니다. 사실은 항상 저장소 증거에서 하위 에이전트에 의해 자체 제공됩니다 — 인간은 탐색으로는 해결할 수 없는 것에 대해서만 질문을 받습니다.

각 항목이 확정되는 즉시 작성되는 증적:

• 도메인 어휘 → 저장소 루트의 CONTEXT.md(용어당 하나의 항목)
• ADR 테스트를 통과한 결정(되돌리기 어렵고, 컨텍스트 없이 놀랍고, 실제 트레이드오프) → docs/adr/NNNN-<slug>.md
• 수렴 중 발견된 비즈니스 규칙 및 배경 → docs/business/(비즈니스 질문당 하나의 문서, 시작 단락은 그것이 중요한 이유를 명시)

여기서 수렴하지 않는 것은 정상적인 작업이며 실패가 아닙니다: 프론티어가 비워지지 않으면 남은 질문을 순위별로 제시합니다 — 이것은 C2의 입력이며 오류가 아닙니다. 남은 질문 자체를 정확하게 말할 수 없으면(안개 테스트 Q2 실패), 목적지 자체가 불안정한 것이며 이는 C2의 권한을 벗어납니다: 중지하고, 이미 확정된 사항(CONTEXT.md의 어휘, 답변된 질문)을 기록하고, /oh-my-claudecode:ask-navigator를 권장하고 종료합니다 — 파이프라인은 목적지를 발명하지 않습니다.

로프트 우회. 정확하지만 산문으로 해결할 수 없는 남은 질문 — 설명이 아닌 보거나 클릭해야 하는 것(UI가 어떻게 보여야 하는지, 상태 모델이 올바른지) — 더 많은 질문이 아닌 아티팩트로 답변합니다: "loft"와 함께 Skill 도구를 호출하고, 캡틴이 반응하도록 하고, 그 반응을 인터뷰에 다시 통합합니다. 로프트된 아티팩트는 C2의 입력입니다; 캡틴은 그들이 들은 것이 아니라 본 것에 서명합니다.

항구 브리핑. /oh-my-claudecode:harbor가 전달한 미션 브리핑에는 링크와 적용 조건이 있는 서명된 결정이 포함되어 있습니다: 이미 만들어진 것으로 소비합니다 — 변경되지 않은 비즈니스 목표를 다시 묻지 마십시오. 증거가 수집된 이후 코드가 이동한 경우(새 헤드, 변경된 베이스), 영향을 받는 기술 증거를 다시 확인합니다; 서명된 브리핑을 넘어서는 새 구현 범위는 여전히 자체 승인이 필요합니다.

2단계 — 사pec 합성(에이전트 초안 → C2 승인)

.omc/specs/<feature-slug>/spec.md 합성:

# <Feature> 사양
## 문제
## 해결책
## 사용자 스토리        (번호가 매겨지고, 각각 테스트 가능한 수락 기준 포함)
## 구현 결정
## 테스트 결정   (외부 동작만)
## 범위 외

전체를 초안으로 작성한 다음 C2에서 중지합니다: 수락 기준과 테스트 심 목록을 인간 승인을 위해 제시합니다. 심은 저장소 증거와 심층 모듈 규율(공개 인터페이스, 기존 테스트 심, 깊이 분석)에 의해 선택됩니다; 인간이 목록을 확인하거나 수정합니다 — 인간이 승인하지 않은 심은 테스트를 받지 않습니다.

내구성 게이트(에이전트 적용, 승인 필요 없음): 사양과 티켓은 계약을 전달하며 좌표(파일 경로, 줄 번호)는 전달하지 않습니다. 결정을 산문보다 더 잘 인코딩하는 조각(상태 머신, 리듀서, 스키마)은 예외이며 그 출처(일반적으로 로프트)를 명시합니다.

3단계 — 티켓 분해(에이전트 초안 → C3 승인)

.omc/specs/<feature-slug>/tickets/ 아래에 수직 슬라이스로 분할:

• NN-slug.md, 티켓당 하나의 파일, 종속성 순서, 각각 blockedBy: [ids] 선언
• 각 티켓은 모든 계층을 교차하고, 독립적으로 입증 가능하며, 하나의 새로운 컨텍스트에 적합
• 광범위한 리팩터는 확장-수축 방식으로 진행: 새 형식 추가, 배치로 마이그레이션, 이전 형식 제거 — 각 배치는 하나의 티켓

에이전트 측 기계적 검증이 먼저 실행됩니다(독립성, 입증 가능성, 컨텍스트 적합성). 그런 다음 C3: 세분성, 차단 에지 및 제안된 병합/분할을 인간 승인을 위해 제시합니다. 승인될 때까지 반복합니다. 모든 티켓을 ready-for-agent로 표시합니다.

통합 배선 규칙: 모든 수직 슬라이스에는 자체 배선과 스모크 어설션이 포함됩니다 — 출력을 아무것도 마운트, 제공 또는 가져오지 않는 슬라이스는 완료된 것이 아닙니다. 단일 슬라이스가 소유하지 않는 교차 슬라이스 심(라우트 마운팅, 정적 제공, 진입점 배선)은 마지막 프론티어 항목으로 명시적 통합 티켓을 받습니다.

4단계 — 프론티어 실행

프론티어는 모든 차단자가 완료된 티켓입니다.

병렬(기본값, 2+ 티켓). 팀에 티켓을 전달합니다: 각 티켓은 팀 작업이 되고, blockedBy 에지는 이월됩니다 — 팀의 클레임 메커니즘은 프론티어 작업만 선택합니다. N개의 작업자를 생성합니다. 각 작업자는 C2에서 승인된 심에서 tdd 규율로 구현하고, /oh-my-claudecode:minimal-code-discipline을 작성 시간 규율로 적용합니다(opt-in 상태 유지); 티켓은 코드 리뷰가 diff를 통과한 후에만 닫히며, 리뷰어가 선언합니다 — 구현자는 자체 승인하지 않습니다.

직렬(단일 티켓 또는 --serial). 한 번에 하나의 티켓을 실행자 하위 에이전트에 위임합니다; 동일한 리뷰 게이트.

이축 리뷰 게이트. 마감 리뷰는 두 축을 따라 병렬로 실행되며, 별도로 보고됩니다 — 병합되거나 교차 순위가 매겨지지 않습니다. 변경 사항이 한 축을 통과하고 다른 축을 실패할 수 있기 때문입니다(표준을 준수하지만 잘못된 동작; 충실하지만 규칙을 위반). 리뷰어는 두 축 중 하나라도 실패하면 티켓을 실패로 표시합니다:

• 표준 축 — 일치하는 docs/standards/ 볼륨에 대한 diff와 판단 호출 전용 냄새 기준선(문서화된 저장소 표준이 기준선을 재정의함; 도구가 이미 적용하는 것은 건너뜀). 이것은 표준 표면이 참조되도록 유지하는 상시 소비자입니다.
• 사양 축 — 이 티켓의 수락 기준에 대한 diff(사양은 티켓이 분해된 총 원장입니다; 기준이 어디에서 왔는지 추적하고 밀수된 범위(어떤 티켓에도 없는 동작)를 판결하기 위해서만 참조됨).

…

[잘림: 번역용]