mo-setup

Meta-O 用のプロジェクトをセットアップする

ユーザーが mo-setup と指定した場合に限り開始してください。一般的な環境やツールに関する質問では、セットアップによる変更を開始しないでください。

プロジェクトセットアップ契約、 バックエンド契約、 方法論に関するフィードバック、 確認済みの外部作業のルーティング、 目的とアーキテクチャの契約をすべて読みます。Python の場合は Python QC プロファイルを、JavaScript／TypeScript の場合は TypeScript QC プロファイルを読みます。複合プロジェクトの場合は両方を読みます。

内容を確認します。ビジネス／アーキテクチャ ID、用語集、README、バイト単位で同一のエージェント契約、一時的な機能バックログ、受け入れテスト／E2E、目的、成熟した言語ゲート、変更を伴わない決定論的な集約 QC です。動作上の不具合が確認された場合は、最小限の回帰テストを必須とします。また、所有権／並行性／信頼性／セキュリティ／互換性／トランザクション／リソース寿命に関わる大規模な修正には、不変条件を記したコメントを必須とします。 名前を指定した利用者がいない限り、通常の対象プロジェクトにバックエンドのフィクスチャ文書を作成しないでください。

まず、同梱の scripts/mo-knowledge-layer.mjs --candidate <HEAD sha> を使ってナレッジレイヤーを読み込み、レビュー担当者向け概要に記載される行をそのまま報告してください。これまでレイヤーがなかったプロジェクトでは Knowledge-Layer: state=not_enabled reason=never_enabled と答えます。レイヤーが存在していたもののシグナルが失われている場合は、ヘルパーが示す理由を付けて Knowledge-Layer: state=needs_attention と答えます。 プロジェクトにレイヤーがあるかどうかは、人間が判断します。その回答を受けたら、AGENTS.md に Knowledge-Layer: enabled または Knowledge-Layer: disabled をそれぞれ独立した行として記載し、決して人間に代わって選択しないでください。disabled が有効なのは、終了コマンド、ペーパーカット文書、履歴記録が削除済みの場合に限ります。

プロジェクトに記載されたバックログのパスと終了コマンドを見つけ、それを宣言する行にリテラルの MO-BACKLOG/1 を含めます。このリテラルを使って、レイヤーヘルパーがコマンドを特定します。 使い捨てのフィクスチャで MO-BACKLOG/1 を検証します。コミット済み blob の同一性、空、空でない状態、型付きの不明状態、宣言されたパスの変更、無関係な変更、不正な UTF-8／スキーマ／モード、変更が行われないことを確認してください。プロジェクト契約では G0／GC／G1／G2 を必須とします。 通常の QC ではリーダー／スキーマをテストしますが、現在のブランチが空であることはアサートしないでください。

ナレッジ ID 履歴契約を読み、現在のツリーとの整合性と履歴を別々に確認します。現在のツリーは、同梱の scripts/mo-knowledge.mjs check をプロジェクト独自の宣言で実行して確認します。対象は、ビジネス文書、アーキテクチャディレクトリ、宣言されたすべての文書、ファーストパーティルート、厳密な除外項目です。その結果である MO-KNOWLEDGE/1 status=… が current_tree を示します。この移植可能な中核機能のために、プロジェクト独自のチェッカーは必要ありません。推測してはいけません。レベル 2 のセクションのうち、見出しに Knowledge id history を含み、フェンス付きの1行コマンドがちょうど1つ、正式な QC コマンドを示す行がちょうど1つ、history_cutoff_sha の記録がちょうど1つあるものから、宣言されたステージを取得します。Markdown AST で解析してください。これ以外の個数の場合は、history=unknown、cutoff=none とします。 同じ契約には、識別子の記載場所も明記する必要があります。つまり、ビジネス文書と、ステージが読み込むアーキテクチャディレクトリです。場所が未指定、曖昧、または矛盾している場合は、history=unknown cutoff=none とし、フィクスチャは一切書き込みません。場所を推測して作成したフィクスチャでは、誰も確認しない文書を検証したり、無作為に選んだクローンを編集したりすることになります。 ステージが機能することは、プロジェクト全体の QC ではなく、ステージ自体の動作で証明してください。また、使い捨てクローン内でのみ実施します。ネットワークを使わず、使い捨ての TMPDIR の下で git clone --no-hardlinks --no-local <path> <tmp> を実行してください。候補のワークツリーは書き込み用に開きません。プローブ全体の予算は 600 秒、ステージの 1 回の実行は 120 秒です。どちらかを超過した場合は、使い果たした予算を明記して unknown とし、gate_missing にはしません。ステージは宣言された QC コマンドに含まれている必要があります。コマンド内にそのまま記述されているか、同じ行でステージとして指定され、かつその行が指す追跡対象のランナー定義に記載されている必要があります。そうでなければ gate_missing です。正式なチェックの範囲外にあるステージは、誰も実行しないステージです。クリーンなクローンでのベースライン実行が失敗した場合は gate_failing とし、プローブを中止します。

