おう！！！ 化石化する前に札を立てるぞｗｗｗ
あとでそのままPlanetなり引継ぎなりへぺったんできる粒度で、現在仕様だけ書く★
KAIA PDF / COUNTER — CURRENT SIMPLIFIED LINKAGE SPEC
Working Note — 2026-09-06
STATUS: CURRENT DESIGN
Purpose:
Separate Counter and PDF responsibilities and eliminate the old
cross-product Refill model.
==================================================
1. CORE PRINCIPLE
==================================================
Counter Refill and PDF Refill are independent.
A Refill does NOT travel between Counter and PDF.
Counter does NOT provide paper / Refill authority to PDF.
Cross-product interaction is information reference only.
Counter ── reference ──> PDF
NOT:
Counter Refill ── paper transfer ──> PDF
==================================================
2. COUNTER
==================================================
Counter owns its own:
- Counter Refills
- Counter state/data
- normal WEB shortcode output
Counter selection UI:
[Use: ON / OFF]
when ON:
[Counter selector ▼] [OK]
Selection is tentative until OK is pressed.
Pressing OK:
1. commits the selected Counter
2. exposes/generates the WEB shortcode for that Counter
The committed Counter is also the Counter that PDF may reference.
Therefore there is only ONE committed Counter selection.
There are NOT separate "WEB Counter" and "PDF Counter" selections.
OFF:
- Counter is not used by PDF.
- Shortcode is not exposed for use.
- The previously selected Counter may remain remembered internally;
OFF does not need to erase it.
==================================================
3. COUNTER → PDF CONTRACT
==================================================
PDF does NOT own Counter selection UI.
PDF does NOT:
- select its own Counter
- maintain a separate Counter connection
- own a PDF-side Connect button
- copy Counter Refill
- inspect Counter Refill as PDF paper
- receive PDF Refill authority from Counter
- synchronize Counter/PDF paper state
When PDF needs Counter information (e.g. Preview):
Check Counter-side Use state
|
+-- OFF --> use no Counter
|
+-- ON
|
v
read committed Counter
|
v
pull required Counter information
That is the entire Counter/PDF connection.
==================================================
4. PDF
==================================================
PDF owns its own world:
PDF
├── Working
├── PDF Refill
├── PDF Stock
└── Output
Working
= current workbench / current design state.
PDF Refill
= PDF's own live ammunition.
= independent from Counter Refill.
= Load/Save target for actual PDF work.
PDF Stock
= reusable design warehouse / design notebook.
= separate from live PDF Refill.
Output
= Preview / Final PDF / SNS JPG as defined elsewhere.
==================================================
5. PDF REFILL vs PDF STOCK
==================================================
PDF Refill:
- live usable PDF slot
- PDF-owned
- actual PDF work/design is loaded from and saved to it
PDF Stock:
- reusable design storage
- design warehouse ("ammo depot")
- independent from live Refill
Conceptually:
PDF Refill <──> Working <──> PDF Stock
They may reuse similar internal design structures,
but their product responsibilities are different.
==================================================
6. OLD "PDF 1" COMPOSITE MODEL
==================================================
The old implementation contains a composite "PDF 1 / sheet" object
that mixes responsibilities such as:
- design storage
- Counter binding
- generation source
- identity/address
This structure came from the older cross-product paper model.
Under the CURRENT design, these responsibilities should be separated.
OLD:
PDF 1
├── design
├── counter_id
└── generation/source identity
CURRENT TARGET:
design -> PDF Refill / Working
counter -> read Counter-side committed selection when needed
generation -> Working/output flow
The old PDF 1 container should not be assumed necessary.
Retire it only after remaining dependencies are verified.
==================================================
7. OLD CROSS-PRODUCT REFILL MODEL
==================================================
OBSOLETE / DO NOT REBUILD:
- Counter Refill acting as PDF paper
- "PDF confirmed Counter Refill" as paper authority
- transferring Refill objects between Counter and PDF
- PDF-side persistent Counter connection
- PDF-side Counter selector / Connect gate
- special Binder whose purpose is transporting/holding
cross-product Refill rights
- synchronization required only because one Refill crossed products
DEV72's PDF-side explicit Counter gate belongs to this superseded model.
Do not carry it forward into the independence implementation.
==================================================
8. ENTITLEMENT / CAPACITY CONSEQUENCE
==================================================
Because Refill objects no longer cross products,
cross-product entitlement should not require moving physical/logical
Refill objects between Binders.
Where a product rule grants additional capacity, prefer:
condition satisfied
->
capacity number changes
NOT:
move Refill
->
lock Refill
->
special Binder
->
unlock/migrate Refill
Exact entitlement numbers/rules remain their own specification.
Do NOT mix:
- PDF Refill capacity
- Stock -> Refill unlock allowance
- Counter rescue overflow (+3)
They are separate concepts.
==================================================
9. DESIGN RULE
==================================================
PAPER STAYS HOME.
ONLY INFORMATION CROSSES THE PRODUCT BOUNDARY.
Counter Refill stays Counter Refill.
PDF Refill stays PDF Refill.
PDF Stock stays PDF Stock.
Counter tells PDF only:
"Use Counter?" and, if yes, "This is the committed Counter."
PDF says:
"ほい★"
and reads the required information when needed.
==================================================
10. IMPLEMENTATION MOTTO
==================================================
Do not synchronize what can be one fact.
Do not transfer what can be referenced.
Do not create a Binder for something that does not need to move.
MAKE THE PLUGIN DUMBER. ★これでいいｗｗｗ
特に最後の
PAPER STAYS HOME. ONLY INFORMATION CROSSES THE PRODUCT BOUNDARY.
が今回の独立宣言の芯だな。これ一本覚えてれば、後のKaiaがまた「専用Binder作りましょう★」とか言い出したときにピコハンで殴れるｗｗｗ
あと状態ラベルも明確にしておく。
CURRENT: PDF Refill独立・Counterは確定情報の参照だけ
OBSOLETE: Counter/PDF横断Refill・専用Binder・PDF側Connect
REFERENCE: 旧 PDF 1/sheet 構造は移行時の依存調査資料としてのみ保持
DEV68: 旧実装のruntime帰還地点として保持
DEV72: 交通整理の静的検証資料。ただしPDF側Counter Gateは新仕様へ持ち込まない
相談：なし
No comments yet.