가이드

변경 검토

Rasen의 전체 약속은 코드가 작성되기 전에 사용자와 AI가 무엇을 구축할지에 대해 동의한다는 것입니다. 해당 동의는 AI가 초안한 내용을 실제로 읽는 경우에만 의미가 있습니다. 이 페이지는 2분간 이를 수행하는 방법에 관한 것입니다. 무엇을 열고, 어떤 순서로 열고, 무엇을 찾아야 하는지.

베팅은 간단합니다. 한 문단 계획에서 잘못된 회전을 잡는 것은 거의 무료입니다. 같은 잘못된 회전을 300줄의 코드에서 잡는 것은 아닙니다. 검토는 베팅을 수집하는 곳입니다.

검토하는 두 가지 순간

정확히 두 가지가 있습니다.

/rasen:propose ──► REVIEW THE PLAN ──► /rasen:apply ──► REVIEW THE CODE ──► /rasen:archive
                  (before any code)                    (/rasen:verify)

/rasen:propose 후(또는 /rasen:ff) — /rasen:apply 전에 계획이 여전히 단어일 때 읽으세요.
구축 후 — /rasen:verify를 사용하여 코드가 계획이 말한 것을 실제로 수행했는지 확인합니다.

첫 번째 검토가 가장 많이 절약하는 것이고, 사람들이 건너뛰는 것입니다. 이 페이지는 대부분의 시간을 그곳에 보냅니다.

이 순서로 읽으세요

변경은 rasen/changes/<name>/의 평문 마크다운 폴더입니다. 뭔가 잘못되면 가장 빨리 종료할 수 있는 순서로 파일을 읽으세요.

rasen/changes/add-dark-mode/
├── proposal.md      1. the intent and scope   ← if this is wrong, stop here
├── specs/…/spec.md  2. the requirements       ← the heart of the review
├── design.md        (only for bigger changes) — the technical approach
└── tasks.md         3. the plan of work

모든 줄을 읽을 필요는 없습니다. 파일당 하나씩 세 가지 질문에 답해야 합니다.

제안: 올바른 문제입니까?

먼저 proposal.md를 열으세요. "왜"와 "무엇"을 포착합니다. 의도, 범위, 한두 문단의 접근 방식.

좋은 것들: 하나의 명확한 의도, 인식하는 범위, 지금 이것이 왜 가치있는지에 대한 이유.

주의 신호:

요청한 것과 약간 다른 문제를 해결합니다.
범위가 증가했습니다. 테마 토글을 요청했고 제안이 "우리가 거기 있는 동안" auth도 건드립니다.
모호합니다. "설정 페이지 개선"은 범위가 아닙니다. "OS 기본 설정을 존중하는 다크 모드 토글 추가"는 범위입니다.

답할 질문: 이것이 내가 실제로 요청한 것과 일치합니까? 아무것도 몰래 들어오고 있습니까? 답이 아니면 중지합니다 — 더 이상 읽지 마세요, 제안을 수정합니다(밀어붙이기는 저렴합니다 참조).

스펙 델타: "완료"가 올바르게 정의되어 있습니까?

이것이 검토의 핵심입니다. specs/ 아래의 델타 스펙은 변경이 배송될 때 참이 될 것을 말합니다. 요구사항과 이를 증명하는 시나리오로.

## ADDED Requirements

### Requirement: Dark Mode Toggle
The system SHALL let a user switch between light and dark themes.

#### Scenario: Respects the OS preference on first load
- GIVEN a user who has never set a theme
- WHEN they open the app on a device set to dark mode
- THEN the app renders in dark mode

좋은 요구사항의 모습: 테스터에게 건넬 수 있는 하나의 명확한 SHALL/MUST 진술 및 실제로 해당 진술을 실행하는 GIVEN/WHEN/THEN 시나리오.

주의 신호:

모호한 요구사항. "시스템은 빨라야 합니다"는 구축하거나 테스트할 수 없습니다. 뭐가 빠른 거예요?
시나리오가 없는 요구사항, 또는 그 아래에 있는 요구사항을 테스트하지 않는 시나리오.
가장 가치있는 잡기: 누락된 것. AI는 말한 것을 충실하게 기록합니다. 당신의 일은 잊은 것을 알아차리는 것입니다. OS 기본 설정 경우를 가장 중요하게 생각했고 어떤 시나리오도 이를 언급하지 않으면 검토가 자신을 위해 지급합니다.

