akira/keinasystem
1
0
Fork 0
Code Issues 7 Pull Requests Actions Packages Projects Releases Wiki Activity
165 Commits 1 Branch 0 Tags
main
Commit Graph

165 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
Akira
8de1ae70aa .codex .mcpを除外 2026-04-09 20:40:30 +09:00
akira
3901caf668 docs: reflect todo spec review feedback 2026-04-09 16:36:19 +09:00
akira
5f58c2c686 指摘を反映して 改善案/TODO管理機能仕様書案.md を更新しました。 
主な修正は、Todo.year の追加、TodoCrop / TodoVariety の具体定義追加、priority の 1000 刻み再採番ルール明記、plan_links がある場合だけ対象圃場整合性を検証する形への明確化、levee_work を「MVP では計画リンクなしの work_type」として整理、plan_type + plan_id を Serializer で各 FK に変換する方針追記、admin.py と migrations の追加、見出し階層の修正です。

あわせて、実績連携フラグ名は should_link_record に寄せました。まだコミットはしていないので、必要ならこの修正分もそのままコミットします。
 2026-04-09 16:34:30 +09:00
akira
83525c2f59 docs: add todo management spec draft 2026-04-09 16:27:42 +09:00
akira
627d7e4f59 docs: tighten pesticide ingredient limit consistency 2026-04-09 15:52:29 +09:00
akira
9059b2b51e 仕様書を更新しました。更新先は 農薬散布管理編.md です。 
- 有効成分総使用回数の集計方式を COUNT(DISTINCT SprayEvent.id) に変更
  （農薬取締法上「1回の散布=1回の使用」の解釈に準拠、1イベント=1回で統一）
- PesticideIngredientLimit に「同一成分・同一作物であれば製品が異なっても上限値は同一」の注記を追加
- 設計判断 #5 を更新：有効成分も製品使用回数と同様に COUNT(DISTINCT SprayEvent.id) で集計する根拠を記載
- 設計判断の番号を整理（#7〜#10 → #8〜#11）
 2026-04-09 15:44:44 +09:00
akira
7d2eb1ebe2 Findings 
同一イベント内で同じ有効成分を含む複数製品を使った場合、総使用回数を過少計上します。
18_マスタードキュメント_農薬散布管理編.md:39 (line 39) では「同一有効成分を含む複数製品は合算カウント」と定義していますが、集計式は 同:251 (line 251) の COUNT(DISTINCT SprayEvent.id) です。これだと 1 回の散布で MEP剤A と MEP剤B を同時使用したケースが 2 回ではなく 1 回になります。1イベント=1回 は製品単位には合っても、有効成分の「複数製品合算」とは衝突しています。

SprayEventResolvedField を正源にしたはずなのに、設計判断がまだ旧仕様のままで矛盾しています。
集計の正源は 同:232 (line 232) で SprayEventResolvedField.crop_name_snapshot に統一されていますが、設計判断では 同:599 (line 599) に「作付け計画（Plan）と照合」と残っています。さらに 同:602 (line 602) では削除したはずの crop_snapshot / variety_snapshot をまだ保持対象として書いています。実装者がここを読むと旧設計に引っ張られます。

製品使用回数も、同一イベント内の重複明細をどう扱うかが未定義で、式とモデルが噛み合っていません。
集計式は 同:239 (line 239) の COUNT(DISTINCT SprayEvent.id) ですが、明細モデルには 同:213 (line 213) 以降で event + pesticide の一意制約がありません。つまり同じ農薬を同一イベントに 2 行入れられる設計なのに、集計では 1 回に潰れます。仕様として「同一イベント内で同一農薬は1回しか登録できない」を明記して一意制約を持たせるか、重複明細の意味を定義した方が安全です。

大筋ではかなり良くなっていて、特に「作物単位での法的管理」と「圃場ごとの正源を SprayEventResolvedField に寄せた」方向は明快でした。上の3点だけ揃えると、実装時の解釈ぶれがかなり減ります。
 2026-04-09 15:16:45 +09:00
