ストア: その独自のリポでプランニング
ベータ版。 ストア、参照、作業コンテキスト、およびワークセットは新しいものです。コマンド名、フラグ、ファイル形式、および JSON 出力はリリース間で変わる可能性があります。以下のすべてのチュートリアルは現在のビルドに対して実行されましたが、アップグレード後にこのガイドを読み直してください。
これが解決する問題
Rasen は通常、1 つのコード リポの内部に存在します: コードの隣にある rasen/ フォルダで、そのリポの仕様と変更を保持しています。
プランニングが 1 つのリポより大きくなった瞬間、それはフィットするのを停止します:
- 作業は複数のリポにまたがります—1つの機能は API サーバー、ウェブ アプリ、共有ライブラリに触れます。プランはどの
rasen/フォルダに存在するでしょうか？ - チームはコードが存在する前、またはこのリポでコードにならないものをプランニングします。
- 要件は 1 つのチームによって所有され、他のチームによって消費されます。Wiki バージョンは漂流し、コーディング エージェントはそれをどのみち読むことができません。
ストアが答えです: スタンドアロン リポ、その全体的な仕事はプランニングです。既に知っている同じ rasen/ 形状を持っています—仕様と変更—プラス小さな ID ファイル。マシン上に一度名前で登録し、すべての通常のraseんコマンドはどこからでもそれで機能できます。
形状
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)
2つのルールはこれを簡単に保ちます:
- ストアは単なる git リポです。 コミット、プッシュ、プル、レビューを自分で実行します。Rasen はクローン、同期、プッシュを独自に行いません。
- メカニズムではなく宣言。 リポはストアとの関係を宣言できます（下を参照）。宣言はraseんが何を伝えられるかを変えます—コマンドが動作する場所は変わりません。
最初のストアまで 5 分
2つのコマンドで、ストアスコープの変更が機能します:
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: 行は常にコマンドが動作している場所を伝えます。
ストーリー: 1 つのチーム、1 つのプランニング リポ
チームはコード リポ全体に分散させるのではなく、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 をストア独自の ID ファイル（.rasen-store/store.yaml）に初期コミット内に記録します。将来のすべてのクローンはそれがどこから来たかを知っていて生まれるため、ヘルス チェックとエラー メッセージはまだ持っていないチームメイト用に完全で貼り付け可能な修正を出力できます。
すべてのチームメイト（マシンごとに 1 回）:
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 の正確に 1 行が必要です:
# web-app/rasen/config.yaml
store: team-plans
これで、web-app 内で実行されるすべてのraseんコマンドはまったくフラグなしで 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 は参照されたストアの仕様のインデックスを含みます—各々 1 行の要約と正確なフェッチ コマンド（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
常に質問できる 2 つの質問
「セットアップは健全ですか？」 — 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 はraseん宣言から作業セットを組み立てます: ルートと参照するストア。
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 ワークスペース ファイルをさらに書き込みます—このコマンドが実行する唯一の書き込み。
ワークセット: 一緒に作業するフォルダを再度開く
上記のすべてとは別: ほとんどの人がすべてのセッションで同じ数個のフォルダを一緒に開きます—プランニング リポとコード リポ 2 つ～3 つ。ワークセットはその正確な個人的で名前付きビュー、ツール選択で 1 つのコマンドで再度開きます。
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）はすべてのメンバーを含む 1 つのウィンドウを開いて戻ります。最初のメンバーが主要。--tool <id> でいつでもツールをオーバーライド。
ワークセットは意図的に共有されていない状態です。マシン上に存在し、コミットされることはなく、作業についての主張を行いません—マシン上で一緒にオープンにしたいものを記録するだけです。1 つを削除してもメンバー フォルダには触れません。新しいツールは設定であり、コード ではありません: ワークスペース ファイルまたはフォルダごとのアタッチ フラグを介して起動できるすべてのものは、グローバル設定（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 ごとに 1 つのチェックアウト。 同じ ID の下で 2 番目のチェックアウトを登録すると、
store unregisterヒント付きで失敗します。 - 同期なし、決してなし—設計上。 Rasen はクローン、プル、プッシュを行いません。古いチェックアウトは あなたが プルするまで古い仕様を表示し、参照はディスクにあるものからライブでインデックスされます。
- 一部のコマンドはそこにあります。
view、templates、schemasは現在のディレクトリでのみ動作します—--storeなし。 - マシンごとの状態はマシンごとです。 ストア レジストリとワークセットはローカル設定です。マシンのレイアウトについての何も共有プランニングにコミットされることはありません。
- ワークセットの 2 つの起動スタイル。 ワークスペース ファイルまたはフォルダごとのアタッチ フラグで起動できないツールはオープナーとして追加できません。
- エージェント JSON には既知のケーシング分割があります（store-family キーは snake_case、workflow-family camelCase）。エージェント契約で文書化。統一は版付きリリースに延期されます。
物事がどこに住むか
| 内容 | 場所 | 共有されていますか？ |
|---|---|---|
| ストアのプランニング | <store>/rasen/（仕様、変更） |
はい—コミットしてプッシュ |
| ストアの ID | <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 リファレンス（ストア、ドクター、作業コンテキスト、個人用ワークセット）およびエージェント契約。