RASEN · 상승하는 나선형 루프
문서
v 0.1.3
MIT
⬤ 자율 하니스
EN / 中文 / 日本語 / 한국어
[ contents ]
가이드

변경 편집 및 반복

변경 시 모든 산출물은 언제든지 편집할 수 있는 단순한 마크다운 파일입니다. 잠긴 "계획 단계", 승인 게이트, 진입할 특별한 편집 모드는 없습니다. 빌드를 시작한 후 제안서를 변경하고 싶으십니까? proposal.md를 열고 변경합니다. 구현 중간에 설계가 잘못되었습니다? design.md를 수정하고 계속합니다. 그것이 전부이며 설계로 인한 것입니다.

이 페이지는 "잠깐, 돌아가서 그것을 변경할 수 있을까?"를 생각하는 순간을 위한 것입니다. 예. 각 일반적인 경우에 대한 방법은 다음과 같습니다.

무엇이든 편집하는 두 가지 방법

항상 둘 다 있습니다:

  1. 파일을 직접 편집합니다. 산출물은 rasen/changes/<name>/의 일반 마크다운입니다. 편집기에서 proposal.md, design.md, tasks.md, 또는 specs/ 아래의 델타 스펙을 열고 변경합니다. 다른 것은 필요하지 않습니다.

  2. AI에 수정을 요청합니다. 채팅에서 원하는 것을 말합니다: "캐싱 아이디어를 삭제하고 속도 제한 섹션을 추가하도록 제안서를 업데이트합니다" 또는 "설계는 폴링이 아닌 큐를 사용해야 합니다." AI는 변경의 나머지를 컨텍스트로 사용하여 산출물을 편집합니다.

순간에 맞는 것을 사용합니다. 작은 표현 조정? 파일을 편집합니다. 실질적인 재고? AI가 전체 컨텍스트로 수정하도록 합니다.

"시작한 후 제안서(또는 스펙)를 어떻게 업데이트합니까?"

그냥 업데이트하세요. 동일한 변경, 정제됨.

확장된 명령을 사용하는 경우 자연스러운 흐름은: 산출물을 편집한 다음 /rasen:continue를 실행하여 새로운 상태에서 선택하거나 /rasen:apply를 실행하여 업데이트된 계획에 대해 계속 구현합니다. 기본 core 명령에 있으면 산출물을 편집하고 /rasen:apply를 실행합니다; 현재 파일을 읽으므로 산출물이 현재 말하는 대로 빌드합니다.

정신 모델: 산출물은 서명된 계약이 아닌 라이브 계획입니다. AI는 항상 현재 콘텐츠에서 작동하므로 편집하면 작업이 조종됩니다.

You: I want to change the approach in this change.

You: [edit design.md, or tell the AI:]
     Update design.md to use a background job instead of a synchronous call.

AI:  Updated design.md. The task list still fits; want me to continue applying?

You: /rasen:apply

이것은 매우 일반적인 질문에 답합니다: 필요하지 않으므로 별도의 "업데이트 제안" 명령이 없습니다. 파일이 정보의 출처이고 편집하면(직접 또는 AI를 통해) 업데이트입니다.

"구현 후 검토로 돌아가려면 어떻게 합니까?"

당신은 결코 떠나지 않았기 때문에 "돌아가야" 할 필요가 없습니다. 워크플로우는 유동적입니다: 검토, 편집, 구현은 갇혀 있는 순차적 단계가 아닙니다.

구체적으로 일부 /rasen:apply 작업 후:

  • 계획을 다시 검토하고 싶으십니까? 산출물을 열고 읽거나 터미널에서 rasen show <change>를 실행하여 통합 보기를 위합니다.
  • 변경할 것을 찾으셨습니까? 산출물을 편집합니다(또는 AI에 요청합니다). 그 다음 계속합니다.
  • 코드가 계획과 일치하는지 구조화된 확인을 원하십니까? /rasen:verify를 실행합니다(확장된 명령). 아무것도 차단하지 않고 완성도, 정확성, 일관성을 보고합니다. Workflows: Verify를 참고합니다.

검토를 반환할 "검토 단계"가 없습니다. 검토는 구현 후를 포함하여 언제든지 수행할 수 있기 때문입니다.

"코드를 직접 편집했습니다. Rasen과 어떻게 조정합니까?"

이것은 지속적으로 발생하며 괜찮습니다. 편집기에서 무언가를 조정하면 코드와 산출물이 동의하지 않습니다. 그들을 어느 방향이든 동기화합니다:

  • 코드가 이제 올바릅니다, 스펙이 부실합니다. 델타 스펙(및 관련된 경우 작업)을 업데이트하여 실제로 배포한 동작을 설명합니다. 보관 시 스펙이 정보의 출처로 병합되므로 보관하기 전에 스펙이 현실과 일치해야 합니다.
  • 스펙이 올바릅니다, 코드가 드리프트되었습니다. 코드가 스펙과 일치할 때까지 빌드하거나 수정합니다.

불일치를 표시하는 빠른 방법은 /rasen:verify입니다: 산출물과 코드를 읽고 그들이 어디서 갈라지는지 알려줍니다. 해당 결과를 조정 할 일 목록으로 처리한 다음 동의하면 보관합니다.

원칙: 보관 시 스펙이 기록의 진실이 됩니다. 따라서 보관하기 전에 코드가 수행하는 작업에 대해 스펙을 정직하게 만듭니다. 수동 편집은 환영받습니다; 스펙을 조용히 동기화 해제하지 마세요.

만족하지 않는 제안서 정제

생성된 제안서가 표시를 놓친 경우 세 가지 좋은 동작이 있습니다:

  • 제 위치에서 반복합니다. AI에 무엇이 잘못되었는지 알려줍니다("범위가 너무 넓습니다, 관리 기능을 삭제합니다") 그리고 수정하도록 합니다. 가장 저렴하고 보통 맞습니다.
  • 먼저 탐색한 다음 다시 제안합니다. 문제가 아이디어 자체가 명확하지 않다면 /rasen:explore로 물러나 생각을 거쳐 더 선명한 제안이 나오도록 합니다. Explore First를 참고합니다.
  • 새로 시작합니다. 의도가 근본적으로 변경된 경우 새로운 변경이 이전 패칭보다 명확할 수 있습니다.

마지막 움직임은 고유한 결정 가이드를 가집니다.

업데이트 vs. 새 변경을 시작할 때

짧은 버전: 같은 작업이 정제될 때 업데이트; 의도가 근본적으로 변경되거나 범위가 다른 작업으로 폭증할 때 새로 시작합니다.

  • 같은 목표, 더 나은 접근? 업데이트합니다.
  • 범위 축소(지금 MVP를 배포, 나중에 더)? 업데이트한 다음 보관, 그 다음 2단계에 대한 새 변경합니다.
  • 문제 자체가 변경되었습니다("어두운 모드 추가"는 "전체 테마 시스템 빌드"가 되었습니다)? 새 변경합니다.

Workflows: When to Update vs Start Fresh 및 OPSX: When to Update vs. Start Fresh의 전체 플로우차트와 작업 예제가 있습니다.

작업에 대한 참고

tasks.md는 고정된 계획이 아닌 생활 체크리스트입니다. 구현하면서 발견한 작업을 추가하거나, 불필요한 것을 제거하거나, 순서를 변경할 수 있습니다. AI는 /rasen:apply 중에 완료하면 항목을 확인하고, 나중에 돌아오면 첫 번째 미확인 작업에서 재개합니다. 비행 중에 목록을 편집하는 것이 예상됩니다.

다음에 갈 곳