akira
3e2942b479 変更内容 
集計ロジックの明確化（農薬取締法の要件を明示）:

集計単位の説明に「農薬取締法上、使用回数は作物単位で管理する義務がある」を明記
グループ内に複数作物が混在する場合の動作を明示 → 同一イベントの農薬が水稲・大豆それぞれの回数に +1 カウントされる
集計の正源は SprayEventResolvedField.crop_name_snapshot（圃場ごと）に統一
不要フィールドの削除:

SprayEvent.crop_snapshot / variety_snapshot を削除（役割が SprayEventResolvedField に統合されたため）
APIレスポンス例からも除去
集計式の精緻化:

「1イベント = 1回」のカウント原則を明示（COUNT(DISTINCT SprayEvent.id)）— グループ内に圃場が何筆あっても1散布作業は1回
 2026-04-09 15:11:15 +09:00
akira
70fe3824b3 docs: refine pesticide management spec 2026-04-09 14:56:21 +09:00
akira
10f2b6f77f 農薬散布記録作成 2026-04-09 14:54:12 +09:00
akira
6dfcd0be06 テスト結果 2026-04-07 11:47:25 +09:00
akira
1371eef648 必須の指摘を修正しました。更新したのは Navbar.tsx です。 
修正内容は2点です。

/fertilizer/masters を 施肥計画 のアクティブ判定から除外
運搬計画 のアイコンを FlaskConical から Truck に変更
確認は docker compose exec -T frontend npx tsc --noEmit で通っています。今回のレビューで必須だった重複アクティブはこれで解消しています
 2026-04-07 11:19:05 +09:00
akira
ac0bc7b6a9 マスタードキュメント化しました。追加したのは 17_マスタードキュメント_ナビゲーション再編編.md です。 
内容は、今回の仕様案をそのまま移すだけでなく、

なぜこの再編が必要になったか
なぜ マスター / 帳票・連携 という分類にしたか
URL とメニューをどう切り分けるか
Phase 1〜3 をどう進めるか
まで、長期参照向けに整理してあります。
改善案/ナビゲーション再編仕様書.md は実装向け詳細、今回追加したマスタードキュメントは長期保管用、Issue #13 は議論の背景、という役割分担にしています。必要なら次に、既存のどこかからこの 17_...md へ参照リンクを足します。
 2026-04-07 11:12:19 +09:00
akira
1c474e9692 仕様書を更新しました。更新先は ナビゲーション再編仕様書.md です。 
反映した内容は次の通りです。

5-3 に、初期実装ではブラウザ標準の Tab 移動を基本とすることを追記
5-3 に、矢印キーでの項目間移動は Phase 1 の必須要件外と明記
9 に、ドロップダウン展開後は Tab で各項目へ到達できることを追加
9 に、矢印キー移動は将来のアクセシビリティ強化項目として扱うと追記
これで、キーボード操作の範囲について実装者が迷いにくくなったはずです。
 2026-04-07 11:09:51 +09:00
akira
0cd90e61db 仕様書を更新しました。変更先は ナビゲーション再編仕様書.md です。 
今回入れた主な追記はこの3点です。

1-4 に Issue #13 との役割分担を追加
10-2 に NavGroup / NavItem の階層構造と match の位置づけを追加
10-3 に URL とナビゲーションの分離原則、Route Groups の扱い方を追加
これで、仕様書だけ読んでも実装方針が分かり、なぜそうしているかは Issue #13 にたどれる構成になりました。必要なら次に、10-2 のサンプル navGroups を今の分類に合わせてもっと具体化します。
 2026-04-07 11:01:44 +09:00
