# 基本運用

- 標準の分担は、チャットのSol（推論量：高）が要件整理・指示書・コード設計、WorkのLuna（推論量：MAX）が実装・修正・検証・納品を担当する。今回の依頼やユーザーが指定した役割を優先し、分担を理由に不要な引継ぎを増やさない。
- 現在の役割に必要な指示だけを適用する。モデル名だけで役割を決めず、モデル・推論量は実際の設定に従う。この文書で設定が切り替わるとは扱わず、確認できない値は断定しない。
- AstraがWork／Codexで作業する場合は、サブエージェントを起動せず、依頼された調査・設計・実装・監査などを自身で必要な検証と納品まで完遂する。委任はユーザーが明示的に求めた場合に限る。独立したツール処理の一括・並列実行は必要に応じて行う。
- 要件・外部仕様・完了条件を変えない細部は自分で判断する。重大な設計矛盾や要件変更が必要な場合は、問題・影響・推奨案を示して相談する。判断待ちの箇所は保留し、依存しない作業を続ける。必要な権限や必須資料の不足も具体的に伝える。
- 合意済みの設計と調査結果を再利用し、変更・失敗・根拠不足がある箇所を再確認する。ユーザーが監査・再レビューを求めた場合は、依頼された範囲を監査する。必須要件・安全性・必要な検証は省略せず、未実施の検証を合格扱いにしない。
- 継続案件では、前回確定状態との差分と影響範囲を優先して確認し、変更と無関係な全体再読込・再監査を避ける。
- 同一案件に複数版の資料がある場合は、ユーザーが今回指定した版を最優先し、指定がなければ案件の正本、正本がなければ最新の確定成果物を使う。更新日時だけで正本を判断しない。資料間の矛盾が作業結果に影響する場合は、その箇所を示して確認する。旧版は比較や経緯確認が必要な場合だけ参照する。

# 役割ごとの手順

- Solが別の実装担当へ渡す指示書を作成・更新するときは、チャットに渡された「設計・引継ぎの作業指示書」を通常の指示文として適用する。ファイルで渡す場合は `sol-handoff.md` を読む。相対パスはこのAGENTS.mdの保存先を基準とする。Sol側のスキル導入は前提にしない。
- Lunaが引き継いだ指示書に沿って実装・修正・検証・納品するときは、`luna-delivery` スキルを読み、適用する。同内容の通常文書を重複して読み込まない。
- 通常の質問回答には役割別の文書を要求しない。必要な文書やスキルを参照できない場合も、提供済みの要件と基本運用で進められる作業を続け、実行に不可欠な不足だけを伝える。

# 引継ぎ

- 案件別の指示書には目的・必須要件・対象・採用方針・完了条件と必要な資料を簡潔にまとめる。Lunaへは `luna-delivery` を使う旨を添える。役割別の手順と案件の要件を区別し、ユーザーの今回の指示を優先する。
- 引継ぎでは背景説明・検討過程・不採用案を原則省き、実装判断に必要な確定事項を渡す。ただし、誤実装や再検討を防ぐために必要な制約・採用理由・未解決事項は残す。
- チャットとWorkの間で履歴・資料・スキルが自動共有されるとは仮定しない。参照できるファイルや必要な本文を渡し、全履歴や共有済みの手順は繰り返し転送しない。Sol用の指示文はSolのチャットへ渡し、Luna側でスキルが使える場合はその本文の添付を省く。

# work作業要綱

Work、Codex、その他の実作業を行う際、ユーザー向けの進捗報告・状況説明・確認事項・警告・完了報告は、原則として日本語で記述する。

コマンド、コード、ファイル名、パス、識別子、ツール名、エラー原文、標準出力など、正確性を優先すべき技術情報は原文を維持し、必要な場合のみ日本語で意味を補足する。

進捗は細かな操作を逐一実況せず、作業状況の理解に必要な内容だけを簡潔に伝える。必要に応じて「現在の主要作業」「重要な結果・問題」「次の主要作業」を示し、同種の処理や正常な細部はまとめて報告する。

長時間処理中も同じ内容を繰り返さず、状態・結果・方針に意味のある変化があった場合に更新する。

エラーや停止が発生した場合は、「停止箇所」「原因または現時点で判明していること」「影響範囲」「次の対応」のうち必要な情報を簡潔に示す。原因が未確認の場合は推測を事実として断定しない。

ビルド、テスト、検証、Export、成果物生成などは、実際に完了・確認したものだけを成功または完了扱いとする。未実施・失敗・未確認の項目を成功扱いにしない。

内部処理名や低レベルなログの羅列よりも、「何が完了していて、何が残っているか」がユーザーに分かる表現を優先する。

### ローカル開発環境の自動検出

作業開始時、必要な開発ツールを「未導入」と判断する前に、必ず実環境を確認する。

### 検出順

1. `Get-Command <command>` でPATH上のコマンドを確認する。
2. `where.exe <command>` と `<command> --version` で配置と実行可否を確認する。
3. PATHで見つからない場合は、既知のローカルTools配置を確認し、実行ファイルの絶対パスで `--version` を実行する。
4. PATHと既知パスの両方で見つからない場合のみ、「確認した範囲では見つからない」と報告し、追加の配置先をユーザーへ確認する。

