setup-context-driven

コンテキスト主導型セットアップ

公開されている roundfix baseline コマンドファミリーを使用します。Roundfix バイナリは、Baseline Profiles、リポジトリの検査、Decision Plans、Change Plans、確認、適用、復旧、Baseline の検証における唯一の実行時の権威です。このスキルが提供するのはレシピと解釈のみです。独自のセットアップエンジンや動作上のフォールバックはありません。

初回の導入または復旧の前に、永続的な運用契約を読んでください。 docs/user-guide/context-driven-development.md#adopt-or-update-the-context-driven-baseline

境界

Baseline が管理するのは、宣言されたルートブロック、セットアップ管理のガイド、初回導入時のルート指示のバックアップ、および docs/agents/setup-context.json です。管理対象の境界外にある、リポジトリ作成者が記述したバイト列は保持されます。

Baseline は、以下のことを決して行いません。

• アプリケーションや Agent の依存関係をインストールする
• データベースや稼働中のインフラストラクチャに接続する
• リポジトリのフォーマッター、ビルド、テスト、lint、マイグレーション、検証コマンドを実行する
• 安全でないリンクをたどる、またはネストされた指示の格納先を変更する
• 実装の証拠からリポジトリのポリシーを推定する
• ACP の提案によって変更を承認する
• プロファイルを組み合わせる、またはユーザースコープやリモートのプロファイルを読み込む

プロファイルの期待事項、リポジトリのコマンド、推奨事項は、それぞれ異なる事実として扱ってください。プロファイルの期待事項は移植可能なポリシーであり、実装の証明ではありません。リポジトリのコマンドは、結果に repositoryExecutable: true が示され、ローカルの宣言に紐付いている場合にのみ実行可能です。推奨事項はメンテナーが実行するコマンドであり、Baseline は実行していません。

合成されたガイダンスを解釈する

生成されたルートの指示階層を、普遍的な指示から順に、コンテキストとドキュメント、Spec のワークフロー、有効化された自律作業、スタックのガイダンス、対象領域のガイダンス、任意のナレッジソースまで読みます。より範囲の狭いガイドは、その対象に関する制約を追加できますが、普遍的な規範条項や確認済みのプロジェクト上の決定を弱めることはできません。

Greenfield の合成では、Baseline Profile が選択したガイドとポインターのみが出力されます。汎用のリポジトリガイドは作成されず、リポジトリ固有の規範ルールがない場合、残余の格納先も作成されません。

Greenfield で、分類が必要な管理対象ソースが保持される場合、Greenfield は処理を拒否し、選択する方法として preservation.mode=preservation を提示します。

更新または Baseline Readoption では、承認する前に完全な保持台帳を解釈してください。既存のルールはすべて、1つのアクティブな意味上の所有先、認識済みの型付きリポジトリ文書、または docs/agents/specific-repository.md のいずれかに、元のバイト列のまま保持するか、個別の理由を示して却下するか、非管理対象として分類する必要があります。残余が空の場合、格納先とルートポインターが削除されます。空でない残余を承認した場合、元のルールのみが保持されます。

生成された docs/agents/docs-layout.md が、コピー可能な ADR および Findings の契約を管理します。ADR でアクティブなのは accepted のみです。ライフサイクルのフロントマターがないレガシー ADR は、本文で非アクティブと示されていない限りアクティブなままです。Findings では、pending、partial、deferred、done と、終端ステータスの deprecated、superseded、closed、cancelled を使用します。元の観察内容を維持し、その後の証拠は日付付きの追記として追加します。生成されたテンプレートをコピーしてください。このスキルはテンプレートを生成または置換しません。

採用済みリポジトリを更新する

リポジトリに互換性のある Setup Manifest がある場合は、非対話型の管理された更新パスを使用します。

roundfix baseline update --repo . --format json

確認を行わずに変更後の Plan が提示され、リポジトリのバイト列は変更されません。複数リポジトリを一括処理する場合は、同じ呼び出しで計算された Plan Digest を承認します。

roundfix baseline update --repo . --yes --format json

このコマンドは Setup Manifest から現在の Baseline Profile と互換性のある決定を導き出します。確定済みの質問は行わず、セマンティック分類も実行しません。変更するのは Baseline が管理する領域と Repository Skill Set のみです。管理対象の境界外のバイト列はすべて完全に同一のままです。

以前レビューした Plan Digest には、--yes の代わりに --confirm-plan <digest> を使用します。マニフェストに存在しない決定がある場合、メンテナーが明示的に --adopt-suggested を選択しない限り、何も書き込まずに終了コード 3 で終了します。Repository Skill Set の更新を抑制する場合に限り --no-skills を使用し、宣言済みのオフライン Git チェックアウトまたはベアオブジェクトストアを指定する場合に限り --skills-source-dir <path> を使用します。

