name: datalog-migration-skill description: DataLog のスキーマ / パイプラインバージョンが breaking 上昇したときに、旧 datalog-store の common / local 両方 (監査クエリ・IDB ルール) を新 breaking 版へ書き直すための移行手順。AI エージェントが datalog_migration_check の出力を読み、新スキーマで等価書き直し → datalog_query_create / datalog_idb_create で新ファイルへ登録するワークフローを提供する。

datalog-migration

スキーマ / パイプライン構造の breaking 境界 (例: 0.0 → 0.1) が上がったとき、datalog-store 配下の common / local 両ファイル (監査クエリ・IDB ルール) を新 breaking 版へ書き直すための skill。

命名規約 (breaking bump 時の前提)

datalog-store/ 配下のファイルは common / local 両方に breaking tag (<major>.<minor>、ゼロ詰め無し) を埋め込む統一命名。

common: <base>.<breaking>.json         例: query.0.0.json / idb.0.0.json
local : <base>.local.<breaking>.json   例: query.0.0.local.json / idb.0.0.local.json

<breaking> は package.json の version の major.minor 部分。patch は除外 (後方互換 patch bump ではデータ書き換え不要)。

breaking bump (0.0 → 0.1) 時に発生する変化:

旧:                          新:
query.0.0.json           →   query.0.1.json         (common、PR で書き換え)
query.0.0.local.json     →   query.0.1.local.json   (local、本 skill で書き換え)
idb.0.0.json             →   idb.0.1.json           (common、PR で書き換え)
idb.0.0.local.json       →   idb.0.1.local.json     (local、本 skill で書き換え)

旧 <breaking> のファイルは並列に残せる (datalog_migration_check で current=false として stale 判定される)。書き直しが完了したら git rm 可。

宣言的 migration DSL を運用するのではなく、AI エージェントが旧 query/IDB の pseudocode と query 文字列を読み、現行スキーマ向けに等価な定義を再構築する方針 (運用負荷とロックインを避ける)。

発動条件

以下のいずれかで発動。

ワークフロー

1. datalog_migration_check                  # 旧 breaking 版の datalog-store/*.local.json + 中身を取得
2. datalog_schema                           # 現行 breaking 版のスキーマ・概念・属性を取得
3. datalog_idb_list                         # 現行 IDB ドメイン述語を再確認 (IDB ファースト)
4. AI が旧 query / IDB を新スキーマで等価書き直し
5. ユーザー承認 (差分提示)
6. datalog_idb_create / datalog_query_create で新 breaking 版に登録 (status='activating' で書き込まれる)
7. datalog_query で :in $ % 含むクエリで動作確認 (試作中の rule は cache に注入されないため、
   ad-hoc クエリで先にアトミック述語の展開を確認)
8. datalog_idb_update {status: 'active'} / datalog_query_update {status: 'active'} で active へ昇格
9. 検証: datalog_query_run で結果が旧と整合するか確認
10. 完了後、ユーザー承認のうえ datalog_reset fullReset=true で現行 breaking 版 local を再構築
   (旧 breaking 版は触られない — 手動で rm したい場合は別途)

書き直しの判断軸

1. 述語名・概念名の rename

旧スキーマで node/name = "settled" を参照していたクエリを新スキーマの node/name = "決済済み" に置換する、といった単純 rename は、旧 query 文字列の文字列置換で対応可能。 ただし pseudocode (日本語) を読み、意味が一致するか必ず確認する。

2. 投入規約 (datom 構造) の変更

例: 「概念 subtype を中間ノード経由で attach していたが、直接 is_attribute_of で張る方式に変更」のような構造変更は、旧 query の where 節を 1〜2 行畳む形になる。 新スキーマの attachmentPolicy (datalog_schema response) と idbUsageGuide を読み、現行のアタッチ規約に合わせて書き直す。

3. IDB ファースト

旧 query が [?det "is_belong_to" ?deal] [?det "is_a" ?c_det] [?c_det "node/name" "明細"] ... のようにアトミック述語で展開されていたら、現行 IDB に同等のドメイン述語 (is_detail_of 等) があれば畳んで :in $ % を付ける。 無ければ先に datalog_idb_create で IDB を整備する (順序逆は技術負債)。

4. 削除された述語・概念

旧 query が参照していた述語が現行で削除されている場合、書き直しではなく drop が妥当な場合もある。pseudocode の意図がもう存在しない場合はユーザーに削除可否を確認する。

出力フォーマット (AI → ユーザー)

各 stale entry について、以下のサマリをユーザーに提示してから書き戻す:

## migration plan: <stale ファイルパス>
- source: query.0.0.local.json (旧 breaking)
- target: query.0.1.local.json (現行 breaking)
- 移行対象: N 件 (queries) / M 件 (rules)

### 1. <id>
- 旧 query: ...
- 旧 pseudocode: ...
- 新 query: ...
- 変更理由: <rename / 投入規約変更 / IDB 畳み込み / 削除提案 ...>

ユーザー承認後、各 entry を datalog_query_create (または datalog_idb_create) で書き戻す。書き戻し先は 現行 breaking 版 (query.<breaking>.local.json / idb.<breaking>.local.json)。CRUD ツールは現行 breaking 版にのみ書き込む (旧 stale ファイルは触らない)。

完了確認

注意事項

関連