次に、クローン内のみで、宣言された場所のみを変更し、そこに AST が実際に見つけた定義のみを対象として、2 つのフィクスチャを実行します。識別子の定義を 1 つ削除し、トレーラーなしでコミットします。ステージはゼロ以外で終了し、型付きマーカー（MO-KNOWLEDGE-HISTORY/1 status=violations またはプロジェクトで文書化されている同等のマーカー）を出力する必要があります。ゼロ終了またはマーカーなしの場合は gate_missing です。その後、クローンで git reset --hard と git clean -xdff を実行し、正しいトレーラーと一致する knowledge_id_change レコードを付けてリテラルを変更します。ステージは合格する必要があり、失敗した場合は gate_failing です。厳格さだけでは許容性の半分しか証明できず、許容性だけでは厳格さの半分しか証明できません。

finally でクローンを削除してください。そのパスはマシン固有のものであり、決して報告しません。

qc を JSON または none とし、ローカルパスを含めずに、レコードを 1 つ報告してください。

Knowledge-IDs/1 current_tree=<ok|violations|unknown> history=<gate_present|gate_missing|gate_failing|unknown> stale=<yes|no|unknown> qc=<json|none> cutoff=<sha|none>

バージョン文字列を信用せず、ハッシュを計算して stale を判定してください。文書化されたルールに従って同梱するバンドルのハッシュを計算し、コピーの最終行にある MO-KNOWLEDGE-HISTORY-SOURCE コメント内のハッシュと比較します。一致する場合は stale=no、異なる場合は stale=yes とし、両方の <semver> 値をレポートに記載します。行がない、重複している、または解析できない場合は stale=unknown です。ただし、供給元プロジェクト自体は例外です。そのプロジェクトの package.json には、このバンドルの供給元となったパッケージ名が記載されています。ここではステージがバンドルのビルド元となるソースを実行するため、記録は stale=no です。バージョンは人が差異を理解するためのものであり、判定には使いません。

コマンドとつまずきに関するドキュメントは、docs/papercut.md だけを探すのではなく、内容に基づいて見つけてください。Papercut/1 path=<json|none> linked=<yes|no> と報告します。linked は、AGENTS.md から実際にリンクされていることを意味します。レイヤーヘルパーは、パスが docs/papercut.md であるか、リンク先のファイル名に papercut が含まれている場合にそのドキュメントを認識します。ファイル名がそれ以外の場合は、マーカーを記述するのと同じ人間向けの回答で、AGENTS.md に Knowledge-Layer-Papercut: <path> という行を記載して宣言してください。そうしないと、ヘルパーは一部しか認識できません。受け入れ可能な修正は、コマンドとつまずきに関するテンプレートを基にしてください。 修復が承認された場合、同梱されている3つのバンドルと、それぞれの tools/licenses/をプロジェクトにコピーし、3つすべてをそのプロジェクトに属させます。 scripts/mo-knowledge.mjsはtools/mo-knowledge.mjsに配置し、QCステージでは そのプロジェクト独自の宣言を指定してcheckを呼び出します。scripts/mo-backlog.mjsは tools/mo-backlog.mjsに配置し、これを呼び出すクロージャコマンドでは、そのプロジェクト独自の --path、--title、--open-heading、タイトルからオープンセクションまでの各段落に対する 順番どおりの--intro、およびすべての --entry-fieldを指定する必要があります。タイトルと各段落は、Markdownのマークアップを含めず、 空白を折りたたんだ、レンダリング後のテキストとして指定します。スキーマ全体がなければ、チェッカーは別の ノートブックをこのプロジェクトのロシア語の文言に照らして検査することになり、スキーマが不完全なら呼び出しエラーになります。scripts/mo-knowledge-history.mjsは バージョン行とともにtools/mo-knowledge-history.mjsに配置します。これを呼び出すステージでは、 プロジェクト独自のQCとプロジェクト独自のカットオフを組み合わせ、AGENTS.mdには宣言セクションと、 動詞がremove|reuse|editorialのトレーラー文法を追加します。決して、このプロジェクトの境界やコミットIDをコピーしてはいけません。別のプロジェクトのカットオフを使うと、対象プロジェクトで検査が必要な履歴がまるごと免除されてしまいます。この修復で作成しないパスを指定するCIジョブは提案しないでください。