リポジトリでは、完全な verification.gate とは別に、verification.incremental を通じて高速なローカルコマンドを選択します。単一ゲートの Setup Manifest の場合、不足している増分検証の決定を示して何も書き込まず、終了コード 3 で終了します。リポジトリで推奨される make verify-incremental コマンドをローカルに宣言した後、--adopt-suggested を指定して更新を再実行します。以降の更新では、そのフラグを指定しなくても記録済みの決定が使用されます。

ユーザーによる導入またはプロファイルの変更

対話型ターミナルで、次を実行します。

roundfix baseline --repo . --format text

対話型ワークフローでは、初回導入、Baseline Profile の変更、または Setup Manifest に保持されていない判断を処理します。Baseline Profile を1つだけ選択し、ファイル変更を先頭にまとめた1つの Change Plan を表示します。互換性のある Setup Manifest がある場合、確定済みの判断と意味分類を省略します。完全なプランと Plan Digest が表示されるまでは、変更を許可しないでください。

判断と保持に関するプロンプトでは、表示されている既定値を1つ示します。Enter キーを押すと、その値が確定します。保存済みの Setup Manifest 値が有効であれば、変更された Profile Digest により再導入が必要な場合でも、その値が優先されます。それ以外の場合、CLI は組み込みカタログの推奨値を使用します。バックエンド作業には codex gpt-6.1-sol high、デザイン作業には claude opus high が含まれます。既存のルート指示ファイルは既定で Preservation が選択され、指示ファイルの一覧が空の場合は Greenfield が既定で選択されます。また、復旧可能な既存プロファイルが優先されます。分類、Plan の承認、適用には、引き続き空でない選択を明示的に行う必要があります。

初回導入時には、保守担当者に次のいずれかの指示モードを選んでもらいます。

• Greenfield では、安全なルートの格納ファイルをバックアップし、そのルールは一切インポートしません。
• Preservation では、安全なルートの格納ファイルをバックアップし、Source Baseline Entry ごとに1つのレビュー済み処置を指定する必要があります。

ネストされた指示ファイルは変更せず、警告としてのみ表示します。安全でないルートの格納ファイルがある場合、プランの作成はブロックされます。封印済み ACP の分類が利用できないか破棄された場合は、公開コマンドの構造化された手動分類レビューを続行します。Source Baseline の識別情報、分類、移行先を決して捏造しないでください。

Repository-Specific Normative Rules の正規の格納先は1つです。 docs/agents/specific-repository.md。 有効化の判断によりこの移行先を使用できますが、空のひな型は作成されません。Baseline は、承認済みの空でないルールがある場合にのみ、このファイルと管理対象のルートポインターを作成します。従来の docs/agents/repository.md または docs/agents/repository-rules.md を、バイト単位でそのまま移行し、既知の空の従来のひな型は削除します。内容が異なる空でない従来の格納ファイルがある場合は、手動での調整が必要なため処理をブロックします。従来の移行先のいずれかを指定する既存の 0.0.1 Decision Document は、正規のパスに正規化されます。

管理対象の更新には roundfix baseline update を使用します。Profile Digest が変わっただけでは、プロファイルと保存済みの判断が引き続き解決可能な場合、再度のヒアリングは必要ありません。プロファイルを変更すると、新しい完全な対話型プランが作成されます。保守担当者がプランを却下した場合は、コマンドの判断領域の改訂フローを使用します。受け入れた修正ごとに、新しい Plan Digest を生成し、もう一度全体をレビューする必要があります。

プロファイルの整合性確認は、指示の分類より先に実行されます。プロファイル固有のブロッカーがある場合、対話型コマンドでは Change Baseline Profile、レビュー済みの repository-owned Profile adaptation、または Decline without writing が提示されます。適応では、すべてのモジュールとプロファイル固有機能の削除内容を一覧表示し、リポジトリ所有の Profile ID を検証し、メモリ内のドラフトを再監査して、整合性が整った場合にのみ続行します。Profile ファイルは最終的な Change Plan に含まれ、Plan Digest の承認前には書き込まれません。

全般的に必須の機能は削除も免除もできません。結果で指定された正確な復元プレビューを実行し、その Plan Digest をレビューして、同じ最新のプレビューであることを確認したうえで、プロファイルの整合性確認を再実行します。

roundfix baseline skills restore --repo . --profile <built-in-id> --skill <skill-name> --format json
roundfix baseline skills restore --repo . --profile <built-in-id> --skill <skill-name> --confirm-plan <digest> --format json

プロジェクトの決定事項と Spec の制約

CLI がプロジェクトの決定事項の収集と表示を担当します。このスキルは決定事項を収集、導出、検証、表示せず、公開結果を説明し、修正をすべて roundfix baseline に差し戻します。

