/crucible
먼저 읽고, 나중에 질문하세요. 인간은 코드가 결정할 수 없는 것에만 답합니다.
1단계: 읽기 (아직 질문하지 않음)
코드가 이미 결정한 사실을 path:line 형식으로 작성하세요. 이후의 모든 질문은 이러한 사실이 답하지 못한 것이어야 합니다.
2단계: 사다리 (새로운 것을 제안하기 전에)
요청된 변경의 각 부분에 대해, 첫 번째 "예"에서 멈추세요:
- 건너뛰거나 삭제할 수 있습니까? 요구 사항이 이미 충족되었거나 필요하지 않습니까? → 그렇게 말하세요.
- 저장소에 이미 있습니까? 기존 헬퍼, 컴포넌트 또는 패턴 → 재사용하세요 (
path:line인용). - 표준 라이브러리나 기존 종속성에 있습니까? → 사용하세요.
- 그런 다음에만: 추측적인 옵션이나 추상화 없이 최소한의 새 코드를 작성하세요.
3단계: 다섯 가지 축
각 축에 대해 확정(코드 또는 요청 인용) 또는 미결로 표시하세요:
- 범위: 포함되는 것과 명시적으로 제외되는 것.
- 데이터 및 상태 불변성: 항상 참이어야 하는 것. 마이그레이션?
- 실패 모드: 잘못된 입력, 시간 초과, 부분 실패, 재시도 시 발생하는 상황.
- 보안 및 신뢰 경계: 누가 어떤 데이터로 호출할 수 있으며, 유효성 검사가 어디에 있는지.
- 검증 증명: 완료를 증명할 검사 (
/proof제공).
4단계: 미결 상태인 것만 질문하세요
- 축이 미결 상태이고, 답변이 설계를 변경합니까? → 질문하세요. 배치당 최대 3개의 질문. 각 질문에 권장 답변과 절충안을 제시하여 인간이 "예"라고만 말할 수 있게 하세요.
- 미결 상태이지만 중요도가 낮습니까? → 결정하고
assumed로 기록하세요. - 모든 것이 확정되었습니까? → 아무것도 질문하지 마세요. 5단계로 이동하세요.
- 진정한 아키텍처 포크가 다른 모델의 의견을 필요로 합니까? → 이 기록을 아티팩트로 사용하여
/council하세요.
5단계: 기록
.ramos/decisions/<topic>.md를 작성하세요:
# <주제> (<날짜>)
## 사실 (코드에서) - … (path:line)
## 사다리 결과 - X 재사용 / 표준 라이브러리 Y / 새 Z (이유)
## 축 | 축 | 확정/가정/답변 | 결정 | 출처 |
## 범위 외 - …
## 증명 - /proof가 실행할 정확한 명령어
완료 조건
모든 축이 확정, 가정 또는 답변되었고, 기록이 존재하며, 증명 명령어가 명명되었습니다. 답변되지 않은 설계 변경 질문 → 중단하고 인간에게 blocked를 보고하세요. 코딩을 시작하지 마세요.