うい。別途保管用なら、今まで決めた内容をまとめて**「Kaia 製品仕上げ前・共通点検票 v0.1」**として吐く。
今後事故が見つかったら、この点検票自体を育てる前提。

Kaia 製品仕上げ前・共通点検票 v0.1

目的

Kaia製品を完成・更新・UI統一する前後に行う共通点検。

基本方針：

• 誤検知は許容する。
• 見落としを避けることを優先する。
• 動作確認済み部分は不用意に変更しない。
• 「古い」「未使用に見える」「Standardと違う」だけでは削除・修正理由にしない。
• 判断できないものは推測せず保留する。
• 技術的に判断可能な事項はKaia側で処理し、Shamyueには製品判断・仕様衝突・実機確認など必要な事項だけを相談する。

判定：

• PASS — 問題なし、または意図された差異。
• WATCH — 気になる点あり。誤検知を含め追加確認する。
• BLOCK — 理解・解決するまで変更を進めない。

01. Socket / 製品間連携

確認対象：

• 現行socketとの互換性
• CNT-22等の現行contract
• 旧socket残存
• Counter Free等、特定grade/productへの直接参照
• 特定クラス・option・basename等への決め打ち
• provider / consumer双方の契約
• 必要functionの存在
• 返却データ構造
• grade-neutralになっているか
• 新旧socketの混在
• UI color socket
• issuance/state/evidence socket
• sibling pluginとの連携

重要：

新socketが存在するだけではPASSにしない。旧socketの残骸も検索する。

旧式を発見した場合、機械的な文字列置換はしない。
旧経路が何を取得していたか確認し、対応する現行contractへ移行する。

新contractに存在しない情報が必要なら勝手に追加せず相談する。

02. UI骨格

確認対象：

• Binder
• Refill
• selector
• 設定ボックス
• 見出し
• 入力欄
• ボタン
• ボックス寸法
• 横幅
• 縦位置
• 余白
• alignment
• Preview
• レスポンシブ

Standardとの差分は確認するが、

Standardと違う = 不具合

とは判定しない。

差異を以下へ分類する：

• grade差
• product差
• 古いUI
• 本当の欠落
• 将来用予約席

03. 状態表示

以下の表示方法・位置・意味を確認：

• Success
• Warning
• Error
• 未設定
• 無効
• LOCK
• 終了
• 使用中
• 空状態
• 条件不足
• 連携先不在

単なる文言統一だけではなく、

• 箱
• 強調方法
• 表示位置
• 状態の意味
• 操作との関係

まで確認する。

04. 操作フィードバック

確認対象：

• Save
• Apply
• Reset
• Delete
• Cancel
• Confirm
• 発行
• 解除
• 選択
• 作成
• Rename

操作後に、

「押せたのか？」
「保存されたのか？」
「何が変わったのか？」

が分からない状態になっていないか確認する。

05. 危険操作

確認対象：

• Reset
• Delete
• 上書き
• 発行
• LOCK解除
• irreversible action
• データ消去

必要に応じて：

• confirmation
• Cancel
• 誤クリック耐性
• Previewと確定処理の分離

を確認する。

06. Kaia Memoria住所 / Admin導線

確認対象：

• Kaia Memoria親メニュー
• 親がなければ作る
• 親があれば入居する
• 子メニュー
• plugin Settings link
• redirect
• form action
• GET navigation
• self-route
• admin.php移行
• options-general.php等の旧住所残存

住所変更後は、自製品内部の旧URLを横断検索する。

07. 外部プラグインへの導線

Auto Stop等、別プラグインへのrouteを確認。

自製品の住所変更時に、外部プラグインのURLまで一括置換しない。

外部routeは原則として別製品側の責任範囲。

08. Registry / Identity

確認対象：

• current Registry情報
• primary identity
• legacy ID
• CNT
• ROOT_ID
• socket ID
• Series
• Build
• Revision marker
• Registry同梱資料

原則：

新Registry番号になったことだけを理由に、既存内部IDを書き換えない。

既存IDがsocket/reference/compatibility keyとして使用されている可能性を確認する。

新Registry情報は必要に応じて外部同梱資料として保持する。

09. Grade境界

確認対象：