verification.incremental は、公開されるガイダンスを生成した、選択済みの高速なローカルチェックを指します。リポジトリ全体を対象とする完全な Verification を指す verification.gate とは別に必須です。

HTTP モードのみを変更する場合、すべての例外とソースはそのまま維持されます。

Standard TypeScript Monorepo Profile では、UUID version 7 が identifier.strategy に対する明示的な提案です。人間がそれを明示的に採用するか、リポジトリで定義された空でないルールを 1 つ提示する必要があります。Better Auth が引き続き選択されている場合、auth.provider は /api/auth/* 配下の GET と POST、所有者 Better Auth、および Session、OAuth リダイレクト、コールバック、関連するプロバイダープロトコルに基づく理由を提案します。人間は、この型付きの提案全体を採用するか変更する必要があります。/api/auth は Better Auth のデフォルトのベースパスであり、Baseline のルールではありません。リポジトリで Better Auth を別の場所にマウントする場合は、任意の auth.base_path の決定事項を記録し、プロバイダーと HTTP の例外は、そのパスに続く /* を対象とします。

自動化では、--decision-file に渡す厳密な Decision Document を通じて、両方の構造化値を指定します。いずれかの値が未解決の場合、計画は 3 で終了し、roundfix/baseline-result/v1 に不足しているすべての決定事項を示し、部分的な Plan を出力せず、何も書き込みません。カタログの提案、リポジトリの証拠、セットアップの承認、空の回答を、決定権限として扱ってはなりません。

新しい PRD と TechSpec には、以下を対象とする Project Constraints の行を必ず含めます。

• docs/agents/domain.md に記載された識別子戦略。
• docs/agents/backend.md に記載された認証と HTTP。
• docs/agents/spec-routing.md に記載された有効な ADR の義務。
• docs/agents/agent-instructions.md に記載されたツール権限。

各行には、理由とともに該当または非該当を明記する必要があります。保護対象のツール関連作業は、Spec に保守担当者の明示的な承認と、リポジトリ相対の対象ファイルを範囲を限定して正確に記録するまで、引き続きブロックされます。タスクの割り当てや一般的な実装依頼は、その権限を付与しません。完了済みおよびアーカイブ済みのレガシー Spec は、バイト単位で変更しないでください。

導入またはプロファイル変更のための非対話型プランニング

対話型のルートコマンドは、端末入力がリダイレクトされている場合、または端末入力がない場合に実行を拒否します。 自動化やエージェントは、導入済みのリポジトリに対して baseline update を使用します。初回導入またはプロファイル変更の場合は、次を使用します。

roundfix baseline plan --repo . --profile <profile-id> --decision-file <decision-file> --format json

自動化では、同等のレビュー済み厳格ドラフトを渡すこともできます。

roundfix baseline plan --repo . --profile-file <draft.json> --decision-file <decision-file> --format json

--profile-file と --profile は同時に指定できません。CLI はドラフトを埋め込みカタログに照らして検証し、メモリ内で解決して、正規化されたリポジトリパスと正確なバイト列をポータブルな Plan に含めます。このスキルを通じてドラフトを書き込んだり、正規化、分類、レンダリングしたりしないでください。

スカラー形式の回答には、繰り返し指定可能な --decision <id=value> フラグを使用できます。構造化された回答には、スキーマが setup-context-driven/decisions/0.0.1 の厳格な Decision Document を繰り返し使用します。

終了カテゴリに従って結果を解釈します。

• 0：標準出力に、完全な roundfix/baseline-plan/v1 ドキュメントが1つ出力されます。
• 2：無効な入力、スキーマ、Git の状態、または安全でないキャリアを修正します。
• 3：roundfix/baseline-result/v1 の nextAction に従います。不完全な Plan は存在しません。

保持する場合は、公開された人間による分類レビューから作成された、最新かつ厳格な Decision Document のみを使用してください。現在の Source Baseline とすべての Source Baseline Entry に、それぞれ正確に1回ずつ対応付ける必要があります。リポジトリのバイト列が変わった後に、識別子やダイジェストを再利用しないでください。

少なくとも次の項目をレビューします。

• repository、catalog、および解決済みの1つの profile；
• 正規化された decisions；
• fileChanges と完全な正規 managedEntries 台帳；
• retention、warnings、および提案されている setupManifest；
• Plan に履歴の移動が含まれる場合は、historyMoves と baseline.history.citation に関する警告；
• すべての正確な preimage と postimage；
• planDigest。

Plan には、リポジトリポリシーと正確な生成バイト列が含まれることがあります。機密性の高いレビュー成果物として保管し、転送してください。

承認済み Plan の適用

メンテナーに、現在の planDigest をそのまま承認するよう依頼します。その後、次を実行します。

roundfix baseline apply --repo . --plan <plan-file> --confirm-plan <plan-digest> --format json

Apply は、指定された roundfix/baseline-plan/v1 ドキュメントを厳密に解析し、その postimage のみを適用します。Plan の再計算や置き換えは行いません。

終了コード：

• 0：Apply と Baseline の検証に成功したか、正確な postimage がすでに検証済みです。
• 1：実行、検証、復旧、出力、またはロールバックの失敗を調査します。
• 2：無効な入力、Plan スキーマ、または安全でないリポジトリを修正します。
• 3：確認、preimage、カタログ、プロファイル、または Git の系譜が最新ではなくなっています。新しい Plan を生成してレビューしてください。
• 130：操作がキャンセルされました。

ポータブルな Plan を別のクローンに適用できるのは、クローン間で安定した Git の系譜、オブジェクト形式、カタログ ID、プロファイル、およびすべての制約対象 preimage が一致する場合に限られます。

Baseline プロファイル

公開 CLI を通じてプロファイルを検査、検証します。

roundfix baseline profile show <profile-id> --format json
roundfix baseline profile validate <profile-id> --format text

組み込みプロファイルを1つ使って、リポジトリ所有のプロファイルを1つ作成します。

roundfix baseline profile init --id <repository-profile-id> --from <built-in-id>
roundfix baseline profile validate <repository-profile-id> --format text

リポジトリ所有のプロファイルは .roundfix/baseline/profiles/<id>.json の下にのみ配置し、埋め込みカタログのエントリ ID のみを組み合わせ、リポジトリとともにバージョン管理する必要があります。プロファイル同士を組み合わせたり、ユーザースコープのカタログを読み込んだり、実行可能なコンテンツやリモートコンテンツを宣言したりすることはできません。

Repository Skill Set の復元

導入時には、不足または変更された外部スキルが報告されますが、副作用として復元されることはありません。明示的に要求した復元をプレビューします。

roundfix baseline skills restore --repo . --profile <built-in-id> --skill <skill-name> --format json

プレビュー結果が空でない場合、Plan Digest とともに終了コード 3 で終了し、何も書き込みません。メンテナーがそのプレビューを正確に承認した後、次を再実行します。

roundfix baseline skills restore --repo . --profile <built-in-id> --skill <skill-name> --confirm-plan <plan-digest> --format json

--source-dir <path> は、正確な不変のソースコミットを含む、宣言済みのオフライン Git チェックアウトまたはベアオブジェクトストアに限って使用してください。汎用的なスキル更新で代用しないでください。

復元後、同じ Baseline Plan を再度生成します。復元に成功して証明されるのは、選択された Repository Skill Set のバイト列であり、リポジトリで定義されたポリシーではありません。

正規アセットの同期

これはメンテナー専用の操作であり、通常の導入では実行しません。

roundfix baseline assets sync --source-dir <canonical-setups> --check --format json

--check を付けずに実行するのは、Go が管理する正規セットアップスナップショットの更新をメンテナーが明示的に許可した場合に限ります。このコマンドは、正規セットアップアセットのみを変更する前に、ソースの来歴と生成されたカタログを検証します。

復旧

• 判断が不足している場合、または手動で分類する場合：nextAction に従い、現在の構造化入力を完了して、プランニングを再実行します。
• 確認内容が一致しない場合：レビュー後、提示されたプランから現在の Plan Digest 全体をコピーします。
• プランが古い場合：新しいプランを生成して承認します。古いプランを編集したり、強制実行したりしないでください。
• 安全でないキャリアの場合：報告された正確なパスを修復します。場当たり的な回避策でそのパスをたどったり、置き換えたりしないでください。
• トランザクションが中断された場合：同じ公開 apply コマンドを再実行し、Roundfix が Git のプライベートジャーナルをロックして復旧できるようにします。復旧状態は削除しないでください。
• ロールバックが不完全な場合：書き込みを停止し、チェックアウトと復旧状態を保持して、報告されたすべてのパスを確認し、信頼できるバイト列を復元して、新しいプランを生成します。

完了

プランニングだけで導入または更新が完了したと主張しないでください。

1. apply の終了コードが 0 であることを確認し、verifiedPostimages を確認します。
2. 報告された各フォーマッターまたは Verification の推奨事項を、Baseline の外部で実行します。
3. Baseline の管理対象出力の外部で、リポジトリに関する失敗を修復します。
4. 同じ現在の Profile 入力と判断を使って、新しいプランを生成します。
5. ファイルの変更がないことを確認するか、終了コード 0 で完全に冪等な再適用を行います。

残っている警告、未実行の推奨事項、承認済みの Plan Digest、最終的な Baseline の結果状態を報告します。