이해하기

먼저 탐색

/rasen:explore은 생각 파트너입니다. 문제가 있지만 아직 계획이 없을 때마다 이에 도달합니다. 코드베이스를 조사하고, 옵션을 검토하고, 단일 산출물이나 코드 줄이 생성되기 전에 실제로 원하는 것을 명확히 합니다. 그림이 명확해지면 /rasen:propose로 인수합니다.

이 문서에서 한 가지 습관을 취하면 이것을 취합니다. 확실하지 않을 때 제안하기 전에 탐색합니다.

왜 이것이 중요한지 알아보겠습니다. AI 코딩 보조자는 열망합니다. 막연하게 요청하면 자신감 있게 뭔가를 구축합니다. 아마도 필요한 것이 아닙니다. 탐색은 치료입니다. 대안이 없는 대화이며, 사용자와 AI가 올바른 움직임을 함께 파악하므로 제안할 때 올바른 것을 제안합니다.

탐색할 때

탐색은 사람들이 기대하는 것보다 더 자주 올바른 첫 번째 단계입니다. 다음 중 하나가 참이면 이를 사용합니다.

해결책이 아니라 문제를 알고 있습니다. ("페이지가 느립니다." "인증이 엉망입니다." "중복 주문을 계속 받습니다.")
접근 방식을 선택하고 실제 코드에 대해 절충사항을 배치하기를 원합니다.
코드베이스에 새로 도착했으며 변경하기 전에 작동하는 방식을 이해해야 합니다.
요구사항이 모호하고 약속하기 전에 날카로우려면.
작업이 보이는 것보다 크거나 작다고 의심하고 정직하게 범위를 지정하길 원합니다.

이미 정확히 원하는 것과 방법을 알고 있을 때만 탐색을 건너뜁니다. 이 경우 /rasen:propose로 바로 가십시오.

수행하는 것(그리고 하지 않는 것)

탐색은 생성자가 아닌 대화입니다.

수행합니다:

실제 질문에 답하기 위해 코드베이스를 읽고 검색합니다.
옵션을 비교하고 각각의 절충사항을 명명합니다.
설계를 읽기 쉽게 하기 위해 다이어그램을 그립니다.
모호한 아이디어를 구체적이고 구축 가능한 범위로 좁히는 데 도움을 줍니다.
준비가 되면 /rasen:propose로 전환합니다.

수행하지 않습니다:

변경 폴더를 생성합니다.
산출물을 작성합니다(제안, 스펙, 설계, 작업 없음).
코드를 작성하거나 수정합니다.

그것이 요점입니다. 탐색은 비용이 없고 약속하지 않습니다. 세 가지 막다른 골목을 탐색하고 각각에서 뭔가를 배운 후 생존한 경로를 제안할 수 있습니다.

이미 설치되어 있습니다

좋은 소식: /rasen:explore는 기본 core 프로파일에 제공되며, propose, apply, sync 및 archive와 함께 제공됩니다. 아무것도 활성화할 필요가 없습니다. rasen이 프로젝트에서 설정되면 AI 채팅에서 탐색이 준비됩니다. (모든 /rasen:* 명령과 마찬가지로 보조자의 채팅에 입력합니다. 터미널 아님. 명령이 작동하는 방법을 참조하세요.)

전체 예시

모호한 걱정이 어떻게 날카롭고 구축 가능한 변경이 되는지 보세요.

You: /rasen:explore

AI:  What would you like to explore?

You: Our checkout sometimes creates duplicate orders. I don't know why
     and I don't know how to fix it safely.

AI:  Let me dig into the checkout path...
     [reads the order service, the payment webhook handler, and the
      client submit logic]

     Here's what I found. There are two ways a duplicate can happen:

     1. The client can submit twice (double-click, retry on slow network).
        Nothing debounces it.
     2. The payment webhook can fire more than once, and the handler
        creates an order each time. There's no idempotency key.

     Cause #2 is the dangerous one: it can charge and fulfill twice.

     Three ways to fix it, roughly in order of robustness:
     - Idempotency key on the order-creation endpoint (handles both causes)
     - Dedup on the webhook by payment-intent id (handles #2 only)
     - Client-side debounce (handles #1 only, papers over the real bug)

     Given your code already stores the payment-intent id, the
     idempotency-key approach is a small change with the biggest payoff.
     Want me to scope that?

You: Yes, let's do the idempotency key.

You: /rasen:propose add-order-idempotency-key

AI:  Created rasen/changes/add-order-idempotency-key/, with a proposal
     and delta spec grounded in what we just found. Ready for implementation.

무엇이 발생했는지 알아보겠습니다. 시작점은 "뭔가 잘못되었고 건드리기가 두렵습니다."였습니다. 20초의 탐색이 명명된 근본 원인, 3개의 순위별 옵션, 기존 코드와 연결된 권장 사항 및 정확한 변경으로 바뀌었습니다. 이어지는 제안은 먼저 생각이 발생했기 때문에 날카롭습니다.

제안으로 인수

탐색은 아무것도 보관하지 않습니다. 준비가 되면 변경을 시작하고, AI가 대화의 컨텍스트를 산출물로 옮깁니다.

explore  ──►  propose  ──►  apply  ──►  archive
 (think)     (agree)       (build)     (record)

평문으로 말할 수 있습니다("이것을 변경으로 바꾸자") 또는 /rasen:propose <name>을 직접 실행합니다. 어느 쪽이든 방금 수행한 탐색은 산출물의 기초가 되며 일회용 채팅이 아닙니다.

확장된 명령 집합을 사용하면 탐색이 대신 /rasen:new으로 인수할 수 있으며 단계별 산출물 생성을 위합니다. 워크플로우를 참조하세요.

좋은 탐색을 위한 팁

해결책이 아닌 문제를 가져오세요. "로그인이 느립니다"는 AI에 조사할 여지를 줍니다. "Redis 캐시 추가"는 아직 테스트하지 않은 답변으로 미리 약속합니다.
절충사항을 큰 소리로 요청하세요. "각 옵션의 단점은 무엇입니까?"는 더 정직한 비교를 얻습니다.
먼저 읽도록 합니다. 최고의 탐색은 추측이 아닌 AI가 실제로 코드를 보는 것으로 시작합니다. 도움이 된다면 관련 영역을 가리킵니다.
보석금을 내도 괜찮습니다. 탐색이 아이디어가 가치있지 않다는 것을 드러내면 그것은 승리입니다. 저렴하게 배웠습니다.
변경 중에 다시 탐색하세요. /rasen:apply 중에 막혔나요? 단계를 물러서서 하위 문제를 탐색한 후 돌아올 수 있습니다.

정직한 절충사항

얻는 것: 탐색은 잘못된 회전을 가능한 가장 저렴한 순간에 잡습니다. 아무 산출물도 존재하기 전에. 특히 낯선 코드에서 강력합니다. AI의 시스템을 읽고 요약하는 능력은 오후 탐험을 저장합니다.

비용: 약간의 인내심. 탐색은 대화이므로 /rasen:propose를 발사하고 바라는 것보다 느립니다. 이미 진정으로 이해하는 작업의 경우 그 추가 단계는 순수 오버헤드이며 건너뛰어야 합니다.

경험칙: 작업이 모호할수록 탐색이 더 많이 지급됩니다. 작업이 명확할수록 더 많이 제안으로 바로 건너뜀.

다음에 갈 곳

명령: /rasen:explore: 정확한 참조
워크플로우: 일상 루프의 일부로 탐색
예시 & 레시피: 전체 연습에서 탐색
시작하기: 탐색이 포함된 첫 변경 가이드