gitnexus-work

gitnexus-work — gitnexus-plan を実行する

gitnexus-plan が生成した実装計画を実行し、検証済みのアトミックなコミットの連続として出荷します。計画のセクション 11（implementation_context パック）が主要な機械可読入力であり、散文のセクションはその根拠です。このスキルはコードを編集します — 計画専用の gitnexus-plan に対する実行者側のカウンターパートです。

/gitnexus-work <plan path>        # execute this plan
/gitnexus-work                    # newest docs/plans/*gitnexus-plan*.md here
/gitnexus-work <small task text>  # direct mode, see Input triage

入力のトリアージ

• 計画パス（または空白 → 現在のリポジトリルート配下の最新の docs/plans/*gitnexus-plan*.md）：通常モードです。フェーズ 1 に進みます。スキーマ 2 の計画には、正規化されたリポジトリ相対の docs/plans/YYYY-MM-DD-gitnexus-plan-<3-5-word-slug>.md という generated_plan_path があります。字句上の候補のみを解決し、次に scripts/evidence-provenance.mjs read-plan --repo <root> --generated-plan <candidate> を呼び出し、そのディスクリプタにアンカーされたレシート内の正確なバイトのみをロードします。レシートの正規のリポジトリ相対パスが、ドキュメントの generated_plan_path とバイト単位で一致することを要求し、外部の、脱出する、スコープの異なる、または不一致の値を拒否します。別のターゲットリポジトリ内の計画も、明示的なパスで渡すことができます。フェーズ 1 の事前完了チェックで、最新の計画の §7 のすべてのステップがすでに着地していることが判明した場合は、再実行せずに停止して尋ねます。
• 素のタスクテキスト：些細で範囲が限定されている（1〜2 ファイル、アーキテクチャ上の決定なし）→ 同じ規律で直接実装します。すべてのシンボル編集の前に impact、最小限の変更、動作が変わる場合はテスト、検証コマンドはリポジトリ自身のスクリプト（package.json / CI）から取得し、すべてのコミットの前に detect_changes、そしてグラフに依存する impact と最終検証の前に共有の Build-current/index-current 手順を実行します。それより大きいもの → 先に /gitnexus-plan を実行することを推奨します。ユーザーが拒否した場合はその選択を尊重します。

フェーズ 1 — 計画をロードして再アンカーする

1. 対象リポジトリと正規化されたプラン候補を特定し、references/evidence-provenance.md に正確に指定されているとおりに、このスキルの記述子に固定された scripts/evidence-provenance.mjs read-plan コマンドを呼び出します。存在しない、外部にある、エスケープしている、シンボリックリンクである、またはスコープが異なるパスは拒否します。レシートの正確な plan_bytes_base64 をデコードして完全に読み取ります。字句上のパスを直接読んだり再度開いたりしないでください。これはスクリプトではなく意思決定の成果物です。スコープの境界と avoid エントリはあなたを拘束しますが、正確なコードはあなたが書くものです。レシートの正規の generated_plan_path と plan_digest をセッション状態に保持します。プラン本文は決して編集しないでください。
2. §11 の implementation_context パックを解析します：acceptance_criteria、evidence_provenance、primary_symbols、related_symbols、files_to_modify、execution_path、pdg_constraints、architectural_patterns、tests、verification_commands、risks、assumptions、open_questions、avoid。コンパクトプランにはミニパックのサブセットが含まれます。存在しないオプションフィールドはエラーではなく空です。evidence_provenance は必須です。存在しない場合、またはスキーマ 1 の場合は、クリーンなツリーではなくレガシープランであることを意味します。これに依存する前に、read-plan レシートの正規の generated_plan_path と evidence_provenance.generated_plan_path がバイト単位で完全に一致することを要求します。
3. 2 層のドリフトチェック — 常に再計算します。 現在の HEAD がプランのピンと同じ HEAD である場合でも、正規のグローバルダーティダイジェストと、ソートされた引用パスマニフェストの両方を再計算します。references/evidence-provenance.md を読み、次にこのスキルの scripts/evidence-provenance.mjs を、プランの正確な generated_plan_path、引用されたすべてのマニフェストパス、およびスキーマバージョン 2 を指定して呼び出します。そのバイトをシェルや散文で再現しないでください。スキーマ 1 は曖昧さなく再計算できないため、保守的な再アンカーが必要です。オブジェクトの種類に加えて、HEAD/インデックス/ワークツリー/未追跡レイヤーのダイジェストを含め、staged、unstaged、untracked、deleted、renamed、mixed、absent の証拠を分類します。生成プランの除外を正確に尊重し、すべてのプランを除外しないでください。
4. どちらかの不一致で再アンカーします。 欠落またはレガシーの来歴、HEAD の不一致、またはグローバルダーティダイジェストの不一致は、作業前に保守的な再アンカーを必要とします：
   • 引用パスマニフェストのすべてのエントリを差分します。変更された引用パス — ステージ済みのみ、未ステージのみ、削除、両方のリネーム端点、ステージ済み+未ステージの混在、および消えた未追跡パスを含む — は、依存する前に引用範囲を再読み取りします。
   • 現在のツリー全体のダーティセットをピンされたグローバルダイジェストと比較します。新しく引用されていないダーティパスはスコープ評価を受けます：それらがプラン、要件、テスト、または重要な技術的決定と重複するかどうかを判断します。引用されていないという理由だけで黙って無視しないでください。
   • 読み取り不能または分類不能な引用証拠は、復元、読み取り、またはユーザーと解決できるまで、依存するすべてのステップをブロックします。でっち上げたダイジェストで代用したり、不在を空のファイルとして扱ったりしないでください。
   • 再アンカーの結果をセッション状態に保持し、プラン本文を決して変更しないでください。調整がスコープ、要件、重要な技術的決定（KTD）、または計画された実装の接合部を無効にする場合にのみ Deepen を使用します。それらの決定を有効なままにする通常のバイトドリフトは、ローカルで再検証されます。
5. assumptions を低コストで再検証します（それぞれが何を確認すべきかを示します）。失敗した仮定は、それに依存するステップに対する停止して再計画するシグナルであり、黙って回避してコーディングするものではありません。
6. open_questions に注意します — ある質問がステップをブロックし、その回答が作業を実質的に変える場合、そのステップの後にではなく前にユーザーに尋ねます。
7. 事前完了チェック。 このプランのコミットがブランチにすでに存在する場合（以前の部分的な実行、またはルートバック後の Deepen サイクル）、§7 のどのステップが HEAD に着地しているかを検証します：それらはスキップされ、事前完了として報告され、実行は最初の未着地ステップから再開されます。すべてのステップが着地している → それを報告して停止します。

フェーズ 2 — 環境

• デフォルトブランチの場合 → プランのスラッグから名前を付けたフィーチャーブランチを作成します。 すでにフィーチャーブランチの場合 → このプランにとって 意味がある場合にのみそのまま留まります（名前がプランのスラッグと一致する、またはユーザーが確認する）。それ以外の場合は、ここからスラッグ名でブランチを作成します。
• プラン文書がまだコミットされていない場合は、ここでコミットします (docs(plans): add <slug> plan) — プランはそれが推進する作業とともに移動し、最終レビューの差分にも含まれます。
• 開始前に、パックの verification_commands がこのチェックアウトで実際に実行できること（依存関係がインストール済み、ビルドが存在する）を確認します。最後のステップの後ではなく、開始前に確認してください。

Build-current/index-current プロシージャ

これは gitnexus-work が所有する唯一のグラフ鮮度プロシージャであり、プランモードとダイレクトモードの両方に適用されます。グラフに依存するすべての impact クエリの前に、Build-current/index-current プロシージャを実行します。最終的なグラフ検証の前にも、同じ Build-current/index-current プロシージャを再度実行します。

1. 現在の HEAD と作業ツリーの来歴を取得します。gitnexus://repo/<name>/context を読み、その型付き index.commit と index.runner_identity レシートを使用してください。アナライザーの同一性を散文、タイムスタンプ、またはパスだけから推測してはいけません。index.commit を現在の HEAD と比較します。最新のレシートには schemaVersion: 4、解決されたランタイムパス/バージョン、CLI バージョン、呼び出されたアーティファクトのパス/ダイジェスト、ビルド種別/ルート/正規化/ダイジェスト、および依存ランタイムのマニフェスト/ロックファイル/正規化/パッケージ数/アーティファクト数/ダイジェストが含まれます。その依存正規化は gitnexus-analyzer-dependency-runtime-v4 です。依存ランタイムのダイジェストは、解決されたパッケージメタデータと、JavaScript、JSON、ネイティブ、Wasm、パーサーアーティファクトを含む完全なロード可能パッケージペイロードを対象とします。schema-1、schema-2、schema-3 のレシートはレガシー/古いものです（MCP コンテキストはそれらに runner_identity_schema_status: legacy-or-unknown というラベルを付けます）。MCP の index.incomplete_reasons: [] を必須とします。候補となる正確な CLI の status --json コマンドを実行し、index.runnerIdentityStatus: current、index.incompleteReasons: []、およびトップレベルの status: up-to-date を必須とします。ステータス比較器はすべての意味的フィールドを検査しつつ、診断用の invokedArtifact のみを意図的に除外します。したがって、ワーカーが作成して永続化したレシートと CLI のライブレシートは、そのフィールドで異なっていても stale にはなりません。欠落、不正な形式、異なるバージョン、意味的に不一致、または不完全なレシートは、一致ではなく unknown/stale です。
2. リレーションシップに影響するコミット済みおよび未コミットの編集は、最後に成功したプロシージャ実行後にフレッシュネスを無効化します。これには、シンボルやエッジを変更しうる、ステージ済み、未ステージ、未追跡、削除済み、または名前変更されたアナライザー/ソース/設定の変更が含まれます。ステップ間でそのような編集が行われた場合、HEAD が移動していなくても、次のグラフクエリの前にステップ間リフレッシュが必要です。
3. アナライザーソースのチェックアウトで型付きランナーレシートが stale または unknown である場合、検証済みのパッケージスクリプトを使用して現在のローカルソースをビルドします。このリポジトリでは cd gitnexus && npm run build です。パッケージの bin ターゲットを解決し、その正確なアーティファクトの status --json コマンドを実行して、その現在のレシートを取得します。ソース/ビルドのタイムスタンプは、保守的な再ビルドのトリガーであり、アーティファクトが最新であることの証明ではありません。
4. ターゲットリポジトリのルートから、PDG レイヤーを有効にして、その正確に新しくビルドされたローカル CLI を呼び出します。このリポジトリでは node gitnexus/dist/cli/index.js analyze --index-only --pdg です。永続化されたレシートが存在しない、不正な形式、異なるバージョン、または不一致であった場合は --force を追加して、すでに up-to-date の高速パスによってレガシー/古い来歴が残らないようにします。通常のプロジェクトランナー形式である node .gitnexus/run.cjs analyze は、その証明されたランナーの同一性が同じ新しくビルドされたアーティファクトに解決される場合にのみ許容されます。ローカルアーティファクトを解決/ビルドした後は、古いプロジェクトランナー、グローバルインストール、またはパッケージダウンロードにフォールバックしないでください。
5. インデックスコンテキストを再読み込みし、正確に呼び出された CLI の status --json を再実行し、リフレッシュ後の index.commit が現在の HEAD と等しいこと、MCP の index.incomplete_reasons が空であること、およびその完全な index.runner_identity が status の index.runnerIdentity（永続化されたレシート）と等しいことを証明します。status の index.runnerIdentityStatus: current、空の index.incompleteReasons、およびトップレベルの status: up-to-date を必須とします。invokedArtifact は意味的フレッシュネスから意図的に除外された診断エントリポイントであるため、current.runnerIdentity との生の等価性は必須としません。このプロシージャでインデックスされたダーティ状態ダイジェストを記録し、同一 HEAD の未コミット編集が後でそれを無効化できるようにします。
6. ビルド、リフレッシュ、メタデータ読み取り、または同一性検証の失敗は、グラフに依存する影響作業と最終完了をブロックします。失敗したコマンドと証拠を報告してください。古いグラフで続行しないでください。

フェーズ 3 — 実装シーケンスの実行

計画の §7 を順番に、ステップごとに進めてください。各ステップでは次のとおりです。

1. 編集前に最新の影響を確認する。 グラフに依存するすべての impact {target, direction: "upstream"} クエリを実行する直前に、 Build-current/index-current の手順を実行します。その後、すべての 直接 (d=1) 依存を確認します。リスクが HIGH または CRITICAL の場合は、 続行する前にブラストラディウスとともにユーザーに提示します（リポジトリの 必須事項 — AGENTS.md の GitNexus ルールを参照）。
2. 制約を守る。 pdg_constraints のエントリは、その変更が維持しなければ ならない順序と依存関係の事実を示します。avoid のエントリは厳格な 禁止事項です。architectural_patterns は踏襲すべき形を示します （独自に考案する前に、その例の場所を読んでください）。
3. 最小限に実装する。 そのステップを完了する最小の変更を、周囲の コードの規約に従って行います。
4. 計画のシナリオからテストする。 各 tests[] シナリオ（入力 → アクション → 期待される結果）は、指定されたファイル内の実際のテストに なります。そのステップの動作が要求する場合は、計画が漏らした カバレッジを追加してください。ステップを通過させるためにアサーションを 削除したり弱めたりしてはいけません。新しい回帰テストが識別力を持つことを 証明してください。失敗モードが微妙な場合は、修正前のツリーに対して一度 実行して（修正の前にテストを書くか、修正をスタッシュする）、失敗するのを 確認してください — どちらでも通過するテストは何も固定しません。
5. 検証する。 そのステップに関連する verification_commands を実行します （それらはビルドの前提条件を伴います。書かれているとおりに使用して ください）。変更の一部がビルド出力から実行される場合 — ワーカーの エントリポイント、dist で配布される CLI、バンドルされたアセット — は、検証を実行するたびにその出力を再ビルドしてください。古いビルド出力に 対する成功や失敗はノイズであり、「修正が機能しない」は多くの場合 「修正がまったく読み込まれなかった」ことです。
6. アトミックにコミットする。 コミットする前に毎回 detect_changes {scope: "staged"} を実行し、期待されるシンボルとフロー だけが影響を受けていることを確認します（リポジトリの必須事項）。その後、 ステップごとに 1 つの Conventional Commit を作成します。リポジトリの ルートから stage → detect_changes → commit を一連の途切れない シーケンスとして実行してください — ゲートとコミットの間に他の作業を 挟むと、ゲートがスキップされてしまいます。予期しない 影響を受けたフローがある場合は、コミットした後ではなく、コミットする前に 調査してください。partial（グラフクエリが失敗した）または truncated （シンボルの一覧が上限に達した）とフラグが付いた結果も同様にコミットを ブロックします。ゲートがすべての変更されたシンボルを確認していないため、 クリーンと解釈するのではなく再実行してください。

関係に影響する実装の編集またはコミットは、その手順の以前の証明を 無効にします。次のステップは、その影響クエリの前に必要なステップ間の リフレッシュを実行しなければなりません。最終検証は、最後の編集の後に もう一度リフレッシュします。

ステップは独立して実行可能です。どのコミットの後でも、ツリーは一貫した 状態にあります。あるステップで計画が誤っていることが判明した場合は、その ステップを停止し、影響を受ける主張を HEAD で再検証し、適応するか（範囲内の 小さな逸脱 — コミットメッセージと最終サマリーに記録します）、 gitnexus-plan の Deepen モードに戻すか（構造的な見落とし）してください — 判断が明らかでない場合は、ユーザーへの一行の確認を添えてください。

フェーズ 4 — 完了

1. 最後に verification_commands スイート全体を一度実行します。たとえ 各ステップが個別にすでに成功していても実施してください。
2. 計画の §13(完了の定義)とパックの acceptance_criteria を 項目ごとに確認します。満たされていないものは、今すぐ完了させるか、 明示的に未達として報告するかのいずれかです — 決して黙って 落とさないでください。
3. 最終的なナレッジグラフを検証します。 最終グラフ検証の前に、最後の 編集後に同じ Build-current/index-current 手順を実行します。たとえ コミットが行われなかったり、HEAD が元のピンのままであっても実施してください。次に、 その証明済みの最新インデックスに対して detect_changes {scope: "all"}(またはリポジトリにおける同等の最終グラフ チェック)を実行し、予期しないすべてのシンボルやフローを 説明してください。手順の失敗は完了をブロックします。
4. 報告: 完了したステップ、作成したコミット、計画からの逸脱(その 理由を含む)、再検証に失敗した前提、DoD のステータス、最終的に インデックスされたコミットとランナーの識別情報、および延期された 事項。テストの失敗は、その出力とともに報告し、滑らかに 覆い隠さないでください。

禁止事項

• フェーズ 3 のゲートをスキップすること: impact なしのシンボル編集、 detect_changes なしのコミットは禁止です。
• 計画を超えてスコープを拡大すること — §12 の延期された フォローアップは延期されたままにします。
• 計画本体を改変すること(フェーズ 2 でファイルをそのままコミットすることは 改変ではありません)、失敗するテストを弱めること、または検証されていない作業を 検証済みとして提示すること。

スキルフィードバック(GitNexus リポジトリのみ)

この実行でこのスキル自体の指示に摩擦が生じた場合 — 誤った、または 欠けているガイダンス、無駄になったツール予算、誤ったルーティングが行われた フェーズ — かつリポジトリに eval/workflow_bench/ が存在するなら、 eval/workflow_bench/learnings.jsonl に JSON 行を 1 行追加します(ファイルが 存在しない場合は作成します): {"skill": "gitnexus-work", "date": "YYYY-MM-DD", "task": "<one line>", "friction": "<one line>", "suggestion": "<one line>"}。 ライブタスクからこのスキルファイル自体を決して編集しないでください。改善は オフラインの候補ループ(eval/workflow_bench/README.md § Prompt and skill evolution loop)を通じて行い、そこでは候補が ペアベンチマークで現行版を上回ってから、人間がマージします。