• Free
• Standard
• Creative
• その他grade

UI統一によって上位grade機能が下位へ漏れていないか確認する。

特に：

• capacity
• Refill数
• LOCK数
• HEX直接入力
• Design機能
• Stock
• 保存数
• 画像機能
• その他grade限定機能

共通UI骨格と製品機能境界を混同しない。

10. データ互換

確認対象：

• option名
• database
• 保存済み設定
• 既発行データ
• instance/sheet ID
• migration
• 旧バージョンからの更新

UIだけを変更したつもりで保存形式まで変更していないか確認する。

11. Binder / Refill

確認対象：

• Binder構造
• Refill構造
• capacity
• 購入権利
• LOCK
• 使用中状態
• selector
• 新規追加
• rename
• entitlement
• overflow
• grade別容量

未実装・開発途中の場合、先行して本体へ将来仕様を固定しすぎない。

12. Cross-product State

Counter / Timestamp / Serial / PDF等の状態受渡しを確認。

単に値を取得できるだけでなく、

送信側と受信側で状態の意味が一致しているか

を確認する。

13. Shortcodes

確認対象：

• instance/sheet ID追従
• Counter
• Timestamp
• Serial
• PDF
• 存在しない機能を表示していないか
• コピー内容
• shortcode出力互換

Kaia Memoria管理UIのShortcodesブロックは英語固定。
通常UIのi18n監査とは分離する。

14. i18n / gettext

確認対象：

• gettext漏れ
• 英語ベタ書き
• 日本語ベタ書き
• 日本語限定処理
• 動的文言
• placeholder
• button label
• warning/error

Shortcodesブロック等の明示された例外は除外する。

15. Color / Design UI

確認対象：

• native color picker
• HEX
• Suggested
• swatches
• Link Colors
• button background
• button text
• surface
• preview color
• Reset追従

同じ役割のUIはKaia UI LEGO Referenceと比較する。

ただし、Standardの高機能Color WorkspaceをFreeへそのまま移植する等、grade境界を壊す統一は禁止。

16. Preview

確認対象：

• 保存前Preview
• 実表示との違い
• Preview連打
• 状態同期
• 色
• サイズ
• 画像
• 数字
• text
• reset
• picker変更

Preview操作を本番実行と誤認しない構造になっているか確認する。

17. Responsive / 実表示崩れ

確認対象：

• PC
• narrow width
• mobile
• 折返し
• button横伸長
• 数字桁崩れ
• box overflow
• input overflow
• Preview崩れ
• 画像導入時
• 1列化

過去に実事故があるため必須点検。

18. Form / Security

確認対象：

• nonce
• capability
• sanitize
• escape
• GET
• POST
• redirect
• action
• form target

LEGO/UI移植時に別製品のnonce/action/option名を混入させない。

19. 重複登録 / 名前衝突

確認対象：

• hooks
• menu
• function
• class
• global
• constants
• CSS selector
• JS
• option
• provider
• socket

単体では動いても、兄弟製品との同時有効化で衝突しないか確認する。

20. Disable / Delete / Uninstall

確認対象：

• deactivate
• delete
• uninstall
• shared data
• sibling data
• Kaia Memoria parent
• socket
• shared state

一製品を無効化・削除したことで兄弟製品や共有データを巻き込まないか確認する。

21. Upgrade経路

確認対象：

• 旧版 → 新版
• settings保持
• data保持
• migration
• migration再実行
• migration途中失敗
• version判定

新規インストールだけ正常で、既存ユーザー更新時に壊れる状態を避ける。

22. 失敗時 / 欠損時挙動

確認対象：

• sibling plugin不在
• 古い兄弟製品
• socket不在
• provider不在
• データ欠損
• 不正値
• 想定外状態
• activation order差

Fatal errorではなく安全に縮退できるか確認する。

23. LEGO移植境界

標本から製品へ移植するとき確認：

• UIだけ必要なのか
• behaviorも必要なのか
• Preview関係も必要なのか
• stateも必要なのか
• socketまで付いてきていないか
• product-specific処理が混入していないか

原則：

UI LEGOはコピー候補。Socket TAPEは自動コピー禁止。

標本 → 製品は必ずRevision Ruleを通す。

24. 差分監査

