操作

リンクをコピー

機能 #65

完了

Geminiへの指示を作り直す

吉田明さんが約2ヶ月前に追加. 約2ヶ月前に更新.

ステータス:

終了

優先度:

通常

担当者:

吉田明

カテゴリ:

設計方針など

対象バージョン:

0.0.1

開始日:

2026/01/01

期日:

進捗率:

予定工数:

説明

Geminiにルールを与えすぎて、まともに作業出来なくなったので、整理する

結構規模のあるプロジェクトの作業をしています。今まで、何度かトライしてきたのですが、途中でgeminiへのうまく指示が伝わらなくてとん挫してきました。その度毎に、必要な事を付け加えてルールを増やしていったのですが、今度は、初期ルールが多すぎて最初からgeminiが混乱する事態に陥っています。これらを整理して、プロジェクトを遂行できる状態にしたいです。 @.gemini\Geminiへのルール.md には、基本的なルールが記載されています。 @.gemini\チケット管理.md では、これからやるチケットにを記録して中期的な目標を定めています。 @.gemini\現在行っている作業について.md では、geminiがオーバーフローしたり、落ちたりした場合、シームレスに作業が再開できるように、Gemini自身にやっている作業を記載してもらっています。プロジェクトの内容などについては、 @docs\aboutMe\AboutThisSystem.txt に、プロジェクトの概要と方針を記述しました。 @docs\roadmap\00_フェーズ0：開発基盤の定義.md では、チケット管理.mdより長いスパンでの作業方針が記載されています。それらを元に、Geminiが適切に作業していけるような、指示内容や情報に変えていきたいです。 @.gemini\プロジェクトコンテキスト.md に、こんな感じになるのかもしれないと思った体裁を作ってみましたが、これを守る必要はないので、あなたがベストだと思う内容でこのプロジェクト全体で適用されるルール .gemini\GEMINI.md と .gemini\プロジェクトコンテキスト.md を作成してください。

操作

リンクをコピー

吉田明さんが約2ヶ月前に更新

Copilot¶

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

🎯 基本原則¶

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

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

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

📋 2つのフェーズ¶

相談フェーズ（Planning）¶

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

やること:

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

やらないこと:

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

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

作業フェーズ（Execution）¶

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

開始条件:

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

作業手順:

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

禁止事項:

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

💾 コミット管理¶

コミットタイミング¶

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

コミット手順¶

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

📁 ファイル変更の原則¶

絶対ルール¶

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

変更が必要になったら¶

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

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

ドキュメント階層¶

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

ソースコード階層¶

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

管理ファイル¶

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

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

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

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

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

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

🔒 守るべき最優先事項¶

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

📝 記録の重要性¶

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

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

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

gemini.md

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

🎯 基本原則¶

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

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

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

📋 2つのフェーズ¶

相談フェーズ（Planning）¶

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

やること:

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

やらないこと:

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

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

作業フェーズ（Execution）¶

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

開始条件:

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

作業手順:

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

禁止事項:

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

💾 コミット管理¶

コミットタイミング¶

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

コミット手順¶

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

📁 ファイル変更の原則¶

絶対ルール¶

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

変更が必要になったら¶

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

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

ドキュメント階層¶

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

ソースコード階層¶

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

管理ファイル¶

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

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

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

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

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

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

🔒 守るべき最優先事項¶

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

前回の課題¶

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

新しい方針¶

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

📚 重要なドキュメント¶

プロジェクト理解¶

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

開発ルール¶

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

作業管理¶

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

既存システム参照¶

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

🎯 次のステップ¶

直近の目標¶

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

この後の流れ¶

riceshop のコードを src/sales/riceshop に配置
PostgreSQL 上にテーブル構造を構築
既存データを移行
管理画面から順次、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 が落ちて再起動した場合¶

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

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

操作

リンクをコピー

吉田明さんが約2ヶ月前に更新

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 にとって、

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

になっています。

次の一手（おすすめ）¶

この2ファイルを 確定版として固定
既存の
- Geminiへのルール.md
  は 参照用 or 退役
次の会話で Gemini にこう言うだけでOK：

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

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

次は

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

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

操作

リンクをコピー

吉田明さんが約2ヶ月前に更新

これまで何度もトライし、ルールの肥大化によって逆に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は大量の初期プロンプトを読み込む必要がなくなり、必要な時に必要なファイルを読みに行く「自律的な作業者」として動きやすくなります。

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

操作

リンクをコピー

吉田明さんが約2ヶ月前に更新

ステータス を新規から終了に変更

操作

リンクをコピー

他の形式にエクスポート: Atom PDF

プロジェクト

全般

プロフィール

恵菜ファーム統合システム

カスタムクエリ

機能 #65

Geminiへの指示を作り直す

吉田 明 さんが約2ヶ月前に更新

Copilot¶

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

🎯 基本原則¶

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

📋 2つのフェーズ¶

相談フェーズ（Planning）¶

作業フェーズ（Execution）¶

💾 コミット管理¶

コミットタイミング¶

コミット手順¶

📁 ファイル変更の原則¶

絶対ルール¶

変更が必要になったら¶

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

ドキュメント階層¶

ソースコード階層¶

管理ファイル¶

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

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

🔒 守るべき最優先事項¶

📝 記録の重要性¶

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

🎯 基本原則¶

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

📋 2つのフェーズ¶

相談フェーズ（Planning）¶

作業フェーズ（Execution）¶

💾 コミット管理¶

コミットタイミング¶

コミット手順¶

📁 ファイル変更の原則¶

絶対ルール¶

変更が必要になったら¶

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

ドキュメント階層¶

ソースコード階層¶

管理ファイル¶

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

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

🔒 守るべき最優先事項¶

📝 記録の重要性¶

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

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

📌 システム概要¶

目的¶

特徴¶

🛠️ 技術スタック¶

開発環境¶

運用環境¶

アプリケーション¶

📊 現在の進捗状況¶

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

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

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

🎫 現在のチケット¶

優先度: 高¶

優先度: 中¶

🔄 現在の作業状況¶

前回の課題¶

新しい方針¶

📚 重要なドキュメント¶

プロジェクト理解¶

開発ルール¶

作業管理¶

既存システム参照¶

🎯 次のステップ¶

直近の目標¶

この後の流れ¶

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

🚨 よくある確認事項¶

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

作業完了時¶

吉田明さんが約2ヶ月前に更新

吉田明さんが約2ヶ月前に更新

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

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

吉田明さんが約2ヶ月前に更新

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

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

吉田明さんが約2ヶ月前に更新