스토어: 자체 리포지토리에서 계획
베타. 스토어, 참조, 작업 컨텍스트 및 워크셋은 새로운 기능입니다. 명령 이름, 플래그, 파일 형식 및 JSON 출력이 릴리스 간에 변경될 수 있습니다. 아래의 모든 연습은 현재 빌드에 대해 실행되었지만 업그레이드 후 이 가이드를 다시 읽으십시오.
이 기능이 해결하는 문제
Rasen은 일반적으로 하나의 코드 리포지토리 내에 존재합니다. 코드 옆의 rasen/ 폴더에 해당 리포지토리의 스펙과 변경을 보유합니다.
계획이 하나의 리포지토리보다 커지는 순간 맞지 않게 됩니다.
- 작업이 여러 리포지토리에 걸쳐 있습니다. — 하나의 기능이 API 서버, 웹 앱 및 공유 라이브러리를 건드립니다. 계획이 어느
rasen/폴더에 있어야 합니까? - 팀은 코드가 존재하기 전에 계획하거나 이 리포지토리에서 코드가 되지 않는 항목을 계획합니다.
- 요구사항은 한 팀이 소유하고 다른 팀이 사용합니다. 위키 버전이 표류하고 코딩 에이전트가 어차피 읽을 수 없습니다.
스토어가 답입니다. 전체 작업이 계획인 독립형 리포지토리입니다. 이미 알고 있는 것과 동일한 rasen/ 구조를 보유합니다 — 스펙과 변경 — 그리고 작은 식별 파일을 추가합니다. 머신에 한 번 이름으로 등록하면 모든 일반 rasen 명령이 어디서나 스토어에서 작동할 수 있습니다.
구조
team-plans (a store: planning in its own repo)
├── .rasen-store/store.yaml identity: "I am team-plans"
└── rasen/
├── specs/ what is true
└── changes/ what is in motion
▲
│ registered on each machine by name;
│ shared by pushing/cloning like any repo
┌─────────────┼─────────────┐
│ │ │
web-app api-server mobile-app
(code repo) (code repo) (code repo)
두 가지 규칙이 이를 단순하게 유지합니다.
- 스토어는 단순한 git 리포지토리입니다. 직접 커밋, 푸시, 풀 및 검토합니다. Rasen은 절대 자체적으로 클론, 동기화 또는 푸시하지 않습니다.
- 선언, 메커니즘 아님. 리포지토리는 스토어와 어떻게 관련되는지 선언할 수 있습니다(아래 표시). 선언은 rasen이 알려줄 수 있는 내용을 변경합니다 — 명령이 작동하는 위치는 절대 변경하지 않습니다.
첫 스토어까지 5분
두 명령으로 준비된 스토어 범위의 변경으로 이동합니다.
rasen store setup team-plans --path ~/rasen-stores/team-plans
Store ready: team-plans
Location: /Users/you/rasen-stores/team-plans
Rasen root: ready
Registry: registered
Next: run normal rasen commands against this store, for example:
rasen new change <change-id> --store team-plans
Share this store by committing and pushing it like any Git repo.
rasen new change add-login --store team-plans
Using Rasen root: team-plans (/Users/you/rasen-stores/team-plans)
Created change 'add-login' at /Users/you/rasen-stores/team-plans/rasen/changes/add-login/
Schema: spec-driven
Next: rasen status --change add-login --store team-plans
이것이 전체 모델입니다. 여기서 라이프사이클은 정확히 알고 있는 것입니다 — status, instructions, validate, archive — 각 명령에서 --store team-plans 사용, 모든 인쇄된 힌트가 플래그를 포함합니다. Using Rasen root: 줄은 항상 명령이 작동하는 위치를 알려줍니다.
스토리: 한 팀, 하나의 계획 리포지토리
팀은 코드 리포지토리에 걸쳐 흩어지지 않고 스펙과 변경을 team-plans에 보유합니다.
첫 날(설정하는 사람):
rasen store setup team-plans --path ~/rasen-stores/team-plans \
--remote git@github.com:acme/team-plans.git
git -C ~/rasen-stores/team-plans push -u origin main
--remote를 전달하면 클론 URL이 초기 커밋의 스토어 자체 식별 파일(.rasen-store/store.yaml)에 기록됩니다. 모든 미래 클론은 어디에서 왔는지 알고 태어나므로 상태 확인 및 오류 메시지는 아직 보유하지 않은 팀 동료를 위해 완전하고 붙여넣을 수 있는 수정사항을 인쇄할 수 있습니다.
모든 팀 동료(머신당 한 번):
git clone git@github.com:acme/team-plans.git ~/rasen-stores/team-plans
rasen store register ~/rasen-stores/team-plans
그 이후로 모든 사람은 이름으로 동일한 계획 리포지토리에서 작업합니다.
rasen status --store team-plans --change add-login
rasen show add-login --store team-plans
작업 공유는 의도적으로 git입니다. 생성하는 변경은 커밋하고 푸시할 때까지만 체크아웃에 존재합니다 — 코드와 동일합니다. 계획은 스토어가 일반 리포지토리이므로 브랜치, 풀 요청 및 검토를 무료로 얻습니다.
팀의 코드 리포지토리 연결. 계획이 완전히 외부화된 코드 리포지토리는 rasen/config.yaml에 정확히 한 줄이 필요합니다.
# web-app/rasen/config.yaml
store: team-plans
이제 web-app 내에서 실행되는 모든 rasen 명령이 플래그 없이 team-plans에 작동합니다.
cd ~/src/web-app
rasen status --change add-login
Using Rasen root: team-plans (/Users/you/rasen-stores/team-plans)
...
포인터는 재정의가 아닌 폴백입니다. 명시적 --store은 항상 이기고, 리포지토리가 자신의 실제 계획 폴더를 확장하면 이들이 이깁니다(경고는 경고된 포인터를 제거하도록).
스토리: 팀 간 교차 요구사항
플랫폼 팀은 요구사항을 소유합니다. 제품 팀은 자신의 리포지토리에서, 자신의 설계로 대항하여 구축합니다. 참조는 누구의 작업도 이동하지 않고 해당 관계를 설명합니다.
platform-reqs (store) api-server (code repo)
owned by the platform team owned by a product team
┌──────────────────────────┐ ┌──────────────────────────┐
│ rasen/specs/ │ ◀────────│ rasen/config.yaml │
│ payments/spec.md │ reads │ references: │
│ auth/spec.md │ │ - platform-reqs │
│ │ │ rasen/specs/ │
│ rasen/changes/ │ │ (their own designs) │
│ platform work │ │ rasen/changes/ │
│ │ │ (their own work) │
│ │ └──────────────────────────┘
└──────────────────────────┘
제품 팀은 리포지토리의 rasen/config.yaml에서 무엇을 그리는지 선언합니다.
references:
- platform-reqs
참조는 읽기 전용 컨텍스트입니다. 리포지토리는 자신의 rasen/ 루트를 유지합니다. 작업은 그곳에 유지됩니다. 변경된 내용: 해당 리포지토리의 rasen instructions는 이제 참조 스토어의 스펙 색인을 포함합니다 — 각각 한 줄 요약과 정확한 fetch 명령(rasen show <spec-id> --type spec --store platform-reqs). api-server에서 작업하는 에이전트는 업스트림 지불 요구사항을 찾고, 인용하고, 리포지토리의 자신의 루트에서 저수준 설계를 작성할 수 있습니다 — 누구도 컨텍스트를 붙여넣을 필요가 없습니다.
참조는 클론 소스를 수행할 수 있으므로 스토어를 아직 갖지 않은 팀 동료는 막다른 골목이 아닌 완전한 수정사항을 얻습니다.
references:
- { id: platform-reqs, remote: "git@github.com:acme/platform-reqs.git" }
계획과 코드를 함께 열고 싶으면 워크셋을 만듭니다. 이는 개인적이고 명시적입니다. 각 사람은 머신에서 실제로 작업하는 폴더를 선택합니다. 이러한 로컬 체크아웃 경로에 대한 것은 공유 계획 리포지토리에 커밋되지 않습니다.
rasen workset create platform \
--member ~/rasen-stores/platform-reqs \
--member ~/src/api-server \
--member ~/src/web-app
항상 물을 수 있는 두 가지 질문
"설정이 건강합니까?" — rasen doctor는 현재 루트 및 참조 스토어를 읽기 전용으로 확인하며, 발견당 붙여넣을 수 있는 수정사항을 제공합니다.
Doctor
Root
Location: /Users/you/src/api-server
Rasen root: ok
References
- platform-reqs: ok (/Users/you/rasen-stores/platform-reqs)
- design-system: Referenced store 'design-system' is not registered on this machine.
Fix: git clone -- git@github.com:acme/design-system.git '/Users/you/rasen-stores/design-system' && rasen store register '/Users/you/rasen-stores/design-system' --id design-system
"나는 무엇과 함께 작업하고 있습니까?" — rasen context는 rasen 선언에서 작업 집합을 조립합니다. 루트 및 참조하는 스토어.
Working context for api-server (/Users/you/src/api-server)
Rasen root
api-server /Users/you/src/api-server
Referenced stores
platform-reqs /Users/you/rasen-stores/platform-reqs
Fetch: rasen show <spec-id> --type spec --store platform-reqs
둘 다 에이전트의 --json을 지원합니다. rasen context --code-workspace <path>는 추가로 전체 집합을 포함하는 VS Code 워크스페이스 파일을 작성합니다 — 이 명령이 수행하는 유일한 쓰기입니다.
워크셋: 함께 작업하는 폴더 다시 열기
위의 모든 항목과 별도로 대부분의 사람들은 매 세션마다 동일한 몇 개의 폴더를 함께 엽니다 — 계획 리포지토리와 두 세 개의 코드 리포지토리. 워크셋은 정확히 그것의 개인적이고 명명된 뷰이며, 선택한 도구에서 한 명령으로 다시 열립니다.
workset "platform" rasen workset open platform
├── team-plans ~/rasen-stores/team-plans │
├── api-server ~/src/api-server ▼
└── web-app ~/src/web-app all three open in your tool
rasen workset create platform \
--member ~/rasen-stores/team-plans --member ~/src/api-server \
--tool code
rasen workset list
platform (opens in VS Code)
team-plans /Users/you/rasen-stores/team-plans
api-server /Users/you/src/api-server
rasen workset open platform는 저장된 도구를 시작합니다. 에디터(VS Code, Cursor)는 모든 멤버가 있는 한 창을 열고 돌아옵니다. 첫 번째 멤버가 기본입니다. --tool <id>로 도구를 언제든지 재정의합니다.
워크셋은 의도적으로 공유되지 않은 상태입니다. 머신에 있으며, 절대 커밋되지 않으며, 작업에 대한 주장을 하지 않습니다 — 함께 열려있는 항목을 기록합니다. 하나를 제거하면 멤버 폴더를 절대 건드리지 않습니다. 새 도구는 코드가 아닌 구성입니다. 워크스페이스 파일 또는 폴더별 attach 플래그를 통해 시작되는 모든 것을 전역 구성(rasen config edit)의 openers 키 아래에 추가할 수 있습니다.
명령이 작동할 위치를 결정하는 방법
모든 일반 명령은 다음 순서로 루트를 해석합니다.
1. --store <id> you said so explicitly → that store
2. nearest rasen/ a real planning root here → this repo
(walking up from cwd)
3. store: pointer config.yaml declares a store → that store
4. none of the above stores registered on this → error with a
machine? selection hint
no stores registered? → the current
directory
(classic behavior)
Using Rasen root: 줄(및 --json 출력의 root 블록)은 어느 경우인지 알려줍니다.
알려진 제한 사항
- 베타 구조. 이 페이지의 모든 항목이 릴리스 간에 변경될 수 있습니다 — 이름, 플래그, 파일 형식, JSON 키.
- 머신당 스토어 id당 하나의 체크아웃. 같은 id로 두 번째 체크아웃을 등록하면
store unregister먼저 힌트와 함께 실패합니다. - 동기화 없음, 절대 — 의도적으로. Rasen은 절대 클론, 풀 또는 푸시하지 않습니다. 진부한 체크아웃은 직접 풀 때까지 진부한 스펙을 보여줍니다. 참조는 디스크에 있는 것에서 실시간으로 색인됩니다.
- 일부 명령은 그들이 있는 곳에 머물러 있습니다.
view,templates및schemas는 현재 디렉토리에서만 작동합니다 —--store없음. - 머신별 상태는 머신별입니다. 스토어 레지스트리 및 워크셋은 로컬 설정입니다. 머신 레이아웃에 대한 어느 것도 공유 계획에 커밋되지 않습니다.
- 워크셋에 대한 두 가지 시작 스타일. 워크스페이스 파일 또는 폴더별 attach 플래그로 시작할 수 없는 도구는 오프너로 추가될 수 없습니다.
- 에이전트 JSON에는 알려진 케이싱 분할이 있습니다(스토어 계열 키는 snake_case, 워크플로우 계열 camelCase). 에이전트 계약에 문서화되었습니다. 통합은 버전 지정된 릴리스로 연기되었습니다.
항목이 있는 곳
| 항목 | 위치 | 공유? |
|---|---|---|
| 스토어의 계획 | <store>/rasen/(스펙, 변경) |
예 — 커밋하고 푸시합니다 |
| 스토어의 식별 | <store>/.rasen-store/store.yaml |
예 — 스토어와 함께 커밋됨 |
| 스토어 레지스트리 | <data dir>/stores/registry.yaml |
아니오 — 이 머신만 |
| 워크셋 | <data dir>/worksets/ |
아니오 — 이 머신만 |
<data dir>은 모든 플랫폼에서 ~/.rasen입니다. RASEN_HOME을 설정하여 재배치합니다. $XDG_DATA_HOME/rasen은 여전히 호환성 별칭으로 RASEN_HOME 아래에서 존중됩니다.
참조
이 페이지의 모든 명령에 대한 정확한 플래그 및 JSON 형태: CLI 참조(스토어, Doctor, 작업 컨텍스트, 개인용 워크셋) 및 에이전트 계약.