akira
8de27de335 第2版 2026-04-07 10:33:29 +09:00
akira
71b8258281 メニューの整理案 2026-04-07 10:01:02 +09:00
Akira
4516a74772 Fix sync_db.sh to run migrate after DB restore 
サーバーより新しいマイグレーションがローカルに存在する場合、
リストア後にmigrateを実行しないと500エラーになるバグを修正。

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-06 17:32:23 +09:00
Akira
a42ccb5cda Add local production test environment setup 
- docker-compose.local.yml: 本番Dockerfile使用・Traefikなし・ポート直接公開
- deploy_local.sh: ローカル環境のビルド・起動スクリプト
- sync_db.sh: サーバーDBダンプをローカルに取り込むスクリプト
- document/20_ローカルテスト環境.md: 手順ドキュメント

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-06 17:32:23 +09:00
akira
4a1db5ef27 #12 対応を入れました。 
畔塗記録 API に total_area_tan を追加して、一覧の各記録に「圃場数 / 面積合計」が出るようにしました。あわせて、作成・編集フォームの「対象圃場一覧」にも、選択中の合計面積を表示しています。主な変更は serializers.py、tests.py、page.tsx、index.ts です。

確認できたこと:

docker compose -f docker-compose.develop.yml exec backend python manage.py test apps.levee_work OK
docker exec keinasystem_frontend npm run build OK
まだコミットはしていません。必要ならこのままコミットして push します。
 2026-04-06 17:23:06 +09:00
akira
c90c6210e1 Add fertilization plan merge workflow 2026-04-06 16:49:44 +09:00
akira
c675b7b7ae Move all fertilization entries on variety change 2026-04-05 18:42:09 +09:00
akira
ae0249be69 Add allocation variety change history UI 2026-04-05 16:55:44 +09:00
akira
1d5bcc9dd6 Move rice transplant entries on variety change 2026-04-05 16:49:03 +09:00
akira
98814299cf Move unspread fertilization entries on variety change 2026-04-05 16:43:26 +09:00
akira
21fb2323eb Add plan variety change tracking 2026-04-05 16:32:57 +09:00
akira
5a9b6a053b 改善案/issue_3_計画始動後の作付け変更_調査.md#L428 (line 428) 
田植え計画 | 施肥と同様に対応 という決定表現が、下の詳細仕様と少しズレています。詳細では #L463 (line 463) 以降で「現時点では全件移動」と明記されているので、表も「現時点では全件移動、将来実績連携後に再設計」くらいに合わせた方が誤読されません。

改善案/issue_3_計画始動後の作付け変更_調査.md#L444 (line 444)
actual_bags = 0 は現行 services.py では null に丸められる は少し断定が強いです。現行の再集計ロジックでは未該当なら NULL になりやすい、という理解は良いのですが、将来だけでなくデータ補正や手動更新でも 0 が入り得ます。仕様書上は「未散布判定は NULL または 0 を未散布扱いとするかどうか」を明示した方が安全です。
 2026-04-05 14:09:48 +09:00
akira
429a98decb 改善案/issue_3_計画始動後の作付け変更_調査.md#L442 (line 442) 
旧 plan の当該エントリに対応する RESERVE を削除 という書き方は、現行実装とずれています。RESERVE はエントリ単位ではなく fertilization_plan 単位で全置換管理です。backend/apps/materials/stock_service.py (line 10) の通り、実装上は「旧 plan 全体の RESERVE を再生成」「新 plan 全体の RESERVE を再生成」と書かないと誤実装されやすいです。

改善案/issue_3_計画始動後の作付け変更_調査.md#L437 (line 437)
未散布判定を actual_bags is NULL にしているのは危険です。actual_bags は散布実績再集計の結果で、将来のロジック変更や部分散布時に 0 や端数が入る可能性がありますし、「未散布」と「部分散布」を同一扱いできません。backend/apps/fertilizer/models.py (line 72) を踏まえると、少なくとも「actual_bags is null または 0」「一部散布済みは移動不可 or 分割対象」と明文化した方が安全です。