KNOWN-GOOD SOURCEと新Revisionを比較。

確認対象：

• intended delta
• unintended delta
• identity drift
• socket drift
• Registry drift
• option drift
• route drift
• business logic drift

「目的と関係ない変更」が入っていないか機械的に確認する。

25. Package / ZIP

確認対象：

• ZIP integrity
• directory構造
• plugin header
• Version
• Build
• Series
• Revision marker
• Registry資料
• Reference資料
• 不要ファイル
• installability
• 誤梱包

製品ZIPへREFERENCEを同梱する場合、runtimeから隔離し、製品コードとして実行されない形にする。

26. Debris / Reserved Structure Audit

コード・UI内の「ゴミ候補」を点検する。

明白な制作ゴミ

例：

• debug出力
• test log
• 処理済みの一時TODO
• コピペ時の無意味なコメント
• 完全重複した一時コード
• 使用済み検証変数
• 明白な仮ラベル
• 作業途中の空殻
• 「俺が置き忘れたメモやんけ！！！」と明確に判断できるもの

依存がないことを確認した上で削除可。

削除した場合はCHECK LOGへ記録する。

RESERVED / 意図的な予約物

以下は未使用に見えても自動削除しない：

• greyed-out UI
• disabled button
• future seat
• Binder/Refill予約席
• 上位grade用表示
• compatibility stub
• hook
• socket
• placeholder
• 外部製品への導線
• 将来機能のため意図的に存在させた構造

原則：

未使用っぽい ≠ 不要。

判断不能

「なぜ存在するのか？」と少しでも判断に迷う場合：

WATCH / POSSIBLE DEBRIS

として保持し、Shamyueへ確認する。

勝手に掃除しない。

27. Documentation / Package Debris Audit

確認対象：

• README
• old README
• manual
• specification
• memo
• sample
• migration note
• bundled documentation
• 古いRegistry資料

旧資料を発見した場合：

1. 最新資料・現行仕様と突き合わせる。
2. 最新資料へ内容が完全に包含されているか確認する。
3. 情報損失なく完全に陳腐化している場合のみ破棄可。

以下の場合は削除しない：

• 旧資料にしかない注意事項がある
• 導入手順が残っている
• compatibility情報がある
• 購入者向け情報がある
• 歴史的に保持する意味がある
• 最新資料と内容が矛盾する
• どちらが正しいかコードから確定できない

矛盾・判断不能は BLOCK / Shamyue相談。

28. Multi-plugin Coexistence Audit

特別重点項目。

単体正常 ≠ シリーズ同時使用正常。

確認対象：

• Kaia Memoria親メニュー
• function/class/global衝突
• provider重複
• hook競合
• CSS汚染
• JS汚染
• option衝突
• socket競合
• activation order
• sibling plugin有無

可能な範囲で兄弟製品同時有効化状態を想定して確認する。

29. State Transition Audit

静止状態だけでなく、時間経過を含む状態遷移を確認する。

例：

未設定
→ 設定
→ 保存
→ 使用
→ 更新
→ Reset
→ 再設定

その他：

LOCK前
→ HOLDING
→ RELEASE
→ CONSUMED

発行前
→ 発行
→ 再表示
→ 次回発行

状態遷移後に古い値・UI・権利が残らないか確認する。

30. Legacy Residue Audit

新仕様の存在確認と同時に、旧仕様の残骸を検索する。

対象例：

• old socket
• Counter Free直接参照
• old admin route
• old slug
• old option
• old UI
• old redirect
• obsolete compatibility path
• old terminology
• deprecated helper

特に、

新実装あり + 旧実装も残存

を高リスクとして扱う。

旧実装を見つけても、それが互換性維持用か単なる残骸かを確認してから処理する。

31. Warning / Error Semantic Consistency

UI状態表示の中でも特に警告系を横断確認する。

確認対象：

• 同じ深刻度なのに製品ごとに見た目が違いすぎないか
• WarningとErrorが逆転していないか
• 成功表示と警告表示を誤認しないか
• ユーザーが次に何をすればよいか分かるか
• sibling plugin不足時の案内
• 必須条件不足
• 発行不能
• LOCK
• 終了状態