.orca/とspec/は、それぞれ個別にgit check-ignore -v --no-indexで確認します。追跡対象のリポジトリ無視ファイルによる一致であることを、git ls-files --error-unmatchで証明できた場合のみ許容します。これとは別に、git ls-files -- .orca/ spec/の結果が空であることを必須とします。無視ルールに一致しても、すでにインデックスに登録されているプライベートなワークスペースのバイト列が存在しない証明にはなりません。

絶対パスでOrcaバイナリを1つ特定します。orca skills list/get --jsonを使って、バンドル済みでバージョンが一致するorchestrationおよびorca-cliのガイドが空でないことを確認します。ガイドの複製をインストールしてはいけません。これとは別に、ネイティブなステータスとプロジェクトID、プロバイダー認証、アカウントの鮮度、選択したハーネスの起動、通常のプロンプトと信頼UI／シェルの違い、安定したタイトル機能、サンドボックスを使わない姿勢の所有者が1つであること、サポート対象のブロッキング待機時間を証明します。

Orca本体とorca-cliを、上流のorchestrationコンパニオンとは別に確認します。また、十分に成熟したjqとflockの依存関係も確認します。

ProjectRegistrationSet/1とOwnedResourceSet/1を読み取ります。同一プロジェクトの既存の隔離ルートがないフォルダー／プロジェクト未設定のワークスペースは、セットアップ不足です。レビューの回避策として一時パスを登録してはいけません。プロジェクト／リポジトリの登録や、個人設定の信頼／姿勢の変更には、別途人間の確認が必要です。ただし、この呼び出しでユーザーが指定したプロジェクトルートと、この実行自身のリソースについては、すでに確認済みです。

指定されたプロジェクトルートを実際に調査し、1行で報告します。

Harness-Trust/1 harness=claude path=<json> state=<trusted|accepted|needs_human|unknown> screen_version=<id>

acceptedを報告できるのは、次の3つの所有条件をすべて満たす場合だけです。ターミナルがこの実行によって作成され、OwnedResourceSet/1に記録されていること、ダイアログに表示されたパスのrealpathがそのターミナルのワークツリーのrealpathと一致すること、そのワークツリーが実行のリソースであるか、ユーザーが指定したルートであることです。ダイアログを確認することは、そのフォルダーにあるものすべてについて回答することになるため、条件が1つでも欠けている場合は、手順「タブ<title>を開き、Yes, I trust this folderを選択してください」を添えてneeds_humanとし、再試行してはいけません。

アクティブなホスティング／CI設定を読み取り専用で調査します。GitHub ActionsまたはGitLab CIの解析にはjs-yamlのみを使い、追跡対象のローカルインクルード／再利用可能なワークフローをリテラルにたどります。プロバイダー、リポジトリ、エントリーポイント、解決済みグラフ、ジョブ／ステップ、イベント、必須ポリシー、結果、未解決事項に加え、history=<full|shallow|unknown>と backlog_job=<yes|no|unknown>を含むCI-Coverage/1レコードを1つ返します。シャロークローンでは履歴ステージが警告なしにスキップされ、クロージャには通常のQCとは別のジョブが必要です。結果はcovered|config_present|no_ci_surface|unknownのいずれかです。動的／リモート構文や読み取り不能な設定がある場合、coveredにはできません。assets/ci/にある同梱例と比較し、提案するYAMLパッチを正確に提示します。ただし、別途依頼されない限り、追跡対象のCIやサーバー保護は変更してはいけません。 追跡対象の修復が承認された場合は、現在の develop をベースにした独立した feature/meta-o-setup ブランチを使用し、セットアップの修復を現在のフィーチャーブランチに決して混在させないでください。無関係な作業は保持してください。不足している各コントロール、コンパニオン、機能、認証情報、ポリシーをそれぞれ個別に報告し、人が実行する具体的な次の手順を1つずつ示してください。手順には、シークレットの値を含めず、正確なインストール、ログイン、信頼、または設定コマンドを記載してください。認証情報そのものを尋ねたり、収集したりしないでください。

Meta-O の呼び出し

• なし