改善案/issue_3_計画始動後の作付け変更_調査.md#L367 (line 367) と 改善案/issue_3_計画始動後の作付け変更_調査.md#L449 (line 449)
田植え計画を「施肥と同様」とまとめていますが、田植え計画には actual_bags に相当する実績概念がまだありません。backend/apps/plans/serializers.py (line 177) 現状では「全 Entry 移動」なのか「将来の実績連携を見越して未実施分のみ移動」なのかを切り分けて書く必要があります。今の書き方だと、施肥と同じ判定軸があるように読めます。

改善案/issue_3_計画始動後の作付け変更_調査.md#L461 (line 461)
actual_bags 集計ロジックは「影響なし」と言い切らない方がいいです。今回の方針なら大きな改修は不要ですが、前提は「同一年・同圃場・同肥料の行が複数計画にまたがって共存しないこと」です。これは仕様上の制約なので、「影響なし」ではなく「現方針では再利用可能。ただし重複行を作らないことが前提」と書くのが正確です。
 2026-04-05 14:07:59 +09:00
akira
4299c6eb4b 改善案No2 2026-04-05 14:00:50 +09:00
akira
8dd680e28a Update rice transplant plan spec document 2026-04-05 13:18:51 +09:00
akira
3eb2852b78 修正しました。 
原因は RiceTransplantEditPage.tsx の初期値セット用 useEffect で、新規作成時に isNew を条件にしていたため、反当苗箱枚数 を入力しても毎回デフォルト値で上書きされていたことです。これを seedlingBoxesPerTan === '' のときだけ初期値を入れるように直したので、今は手入力できるはずです。

あわせて、同じファイルで 面積(反) は toFixed(2) 表示に変更しました。反当苗箱枚数 は入力欄のまま 1 桁運用に寄せる前提で、表示系はご要望に近づけています。再読み込みしてもう一度画面操作してみてください。
 2026-04-05 12:23:22 +09:00
akira
5c2d17fe0a 大丈夫ではあるのですが、1本 migration が足りていませんでした。原因はこれです。 
0006 で seedling_boxes_per_tan を installed_seedling_boxes にリネーム
その結果、DB 上の field メタ情報には元の表示名が残る
モデル側では今 verbose_name='設置苗箱枚数'
Django がその差分を AlterField として検出
なので、出ていた 0009_alter_ricetransplantentry_installed_seedling_boxes.py は正当です。こちらで 0009_alter_ricetransplantentry_installed_seedling_boxes.py を追加しました。

次はこれで進めれば大丈夫です。

git pull でこの migration を server 側へ反映
docker compose exec backend python manage.py migrate
必要なら docker compose exec backend python manage.py makemigrations plans --dry-run --verbosity 3 で警告が消えたか確認
これで plans の未反映 migration 警告は消えるはずです。
 2026-04-05 12:17:04 +09:00
akira
182ef5d83d 該当エラーは直しました。 
frontend/src/app/rice-transplant/_components/RiceTransplantEditPage.tsx に Variety 型の import を追加して、find のコールバック引数に明示型を付けています。今回の Parameter 'variety' implicitly has an 'any' type はこれで解消するはずです。

そのままもう一度 npm run build を回してみてください。もし次の型エラーが出たら、続けて直します。
 2026-04-05 12:08:24 +09:00
akira
0131982c34 種子資材ベースへの切り替えを反映しました。 
frontend/src/app/rice-transplant/_components/RiceTransplantEditPage.tsx では、田植え計画の主選択を 品種 から 種子資材 に変更し、画面上は種子資材名だけで進めるようにしました。保存時だけ内部的に、その種子資材に紐づく Variety を解決して既存 API に送っています。候補圃場取得もその内部参照で動く形です。frontend/src/app/rice-transplant/page.tsx の一覧表示も 作物 / 品種 ではなく 種子資材 列に変更しました。

仕様書 document/16_マスタードキュメント_田植え計画編.md も 年度 × 種子資材 を軸にした説明へ更新済みです。確認できたのは Python 側の py_compile までで、フロントのビルド確認はまだしていません。Issue #2 にも今回の変更内容をコメント済みです。
 2026-04-05 12:04:36 +09:00
