기존 프로젝트에서 Rasen 사용

당신은 전체 코드베이스를 문서화할 필요가 없습니다. 변경할 것에 대해서만 스펙을 작성합니다. 기존 프로젝트에서 rasen을 채택할 때 알아야 할 가장 중요한 것입니다. rasen이 기존 코드베이스 우선으로 구축된 이유입니다.

일반적인 걱정은 이렇게 들립니다: "내 앱은 80,000줄 오래됐어요. rasen이 유용하기 전에 모든 것에 대해 스펙을 작성해야 하나요?" 아니요. 당신은 그것을 미워할 것이고, 우리도 합니다. Rasen은 한 번에 한 변경씩 스펙을 성장시킵니다. 첫 번째 변경은 접하는 조각을 문서화하고, 다음 변경은 조각을 문서화하고, 몇 달에 걸쳐 스펙이 실제로 수행하는 작업 주위에 자연스럽게 채워집니다.

이 가이드는 대양을 끓이지 않고도 첫 날에 시작하는 방법을 보여줍니다.

30초 버전

$ cd your-existing-project
$ rasen init          # rasen/과 AI 도구의 명령 추가

그 후 AI 채팅에서:

/rasen:explore            # 선택사항: AI가 만질 영역을 읽게 함
/rasen:propose <실제로 필요한 작은 실제 변경>
/rasen:apply
/rasen:archive

스펙이 이제 그 변경이 접한 시스템의 정확히 그 부분을 설명하고, 더 이상은 아닙니다. 그것이 정확합니다. 다른 80,000줄에 대해 걱정하는 것을 끝냈습니다.

왜 증량 우선이 전체 트릭인지

Rasen 변경은 증량으로 작성됩니다: ADDED, MODIFIED, REMOVED. 증량은 전체 시스템이 아닌 현재 동작에 비해 변경되는 것을 설명합니다.

이것이 정확히 기존 코드베이스 작업이 필요로 하는 것입니다. 당신은 거의 처음부터 구축하지 않습니다. 필드를 추가하고, 리다이렉트를 수정하고, 시간초과를 조여줍니다. 증량을 사용하면 먼저 주변의 모든 것을 기술하지 않고도 그 하나의 변경을 정확히 지정할 수 있습니다.

따라서 rasen/specs/ 디렉터리는 완전하고 완전하게 시작하지 않습니다. 거의 비어있게 시작하고 누적됩니다. 각 보관된 변경이 증량을 병합합니다. auth/에 대한 스펙은 여러 인증 변경을 한 후에만 철저해지며, 이것이 정확히 철저하게 원할 때입니다.

더 깊은 메커니즘을 원하면, 개념: 증량 스펙을 참조하세요.

실제 코드베이스에서 첫 번째 변경

작고 실제적인 것을 선택하세요. 장난감도 아니고 재작성도 아닙니다. 어쨌든 이번 주에 할 변경. 작은 첫 번째 변경은 낮은 위험으로 워크플로우를 가르칩니다.

단계 1: AI가 관련 영역을 읽게 합니다. 이것이 /rasen:explore가 낯선 또는 큰 코드베이스에서 가치를 입증하는 곳입니다. 접할 부분을 지정하고 뭔가를 제안하기 전에 일이 어떻게 작동하는지 지도하도록 합니다.

당신: /rasen:explore

AI:   뭘 탐색하고 싶으세요?

당신: 공개 API에 속도 제한을 추가해야 하는데, 요청이 현재
      미들웨어를 통해 어떻게 흐르는지 확실하지 않아요.

AI:   추적해봤어요... [라우터, 미들웨어 스택, 설정을 읽음]
      요청이 Express를 히트하고, 인증 미들웨어를 통과한 후
      컨트롤러로 이동합니다. 오늘 속도 제한 계층이 없습니다.
      가장 깔끔한 삽입 지점은 인증 직후의 미들웨어입니다.
      범위를 정하려면?

AI가 이제 실제 구조를 이해하므로, 기술 템플릿이 아닌 코드에 맞는 제안서를 작성합니다. 큰 코드베이스에서, 이 단일 습관이 가장 많은 고통을 구합니다. 먼저 탐색을 참조하세요.

단계 2: 변경을 제안합니다. 제안서와 증량 스펙이 이 변경만 캡처합니다.

당신: /rasen:propose add-api-rate-limiting

단계 3: 빌드하고 보관 /rasen:apply와 /rasen:archive로, 다른 변경처럼. 보관 후, 어쨌든 필요했던 변경에서 태어난 속도 제한 동작에 대한 실제 스펙이 있습니다.

가이드 투어를 선호하나요? onboard 사용

전체 루프가 당신의 코드에서 설명과 함께 발생하는 것을 보려면, 확장 명령 /rasen:onboard가 정확히 그것을 수행합니다: 코드베이스를 스캔하여 작고 안전한 개선을 찾은 다음 제안, 구축, 보관 단계를 안내하며 각 단계를 설명합니다.

