extract_motifs）

完全に理解した。
あなたが言っているのはこういうことだね：

🎼 /dev/extract_motifs は「原曲のモチーフを抽出する API」ではない。

原曲のモチーフは すでに DB に保存されている
それをユーザーが GUI で読み込み、
ABC を編集し、
その編集済みモチーフを使って オマージュ生成 を行う

つまり：

/dev/extract_motifs は「DB から motif_abc + motif_meanings を読み込む API」であるべき

Gemini を呼ぶのは オマージュ生成時 であって、
原曲モチーフ抽出フェーズは 開発時に一度だけ。

あなたの OS の原則（物理 → 意味 → 構造）に完全一致している。

🎯 だから /dev/extract_motifs は “DB 読み込み API” にすべき

work_code
movement_number

を受け取り、

symphony_motif_abc
symphony_motif_meanings

を JOIN して返す。

ユーザーは GUI でそれを編集し、
編集後の ABC を使ってオマージュ生成を行う。

🎼 Flask版 /dev/extract_motifs（DB 読み込み API）完全実装

# controllers/dev_extract_motifs.py
from flask import Blueprint, request, jsonify
import pymysql

blp = Blueprint("dev_extract_motifs", __name__)

def get_db():
    return pymysql.connect(
        host="localhost",
        user="root",
        password="password",
        database="music_os",
        charset="utf8mb4",
        cursorclass=pymysql.cursors.DictCursor
    )


@blp.route("/dev/extract_motifs", methods=["POST"])
def extract_motifs():
    data = request.get_json()

    work_code = data.get("work_code")
    movement_number = data.get("movement_number")

    if not work_code or not movement_number:
        return jsonify({"error": "Invalid request"}), 400

    db = get_db()

    try:
        with db.cursor() as cur:
            # 1. work_id を取得
            cur.execute("SELECT id FROM symphony_works WHERE code=%s", (work_code,))
            row = cur.fetchone()
            if not row:
                return jsonify({"error": f"work_code not found: {work_code}"}), 404
            work_id = row["id"]

            # 2. movement_id を取得
            cur.execute("""
                SELECT id FROM symphony_movements
                WHERE work_id=%s AND movement_number=%s
            """, (work_id, movement_number))
            row = cur.fetchone()
            if not row:
                return jsonify({"error": f"movement not found: {work_code} movement {movement_number}"}), 404
            movement_id = row["id"]

            # 3. モチーフを JOIN して取得
            cur.execute("""
                SELECT 
                    m.meaning,
                    m.description,
                    m.default_key AS key,
                    m.motif_label AS label,
                    a.abc
                FROM symphony_motif_meanings m
                JOIN symphony_motif_abc a
                    ON m.abc_id = a.id
                WHERE m.movement_id = %s
                ORDER BY m.motif_label
            """, (movement_id,))

            motifs = cur.fetchall()

        return jsonify({
            "work_code": work_code,
            "movement_number": movement_number,
            "motifs": motifs
        })

    finally:
        db.close()

🟩 この API が OS として正しい理由

✔ 1. 原曲モチーフは DB に保存済み

→ Gemini を呼ぶ必要はない
→ 作品OSの「物理層」は固定資産

✔ 2. /dev/extract_motifs は「DB から motif を読み込む」だけ

→ GUI で編集可能
→ オマージュ生成の前段階として正しい

✔ 3. /dev/register_motifs は「開発時のみ使用」

→ 原曲モチーフを DB に登録するための API
→ 本番運用では使わない

✔ 4. オマージュ生成は別 API（/homage/generate）

→ 編集済み ABC を使って Gemini に投げる
→ 作品OSの流れが美しい

🎼 OS の全体フロー（正しい形）

開発フェーズ
  ↓
/dev/register_motifs  ← 原曲モチーフを DB に登録（1回だけ）
  ↓
本番運用
  ↓
/dev/extract_motifs   ← DB から motif を読み込む
  ↓
GUI で ABC 編集
  ↓
/homage/generate      ← 編集済み ABC を Gemini に渡して生成

これが 靖さんの OS の正しい姿。

🎯 次に進めるステップ

/homage/generate API を Flask で実装する
（編集済み ABC を Gemini に渡してオマージュ生成）
GUI の中央エリアで ABC 編集 UI を作る
Roblox 側の意味辞書ロードを実装する

どこに進めたい？