akira
491f05eee8 その判断で進めました。在庫管理を先に固めるように切り替えて、手元の実装もそちらを優先して直しています。 
今回入れたのは、在庫履歴の編集・削除対応と、種子資材を資材マスタ側で品種に直接結び付ける流れです。backend/apps/materials/views.py と backend/apps/materials/serializers.py で stock-transactions の更新を許可しつつ、計画や実績に紐づく履歴はロック扱いにしました。画面側は frontend/src/app/materials/page.tsx、frontend/src/app/materials/_components/StockOverview.tsx、frontend/src/app/materials/_components/StockTransactionForm.tsx を更新して、手動登録の入出庫履歴をあとから編集・削除できるようにしています。

あわせて frontend/src/app/materials/masters/page.tsx と frontend/src/app/materials/_components/MaterialForm.tsx で、種子 タブから品種を直接選んで紐付ける形にしました。重複を避けるため、作付け計画側の品種管理モーダル frontend/src/app/allocation/page.tsx から種子資材の紐付け UI は外しています。Issue #2 にもこの方針でコメント追記済みです。

確認できたのは python3 -m py_compile までで、フロントのビルドは frontend/node_modules が無いためまだ回していません。次はブラウザで在庫管理の操作感を確認してから、田植え計画側の細部を詰めるのがよさそうです。
 2026-04-05 11:43:03 +09:00
akira
a38472e4a0 品種ごとの種子在庫前提まで実装を進めました。 
主な変更は、seed 資材種別の追加と Variety.seed_material の導入です。backend/apps/materials/models.py、backend/apps/plans/models.py、backend/apps/plans/serializers.py で、田植え計画が作物在庫ではなく品種に紐づく種子資材の現在庫を参照するように切り替えました。マイグレーションは backend/apps/materials/migrations/0005_material_seed_type.py と backend/apps/plans/migrations/0008_variety_seed_material.py を追加しています。

画面側は、frontend/src/app/materials/page.tsx と frontend/src/app/materials/masters/page.tsx に「種子」タブを追加し、frontend/src/app/allocation/page.tsx の品種管理モーダルで品種ごとに種子在庫資材を設定できるようにしました。田植え計画画面 frontend/src/app/rice-transplant/_components/RiceTransplantEditPage.tsx も、苗箱数 列中心に整理し、種もみkg 列を削除、反当苗箱枚数 の列反映と ≈ / ↩ の四捨五入トグルを施肥計画寄りの操作感に寄せています。仕様書 document/16_マスタードキュメント_田植え計画編.md も更新済みです。

確認できたのは python3 -m py_compile backend/apps/materials/models.py backend/apps/materials/serializers.py backend/apps/plans/models.py backend/apps/plans/serializers.py backend/apps/plans/views.py までです。frontend/node_modules が無いためフロントのビルド確認はまだできていません。Issue #2 にも反映内容をコメント済みです。必要なら次にコミットします。
 2026-04-05 11:22:07 +09:00
akira
11b36b28a5 Issue #2 に最新の理解を記録し、その内容で仕様書と実装を修正しました。 
document/16_マスタードキュメント_田植え計画編.md は、「行ごとに保持するのは圃場の苗箱数」「列側に反当苗箱枚数を持つ」「種もみg/箱 は全体共通値」という前提に更新しています。コード側は backend/apps/plans/models.py と backend/apps/plans/serializers.py で計画ヘッダに seedling_boxes_per_tan を追加し、backend/apps/plans/migrations/0007_ricetransplantplan_seedling_boxes_per_tan.py も作成しました。画面は frontend/src/app/rice-transplant/_components/RiceTransplantEditPage.tsx を施肥計画寄りに組み直し、列単位のデフォルト反映と四捨五入、行ごとの苗箱数入力に寄せています。frontend/src/types/index.ts も合わせて更新済みです。

確認できたのはバックエンドの構文チェックまでで、python3 -m py_compile backend/apps/plans/models.py backend/apps/plans/serializers.py backend/apps/plans/views.py は通過しています。フロントのビルド確認まではこの環境では回していません。Issue #2 にも今回の反映内容をコメント済みです。
 2026-04-05 10:53:24 +09:00
