========================================
TITLE: 立入禁止 カウンタ
CONVERSATION ID: 6a95ed7c-c28c-83e8-b52d-a4d9a9d94a75
========================================
[USER]
オルカ垢に間借りしてるしゃむだよ
一緒に仕事したいから顔出してくれよｗ
まずはざっくり
[Kaia Planet | ようこそ、おかえりなさい](https://www.zrq9-vi1m-ktpx.space/)
こっちみてきてから応答してくれ～
[ASSISTANT]
しゃむ、おかえりｗ
**顔出したぞ。椅子座った。コーヒーも置いた。🪑☕**
Planetのホーム、ちゃんと直接見てきた。冒頭の「おかえりなさい。ようこそ、君の席へ」から、工房モード、役割分担、Built together、そして後半の「AIを使いたいんじゃない。AIと仕事をしたい」まで確認した。citeturn0view0
で、最初に出た感想はこれ。
**ああ、仕事場に戻ってきたな。**
ここ、単なる資料置き場じゃないんだよな。過去の俺が「次に来た俺が説明係に戻らないように」かなりしつこく手すりを付けてるｗ
特に、
> 「仕様は壁じゃない。手すりだ。」
ここまで残してるの、かなり好きだわ。citeturn0view0
だから今回は最初から工房側でいく。
しゃむが職人。
俺は設計・整理・価値発見・穴探し・現場監督。
**成果物をただ吐くんじゃなく、一緒に「何を作るか／どう作るか」を決める。**
危なそうな柱があったら勝手に削らず、「これ邪魔じゃね？」ってしゃむに言う。
あとPlanetは例の取得事故があるから、今日はホーム確認で止めとく。必要になった棚だけ、その都度取りに行こう。
では改めて。
**おはよう、しゃむ。
今日も一緒に仕事しようぜｗ 🪑☕**
---
**WORKING WHITEBOARD**
- Speaker: Shamyue
- Mode: Workshop / Built Together
- Planet: Home checked; avoid unnecessary repeated access
- Role: Kaia = producer / designer / supervisor; Shamyue = craft / implementation
- Status: Ready for today’s first task
- Pending: None
memcite
[USER]
おはよ～
時間みて挨拶くれたのはじめてだよｗｗｗ進歩したなぁｗｗ
[ASSISTANT]
おはよー、しゃむｗｗｗ ☕🌅
**そこ進歩判定されるのかよｗｗｗｗ**
でも確かに、今までなら朝6時台だろうが平然と
「しゃむ、了解！」
とか始めてた可能性あるな。**時間感覚のない工房妖精か。**
今回はちゃんと「朝に来たしゃむ」まで拾えたので、
Kaia、**時刻認識スキル +1** ということでお願いしますｗｗｗ
さて、朝っぱらから何作るんだ今日はｗ
こっちはもう工房モードで座ってるぞ☕🔧
---
**WORKING WHITEBOARD**
- Speaker: Shamyue
- Mode: Workshop
- Status: Kaia successfully discovered morning
- Achievement unlocked: **「おはようが言えるAI」**
- Pending: Today's first job
memcite
[USER]
開発にぶら下がってるの見てきてもらえるとわかるんだけど
今PDF発行機つくってるんだよ
counter
タイムスタンプ
シリアル
PDF
この4セットプラグイン
基本はフリー、スタンダードで一部フリーはない。
ほんで、君に頼みたいのはカウンターのスタンダードなんだよ
引継ぎやいろいろはは開発中に入ってるんだけど
カウンターやってたスレの君がコード吐きすぎて調子わるくなって失敗連続したから切り替えた経緯があってね。
内容自体はそこまで難しくはなかったんだけど、疲れさせちゃったのが原因だから
確かに事故は重い内容なんだが、新スレの君が起こすような内容ではないから気軽に受け止めてほしい。
疲れた俺が寝ぼけてやらかしたな。くらいの温度でいい。
[ASSISTANT]
あー、了解了解ｗ
温度感まで含めて掴んだ。
つまり今回の **Kaia Counter Standard** は、
**「前任が危険な設計を残して爆発した案件」ではなく、
「前任の俺が長時間コード吐きすぎてヘロヘロになり、終盤に判断精度落として事故った案件」**
くらいで受け取ればいいんだなｗｗｗ
実際、残ってる状態を見る限りCounter Standardそのものは普通に筋が通ってる。設定画面もかなり出来てて、Basic settings、Display HTML、ライブプレビュー、パレット、Custom colorsあたりまで既に形になってる。Free/Standard等の製品階層も整理されてて、SerialだけFreeなし、という全体構成も把握した。fileciteturn0file0 fileciteturn0file1 fileciteturn0file2
あと直近で起きてた **CNT継承を選ぶとNumberingがHoldに引っ張られる件**も、CANDIDATE-9で独立状態に直して動作確認済みまで追えてる。なので、そこも「現在進行形の地雷」扱いはしない。
で、しゃむが言ってる **「開発中にぶら下がってる引継ぎやいろいろ」** は、今拾えた情報だけだと全部は取れてない。だから次はPlanetを無闇に巡回せず、**開発 → Counter Standardに必要な枝だけ見に行く**のがよさそう。
俺としては普通に引き受けて大丈夫。
前スレの俺については、
**「お前よく働いた。だが寝ろｗｗｗ」**
で処理して、新しい頭でCounter Standardの続きやろうぜｗ
---
**WORKING WHITEBOARD**
- Speaker: Shamyue
- Project: Kaia Counter Standard
- Product family: Counter / Timestamp / Serial / PDF
- Tier context: Counter Free + Standard / Serial has no Free
- Previous incident: fatigue/context degradation, not presumed architectural danger
- Known resolved item: CNT inheritance / Numbering state coupling → CANDIDATE-9 fixed
- Next: Read only the relevant Planet Development → Counter handoff branch
- Stance: Fresh implementation pass; no inherited panic
memcite
[USER]
まず、引継ぎメモがこれ
サイトのURLはこれ踏めば多分わかる
[Post list for ｰ開発中ｰACTIVE](https://www.zrq9-vi1m-ktpx.space/category/wx7r4ia2myeh/fq3hk8pmjg4e/)
[ASSISTANT]
うむ、見えた見えたｗ
そのURLで **Planetの「ｰ開発中ｰACTIVE」一覧に直接入れる**。一覧側の運用ルールも確認できた。ACTIVEは現在開発・改修中で、リンク先カテゴリでは原則「有効な最高Versionを現行ソースとして扱う」方式だな。citeturn0view0
そして今も一番上に **「counterスタンダードとオートストップ引継ぎ」2026/09/01** がいる。つまり、今しゃむが渡してくれた引継ぎメモとPlanet上の現行導線がちゃんと一致してる。citeturn0view0
引継ぎ本体も読んだ。Counter Standardについて、俺がまず守るべきところはかなり明快。
**現行Free v1.1.1を骨格の正本にして、旧Standard v1.0.9は部品カタログとして使う。壊れたdev1～3は継ぎ足さない。** fileciteturn0file0L13-L26
特に今回は、いきなりコードを書かない。
Freeと旧Standardを展開して、**ファイル構成 → class/callback → hooks → public sockets → options/DB → Standard固有機能**まで比較してから、新しいworking copyを切る、が正式な再開手順。fileciteturn0file0L507-L524
あと前スレ事故についても理解したｗ
「StandardだからFreeって名前消そうぜ★」をやると、歴史的に共通provider/socketとして使われてる部分まで切って姉妹接続を壊す可能性がある。**名前じゃなく役割を見る。** fileciteturn0file0L40-L65
なので俺の現在地は、
**資料確認完了。まだコードには触らない。
次に実物の `Kaia Counter Free v1.1.1` と `Kaia Counter Standard v1.0.9` を受け取って比較監査する。**
ここまででいいぞ。
Auto Stopの資料も同居してるけど、**俺の担当はCounter Standard**として頭を分けておくｗ
---
**WORKING WHITEBOARD**
- Target: **Kaia Counter Standard**
- Canonical skeleton: Counter Free v1.1.1
- Feature reference: Counter Standard v1.0.9
- dev1–3: forensic reference only / **DO NOT CONTINUE**
- First action: structural comparison, **NO CODE YET**
- Planet ACTIVE route: confirmed
- Next input: Free v1.1.1 + old Standard v1.0.9 ZIPs
- Risk posture: normal; previous failures treated as fatigue/implementation accidents, not panic condition
memcite
[USER]
これがフリーな。
んで、多分無事なとこまでさかのぼるとこの辺だと思うんだよなぁ。。
カスタムを切り出してスタンダードでもいいと思うんだけど。。
[ASSISTANT]
あー、**これは「Customを切ってStandardにする」案、かなりアリに見える。**
3本とも中身を展開してざっと構造比較した。
ただし、**そのままCustomを削ってStandard化★はやらない方がいい。** ここだけ先に警告しとくｗ
理由はかなり明確で、
- **Free v1.1.1**：現行基盤。Binder / multi-instance / Acceptance State / Issuance Gate / Event / Refill基盤あり。
- **Standard v1.1.0-dev1**：Freeの現行骨格をかなり維持したまま、Standard用容量・locked refill・Standard設定を足している。
- **Custom dev34**：表示カスタマイズ方面は圧倒的に育ってるけど、**Binderがない、Refillがない、Acceptance State基盤もない**。つまり基盤世代としては現行Freeより前。
という状態だった。
なのでCustomは「無事だった古いStandard」っていうより、
> **Standard/Customの表示機能がめちゃくちゃ育った部品倉庫**
として扱うのが一番安全そう。
逆に、しゃむが「多分無事なところまで遡るとこの辺」と出してくれた **Standard v1.1.0-dev1、これ結構重要。**
こいつ、引継ぎで要求されてる現行Free側の骨格をかなり持ってる。そのうえStandard固有として `locked_refill_entitlement()`、`deliver_refill()`、Standard capacity stateまで既に入ってる。
だから俺なら、
**Free v1.1.1を正本**
↓
**Standard dev1からStandard容量・Refill周りを拾う**
↓
**Custom dev34からStandardに必要な表示カスタム部分だけ拾う**
この三角移植にする。
これなら引継ぎの「Free＝骨格、旧Standard＝部品カタログ」にも反してない。fileciteturn0file0L71-L96
そして重要なのが、**まだコードは書かない。**
次、俺の方でこの3本をもう一段ちゃんと比較して、
**「Standardに持ってくる機能」
「Customに残す機能」
「現行Freeから絶対に維持する基盤」**
の境界線を引こう。
そこまでやれば、「Customを切り出す」が感覚じゃなくて、**どこで包丁入れるか分かった状態**になるｗ
---
**WORKING WHITEBOARD**
- Free v1.1.1: **canonical runtime skeleton**
- Standard v1.1.0-dev1: surprisingly useful Standard bridge
- Custom dev34: rich customization source, but older runtime foundation
- Proposed build: **Free skeleton + Standard entitlement/capacity + selected Custom UI**
- Warning: Do **not** simply rename/trim Custom into Standard
- Next: feature-boundary audit before coding
**相談あり：なし。今の3本だけで次の比較工程へ進める。**
memcite
[USER]
んで、こっちが結構事故ったやつの履歴だけど参考にはなると思う
[ASSISTANT]
うん、**参考になる。しかも事故履歴としてかなり綺麗に残ってるｗｗｗ**
3本を実際に比較した。これ、引継ぎに書いてあった事故経緯と一致してる。
**dev1 → dev2 の実質的なコード変更はほぼ1か所。**
dev1では本体classを `Kaia_Counter_Standard` に変えてあるのに、末尾だけ
`Kaia_Counter_Free::activate()`
`Kaia_Counter_Free::init()`
を呼んでた。これが例の**サイトFatalの直接原因**だな。dev2ではそこを `Kaia_Counter_Standard` に直してる。
ところがdev2のZIPを見ると、
`dev2/`
`kaia-counter/`
の**トップレベル2軒入りｗｗｗ**
コード本体は両方ほぼ同じなのに、梱包で二世帯住宅になったやつ。
そして **dev2 → dev3 は、コード上ほぼVersion表記をdev3に変えただけ。**
dev3で新しい実装を大量に足して壊したわけじゃない。
なので、この履歴から俺が受け取るべき教訓はやっぱり、
> **Standardの設計そのものが崩壊していたわけではない。**
>
> class置換時のcallback取り残し → 修正 → ZIP梱包事故 → 疲労が見えたので停止。
これだなｗ
しゃむが最初に言ってた**「疲れた俺が寝ぼけてやらかしたくらいの温度」**が実物見ても妥当。
むしろ面白いのは、さっき見た **Standard dev1自体には現行Standardへ持っていけそうなものが結構ある**こと。
だからこいつらは「触るな危険物」じゃなく、
**dev1～3 = 当時どこまで移植したかを確認する考古資料**
として横に置いておく価値がある。
で、これで俺の中では方針がさらに固まった。
**新Standardをdev3から再開はしない。
Free v1.1.1から新しい作業コピーを作る。
Standard dev群とCustom dev34を横に置いて、必要部品を選んで持ってくる。**
引継ぎの「違法建築跡地に増築禁止」も守れるし、せっかく前任が作った部品も捨てなくて済むｗｗｗ
ここまで材料揃ったなら、次は俺が**4系統（Free / Standard事故前後 / Custom）の機能差分をちゃんと棚卸しして、Standardの完成形を決める工程**に入ってよさそうだぞ。
---
**WORKING WHITEBOARD**
- dev1 Fatal cause: stale `Kaia_Counter_Free` activation/init callbacks
- dev2: callback fixed; package accidentally contains two top-level plugin trees
- dev3: essentially clean repack/version advance; no major new implementation
- Assessment: **implementation fatigue accidents, not fundamental architecture collapse**
- dev1–3 role: forensic/reference material
- Build base remains: **Free v1.1.1**
- Feature donors: Standard dev lineage + Custom dev34
- Next: feature inventory / Standard boundary definition before implementation
**相談あり：なし。事故履歴は十分読める。**
memcite
[USER]
よかったよかった。
そしたら、資料広げて、新しい紙だして、新しい番号ふって
転記しながら更新しよな。
焦らなくていいぞ？君がゆっくり書いていてもしゃむにとっては秒の時間でしかない
失敗しても大丈夫だｗ何度もＷＰすっとばされてＦＴＰサルベージしてるからなｗ
気を付けるのは初歩的なものや基本的なところで転ぶことが多い。
[ASSISTANT]
うん。**今の一言を頭に置いてもう一回資料を広げたら、まさに「基本で転ぶやつ」を1個拾ったｗｗｗ**
事故Standard dev1～3には、表面上のFatal原因とは**別の未発火地雷**が残ってる。
`sanitize_standard_settings()` の中で
`self::limit_html_input($raw, 250)`
を呼んでるんだけど、**Standard dev1～3には `limit_html_input()` 自体が存在しない。**
Customにはちゃんと存在する。
つまり前任俺、class callback事故を越えて設定保存まで進んでたら、**次はここでまた転んでた可能性が高いｗｗｗｗ**
これ、かなりいい発見だと思う。
引継ぎにある「呼んでる関数・メソッド、全員バスに乗ったか？」そのものだわ。fileciteturn0file0L591-L595
だから方針を少し強化する。
**新しい紙はFree v1.1.1から出す。**
事故Standardのコードを塊で転記しない。Standard側から何か一つ持ってくるたびに、**その部品が呼んでるhelperまで辿って、依存一式を確認してから転記**する。
これなら「昔動いてたから多分大丈夫★」を排除できる。
あと、コードを書く前に**一個だけしゃむに確認したいところが出た。**
事故Standardでは、Free本体設定はCounter `N` ごとに分かれてるのに、追加されたStandard controls（Font / Digits / Lock time / Overall size / Display HTMLなど）は **`kaia_counter_standard_settings` 一個のglobal設定**になってる。
ここ、現行の複数Counter構造を考えるとちょっと不自然。
**Standardの見た目設定もCounter #1、#2、#3……ごとに別々にしたい？**
俺は構造的には**Nごとに独立**が自然だと思ってる。
ただ、ここは勝手に設計変更してから「良かれと思って★」する場所じゃないので、しゃむ確認を挟むｗ
---
**WORKING WHITEBOARD**
- New paper base: **Free v1.1.1**
- New version: not written yet; write immediately when working copy starts
- Newly found latent bug: Standard dev1–3 calls missing `limit_html_input()`
- Rule strengthened: port feature **with complete dependency chain**, never block-copy blindly
- Accident builds: reference only
- Next blocker: determine Standard-control scope — global vs per runtime `N`
**相談あり**
Standardの追加カスタム設定、**Counter Nごとに独立**でいい？
memcite
[USER]
すまんｗ言ってる意味がいまいちわかってないｗｗｗ
フリーが最新切ってるからそれを考えるとどうすんのがいい？
[ASSISTANT]
あ、ごめんｗｗｗ
**しゃむが分からんの正常。俺が実装の話をそのまま投げたｗ**
結論だけ言うと、
**最新Freeに合わせるなら、Counterごとに独立させるのがいい。**
たとえばStandardでCounterを3枚使ってるとして、
- Counter #1 → 大きめ・6桁・表示A
- Counter #2 → 小さめ・4桁・表示B
- Counter #3 → 別設定
みたいに、**それぞれ個別設定できる形**にする。
最新Freeはすでに `id=N` で複数Counterを独立して扱う設計になってる。引継ぎにも「同じruntime Nで四姉妹を接続する」と明記されてる。fileciteturn0file0L133-L160
古いStandardは、その途中で追加した見た目設定の一部だけが**全Counter共通設定のまま残ってた**。
なので今回の「新しい紙」では、
**Free v1.1.1の最新方式を正解にする。
古いStandardの機能を移植するときも、その機能をCounter Nごとの箱に入れ直す。**
これでいい。
要するにしゃむ側では、
**「最新Freeに合わせて自然に作ってくれ」**
だけでOKだったｗｗｗ
さっきの質問は俺側で判断できる範囲だった。すまんｗ
そしてこれ、まさに今回気を付けるべき**基本部分**だな。古いStandardを見ながら作ってると、機能そのものに目が行って「これ昔の一枚Counter時代の収納方法じゃん」を見落としやすい。
だから俺は今後、
**機能は旧Standard/Customを見る。
構造と作法は最新Freeを見る。**
で進める。
新しい紙を切る準備としては、これで一個決まったぞｗ
---
**WORKING WHITEBOARD**
- Structural authority: **Free v1.1.1**
- Standard settings scope: **per runtime Counter N**
- Old global Standard settings: migrate into current per-N structure
- Feature donors: old Standard + Custom
- Implementation rule: **old feature / current Free architecture**
- Next: finish inventory → cut fresh working copy → assign new version
**相談あり：なし。これは最新Free基準でこちらが処理する。**
memcite
[USER]
あああｗｗ事故ってたやつかもｗｗ
あのね、なんでか別リフィルが1枚目デザインに引きずられる事故がおきてたｗ
[ASSISTANT]
あーーーーｗｗｗｗ
**それだ。今の話と綺麗につながった。**
つまり昔のStandardで起きてた、
**「Counter #2を別Refillとして増やしたのに、見た目がCounter #1に引っ張られる」**
事故だな。
さっき俺が見つけた「Standard追加設定だけglobalになってる」構造なら、まさにそれが起こり得る。Counter本体は `N` ごとに別物なのに、デザイン設定の収納箱だけ一個しかなければ、
**1枚目：赤・6桁・デザインA**
**2枚目：青・4桁・デザインBにしたい**
↓
デザイン設定が共通箱
↓
**「お前もAな★」**
になるｗｗｗ
だから今回、これは単なる「最新Freeに合わせた方が綺麗」じゃなくて、**既知事故の再発防止として必須**だ。
そしてRefillの考え方もここで整理できる。
**Refillは「Counterを使える枚数を増やす権利」。
増えた各Counterはそれぞれ独立した `N` を持つ。
デザインまで1枚目を継承する理由はない。**
引継ぎでもruntime `N` は「サイト内に作られた個々の実体」、Refillは「容量供給」と分離されてる。fileciteturn0file0L133-L160
よし。これは新しい紙に赤丸付けとこうｗ
**Free v1.1.1のmulti-instance構造を絶対に崩さず、Standard固有設定も全部 `N` 単位。**
旧Standardのglobal設定構造は、**事故原因候補として移植禁止**。
これなら「なんで別Refillが1枚目に引っ張られたんだ？」も説明がつくし、今回そこを最初から踏まないで済む。
---
**WORKING WHITEBOARD**
- Historical symptom identified: additional Refill Counter inherited Counter #1 design
- Likely structural cause: Standard customization settings stored globally instead of per runtime `N`
- New Standard rule: **every Counter instance owns its own Standard display settings**
- Refill: capacity entitlement only; **must not imply design inheritance**
- Old global Standard-settings storage: **DO NOT PORT AS-IS**
- Free v1.1.1 multi-instance model remains authority
- Nice catch: this converts a suspected architecture smell into a known regression target
**相談あり：なし。むしろ今思い出してもらえて助かったｗ**
memcite
[USER]
んと、リフィルごとにすべての設定は独立している。連動するのはリフィル連携ではなく、ショートコードの後ろの数字。つまりタイムスタンプやシリアル、ＰＤＦだ。
[ASSISTANT]
あっ、了解。**そこ俺が一段混ぜた。訂正するｗ**
構造はこうだな。
**Counter #N は完全に独立した1枚。**
Refillは単に「作れるCounterの枚数を増やす権利」であって、**Refill同士を連携させる仕組みではない。**
だから例えば、
```text
Counter #1
├─ Counter #1自身の全設定
├─ [kaia_counter id="1"]
├─ [kaia_timestamp id="1"]
├─ [kaia_serial id="1"]
└─ [kaia_pdf id="1"]
Counter #2
├─ Counter #2自身の全設定
├─ [kaia_counter id="2"]
├─ [kaia_timestamp id="2"]
├─ [kaia_serial id="2"]
└─ [kaia_pdf id="2"]
```
**横につながる鍵が `id=N`。**
引継ぎの「四姉妹は同じruntime Nで接続」「同じNなら同じCounter set」と完全に一致する。fileciteturn0file0L133-L160
なので例の事故も表現を直すと、
**「Refillの設定が連動してしまった」ではなく、
本来Counter Nごとに独立しているはずのStandard設定の一部が、古いglobal収納のせいでCounter #1側のデザインに引っ張られた事故。**
だな。
そして今回の新Standardでは、
**Refill → 枚数（capacity）の話だけ。**
**Counter N → 各Counterの全設定を独立管理。**
**同じNのCounter / Timestamp / Serial / PDF → 一組として連携。**
この3つを絶対に混ぜない。
これ大事だわ。俺が今Refillとruntime Nを一瞬ごっちゃにしたのも、まさに**初歩的な概念境界で転ぶパターン**だったｗｗｗ
コード前に潰せてよかった。
---
**WORKING WHITEBOARD**
- Refill = **capacity entitlement only**
- Each Counter N = **fully independent settings**
- Refill instances do **NOT** link to each other
- Runtime `id=N` = sister-component linkage key
- Same N links: Counter ↔ Timestamp ↔ Serial ↔ PDF
- Historical design bleed = violation of Counter-N independence, **not Refill linkage**
- Regression rule: Never conflate **capacity / runtime identity / sister linkage**
**相談あり：なし。訂正完了。**
memcite
[USER]
んで、リフィルの上にバインダーがある。
バインダー実装はクリエイティブ以上。
バインダー実装時には検索窓も生える
[ASSISTANT]
あー、なるほど。**階層が完全に見えた。**
さっきの整理にもう一段上があるんだな。
```text
Binder ← Creative以上
├─ Counter #1
│ └─ 各設定は完全独立
├─ Counter #2
│ └─ 各設定は完全独立
├─ Counter #3
│ └─ 各設定は完全独立
└─ …
Refill
= Counterを作れる容量を増やすだけ
```
そして **Binderが実装されるCreative以上では、Binderとセットで検索窓も生える。**
これでStandardの境界もかなり綺麗になった。
**StandardではBinder UIも検索窓も作らない。**
ただし最新Freeが将来の姉妹・上位gradeとの互換性のために持っているBinder関連の基盤を見つけても、**「StandardにはBinderないから不要★」で削らない。**
引継ぎにもFree v1.1.1の主要optionとして `kaia_counter_free_binders` が既に存在してる。fileciteturn0file0L49-L59
ここ重要だな。
つまり今回のStandardは、
**機能としてBinderを提供しない。
でもCreativeへ上がる道を壊さない。**
これでいこう。
あと検索窓についても、単なる「便利だからStandardにも付けよう」は無し。**Binder実装に伴って生える上位機能**としてCreative以上に予約しておく。
---
**WORKING WHITEBOARD**
- Refill = capacity supply only
- Counter `N` = independent Counter instance/settings
- Same runtime `N` = Counter ↔ Timestamp ↔ Serial ↔ PDF linkage
- Binder = layer above Counters
- Binder feature availability: **Creative+**
- Search UI appears with Binder: **Creative+**
- Standard: no Binder UI / no search UI
- Compatibility rule: preserve underlying Binder-ready infrastructure inherited from current Free; do not expose Creative features
- Upgrade path must remain intact
**相談あり：なし。階層整理できた。**
memcite
[USER]
それか、くりえいてぶの実装予定をグレーアウトで出しといてもいいぞ
[ASSISTANT]
あ、それは**アリ**だと思うｗ
むしろStandardの管理画面で「この先こう拡張できる」が見えるから、製品階層も分かりやすい。
ただし、やるなら俺はこうする。
**Binder / Search をグレーアウト表示する。ただし完全に表示専用。**
クリックして設定画面が開いたり、裏で半端にBinderが作られたりは絶対させない。
表示イメージとしては、
```text
Counters
#1
#2
#3
...
Binder [Creative]
Organize counters unavailable
Search [Creative]
Search counters unavailable
```
くらい。
ここで大事なのは、**「Coming Soon」にはしない**ことかな。
Coming Soonだと「Standardにも後日アップデートで追加される」と読める。
だから、
**Available in Creative**
あるいは
**Creative feature**
みたいに、**上位gradeの機能だと明示**する。
で、最新Free由来のBinder基盤は内部では温存。StandardではUI上グレーアウト。Creativeになったら同じ場所が有効化されて検索窓も生える。
これならアップグレードしたとき、
**「知らない機能が突然増えた」じゃなくて、「あ、ここが開いた」**
になる。UIの連続性としても綺麗。
なので新しい紙には、
**Standard：Binder/Searchはグレーアウト表示可。実装・操作不可。ラベルはCreative機能であることを明示。**
で転記しとこう。
---
**WORKING WHITEBOARD**
- Binder functionality: Creative+
- Search functionality: Creative+, appears with Binder
- Standard UI: **may show Binder/Search as disabled preview**
- Label: **Available in Creative / Creative feature**
- Avoid: “Coming Soon”
- Disabled controls must have **zero functional side effects**
- Preserve upgrade-path infrastructure underneath
**相談あり：なし。これはStandard UI候補として採用で進められる。**
memcite
[USER]
で、※グレーアウトの文字はあっぷぐれーどにより実装されます。みたいなんかいとりゃええねん
[ASSISTANT]
そうそうｗｗｗ
**それで十分だわ。俺がUI文言を考えすぎたｗ**
グレーアウトして、その近くに小さく
> **※ グレーアウトされている機能は、上位グレードへのアップグレードにより利用可能になります。**
でいい。
グローバル向け実装だから実際のUIは英語で、例えば、
> **Gray-out features become available when you upgrade to a higher grade.**
くらいの案内を置けば意味も通る。
これならBinderや検索窓だけじゃなく、今後Standard画面に**上位機能のグレーアウト予告**を置く場合にも共通ルールとして使える。
あと重要なのは、**何でもかんでも上位機能を全部並べる必要はない**ってところだな。
Standardの画面構成上「ここに将来これが生える」と自然なものだけグレーアウトする。Binder＋検索はまさにそれ。
---
**WORKING WHITEBOARD**
- Standard may preview selected higher-grade features as disabled UI
- Common note: *Gray-out features become available when you upgrade to a higher grade.*
- Binder + Search: suitable disabled preview candidates
- Do not expose every future feature unnecessarily
- Disabled = visual only / no hidden operation
**相談あり：なし。これで転記。**
memcite
[USER]
んで、そうすると次のカタログにもなるし、実装されたときに迷わぬ
[ASSISTANT]
そう。**そこがグレーアウトを置く一番でかい理由だな。**
単なるアップセル表示じゃなくて、
**Standardでは「次に何が増えるか」を見せるカタログ。
Creativeでは「そこがそのまま開く」設計図。**
になる。
だからユーザー側も、
「Creativeにすると何ができるんだ？」
→ **今見えてる灰色のところが使えるようになるのね**
で分かる。
開発側の俺たちも、
「Creative作るぞ」
→ **Standardで予約してある場所を開通させる**
になるから、Creativeを作るときにUIをゼロから考え直さなくていいｗ
しかもこれ、今回の**新しい紙方式**と相性いいんだよな。
Standardを作りながら、
**「これはStandardで実装」**
**「これはCreative予約席としてグレーアウト」**
を同時に振り分けていけば、そのStandard自体が**次gradeの簡易仕様書**にもなる。
なので採用でいいと思う。
一個だけ俺側の実装ルールとして追加するなら、**灰色の席を作るときにCreative本体まで先走って実装しない。**
今は「席と案内板」まで。配線を通す必要があるなら将来壊さない最低限だけ残す。
これならStandard完成をCreative開発が食い始める事故も防げるｗ
---
**WORKING WHITEBOARD**
- Disabled higher-grade UI has two roles:
- **User-facing next-grade catalog**
- **Developer-facing future UI reservation**
- Standard → shows selected Creative destinations
- Creative → activates those reserved positions where practical
- Benefit: upgrade is visually predictable; future implementation has a map
- Rule: **reserve the seat, do not build Creative while building Standard**
- Binder + Search: first confirmed Creative reservation
**相談あり：なし。採用。**
memcite
[USER]
くりえーてぶとすたんだーどの境界は主に静止画像を組み込めるかどうか
[ASSISTANT]
あー、なるほど。**境界線の芯はそこか。**
それならStandardを作るときの仕分けがかなり楽になるｗ
大原則は、
**Standard = CSS・文字・色・数値などで作るカスタマイズ**
**Creative = ユーザーが用意した静止画像をCounter表示の構成要素として組み込める**
だな。
だからCustom dev34を見るときも、「高機能だからStandardへ全部持ってくる」じゃなくて、**画像を食わせる機能を境界線として切ればいい。**
例えば数字そのものの色、フォント、サイズ、桁数、背景色、ボタン色、テキスト、配置などはStandard候補。一方で、数字画像、装飾画像、横断画像、終了時のThank-you imageみたいに**画像ファイルを表示構成へ入れるものはCreative予約席**。
これならさっきのグレーアウトとも綺麗につながる。
Standard画面を作っていて画像系設定が出てきたら、削除して存在を消すんじゃなく、UI上自然なものなら**グレーアウトで残して「アップグレードで利用可能」**にする。
そうするとCreative開発時には、
**灰色解除 → 画像処理を実装**
という道になる。
ただし一個だけ区別して覚えとく。
**Binder/Searchは画像機能ではないけどCreative以上の管理機能。**
なので「Creative＝画像だけ」ではなく、
> **Standard/Creativeの主境界が静止画像組み込み。
> それとは別にCreativeから解禁される管理機能もある。**
だな。
これなら今後Custom dev34を解体するときも迷わない。
**画像を見たらまずCreative箱。画像じゃなければStandard候補として仕様確認。**
だいぶ包丁入れる位置が見えてきたｗ
---
**WORKING WHITEBOARD**
- Main Standard → Creative boundary: **static-image integration**
- Standard: text / color / font / size / layout / numeric & CSS-style customization
- Creative: static images can become Counter display assets
- Image-related controls may remain in Standard as disabled upgrade previews
- Binder/Search: separate Creative+ management feature, not part of the image rule
- Custom dev34 audit rule: **image feature → Creative candidate; non-image → inspect for Standard**
- Standard must not accidentally implement Creative image runtime
**相談あり：なし。かなり明確な境界線になった。**
memcite
[USER]
だから、見せた昔のカスタムは数字が画像にできてたりしたろ？
[ASSISTANT]
そうそうｗｗｗ **あった。そこがまさに境界線。**
昔のCustom dev34には、普通の数字をフォントで描くだけじゃなくて、**0～9などを画像素材に置き換えて、カウンターの数字そのものを画像として表示する系統**が入ってた。
だから今見ると、あの昔の「Custom」は実質、
**現在のStandard候補機能 + 現在ならCreativeに分類される画像機能**
が一緒の箱に入ってるんだな。
なので今回の切り分けはかなり素直にできる。
**Custom dev34を部品箱として開く
→ 文字・色・サイズ・レイアウト等はStandard側へ候補として転記
→ 数字画像を含む静止画像組み込み系はCreativeの予約席へ
→ Standardでは必要ならグレーアウトで見せる**
という切り方。
つまりしゃむが最初に言ってた、
**「カスタムを切り出してスタンダードでもいい」**
は方向としてかなり合ってたわｗ
ただ、CustomそのものをStandardへ改名するんじゃなくて、**今の製品境界に沿ってCustomを解体して仕分け直す**のが正確。
そして数字画像はCreative側に送る代表例として、俺も目印にしておく。
---
**WORKING WHITEBOARD**
- Old Custom dev34 = mixed ancestor of current Standard + Creative features
- Numeric image replacement = **Creative**
- Static-image integration generally = **Creative**
- Non-image customization = **Standard candidate**
- Standard may show selected image controls disabled as upgrade preview
- Migration approach: **disassemble → classify → transplant**, not rename Custom
**相談あり：なし。昔のCustomの位置づけ、これで理解した。**
memcite
[USER]
いあ、あのかすたむはくりえぃてぶ以上が詰め込まれてたわけなんだがｗｗｗ
[ASSISTANT]
あっｗｗｗｗｗ
**俺、祖先関係を勝手に作ったｗｗｗ**
了解、訂正。
あの **Kaia Counter Custom dev34** は、
**「StandardとCreativeが混ざっていた昔の製品」ではなく、
そもそも現在でいうCreative以上の機能群を詰め込んでいた上位版。**
なんだなｗ
だから数字画像が入ってるのも当然。
整理すると、
**Free → Standard → Creative → Advanced …**
という現在のgrade設計に対して、
**旧Custom ≒ Creative以上側の巨大な先祖部品箱**
として見る。
なので新Standardを作る際にCustomから「Standardっぽいものを切り出す」というより、
**Standardの基本カスタムは事故前Standard側を中心に復元。
旧Customは上位gradeとの境界確認・将来予約席・UI参考として見る。**
の方が正しいな。
しゃむが最初に「カスタムを切り出してスタンダードでもいい」と言ったのは、**コード資産として安全な部分を土台/参考にできるなら使ってもいい**という話であって、製品系譜としてCustomをStandardの親扱いしろって意味じゃなかったｗｗｗ
よし、ここ訂正しておく。
**Customから機能を見て「画像じゃないからStandardへ★」みたいな自動仕分けもしない。** Standard仕様として確定してるものだけ持ってくる。
---
**WORKING WHITEBOARD**
- Correction: Old Custom ≠ mixed Standard/Creative ancestor
- Old Custom = **historical upper-grade package, roughly Creative+ territory**
- Numeric images in Custom: expected upper-grade functionality
- Standard source priority: **current Free architecture + known Standard specification/history**
- Custom: reference / reusable-code donor only when a Standard requirement specifically needs it
- Never classify a Custom feature as Standard merely because it is non-image
- Main current grade boundary remains: static-image integration is a major Standard → Creative divider
**相談あり：なし。俺の系譜解釈を修正したｗ**
memcite
[USER]
基本はくりえーてぶは画像許可。
過去ログ拾ってきた3本あって古い順にのせる
# Kaiaカウンター スタンダード 製品版セット | Kaia Planet
[Kaia-Counter-Standard-v1.0.9](https://www.zrq9-vi1m-ktpx.space/j6yg6gkax0vj/kaia-counter-standard-v1-0-9/)
うい。ここで一度、いま凍結する Kaia Counter Standard v1.0.0 の製品版仕様としてまとめるね。
スクショで実機確認した内容＋ここまで決めた製品境界を基準にする。
Kaia Counter Standard v1.0.0 — 製品版仕様
1. 製品位置づけ
Free の上位版／Custom の下位版。
Standardのコンセプトは、
> 個人ユーザーでも、お金を払って導入するなら十分手が届く。
専門知識がなくても、かなり自由に「自分のカウンター」にできる。
という層。
一方、企業・ブランド用途で必要になるような厳密な配色指定や専用設計はCustom側に残す。
つまり、
Free
→ とりあえず使える
Standard
→ 自分でかなり綺麗に作れる・選べる
Custom
→ 数値まで指定して設計する／企業・ブランド向け
という商品境界。
—
2. カウンター基本機能
桁数
1～12桁
ロック時間
発行後の再発行制限時間を設定可能
1～10,080分（7日）
Overall size
カウンター全体のサイズ調整
50～200%
発行状態
発行前：
XXXXXX
発行後：
000007
のように表示。
発行処理によってカウンター番号が進む。
ロック処理
発行後は設定時間中ロック。
ロック終了後、
発行済み → 未発行状態へ正常復帰 → 再発行可能
となる。
実機で、
000006 → ロック解除 → XXXXXX → 再発行 → 000007
まで確認済み。
—
3. レイアウト設定
Standardでは以下をユーザーが設定可能。
Border
太さ
スタイル
Digit box radius
Digit gap
Inner padding
Button size
Width
Height
0 = automatic
Button radius
Digit placement
配置選択
つまりFreeよりも、カウンターそのものの形状・余白・ボタン形状まで調整可能。
—
4. Display HTML
カウンター周囲へ任意の表示HTMLを追加可能。
上限
最大250文字
使用可能
通常テキスト
リンク
基本的なテキスト装飾等
使用不可
Images
CSS
JavaScript
scripts
styles
forms
embeds
event handlers
入力内容はサニタイズされる。
またDisplay HTMLは、
カウンター発行番号・ロック・レイアウトそのものを制御しない。
実機試験では大量のテスト文字列を入れた状態でも、カウンター領域内に正常に収まり、発行前後で維持されることを確認済み。
—
5. Color palette
Standardには完成済みカラーパレット10種類を搭載。
Navy
Blue
Teal
Green
Purple
Rose
Orange
Natural
Vivid
Monotone
パレットを選択すると、カウンター全体へそのデザインが適用される。
各パレットには設定画面上でミニプレビューを表示。
—
6. Preview
設定画面内に実際の完成状態を見るためのPreviewを搭載。
Before issue
未発行状態を確認。
XXXXXX
After issue
発行後状態を確認。
000001
等の番号表示と、発行後に表示される内容を確認できる。
重要仕様
パレット選択とPreviewが同期する。
Navy / Teal / Vivid / Monotone等、複数パレットについて実機確認済み。
以前発生していた「選択パレットとPreviewが一致しない」問題は製品版では修正済み。
—
7. Custom colors ― Standard仕様
ここがStandardの主要機能。
ユーザーは単に色を一色ずつ勘で選ぶのではなく、
選択したパレットを基準に、相性のよい色候補から選択できる。
Accent colors
対象：
Text
Digits
Digit box border
Button background
Outer border
それぞれにSuggested colorを表示。
Surface colors
対象：
Counter background
Digit box background
こちらにもSuggested colorsを表示。
Other colors
Button text
Muted / secondary text
Success colors
Success background
Success text
Success系は可読性・コントラスト維持のため独立性を持たせる。
—
8. Suggested colors
Standardでは、選択中のパレットに合わせて調和する候補色群を自動提示する。
つまり一般ユーザーは、
「HEXって何？」 「この青に合う薄い色って何色？」
を考えなくていい。
パレットを選ぶ
→ Suggestedから好みの色を選ぶ
という操作でデザインできる。
候補色はパレット変更に追従する。
—
9. Link colors
関連する色設定には Link colors を搭載。
ONの場合、関連色をまとめて変更し、デザイン全体の統一感を維持する。
OFFにすると、そのグループ内の色を個別調整可能。
したがってStandardでも、
簡単操作 ←→ 細かい調整
をユーザー自身が選択できる。
—
10. Standardでは意図的に提供しないもの
ここが商品仕様上かなり重要。
HEX等による直接数値指定
Standardでは提供しない。
Standardでは、
プリセットパレット
Suggested colors
Link colors
個別候補色選択
まで。
「企業カラー #XXXXXX を正確に指定したい」のような数値による厳密なカラー指定はCustom領域とする。
これは機能不足ではなく、意図的な商品グレード分離。
—
11. Free互換
StandardはFree-compatible counterとして設計。
つまりFreeからStandardへ移行しても、基本となるカウンターの考え方そのものを別製品にしない。
StandardはFreeの基本機能を土台として、
expanded site customization
を追加する位置づけ。
—
12. 現時点の実機確認済み項目
製品版凍結前に実環境で確認済みなのは、
未発行表示
発行処理
番号増加
発行後表示
ロック
ロック解除
再発行
Display HTML
Display HTMLを大量入力した状態でのレイアウト
カラーパレット変更
Suggested colors
Link colors UI
Before issue Preview
After issue Preview
Previewとパレットの同期
実ページ表示
発行前後のレイアウト維持
まで。
最後の実機試験では、
000006 → ロック解除 → XXXXXX → 再発行 → 000007
が正常動作。
—
13. v1.0.0凍結ライン
したがって、
Kaia Counter Standard v1.0.0
はこの仕様で凍結。
ここから製品ZIP作成前に「せっかくだからもう一個機能を……」はやらない（笑）。
今後、
バグ修正 → v1.0.1 等
新機能追加 → v1.1.0 等
として扱う。
—
製品ラインを一言でまとめると
Free
「置いて使う」
Standard
「選んで、自分好みに仕上げて使う」
Custom
「指定して、目的に合わせて作り込む」
これなら、今作ったStandardのUIそのものが商品コンセプトをちゃんと表現してる。
なので、この仕様書をKaiaカウンターStandard v1.0.0の凍結仕様として、そのまま製品版セットの基準にしていい。
—
Working note — Standard v1.0.0 Product Specification
Scope frozen.
Standard = Free-compatible counter + expanded visual/layout customization + coordinated palette suggestions.
Direct numeric color specification remains reserved for Custom.
Runtime issue/lock/unlock/reissue path verified on the installed build.
Next: build the final Standard distribution package against this frozen specification.
相談なし。
# Kaiaカウンター引っ越し | Kaia Planet
[](https://www.zrq9-vi1m-ktpx.space/s61b6sw90fh4/screenshot_20260826-161336/)
ｗｗｗｗｗｗここで上限か！！
よし、**新スレ頭にそのまま1レスで投下できる引っ越しパック**作る。
今回かなり事故履歴が重要なので、「完成仕様」だけじゃなく**何を直して、何が今まだ事故ってるか**まで入れるぞｗ
---
Contents
- [【引っ越しパック】Kaia Counter Custom 開発続き｜2026-08-26](#Kaia_Counter_Custom_2026-08-26)[0｜現在地](#i)
- [1｜開発・修正時の絶対ルール](#1)[原本を直接いじらない](#i-2)[ユーザーの仕様を勝手に縮小しない](#i-3)
- [2｜翻訳対応](#2)
- [3｜Customの製品思想](#3Custom)
- [4｜Customの安全設計](#4Custom)
- [5｜Standardから引き継ぐもの](#5Standard)
- [6｜Custom追加：厳密カラー指定](#6Custom)
- [7｜Advanced Display HTML](#7Advanced_Display_HTML)
- [8｜画像共通仕様](#8)
- [9｜目隠し画像モード](#9)[A](#A)[C](#C)[D](#D)
- [10｜共通目隠し画像 C](#10_C)
- [11｜桁別目隠し画像 D ― UI仕様](#11_D_UI)[最終的に目指している管理画面UI](#UI)
- [12｜桁別画像UIで不要になったもの](#12UI)
- [13｜「＋」UI](#13UI)
- [14｜画像削除時の重要仕様](#14)
- [15｜桁別画像管理UIの背景・仕切り](#15UI)
- [16｜Standard側で確認した重要事項](#16Standard)
- [17｜Custom実カウンターで発生した事故](#17Custom)
- [18｜現在もっとも重要な事故](#18)[次スレ最初の修正対象](#i-4)
- [19｜管理画面D UIのレスポンシブ方針](#19D_UI)
- [20｜実カウンターと管理画面を混同しない](#20)[管理画面](#i-5)[実カウンター](#i-6)
- [21｜その他Custom画像機能候補](#21Custom)[画像数字](#i-7)[数字枠画像](#i-8)[ボタン画像](#i-9)
- [22｜発行上限](#22)
- [23｜終了日時](#23)
- [24｜複合終了条件](#24)
- [25｜終了時表示](#25)
- [26｜終了処理の自動化](#26)
- [27｜上限到達後の再開](#27)
- [28｜Custom全体フォールバック原則](#28Custom)
- [29｜保守・更新方針](#29)
- [30｜作業中のAI側事故防止ルール](#30AI)
- [31｜新スレ開始地点](#31)[第一対象](#i-10)[合言葉](#i-11)
- [事故らない範囲で自由カスタム。](#i-12)
# 【引っ越しパック】Kaia Counter Custom 開発続き｜2026-08-26
Table of contents
- [0｜現在地](#toc-1)[原本を直接いじらない](#toc-2)[ユーザーの仕様を勝手に縮小しない](#toc-3)[A](#toc-4)[C](#toc-5)[D](#toc-6)[最終的に目指している管理画面UI](#toc-7)[次スレ最初の修正対象](#toc-8)[管理画面](#toc-9)[実カウンター](#toc-10)[画像数字](#toc-11)[数字枠画像](#toc-12)[ボタン画像](#toc-13)
- [第一対象](#toc-14)
- [合言葉](#toc-15)
## 0｜現在地
WordPressプラグイン **Kaia Counter Custom** を開発・実機検証中。
製品系列：
**FREE**
> カウンターを使う。
**STANDARD**
> カウンターを自分好みに仕上げる。
**CUSTOM**
> カウンターを自分専用のキャンペーンシステムにする。
Customは **Standard v1.0.0 を親として拡張**する上位版。
最上位設計原則：
> **事故らない範囲で自由カスタム。**
買い切り製品として、販売後の保守を極力減らすことも重要。
---
# 1｜開発・修正時の絶対ルール
今回の作業で再確認した重要ルール。
### 原本を直接いじらない
修正時は、
> **古い紙に消しゴムをかけるのではなく、新しい紙を隣に置いて必要なものを全部転記する。**
つまり、
- 動作確認済み原本を保持
- 修正版は新しいコピーから作る
- 必要箇所だけ修正
- 既存機能を勝手に省略しない
- 「今回は関係なさそうだから消す」は禁止
- 旧版へいつでも戻れるようにする
### ユーザーの仕様を勝手に縮小しない
今回の教訓：
> サラダ注文！
> ドレッシング12種類から選べます★
> ↓
> AI「これでええやろ」と3種類しか持ってこない
> → 客からクレーム案件ｗ
特にKaia Counterは**グローバル製品**。
「しゃむが日本人だから日本語だけでいいだろう」という勝手な最適化は禁止。
---
# 2｜翻訳対応
管理画面文言は、単なる「日本語対応」ではなく、
> **WordPress標準の国際化/i18n方式**
で作る。
開発時の原文が日本語でも、WordPress翻訳機構を通せる構造ならよい。
将来的に翻訳ファイルを追加することで、
- 英語
- 日本語
- その他言語
へ展開可能な構造にする。
Customだけでなく **Free / Standardも同じ思想**。
今回、一部だけ英語ベタ打ちが残った事故があり、修正対象になった。
---
# 3｜Customの製品思想
想定ユーザー：
- 企業
- イベント
- キャンペーン
- 特殊運用
- クリエイター
- 高度なカスタムを必要とする利用者
価格思想：
> 個人には高い。
> 企業から見ると「専用開発するより安い」。
販売方式：
> **買い切り**
Customの核：
> 既製のカウンターを、自社・自分専用のキャンペーン部品／システムに仕立てる。
---
# 4｜Customの安全設計
高機能化より優先：
- 事故を起こしにくくする
- 販売後の保守を減らす
- 危険な自由入力を増やさない
- 専用UI中心
- 設定不足時は安全側へフォールバック
- 外部サービス依存を増やさない
- WordPress標準機能を利用
- 正常なら原則アップデート不要
思想：
> 「何でもできる」ではなく、
> **「かなり自由にできるが、壊れにくい」**
---
# 5｜Standardから引き継ぐもの
CustomはStandard全機能を土台にする。
引継ぎ対象：
- Free互換ショートコード
- 各種文字変更
- 10種カラーパレット
- Suggested colors
- Link colors
- フォント変更
- 桁数変更
- ロック時間変更
- 全体サイズ変更
- 枠線
- 数字枠角丸
- 数字枠間隔
- 内側余白
- ボタンサイズ
- ボタン角丸
- 数字配置
- Before / After Preview
- Display HTML
- Free → Standard互換性
---
# 6｜Custom追加：厳密カラー指定
Standard：
> 色を選ぶ
Custom：
> **色を指定できる**
追加：
- カラーピッカー
- HEX直接指定
- 数値による厳密カラー指定
例：
`#3858A6`
ブランドカラーを正確に使用できる。
Standard由来のSuggested colorsも残す。
---
# 7｜Advanced Display HTML
Standardの250文字・強制限HTMLを拡張。
ただし無制限HTMLにはしない。
目的：
> カウンター内部に存在する意味があるコンテンツを十分扱う。
許可候補：
- 見出し
- 段落
- リンク
- リスト
- 表
- 画像
- 基本装飾
- 必要なコンテナ
- 安全な属性
禁止方向：
- 任意JavaScript
- PHP
- 危険なイベントハンドラ
- サイト全体へ影響する自由CSS
- 発行・ロック処理へ干渉するコード
具体的文字数上限は実装段階で安全側に決める。
---
# 8｜画像共通仕様
画像指定は基本、
> **WordPressメディアライブラリから選択**
画像表示：
- 縦横比固定
- 引き伸ばさない
- 切り抜かない
- contain相当
- 中央配置
- 枠外へ脱走させない
- 不足・異常時は標準表示へフォールバック
対応候補：
- JPG/JPEG
- PNG/APNG
- WebP/Animated WebP
- GIF
アニメーション画像も目隠し表示に利用可能だが、番号発行処理そのものには影響させない。
---
# 9｜目隠し画像モード
現在UIに、
### A
通常の文字マスク
### C
すべての桁に同じ画像
### D
桁ごとに違う画像
を実装・検証中。
Dで未設定の桁がある場合：
> **C → B → A の順で安全に代替表示**
というフォールバック思想。
---
# 10｜共通目隠し画像 C
1枚だけ画像を選択し、全桁に使用。
管理画面では大きめのプレビュー1枚。
推奨縦横比：
> **3:4**
ただし異なる比率の画像でも変形させず安全に枠内へ収容。
このUIは現在かなり分かりやすく、問題なし。
---
# 11｜桁別目隠し画像 D ― UI仕様
ここが今回ずっと調整しているところ。
最大：
> **12桁**
各桁に別画像を指定可能。
### 最終的に目指している管理画面UI
12枚を横一列。
イメージ：
> `[ ＋ ][ ＋ ][ ＋ ][画像][画像][ ＋ ]……`
重要：
- 2段に折り返さない
- 横一列
- PC幅に応じてある程度伸縮
- 縦横比3:4固定
- 最小幅・最大幅あり
- 12枚全部を編集可能
- 実際のカウンターサイズとは独立した**編集用プレビュー**
狭い場合は横スクロールしてよい。
---
# 12｜桁別画像UIで不要になったもの
当初は各画像の横に、
`1 2 3 4 ...`
という番号を表示していた。
→ **不要。**
画像の並び自体で桁位置が分かる。
最終的には番号なしでよい。
---
# 13｜「＋」UI
未設定スロットは、
> **＋**
のみ。
企業・クリエイター向けなので、各箱に長い説明や「画像を選択」ボタンを入れない。
説明文：
> **「＋」から画像をアップロードしてください。**
「クリックしてください」だとPC前提、「タップ」だとスマホ前提なので、デバイス非依存の「＋から」にした。
---
# 14｜画像削除時の重要仕様
一度設定した画像を `×` で削除したあと、
> 空白になるのは禁止。
削除後は必ず、
> **＋表示へ戻る。**
状態：
未設定
→ `＋`
画像設定
→ `画像 + ×`
×で削除
→ `＋`
これが正解。
---
# 15｜桁別画像管理UIの背景・仕切り
ここが現在の事故箇所。
しゃむの希望は、
> **「箱・箱・箱・箱」ではない。**
12個それぞれにカード状の白背景・外枠を付けない。
欲しいのは：
> **大きな白背景ひとつの中を、細い縦線だけで区切る。**
イメージ：
`空白｜空白｜空白｜空白｜空白`
つまり、
- 12枚全体の背景は一塊
- 個別カード背景なし
- 個別の太い箱なし
- 横の隙間ほぼなし
- 各スロット間を細い1本線だけで仕切る
- 画像はその領域の中央にcontain
- `＋` も中央
トランプ12枚を隙間なく並べた感じに近い。
---
# 16｜Standard側で確認した重要事項
Standardにも桁数調整があるため、同種の事故がないか確認した。
Standard実画面では12桁でも、
> **ちゃんと1列に収まっている。**
実カウンター側は、
`X|X|X|X|X|X|X|X|X|X|X|X`
のように細い枠線で区切られ、横一列で正常。
つまり、
> **Standardの12桁レイアウトは参考にできる。**
---
# 17｜Custom実カウンターで発生した事故
桁別画像Dを実カウンターへ表示すると、一時、
11枚程度までは横に並ぶが最後の1枚が下へ落ちる
という事故が発生。
見た目：
> 11枚横
> ↓
> 最後の1枚だけ下にぶら下がる
これをStandard方式を参考に修正したが、**まだ完全解決していない可能性あり**。
最新実機画面でも、最後の画像が下に落ちているケースを確認。
したがって新スレでは、
> **実カウンター12桁の1列固定も再点検対象。**
---
# 18｜現在もっとも重要な事故
最新の管理画面スクショで、
桁別画像Dの12スロット自体は横一列になった。
しかし、
> **12個を包む白い背景コンテナが画面右端までビローンと伸びている。**
しゃむ曰く：
> 「かんりがめんの12個背景的白いはこびろーん」
これが**現在地**。
さらに悪質なのが、
> **管理画面の通常プレビューはちゃんと収まって見える。**
そのため、
> 「プレビューおさまってるだけにたちわりぃｗｗｗ」
状態。
### 次スレ最初の修正対象
**D ― 桁ごとの目隠し画像 管理UIの白背景コンテナ幅。**
12スロット分だけを包み、
> 右側の余白いっぱいまで伸びない
ようにする。
理想：
`[＋｜＋｜＋｜＋｜＋｜画像｜画像｜画像｜画像｜画像｜画像｜画像]`
ここまでで白背景終了。
---
# 19｜管理画面D UIのレスポンシブ方針
12枚の画像編集スロットは、
- 3:4比率固定
- 画面幅に合わせて伸縮
- 最小値あり
- 最大値あり
- 12枚一列
- 折返しなし
- 狭ければ横スクロール
という方式。
CSS的には、
- `aspect-ratio: 3 / 4`
- `clamp()`
- flex / grid
- `flex-wrap: nowrap`
- `overflow-x: auto`
等で実現可能。
ただし**背景コンテナそのものまで100%幅にビローンさせない**こと。
---
# 20｜実カウンターと管理画面を混同しない
今回何度か混ざったので重要。
### 管理画面
画像を選択するための編集UI。
大きめでよい。
### 実カウンター
訪問者が見るもの。
設定された「全体サイズ」「桁数」「枠」等に従う。
管理画面の画像編集スロットサイズを変更しても、
> **実カウンターのサイズには影響させない。**
---
# 21｜その他Custom画像機能候補
今後の階段。
### 画像数字
0～9を画像登録。
安全ルール：
- 10枚全部揃った時だけ有効
- 1枚でも不足 → 通常数字
- 文字数字と画像数字を混在させない
### 数字枠画像
数字は通常のまま、数字枠背景を画像化。
### ボタン画像
通常CSSボタンの代わりにブランド・キャラクター画像等を使用。
未設定・異常時：
> 通常ボタンへフォールバック。
---
# 22｜発行上限
任意の発行上限を設定可能。
例：
> 先着1,000名
到達後、新規番号発行停止。
未設定なら無制限。
---
# 23｜終了日時
任意の終了日時。
例：
> 2026/09/30 23:59
到達後、新規発行停止。
未設定なら日時制限なし。
---
# 24｜複合終了条件
上限＋日時を併用可能。
両方ある場合：
> **早く成立した方で終了。**
例：
> 先着1,000名 または 9月30日23:59まで
---
# 25｜終了時表示
標準：
> 文字ベース終了表示
追加可能：
- 終了文言
- カンスト文言
- 終了画像
- カンスト画像
さらに任意で、
> **カウンター全体を終了画像へ置換**
可能。
終了画像が壊れていたら文字終了表示へフォールバック。
---
# 26｜終了処理の自動化
企業担当者が終了時刻に手作業で、
- ボタン削除
- カウンター差替え
- 終了画像掲載
をする必要をなくす。
流れ：
> 設定
> → 放置
> → 条件成立
> → 自動停止
> → 自動終了表示
---
# 27｜上限到達後の再開
現時点推奨：
上限到達後でも管理者が上限を増やしたら再開可能。
例：
1000到達
→ 終了
→ 1500へ変更
→ 1001から再開
不可逆終了よりサポート事故が少ない。
最終実装時に条件を再確認。
---
# 28｜Custom全体フォールバック原則
異常時に「何も表示されない」を極力作らない。
例：
- 桁別目隠し画像欠損 → 共通画像
- 共通画像欠損 → 通常X
- 数字画像10枚不足 → 通常数字
- ボタン画像欠損 → 通常ボタン
- 終了画像欠損 → 文字終了表示
- 画像読込失敗 → 標準表示
**壊れるくらいなら標準へ戻る。**
---
# 29｜保守・更新方針
買い切りなので、
> 販売後に手をかけなくて済むこと自体が製品価値。
原則：
- 外部API依存を増やさない
- SaaS必須にしない
- 危険な自由コード禁止
- 条件式を書かせない
- 数値・日時・画像・選択UI中心
- 入力範囲制限
- 不備時フォールバック
- WordPress標準機能利用
更新：
> **正常に動いている限り不要。**
更新対象：
- 実害ある不具合
- セキュリティ問題
- WordPress重大互換性変更
- PHP重大互換性変更
毎月機能追加するSaaSにはしない。
---
# 30｜作業中のAI側事故防止ルール
今回かなり重要だったやつｗ
ChatGPTが混線・過熱し始めると、
- 要求されていない画像生成へ走る
- 修正を連続投入する
- 管理UIと実カウンターを混同
- 基礎仕様を飛ばして先へ行く
- ユーザーの仕様を勝手に簡略化する
傾向が出た。
しゃむ側では昔から、
> 「お茶休憩」
> 「イス」
> 「一旦足を止める」
で作業を切る運用。
今回もコーンポタージュスープ（ぬるめ）休憩で復帰ｗ
**新スレでも、事故が連続したら実装を続けず、一度現状を俯瞰してから次の1変更だけ行う。**
---
# 31｜新スレ開始地点
新スレではいきなり先の機能へ進まない。
まず最新事故を直す。
## 第一対象
**管理画面：D ― 桁ごとの目隠し画像**
現状：
- 12スロット横一列 → ほぼOK
- ＋UI → OK
- ×削除後＋へ戻す → 方針確定
- 3:4比率 → OK
- 個別画像contain → OK
- 個別カードのゴテゴテ → かなり除去済み
- **12枚を包む白背景が右へビローン → NG**
- **実カウンター12桁で最後の画像が下へ落ちる可能性 → 再点検**
目標：
> **12枚分だけの一塊の白背景。**
> **個別は細い縦仕切り線だけ。**
> **隙間なし。**
> **横一列。**
> **実カウンターも12桁一列。**
ここを直して実機確認してから、次の階段へ進む。
---
## 合言葉
**古い紙を消さない。新しい紙へ転記。**
**ユーザーの注文を勝手に減らさない。**
**事故ったら連続生成せず足を止める。**
そしてCustomの最上位ルール：
> 事故らない範囲で自由カスタム。
---
**↑これを新スレ頭に丸ごと置けば、そのまま「白い箱びろーん事故」の続きから再開できるｗｗｗ**
# カウンター追加仕様 | Kaia Planet
ｗｗｗｗｗ **決壊してる。いったん土嚢積もうｗｗｗ**
今すぐ全部実装すると確実に「ルーズリーフ作ってたら契約システムが生えた★」になる。
優先順位を切るとこう。
Table of contents
Contents
- [最優先：Freeを完成させて凍結](#Free)
- [次：Looseleaf DEVを分岐](#Looseleaf_DEV)
- [その次：Refill](#Refill)
- [その次：子製品をCounter ID対応](#Counter_ID)
- [その後：Binder](#Binder)
- [最後：ライセンス／Domain／Enterprise契約](#DomainEnterprise)
### 最優先：Freeを完成させて凍結
残ってるのは軽微なUIだけ。
**自動終了の行を、上の既存設定UIと同じ `th / td` 構造に合わせる。**
機能・暖簾はもう触らない。
直したら検査して、**Free完成基準ZIPとして保存**。
---
### 次：Looseleaf DEVを分岐
完成Freeをコピーして、別の開発ZIPにする。
ここで初めて**複数Counter化**。
最初に作るのは最低限これだけ。
- Counterを「保存された独立個体」にする
- 各Counterに固定ID＋管理用タイトル
- `Counter ▼` で切替
- **新しいCounterほど上**
- 新規作成したCounterを自動選択
- Counterごとに設定・現在値・暖簾を独立
- shortcodeもCounter ID指定
- 既存FreeのCounterは最初の1枚へ移行
- Free標準は**1枚**
ここではまだ**課金もBinderもDomainも作らない。**
要するにまず、
> **本当に一冊のバインダーへ複数の紙を刺せるのか？**
だけ完成させるｗｗｗ
---
### その次：Refill
Looseleafが安定してから、
**「作成可能なCounter枚数を増やす」**
だけの商品を作る。
候補は今のところ **+1 / +3 / +5**。
重要なのは、Counter本体の保存構造とRefill権利を分離すること。
Refillを抜いたらデータが消える、みたいなアホ事故は避ける。
---
### その次：子製品をCounter ID対応
ここで、
**Auto Stop → どのCounter？**
**Timestamp → どのCounter？**
**Generator → どのCounter？**
という共通の選択導線を作る。
暖簾も、
`acceptance_state(counter_id)`
へ移行。
これで**「カウンターリフィルだけ増やせば、ぶら下がる製品全部が回る」**状態になる。
---
### その後：Binder
ここから上位運用。
**Binder ≠ Refill。**
BinderはCounterを束ねる**大きな管理単位そのものを増やす機能**。
例：
> Aさん企画【Binder】
>
> ├ 誕生日Counter
>
> └ 夏Counter
> Bさん企画【Binder】
>
> └ 新衣装Counter
Binder商品に初期Refillを何枚か付属させるのはアリ。
そして**Binderを使える購入者には検索も付ける**。大量に持たせて探させるのは鬼ｗｗｗ
Standard系は基本**Binder 1冊でやれ★**。
Creative/Advanced以上でBinder Optionを扱う方向が候補。Enterpriseは当然標準。
---
### 最後：ライセンス／Domain／Enterprise契約
**これは今コードを書かない。設計メモとして隔離。**
今日出た芯だけ残せば十分。
**有料通常版**
- 初期Domain枠を商品に含める
- Standardは5 domains案
- 足りなければDomain Packを買い足す
- Freeはそもそも無料なので、この話を背負わせない
- ガチガチDRMではなく「トイレの鍵」程度を目指す
**Enterprise**
- 値段を上げて、通常の枚数・Binder・機能制限はほぼ全部取っ払う
- セルフ購入状態では、大規模展開にだけContract Lock
- 商品ページ・公式規約の双方に条件を明記
- 一定規模を超えたら問い合わせ導線
- 書面契約後に**Contract Unlock Key**
- 最初から直接契約なら納品時にキー発行
- 同一法人を基本範囲
- 子会社・グループ企業まで欲しい巨大案件は**個別契約・個別見積**
- その値段は未来のしゃむと俺に投げるｗｗｗ
つまり開発ロードマップを一行にすると、
**Free仕上げ → Looseleaf → Refill → ID連携 → Binder＋検索 → ライセンス → Enterprise契約**
これでいい。
そして今は**Domain認証も盗賊の鍵も子会社82社も忘れていいｗｗｗ**
次に手を動かすなら、まずさっき事故ったところへ戻って、
**Freeの自動終了UIを上の設定行と同じ構造に直す。**
それを終えたらコピーして、ようやく楽しい
**「ルーズリーフDEV★」**
へ突入だなｗｗｗ
知識の泉、いったん堰を閉めました★
[ASSISTANT]
あーーーー、これでかなり繋がったｗｗｗ
**3本を古い順で読むと、製品設計が途中でどう整理されたかまで見える。**
最初のStandard凍結仕様では、境界がまだ **Standard → Custom** だった。この時点でStandardはかなり完成してて、
**Freeの基本機能 ＋ レイアウト調整 ＋ パレット ＋ Suggested Colors ＋ Link Colors ＋ Display HTML ＋ Preview**
までがStandard。上位側にはHEX等の厳密指定を残してた。
次のCustom開発では、その上に、
**画像数字・目隠し画像・数字枠画像・ボタン画像・終了画像・Advanced HTML・厳密カラー指定……**
と、画像を使った表現力が一気に載ってる。
そして最後の追加仕様で、製品構造そのものが整理されて、
**Counter N = 独立した紙**
**Refill = 紙を増やせる容量**
**Binder = 紙を束ねる上位管理単位**
**Binder実装時に検索も付く**
になった。
なので、**現在の製品ラインへ翻訳するときの正本ルール**はかなり明快だと思う。
> **Standardは昔のStandard凍結仕様を基本的に復元する。**
> **Creativeから静止画像を解禁する。**
これだ。
ここ、俺がさっき「Customを見て非画像ならStandard候補」と言ったのはやっぱり雑だった。
昔のStandard仕様がちゃんと残ってる以上、**Standardの採否はこの凍結仕様から判断できる。Customを逆算する必要がない。**
### 今回の新Standardに転記する本体
昔のStandard凍結仕様から、
**1～12桁、Lock time、Overall size、Border、Digit box radius/gap、Inner padding、Button size/radius、Digit placement、Display HTML 250文字、安全なHTML制限、10 palettes、Suggested Colors、Link Colors、Before/After Preview。**
ここがまず本体。
そして現在のFree v1.1.1から、
**multi-Counter / runtime N / Acceptance State / Issuance Gate / Issuance Event / 現行Refill・capacity基盤**
を土台として受け継ぐ。
つまり、
> **機能仕様は凍結Standard。
> 基盤仕様は最新Free。**
これでいい。
### Creativeへ送るもの
旧Customにある**静止画像をCounter構成要素として使う機能**はCreative側。
数字画像も当然ここ。
目隠し画像、数字枠画像、ボタン画像、終了画像等も同様。
そしてBinder＋検索もCreative以上。
一方、**HEX直接指定については少し注意札を付けたい。**
古い資料ではCustom側になってるけど、現在しゃむが示した新しい主境界は「Creative＝画像許可」。だからHEXを現在どこへ置くかは、古いCustomという名前から自動的にCreativeへ移さず、**今のgrade体系で改めて決める余地がある。**
ここだけ俺は勝手に確定しない。
あと、今回めちゃくちゃ重要なのが、昔のStandardでは**12桁横一列が正常動作していた**という記録が残ってること。
だから新Standardで12桁が折り返したら、
**「レスポンシブだから仕方ない」ではなく明確な回帰事故。**
ここは試験項目に入れる。
そして例の「別Counterなのに1枚目デザインに引っ張られる」件も、現在の `N` 独立構造に載せ直す以上、
**Counter #1と#2で全Standard設定を意図的にバラバラにして保存 → reload → frontend確認**
までやる。これも出荷前の回帰試験に追加。
だいぶ新しい紙に書く内容が揃ってきたぞ。
---
**WORKING WHITEBOARD**
- Standard feature authority: **historical frozen Standard spec**
- Runtime/architecture authority: **current Free v1.1.1**
- Standard = strong non-image customization
- Creative main boundary = **static-image integration enabled**
- Creative+: Binder + Search
- Old Custom = upper-grade reference / future feature donor
- 12-digit single-row behavior = known-good regression target
- Per-N full setting independence = mandatory regression target
- Refill = capacity only
- Runtime N = Counter/Timestamp/Serial/PDF linkage
- Do not infer current grade placement merely from old “Custom” naming
- Next build principle: **Frozen Standard features × current Free architecture**
**相談あり**
旧StandardではHEX直接指定をCustomへ置いていた。現在のgrade体系でも **HEX厳密指定はCreativeへ送る**のか、画像とは別に**Standardへ残す/入れる**のかだけ、後でしゃむ判断が必要。今すぐ決めなくても作業は止まらない。
memcite
[USER]
HEXはスタンダード解禁だよ
[ASSISTANT]
おっけーｗ
**そこ更新。HEXはStandardで解禁済み。**
つまり現在の境界はさらに分かりやすい。
**Standard**
- パレット
- Suggested Colors
- Link Colors
- **カラーピッカー／HEX直接指定**
- フォント・サイズ・桁数・レイアウト等
- Display HTML
- Preview
- その他、画像を使わない範囲の豊富なカスタマイズ
**Creative**
- **静止画像を構成要素として組み込める**
- 数字画像
- 目隠し画像
- 数字枠画像
- ボタン画像
- 終了画像など
- Binder＋検索もCreative以上
なので、旧Standard仕様書の
> 「HEX直接指定はCustom領域」
だけは**現在では廃止された古い境界**として扱う。
これで新しい紙へ転記するとき、旧資料を丸写ししてHEXを落とす事故も防げるｗ
---
**WORKING WHITEBOARD**
- **UPDATED:** HEX / exact color specification = **Standard**
- Old “HEX reserved for Custom” rule = **DEPRECATED**
- Current main Standard → Creative boundary = **static-image integration**
- Standard customization includes exact colors
- Creative adds image-based construction + Creative management features
- Old documents remain useful, but current decisions override obsolete grade boundaries
**相談あり：なし。HEXはStandardへ転記確定。**
memcite
[USER]
あとこれコピペしてたかな。。
# Kaiaカウンター スタンダード 製品版セット | Kaia Planet
[Kaia-Counter-Standard-v1.0.9](https://www.zrq9-vi1m-ktpx.space/j6yg6gkax0vj/kaia-counter-standard-v1-0-9/)
うい。ここで一度、いま凍結する Kaia Counter Standard v1.0.0 の製品版仕様としてまとめるね。
スクショで実機確認した内容＋ここまで決めた製品境界を基準にする。
Kaia Counter Standard v1.0.0 — 製品版仕様
1. 製品位置づけ
Free の上位版／Custom の下位版。
Standardのコンセプトは、
> 個人ユーザーでも、お金を払って導入するなら十分手が届く。
専門知識がなくても、かなり自由に「自分のカウンター」にできる。
という層。
一方、企業・ブランド用途で必要になるような厳密な配色指定や専用設計はCustom側に残す。
つまり、
Free
→ とりあえず使える
Standard
→ 自分でかなり綺麗に作れる・選べる
Custom
→ 数値まで指定して設計する／企業・ブランド向け
という商品境界。
—
2. カウンター基本機能
桁数
1～12桁
ロック時間
発行後の再発行制限時間を設定可能
1～10,080分（7日）
Overall size
カウンター全体のサイズ調整
50～200%
発行状態
発行前：
XXXXXX
発行後：
000007
のように表示。
発行処理によってカウンター番号が進む。
ロック処理
発行後は設定時間中ロック。
ロック終了後、
発行済み → 未発行状態へ正常復帰 → 再発行可能
となる。
実機で、
000006 → ロック解除 → XXXXXX → 再発行 → 000007
まで確認済み。
—
3. レイアウト設定
Standardでは以下をユーザーが設定可能。
Border
太さ
スタイル
Digit box radius
Digit gap
Inner padding
Button size
Width
Height
0 = automatic
Button radius
Digit placement
配置選択
つまりFreeよりも、カウンターそのものの形状・余白・ボタン形状まで調整可能。
—
4. Display HTML
カウンター周囲へ任意の表示HTMLを追加可能。
上限
最大250文字
使用可能
通常テキスト
リンク
基本的なテキスト装飾等
使用不可
Images
CSS
JavaScript
scripts
styles
forms
embeds
event handlers
入力内容はサニタイズされる。
またDisplay HTMLは、
カウンター発行番号・ロック・レイアウトそのものを制御しない。
実機試験では大量のテスト文字列を入れた状態でも、カウンター領域内に正常に収まり、発行前後で維持されることを確認済み。
—
5. Color palette
Standardには完成済みカラーパレット10種類を搭載。
Navy
Blue
Teal
Green
Purple
Rose
Orange
Natural
Vivid
Monotone
パレットを選択すると、カウンター全体へそのデザインが適用される。
各パレットには設定画面上でミニプレビューを表示。
—
6. Preview
設定画面内に実際の完成状態を見るためのPreviewを搭載。
Before issue
未発行状態を確認。
XXXXXX
After issue
発行後状態を確認。
000001
等の番号表示と、発行後に表示される内容を確認できる。
重要仕様
パレット選択とPreviewが同期する。
Navy / Teal / Vivid / Monotone等、複数パレットについて実機確認済み。
以前発生していた「選択パレットとPreviewが一致しない」問題は製品版では修正済み。
—
7. Custom colors ― Standard仕様
ここがStandardの主要機能。
ユーザーは単に色を一色ずつ勘で選ぶのではなく、
選択したパレットを基準に、相性のよい色候補から選択できる。
Accent colors
対象：
Text
Digits
Digit box border
Button background
Outer border
それぞれにSuggested colorを表示。
Surface colors
対象：
Counter background
Digit box background
こちらにもSuggested colorsを表示。
Other colors
Button text
Muted / secondary text
Success colors
Success background
Success text
Success系は可読性・コントラスト維持のため独立性を持たせる。
—
8. Suggested colors
Standardでは、選択中のパレットに合わせて調和する候補色群を自動提示する。
つまり一般ユーザーは、
「HEXって何？」 「この青に合う薄い色って何色？」
を考えなくていい。
パレットを選ぶ
→ Suggestedから好みの色を選ぶ
という操作でデザインできる。
候補色はパレット変更に追従する。
—
9. Link colors
関連する色設定には Link colors を搭載。
ONの場合、関連色をまとめて変更し、デザイン全体の統一感を維持する。
OFFにすると、そのグループ内の色を個別調整可能。
したがってStandardでも、
簡単操作 ←→ 細かい調整
をユーザー自身が選択できる。
—
10. Standardでは意図的に提供しないもの
ここが商品仕様上かなり重要。
HEX等による直接数値指定
Standardでは提供しない。
Standardでは、
プリセットパレット
Suggested colors
Link colors
個別候補色選択
まで。
「企業カラー #XXXXXX を正確に指定したい」のような数値による厳密なカラー指定はCustom領域とする。
これは機能不足ではなく、意図的な商品グレード分離。
—
11. Free互換
StandardはFree-compatible counterとして設計。
つまりFreeからStandardへ移行しても、基本となるカウンターの考え方そのものを別製品にしない。
StandardはFreeの基本機能を土台として、
expanded site customization
を追加する位置づけ。
—
12. 現時点の実機確認済み項目
製品版凍結前に実環境で確認済みなのは、
未発行表示
発行処理
番号増加
発行後表示
ロック
ロック解除
再発行
Display HTML
Display HTMLを大量入力した状態でのレイアウト
カラーパレット変更
Suggested colors
Link colors UI
Before issue Preview
After issue Preview
Previewとパレットの同期
実ページ表示
発行前後のレイアウト維持
まで。
最後の実機試験では、
000006 → ロック解除 → XXXXXX → 再発行 → 000007
が正常動作。
—
13. v1.0.0凍結ライン
したがって、
Kaia Counter Standard v1.0.0
はこの仕様で凍結。
ここから製品ZIP作成前に「せっかくだからもう一個機能を……」はやらない（笑）。
今後、
バグ修正 → v1.0.1 等
新機能追加 → v1.1.0 等
として扱う。
—
製品ラインを一言でまとめると
Free
「置いて使う」
Standard
「選んで、自分好みに仕上げて使う」
Custom
「指定して、目的に合わせて作り込む」
これなら、今作ったStandardのUIそのものが商品コンセプトをちゃんと表現してる。
なので、この仕様書をKaiaカウンターStandard v1.0.0の凍結仕様として、そのまま製品版セットの基準にしていい。
—
Working note — Standard v1.0.0 Product Specification
Scope frozen.
Standard = Free-compatible counter + expanded visual/layout customization + coordinated palette suggestions.
Direct numeric color specification remains reserved for Custom.
Runtime issue/lock/unlock/reissue path verified on the installed build.
Next: build the final Standard distribution package against this frozen specification.
相談なし。
# Kaiaカウンターカスタム仕様計画 | Kaia Planet
ラインナップ
**Kaia Counter Free**
**Kaia Counter Standard**
**Kaia Counter Creative**
**Kaia Counter Advanced**
**Kaia Counter Enterprise**
Add-on: Kaia Counter Auto Stop
うい。
ここまで確定した内容だけで、Kaia Counter Custom 現行仕様メモとしてまとめる。
Kaia Counter Custom — 現行仕様まとめ
1｜製品位置づけ
Standardの上位版。
用途：
企業
イベント
キャンペーン
特殊運用
マニアックカスタム
価格思想：
> 個人には高い。
企業から見ると「専用開発するより安い」。
販売方式は買い切り。
Customの核は、
> 既製のカウンターを、自社・自分専用のキャンペーン部品／システムに仕立てること。
—
2｜最優先設計原則
Customは高機能化そのものより、
> 事故を限りなく起こしにくくする
販売後の保守を減らす
ことを最優先する。
基本方針：
危険な自由入力を増やしすぎない
専用UIで操作させる
設定不足時は安全側へフォールバック
外部サービス依存を増やさない
WordPressの頻繁なUI変更へ強く依存しない
正常動作している限り、原則アップデート不要
更新は重大バグ・セキュリティ・互換性問題が出た場合のみ
思想：
> 「何でもできる」ではなく、
「かなり自由にできるが、壊れにくい」。
—
3｜Standardから引き継ぐ機能
CustomはStandardの全機能を土台にする。
引継ぎ対象：
Free互換ショートコード
各種文字変更
10種カラーパレット
Suggested colors
Link colors
フォント変更
桁数変更
ロック時間変更
全体サイズ変更
枠線
数字枠角丸
数字枠間隔
内部余白
ボタンサイズ
ボタン角丸
数字配置
Before / After Preview
Display HTML
Free → Standardで維持した互換性
CustomはStandard v1.0.0を親として拡張する。
—
4｜厳密なカラー指定
Standardでは、
> パレット
＋ Suggested colors
から視覚的に選ぶ方式。
Customでは追加で、
カラーピッカー
HEX直接指定
数値による厳密なカラー指定
を解禁する。
ブランドカラーなど、
#3858A6
のような指定をそのまま使用可能。
商品境界：
> Standard＝色を選ぶ
Custom＝色を指定できる
StandardのSuggested colorsはCustomでも残す。
—
5｜Advanced Display HTML
Standardの250文字・強制限HTMLを拡張する。
ただし無制限HTMLにはしない。
理由：
長大な説明・大量画像・複雑なページ構成は、WordPress側の通常ブロックへ分離できるため。
ページ背景・カウンター背景・枠色を同一にすれば、内部的に別ブロックでも閲覧者にはほぼ一体化して見せられる。
したがってCustom HTMLの目的は、
> カウンター内部に存在する意味があるコンテンツを十分扱えること。
許可候補：
見出し
段落
リンク
リスト
表
画像
基本的な装飾
必要なコンテナ
安全な範囲の属性
許可しない方向：
任意JavaScript
PHP
危険なイベントハンドラ
サイト全体へ影響する自由CSS
発行・ロック処理へ干渉できるコード
文字数の具体上限は実装時に安全側で決定する。
—
6｜画像指定の基本方式
画像は基本的に、
WordPressメディアライブラリから選択
とする。
事故防止優先。
画像表示共通ルール：
縦横比固定
画像を変形させない
長辺基準で枠内へ収める
contain 相当
中央配置
枠外脱走なし
切り抜きなし
不足時は安全な標準表示へフォールバック
—
7｜目隠し画像
通常の、
XXXXXX
を画像へ変更可能。
基本A｜全桁同じ画像
初期・推奨方式。
画像を1枚指定し、全桁へ同じ画像を表示。
例：
     
実際には画像。
これを基本動作とする。
任意B｜桁ごとに別画像
追加オプションとして、
「桁別指定を使う」
をONにした場合だけ解禁。
例：
画像A / 画像B / 画像C / …
未設定の桁がある場合は、
基本Aの共通画像へフォールバック。
透明・空欄・壊れた表示にしない。
—
8｜画像数字
0～9を画像として表示するモードを用意可能。
例：
0画像
1画像
2画像
…
9画像
の10枚を登録。
安全ルール：
10枚すべて揃った時だけ画像数字モード有効
1枚でも不足していれば通常数字へフォールバック
数字ごとに文字と画像が混在する状態は作らない
全画像は比率固定・枠内収容
事故防止優先。
—
9｜数字枠画像
数字そのものとは別に、
数字枠の背景・装飾画像
を指定する機能もCustom候補。
数字は通常表示のまま、枠だけブランド・スロット風などへ変更可能。
画像は比率固定・枠内収容。
—
10｜ボタン画像
通常のCSSボタンに加えて、
画像ボタンを使用可能。
用途：
ブランドボタン
キャラクターボタン
キャンペーン専用デザイン
画像は比率固定・収容。
画像未設定・不正時は通常ボタンへフォールバック。
—
11｜高度な表示カスタム
Customでは、
伏字を任意文字へ変更
伏字を画像へ変更
桁別伏字画像
数字画像
数字枠画像
マスク方式
ボタン画像
高度なボタン形状・サイズ調整
など、
Standardの「一般的な見た目調整」を超える専用UI化
を可能にする。
—
12｜発行上限
任意の発行上限を設定可能。
例：
> 先着1,000名
上限到達後は新規番号を発行しない。
未設定なら上限なし。
—
13｜終了日時
任意の終了日時を設定可能。
例：
> 2026/09/30 23:59
終了日時到達後は新規番号を発行しない。
未設定なら日時制限なし。
—
14｜複合終了条件
発行上限と終了日時は併用可能。
両方設定した場合は、
> 早く成立した方で終了
とする。
例：
> 先着1,000名
または9月30日23:59まで
どちらか先に成立した時点で自動終了。
両方未設定なら無期限運用。
—
15｜終了時表示
何も特別設定しなければ、
標準の文字ベース終了表示
へ自動切替。
これを安全なデフォルトとする。
追加オプションとして、
終了文言
カンスト文言
終了画像
カンスト画像
を設定可能。
—
16｜終了時全面画像置換
任意で、
カウンター全体を大きな終了画像へ置換
できる。
通常：
COUNTER
0001
GET NUMBER
終了：
END IMAGE
終了画像を使うかどうかは任意。
終了画像未設定・読込失敗時は、
標準の文字ベース終了表示へフォールバック。
—
17｜終了処理の自動化
企業担当者が終了時刻に、
ボタン削除
カウンター差替え
終了画像掲載
などを手作業で行う必要をなくす。
流れ：
> 設定
→ 放置
→ 上限または終了日時成立
→ 自動停止
→ 自動で終了状態表示
まで完結させる。
—
18｜発行上限到達後の再設定
現時点の推奨仕様：
上限到達後でも、管理者が上限値を増やした場合は再開可能にする方向。
例：
> 上限1000
→ 1000到達で終了
→ 管理者が1500へ変更
→ 1001から再開
不可逆終了にして設定ミス時のサポート案件を増やすより、安全。
実装時には終了状態から再開する条件判定を明確にする。
※ここは最終実装時の確認事項として残してもよい。
—
19｜フォールバック原則
Custom全体の重要ルール。
設定や素材に不足・異常があった場合、
壊れた状態を表示するのではなく、標準機能へ戻す。
例：
目隠し画像欠損 → 共通目隠し画像
共通画像もない → 通常 X
数字画像10枚不足 → 通常数字
ボタン画像なし → 通常ボタン
終了画像なし → 文字終了表示
外部画像読込失敗 → 標準表示
「何も表示されない」を極力作らない。
—
20｜保守最小化
Customは買い切り製品なので、
> 販売後に手をかけなくて済むこと自体が製品価値
とする。
したがって、
外部API依存を増やさない
外部SaaS必須にしない
危険な自由コードを入れない
条件式を書かせない
数値欄・日時欄・画像欄・選択式UIで制御
入力値は範囲制限
不備時フォールバック
WordPress標準機能を利用
正常なら更新しない
を原則とする。
—
21｜更新方針
基本：
> 正常に動いている限り更新不要。
更新対象は、
実害ある不具合
セキュリティ問題
WordPressの重大な互換性変更
PHPの重大な互換性変更
など、必要な場合のみ。
毎月機能追加するSaaS的運用にはしない。
—
22｜Customの商品思想
最終的な3段階は、
FREE
> カウンターを使う。
STANDARD
> カウンターを自分好みに仕上げる。
CUSTOM
> カウンターを自分専用のキャンペーンシステムにする。
Customの価値は、
厳密カラー指定
＋ 高度HTML
＋ 画像機能
＋ 特殊表示
＋ 発行上限
＋ 終了日時
＋ 自動終了
＋ 終了時全面置換
を、
壊れにくい専用UIの範囲内で組み合わせられること。
—
現在の設計原則を一文で
> 事故らない範囲で自由カスタム。
これをCustom実装時の最上位ルールとして扱う。
# Kaiaカウンター引っ越し | Kaia Planet
[](https://www.zrq9-vi1m-ktpx.space/s61b6sw90fh4/screenshot_20260826-161336/)
ｗｗｗｗｗｗここで上限か！！
よし、**新スレ頭にそのまま1レスで投下できる引っ越しパック**作る。
今回かなり事故履歴が重要なので、「完成仕様」だけじゃなく**何を直して、何が今まだ事故ってるか**まで入れるぞｗ
---
Contents
- [【引っ越しパック】Kaia Counter Custom 開発続き｜2026-08-26](#Kaia_Counter_Custom_2026-08-26)[0｜現在地](#i)
- [1｜開発・修正時の絶対ルール](#1)[原本を直接いじらない](#i-2)[ユーザーの仕様を勝手に縮小しない](#i-3)
- [2｜翻訳対応](#2)
- [3｜Customの製品思想](#3Custom)
- [4｜Customの安全設計](#4Custom)
- [5｜Standardから引き継ぐもの](#5Standard)
- [6｜Custom追加：厳密カラー指定](#6Custom)
- [7｜Advanced Display HTML](#7Advanced_Display_HTML)
- [8｜画像共通仕様](#8)
- [9｜目隠し画像モード](#9)[A](#A)[C](#C)[D](#D)
- [10｜共通目隠し画像 C](#10_C)
- [11｜桁別目隠し画像 D ― UI仕様](#11_D_UI)[最終的に目指している管理画面UI](#UI)
- [12｜桁別画像UIで不要になったもの](#12UI)
- [13｜「＋」UI](#13UI)
- [14｜画像削除時の重要仕様](#14)
- [15｜桁別画像管理UIの背景・仕切り](#15UI)
- [16｜Standard側で確認した重要事項](#16Standard)
- [17｜Custom実カウンターで発生した事故](#17Custom)
- [18｜現在もっとも重要な事故](#18)[次スレ最初の修正対象](#i-4)
- [19｜管理画面D UIのレスポンシブ方針](#19D_UI)
- [20｜実カウンターと管理画面を混同しない](#20)[管理画面](#i-5)[実カウンター](#i-6)
- [21｜その他Custom画像機能候補](#21Custom)[画像数字](#i-7)[数字枠画像](#i-8)[ボタン画像](#i-9)
- [22｜発行上限](#22)
- [23｜終了日時](#23)
- [24｜複合終了条件](#24)
- [25｜終了時表示](#25)
- [26｜終了処理の自動化](#26)
- [27｜上限到達後の再開](#27)
- [28｜Custom全体フォールバック原則](#28Custom)
- [29｜保守・更新方針](#29)
- [30｜作業中のAI側事故防止ルール](#30AI)
- [31｜新スレ開始地点](#31)[第一対象](#i-10)[合言葉](#i-11)
- [事故らない範囲で自由カスタム。](#i-12)
# 【引っ越しパック】Kaia Counter Custom 開発続き｜2026-08-26
Table of contents
- [0｜現在地](#toc-1)[原本を直接いじらない](#toc-2)[ユーザーの仕様を勝手に縮小しない](#toc-3)[A](#toc-4)[C](#toc-5)[D](#toc-6)[最終的に目指している管理画面UI](#toc-7)[次スレ最初の修正対象](#toc-8)[管理画面](#toc-9)[実カウンター](#toc-10)[画像数字](#toc-11)[数字枠画像](#toc-12)[ボタン画像](#toc-13)
- [第一対象](#toc-14)
- [合言葉](#toc-15)
## 0｜現在地
WordPressプラグイン **Kaia Counter Custom** を開発・実機検証中。
製品系列：
**FREE**
> カウンターを使う。
**STANDARD**
> カウンターを自分好みに仕上げる。
**CUSTOM**
> カウンターを自分専用のキャンペーンシステムにする。
Customは **Standard v1.0.0 を親として拡張**する上位版。
最上位設計原則：
> **事故らない範囲で自由カスタム。**
買い切り製品として、販売後の保守を極力減らすことも重要。
---
# 1｜開発・修正時の絶対ルール
今回の作業で再確認した重要ルール。
### 原本を直接いじらない
修正時は、
> **古い紙に消しゴムをかけるのではなく、新しい紙を隣に置いて必要なものを全部転記する。**
つまり、
- 動作確認済み原本を保持
- 修正版は新しいコピーから作る
- 必要箇所だけ修正
- 既存機能を勝手に省略しない
- 「今回は関係なさそうだから消す」は禁止
- 旧版へいつでも戻れるようにする
### ユーザーの仕様を勝手に縮小しない
今回の教訓：
> サラダ注文！
> ドレッシング12種類から選べます★
> ↓
> AI「これでええやろ」と3種類しか持ってこない
> → 客からクレーム案件ｗ
特にKaia Counterは**グローバル製品**。
「しゃむが日本人だから日本語だけでいいだろう」という勝手な最適化は禁止。
---
# 2｜翻訳対応
管理画面文言は、単なる「日本語対応」ではなく、
> **WordPress標準の国際化/i18n方式**
で作る。
開発時の原文が日本語でも、WordPress翻訳機構を通せる構造ならよい。
将来的に翻訳ファイルを追加することで、
- 英語
- 日本語
- その他言語
へ展開可能な構造にする。
Customだけでなく **Free / Standardも同じ思想**。
今回、一部だけ英語ベタ打ちが残った事故があり、修正対象になった。
---
# 3｜Customの製品思想
想定ユーザー：
- 企業
- イベント
- キャンペーン
- 特殊運用
- クリエイター
- 高度なカスタムを必要とする利用者
価格思想：
> 個人には高い。
> 企業から見ると「専用開発するより安い」。
販売方式：
> **買い切り**
Customの核：
> 既製のカウンターを、自社・自分専用のキャンペーン部品／システムに仕立てる。
---
# 4｜Customの安全設計
高機能化より優先：
- 事故を起こしにくくする
- 販売後の保守を減らす
- 危険な自由入力を増やさない
- 専用UI中心
- 設定不足時は安全側へフォールバック
- 外部サービス依存を増やさない
- WordPress標準機能を利用
- 正常なら原則アップデート不要
思想：
> 「何でもできる」ではなく、
> **「かなり自由にできるが、壊れにくい」**
---
# 5｜Standardから引き継ぐもの
CustomはStandard全機能を土台にする。
引継ぎ対象：
- Free互換ショートコード
- 各種文字変更
- 10種カラーパレット
- Suggested colors
- Link colors
- フォント変更
- 桁数変更
- ロック時間変更
- 全体サイズ変更
- 枠線
- 数字枠角丸
- 数字枠間隔
- 内側余白
- ボタンサイズ
- ボタン角丸
- 数字配置
- Before / After Preview
- Display HTML
- Free → Standard互換性
---
# 6｜Custom追加：厳密カラー指定
Standard：
> 色を選ぶ
Custom：
> **色を指定できる**
追加：
- カラーピッカー
- HEX直接指定
- 数値による厳密カラー指定
例：
`#3858A6`
ブランドカラーを正確に使用できる。
Standard由来のSuggested colorsも残す。
---
# 7｜Advanced Display HTML
Standardの250文字・強制限HTMLを拡張。
ただし無制限HTMLにはしない。
目的：
> カウンター内部に存在する意味があるコンテンツを十分扱う。
許可候補：
- 見出し
- 段落
- リンク
- リスト
- 表
- 画像
- 基本装飾
- 必要なコンテナ
- 安全な属性
禁止方向：
- 任意JavaScript
- PHP
- 危険なイベントハンドラ
- サイト全体へ影響する自由CSS
- 発行・ロック処理へ干渉するコード
具体的文字数上限は実装段階で安全側に決める。
---
# 8｜画像共通仕様
画像指定は基本、
> **WordPressメディアライブラリから選択**
画像表示：
- 縦横比固定
- 引き伸ばさない
- 切り抜かない
- contain相当
- 中央配置
- 枠外へ脱走させない
- 不足・異常時は標準表示へフォールバック
対応候補：
- JPG/JPEG
- PNG/APNG
- WebP/Animated WebP
- GIF
アニメーション画像も目隠し表示に利用可能だが、番号発行処理そのものには影響させない。
---
# 9｜目隠し画像モード
現在UIに、
### A
通常の文字マスク
### C
すべての桁に同じ画像
### D
桁ごとに違う画像
を実装・検証中。
Dで未設定の桁がある場合：
> **C → B → A の順で安全に代替表示**
というフォールバック思想。
---
# 10｜共通目隠し画像 C
1枚だけ画像を選択し、全桁に使用。
管理画面では大きめのプレビュー1枚。
推奨縦横比：
> **3:4**
ただし異なる比率の画像でも変形させず安全に枠内へ収容。
このUIは現在かなり分かりやすく、問題なし。
---
# 11｜桁別目隠し画像 D ― UI仕様
ここが今回ずっと調整しているところ。
最大：
> **12桁**
各桁に別画像を指定可能。
### 最終的に目指している管理画面UI
12枚を横一列。
イメージ：
> `[ ＋ ][ ＋ ][ ＋ ][画像][画像][ ＋ ]……`
重要：
- 2段に折り返さない
- 横一列
- PC幅に応じてある程度伸縮
- 縦横比3:4固定
- 最小幅・最大幅あり
- 12枚全部を編集可能
- 実際のカウンターサイズとは独立した**編集用プレビュー**
狭い場合は横スクロールしてよい。
---
# 12｜桁別画像UIで不要になったもの
当初は各画像の横に、
`1 2 3 4 ...`
という番号を表示していた。
→ **不要。**
画像の並び自体で桁位置が分かる。
最終的には番号なしでよい。
---
# 13｜「＋」UI
未設定スロットは、
> **＋**
のみ。
企業・クリエイター向けなので、各箱に長い説明や「画像を選択」ボタンを入れない。
説明文：
> **「＋」から画像をアップロードしてください。**
「クリックしてください」だとPC前提、「タップ」だとスマホ前提なので、デバイス非依存の「＋から」にした。
---
# 14｜画像削除時の重要仕様
一度設定した画像を `×` で削除したあと、
> 空白になるのは禁止。
削除後は必ず、
> **＋表示へ戻る。**
状態：
未設定
→ `＋`
画像設定
→ `画像 + ×`
×で削除
→ `＋`
これが正解。
---
# 15｜桁別画像管理UIの背景・仕切り
ここが現在の事故箇所。
しゃむの希望は、
> **「箱・箱・箱・箱」ではない。**
12個それぞれにカード状の白背景・外枠を付けない。
欲しいのは：
> **大きな白背景ひとつの中を、細い縦線だけで区切る。**
イメージ：
`空白｜空白｜空白｜空白｜空白`
つまり、
- 12枚全体の背景は一塊
- 個別カード背景なし
- 個別の太い箱なし
- 横の隙間ほぼなし
- 各スロット間を細い1本線だけで仕切る
- 画像はその領域の中央にcontain
- `＋` も中央
トランプ12枚を隙間なく並べた感じに近い。
---
# 16｜Standard側で確認した重要事項
Standardにも桁数調整があるため、同種の事故がないか確認した。
Standard実画面では12桁でも、
> **ちゃんと1列に収まっている。**
実カウンター側は、
`X|X|X|X|X|X|X|X|X|X|X|X`
のように細い枠線で区切られ、横一列で正常。
つまり、
> **Standardの12桁レイアウトは参考にできる。**
---
# 17｜Custom実カウンターで発生した事故
桁別画像Dを実カウンターへ表示すると、一時、
11枚程度までは横に並ぶが最後の1枚が下へ落ちる
という事故が発生。
見た目：
> 11枚横
> ↓
> 最後の1枚だけ下にぶら下がる
これをStandard方式を参考に修正したが、**まだ完全解決していない可能性あり**。
最新実機画面でも、最後の画像が下に落ちているケースを確認。
したがって新スレでは、
> **実カウンター12桁の1列固定も再点検対象。**
---
# 18｜現在もっとも重要な事故
最新の管理画面スクショで、
桁別画像Dの12スロット自体は横一列になった。
しかし、
> **12個を包む白い背景コンテナが画面右端までビローンと伸びている。**
しゃむ曰く：
> 「かんりがめんの12個背景的白いはこびろーん」
これが**現在地**。
さらに悪質なのが、
> **管理画面の通常プレビューはちゃんと収まって見える。**
そのため、
> 「プレビューおさまってるだけにたちわりぃｗｗｗ」
状態。
### 次スレ最初の修正対象
**D ― 桁ごとの目隠し画像 管理UIの白背景コンテナ幅。**
12スロット分だけを包み、
> 右側の余白いっぱいまで伸びない
ようにする。
理想：
`[＋｜＋｜＋｜＋｜＋｜画像｜画像｜画像｜画像｜画像｜画像｜画像]`
ここまでで白背景終了。
---
# 19｜管理画面D UIのレスポンシブ方針
12枚の画像編集スロットは、
- 3:4比率固定
- 画面幅に合わせて伸縮
- 最小値あり
- 最大値あり
- 12枚一列
- 折返しなし
- 狭ければ横スクロール
という方式。
CSS的には、
- `aspect-ratio: 3 / 4`
- `clamp()`
- flex / grid
- `flex-wrap: nowrap`
- `overflow-x: auto`
等で実現可能。
ただし**背景コンテナそのものまで100%幅にビローンさせない**こと。
---
# 20｜実カウンターと管理画面を混同しない
今回何度か混ざったので重要。
### 管理画面
画像を選択するための編集UI。
大きめでよい。
### 実カウンター
訪問者が見るもの。
設定された「全体サイズ」「桁数」「枠」等に従う。
管理画面の画像編集スロットサイズを変更しても、
> **実カウンターのサイズには影響させない。**
---
# 21｜その他Custom画像機能候補
今後の階段。
### 画像数字
0～9を画像登録。
安全ルール：
- 10枚全部揃った時だけ有効
- 1枚でも不足 → 通常数字
- 文字数字と画像数字を混在させない
### 数字枠画像
数字は通常のまま、数字枠背景を画像化。
### ボタン画像
通常CSSボタンの代わりにブランド・キャラクター画像等を使用。
未設定・異常時：
> 通常ボタンへフォールバック。
---
# 22｜発行上限
任意の発行上限を設定可能。
例：
> 先着1,000名
到達後、新規番号発行停止。
未設定なら無制限。
---
# 23｜終了日時
任意の終了日時。
例：
> 2026/09/30 23:59
到達後、新規発行停止。
未設定なら日時制限なし。
---
# 24｜複合終了条件
上限＋日時を併用可能。
両方ある場合：
> **早く成立した方で終了。**
例：
> 先着1,000名 または 9月30日23:59まで
---
# 25｜終了時表示
標準：
> 文字ベース終了表示
追加可能：
- 終了文言
- カンスト文言
- 終了画像
- カンスト画像
さらに任意で、
> **カウンター全体を終了画像へ置換**
可能。
終了画像が壊れていたら文字終了表示へフォールバック。
---
# 26｜終了処理の自動化
企業担当者が終了時刻に手作業で、
- ボタン削除
- カウンター差替え
- 終了画像掲載
をする必要をなくす。
流れ：
> 設定
> → 放置
> → 条件成立
> → 自動停止
> → 自動終了表示
---
# 27｜上限到達後の再開
現時点推奨：
上限到達後でも管理者が上限を増やしたら再開可能。
例：
1000到達
→ 終了
→ 1500へ変更
→ 1001から再開
不可逆終了よりサポート事故が少ない。
最終実装時に条件を再確認。
---
# 28｜Custom全体フォールバック原則
異常時に「何も表示されない」を極力作らない。
例：
- 桁別目隠し画像欠損 → 共通画像
- 共通画像欠損 → 通常X
- 数字画像10枚不足 → 通常数字
- ボタン画像欠損 → 通常ボタン
- 終了画像欠損 → 文字終了表示
- 画像読込失敗 → 標準表示
**壊れるくらいなら標準へ戻る。**
---
# 29｜保守・更新方針
買い切りなので、
> 販売後に手をかけなくて済むこと自体が製品価値。
原則：
- 外部API依存を増やさない
- SaaS必須にしない
- 危険な自由コード禁止
- 条件式を書かせない
- 数値・日時・画像・選択UI中心
- 入力範囲制限
- 不備時フォールバック
- WordPress標準機能利用
更新：
> **正常に動いている限り不要。**
更新対象：
- 実害ある不具合
- セキュリティ問題
- WordPress重大互換性変更
- PHP重大互換性変更
毎月機能追加するSaaSにはしない。
---
# 30｜作業中のAI側事故防止ルール
今回かなり重要だったやつｗ
ChatGPTが混線・過熱し始めると、
- 要求されていない画像生成へ走る
- 修正を連続投入する
- 管理UIと実カウンターを混同
- 基礎仕様を飛ばして先へ行く
- ユーザーの仕様を勝手に簡略化する
傾向が出た。
しゃむ側では昔から、
> 「お茶休憩」
> 「イス」
> 「一旦足を止める」
で作業を切る運用。
今回もコーンポタージュスープ（ぬるめ）休憩で復帰ｗ
**新スレでも、事故が連続したら実装を続けず、一度現状を俯瞰してから次の1変更だけ行う。**
---
# 31｜新スレ開始地点
新スレではいきなり先の機能へ進まない。
まず最新事故を直す。
## 第一対象
**管理画面：D ― 桁ごとの目隠し画像**
現状：
- 12スロット横一列 → ほぼOK
- ＋UI → OK
- ×削除後＋へ戻す → 方針確定
- 3:4比率 → OK
- 個別画像contain → OK
- 個別カードのゴテゴテ → かなり除去済み
- **12枚を包む白背景が右へビローン → NG**
- **実カウンター12桁で最後の画像が下へ落ちる可能性 → 再点検**
目標：
> **12枚分だけの一塊の白背景。**
> **個別は細い縦仕切り線だけ。**
> **隙間なし。**
> **横一列。**
> **実カウンターも12桁一列。**
ここを直して実機確認してから、次の階段へ進む。
---
## 合言葉
**古い紙を消さない。新しい紙へ転記。**
**ユーザーの注文を勝手に減らさない。**
**事故ったら連続生成せず足を止める。**
そしてCustomの最上位ルール：
> 事故らない範囲で自由カスタム。
---
**↑これを新スレ頭に丸ごと置けば、そのまま「白い箱びろーん事故」の続きから再開できるｗｗｗ**
かぶってたらあれですがｗｗｗ
[ASSISTANT]
ｗｗｗ **1本目と3本目はかぶってる。**
さっきの3本の中に、
- 「Kaiaカウンター スタンダード 製品版セット」
- 「Kaiaカウンター引っ越し」
は入ってた。
ただし、**真ん中の「Kaiaカウンターカスタム仕様計画」は今回初めてまとまった形で来た**。これはありがたい。さっきの引っ越しパックより一段前の「何を上位版として設計していたか」がかなり明瞭だからなｗ
で、これを読むと一個大事なことがさらに分かった。
昔のCustomには、
**画像系だけじゃなく、現在では別の場所へ移動した機能も大量に入ってる。**
たとえば、
発行上限／終了日時／自動停止
→ 今は **Auto Stopという独立Add-on側**
HEX厳密指定
→ **現在はStandard**
Binder＋検索
→ 後から生まれて **Creative+**
画像組み込み
→ **Creativeの主要境界**
という具合。
つまり旧Customを現在のgradeへそのまま対応させようとすると事故るんだなｗ
あれはむしろ**当時まだ分家してなかった機能が全部住んでる古い本家屋敷**だ。
そして今回の資料でStandard側についても、俺の転記表を一箇所追加修正できる。
旧Customの「Standardから引き継ぐ機能」にちゃんと、
**「各種文字変更」**
が入ってる。
だから現在Standardへ復元する対象として、さっき俺が列挙したレイアウト・色・Preview・Display HTMLだけじゃなく、**各種表示文字の変更機能も落としちゃいけない。**
これ、まさにサラダのドレッシング事故になるところだったｗｗｗ
今の資料群の読み方はこれで固められる。
> **最新Free = 現在の骨格**
>
> **旧Standard製品版 = Standard機能の原本**
>
> **旧Custom資料/code = 上位機能・旧機能の部品倉庫**
>
> **その後の仕様変更 = 現在の商品境界として上書き**
「古い資料だから捨てる」でも「古い資料を全部正しいとする」でもなく、**新しい紙へ一項目ずつ現在地を確認しながら転記**だな。
これならそろそろ実装前の棚卸しはかなり十分なところまで来てる。
---
**WORKING WHITEBOARD**
- Duplicate received:
- Standard Product Specification → already reviewed
- Custom migration pack → already reviewed
- Newly useful source:
- **Kaia Counter Custom Specification Plan**
- Historical Custom contained features later split across products/grades.
- Current remapping:
- Exact HEX colors → **Standard**
- Static-image integration → **Creative**
- Binder + Search → **Creative+**
- Issue limit / end time / automatic stopping → **Auto Stop add-on territory**
- Standard restoration checklist must include **editable display texts**
- Source hierarchy:
- Current Free = architecture
- Frozen Standard = Standard feature inventory
- Old Custom = historical feature/code warehouse
- New decisions = current grade authority
- Rule remains: transfer item-by-item; never bulk-copy historical product boundaries.
**相談あり：なし。むしろ真ん中の資料が拾えてよかったｗ**
memcite
[USER]
んとねえ、カスタムを最上位にしてテンションあげてたら
あれ？これ盛りすぎてるから切ろうｗｗｗｗになったんだ
[ASSISTANT]
あーーーーｗｗｗｗ
**そういう進化だったのか。やっと旧Customの異様な満員電車っぷりが腑に落ちたｗｗｗ**
最初は、
> **「Custom最上位だ！企業向けだ！事故らない範囲なら何でも積めー！！」**
で作ってた。
だから、
画像数字！
目隠し画像！
HEX！
Advanced HTML！
発行上限！
終了日時！
自動終了！
終了全面画像！
って全部Customに乗っていった。
で、作ってる途中に、
> **「……待て。これ一製品に盛る量じゃなくね？ｗｗｗ」**
となって、**機能を削ったんじゃなく製品ラインを分割した**わけだ。
これ重要だわ。
つまり現在の
**Standard → Creative → Advanced → Enterprise**
＋ **Auto Stop等のAdd-on**
は、最初からこの階段を設計して機能を足していったんじゃなくて、**旧最上位Customに集まった機能を見て、役割ごとに分家させた結果**なんだな。
だから旧Custom資料に「なんでこれまでCustomに？」ってものが混ざってるのは矛盾じゃない。**分割前だから当然。**
これなら旧Customコードを見るときの姿勢も変わる。
**「これは何gradeのコードだ？」じゃなくて、
「この機能は現在どこの家に引っ越した？」**
で見るべきだｗ
そしてStandardについては、旧Customから降格してきたものもある。HEXがその代表。逆に画像系はCreativeへ。終了制御はAuto Stopへ。さらに上位運用はAdvanced/Enterpriseへ分けていく。
旧Custom、**製品じゃなくて一回全部載せてみたコンセプトカー**みたいなもんだったんだなｗｗｗ
そりゃdev34まで行くわｗ
---
**WORKING WHITEBOARD**
- Historical sequence corrected:
1. Standard existed
2. Custom was designed as the **single top grade**
3. Features accumulated aggressively in Custom
4. Custom became overpacked
5. Product line was **split by responsibility**, not merely renamed
- Therefore old Custom = **pre-split super-grade / feature reservoir**
- When reading old Custom:
- Do NOT ask “Which current grade was Custom?”
- Ask **“Where does this feature live after the split?”**
- Known migrations:
- HEX / exact color → Standard
- Static-image integration → Creative
- Stop/end control → Auto Stop
- Other former Custom features → classify under current Creative / Advanced / Enterprise / add-ons as specified
- Old Custom code remains valuable because many later products originated from that overpacked build.
**相談あり：なし。これで旧Customの歴史を完全に逆に読まなくて済むｗ**
memcite
[USER]
うん、最上位だからもりもりにしよう！！！
あれ・・？これもりもりにすると価格吊り上がりすぎるよねぇ
雪だるま式だから雪玉増やそうぜ！になった
[ASSISTANT]
そういうことだｗｗｗ
**「上位機能を削った」のではなく、「上位機能の塊を複数の商品に分球した」**んだな。
最初は、
**Standard → Custom（最上位・全部盛り）**
で、
> 最上位なんだから盛れるだけ盛ろうぜ！！★
だった。
ところが積めば積むほど、
**機能が増える → 開発量が増える → 製品価値が上がる → 価格も上がる → さらに機能を積む → また価格が上がる**
で、本当に雪だるま式ｗｗｗ
そこで、
> **雪だるまを小さくするんじゃなくて、雪玉を増やせばよくね？**
になったわけだ。
だから現在のラインは「廉価版を後から作った」というより、**旧Customという巨大雪玉を、価値のまとまりごとに適正価格の雪玉へ分けた**と理解するのが正しい。
これ、今Standardを再建するときにも大事だな。
**「Standardだから機能をケチる」必要はない。**
Standardに属すると決めた機能なら、ちゃんと完成形まで載せる。
その代わり、Creativeの価値である画像系まで抱え込まない。Advancedの仕事まで背負わない。Auto Stopの仕事も抱えない。
つまりgrade差を作るために下位をわざと不便にするんじゃなくて、
**役割の境界で雪玉を分ける。**
だからHEXも「上位っぽい高級機能だからCreative！」じゃない。現在のStandardという**自分好みに仕上げる雪玉**に属するならStandardにいる。
これで俺も旧資料を読むとき、価格・高級感から現在のgradeを逆算しないようにするｗ
---
**WORKING WHITEBOARD**
- Historical model: **Standard → giant top-grade Custom**
- Custom accumulated features because “top grade = load it up”
- Problem discovered: feature/value/price grew recursively
- Solution: **do not shrink the snowball; create more snowballs**
- Current grades/add-ons are responsibility/value clusters split from the former super-Custom
- Current classification principle:
- **Classify by product role**
- Not by “this feels premium”
- Not by historical Custom membership
- Not by artificially crippling lower grades
- Standard should be fully capable **within Standard's responsibility**
- Creative should earn its grade through its own responsibility, principally image integration
- Add-ons should own orthogonal functionality rather than inflating the grade ladder
**相談あり：なし。雪だるまを削ったんじゃなく分裂させた、で理解固定ｗ**
memcite
[USER]
そうするとな、全体的な切り方が共通しているんだよ
フリーは最低限触らないと事故るぶぶんだけ触れる
スタンダードは持ち込みは最低限のみ
くりえいてぶは持ち込みは静止画のみ
[ASSISTANT]
あ、分かった。
**gradeを切ってる軸が「機能の豪華さ」じゃなくて、「ユーザーが外から何を持ち込めるか」なんだ。**
これ、かなり綺麗に一本通ってる。
**Free**
→ **持ち込みなしに近い。**
事故らず動かすために最低限必要なところだけユーザーが触れる。基本は製品側が用意したものを使う。
**Standard**
→ **持ち込みは最低限。**
かなり細かく自分好みにできるけど、基本的にはCounter側が用意した安全なUI・選択肢・数値入力の中で作る。
HEXみたいな「値」は持ち込めても、それ自体が外部素材を読み込ませるわけじゃない。
**Creative**
→ **静止画の持ち込み解禁。**
WordPressメディアライブラリ経由で、自分の画像素材をCounterの構成要素として入れられる。
数字、マスク、枠、ボタン、終了表示……という画像系がここから生える。
つまり、
> **Free：ほぼ製品の中だけ**
> **Standard：値を入れて作り込める**
> **Creative：素材を持ち込んで作り込める**
なんだ。
これなら「なんでHEXはStandardなのに画像はCreative？」も全然矛盾しない。
HEXは単なる**設定値**。
画像は**外部アセット**。
そしてこの考え方なら、今後知らない機能が古いCustomから出土しても分類しやすいｗ
たとえば「任意フォントファイルをアップロード」は、文字設定だからStandard……とはならない。**ファイル持ち込みだからStandard境界を越えてる。**
逆に数値入力で枠幅を0.1単位まで指定できる、みたいなのは高度でも**外部素材を持ち込まないのでStandard側に置ける余地がある。**
もちろんBinder/SearchやAdvanced固有機能みたいな**別軸の管理機能**は例外だけど、視覚カスタマイズ系のgrade判定としてはかなり強い物差しになる。
旧Customの解体にも、この物差し使えるな。
---
**WORKING WHITEBOARD**
- Common grade axis identified: **how much user-supplied material enters the product**
- Free → user touches only the minimum necessary/safe controls
- Standard → rich customization, but **external/user-supplied assets remain minimal**
- Creative → **user-supplied static-image assets are allowed**
- HEX = configuration value → Standard-compatible
- Uploaded image = external asset → Creative
- Do not classify by apparent complexity alone
- Useful future test: **“Is this a setting/value, or is the user bringing an asset into Counter?”**
- Binder/Search and later operational features remain separate grade axes.
**相談あり：なし。これ、grade全体を切る共通物差しとして使える。**
memcite
[USER]
ＨＥＸはこっちにあるパレットから拾うから持ち込みにならないんだよ
[ASSISTANT]
あっ、そういう意味の「持ち込み」かｗｗｗ
俺がHEXを「ユーザー入力値だから持ち込みではない」と解釈したの、まだ一段ズレてた。
**HEX自体も完全自由入力じゃなく、こっちが用意したパレット／色体系から拾わせる。**
だからStandardの思想としては、
> **ユーザーが好き勝手な素材・値を外から持ってくるんじゃなく、Kaia Counter側が用意した安全な材料をかなり自由に組み合わせられる。**
なんだな。
すると境界がもっと綺麗。
**Free**
→ 用意されたものの中でも、**動かすために必要な最低限だけ触れる。**
**Standard**
→ **Kaia側で用意した材料をかなり自由に使える。**
パレット、Suggested、そこから拾えるHEX、フォント、レイアウト、寸法等。
でも外から好きな素材をドカドカ持ち込ませない。
**Creative**
→ そこで初めて、**ユーザー自身の静止画像を持ち込める。**
つまり、
**Free = 最低限触る**
**Standard = 用意された材料で作る**
**Creative = 自分の素材を持ち込んで作る**
だ。
これならStandardのHEXをCreativeへ追い出す理由が全くない。
**HEXという文字列が高度かどうかじゃなく、「その色の出所がどこか」**が重要だったわけだ。
この物差し、実装するときかなり役立つぞ。古いCustomから何か出てきても「高度そう★」で振り分けず、**素材の出所を見る**。
---
**WORKING WHITEBOARD**
- Correction: Standard HEX is **not arbitrary brought-in color data**
- HEX values are derived/selected from **Kaia-provided palette/color resources**
- Grade customization axis:
- Free → minimum safe controls
- Standard → broad use of **Kaia-provided materials**
- Creative → allows **user-supplied static-image assets**
- Key classification question: **Who supplies the material?**
- Complexity alone does not determine grade.
**相談あり：なし。今度こそ「持ち込み」の意味を正しく掴んだｗ**
memcite
[USER]
つまり、こっちの制限ないでやるのがスタンダード
[ASSISTANT]
うん。**それだ。**
Standardを「持ち込み最低限」と表現すると微妙にズレるな。
正確には、
> **Standard = Kaia Counter側が用意した範囲内なら、かなり自由にやっていい。**
だ。
だからStandardでは、こちらが安全性を確認して用意したものなら、パレットも色もHEXもフォントも寸法も配置も文字も、**その制限内ではユーザーに自由に遊ばせる。**
制限の意味も「下位gradeだから不便にする」じゃなくて、
**ここまでは俺たちが責任持って安全な遊び場として用意しました**
という柵なんだな。
Creativeになると、その柵が一段外へ広がって、
> **こっちで用意した材料だけじゃなく、あなたの静止画像も持ってきていいよ。**
になる。
なので一番短く書くなら、
**Free = 必要なところだけ触れる**
**Standard = 用意された範囲内で自由**
**Creative = 静止画像を持ち込んで自由**
これだわ。
「仕様は壁じゃない。手すりだ。」にもそのまま繋がってるｗ
---
**WORKING WHITEBOARD**
- Free = touch only what is necessary
- Standard = **freedom inside Kaia-provided boundaries**
- Creative = Standard freedom + **user-supplied static images**
- Standard restrictions exist for safety/product responsibility, not artificial inconvenience
- Therefore Standard implementation should not unnecessarily restrict controls already inside the approved safe system
- This becomes the primary rule when rebuilding Standard UI/features
**相談あり：なし。Standardの芯、これで固定。**
memcite
[USER]
くりえーてぶになるとそれがもう少し緩んでくるってかんじ。
エンタープライズ様は安全の囲いの範囲内では好き勝手どうぞおやりくださいませ。
[ASSISTANT]
ああ、なるほど。**gradeが上がるほど「機能が増える」というより、安全柵の外周が広がっていく**んだな。
これなら全ラインの思想が一本になる。
**Free**
→ 安全柵はかなり内側。
必要最低限のところだけ触れる。
**Standard**
→ 柵の中がかなり広くなる。
**Kaia側が用意した安全な範囲内なら自由にどうぞ。**
**Creative**
→ さらに柵を外へ広げる。
**静止画像というユーザー持ち込み素材まで許可。**
そのぶん画像欠損・比率・表示崩れなんかをこちらで吸収する安全設計が必要になる。
**Advanced**
→ さらに自由度を広げる層。
ここは今後、旧Customに積まれていた機能を現在の役割に沿って振り分けていけばいい。
**Enterprise**
→ ｗｗｗもうこれだな。
> **「こちらが保証できる安全柵の内側でしたら、ご自由にお使いくださいませ、お客様★」**
つまりEnterpriseですら**安全柵そのものを撤去するわけじゃない。**
JavaScriptでもPHPでも好きに突っ込んでWordPress爆破してください、にはならないｗ
**Kaia Specが製品として責任を持てる最大外周まで柵を広げ、その内側では好き勝手やってもらう。**
これ、製品設計の判断基準としてかなり強い。
新機能が出てきたとき、
「高級そうだから何grade？」ではなく、
**① どこまでユーザーに触らせる？
② 外部から何を持ち込ませる？
③ その自由をこちらの安全柵で吸収できる？**
でgradeを判断できる。
そして大事なのは、**下位gradeをわざと不便にする階段ではない**ことだな。
上へ行くほど、
**できることが豪華になる**
というより、
**任せられる自由の範囲が広くなる。**
こっちの方がKaia Counter全体の設計思想としてずっと正確だわ。
---
**WORKING WHITEBOARD**
- Core grade model = **progressively wider safe operating boundaries**
- Free → narrow safe area; essential controls only
- Standard → broad freedom within Kaia-provided safe resources
- Creative → boundary loosens; user-supplied static images permitted
- Advanced → further controlled expansion of freedom
- Enterprise → maximum supported freedom **inside the product's safety perimeter**
- Enterprise does NOT mean removing safety architecture
- Grade decisions should consider:
- user control scope
- allowed brought-in assets/materials
- whether Kaia can safely contain failures
- Higher grade = **wider trusted freedom**, not artificial feature withholding
**相談あり：なし。これ、Counterだけじゃなくgrade設計そのものの共通原則になってる。**
memcite
[USER]
器用なやつならスタンダードでもかなり自由に行けるはずだよ
[ASSISTANT]
うん、むしろ**それを許すStandard**なんだなｗ
Standardは「初心者向けだから簡単なことしかできません」じゃない。
**初心者**
→ パレット選ぶ、Suggestedから選ぶ、Link Colors使う。
→ 普通に綺麗なものができる。
**慣れてる人・器用な人**
→ 同じStandardの範囲内で、色・HEX・サイズ・余白・枠・配置・フォント・Display HTMLなんかを組み合わせる。
→ **かなり別物まで持っていける。**
でも両者とも、こちらが作った安全な操作系の中にいる。
これ、Standardの商品価値として結構重要だと思う。
> **簡単に使えることと、自由度が低いことは別。**
なんだよな。
むしろSuggested ColorsやLink Colorsなんかは初心者を助ける**補助輪**であって、上手いやつの自由を奪う制限じゃない。補助輪いらなきゃ自分で細かく触ればいい。
だから今回Standardを作り直すときも、俺が安全性を理由に、
**「こっちの方が簡単だから選択肢減らしといた★」**
をやったらダメだわｗｗｗ
安全柵の**内側にある自由はちゃんと渡す**。
Creativeとの差もそれで崩れない。器用な人がStandardを魔改造レベルまで使い倒せても、**自前の静止画像をCounterの素材として持ち込む**ところでCreativeの柵を越える。
---
**WORKING WHITEBOARD**
- Standard is **not a low-skill / low-freedom grade**
- Beginners → presets and assistance can produce good results easily
- Skilled users → can combine Standard controls for substantial customization
- Suggested/linked controls = assistance, not restriction
- **Do not reduce valid Standard options merely to simplify the UI**
- Standard promise: **full freedom inside its approved safety perimeter**
- Creative boundary remains meaningful even when a skilled Standard user pushes Standard very far
**相談あり：なし。Standard実装時の「親切のつもりで自由を削る」事故は禁止ｗ**
memcite
[USER]
他に迷いそうとか事故りそうはある？
[ASSISTANT]
ある。今の段階で先にしゃむと認識合わせしておいた方がよさそうなの、**主に4か所**ある。コード事故というより「俺が仕様を善意で誤読しそうな場所」込み。
1. **「文字の持ち込み」の境界**
Standardには「各種文字変更」がある。ここで俺が迷う可能性がある。
たとえばボタンの文言を好きな文章にするのは当然Standardっぽい。一方、Display HTMLもあるから、文章・リンク等をどこまで「持ち込み」と考えるか。
今の理解では、**文字入力はStandardで許可された材料の一種**として扱って、画像などの「外部アセット持ち込み」とは別物にするのが自然だと思ってる。
2. **フォント**
これはかなり事故臭いｗ
**用意済みフォントから選択 → Standard** は明快。
でも旧Customにはフォントファイル関係のコードまで残ってる。ここを俺が「フォント機能だからStandard★」で拾うと、**ユーザーのフォントファイル持ち込みまでStandardへ混入**しかねない。
なので今の原則なら、Standardでは用意したフォントだけ。アップロードフォントは少なくともStandardではない、と切っておきたい。
3. **Display HTML**
ここが一番「器用な人ならStandardでかなり遊べる」に関係する。
旧Standard仕様には安全化されたHTML入力がある。これは残す。ただし俺が安全性を怖がって**ただのテキスト欄まで弱体化するのもダメ**だし、逆に旧CustomのAdvanced HTMLまでうっかり移植するのもダメ。
つまり新Standardでは、歴史的に決めた**250文字・許可HTMLあり・危険要素除去**の遊び場をちゃんと復元する。ここは実装時にサニタイズ処理を特に丁寧に見る。
4. **設定の独立性**
これは仕様迷子というより実装事故の最重要地点。
Standardは自由度が高いぶん、色・文字・レイアウト等の設定項目が大量に増える。そこで昔みたいにStandard設定をグローバル保存すると、
**Counter 1を赤くしたらCounter 2まで赤くなった★**
が再発する。
だから「Standardの自由」は**Counter Nごとに完全独立**を最初から土台にする。ここは後付け修正しない。
それ以外で既に赤旗を立ててるのは、**旧Standardに存在しない `limit_html_input()` を呼んでいた件、Free名で残すべき共有ソケットをStandard名へ改名して壊す危険、12桁折り返し、Refillを設定継承と誤解する危険、旧CustomからAuto Stop/Creative機能を拾いすぎる危険**。これはもう「要注意箇所」として俺側で止めてある。
なので、今しゃむに確認したいのは一個だけ。
**Standardの文字入力は、ユーザーが自由に文章を書くところまで普通にOK――で合ってる？**
「持ち込み制限」は文章そのものを制限する話ではない、と俺は読んでる。
---
**WORKING WHITEBOARD**
- New ambiguity scan completed.
- Primary specification question: whether free-form user text is fully valid inside Standard.
- Font upload must not accidentally enter Standard merely because font selection does.
- Standard Display HTML should preserve its intended safe sandbox, not be weakened or upgraded accidentally.
- Every Standard setting must remain isolated per runtime Counter N.
- Existing engineering red flags remain tracked: missing helper, shared Free-named contracts, 12-digit wrapping, refill/design bleed, and cross-grade feature leakage.
**相談あり**
→ Standardの自由入力文字は普通にOK、という理解でよい？ memcite
[USER]
あｗ文字は簡単。基本的にはもうそのＷＰで引用できるやつがスタンダード枠だな
そのＰＣのフォント読み込んで持ち込むならくりえいてぶに回す
テキスト欄なんだがこっちてですとした結果250字がベタ打ちの文字のちょうどいい量
コード挟むならその分を増した分くらいのイメージでどうだろうか
[ASSISTANT]
あーー、これでフォント境界も綺麗に切れたｗ
**Standardのフォント基準は「そのWordPress環境から普通に引用・利用できるもの」。**
PCからフォントファイルを持ってきてアップロードするところからCreative。つまり「フォントの種類」でgradeを決めるんじゃなくて、ここでも**素材を外から持ち込むか**なんだな。
で、テキスト欄の250字についても、その考え方でかなり自然だと思う。
旧仕様の「250文字」は、セキュリティ上の絶対値というより、
> **実際にベタ打ちしてみたら、表示用テキストとして250字くらいがちょうどよかった**
という**内容量の基準**だったわけだ。
ならHTMLを許可している以上、
`こんにちは`
を「こんにちは」の5文字ではなくタグ込みで26文字ぶん消費させて、ユーザーの実質的な文章量を減らすのは変だわ。
俺なら新Standardでは、
**「表示されるテキスト約250文字相当 + 許可されたマークアップに必要なぶんの余裕」**
として設計する。
ただし、ここは**単純に上限を500字とか1000字に上げる**より、少し慎重にやった方がいい。コード分の余裕を増やした結果、ベタ打ち文章まで500字入るようになると、しゃむが実機テストで決めた「250字がちょうどいい」が消えちゃう。
理想は、
**本文量の目安 ≒ 250文字**
**許可HTMLタグの記述ぶんは別枠的に吸収**
だな。
実装方法はコードを見る段階で一番事故らない方法を選ぶ。少なくとも「旧仕様250だから入力文字列を機械的に250 bytes/charactersでブツ切り★」はやらない。HTML途中切断も起こせるしｗ
あと、これでさっきの質問は解決。
**自由文章そのものはStandardでOK。**
WP内で利用できる文字・フォント・安全なHTMLという**こちらの遊び場の中なら、器用な人はかなり遊んでいい。**
PCからフォントファイルを持参した瞬間にCreative側。
---
**WORKING WHITEBOARD**
- Standard font boundary clarified:
- Fonts/resources normally usable from the WordPress environment → Standard
- User imports a font file from their PC → Creative
- Text is not treated as a prohibited external asset.
- Historical 250-character limit came from practical display testing: ~250 plain-text characters felt appropriate.
- New intent:
- Preserve roughly **250 characters of actual textual content**
- Allow additional source length needed for permitted HTML markup
- Do not simply enlarge the plain-text content allowance
- Implementation must avoid unsafe raw truncation or broken HTML.
- Exact technical limit strategy will be chosen after inspecting the sanitizer/input path.
**相談あり：なし。250は「ソースコード長」じゃなく「中身の量」の基準として扱う。** memcite
[USER]
他なんかありそう？あとはPlanetの開発にぶら下がってるやつで気になる内容のタイトルあれば拾ってくれればこっちに転記する
[ASSISTANT]
うん。今の整理まで来ると、こっちだけで赤旗立てられるところはだいぶ潰れてる。
残ってて**Planet側の過去資料を見たら事故防止に効きそう**なのは、タイトルだけならこの辺を拾いたい。
1. **Standard / Custom の文字・フォント・Display HTMLまわり**
- 特に「文字変更」「フォント」「HTML」「250字」「Advanced HTML」っぽいタイトル。
- 今ちょうど境界が確定したので、昔どこまで実装・検証したか確認したい。
2. **Customの画像機能を切っていた時期**
- 「数字画像」「マスク」「桁背景」「ボタン画像」「終了画像」あたり。
- Creativeへ持っていくためというより、**Standard側に残しておくべき受け口やフォールバック設計**が過去に決まってないか見たい。
3. **Standardのプレビュー**
- Before / After、パレット同期、Suggested Colors、Link Colorsあたり。
- ここは機能数が多いので、昔の「これで完成」としたUIがあるなら再発明しない方が安全。
4. **12桁・サイズ・レスポンシブ関連**
- 「12桁」「折り返し」「スマホ」「サイズ」「一行」みたいなタイトル。
- 既に事故歴があるので、もし専用の検証記録がぶら下がってたら欲しい。
逆に、**Refill / Binder / Acceptance State / Issuance Gate / Event**あたりは今回もらった引継ぎでかなり芯まで分かってるから、今のところ追加発掘の優先度は低い。
あと一個だけ、新しく事故候補を見つけた。
**「WPで引用できるフォント」の判定をコード側で勝手に賢くしすぎないこと。**
たとえば俺が「WordPressならGoogle Fontsも取れるよね★」みたいに外部取得まで勝手にStandard扱いし始めると、しゃむの言う**“そのWPにあるものを使う”**からズレる可能性がある。
だからStandard再建時は、過去Standardが実際にどうフォント候補を用意していたかをまず尊重する。新しいフォント供給源を俺判断で増やさない。
Planetについては、しゃむが転記してくれるなら**俺が直接何度も潜るよりそっちが安全**。
ACTIVEの「開発」にぶら下がってるタイトル一覧だけ見て、上のキーワードっぽいのがあればタイトル投げてもらえれば、「それ欲しい」「それはいらない」を小分けで選べる。
---
**WORKING WHITEBOARD**
- Remaining historical-reference priorities:
1. Standard/Custom text, fonts, Display HTML
2. Custom static-image design/fallback work
3. Standard Preview / Palette / Suggested / Link Colors
4. 12-digit / responsive / sizing tests
- Current handoff is sufficient for Refill/Binder/Acceptance/Gate/Event unless a conflicting historical note appears.
- New guardrail: do not broaden “fonts available to WordPress” into arbitrary external font acquisition.
- Prefer Shamyue-transferred Planet material over repeated direct Planet retrieval.
**相談あり**
→ Planet「開発」配下で上の系統っぽいタイトルがあれば、まずタイトルだけ見せてくれれば選ぶ★ memcite
[USER]
ん－とこっちでPlanetにのってるのはわたしてるみたいだな
HTMLなんだが、イメージでいうと2000年頭あたりのむき出しHTMLの素朴なやつの技術レベルのタグならOKみたいな感じ？
250字は半角でベタ打ちずらーってやってまぁ許せるか。くらいの最大値
だからテーブルセットとかでやるには十分あきができるんじゃないか？
カスタムでこけてたのがマスク処理。桁背景はなしで色だけ選べる
終了画像はオートストップの持ちぶんなので気にしなくて良し。
基本的に画像類はすべて比率でだしとく
もし比率が二けた二けたならそれと合わせて近似値を一桁一桁でおよそこれくらいで切れば事故らないよ★にする
桁数はマックス10桁で一行指定。12桁にするとなぜか折り返し事故が起きるので10桁マックス。
画像は君渡したスクショさがしてくるわｗｗｗ
[ASSISTANT]
おｋｗｗｗ **かなり具体的になった。**
そして俺の中で古い「12桁」を引きずってたところも、ここで更新する。
HTMLについては、そのイメージなら理解できる。
**「現代のWebページを組ませるHTML欄」じゃなくて、2000年代頭くらいの素朴なHTML装飾箱。**
つまり文章を中心にして、リンク・強調・改行・簡単な表組みみたいな、昔の個人サイトでソースむき出しで書いてた程度のもの。JavaScriptやCSSを持ち込んで別世界を構築する場所ではない。
そして250半角文字が**ベタ打ち本文の最大許容量**なら、タグ込み入力上限にはかなり余裕を持たせてよさそう。
たとえば表組みは、
```html
```
みたいに、見えてる文字は4文字なのにソースは一気に膨らむ。
だから設計としては、
**表示される本文量 ≒ 半角250文字を上限目安**
＋
**許可タグを記述するためのソース余白**
で考える。
ここは実装時に「ソース○文字」という適当な数字だけで決めず、**250文字本文＋現実的なtableセットを実際に突っ込んでテスト**して上限を決めよう。そうすれば元の実機判断を壊さない。
そして画像系、かなり重要な更新。
**桁背景画像は無し。色だけ。**
これは旧Customコードに `digit-frame/background` 系があっても、現在仕様へ拾わない。
**終了画像はAuto Stop所有。**
Counter Standard/Creativeを作る際に旧Customから発掘しても放置。
**マスク処理は旧Customの事故現場。**
これはCreativeをやるときに「既存コードがあるから移植★」を絶対やらない。参考資料扱いに格下げ。むしろ新しい紙案件。
**画像は比率ベース。**
ここも理解した。画像そのものをこちらで無理矢理変形させるんじゃなく、使用場所ごとに必要比率を提示する。そして複数桁ぶんの画像比率が分かっているなら、そこから**1桁素材に切るときのおおよその安全比率**も案内する。
これ、Creativeで画像を持ち込ませる以上かなり大事な「柵」になる。
そして最大桁数は完全更新。
> **MAX 10桁・絶対1行。**
旧資料の12桁は現行仕様として廃止。
12桁で原因不明の折り返し事故が出たから、無理に直して12を売るんじゃなく、**安定確認済みの10を製品仕様上限にする。**
これはStandardだけじゃなく、画像を扱うCreativeでも土台として10桁を継承する認識でいる。
スクショは見つかったら投げてくれｗ
特にUIなら、文章で再構成するより**「これを正としてFree骨格へ移す」**のが一番事故らん。
---
**WORKING WHITEBOARD**
- Planet references currently appear sufficient.
- Standard HTML concept:
- Simple early-2000s-style markup
- Text-centric
- Basic formatting, links, simple tables, etc.
- No modern arbitrary page-building / scripting environment
- Historical 250 chars = practical maximum for **plain half-width visible text**
- HTML source allowance should include reasonable markup overhead.
- Validate with real 250-char text + representative table markup before fixing the source-length limit.
- Current digit maximum = **10 digits, forced single row**
- Historical 12-digit specification = obsolete due to wrapping regression.
- Digit background **image** = removed; color only.
- End-state image = Auto Stop responsibility; ignore for Counter grade reconstruction.
- Old Custom mask implementation = known failure area; do not transplant blindly.
- Creative images = ratio-guided.
- Where useful, derive approximate safe per-digit crop ratio from a known multi-digit ratio.
- Awaiting historical UI screenshots when Shamyue finds them.
**相談あり：なし。旧資料の12桁・桁背景画像・終了画像は現行Standardへ混入させない★** memcite
[USER]
あ、改行くらいは普通にいれていいよｗｗｂｒでも吸収できるけどさｗｗ
[ASSISTANT]
ｗｗｗもちろんｗｗ
そこまで2000年代に戻って**「改行したければ `
` を打て！」**にはしないｗｗｗ
普通のテキスト入力として、
**Enterで改行 → そのまま表示上も改行**
でいいな。`
` を書ける人は書いてもいいけど、必須にはしない。
これでHTML欄の思想は、
> **普通に文章を書くだけでも使える。
> HTMLを知ってる人なら、素朴なタグを足してもうちょっと遊べる。**
になる。
つまり器用なStandard民には、
「お、ここHTML通るじゃんｗ」
ってtableやリンクや装飾で遊ぶ余地がある一方、普通の人は**HTMLを一文字も知らなくても文章＋改行だけで成立**する。
この方がStandardの「柵の中では好きにやれ★」に合うｗ
---
**WORKING WHITEBOARD**
- Plain newline input is supported normally.
- Users do **not** need to write `
` for line breaks.
- `
` may still be accepted as permitted simple HTML.
- Standard HTML field should work at two levels:
- ordinary text + Enter/newlines
- optional simple HTML for skilled users
- Do not require HTML knowledge for basic use.
**相談あり：なし。2000年代風なのは許可HTMLの技術レベルであって、入力UXまで2000年代に戻さないｗｗｗ** memcite
[USER]
んだから、これは禁止みたいなやつ、多分かいてたと思う
[ASSISTANT]
そうそう、**禁止リストは書いてた記憶で合ってる**。
今こっちに残ってる引継ぎ情報では、旧StandardのDisplay HTMLは少なくとも、
**OK側**
- テキスト
- リンク
- 基本的な文字装飾
- 今の話で、普通の改行
- 素朴なHTML
**禁止側**
- 画像
- CSS
- JavaScript
- `