.agents

Imported from yasudajs/NoCapEdit (.agents/AGENTS.md). Install upstream with npx skills add yasudajs/NoCapEdit --skill .agents. Copyright stays with the author.

プロジェクト固有ルール

機能の実装作業の手順

• 実装作業の各ステップは、必ずユーザーの指示を受けてから行うこと。（計画完了後に自己判断でコード変更などの実装ステップへ自動で進んではならない）

• [フェーズ1: 実装計画の作成]

  • 機能追加の際には、ユーザーとAIはソースコードやリポジトリの修正等はおこなわず、修正内容についてディスカッションする。
  • 修正内容の合意ができたら、AIはまず「実装計画書（implementation_plan.md）」のみを作成してユーザーに提示する。（この時点では、作業用ブランチの作成やソースコード、バージョン番号、spec.mdなどの変更・リポジトリ操作は一切行ってはならない）
  • 作業に関わるドキュメント（実装計画書implementation_plan.md、および task.md walkthrough.md などの作業用ドキュメントについても）は、docs/ 配下に実ファイルとして逐次保存すること。

• [フェーズ2: 実装作業の開始]

  • ユーザーが実装計画書を承認し、「作業開始」の明示的な指示を出した後に、AIは初めて以下の作業を開始する。
    1. master ブランチから作業用ブランチを作成する。
    2. フェーズ1で作成したドキュメント（実装計画書など）を docs/wip/ から docs/[機能名]/ へ移動し、コミットおよびプッシュする。
    3. バージョン番号の更新:
       • バージョン管理ファイル（Cargo.toml 等の4ファイル）のバージョン番号を次の内部バージョン（0.2.x）に更新する。
    4. spec.md を最新版に更新する。
    5. 実装計画書に基づいて実装を行い、動作確認等の検証を行う。

• ユーザーが実装計画書を承認し、作業を開始した後は、AIは実装の進捗に応じて、作業用ドキュメントやソースコードのコミットおよびプッシュを自己判断でこまめに実施して良い。その際、task.md の該当タスク項目も完了するごとに随時チェック（- [x]）を更新すること。

• 実装および検証の完了後、ユーザーに確認を求める前に、今回の作業結果報告として docs/[機能名]/walkthrough.md（ウォークスルー）を必ず作成し、docs/history.md に今回のバージョンの変更履歴を最上部に追記して、実装したソースコードおよびドキュメントの更新を含めてコミット＆プッシュする。

• ユーザーが実装内容、ウォークスルー（walkthrough.md）、および変更履歴（docs/history.md）を承認したら、実装完了とし、クリーンアップ・マージ指示を待つ。

• 実装作業完了後のクリーンアップ・マージルール: ユーザーからクリーンアップまたはマージの指示を受けたら、以下の通り追加の確認指示を挟まずに一気に実施する（このフェーズは不要になったドキュメントやブランチの「削除・整理」のみを行う）。 ※重要: クリーンアップ作業に入る前に、必ず git status 等で未コミットの変更（Cargo.lock の自動更新など）がないか確認し、存在する場合は先にコミット・プッシュを実施して作業ブランチをクリーンな状態にしてから以下の手順へ進むこと。

  1. docs/history.md に今回のバージョンの変更履歴が正しく追記されているか最終確認する。
  2. 作業関連のドキュメントフォルダ（docs/[機能名]/）を完全に削除してコミット＆プッシュする。
  3. master ブランチに切り替え、作業ブランチを非Fast-forwardマージ（--no-ff）してプッシュする。
  4. マージ完了後、ローカルおよびリモートの作業ブランチを削除する。

• 本番リリース（0.2.20など）であれば、ユーザーが配布用のアーカイブファイルのビルドとGitHub CLIでのログイン（gh auth login）を完了したことを受けて、AIはGitHub Releaseへの登録およびREADME.mdの更新を行う。

Gitの運用方針

