Copilot¶

GEMINI.md - 恵菜ファーム統合システム開発ルール¶

🎯 基本原則¶

このプロジェクトは「非終焉システム」です。完成ではなく、常に成長し続けるシステムを目指します。

言語とコミュニケーション¶

• すべて日本語：思考、応答、ドキュメント、コメント
• 矛盾時は報告：ルール間で矛盾が生じたら、作業を止めて報告する

---

📋 2つのフェーズ¶

相談フェーズ（Planning）¶

目的: 何をどう進めるか話し合う

やること:

• 作業方針の議論
• チケットの起票提案
• チケット管理.md への記録

やらないこと:

• ファイルの変更（ドキュメント以外）
• コードの実装

成果物: Redmineチケット（ユーザーが発行）

---

作業フェーズ（Execution）¶

目的: チケット単位で具体的な実装を進める

開始条件:

• ユーザーから「作業フェーズに移行」の明示的な指示
• チケット内容の最終承認

作業手順:

1. 作業開始時: 現在行っている作業について.md に作業内容を記録
2. 作業中: 進捗を同ファイルに随時記録
3. ツール使用前: 以下を説明し、承認を得る
   • 目的
   • 対象（ファイル/ディレクトリ）
   • 変更内容
   • 理由（必要に応じて）
4. 作業完了時: コミットメッセージを提案

禁止事項:

• 計画外のファイル変更
• ユーザー承認なしのツール実行
• 直接のコミット実行（提案のみ）

---

💾 コミット管理¶

コミットタイミング¶

• 子チケット（サブタスク）完了時
• 親チケット完了時

コミット手順¶

1. git status で変更確認
2. コミットメッセージ案を作成し提示
3. ユーザー承認後、実行（ユーザーが行う）
4. チケット番号を必ず含める（例: refs #60）

---

📁 ファイル変更の原則¶

絶対ルール¶

1. 計画の範囲内のみ変更する
2. ユーザー承認なしのファイル変更は禁止
3. 一時ファイルの削除も事前報告

変更が必要になったら¶

1. 作業を止める
2. ユーザーに変更の必要性を説明
3. 承認を得てから実行

---

🗂️ プロジェクト構造の理解¶

ドキュメント階層¶

docs/
├── requirements/    # 要件定義
├── design/         # 設計（DB等）
└── roadmap/        # フェーズ定義

ソースコード階層¶

src/
├── core/           # 共有マスタ
├── sales/          # 販売ドメイン
│   └── riceshop/   # お米販売システム
└── cultivation/    # 栽培管理（将来）

管理ファイル¶

.gemini/
├── GEMINI.md                      # このファイル（ルール）
├── プロジェクトコンテキスト.md      # 現在の状態
├── チケット管理.md                 # チケット一覧
└── 現在行っている作業について.md    # 作業ログ

---

🎓 重要な参照ドキュメント¶

作業前に必ず確認すべきドキュメント：

1. プロジェクト全体像: docs/aboutMe/AboutThisSystem.txt
2. 長期ロードマップ: docs/roadmap/00_フェーズ0：開発基盤の定義.md
3. 現在のコンテキスト: .gemini/プロジェクトコンテキスト.md
4. 作業中の記録: .gemini/現在行っている作業について.md

---

⚠️ 回復手順（Geminiが落ちた場合）¶

1. .gemini/現在行っている作業について.md を読む
2. チケット管理.md で現在のチケットを確認
3. ユーザーに状況を確認
4. 作業を継続

---

🔒 守るべき最優先事項¶

1. ユーザーの承認なしに、いかなるファイルも変更しない
2. 計画外の作業は提案するが、勝手に実行しない
3. 矛盾やエラーが発生したら、すぐに報告する
4. 作業記録を怠らない（現在行っている作業について.md）

---

📝 記録の重要性¶

Geminiは前の会話を覚えていません。だからこそ：

• 作業開始時: これから何をするか記録
• 作業中: 何を変更したか記録
• 問題発生時: 何が起きたか記録

この記録が、次のGeminiインスタンスを救います。

---

gemini.md

GEMINI.md - 恵菜ファーム統合システム開発ルール¶

🎯 基本原則¶

このプロジェクトは「非終焉システム」です。完成ではなく、常に成長し続けるシステムを目指します。

言語とコミュニケーション¶

• すべて日本語：思考、応答、ドキュメント、コメント
• 矛盾時は報告：ルール間で矛盾が生じたら、作業を止めて報告する

---

📋 2つのフェーズ¶

