Thought Experiment ver 0.6.0 alpha — 엄격한 실패 시나리오 감사 및 수정
트리거: "thought experiment" 구문, 정확히 이 구문만 해당됩니다. 추론된 동의어는 인식하지 않습니다. 명시적인 요청과 명확한 대상 없이는 절대 실행되지 않습니다. 이는 의도적인 설계이며 자율적이지 않습니다.
범위: 대상에 구애받지 않습니다. 단일 파일, 전체 프로젝트, 설정, API 계약, 인프라 설정 등 — 자신의 동작, 구조, 또는 의존하는 것에 대해 잘못될 수 있는 주장을 하는 모든 것이 대상입니다.
일반 검토와의 차이점: 두 가지가 다릅니다. 첫째, "이것을 더 깔끔하게 할 수 있다"는 모호한 제안이 아닌 "이 입력/이 상태가 주어졌을 때, 여기서 정확히 무엇이 깨지고 왜 그런지"에 대한 구체적인 시나리오를 생성합니다. 둘째, 특히 대상이 자신 외부의 것이 어떻게 동작하는지에 대해 하는 주장을 찾아냅니다. 이러한 종류의 주장은 대상의 자체 로직을 읽어서 발견되기보다는 기억에 의존하여 조용히 잘못될 가능성이 가장 높기 때문입니다.
라운드 전 커밋 확인 (안전 레일): 라운드를 시작하기 전에 기존의 커밋되지 않은 변경 사항을 커밋/푸시하도록 엄격히 요청하고 권장합니다. 사전에 깨끗한 체크포인트를 확보하면 라운드 자체가 손상을 입힌 경우 항상 해당 지점으로 롤백할 수 있습니다.
프로세스
- 대상을 새로 읽습니다. 현재의 실제 상태(파일, 설정 등 대상이 구성하는 모든 것)를 가져옵니다. 이전 컨텍스트에서 대상이 포함해야 하는 내용에 대해 의존하지 마십시오.
- 의존성을 열거합니다. 대상이 자신 외부의 근본 진실로 취급하는 모든 것: 스크립트의 경우 — 가져온 라이브러리, 호출된 API, CLI 도구와 해당 플래그, 환경/설정 가정; 서비스 또는 클라우드 설정의 경우 — 통신하는 다른 서비스, 권한/IAM, DNS, 인증서, 타사 API, 네트워크 경로; 문서의 경우 — 다른 것이 어떻게 동작하는지에 대한 모든 사실적 주장. 이 목록을 의도적으로 작성하십시오 — 4단계에서 이를 검증하며, 건너뛴 의존성은 실제 버그를 잡을 기회를 놓치는 것입니다. 대상이 특히 배포를 목표로 할 때는 다음도 확인하십시오: 롤백 안전성, 개발/프로덕션 설정 일관성, 시크릿 처리, 명시된 호환성 기준, 그리고 순수 개발 전용 테스트와 대비되는 최초 로드/실제 조건 성능 — 이러한 사항은 일반적인 의존성 스캔만으로는 항상 드러나지 않습니다. 쌍을 이루는 문서(README와 해당 SKILL.md, 또는 코드/설정과 이를 설명하는 문서)의 경우, 각 파일이 다른 파일이 말하거나 하는 것에 대해 주장하는 내용을 검증할 의존성으로 취급하십시오. 그리고 별도로, 열거된 값의 굵게/대소문자 처리, 제목 스타일과 같은 확립된 서식 규칙이 대상 내부와 형제 파일 간에 일관되게 적용되는지 확인하되, 실제로 그러한 규칙이 존재하는 경우에만 확인하십시오.
- 구체적인 실패 시나리오 '생각 실험'을 구성합니다. 일반적인 인상이 아닌, 특정 잘못된 출력, 충돌 또는 보안 허점으로 이어지는 특정 입력 또는 상태입니다. 시나리오 수를 미리 고정하지 마십시오. 임의의 숫자에 도달할 때까지가 아니라 대상의 실제 위험 표면이 충분히 다루어졌다고 느껴질 때까지 계속 생성하십시오.
- 시나리오가 의존하는 모든 의존성 동작 주장을 라이브 또는 권위 있는 소스 (실제 문서, 실제 API 응답, 도구의 실제 출력 등)에 대해 검증하고 기억을 신뢰하지 마십시오. 이 단계는 일반적으로 가장 가치 있는 발견이 이루어지는 단계입니다.
- 수정 승인 방식을 한 번 묻고, 수정을 적용하기 전에 선택하도록 합니다 — CRUD 옵션. 읽기는 항상 자유롭게 허용되며 절대 제한되지 않습니다. 생성/업데이트/삭제만 승인됩니다. 포괄적(확인된 모든 발견, 추가 질문 없음), 프로세스(라운드당 한 번 확인, 파일당이 아님), 파일(다음 파일의 수정으로 이동하기 전에 확인), 또는 모든 CRUD 단계(각 개별 편집을 확인) — 사용자가 선택한 옵션이 실행의 나머지 부분 동안 유지됩니다. 포괄적 승인은 일상적인 확인된 발견을 다루며, 무조건적인 재정의가 아닙니다: 사용자가 승인할 때 염두에 두었던 것보다 정말로 놀랍거나 위험이 높은 발견이 있으면 여전히 중단되고 질문이 제기됩니다.
- 확인된 발견에 대한 수정을 승인된 세분성에 따라 적용합니다.
- 수정된 상태에 대해 동일한 프로세스를 재실행합니다. 수정은 자체적인 새로운 문제를 도입할 수 있습니다 — 정확성 수정이 다른 것을 일관성 없게 만들거나, 수정된 주장이 다른 곳의 다른 가정을 깨뜨릴 수 있습니다. 새로운 것을 발견하지 못하는 패스가 나올 때까지 루프는 끝나지 않습니다.
- 보고합니다. 각 시나리오의 통과/실패를 명확히 명시합니다. 확인된 실패에 대해서만, 또는 명시적으로 세부 정보를 요청한 경우에만 전체 세부 정보를 제공합니다 — 깨끗한 통과에는 에세이가 필요하지 않습니다. 각 실패를 차단(배포/출시 전에 반드시 수정) 또는 비차단(출시해도 안전, 이후 수정)으로 태그하여 보고서가 단순한 발견 목록이 아니라 진행/중단 입력 역할을 하도록 합니다. 모든 실행을 프로세스 전반에 흩어진 시나리오별 언급이 아닌 하나의 통합된 열거형 요약으로 마무리합니다 — 범위에 맞게 조정: 여러 대상 실행(여러 파일, 여러 스킬)은 대상당 하나의 섹션을 얻습니다. 단일 깨끗한 대상은 하나의 간단한 평결 라인을 얻으며, 부풀려진 의식은 없습니다.
새 줄로, 모든 보고서를 thought experiment로 마칩니다.