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

21 Commits

Author SHA1 Message Date
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
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
c675b7b7ae Move all fertilization entries on variety change 2026-04-05 18:42:09 +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
865d53ed9a 仕様書に追記しました。更新先は 施肥散布実績連携変更実装仕様.md です。 
今回追加した内容は主にこの5点です。

FertilizationEntry.actual_bags の追加
SpreadingSessionItem 保存・更新・削除時の actual_bags 再集計ルール
copy_from_previous_year で actual_bags があれば次年度 bags 初期値に使う方針
施肥計画一覧・編集画面での 計画値 / 実績値 併記
RESERVE = bags、USE = actual_bags の併存整理
受け入れ条件にも、

actual_bags が再集計されること
計画値と実績値の両方が見えること
前年度コピーで actual_bags を使えること
を追加しています。
今回は仕様書更新のみで、コード変更やテストはしていません。必要なら次に、この内容をマスタードキュメント側へ反映します
 2026-03-17 17:24:25 +09:00
Akira
c9ae99ebc8 CODEX版 
昨日運んだ肥料を散布してきました。
それで、今は施肥計画に「散布確定」ボタンがあるのですが、それだと実態に合わない事がわかりました。
実際には運搬計画を元に、運んだ肥料を散布します。
順序は、運搬計画の1回目2回目などの順序には関係がなく
運搬計画のすべての中から、全部または一部の圃場に対して散布します。
散布中に、運搬計画から実際の散布袋数が変更になる場合があるので、変更に対処できなければなりません。。散布は日付単位で行い、その日付を元に作業記録が自動的に作成されるようにしたいです。
運搬計画にも日付をつけたので、それも作業記録が自動的に作成されるようにしたいです。

以上のような感じで、変更実装仕様を作成してもらえますか？
 2026-03-17 16:26:41 +09:00
Akira
e3c21d6e81 ConfirmSpreadingModal の改善点: 
groupedEntries（肥料別リスト表示）→ layout（圃場×肥料のマトリクス表）に変更 ✅
施肥計画編集画面と同じ「圃場名 / 面積(反) / 肥料列... / 合計」のテーブル構造に統一 ✅
各セルに計画値ラベル + 実績入力欄を縦並び ✅
列合計（肥料別）・行合計（圃場別）・総合計を追加 ✅
計画情報サマリーカード（年度・品種・圃場数・肥料数）を追加 ✅
操作ガイド（sky色バナー）を追加 ✅
モーダル幅を max-w-4xl → max-w-[95vw] に拡大（マトリクス表に合わせて） ✅
ドキュメント更新:

document/13_マスタードキュメント_施肥計画編.md — 在庫引当・散布確定・確定取消 API を追記 ✅
改善案/在庫管理機能実装案.md — 微修正 ✅
 2026-03-15 13:48:48 +09:00
Akira
42b11a5df8 在庫管理 Phase 1.5（引当・散布確定）の設計を追記し、CODEX指示書を更新 
- 在庫管理機能実装案.md: セクション23（引当・散布確定ワークフロー）を追加
- CODEX.md: Phase 1完了を受け、Phase 1.5実装指示に全面書き換え

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-03-14 17:29:05 +09:00
Akira
67d4197b7f 在庫管理機能実装案をレビュー反映し、CODEX実装指示書を追加 
- StockTransaction から冗長フィールド除外（unit, reference_type/id, created_by, inventory_count）
- フロントエンド画面構成を変更（入出庫登録をモーダル化、マスタ管理をタブ統合）
- レビュー記録セクション22を追加
- CODEX.md: Phase 1 実装指示書を作成（モデル・API・画面の詳細仕様）

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-03-14 15:03:09 +09:00
Akira
1b619c44a0 在庫管理機能実装案.md に ## 21. 補足: 外部サブスクLLM活用案 を追記しました。 
内容は、恵菜システム自身は LLM API を呼ばず、調査用プロンプトを提供する 調査手順を表示する LLM回答を貼り付けてフォームへ反映する という実装案です。肥料用・農薬用のプロンプト例、画面イメージ、貼り付け結果の取り込み方式、メリットと注意点まで入れています。

今回は文書更新のみで、コード変更やテストはしていません。必要なら次に、この 貼り付け結果をフォームへ反映 するための入力フォーマット仕様や、画面ワイヤー案まで具体化できます。
 2026-03-13 18:29:03 +09:00
Akira
f1512febde 在庫管理機能実装案.md に、電気炉さい ミネラルホウ素 リン酸グアノ も追記しました。 
追加した内容は、各資材についての袋表示・保証票ベースの情報、実装上の扱い、alias の例です。あわせて最後のまとめも更新して、5件を次の3パターンに整理しました。

現場名と保証票名が違う: 仁井田米有機, 土佐勤農党, 電気炉さい
現場名と表示名がほぼ一致する: リン酸グアノ
公式マスタよりローカル資材管理向き: ミネラルホウ素
今回は文書更新のみで、コード変更やテストはしていません。必要なら次に、この5件を前提にした MaterialAlias の Django モデル案まで具体化します。
 2026-03-13 13:50:24 +09:00
Akira
776a269d6d 在庫管理機能実装案.md に ## 18. 補足: 肥料公式データ同期・あいまい検索案 を追記しました。 
内容は、普通肥料を主対象に公式データをローカルDB化し、検索時はローカル検索、24時間超過時だけ裏で差分同期する という方針です。FertilizerOfficialMaster のテーブル案、既存 Fertilizer との紐づけ、検索API、同期ジョブ、特殊肥料は手入力併用にする考え方まで入れています。

今回は文書更新のみで、コード変更やテスト実行はしていません。必要なら次は、この18章をもとに models.py レベルの実装草案まで起こせます。
 2026-03-13 13:26:18 +09:00
Akira
1425094107 在庫管理機能実装案.md に、## 17. 補足: 農薬公式データ同期・あいまい検索案 を追記しました。 
今回追加したのは、ローカルDBで即検索しつつ、24時間以上経過時だけ裏で差分同期する 方式の具体化です。PesticideOfficialMaster と OfficialDataSyncStatus のテーブル案、検索API、同期ジョブ、差分更新ルール、フロントの再読込挙動、失敗時フォールバックまで入れてあります。

文書更新のみで、コード変更やテスト実行はしていません。必要なら次に、この章をそのまま実装に落として、Django モデル案と API 仕様書を作れます。
 2026-03-13 13:22:05 +09:00
Akira
f74dc4c4b7 在庫管理機能実装案 2026-03-13 13:13:40 +09:00