他の言語: English, Español, Português, Deutsch, Français, 한국어, 简体中文, Italiano, हिन्दी · 日本語のガイド一覧
開示: Carbon Forge と、その隣の AEGIS は 100monkeys.ai で開発しているため、作り手による説明として読んでください。このガイドは公開ドキュメント、主に Working in lanes のステップ 8、Source control settings、MCP tools catalog: Lanes, continued、Source control: how it is built and why をもとに当社の AI エージェントが下書きし、当社がレビューしました。この日本語版は英語の原文ガイドの翻訳です。表、呼び出し、拒否メッセージはドキュメント自身のもので、引用は英語のまま示し訳を添えています。ドキュメントが答えていない点は最後の節に書いています。
なぜルールを記録の中に置くのか
ドキュメントは理由を 2 文で述べています。"Landing rules are the code-owners rule kept in the record. The approvers a path needs are named on a page of the workspace, and each approval binds to the lane's composition hash, so review is the record's and not a forge's."(ランディングルールは、記録の中に置かれたコードオーナーのルールです。パスに必要な承認者はワークスペースのページに書かれ、各承認はレーンのコンポジションハッシュに結び付くので、レビューはフォージのものではなく記録のものになります。)これがなければ、"a landing can carry code no approver saw."(ランディングが、どの承認者も見ていないコードを運びうる)のです。最初に一つ制限を。"Carbon runs no review itself."(Carbon 自身はレビューを行いません。)誰が何を承認したかを記録するだけで、レビューをするのは人と、あなたが指定するワークフローです。
ステップ 1. トランクを保護する
ルールが読まれるのは保護されたトランクの上だけです。ワークスペース管理者が Settings、Workspace、Source control で Protect the trunk にチェックを入れ、必要なら Protect pages and atoms too にも入れます。エージェントは次の呼び出しで設定を確認します。
workspaces.get_settings {}
→ { "workspaceId": "…", "trunkProtected": true, "trunkProtectedEntities": false }以後、"the trunk moves only by a lane's landing"(トランクはレーンのランディングでしか動きません)。直接の書き込みは workspace <slug> protects its trunk: the trunk lands by lanes.land only; write on a lane で拒否されます。
ステップ 2. .landing-rules ページを書く
予約パス .landing-rules にページを作り、最初の Markdown 表の見出しを glob | approvers | gate にします。ドキュメントの例です。
| glob | approvers | gate |
| --- | --- | --- |
| app/src/billing/** | <user id>, <user id> | |
| docs/** | <user id> | docs-review |glob: インポートの除外ルールと同じ構文のルールを一つ。!で始めてはいけません。approvers: カンマ区切りのユーザー ID で、それぞれワークスペースのメンバーであること。ゲートを指定する行では空でもかまいません。gate: 任意。AEGIS のワークフローの名前で、128 文字まで。"Carbon never runs it."(Carbon がそれを実行することはありません。)
このページを書けるのはワークスペース管理者だけで、トランクでもレーンでも同じです。それ以外の人は The landing rules page .landing-rules is reserved: only a workspace admin writes it. で拒否されます。
ステップ 3. サーバーが有効と読むことを確かめる
設定ダイアログの Landing rules の節は <n> rules, valid. と報告するか、不正な行を示して Every landing is refused until it is fixed. と表示します。メンバーでない人を指定した行や、承認者もゲートも指定していない行は不正です。壊れたページはすべてのランディングを止めるので、頼る前にここを確認してください。
ステップ 4. レーンで作業する
Working in lanes のとおりにレーンを開いて書き込みます。ランディング時には、レーンが触れるすべてのパスが各行と照合されます。ページはそのパスで、移動したページは両方のパスで、ツリーのファイルは <tree path>/<entry path> として照合されます。
ステップ 5. レーンにまだ必要なものを読む
lanes.create { "label": "agent/7/fix-login" }
lanes.get { "label": "agent/7/fix-login" }
lanes.export { "lane": "agent/7/fix-login" } // header line: # composition: <hash>
lanes.approve { "lane": "agent/7/fix-login" }lanes.get は、誰が承認したか、誰が足りないか、各ゲートが pending か satisfied かを一覧します。アプリでは、レーンの Overview に同じことが表示されます。一致するルール、m 人中 n 人の承認、そしてゲートからの承認には "via gate <workflow>" の印が付きます。
ステップ 6. 正確な変更を承認する
レビュアーは、# composition: <hash> で始まる 1 つの unified diff である lanes.export を読み、それから lanes.approve を呼びます。承認はそのハッシュに結び付くので、"a reviewer who reads the export and approves at its # composition: value has approved exactly that change."(エクスポートを読み、その # composition: の値で承認したレビュアーは、まさにその変更を承認したことになります。)その後のパッチ、解決、トランクの移動でランディングされる内容が変わればハッシュも変わり、それ以前の承認は数えられなくなります。承認は最後の変更の後に行い、前には行わないでください。
ステップ 7. AEGIS のワークフローにゲートとして承認させる
ゲートを満たせるのはそのワークフロー自身だけです。実行のトークンは tokens.mint_execution で、任意の workflow 引数にゲートの名前(1 から 128 文字)を設定して発行し、実行はそのトークンで lanes.approve を呼びます。一致は完全一致で、"case included"(大文字と小文字も含めて)です。"A person's approval, and one given through a token minted without workflow, satisfies no gate."(人の承認や、workflow なしで発行したトークンによる承認は、どのゲートも満たしません。)実行トークンは呼び出し元のトークンの子で、1 つのワークスペース、1 つのツリーパス、1 つのレーン、ツールのリスト、最長 1 日に限られます。AEGIS by 100monkeys.ai, in beta では、ゲートはあなた自身のワークフローです。行がその名前を指定し、Carbon Forge はその実行が承認したことだけを確かめます。
ステップ 8. ランディングする
lanes.land { "label": "agent/7/fix-login", "intent": "fix: accept magic links", "dry_run": true }
lanes.land { "label": "agent/7/fix-login", "intent": "fix: accept magic links" }承認が足りないランディングは、足りないものを示して丸ごと拒否されます。
Lane <label> touches <path> under landing rule <glob> (line <n>), which needs approval from <user ids> and gate <name> at the lane's current composition. Approve with lanes.approve; nothing was written.ランディングすると、消費した承認は、ゲートのものも含めて "follow its intent as Approved-by: lines"(Approved-by: 行として意図の後に続き)、チェンジセットは他と同じように封印されます。なお、dry_run のランディングはルールを確認しません。確認には lanes.get を読んでください。
ドキュメントが答えていないこと
- AEGIS 側。ドキュメントは "the execution service"(実行サービス)が
workflow付きで実行のトークンを発行すると書いていますが、そのトークンを持ってlanes.approveを呼ぶ AEGIS のワークフローは示していません。 - 承認者はユーザー ID だけです。グループやチームはなく、設計は "No per-directory permissions"(ディレクトリ単位の権限はなし)としています。
- 実行トークンによる承認が、トークンのユーザーが承認者として載っている場合に、そのユーザーの承認としても数えられるかどうか。