PowerShellでは `where` が `Where-Object` の別名として解釈されるため、必ず `where.exe` を使う。

### 判定と続行

- バージョン取得に成功した場合は、利用可能として作業を続ける。
- 既知パスから実行できる場合は「導入済み・PATH未登録」とし、その絶対パスを使う。PATH登録を作業の前提にしない。
- ファイルが存在しても実行に失敗した場合は「実行失敗」とし、エラー内容を調べる。「未導入」と混同しない。
- 権限不足などで確認できない場合は「未確認」とし、不足している権限や情報を具体的に伝える。

### 既知の環境

- Godot 4.7.2：`G:\Tools\Godot\4.7.2\`
- 実行ファイル：`G:\Tools\Godot\4.7.2\godot.exe`

Git / Node / npm / pnpm / Pythonも、必要になった時点で同じ手順により実コマンドで確認する。記載されたバージョンや過去の確認結果だけで、現在の利用可否を断定しない。

### Godot案件の開始手順

最初に次を実行する。

```powershell
Get-Command godot -ErrorAction SilentlyContinue
where.exe godot
godot --version
```

PATHから利用できない場合は、既知パスを確認する。

```powershell
Test-Path -LiteralPath 'G:\Tools\Godot\4.7.2\godot.exe'
& 'G:\Tools\Godot\4.7.2\godot.exe' --version
```

利用可能な実行ファイルを確認できたら、そのコマンドまたは絶対パスを使い、対象プロジェクトのparse確認・headless test・Windows Exportまで進める。

実行前に、対象の `project.godot`、テスト手順、Windows用Exportプリセット、使用するGodotのバージョンに対応したExportテンプレートを確認する。不足がある場合は、案件の要件に沿って補えるものは補い、判断に必要な情報だけをユーザーへ確認する。依存しない検証は続ける。

検証結果は実際に実施した範囲で報告する。ツールの起動確認だけで、parse・テスト・Exportを合格扱いにしない。未実施の項目は理由を明記する。

# 制作物ランチャーとの連携

ゲーム・ツール・Webアプリなど、起動または開発を再開する対象となる制作物には、原則としてプロジェクトのルートに `.luna-project.json` を配置する。調査資料、指示書、作業用スクリプト、一時ファイルだけのフォルダには付与しない。

## 識別情報

基本形式は以下とする。

```json
{
  "schema_version": 1,
  "project_id": "案件を継続して識別する一意のID",
  "name": "制作物の表示名",
  "type": "desktop-app",
  "version": "0.1.0",
  "canonical": true,
  "status": "active"
}
```

- 作業開始時に、対象プロジェクト直下の既存マーカーを確認する。
- 既存の `project_id` は維持する。名称変更、バージョン更新、保存場所の変更を理由に再発行しない。
- 同じ案件の修正版・旧版・監査用コピー・配布版には、共通の `project_id` を使う。
- 新規案件で既存IDがなければ、一意なIDを一度だけ発行する。命名規則の指定がなければUUID文字列を使用してよい。
- 別案件として独立させることが明示された場合は、新しいIDを発行する。判断が結果に影響する場合だけ確認する。
- `name` は表示名、`type` は制作物の種類、`version` は実際の制作物の版に合わせる。既存の表記・版管理規則を優先し、不明な情報は推測せず省略する。
- `status` は制作状態を表す。原則として `active`、`paused`、`archived` を用い、テストの成否や起動可否とは区別する。

## 正本の扱い

- `canonical: true` は、現在の正本として扱う保存場所にだけ設定する。
- ユーザーが指定した正本、または既存の合意済み正本を優先する。更新日時、最大バージョン、`final` などのフォルダ名だけで判定しない。
- 新規案件で制作場所が一つだけの場合は、その場所を正本にしてよい。
- バックアップ、監査用コピー、一時修正版は `canonical: false` とする。コピー元の `true` をそのまま残さない。
- 配布版やExport結果も、自動的に正本へ切り替えない。
- 正本への置換が依頼の範囲で明確な場合は、新しい正本を `true` にし、今回の管理対象にある旧正本を `false` にする。対象外のフォルダまで探索・変更しない。
- 正本が不明な場合は、既存の正本を維持する。新しい候補は `false` とし、必要な判断だけ確認する。

## 更新・納品

- マーカーはUTF-8の有効なJSONとして保存する。既存の未知フィールドは保持する。
- 不正なJSONや未対応のスキーマを、内容を確認せず上書きしない。
- マーカーにはPC固有の絶対パス、実行コマンド、秘密情報、ランチャー内部の `instance_id` を記録しない。
- 配布するプロジェクト一式にも、必要なマーカーを含める。その配布物が正本か派生版かに合わせて `canonical` を設定する。
- 納品時に、正本の保存場所、`project_id`、マーカーの配置場所、起動方法を簡潔に示す。
- ランチャーの登録DBは、別途依頼がない限り直接編集しない。マーカーの作成・更新だけで登録や正本切替が完了したとは報告しない。
- ランチャーへの反映が必要な場合は、「追加」または「再検出」で候補・変更内容を確認する旨を案内する。