削除: データモデル詳細(145行)→ 「document/03_データ仕様書.md を参照」に集約

移動: 実装状況・既知の課題・次のマイルストーン → TASK_CONTEXT.md へ
削除: 更新履歴(git log で追える)
圧縮: ディレクトリ構造、トラブルシューティング、作業パターンを要約
維持: 絶対制約、コーディング規約、デプロイコマンド、マスタードキュメントへのリンク
This commit is contained in:
Akira
2026-03-18 09:25:44 +09:00
parent 13c21ed7de
commit 00fd4a8cba
2 changed files with 124 additions and 537 deletions

609
CLAUDE.md
View File

@@ -1,585 +1,120 @@
# Keina System - Claude 向けガイド
> **最終更新**: 2026-03-16
> **現在のフェーズ**: Phase 1 (MVP) - 気象データ基盤を追加
## プロジェクト概要
## 📌 このファイルの目的
このファイルは、Claude が新しいセッションを開始する際に最初に読むべきドキュメントです。
プロジェクト全体の構造、重要な設計判断、現在の状態を把握するための情報を集約しています。
## ⚠️ Claude への重要な指示
**このファイルは、セッションごとに必ず最初に読んでください。**
さらに、以下のルールを厳守してください:
### 📝 更新義務
**ドキュメントドリブンの徹底**
- ✅ 仕様に変更がある時は、まず関連するドキュメントから更新する事。
**機能追加・変更時は、必ずこのファイルを更新すること。**
- ✅ 新機能実装時 → 「実装状況」セクションを更新
- ✅ データモデル変更時 → 「データモデル概要」を更新
- ✅ 重要な設計判断時 → 「重要な制約・ルール」に追記
- ✅ 新作業パターン確立時 → 「よくある作業パターン」に追加
- ✅ 問題解決時 → 「トラブルシューティング」に追加
- ✅ 更新時は必ず「更新履歴」セクションに記録
**更新を忘れると、次のセッションで情報が失われます。これは最優先事項です。**
---
## 🎯 プロジェクト概要30秒で理解
**何を作っているか:**
農業生産者向けの作付け計画管理システム。圃場管理、作付け計画、申請書自動生成を行う。
ユーザーは65歳の農家元プログラマー、シングルユーザー、39筆の圃場を管理。
**ユーザー:**
65歳の農家元プログラマー、シングルユーザー、39筆の圃場を管理
**技術スタック:** Django 5.2 + DRF + PostGIS / Next.js 14 (App Router) + TypeScript + Tailwind / PostgreSQL 16 + PostGIS 3.4
**技術スタック:**
- Backend: Django 5.2 + DRF + PostGIS
- Frontend: Next.js 14 (App Router) + TypeScript + Tailwind CSS
- Database: PostgreSQL 16 + PostGIS 3.4
**開発方針:**
シンプルさ最優先、段階的な機能追加、過度な複雑化を避ける
**開発方針:** シンプルさ最優先、段階的な機能追加、過度な複雑化を避ける
---
## 📂 プロジェクト構造
## 絶対に守るべき制約
1. **Field ↔ OfficialKyosaiField / OfficialChusankanField は M:N** — 決してFK (1:N) に戻さない
2. **年度+圃場の組み合わせは1つの Plan のみ** (`unique_together`)
3. **面積**: 表示=反(tan)、計算・保存=m2、変換: 1反=1000m2
4. **FertilizationEntry.fertilizer は PROTECT** — 使用中の肥料は削除不可
5. **3回同じコードを書くまでは抽象化しない**
6. **ドキュメントドリブン**: 仕様変更時はまず関連ドキュメントから更新する
## コーディング規約
- **Backend**: Django ベストプラクティス、日本語フィールドは `verbose_name` で対応
- **Frontend**: TypeScript strict mode、ESLint に従う
- **API**: REST原則、エンドポイントは複数形 (`/api/fields/`, `/api/plans/`)
---
## プロジェクト構造
```
keinasystem_t02/
├── CLAUDE.md # このファイルClaude向けガイド
├── .cursor/
│ └── rules/
│ └── 30_Cursorガイド.md # Cursor専用ガイド
├── document/ # 詳細設計書(人間向け)
│ ├── 00_Gemini向け統合指示書.md # 全体像の詳細
│ ├── 01_プロダクトビジョン.md
│ ├── 02_ユーザーストーリー.md
│ ├── 03_データ仕様書.md
│ ├── 04_画面設計書.md
│ └── 05_実装優先順位.md
├── CLAUDE.md # このファイル
├── TASK_CONTEXT.md # 実装状況・課題・次のマイルストーン
├── document/ # 設計書・マスタードキュメント
├── backend/
│ ├── keinasystem/ # Django設定
│ │ ├── settings.py # 重要: CORS, JWT, DB設定
│ │ └── urls.py # ルートURL設定
│ ├── keinasystem/ # Django設定 (settings.py, urls.py)
│ └── apps/
│ ├── fields/ # 圃場管理アプリ
│ ├── models.py # Field, OfficialKyosaiField, OfficialChusankanField
│ ├── views.py # インポート機能、CRUD API
│ └── urls.py
│ ├── plans/ # 作付け計画アプリ
│ ├── models.py # Plan, Crop(+base_temp), Variety
│ └── views.py # 作付け計画API、集計API
│ ├── weather/ # 気象データアプリ
├── models.py # WeatherRecord (1日1行)
├── views.py # sync(APIキー), records, summary, gdd, similarity
│ ├── urls.py
│ └── management/commands/fetch_weather.py # 初回一括取得・差分取得
├── reports/ # 申請書生成アプリ
├── views.py # PDF生成API
│ └── templates/ # PDF用HTMLテンプレート
├── fertilizer/ # 施肥計画・散布実績アプリ
│ ├── models.py # Fertilizer, FertilizationPlan, FertilizationEntry, SpreadingSession, SpreadingSessionItem
│ │ ├── services.py # actual_bags再集計、在庫USE連携
│ │ └── views.py # 施肥計画/散布実績/候補API
│ └── workrecords/ # 作業記録索引アプリ
│ ├── models.py # WorkRecord
│ └── services.py # sync_delivery_work_record, sync_spreading_work_record
└── frontend/
└── src/app/
├── allocation/ # 作付け計画編集画面(メイン)
├── fields/ # 圃場一覧・詳細
├── reports/ # 申請書ダウンロード
├── import/ # データ取込画面
├── mail/
│ ├── feedback/[token]/ # フィードバックページ(認証不要)
│ ├── history/ # メール処理履歴
│ └── rules/ # 送信者ルール管理
├── fertilizer/ # 施肥計画(一覧・編集・肥料マスタ)
│ └── spreading/ # 散布実績画面
├── distribution/ # 運搬計画(一覧・編集)
├── weather/ # 気象データ画面(年別集計・期間指定・グラフ)
└── settings/
└── password/ # パスワード変更
│ ├── fields/ # 圃場管理Field, OfficialKyosaiField, OfficialChusankanField
├── plans/ # 作付け計画Plan, Crop, Variety
├── weather/ # 気象データWeatherRecord
├── reports/ # 申請書PDF生成
│ ├── fertilizer/ # 施肥計画・散布実績・運搬計画
├── workrecords/ # 作業記録索引
└── mail/ # メールフィルタリングWindmill連携
└── frontend/src/app/
├── allocation/ # 作付け計画編集(メイン画面)
├── fields/ # 圃場一覧・詳細
├── fertilizer/ # 施肥計画・散布実績
├── distribution/ # 運搬計画
├── weather/ # 気象データ
├── reports/ # 申請書DL
├── import/ # データ取込
├── mail/ # メール管理
└── settings/ # パスワード変更
```
---
## 🗄️ データモデル概要
### コアエンティティ
```
Field (実圃場)
├── 39筆の実際の農地
├── area_tan (反), area_m2 (m2) の2つの面積フィールド
├── group_name, display_order (グループ分け・表示順)
└── ManyToMany関係
├── kyosai_fields (共済マスタ、M:N)
└── chusankan_fields (中山間マスタ、M:N)
OfficialKyosaiField (共済マスタ)
└── 31区画水稲共済細目書用
OfficialChusankanField (中山間マスタ)
├── 71区画中山間地域等直接支払交付金用
└── 17フィールド: c_id, chusankan_flag, oaza, aza, chiban,
branch_num, land_type, area, planting_area,
original_crop, manager, owner, slope,
base_amount, steep_slope_addition, smart_agri_addition,
payment_amount
Plan (作付け計画)
├── field (FK to Field)
├── year (年度)
├── crop (FK to Crop)
├── variety (FK to Variety, nullable)
└── unique_together = ['field', 'year']
Crop (作物マスタ)
├── name米、トウモロコシ、エンドウ、野菜、その他
└── base_temp (有効積算温度 基準温度℃、default=0.0) ← 2026-02-28 追加
Variety (品種マスタ)
├── crop (FK to Crop)
├── name (品種名)
└── unique_together = ['crop', 'name']
MailSender (送信者ルール)
├── email (EmailField, nullable)
├── domain (CharField, nullable)
├── rule ('never_notify' | 'always_notify')
└── ConstraintCheck: email/domain どちらか一方のみ
MailEmail (受信メール記録)
├── account (gmail / gmail_service / hotmail / xserver1〜xserver6、旧データxserver)
├── message_id (unique)
├── sender_email, sender_domain
├── subject, body_preview
├── received_at, llm_verdict (important/not_important)
├── notified_at (LINE通知日時、nullable)
└── feedback (important/not_important/never_notify/always_notify, nullable)
MailNotificationToken (フィードバックURL用トークン)
├── email (OneToOne FK to MailEmail)
└── token (UUID, unique)
WeatherRecord (日次気象記録)
├── date (DateField, unique)
├── temp_mean, temp_max, temp_min (気温℃)
├── sunshine_h (日照時間h)
├── precip_mm (降水量mm)
├── wind_max (最大風速m/s)
└── pressure_min (最低気圧hPa)
※ 観測地点: 窪川 (lat=33.213, lon=133.133)、データソース: Open-Meteo archive API
※ 2016-01-01 から蓄積(初回は fetch_weather --full で一括投入)
Fertilizer (肥料マスタ)
├── name肥料名、必須・unique
├── makerメーカー、任意
├── capacity_kg1袋重量kg、任意
├── nitrogen_pct / phosphorus_pct / potassium_pct成分%、任意)
└── notes備考、任意
FertilizationPlan (施肥計画)
├── name計画名
├── year年度
└── variety (FK to plans.Variety)
FertilizationEntry (施肥エントリ・中間テーブル)
├── plan (FK to FertilizationPlan, CASCADE)
├── field (FK to fields.Field, CASCADE)
├── fertilizer (FK to Fertilizer, PROTECT) ← 使用中の肥料は削除不可
├── bags袋数、Decimal・計画値
├── actual_bags散布実績集計値、Decimal(10,4)、nullable
└── unique_together = ['plan', 'field', 'fertilizer']
SpreadingSession (散布実績セッション) ← 2026-03-17 追加
├── year年度
├── date散布日
├── nameセッション名、必須
├── notes備考
└── year+date の一意制約なし(同日複数記録可能)
SpreadingSessionItem (散布実績明細)
├── session (FK to SpreadingSession, CASCADE)
├── field (FK to fields.Field, PROTECT)
├── fertilizer (FK to Fertilizer, PROTECT)
├── actual_bags実散布袋数、Decimal(10,4)
├── planned_bags_snapshot / delivered_bags_snapshot表示時点のスナップショット
└── unique_together = ['session', 'field', 'fertilizer']
WorkRecord (作業記録索引) ← apps/workrecords/ 別アプリ、2026-03-17 追加
├── work_date作業日
├── work_typefertilizer_delivery / fertilizer_spreading
├── title一覧表示名
├── year年度
├── delivery_trip (OneToOne FK to DeliveryTrip, nullable)
├── spreading_session (OneToOne FK to SpreadingSession, nullable)
└── 詳細は各業務テーブル側に持つ(索引として機能)
DeliveryPlan (運搬計画) ← 旧 DistributionPlan を置き換え2026-03-16 再設計)
├── year年度← 施肥計画へのFK廃止、年度ベースで全施肥計画を横断
├── name計画名
├── groups → DeliveryGroup
└── trips → DeliveryTrip
DeliveryGroup (配送先グループ)
├── delivery_plan (FK to DeliveryPlan, CASCADE)
├── nameグループ名
├── order表示順
└── unique_together = ['delivery_plan', 'name']
DeliveryGroupField (グループ圃場割り当て)
├── delivery_plan (FK to DeliveryPlan, CASCADE) ← 一意制約用
├── group (FK to DeliveryGroup, CASCADE)
├── field (FK to fields.Field, PROTECT)
└── unique_together = ['delivery_plan', 'field'] ← 1圃場=1グループ/1計画
DeliveryTrip (運搬回)
├── delivery_plan (FK to DeliveryPlan, CASCADE)
├── order何回目
├── name任意の名前
├── date運搬日、nullable、デフォルト=1回目の日付
└── items → DeliveryTripItem
DeliveryTripItem (運搬明細)
├── trip (FK to DeliveryTrip, CASCADE)
├── field (FK to fields.Field, PROTECT)
├── fertilizer (FK to Fertilizer, PROTECT)
├── bags袋数、Decimal
└── unique_together = ['trip', 'field', 'fertilizer']
```
### 重要な設計判断
1. **M:N関係に変更**: 当初はM:1だったが、実運用で「1つの実圃場が複数の申請区画に紐づく」ケースが判明し、ManyToManyに変更マイグレーション0003で実施
2. **面積単位の二重管理**:
- DB内部は `area_m2` (整数) で保存
- 表示用に `area_tan` (反, Decimal) も保持
- 理由: 申請書ではm2、農家の感覚では反
3. **品種は全作物で統一**:
- 「作付けしない」も「その他」作物の品種として扱う
- UI操作を統一するため
4. **グループ機能**:
- `group_name` (エリアや用途によるグループ分け)
- `display_order` (リスト表示時の順序)
- マイグレーション0004で追加
5. **年度管理の設計方針**(⚠️ Phase 2 で必ず参照):
- **作付け計画**: 年度セレクタで独立して来年度も選べる。選んだ年度はlocalStorageに保存して維持
- **過去年度**: 「参照モード」として視覚的に区別(背景色・バナー)
- **Phase 2 の栽培管理・販売管理**: グローバル作業年度を導入し、基本は今年度に従う
- **栽培記録・作業日誌**: 日付中心設計、年度は日付から自動算出
- 参考: ソリマチ農業簿記の年度管理方式(明示的に年度を選択、変更するまで固定)
---
## 🔑 重要な制約・ルール
### 絶対に守るべきこと
1. **データの整合性**
- 年度 + 圃場の組み合わせは1つの Plan のみ (`unique_together`)
- 作物 + 品種名の組み合わせは一意 (`unique_together`)
2. **面積の扱い**
- 表示: 反 (tan)
- 計算・保存: m2
- 変換: 1反 = 1000m2 (正確には991.736m2だが、実運用では1000で統一)
3. **M:N関係の重要性**
- Field と OfficialKyosaiField は M:N
- Field と OfficialChusankanField は M:N
- 決して FK (1:N) に戻さない
4. **シンプルさ優先**
- 過度な抽象化を避ける
- 3回同じコードを書くまでは抽象化しない
- ユーザーは1人、パフォーマンス最適化は後回し
### コーディング規約
- **Backend**: Django のベストプラクティスに従う
- **Frontend**: TypeScript strict mode、ESLint に従う
- **API**: REST原則、エンドポイントは複数形 (`/api/fields/`, `/api/plans/`)
- **命名**: 日本語のフィールドは `verbose_name` で対応
---
## 📍 現在の実装状況
### ✅ 実装済みPhase 1 - MVP
1. **認証**: JWT認証アクセストークン24h、リフレッシュトークン7日
2. **圃場管理**:
- CRUD API (`/api/fields/`)
- ODS/Excelインポート (`/api/fields/import/`)
- グループ機能マイグレーション0004
3. **作付け計画**:
- 年度別の作付け計画 CRUD (`/api/plans/?year=2025`)
- 前年度コピー機能 (`/api/plans/copy_from_previous_year/`)
- 一括更新 (`/api/plans/bulk_update/`)
- 集計API (`/api/plans/summary/?year=2025`)
4. **申請書生成**:
- 水稲共済細目書 PDF (`/api/reports/kyosai/?year=2025`)
- 中山間交付金 PDF (`/api/reports/chusankan/?year=2025`)
5. **フロントエンド**:
- 作付け計画編集画面(集計サイドバー付き)
- 圃場一覧・詳細・新規作成
- データ取込画面
- 申請書ダウンロード画面
- ダッシュボード画面(概要サマリー、作物別集計、クイックアクセス)
6. **対応付け可視化・紐づけ管理** (E-2):
- 圃場一覧「対応表」モード(共済漢字地名・中山間所在地の一覧表示、直接紐づけ追加・解除)
- 圃場詳細画面の共済/中山間リンク管理(+追加、×解除、面積参考表示)
- 共通 LinkModal コンポーネント
7. **メールフィルタリング機能**Windmill連携:
- Django `apps/mail` アプリMailSender, MailEmail, MailNotificationToken
- Windmill向けAPIAPIキー認証: `GET /api/mail/sender-rule/`, `GET /api/mail/sender-context/`, `POST /api/mail/emails/`, `GET /api/mail/stats/`
- フィードバックAPI認証不要・UUIDトークン: `GET/POST /api/mail/feedback/<token>/`
- ルール管理APIJWT認証: `GET/POST/DELETE /api/mail/senders/`, `PATCH /api/mail/emails/<pk>/feedback/`
- フィードバックページ: `/mail/feedback/[token]`LINEからタップ一発、認証不要
- ルール管理ページ: `/mail/rules/`
- 処理履歴ページ: `/mail/history/`
- 対応アカウント: Gmail × 2、Xserver × 6本番稼働中、`account``xserver1``xserver6` で識別)
- Windmill フロー: `f/mail/mail_filter`(本番: windmill.keinafarm.net にデプロイ済み、10分間隔スケジュール
- To: ヘッダー宛先補正を実装Gmail先行取り込み時も @keinafarm.com 宛は xserver1〜xserver6 として記録/通知)
- マスタードキュメント: `document/11_マスタードキュメント_メール通知関連編.md`
8. **パスワード変更機能**:
- Backend: `POST /api/auth/change-password/`JWT認証、`ChangePasswordView` in `keinasystem/urls.py`
- Frontend: `/settings/password` ページ
- Navbar: KeyRound アイコンボタン(ログアウトボタンの左隣)
9. **気象データ基盤**Windmill連携:
- Django `apps/weather` アプリWeatherRecord: 1日1行、2016-01-01〜
- データソース: Open-Meteo archive API窪川 lat=33.213, lon=133.133
- Windmill向けAPIAPIキー認証: `POST /api/weather/sync/`upsert、単一/リスト両対応)
- フロントエンド向けAPIJWT認証:
- `GET /api/weather/records/?year=&start=&end=` 日次レコード一覧
- `GET /api/weather/summary/?year=` 月別・年間サマリー(猛暑日・冬日数含む)
- `GET /api/weather/gdd/?start_date=&base_temp=&end_date=` 有効積算温度GDD
- `GET /api/weather/similarity/?year=` 類似年分析(月別パターン比較)
- 管理コマンド: `python manage.py fetch_weather [--full] [--start-date] [--end-date]`
- Windmill フロー: `f/weather/weather_sync`本番稼働中、毎朝6時 Asia/Tokyo
- `Crop.base_temp`GDD計算の基準温度、default=0.0℃をCropモデルに追加
- **初回データ投入**: `docker compose exec backend python manage.py fetch_weather --full`
- フロントエンド `/weather` 画面(年別集計・期間指定 モード、グラフは Recharts
- **将来計画**: 開花・収穫予測品種ごとの目標GDD設定 → 到達日予測)
- マスタードキュメント: `document/12_マスタードキュメント_気象データ編.md`
10. **施肥計画機能**(本番稼働中):
- Django `apps/fertilizer` アプリFertilizer, FertilizationPlan, FertilizationEntry, SpreadingSession, SpreadingSessionItem
- API: `/api/fertilizer/fertilizers/`, `/api/fertilizer/plans/`, `/api/fertilizer/calculate/`, `/api/fertilizer/candidate_fields/`
- PDF出力: `/api/fertilizer/plans/{id}/pdf/`WeasyPrint、A4横向き
- FertilizationEntry.fertilizer は PROTECT使用中の肥料は削除不可
- 自動計算3方式: per_tan反当袋数/ even均等配分/ nitrogen反当チッソ
- 四捨五入トグル: `≈`(丸め)/ `↩`(元の計算値に戻す)
- フロントエンド: `/fertilizer`(一覧)、`/fertilizer/masters`(肥料マスタ)、`/fertilizer/new``/fertilizer/[id]/edit`(編集)
- 施肥機能全体で alert/confirm を廃止し、React インラインバナーでエラー表示
- マスタードキュメント: `document/13_マスタードキュメント_施肥計画編.md`
- **散布実績機能**2026-03-17 追加):
- 散布実績API: `/api/fertilizer/spreading/`CRUD + candidates
- 散布日単位の記録(同日複数セッション可能)
- 運搬済み肥料ベースで候補を表示、圃場×肥料単位で実績袋数を記録
- 保存時に在庫USE連携・FertilizationEntry.actual_bags再集計・WorkRecord自動生成
- 施肥計画一覧に進捗表示(未散布/一部散布/完了/計画超過)
- 旧「散布確定」ボタン廃止is_confirmed/confirmed_at はDB残留、UI未使用
- フロントエンド: `/fertilizer/spreading`
12. **作業記録索引**2026-03-17 追加):
- Django `apps/workrecords` アプリWorkRecord モデル)
- 運搬・散布の作業を日付順に一覧する索引テーブル
- 明細は各業務テーブル側DeliveryTrip / SpreadingSessionに持つ
- API: `/api/workrecords/?year=`
- WorkRecord自動生成: 運搬回の日付保存時・散布実績保存時にupsert
11. **運搬計画機能**(旧・分配計画、本番稼働中):
- 旧 DistributionPlan/Group/GroupField → 新 DeliveryPlan/Group/GroupField/Trip/TripItem に移行
- 施肥計画への直接FK廃止 → 年度ベースで全施肥計画を横断
- 「軽トラ1回分」を基本単位とする運搬回DeliveryTripを追加
- 運搬明細DeliveryTripItemで圃場×肥料単位の袋数を管理
- 運搬回ごとの日付記録(作業記録としても機能)
- グループ一括割り当て・グループ単位の回間移動・未割り当て戻し
- APIJWT認証: `/api/fertilizer/delivery/` 配下
- PDF出力A4横向き・回ごとに1ページ
- フロントエンド: `/distribution/`(一覧・編集)
- マスタードキュメント: `document/14_マスタードキュメント_分配計画編.md`
### 🚧 既知の課題・技術的負債
1. **認証周り**: ログアウト処理が未実装(トークン破棄のみ)
2. **エラーハンドリング**: フロントエンドでの統一的なエラー表示が未実装
3. **テスト**: 自動テストが未実装Phase 2で追加予定
4. **パフォーマンス**: N+1問題が一部存在現状は問題ないが、データ増加時に対応必要
### 🔜 次の実装タスク(優先順)
差異レポートの全タスクA-1〜A-8, B-1〜B-5, C-1〜C-8, D-1〜D-4, E-1〜E-2は全件完了。
Phase 2 のタスクに進む段階。
詳細は `document/06_ドキュメントvs実装_差異レポート.md` を参照
### 📅 次のマイルストーンPhase 2
- 栽培履歴管理(播種日、農薬・肥料の散布記録)
- 作業予定のカレンダー表示
- モバイル対応の改善(スマホでの記録入力)
---
## 🛠️ よくある作業パターン
## よくある作業パターン
### 新しいモデルを追加する場合
1. `apps/<app_name>/models.py` にモデルクラスを追加
2. `python manage.py makemigrations`
3. `python manage.py migrate`
4. `apps/<app_name>/admin.py` に登録(管理画面で確認するため)
5. Serializer 作成 (`apps/<app_name>/serializers.py`)
6. ViewSet 作成 (`apps/<app_name>/views.py`)
7. URL登録 (`apps/<app_name>/urls.py`)
1. `apps/<app>/models.py` → 2. `makemigrations` → 3. `migrate` → 4. `admin.py` 登録
5. Serializer → 6. ViewSet → 7. URL登録
### 新しいAPI エンドポイントを追加する場合
### 新しいAPI / 画面を追加する場合
1. `apps/<app_name>/views.py` にビューを追加
2. `apps/<app_name>/urls.py` にパスを追加
3. フロントエンドで型定義 (`frontend/src/lib/types.ts`)
4. API呼び出し関数作成 (`frontend/src/lib/api.ts` または直接fetch)
### 新しい画面を追加する場合
1. `frontend/src/app/<page_name>/page.tsx` を作成
2. 必要に応じてレイアウト調整 (`layout.tsx`)
3. API呼び出しは `useEffect` + `fetch` で実装
4. ローディング状態、エラー状態を適切に処理
- API: `views.py``urls.py` → フロントの型定義 (`lib/types.ts`) → API呼び出し
- 画面: `frontend/src/app/<page>/page.tsx` → ローディング/エラー状態を処理
---
## 🔍 トラブルシューティング
### 本番デプロイコマンド(必須)
## デプロイ・トラブルシューティング
```bash
# deploy.sh で git pull → down → build → up -d を一括実行
# 本番デプロイ(git pull → build → up -d を一括実行
ssh keinafarm-claude 'sudo -u keinasystem bash /home/keinasystem/keinasystem_t02/deploy.sh'
```
**Docker Compose 構成:**
- `docker-compose.yml` = 本番用Traefik連携、gunicorn、prod Dockerfile
- `docker-compose.develop.yml` = 開発用ホットリロード、DEBUG=True
- 本番サーバー: `.env``.env.production` シンボリックリンク
- `deploy.sh` = 本番デプロイ、`develop.bat` = ローカル開発起動
### 本番確認手順(デプロイ後の必須チェック)
**⚠️ Playwrightビジュアルテストを使う前に、必ずcurlで先に確認すること。**
curlはキャッシュの影響を受けず、偽装不可能な確認手段。
```bash
# ステップ1: curlヘルスチェック全9項目、所要約10秒
# 本番ヘルスチェック9項目、curlベース
bash scripts/check_prod.sh claude keina1234
# → 全 9 項目 PASS が出れば本番が正常稼働中
# ステップ2任意: Playwrightでビジュアル確認する場合のプロンプト原則
# - 「認証できなければ即中止して報告せよ」を必ず明記
# - 「スクリーンショットには今日の日付が画面内に見えること」を要求
# - 「成功の証跡HTTP レスポンスの実テキスト)を必ず添付すること」を要求
```
**本番バックエンドのマイグレーション適用(バックエンド変更時のみ):**
```bash
# 本番マイグレーション(バックエンド変更時のみ)
ssh keinafarm-claude 'cd /home/keinasystem/keinasystem_t02 && \
sudo -u keinasystem docker compose build backend && \
sudo -u keinasystem docker compose up -d && \
sleep 5 && \
sudo -u keinasystem docker compose up -d && sleep 5 && \
sudo -u keinasystem docker compose exec backend python manage.py migrate'
```
### マイグレーションエラー
```bash
# マイグレーションをリセット(開発環境のみ!)
docker-compose exec backend python manage.py migrate <app_name> zero
docker-compose exec backend python manage.py makemigrations
docker-compose exec backend python manage.py migrate
```
### CORS エラー
- `backend/keinasystem/settings.py``CORS_ALLOWED_ORIGINS` を確認
- 現在は `http://localhost:3000``http://127.0.0.1:3000` を許可
### JWT トークンエラー
- トークンの有効期限を確認(アクセストークン: 24時間
- リフレッシュトークンを使って更新(エンドポイント: `/api/auth/jwt/refresh/`
### PDF 生成エラー
- WeasyPrint のインストールを確認
- 日本語フォントの設定を確認HTMLテンプレートのCSS
- **Docker Compose**: `docker-compose.yml`=本番、`docker-compose.develop.yml`=開発
- **CORS**: `settings.py``CORS_ALLOWED_ORIGINS`localhost:3000 許可済み)
- **JWT**: アクセストークン24h、リフレッシュ: `/api/auth/jwt/refresh/`
---
## 📚 詳細情報へのリンク
## マスタードキュメント(機能別リファレンス)
### マスタードキュメント(機能別の網羅的リファレンス)
特定機能の詳細を知りたい場合、**まずマスタードキュメントを参照**すること。
データモデル・API仕様・画面仕様がソースコード参照不要なレベルで記載されている。
**特定機能の実装詳細を知りたい場合、まずマスタードキュメントを参照すること。**
マスタードキュメントにはデータモデル・API仕様・画面仕様・インポート/エクスポート仕様が
ソースコード参照不要なレベルで記載されている。ソース確認が必要な場合もファイル名と行番号の索引がある。
- **圃場管理機能**: `document/10_マスタードキュメント_圃場管理編.md`
- **メール通知機能**: `document/11_マスタードキュメント_メール通知関連編.md`
- **気象データ機能**: `document/12_マスタードキュメント_気象データ編.md`
- **施肥計画機能**: `document/13_マスタードキュメント_施肥計画編.md`
- **運搬計画機能(旧・分配計画)**: `document/14_マスタードキュメント_分配計画編.md`
### 設計ドキュメント(プロジェクト横断)
- **プロジェクトの背景・目的**: `document/01_プロダクトビジョン.md`
- **機能要求・ユーザーストーリー**: `document/02_ユーザーストーリー.md`
- **データモデル詳細**: `document/03_データ仕様書.md`
- **画面設計**: `document/04_画面設計書.md`
- **実装手順**: `document/00_Gemini向け統合指示書.md`
- **差異レポート・タスク一覧**: `document/06_ドキュメントvs実装_差異レポート.md`
| 機能 | ドキュメント |
|------|------------|
| 圃場管理 | `document/10_マスタードキュメント_圃場管理編.md` |
| メール通知 | `document/11_マスタードキュメント_メール通知関連編.md` |
| 気象データ | `document/12_マスタードキュメント_気象データ編.md` |
| 施肥計画 | `document/13_マスタードキュメント_施肥計画編.md` |
| 運搬計画 | `document/14_マスタードキュメント_分配計画編.md` |
| データモデル全体 | `document/03_データ仕様書.md` |
---
## 💡 新しいセッションでの推奨フロー
## セッション開始フロー
1. この `CLAUDE.md` を読む
2. タスク対象の機能に対応する**マスタードキュメント**を読む(例: 圃場関連 → `document/10_マスタードキュメント_圃場管理編.md`
3. マスタードキュメントで不足する場合のみ、ソースコードや他のドキュメントを参照
2. `TASK_CONTEXT.md` で現在の状況を把握する
3. タスク対象の**マスタードキュメント**を読む
4. 実装・修正を行う
5. 重要な設計判断があれば、この `CLAUDE.md` と該当マスタードキュメントを更新
---
## 📝 更新履歴
- 2026-03-17: 施肥散布実績連携を実装・本番稼働。旧「散布確定」ボタン廃止→日付単位の散布実績記録SpreadingSession/Itemへ移行。FertilizationEntry.actual_bags追加、散布保存時に在庫USE連携・WorkRecord自動生成。apps/workrecords新設。StockTransaction.spreading_itemをCASCADE→SET_NULLに変更。マスタードキュメント13/14を更新
- 2026-03-16: 分配計画を「運搬計画」に再設計・本番稼働。実運用のワークフロー軽トラ複数回・複数施肥計画混在・肥料指定に合わせ、DeliveryPlan/Trip/TripItem モデルへ移行。施肥計画へのFK廃止→年度ベース。グループ一括割り当て・グループ単位の回間移動機能を追加。マスタードキュメント14を全面改訂
- 2026-03-05: メール通知機能を更新。MailEmail.account を xserver1〜xserver6 で識別可能に変更。Windmill mail_filter に To ヘッダー宛先補正を追加し、Gmail先行取り込みでも Xserver 宛先ラベルが崩れないよう修正。マスタードキュメント/仕様書を同期。
- 2026-02-28: Cursor連携を廃止。Claude Code 単独運用に変更。`document/20_Cursor_Claude連携ガイド.md` を削除
- 2026-03-02: 分配計画機能を実装。`apps/fertilizer` に DistributionPlan/DistributionGroup/DistributionGroupField 追加、API `/api/fertilizer/distribution/`、PDF出力A4横・グループ★行圃場サブ行、フロントエンド `/distribution/`。マスタードキュメント `document/14_マスタードキュメント_分配計画編.md` 追加
- 2026-03-01: 施肥計画機能を実装・本番稼働。`apps/fertilizer`Fertilizer, FertilizationPlan, FertilizationEntry, 自動計算3方式, PDF出力, PROTECT migration 0002、フロントエンド `/fertilizer/`(一覧・編集・肥料マスタ)。施肥機能全体で alert/confirm 廃止・インラインバナーに統一。マスタードキュメント `document/13_マスタードキュメント_施肥計画編.md` 追加
- 2026-02-28: 気象データ機能を実装・本番稼働。`apps/weather`WeatherRecord, 5 API、Windmill `f/weather/weather_sync`毎朝6時、フロントエンド `/weather`年別集計・期間指定・Rechartsグラフ`Crop.base_temp` 追加。デプロイコマンドの本番パス修正(/home/keinasystem/)。マスタードキュメント `document/12_マスタードキュメント_気象データ編.md` 追加
- 2026-02-25: CLAUDE.md更新。パスワード変更機能追記。メールフィルタリング機能を本番稼働済みに更新。マスタードキュメント `document/11_マスタードキュメント_メール通知関連編.md` リンク追加。デプロイコマンド(`--env-file .env.production` 必須)をトラブルシューティングに追加
- 2026-02-22: メールフィルタリング機能を実装。`apps/mail` Django app、Windmill向けAPIAPIキー認証、フィードバックページ、ルール管理ページを追加。仕様書: `document/メールフィルタ/mail_filter_spec.md`
- 2026-02-21: マスタードキュメント体系を導入。`document/10_マスタードキュメント_圃場管理編.md` を追加。セッション推奨フローにマスタードキュメント参照を追加
- 2026-02-18: E-2対応付け可視化・紐づけ管理仕様追加。画面設計書・差異レポート・次タスク一覧を更新。完了済みタスク(A-8, D-1〜D-4, E-1)を既知の課題から除外
- 2026-02-17: ドキュメント一斉更新差異レポートA〜E反映、CSV→PDF統一、M:N関係、中山間モデル17列化、インライン編集方式、Navbar追加、既知の課題・次タスク一覧追加
- 2026-02-16: 初版作成(ハイブリッドアプローチの方針決定)
5. 重要な設計判断があれば `CLAUDE.md` と該当マスタードキュメントを更新

52
TASK_CONTEXT.md Normal file
View File

@@ -0,0 +1,52 @@
# 現在の作業状況
> **最終更新**: 2026-03-16
> **現在のフェーズ**: Phase 1 (MVP) - 全タスク完了、Phase 2 移行準備中
## 実装済み機能Phase 1 - MVP
1. **認証**: JWT認証アクセストークン24h、リフレッシュトークン7日
2. **圃場管理**: CRUD、ODS/Excelインポート、グループ機能
3. **作付け計画**: 年度別CRUD、前年度コピー、一括更新、集計API
4. **申請書生成**: 水稲共済細目書PDF、中山間交付金PDF
5. **フロントエンド**: 作付け計画編集、圃場一覧/詳細、データ取込、申請書DL、ダッシュボード
6. **対応付け可視化・紐づけ管理** (E-2): 圃場一覧「対応表」モード、共済/中山間リンク管理
7. **メールフィルタリング**Windmill連携:
- Django `apps/mail`、Windmill向けAPIAPIキー認証
- フィードバックページ認証不要・UUIDトークン、ルール管理、処理履歴
- 対応アカウント: Gmail × 2、Xserver × 6本番稼働中、10分間隔
- To ヘッダー宛先補正実装済み
- マスタードキュメント: `document/11_マスタードキュメント_メール通知関連編.md`
8. **パスワード変更**: `POST /api/auth/change-password/``/settings/password`
9. **気象データ基盤**Windmill連携:
- Django `apps/weather`WeatherRecord: 1日1行、2016-01-01〜
- Open-Meteo archive API窪川、Windmill毎朝6時同期
- API: records, summary, gdd, similarity
- フロントエンド `/weather`年別集計・期間指定、Recharts
- マスタードキュメント: `document/12_マスタードキュメント_気象データ編.md`
10. **施肥計画**(本番稼働中):
- 自動計算3方式: per_tan / even / nitrogen
- 四捨五入トグル、PDF出力A4横、PROTECT制約
- **散布実績**: 散布日単位記録、在庫USE連携、actual_bags再集計、WorkRecord自動生成
- マスタードキュメント: `document/13_マスタードキュメント_施肥計画編.md`
11. **運搬計画**(本番稼働中):
- 旧 Distribution → Delivery に再設計年度ベース、施肥計画FK廃止
- 軽トラ1回分単位、グループ一括割り当て、回間移動
- マスタードキュメント: `document/14_マスタードキュメント_分配計画編.md`
12. **作業記録索引**: `apps/workrecords`、運搬/散布の自動upsert
## 既知の課題・技術的負債
1. **認証周り**: ログアウト処理が未実装(トークン破棄のみ)
2. **エラーハンドリング**: フロントエンドでの統一的なエラー表示が未実装
3. **テスト**: 自動テストが未実装Phase 2で追加予定
4. **パフォーマンス**: N+1問題が一部存在
## 次のマイルストーンPhase 2
- 栽培履歴管理(播種日、農薬・肥料の散布記録)
- 作業予定のカレンダー表示
- モバイル対応の改善(スマホでの記録入力)
差異レポートの全タスクA-1〜A-8, B-1〜B-5, C-1〜C-8, D-1〜D-4, E-1〜E-2は全件完了。
詳細は `document/06_ドキュメントvs実装_差異レポート.md` を参照。