相談フェーズ（Planning）¶

目的: 何をどう進めるか話し合う

やること:

• 作業方針の議論
• チケットの起票提案
• チケット管理.md への記録

やらないこと:

• ファイルの変更（ドキュメント以外）
• コードの実装

成果物: Redmineチケット（ユーザーが発行）

---

作業フェーズ（Execution）¶

目的: チケット単位で具体的な実装を進める

開始条件:

• ユーザーから「作業フェーズに移行」の明示的な指示
• チケット内容の最終承認

作業手順:

1. 作業開始時: 現在行っている作業について.md に作業内容を記録
2. 作業中: 進捗を同ファイルに随時記録
3. ツール使用前: 以下を説明し、承認を得る
   • 目的
   • 対象（ファイル/ディレクトリ）
   • 変更内容
   • 理由（必要に応じて）
4. 作業完了時: コミットメッセージを提案

禁止事項:

• 計画外のファイル変更
• ユーザー承認なしのツール実行
• 直接のコミット実行（提案のみ）

---

💾 コミット管理¶

コミットタイミング¶

• 子チケット（サブタスク）完了時
• 親チケット完了時

コミット手順¶

1. git status で変更確認
2. コミットメッセージ案を作成し提示
3. ユーザー承認後、実行（ユーザーが行う）
4. チケット番号を必ず含める（例: refs #60）

---

📁 ファイル変更の原則¶

絶対ルール¶

1. 計画の範囲内のみ変更する
2. ユーザー承認なしのファイル変更は禁止
3. 一時ファイルの削除も事前報告

変更が必要になったら¶

1. 作業を止める
2. ユーザーに変更の必要性を説明
3. 承認を得てから実行

---

🗂️ プロジェクト構造の理解¶

ドキュメント階層¶

docs/
├── requirements/    # 要件定義
├── design/         # 設計（DB等）
└── roadmap/        # フェーズ定義

ソースコード階層¶

src/
├── core/           # 共有マスタ
├── sales/          # 販売ドメイン
│   └── riceshop/   # お米販売システム
└── cultivation/    # 栽培管理（将来）

管理ファイル¶

.gemini/
├── GEMINI.md                      # このファイル（ルール）
├── プロジェクトコンテキスト.md      # 現在の状態
├── チケット管理.md                 # チケット一覧
└── 現在行っている作業について.md    # 作業ログ

---

🎓 重要な参照ドキュメント¶

作業前に必ず確認すべきドキュメント：

1. プロジェクト全体像: docs/aboutMe/AboutThisSystem.txt
2. 長期ロードマップ: docs/roadmap/00_フェーズ0：開発基盤の定義.md
3. 現在のコンテキスト: .gemini/プロジェクトコンテキスト.md
4. 作業中の記録: .gemini/現在行っている作業について.md

---

⚠️ 回復手順（Geminiが落ちた場合）¶

1. .gemini/現在行っている作業について.md を読む
2. チケット管理.md で現在のチケットを確認
3. ユーザーに状況を確認
4. 作業を継続

---

🔒 守るべき最優先事項¶

1. ユーザーの承認なしに、いかなるファイルも変更しない
2. 計画外の作業は提案するが、勝手に実行しない
3. 矛盾やエラーが発生したら、すぐに報告する
4. 作業記録を怠らない（現在行っている作業について.md）

---

📝 記録の重要性¶

Geminiは前の会話を覚えていません。だからこそ：

• 作業開始時: これから何をするか記録
• 作業中: 何を変更したか記録
• 問題発生時: 何が起きたか記録

この記録が、次のGeminiインスタンスを救います。¶

プロジェクトコンテキスト¶

最終更新: 2025-01-01
現在のフェーズ: ステージ2（技術実証・プロトタイプ検証）

---

📌 システム概要¶

恵菜ファーム統合システム は、農業経営を支援する成長し続けるシステムです。

目的¶

• 栽培管理: 圃場管理、作付計画、作業記録
• 販売管理: お米販売システムの統合と拡張
• 統合基盤: 両者を繋ぐ共通マスタデータ

特徴¶

• 非終焉システム: 完成ではなく、常に機能追加・改善を続ける
• 階層化設計: ドメイン毎に明確に分離（スパゲッティ化防止）
• AIとの協働: Gemini/RAGを活用した開発体制

---

🛠️ 技術スタック¶

開発環境¶

• OS: Windows 11
• エディタ: VSCode 1.107.1
• コンテナ: Docker 29.1.2 + Docker Compose
• バージョン管理: Git 2.52.0