시스템이 정확히 — 그리고 오직 이것만 — 이렇게 했다면 행복할까요? 하는 요청을 하면서 델타를 읽으세요. 여기서는 아직 코드에 대한 것이 없으므로 변경하기에 저렴합니다.

작업: 작업 계획이 정상적입니까?

마지막으로 tasks.md를 열으세요. AI가 진행할 구현 체크리스트입니다.

좋은 것들: 순서화된 단계, 각각 요구사항으로 추적 가능, 신비로운 것 없음.

주의 신호:

일치하는 요구사항이 없는 작업(어디에서 나온 거예요?).
모든 실제 결정을 숨기는 하나의 거대한 "기능 구현" 작업.
방금 승인한 범위 외부의 항목에 닿는 작업.

당신은 여기서 추정하거나 미세 관리하지 않습니다. — 계획이 이미 수락한 요구사항과 일치하는지 확인합니다.

밀어붙이기는 저렴합니다

세 가지 질문 중 하나가 잘못 나오면 말해주세요. 단계도 없고 아무것도 잠기지 않습니다 — 수정하고 계속합니다. 정확히 변경 편집처럼 두 가지 방식이 있습니다.

파일을 직접 편집합니다. 평문 마크다운입니다. 범위 줄을 변경하고, 요구사항을 강화하고, 작업을 삭제합니다.
AI에 무엇이 잘못되었는지 알려줍니다. 수정하게 합니다. "auth 변경 드롭 — 범위 밖," "사용자가 이미 테마를 선택한 경우에 대한 시나리오 추가," "작업 3을 스키마와 UI로 분할."

그 다음 변경한 부분을 다시 읽으세요. 서명할 계획일 때까지 재초안합니다. 그 앞뒤 는 제품이 작동하는 것입니다.

코드 후: 검증

작업이 구축되면 /rasen:verify는 두 번째 검토입니다. 산출물과 코드를 다시 읽고 세 가지 차원에 걸쳐 불일치를 보고합니다.

차원	확인되는 항목
완전성	모든 작업 완료, 모든 요구사항 구현, 시나리오 커버됨
정확성	구현이 스펙의 의도와 일치, 엣지 케이스 처리됨
일관성	설계 결정이 실제로 코드에 나타남

You: /rasen:verify

AI:  Verifying add-dark-mode...

     COMPLETENESS
     ✓ All 8 tasks in tasks.md are checked
     ✓ All requirements in specs have corresponding code
     ⚠ Scenario "Respects the OS preference on first load" has no test coverage

문제를 CRITICAL, WARNING 또는 SUGGESTION으로 플래그하고 보관을 차단하지 않습니다. — 간격을 표시하고 호출을 당신에게 맡깁니다. 이것은 "AI가 코드를 썼습니까?"와 "동의한 것을 구축했습니까?" 사이의 차이입니다.

/rasen:verify는 확장된 프로파일에 있습니다. 없으면 rasen config profile(그 다음 rasen update)로 켜거나, 자신의 변경과 차이를 다시 읽으세요.

검토를 올바르게 크기 조정하세요

모든 변경이 전체 통과를 얻는 것은 아닙니다. 한 파일 오타 수정은 20초 훑어보기를 원합니다. auth, 지불 또는 복구할 수 없는 데이터를 건드리는 변경은 위의 모든 질문을 합니다. 요점은 절대 의식이 아닙니다 — 실수가 비쌀 곳에 주의를 쓰고, 비싸지 않을 곳에서 훑어보는 것입니다.

2분 체크리스트

제안의 의도가 내가 요청한 것과 일치합니다.
범위에 추가 항목이 몰래 들어오지 않았습니다.
모든 요구사항이 테스트하기에 충분히 구체적입니다.
모든 요구사항에 실제로 실행하는 시나리오가 있습니다.
내가 가장 중요하게 생각하는 경우가 포함됩니다.
작업은 요구사항에 매핑됩니다. 신비로운 것이나 범위 밖의 것은 없습니다.
AI가 정확히 이것을 구축하고 아무것도 더 안 했을 때 편할 것입니다.

7개 모두 통과하면 /rasen:apply를 자신감을 가지고 실행합니다. 어떤 것이 실패하면, 그것은 후퇴가 아닙니다 — 2분이 그 일을 합니다.

다음에 갈 곳

좋은 스펙 작성 — 다른 쪽. 승인할 가치가 있는 요구사항과 시나리오를 초안하는 방법.
변경 편집 & 반복 — 시작한 후 계획을 변경하는 메커니즘.
워크플로우 — 더 큰 루프에서 검토가 맞는 곳.