• コミットおよびプッシュのルール:
  • 実装作業中のコミットおよびプッシュは、AIの自己判断でこまめに実施して良い（進捗の確実な保存や、問題発生時のロールバックを容易にするため）。ただし、ビルドが通らない状態や不要な一時ファイルをコミットしないよう注意し、コミットメッセージは適切に記述すること。
  • コミットメッセージは日本語で記述する。
  • 1行目を20文字程度で作業内容の概要を記述し、その下に箇条書きで詳細を記述する。
• マージのルール:
  • 作業ブランチをマージする際は、ブランチでの開発履歴（分岐と合流）を視覚的に残すため、常に git merge --no-ff <ブランチ名> を使用して非Fast-forwardマージを行うこと。

ドキュメントの運用方針

開発ドキュメント（実装計画書、タスク、ウォークスルー等）のライフサイクルは以下の通りとします。

• 作業ドキュメントの実ファイル化とコミット:
  • AIが生成する実装計画書 (implementation_plan.md)、タスクリスト (task.md)、ウォークスルー (walkthrough.md) は、一時的なアーティファクトで済まさず、必ず docs/ 配下の適切なフォルダに実ファイルとして保存し、コミット対象としてください。
  • タスクリスト（task.md）の随時更新:
    • 作業中のリアルタイムな進捗を可視化するため、作業ステップ（ブランチ作成、バージョン更新、spec更新、各コード修正、検証、ドキュメント作成など）が完了するごとに、該当する項目のチェックボックス（- [ ] → - [x]）を随時チェック（更新・保存）すること。全作業完了後に一括でチェックを入れてはならない。

1. 検討中・作業着手前 (WIP):
   • docs/wip/[機能名]/ 配下にドキュメントを配置して検討を行います。このフォルダはクリーンアップ対象外です。
   • 例外 (master_plan.md): プロジェクト全体を通して継続してメンテナンスする全体計画書（master_plan.md など）は、実装開始後も docs/wip/ 配下に配置し続け、クリーンアップによる削除対象から外してください。
2. 実装開始時 (本番格上げ):
   • 実装が正式に開始されたら、対象のフォルダを docs/wip/ から docs/[機能名]/ に移動します（この時点で WIP からは削除されます）。
3. 実装完了時 (クリーンアップ):
   • 開発が終了し、ソースコードとドキュメントがGitにコミット＆プッシュされた後は、その機能の個別ドキュメントフォルダ（docs/[機能名]/）を完全に削除します。
   • 過去の履歴はGitのコミット履歴で管理するため、リポジトリ内に古いフォルダやファイルを残さないでください。

• 最新版のみの維持:
  • 常に現在進行中の作業、または全体の共通設計に関する最新のドキュメントのみを残すようにしてください。
  • 実装作業の開始指示を受けた後、コードの実装に入る前に spec.md を最新版に更新すること。

リリース運用方針

• 内部バージョン:
  • 変更ごとに 0.2.x を1ずつインクリメント（小変更は統合可）
• 本番リリース: 原則5ステップごと（0.2.20, 0.2.25...）または大きな機能追加・修正時にGitHub Releaseを作成
• 緊急修正: 必要に応じて例外的に即リリース可
• GitHub Release: 本番リリース時のみ作成（内部バージョンではReleaseを作成しない）

バージョン番号の管理ファイル

バージョンアップ時は、以下の4ファイルを必ずセットで更新すること。更新漏れはビルド成果物のバージョン不一致の原因になる。

以下は参照・記録用のため、バージョンアップ時の自動更新対象外（内容に応じて手動追記）:

• docs/history.md — 変更履歴の追記
• README.md — 本番リリース時のダウンロードリンク更新

コーディング規約（将来の多言語化対応）

• 今後の機能追加や改修において、フロントエンド（JS）側で新しくUIに表示する日本語テキスト（エラーメッセージやダイアログの確認文など）を追加する場合は、コード内に直接ハードコードしないこと。
• 代わりに src/frontend/i18n.js にテキストを定義し、t('キー名') のような翻訳関数を経由して呼び出す設計にすること。