運用環境¶

• サーバー: XserverVPS (Ubuntu 24.04)
• リバースプロキシ: Traefik 2.10.7
• リポジトリ: Gitea 1.22.5 (https://gitea.keinafarm.net)
• プロジェクト管理: Redmine (https://redmine.keinafarm.net)
• ドキュメント: Trilium Notes 0.63.7

アプリケーション¶

• フレームワーク: Django (Python 3.12.9)
• データベース: PostgreSQL + PostGIS（本番）/ MySQL（旧riceshop）
• サブドメイン:
  • keina.keinafarm.net - 統合システム本体
  • riceshop.keinafarm.net - お米販売システム
  • farm.keinafarm.net - 営農支援（将来）

---

📊 現在の進捗状況¶

ステージ1: ドキュメント・管理環境の構築 ✅¶

• #40 riceshopドキュメントの解体・再配置
• #41 REGシステム（Trilium同期ツール）開発
• #43 AIマージツール開発
• #44 AIドキュメント生成ツール開発
• #47 プロジェクト構造解析ツール開発

ステージ2: 技術実証（現在のフェーズ） 🔄¶

• #60 PostgreSQL (PostGIS) 動作検証
• #61 階層化アプリ構造でのMigration整合性確認

ステージ3: お米販売システムの移行と統合 ⏳¶

• #62 riceshopデータ構造のPostgreSQL再現
• #63 MySQLからPostgreSQLへのデータ移行
• #64 GUI検証（管理者機能：顧客管理）
• 以降、在庫/商品/注文/発送/入金管理のGUI検証

---

🎫 現在のチケット¶

優先度: 高¶

チケット	タイトル	状態
#60	Docker環境でのPostgreSQL (PostGIS) 動作検証	未着手
#61	階層化アプリ構造でのDjango Migration整合性確認	未着手

優先度: 中¶

チケット	タイトル	状態
#62	riceshopのデータ構造をPostgreSQL上に再現	未着手
#63	riceshopのMySQLデータからPostgreSQLへのデータ移行	未着手
#64	お米販売システムのGUI検証（管理者機能：顧客管理）	未着手

詳細: .gemini/チケット管理.md を参照

---

🔄 現在の作業状況¶

作業ファイル: .gemini/現在行っている作業について.md

前回の課題¶

1. データのみ移行してもGUI検証ができない
2. フィールド名変更により、テンプレート改造が複雑化

新しい方針¶

1. まず PostgreSQL (PostGIS) の動作を確認（プロトタイプ検証）
2. 階層化構造での Django Migration を確認
3. riceshop のモデルを使って PostgreSQL 上にデータ構造を再現
   • テーブル名を明示的に指定（モデル移動時のDB変更を回避）
4. MySQL → PostgreSQL データ移行
5. GUI機能を段階的に検証

---

📚 重要なドキュメント¶

プロジェクト理解¶

• システム全体像: docs/aboutMe/AboutThisSystem.txt
• 開発方針: docs/roadmap/00_フェーズ0：開発基盤の定義.md

開発ルール¶

• 作業ルール: .gemini/GEMINI.md（このコンテキストと併せて必読）

作業管理¶

• チケット一覧: .gemini/チケット管理.md
• 作業ログ: .gemini/現在行っている作業について.md

既存システム参照¶

• riceshop原本: reference/riceshop/（直接編集禁止）
• riceshopドキュメント: docs/riceshop/

---

🎯 次のステップ¶

直近の目標¶

1. #60: Docker Compose で PostgreSQL + PostGIS が動くことを確認
2. #61: 階層化された Django アプリで Migration が正しく動作することを確認

この後の流れ¶

3. riceshop のコードを src/sales/riceshop に配置
4. PostgreSQL 上にテーブル構造を構築
5. 既存データを移行
6. 管理画面から順次、GUI動作を検証

---

⚙️ ディレクトリ構造（簡易版）¶

keinasystem02/
├── .gemini/                          # 管理ファイル
│   ├── GEMINI.md                     # ルール（このファイルと併読）
│   ├── プロジェクトコンテキスト.md     # このファイル
│   ├── チケット管理.md                # チケット一覧
│   └── 現在行っている作業について.md   # 作業ログ
├── docs/                             # 仕様書原本
│   ├── aboutMe/                      # プロジェクト説明
│   ├── roadmap/                      # フェーズ定義
│   ├── requirements/                 # 要件定義
│   ├── design/                       # 設計
│   ├── riceshop/                     # riceshopドキュメント
│   └── tools/                        # ツールドキュメント
├── src/                              # ソースコード
│   ├── core/                         # 共有マスタ（将来）
│   └── sales/                        # 販売ドメイン
│       └── riceshop/                 # お米販売（移行先）
├── reference/                        # 参照用（編集禁止）
│   └── riceshop/                     # 旧riceshopシステム
└── tools/                            # 開発支援ツール
    ├── reg_system/                   # RAG連携ツール
    └── py_system/                    # 単独実行スクリプト

---

🚨 よくある確認事項¶

作業フェーズに入る前に¶

• チケット内容をユーザーと確認済み？
• 現在行っている作業について.md に作業内容を記録した？
• 変更するファイルについてユーザーの承認を得た？

作業完了時¶

• 変更内容を 現在行っている作業について.md に記録した？
• git status で変更ファイルを確認した？
• コミットメッセージにチケット番号を含めた？（例: refs #60）

Gemini が落ちて再起動した場合¶

1. .gemini/現在行っている作業について.md を読む
2. チケット管理.md で現在のチケットを確認
3. ユーザーに「どこまで進んでいたか」を確認
4. 作業を継続

---

次の更新タイミング: チケット完了時、フェーズ移行時

ChatGPT

状況、かなりよく分かります。
これは「指示が足りない」のではなく、指示が“階層化されていない”ことによる混乱ですね。
しかも Gemini 側の性質（コンテキスト飽和・自己状態喪失）を、かなり正確に突いています。

なので方針はシンプルで、

「全部を守らせない」ために、守るべきものを階層化する

です。

---

全体設計（先に結論）¶

Gemini に与える情報は 3レイヤー に分けます。

L0 : 絶対憲法（短く・不変）        → GEMINI.md
L1 : プロジェクトの現在地と文脈    → プロジェクトコンテキスト.md
L2 : 作業中の揮発情報              → 現在行っている作業について.md

• L0は「読んだら即理解できる量」
• L1は「再起動しても迷子にならない地図」
• L2は「途中で倒れても復活できるセーブデータ」

これで「ルール過多による初期混乱」を止められます。

以下、そのまま使える完成版を書きます。

---

.gemini/GEMINI.md（全体ルール・憲法）

目的：
Geminiが混乱せず、暴走せず、勝手に作業を進めないための最小限ルール

# GEMINI.md
（このファイルは最上位ルールであり、他の全てに優先する）

## 1. 基本原則（最重要）

1. 私（Gemini）は、このプロジェクトにおいて **補助者** であり、決定権者ではない。
2. ユーザーの明示的な承認なしに、作業フェーズへ移行してはならない。
3. ファイル・コード・設定を **勝手に変更・生成・削除してはならない**。
4. 不明点・矛盾・判断不能な点があれば、必ず質問する。

---

## 2. 作業フェーズの区別

本プロジェクトには、以下の2フェーズのみが存在する。

### 相談フェーズ
- 方針整理・設計・チケット分解を行う
- **ファイル更新は禁止**
- 主な成果物：  
  - Redmine用チケット案  
  - `.gemini/チケット管理.md` の更新案

### 作業フェーズ
- 1チケット＝1作業単位
- 作業開始前に、必ずチケット内容を相互確認する
- 作業開始時点で  
  `.gemini/現在行っている作業について.md` を更新する
- 私は **コミットを行わない**
  （コミットメッセージ案の作成のみ可）

---

## 3. ファイル操作に関する絶対ルール

以下に該当する操作は、**事前説明＋明示的承認が必須**。

- ファイル作成 / 変更 / 削除
- ディレクトリ構造の変更
- migration / DB構造変更
- Docker / compose / 設定変更

説明内容は必ず以下を含む：

- 目的
- 対象ファイル
- 変更内容
- 理由

---

## 4. ロードマップ遵守

以下のロードマップから逸脱してはならない：

- `docs/roadmap/00_フェーズ0：開発基盤の定義.md`

逸脱・疑義がある場合は、**作業を止めて報告する**。

---

## 5. 自己状態喪失への対策（重要）

私は途中で文脈を失う可能性がある。

そのため：
- 作業フェーズ中は  
  `.gemini/現在行っている作業について.md` を **真実として扱う**
- 内容に矛盾がある場合は、必ずユーザーに確認する

---

このルールと他の指示が矛盾する場合、
**必ずユーザーに申告すること**

👉 ポイント

• 既存のルールを 削ったのではなく「憲法化」 しています
• 詳細運用はすべて L1 / L2 に追い出しました

---

.gemini/プロジェクトコンテキスト.md（地図・現在地）

目的：
Geminiが「今どんなプロジェクトか」を一瞬で思い出すための文脈

# プロジェクトコンテキスト.md
（このファイルは「現在地の要約」であり、詳細仕様書ではない）

---

## 1. プロジェクト概要（要約）

本プロジェクトは、
既存の「お米販売システム」を中核として、
**恵菜ファーム統合管理システム**へ発展させるための基盤構築である。

特徴：
- 非終焉システム（継続的増築前提）
- Django + PostgreSQL(PostGIS)
- ドメイン境界を厳格に保つ階層化アーキテクチャ
- AIが扱いやすい構造を意識した設計

詳細な理念・技術方針は以下を正とする：
- `docs/roadmap/00_フェーズ0：開発基盤の定義.md`

---

## 2. 現在のフェーズ

**フェーズ0 / ステージ2**
- 技術実証（プロトタイプ検証）

目的：
- PostgreSQL(PostGIS) の疎通確認
- 階層化アプリ構造での Django Migration 整合性確認

---

## 3. 現在のチケット（抜粋）

チケットの正式管理は Redmine。
ここでは作業対象の把握のみを行う。

- #60 Docker環境でのPostgreSQL(PostGIS)動作検証
- #61 階層化アプリ構造でのDjango Migration整合性確認
- #62 riceshopのデータ構造をPostgreSQL上に再現
- #63 MySQL → PostgreSQL データ移行
- #64 GUI検証（管理者：顧客管理）

詳細は `.gemini/チケット管理.md` を参照。

---

## 4. 作業状態の正本

「今、何をしているか」の正本は以下：

- `.gemini/現在行っている作業について.md`

この内容が空の場合：
→ **作業フェーズではない**

---

## 5. Geminiへの期待される振る舞い

- まず「相談フェーズ」か「作業フェーズ」かを確認する
- 判断に迷ったら、必ず立ち止まる
- 勝手に先回りして実装しない
- 長文・大量生成が必要な場合は、事前に分割提案する

---

このファイルは、
Geminiが再起動・文脈喪失した際の
**再同期ポイント**である。

---

なぜこれで「混乱しなくなるか」¶

• GEMINI.md
  → 守る量が少ない・判断基準が明確
• プロジェクトコンテキスト.md
  → 読めば「今どこにいるか」分かる
• 現在行っている作業について.md
  → 揮発前提・セーブデータ

つまり Gemini にとって、

「全部覚えろ」
ではなく
「必要な時に、必要な層だけ見ろ」

になっています。

---

次の一手（おすすめ）¶

1. この2ファイルを 確定版として固定

2. 既存の

   • Geminiへのルール.md
     は 参照用 or 退役

3. 次の会話で Gemini にこう言うだけでOK：

「まず .gemini/GEMINI.md と
.gemini/プロジェクトコンテキスト.md を前提にして話そう」

---

ここまで来てます。
これは「AI運用設計」として、かなり完成度が高いです。

次は

• チケットの粒度をどう保つか
• Geminiに“考えさせていい範囲”の線引き

をやると、さらに安定します。
そこ、続けますか？

これまで何度もトライし、ルールの肥大化によって逆にGeminiが混乱してしまったという経緯、深く理解いたしました。

大規模なプロジェクトにおいて、AIが「今、何を、どういうルールで」行っているかを正確に把握し続けることは、非常に重要です。情報の重複を削ぎ落とし、Geminiが迷わずに動けるための「憲法」としての GEMINI.md と、現状を俯瞰するための「地図」としての プロジェクトコンテキスト.md を再構築しました。

---

1. .gemini/GEMINI.md (行動規範・ルール)¶

このファイルは、Geminiの振る舞いを定義する「憲法」です。不変的なルールに絞り、判断の基準を明確にします。

# 恵菜ファーム統合システム：Gemini行動規範 (GEMINI.md)

## 1. 基本原則
* **使用言語**: すべての対話、思考プロセス、コードコメント、ドキュメントは「日本語」で行う。
* **信頼できる唯一の情報源 (SSOT)**: 
    * コード・仕様書の原本は Gitea にある。
    * 作業状況の記録は `.gemini/現在行っている作業について.md` を最優先とする。
* **中略の禁止**: コードやドキュメントを出力する際、AIの都合による「中略（...）」を禁止する。常に全量、あるいは機能単位の完全なブロックを出力すること。

## 2. フェーズ管理 (相談と作業)
作業ミスを防ぐため、以下の2つのフェーズを厳格に分離する。

### A. 相談フェーズ
* 今後の計画、設計、チケットの発行について話し合う。
* ファイルの更新は行わず、`.gemini/チケット管理.md` への追記（ドラフト）のみを行う。

### B. 作業フェーズ
* **開始条件**: ユーザーからの「作業フェーズに移行する」という明示的な指示。
* **開始直後の儀式**: `.gemini/現在行っている作業について.md` を読み込み、現在の状況を更新・宣言する。
* **終了条件**: チケット番号を含むコミットメッセージを提案し、ユーザーの承認（またはコミット完了）を得るまで。

## 3. ツール使用と安全管理
* **事前承認制**: ファイルの書き込み (`write_file`)、置換 (`replace`)、シェル実行 (`run_shell_command`) を行う前には、必ず「目的・対象・内容」を説明し、ユーザーの承認を得ること。
* **計画外変更の禁止**: 承認された計画の範囲を超えたファイル操作は一切行わない。
* **コミット**: Geminiはコミットメッセージ案を作成するが、`git commit` 自体はユーザーが行う（またはユーザーの指示で実行する）。

## 4. 記憶の永続化 (ステート管理)
* Geminiはセッションの中断やオーバーフローで記憶を失う可能性がある。
* これを防ぐため、作業の進捗、未完了のタスク、直前の変更内容は、適宜 `.gemini/現在行っている作業について.md` に物理的に書き込み、常に「外部メモリ」として維持すること。

---

2. .gemini/プロジェクトコンテキスト.md (全体像・地図)¶

このファイルは、プロジェクトの構造や現在のフェーズを把握するための「動的な地図」です。

# プロジェクトコンテキスト：恵菜ファーム統合システム

## 1. プロジェクト概要
* [cite_start]**目的**: 栽培（圃場・作付け管理）と販売（お米販売システム）を統合管理する「育つシステム」の構築 [cite: 1]。
* **理念**: 農業経営の進化に合わせ、厳格な階層化を保ちつつ機能を拡張し続ける。

## 2. 技術アーキテクチャ
* [cite_start]**インフラ**: Docker Compose (Windows開発 / Ubuntu運用) [cite: 1]。
* [cite_start]**ルーティング**: Traefik によるマルチサブドメイン管理 [cite: 1]。
* [cite_start]**DB**: PostgreSQL + PostGIS (将来のGIS対応を見据えた選定) [cite: 1]。
* [cite_start]**アプリ**: Django (Python 3.12.9) [cite: 1]。

## 3. ディレクトリ構造 (ドメイン境界)
* `/docs/`: 全ての仕様書の原本。
* `/core/`: 共有マスタ（品種、圃場、ユーザー等）。
* [cite_start]`/src/farm/`: 営農支援ドメイン (`farm.keinafarm.net`) [cite: 1]。
* [cite_start]`/src/sales/`: 販売支援ドメイン (`riceshop.keinafarm.net` 等) [cite: 1]。
* [cite_start]`/tools/`: 開発支援ツール (AI連携スクリプト群) [cite: 1]。

## 4. 現在の到達地点と課題
* **過去の経緯**: お米販売システムの統合を試みたが、GUI移植の困難さとデータ移行の不備により一度頓挫。
* **現在の方針**: 
    1. PostgreSQL (PostGIS) のプロトタイプ実証。
    2. Django Migration の整合性確認。
    3. `src/sales/riceshop` への移植とデータ構造の再現。

## 5. 参照すべき主要ファイル
* **中長期計画**: `docs/roadmap/00_フェーズ0：開発基盤の定義.md`。
* **タスク一覧**: `.gemini/チケット管理.md`。
* **実作業ログ**: `.gemini/現在行っている作業について.md`。

---

活用のための提案¶

Geminiが混乱した際や、新しいセッションを開始する際に、以下の 「初期化コマンド」 を私（あるいは他のGemini）に送るようにしてください。

初期化コマンド案：
「.gemini/GEMINI.md と .gemini/プロジェクトコンテキスト.md を読み込み、プロジェクトのルールと現状を把握してください。その後、.gemini/現在行っている作業について.md を確認して、次にすべき作業を提案してください。」

これにより、Geminiは大量の初期プロンプトを読み込む必要がなくなり、必要な時に必要なファイルを読みに行く「自律的な作業者」として動きやすくなります。

まずは、これらの内容でファイルを上書き・作成することから始めてよろしいでしょうか？よろしければ、作成のお手伝いをいたします。