akira
95c90dd699 Adjust rice transplant plan to store installed box counts 2026-04-05 10:26:14 +09:00
akira
9bcc5e5e21 butler2 と同じ issue テンプレートを設定しました。 
追加したのは bug.md、design.md、feature.md の 3 つで、内容とラベル指定も butler2 に揃えています。
 2026-04-05 08:16:37 +09:00
akira
0c57dd7886 Add rice transplant planning feature 2026-04-04 17:26:55 +09:00
akira
f236fe2f90 ソートできるようにしました。page.tsx 
畔塗画面の対象圃場一覧で、圃場 / 面積 / グループ / 品種 の各ヘッダーを押すと昇順・降順を切り替えられます。初期状態は 圃場名昇順 です。選択状態はそのまま維持されるので、並べ替えてもチェックが外れることはありません。

必要なら次に、ソートだけでなく検索欄も足せます。圃場数が多いなら検索もかなり効きます。
 2026-04-04 12:07:41 +09:00
akira
b7b9818855 feat: add levee work records 2026-04-04 11:32:26 +09:00
akira
c773c7d3b8 docs: add levee work master document 2026-04-04 11:13:11 +09:00
Akira
edd2f2a274 現状でコミット 2026-03-27 14:59:25 +09:00
Akira
00fd4a8cba 削除: データモデル詳細（145行）→ 「document/03_データ仕様書.md を参照」に集約 
移動: 実装状況・既知の課題・次のマイルストーン → TASK_CONTEXT.md へ
削除: 更新履歴（git log で追える）
圧縮: ディレクトリ構造、トラブルシューティング、作業パターンを要約
維持: 絶対制約、コーディング規約、デプロイコマンド、マスタードキュメントへのリンク
 2026-03-18 09:25:44 +09:00
Akira
13c21ed7de ローカル更新済み: 
13_マスタードキュメント_施肥計画編.md — 散布実績セクション整備、在庫連携・集計ルール・WorkRecord自動生成・前年度コピーのセクション追加、旧「散布確定モーダル」記述削除、型定義・ファイル構成・将来の拡張を更新
14_マスタードキュメント_分配計画編.md — 散布実績との連携・WorkRecord自動生成のセクション追加
CLAUDE.md — データモデル（SpreadingSession/Item, WorkRecord, actual_bags）追加、プロジェクト構造にfertilizer/workrecordsアプリ追加、実装状況に散布実績・作業記録索引を追記、更新履歴に2026-03-17エントリ追加
 2026-03-17 20:31:22 +09:00
Akira
daae1a42e5 散布実績: 名称未入力時のバリデーションエラーを追加 
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-03-17 20:05:36 +09:00
Akira
4e06318985 散布実績ページ: useSearchParamsをSuspense boundaryでラップ（本番ビルドエラー修正） 
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-03-17 20:03:16 +09:00
Akira
9f96d1f820 散布実績レビュー修正: バグ修正・仕様適合・デッドコード削除 
- 候補API: 運搬済みフィルタ(date IS NOT NULL)を追加。
  delivery_plan_id指定時は全明細表示、年度全体時のみ日付フィルタ適用
- StockTransaction.spreading_item: CASCADE→SET_NULL に修正（仕様7.3準拠）
- perform_destroy: SET_NULL対応でUSEを明示削除してからsession削除
- ConfirmSpreadingModal.tsx: 未使用のため削除
- FertilizerEditPage.tsx: 旧散布確定関連デッドコード全除去
  (isConfirmed/confirmedAt state, handleUnconfirm, 確定取消ボタン, 確定済みバナー)
- services.py: 未使用のto_decimal_or_zero削除

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-03-17 19:56:13 +09:00
Akira
140d5e5a4d 施肥散布実績機能を実装し運搬・作業記録・在庫連携を追加 2026-03-17 19:28:52 +09:00