了解した。
ここまでの議論で あなたが求めている「データ項目サマリ」の形式 が完全に固まった。
あなたの言う通り、
- CRUD 分類は不要
- 「入力か」「出力か」「両方か」だけで十分
- くどい説明は不要
- 必要なのは アプリの“永続データ項目”の一覧
- そして その項目がコード全体でどう使われたか（入力／出力）
これを 最小・明快・実用的 にまとめるための「継続メモ（正式仕様）」をここに書く。
◆ 継続メモ：Flask コード生成後に行う “Data Items Summary” の正式仕様
1. 目的
AI が生成した Flask コードから、
アプリ固有のデータ項目（業務データ名）だけを抽出し、
それが入力か出力かを一覧化する。
これにより：
- 参照の整合性
- 名称の永続性
- データ構造の安定性
を自動的に確保する。
◆ 2. 抽出対象（data-items）
● 抽出するもの（意味のあるデータ名）
- API 入力名
- API 出力名
- DB カラム名
- モデルフィールド名
- JSON キー名
- URL パラメータ名
- サービス層の引数名（永続データを受け取るもの）
- 業務ロジックで意味を持つ変数名（image_id, user_id, title, content など）
● 抽出しないもの
- ローカル変数（i, j, k, tmp など）
- 一時変数
- フレームワークの構造名（request, jsonify, Blueprint など）
- その場限りの内部変数
◆ 3. 分類方法（CRUD ではなく、もっとシンプルに）
● 入力
- 外部から受け取る
- DB を参照するために使う
- API のパラメータになる
● 出力
- 新しく生成する
- DB に書き込む
- API のレスポンスとして返す
● 入力＋出力
- 入力として受け取り
- 出力として返す
- DB で読み書き両方する
◆ 4. 出力形式（最終的に AI が返す形）
★ 必要最小限で、くどくない形式
[Data Items Summary]
■ image_id
- 用途: 画像を識別するキー
- 区分: 入力＋出力
- 出現箇所:
- /upload（出力）
- /extract（入力）
- /view（入力）
- /api/landmarks（入力）
■ landmarks
- 用途: 抽出されたランドマーク配列
- 区分: 出力
- 出現箇所:
- extract_service（出力）
- /api/landmarks（出力）
ポイント
- 短い
- 必要な情報だけ
- CRUD の説明はしない
- 入力／出力／両方 のみ
- 用途（1行）
- 出現箇所（簡潔）
これがあなたの求めていた「くどくない、実用的な刑法IR」。
◆ 5. 運用方法（実際の使い方）
- あなたが「Flask の ○○ を書いて」と依頼
- 僕が Flask コードを生成
- あなたが「ここまでの data-items を一括抽出して」と言う
- 僕が このチャットに存在するコード全体 を解析し、
上記フォーマットで Data Items Summary を返す
これで：
- あなたはコード生成に集中できる
- 僕は後から構造を抽出して整合性を保証する
- IR を手で書く必要がない
- Delphi / Flask / Roblox どれでも共通化できる
◆ 6. 次のステップ
この仕様はもう完成しているので、
あとは 実際に Flask コードを生成して、
この Data Items Summary を一度やってみるだけ。
いつでも言ってくれれば、
コード生成 → 一括抽出 の流れをすぐ実行できる。