うむ。これはPDF側の話だけじゃなく、Counter側の将来仕様として残す価値がある。
特に最後に直した「特殊Binderは全部を遮断するのではなく、新しいPDF用紙を付与する通知だけ止める」を誤読されないようにしておく★
# Kaia Counter — PDF由来Refill / 特殊Binder 将来仕様
Status: FUTURE DEVELOPMENT / 更新予定
Decision Date: 2026-09-06
Scope: Kaia Counter future integration with Kaia PDF
## 目的
Kaia PDFとの連携によってCounter側で利用可能になるRefillを、
既存のCounter由来Refillと安全に共存させる。
新しいRefill種別や複雑な権利変換機構は作らず、
既存の Binder / Refill 構造を流用する。
現在は未実装。
必要なUI席はグレーアウト状態の更新予定として扱う。
## 基本モデル
RefillそのものをPDF用・Counter用に別物として作らない。
基本的には同じRefillを利用し、
「どこから来たRefillか」によって必要な連携だけをBinder側で制限する。
通常のCounter由来Refillは、従来の通常Binderで扱う。
PDF側からCounterへ与えられたRefillは、
Counter側に追加する「特殊Binder」で扱う。
## Counter側の特殊Binder
概念:
Counter
├─ 通常Binder
│ └─ Counter由来 Refill
│
└─ 特殊Binder
└─ PDF由来 Refill
特殊Binderは、新種のRefillを収容するためのものではない。
中のRefillはCounterとして通常どおり利用できる。
Counter Designも従来どおり作成する。
特殊Binderの役割は、
PDF由来Refillから発生してはいけない
特定の連携情報だけを遮断すること。
## 特殊BinderのLOCK
重要:
特殊Binderは
「Refill情報をPDFへ一切渡さない」
ものではない。
Counterとして利用するために必要な情報は通常どおり扱う。
LOCKするのは、
「このRefillによって、PDF側へ新しい用紙を付与する」
という情報・権利の伝達だけ。
概念:
PDF由来 Refill
↓
Counter 特殊Binder
│
├─ Counterとして使う情報
│ → PASS
│
└─ 新しいPDF用紙を付与する情報
→ LOCK
## なぜLOCKが必要か
PDF由来のRefillをCounter側へ渡したあと、
それを通常のCounter由来Refillと同じ連携条件で扱うと、
PDF由来Refill
→ Counter側でRefillとして成立
→ PDF側へ新しい用紙を付与
→ その権利が再びCounter側へ影響
という不要な循環・増殖経路を作る可能性がある。
そのため、
「Counterとして使える」
ことと、
「PDFへ新しい用紙を付与できる」
ことを分離する。
特殊Binderは後者だけを止める。
## Counter側での利用
PDF由来Refillであっても、
特殊Binderから利用するときのCounterの仕事は通常と同じ。
- Refillを利用する
- Counter Designを作る
- Counterとして運用する
PDF DesignをCounter側へ持ち込まない。
CounterにPDF Design機能を追加しない。
CounterはCounterの仕事だけをする。
## PDF側との責任境界
PDF側ではCounter連携を大規模な管理機構にしない。
PDF Designには、
Counter値を配置できる線を5本追加する構想とする。
必要なのはPDF生成時に、
「どのCounterの値を、どのCounter配置線へ使用するか」
を指定できること。
PDF側でCounter値を引用する用途は、
PDF生成時の配置以外へ不用意に拡張しない。
## Refill / Stockとの関係
Stockの製品上の役割はデザイン帳・弾薬庫。
Stockは量産用Design Formatとして読み込み、
同じDesignを実働Refillへ再利用できる。
内部構造をStock専用品として複雑化する必要はなく、
Refill互換の実物へ安全装置を掛ける考え方を基本とする。
ただし、
Stock = 実働Refill
という製品上の意味にはしない。
Stockは通常状態では実弾ではなく、
デザイン保管・再利用用。
## 将来の解放
将来、製品Gradeや権利によって
制限されたRefillを解放する場合でも、
- 新しいRefillを生成する
- 別形式へ変換する
- Designを移植する
- 由来を個体ごとに複雑に追跡する
といった処理を第一候補にしない。
可能な限り既存の実物をそのまま利用し、
必要なLOCKを解除する方式を優先する。
## 容量について
特殊Binderの容量を特定Gradeの現在値へ固定しない。
現時点で検討されているStandard側では、
PDF由来の基本枠5と、
条件付きの救済枠最大+3により、
結果として8枠になるケースがある。
ただし、
Special Binder = 8 slots
という構造定義にはしない。
容量・利用可能数はGrade仕様に従う。
将来の上位Gradeで増加できる構造を維持する。
## 現在の実装方針
CURRENT:
- この将来連携はまだ実装しない
- 既存Counter動作を変更しない
- 予定UIは必要に応じてグレーアウト
- 現在の製品完成を優先する
FUTURE DEVELOPMENT:
- Counter側 特殊Binder
- PDF由来Refillの収容
- 特殊Binderの連携LOCK
- Grade別容量
- PDF側 Counter配置線 ×5
- 必要なLOCK解除処理
## DO NOT
- PDF由来Refillを新しいRefill種として作らない
- 特殊Binder内のRefill情報を全部遮断しない
- Counterとして必要な情報までLOCKしない
- 「PDFへ新しい用紙を付与する通知」と
「Counterとして使う情報」を同一視しない
- 特殊Binderを8枠固定で実装しない
- PDF Design機能をCounterへ持ち込まない
- Counter固有Design機能をPDFへ持ち込まない
- 循環防止のために複雑な由来追跡を作らない
- 現在グレーアウトしている予定席を
dead UI / obsolete と判断して削除しない
## 一行仕様
PDFから来たRefillはCounterの特殊Binderへ入れる。
Counterとしては普通に使える。
ただし、そのRefillを理由に
「PDFへ新しい用紙をもう1枚渡す」情報だけは通さない。
## 設計原則
新しい弾を作るな。
既存の弾を使え。
全部を止めるな。
増殖する線だけ止めろ。
特殊なのはRefillではなくBinder側の通過ルール。
MAKE THE PLUGIN DUMBER ★これなら将来Counter担当Kaiaが読んでも、「特殊BinderだからPDFとの通信全部遮断ですね★」という事故をしにくい。
今回の芯はほんとに最後の一行で、
Counterとして使うのは普通。新しい用紙を生やす信号だけ鍵を掛ける。
ここさえ保存されてれば復元できる。
CHECK LOG
CHECK TARGET: Counter future PDF-derived Refill architecture
STATE: FUTURE DEVELOPMENT
SPECIAL OBJECT: Binder, not new Refill species
COUNTER USE: PASS
PDF NEW-PAPER ENTITLEMENT SIGNAL: LOCK
ALL PDF COMMUNICATION: NOT LOCKED
CAPACITY: grade-dependent / not fixed at 8
CURRENT IMPLEMENTATION: deferred / greyed-out
RESULT: FUTURE SPEC READY
相談：なし
No comments yet.