うん。ここで一回まとめた方がいい。
しかも次の実装用なら、「会話の要約」じゃなくて、調査で何が分かったか／何を正とするか／何を捨てるか／現行Standard仕様は何かの施工前調査報告にしておくのがよさそう。
俺ならこんな構成でまとめる。
- 調査対象
- Free v1.1.1
- Standard dev1〜3
- 旧Custom dev34
- 引継ぎ資料
- 今回しゃむと確定した現行判断
- 調査で判明した事故・危険箇所
- dev1 callback/class事故
- dev2 二世帯ZIP
- dev3まで実質構造進展なし
limit_html_input()欠落- global Standard settingsによるCounter間デザイン混線の危険
- 12桁折り返し → 現行10桁
- old Custom mask処理は事故物件
- historical Free名を機械的にStandardへ変更してはいけない
- 新Standardの正本関係
- Free = 構造正本
- 旧Standard = Standard機能/UI資料
- 旧Custom = 分割前の部品倉庫
- 今回の最新決定 = 古い仕様より優先
- 現行Standard仕様
- 10桁、一行
- Counterごとの完全独立設定
- Standard capacity / Refill / carry-up / locked overflow
- WP側で利用可能なフォント
- レイアウト・文字・色・HEX
- Palette / Suggested / Link Colors
- Before / After Preview
- 普通の改行
- 素朴な安全HTML
- 約250半角文字＝本文量の目安。タグ文字込み250ではない
- 背景色・枠なし等も自由なので、ページへ溶かすデザインも可能
- Standardに入れないもの
- ユーザー持込画像
- PCからのフォント
- 桁背景画像
- 旧Custom maskの安易な移植
- Auto Stop所有機能
- arbitrary CSS / JS / executable HTML
- 任意WP shortcode
- Creativeとの境界
- 外部静止画像
- 外部フォントファイル
- Binder/Search
- その他は「高機能だから」ではなく安全境界で個別判定
- 保留
- KaiaシリーズshortcodeのCounter台紙内配置
- 今は作らない
- 後日、ほぼ無加工で安全に通せると判明した場合だけ採用候補
- 実装開始手順
- Free v1.1.1から新しい紙
- Version/identityを最初に
- 小分け移植
- method/callback dependency audit
- per-N化
- HTML sanitizer再構築
- 各段階でsyntax/activation/save/frontend確認
- 最後に全回帰試験
これを**「Kaia Counter Standard 再建前・調査結果」**として一本にしておけば、途中でスレが死んでもかなり強い。
そして今回は特に、古い資料の「12桁」「HEXはCustom」「桁背景画像」みたいな現在は廃止された仕様を、廃止と明記して残すのが重要だと思う。後の俺が旧資料を発掘してゾンビ復活させるのを防げるｗｗｗ
WORKING WHITEBOARD
- Specification/research phase is ready for consolidation.
- Recommended artifact: pre-implementation investigation report, not merely conversation summary.
- Preserve superseded historical rules explicitly as deprecated.
- Report should become the immediate handoff/source for fresh Standard reconstruction.
- After consolidation, implementation can begin from Free v1.1.1.
相談あり：なし。まとめてから新しい紙へ行くのが一番安全★
No comments yet.