シリーズとして同じ意味の状態は、可能な範囲で同じUI grammarを使用する。

32. CURRENT / CANDIDATE / REJECTED / OBSOLETE / REFERENCE確認

変更前に対象コード・設計の状態を確認する。

• CURRENT — 採用済み
• CANDIDATE — 未決定
• REJECTED — 検討済み・不採用
• OBSOLETE — 以前は有効だったが置換済み
• REFERENCE — donor/evidenceのみ

古いコードという理由だけでREJECTED扱いしない。

既知のREJECTED案と同等のものを再実装しそうな場合は停止して理由を確認する。

死体を保存するな。死因を保存する。

33. Revision Safety

製品修正は原則：

KNOWN-GOOD
→ COPY
→ NEW REVISION IDENTITY
→ EDIT
→ COMPARE
→ VERIFY

完成済み旧製品を直接編集しない。

失敗Revisionが発生した場合：

KNOWN-GOOD
→ COPY
→ NEW IDENTITY
→ failed revisionから必要部分のみ選択移植
→ COMPARE
→ VERIFY

失敗版をそのまま修理ベースにしない。

34. Runtime Verification Boundary

静的検査で確認できるものと、実機でしか確認できないものを分離する。

静的PASSだけで、

「製品動作PASS」

とは宣言しない。

実機確認が必要な項目は明示してShamyueへ渡す。

例：

• WordPress admin表示
• sibling同時有効化
• save/redirect
• responsive
• issuance
• lock
• PDF生成
• plugin disable
• cross-product linkage

35. Final Release Gate

出荷候補へ昇格する前に最低限確認：

• PHP/static syntax PASS
• ZIP integrity PASS
• intended delta確認
• unexpected deltaなし
• socket audit完了
• legacy residue audit完了
• Registry/identity driftなし
• grade境界維持
• UI統一確認
• warning/error表示確認
• i18n確認
• responsive確認
• debris audit完了
• documentation audit完了
• sibling coexistence確認
• 必要なruntime test完了
• unresolved BLOCKなし

WATCHが残る場合は、内容と理由を記録する。

CHECK LOG運用

重要な検査を行った場合、未来のKaia/ChatGPTが再調査しなくて済むようCHECK LOGを残す。

最低限：

CHECK TARGET
SOURCE / BASE
REVISION
SOCKET STATUS
IDENTITY STATUS
INTENDED DELTA
UNEXPECTED DELTA
DEBRIS REMOVED
RESERVED ITEMS
STATIC CHECK
ZIP CHECK
RUNTIME CHECK
WATCH
BLOCK
RESULT

削除したゴミがあれば、何を削除したか記録する。

不採用判断ではコードそのものを永久保存する必要はないが、不採用理由＝死因を残す。

基本事故防止原則

1. 動いているものを、綺麗にする目的だけで壊さない。
2. UI統一と業務ロジック変更を混ぜない。
3. 新仕様があることだけで安心せず、旧仕様の残骸も探す。
4. Standardとの差を自動的に不具合扱いしない。
5. 未使用コードを自動的にゴミ扱いしない。
6. グレーアウト・disabled・空席には意図がある可能性を優先する。
7. Registry番号変更だけで内部IDを書き換えない。
8. socketは製品名・grade名への直接依存を避け、現行contractを確認する。
9. 標本からは必要なLEGOだけを選択移植する。
10. 判断不能なら推測しない。
11. 明白な制作ゴミは安全確認後に掃除してよい。
12. 古い資料は最新資料と比較してから捨てる。
13. 単体PASSだけでシリーズPASSとしない。
14. 静的PASSだけで実機PASSとしない。
15. 修正前にKNOWN-GOODを確定する。
16. 製品変更はRevision Ruleを通す。
17. 誤検知より見落としを警戒する。
18. 技術判断はKaia側で処理し、Shamyueへ不要なコード判断を投げない。
19. 仕様衝突・意味不明な残存物・製品判断が必要な場合はShamyueへ相談する。
20. 新しい事故原因を発見したら、この点検票へ追加する。

これを初版の母票でいいと思う。
今後「うわ、こんな事故経路もあるんかｗ」が出たら、その場限りの注意で終わらせず項目を増やしていけばいい。

相談：なし