Loft (형상 검증)

Loft (형상 검증)은(는) 무엇을 하나요?

형상이 적합해질 때까지 강철을 자르지 마십시오. 선박 설계자(shipwright)는 단 한 장의 강철판을 자르기 전에 선체의 선을 실물 크기로 그리고 조정합니다. Loft는 설계 질문에 동일한 순서를 적용합니다: 말이 다 떨어졌을 때 — 두 가지 그럴듯한 답변이 있고, 대화로는 어느 것도 반증할 수 없을 때 — 저렴하고 실행 가능한 아티팩트를 만들고, 캡틴이 이에 반응하도록 한 후, 그 반응을 결정에 반영합니다.

역할 계약. 승무원이 아티팩트를 만듭니다. 캡틴의 유일한 임무는 반응하는 것이며, 그 반응이 곧 결정입니다. 아티팩트는 '보기 위한 도구'일 뿐, 인도물을 미리 시작하는 수단이 아닙니다.

Loft를 사용해야 할 때

• 설계 질문이 산문(prose)으로 막혔을 때: 반복해서 바꿔 말해도 여전히 결정할 수 없는 경우 ("경로 페이지는 어떻게 보여야 하는가", "이 상태 모델이 올바른가")
• 내비게이터 맵에 loft 티켓이 있을 때
• 스펙 논의가 "직접 봐야 알겠다"에 도달했을 때

Loft를 사용하지 말아야 할 때:

• 저장소 증거나 캡틴에게 물어봄으로써 답변할 수 있는 질문일 때 (그것은 인터뷰이지 Loft가 아닙니다)
• 목적지 자체가 불분명할 때 (그것은 안개(fog)입니다 — /oh-my-claudecode:ask-navigator)
• 답변이 이미 ADR(아키텍처 결정 기록)에 있을 때 (이미 결정된 사항을 다시 Loft하지 마십시오)
• "설계 질문"이 실제로는 버그일 때 (그것은 디버거의 권한입니다)

포크 선택

질문이 무엇을 묻는지에 따라 선택하십시오. 잘못된 포크는 아티팩트 전체를 낭비하게 만듭니다.

로직 포크 — 모델이 올바른가?

상태(state), 비즈니스 규칙, 데이터 형상, 또는 알고리즘에 대한 질문("잠금 해제가 재응시(retake) 시 원상복귀되는가?", "이 리듀서가 경계 조건에서 유효한가?")에 사용합니다:

1. 결정을 담당하는 핵심 요소를 순수 모듈로 분리하십시오: 상태 머신, 리듀서, 스키마, 또는 알고리즘. DOM, I/O, 프레임워크가 없어야 합니다. 형상이 확인되면 실제 코드베이스로 변경 없이 이동할 수 있도록 작성합니다.
2. 단일 클릭 가능한 HTML 셸로 감쌉니다: 시나리오당 하나의 버튼, 까다로운 경계 조건을 순서대로 실행, 모든 클릭 후 전체 상태가 표시됩니다.
3. 모듈을 인계(lift)할 준비가 되었다는 확인이 이루어지면, 론치(launch)를 통해 실제 업무로 재진입합니다. Loft 자체 동안 main 브랜치는 건드리지 않고 셸은 브랜치에 남겨둡니다.

UI 포크 — 어떻게 보여야 하는가?

형상과 배열에 대한 질문("단계(steps) 또는 카드(cards)?", "진행 상황은 어디에 위치하는가?")에 사용합니다:

1. 하나의 경로(route)에 구조적으로 다른 세 가지 변형을 만듭니다 — 정보 아키텍처, 내비게이션 모델, 밀도(density). 스타일링만 다른 변형은 아무것도 증명하지 않습니다: 세 개의 다른 스킨은 벽지와 같습니다.
2. 페이지 위의 전환기(switcher)가 변형들을 순환합니다. 가능하면 기존 제품에 임베드하여, 세 개의 깔끔한 가짜 행 대신 실제 데이터 밀도가 디자인을 시험하게 하십시오.
3. 확인이 이루어지면, 결정만 이전되고 변형들은 왜 이렇게 되었는지에 대한 기록으로 브랜치에 남습니다.

규율

• 하나의 명령으로 실행 가능해야 합니다 — 저장소의 가장 간단한 기존 서브 명령어를 사용하며, file:// 모듈의 CORS 문제가 있다면 모듈을 셸에 인라인합니다. 몇 초 안에 로드되어야 하며, 저장소가 이미 가지고 있는 것 이상의 빌드 단계가 없어야 합니다.
• 지속성(persistence), 테스트, 추상화(abstractions), 그리고 해피 패스(happy path)를 넘어서는 오류 처리가 없어야 합니다. 아티팩트는 배송하고 싶지 않은 것이어야 합니다 — 이 규칙들은 그 상태를 유지하기 위해 존재합니다.
• 첫 번째 형상은 논쟁의 대상이 될 것으로 예상하십시오: 같은 세션 내에서 브랜치 위에서 수정하십시오. 캡틴이 최종 형상을 확인하는 것이 결정입니다. 아무도 논쟁하지 않는 아티팩트는 보통 아무도 가지지 않았던 질문에 답한 것입니다.
• 아티팩트의 전체 수명은 만드는 데 몇 분, 결정하는 데 한 세션입니다. 만약 그것이 프로덕션 코드로 성장하기 시작한다면 중단하십시오: 그 작업은 Loft가 아닌 론치(launch) 노력입니다. 매몰 비용(sunk cost)은 이 스킬이 방지하고자 하는 실패 모드입니다.
• 하나의 Loft는 하나의 질문에 답합니다. 두 질문은 두 개의 Loft입니다 — 또는 하나의 질문이 실제로는 두 개였던 경우입니다.

답변 접기

아티팩트는 증거이지, 착륙 지점이 아닙니다. 캡틴이 반응할 때:

1. 결정이 있어야 할 곳(이슈 코멘트, 스펙의 구현 결정(Implementation Decisions) 섹션, 또는 보류 중인 결정 노트)에 캡틴 자신의 말과 한 줄의 이유를 함께 기록하십시오. 산문보다 더 정확한 조각(리듀서, 상태 머신, 스키마)은 거기에 인라인으로 포함될 수 있으며, lofted로 표시하십시오.
2. 아티팩트를 loft/<name> 브랜치로 푸시하십시오. 절대 병합되지 않습니다: 미래의 독자가 결정의 '이유'가 중요할 때 열어볼 수 있는 주요 출처로 남습니다.
3. 아티팩트의 어떤 내용도 main 브랜치로 들어가지 않습니다 — 로직 포크의 경우 확인된 모듈은 론치를 통해 실제 업무로 재진입하고, UI 포크의 경우 실제 페이지는 결정으로부터 새롭게 빌드됩니다.

범위 및 비목표

• Loft는 답변을 생성하지, 인도물을 생성하지 않습니다: 런타임, 상태 파일, 항상 켜져 있는 것 등이 없습니다.
• 진단하지 않으며(디버거), 안개를 차트로 만들지 않고(/oh-my-claudecode:ask-navigator), 자신의 답변을 승인하지 않습니다(캡틴의 반응이 유일한 수용 기준입니다).
• 심(seam) 승인을 대체하지 않습니다: Loft된 UI는 형상을 보여줄 뿐이며, 그에 대한 테스트 심은 여전히 C2에서 승인됩니다.

완료 조건

캡틴이 반응했고, 답변이 결정이 있어야 할 곳에 위치하며, 아티팩트는 해당 브랜치에 있고 — 아티팩트의 어떤 줄도 main 브랜치에 없습니다.