먼저 확장 명령을 켜세요:

$ rasen config profile      # 확장 워크플로우 선택
$ rasen update              # 이 프로젝트에 적용

그 후 채팅에서:

/rasen:onboard

실제 프로젝트에서 가장 부드러운 소개이며, 유지하거나 버릴 수 있는 정품 (작은) 변경으로 남습니다. 명령: /rasen:onboard을 참조하세요.

"하지만 나는 이미 요구사항 문서가 있어요"

아마 PRD, SRS, 공식 스펙, TLA+ 모델도 있을 수 있습니다. 좋습니다. 당신은 그들을 대량으로 수입하지 않으며, 또한 버리지도 않습니다.

기존 문서를 탐색을 위한 원본 자료로 다루세요. 변환할 스펙이 아닙니다. 변경을 시작할 때, 관련 섹션을 AI에 붙여넣거나 지적하고, rasen 증량으로 초점을 맞춘 것으로 만들도록 합니다. 증량이 지금 변경하는 동작을 rasen의 테스트 가능한 요구사항 및 시나리오 형식으로 캡처합니다. 원본 문서는 배경으로 있는 곳에 남아있습니다.

정직한 이유: rasen 스펙은 의도적으로 동작 우선이며 변경으로 범위가 지정됩니다. 40페이지 PRD는 다른 목적을 가진 다른 산출물입니다. 일회성 대량 변환을 강제하면 아무도 신뢰하지 않는 크고 오래된 스펙을 생성하는 경향이 있습니다. 실제 변경에서 스펙을 성장시키면 정확함을 유지합니다.

당신: /rasen:explore
당신: 여기 체크아웃에 대한 PRD 섹션이 있어요. 다음에 "게스트 체크아웃" 요구사항을 구현하고 있어요.
      [관련 요구사항 붙여넣기]
AI:   [읽고, 명확히 하는 질문을 하고, 변경 범위를 정하는 데 도움]
당신: /rasen:propose add-guest-checkout

큰 코드베이스에서 스펙 정리

스펙은 rasen/specs/에 있으며, 도메인별로 그룹화됩니다: 팀이 시스템에 대해 생각하는 방식과 일치하는 논리적 영역. 전체 분류법을 미리 설계할 필요가 없습니다. 첫 번째 변경이 그 영역에서 필요할 때 도메인 폴더를 생성합니다.

도메인을 자르는 일반적인 방법:

• 기능 영역별: auth/, payments/, search/
• 컴포넌트별: api/, frontend/, workers/
• 경계된 컨텍스트별: ordering/, fulfillment/, inventory/

신입이 고개를 끄덕일 것을 선택하세요. 나중에 정제할 수 있습니다. 개념: 스펙을 참조하세요.

모노리포와 리포를 걸친 작업

모노리포의 경우, 가장 간단한 모델은 리포 루트에 하나의 rasen/ 디렉터리이고, 패키지 또는 서비스에 매핑되는 도메인입니다. 대부분의 팀을 다룹니다.

작업이 진정으로 여러 리포지토리를 걸쳐 있다면 (또는 별도로 취급하는 여러 패키지), rasen은 베타 stores 기능을 가지고 있습니다: 계획은 코드 리포 중 하나의 rasen/ 폴더 내에 살 필요가 없도록 자체 독립 리포에 있습니다. 베타이므로, 명령과 상태를 진화시키는 것으로 취급하세요. Stores 사용자 가이드로 정신 모델과 가장 작은 유용한 경로를 시작하세요.

몇 가지 정직한 주의사항

• 모든 것을 역채우고 싶은 충동을 저항하세요. 변경하지 않는 코드에 대한 스펙 작성은 생산적으로 느껴지고 대개 그렇지 않습니다. 그 스펙은 현실을 추적하도록 강제하는 것이 없기 때문에 오래됩니다. 실제 변경이 스펙을 주도하게 합니다.
• 초기 변경을 작게 유지하세요. 처음 몇 변경은 배송만큼 리듬을 배우는 것입니다. 타이트한 범위는 루프를 빠르게 하고 교훈을 저렴하게 합니다.
• rasen/을 git에 커밋하세요. 스펙과 보관은 기술하는 코드와 함께 버전 제어에 속합니다.
• AI에 컨텍스트를 제공하세요. 강력한 규칙이 있는 큰 코드베이스에서 rasen/config.yaml의 context:를 채우면 모든 제안서가 스택과 패턴을 존중합니다. 커스터마이징을 참조하세요.

다음은 어디로?

• 먼저 탐색 - 변경하기 전에 코드를 이해하기 위한 핵심 습관
• 시작하기 - 전체 첫 번째 변경 안내
• 변경 편집 및 반복 - 배우면서 변경 조정
• 개념: 증량 스펙 - 왜 증량이 기존 코드베이스 작업을 깨끗하게 만드는지
• 커스터마이징 - rasen에 프로젝트의 규칙을 가르치기