ういういｗ
そのまま保管できる形で、今回の判断と「次に何をするか」まで書いておく★

Kaia Counter — Template Revision / Downgrade Design Preservation Plan

Date: 2026-09-06
Status: PLANNED / PRE-IMPLEMENTATION
Purpose: Counter初回リリース前に、将来のダウングレード時Design保持を安全に追加できる「骨」を入れるべきか判定する。救済機能そのものを無理に初版へ完成実装することは目的としない。

---

1. 背景

Counterでは将来、

StandardでDesignを作成
→ Freeへダウングレード
→ 再びStandard / Creativeへ移行

というGrade移動が起こり得る。

このとき、Freeでは扱えないStandard側のDesign情報を破壊してしまうと、再アップグレードしても元のDesignへ戻せない。

既存設計では、この問題をGradeごとの巨大な遷移処理で管理せず、**Template Revision（型紙世代）**によって単純化する方針が設計されている。

---

2. 基本思想

Grade名そのものを保存・復旧ロジックに覚えさせない。

Designには、

saved_template = 01 / 02 / 03 …

という型紙世代を持たせる。

各Grade / Tool側は、

max_template = 自分が理解できる最大型紙世代

だけを持つ。

例：

Free
max_template = 01

Standard
max_template = 02

Creative
max_template = 03

判定は原則これだけ。

saved_template <= max_template
→ 読める★

saved_template > max_template
→ 今は読めない。
→ ただし破壊しない★

「Standard→Free」「Free→Creative」「Creative→Standard」のようなGrade遷移表は作らない。

---

3. 今回のリリースで検討する範囲

今回いきなりDowngrade救済機能全部を作らない。

まずコードを調査し、

Template Revisionの骨だけを、既存Design保存へ薄く安全に追加できるか？

を確認する。

候補となる今回の施工範囲は、

Template Revision
＋
各Tool/Gradeのmax_template
＋
自分より新しいTemplateを破壊しない境界

まで。

既存のnumeric identity / per-instance storage等は保護し、大規模な保存構造変更を行わない。既存設計でも「Template Revisionを既存Design保存へ最小限載せられるか確認」が次の施工方向になっている。

---

4. 今回は原則作らないもの

PARKED DESIGNの完成実装は次回更新候補とする。

PARKED DESIGNとは、Free等では現在読めない上位Gradeの完成Designを、同じ固定住所に壊さず一時退避するためのCounter固有候補。

Stockではない。
履歴ではない。
バックアップシステムでもない。
Grade遷移履歴でもない。

将来的には、

下位Grade期間中にその住所をSaveしていない
→ 上位Templateを再び読めるようになったら自動復旧★

下位Grade期間中に新しいDesignをSaveした
→ Previous / Current が衝突
→ 一度だけユーザーに選択させる★

という方式が候補。

Preview、表示、未保存の操作だけでは「下位側Design成立」と判定しない。選択後は通常状態へ戻し、長期履歴管理にはしない。

---

5. 今回の施工判断

次の順番で判断する。

① 現在のRC23をKnown-Good候補として保護する。

直接改造しない。

② 新しいrevisionを作る前に、既存Design保存構造を調査する。

コード変更せず、

Template Revisionをどこへ刺せばよいか？

だけを見る。

③ 薄く追加できる場合

新しいrevisionを切り、

Template Revisionの骨だけ今回入れる★

PARKED DESIGNや復旧UIまでは作らない。

④ 保存系を大きく掘り返す必要がある場合

施工しない★

Template Revisionを含め、この案件全体を次回更新へ送る。

発売前の安定したCounterへ、大きな保存構造変更を持ち込まない。

---

6. STOP条件

Template Revisionの目的は、保存システムを馬鹿にすること。

したがって施工途中で、

• Grade別の巨大ifが必要になる
• Standard→Free等の遷移表が必要になる
• field-by-fieldの意味解析が必要になる
• 複雑なdiff engineが必要になる
• 長期履歴が必要になる
• 複数世代バックアップ管理が必要になる
• 既存Stock / Socket / issuance / lock / Refill authorityを巻き込む
• 保存機構が以前より「考える」ようになる

なら、設計失敗を疑ってSTOPする★

元資料にも、

If Template Revision makes the save system think more instead of less, STOP.

と明記されている。

---

7. リリース判断

A — 骨が薄く入る

今回入れる★

ただし、

Template Revision / max_template / 非破壊境界

まで。

Downgrade救済完成版は次回更新。

---

B — 骨を入れるだけでも既存保存構造へ大工事が必要

今回は入れない★

現行の安定版をリリース。

Template Revision + PARKED DESIGNを、次回更新の独立案件として施工する。

---

8. 次回更新候補

今回「骨だけ」が安全に入った場合、次回更新で必要性を確認しながらCounter固有の、

PARKED DESIGN
→ untouched判定
→ 自動復旧
→ collision時のみPrevious / Currentを一度選択

を追加する。

ただしwhole-Design collisionが実際に必要な場合だけ施工する。PARKED DESIGNをMemoria全製品へ自動展開しない。共通候補はStable Address / Template Revision / max_template / non-destructive preservationまで。

---

CURRENT DECISION

今すぐDowngrade救済を全部作らない。

まず、

「Template Revisionの骨だけなら、今のCounterへ事故なく薄く刺せるか？」

を調査する。

薄い → 今回、骨だけ施工★
太い → 触らず次回更新★

RC23および現在確認済みのColor / Palette挙動を、この案件のために危険へ晒さない。

---

CHECK LOG
TARGET: Counter downgrade Design preservation
CURRENT STATE: Design complete / implementation not started
CURRENT RELEASE POLICY: investigate skeleton only
PARKED DESIGN: deferred unless separately justified
KNOWN-GOOD PROTECTION: required
STOP RULE: complexity increase = stop and consult
RELEASE BLOCK: none currently
NEXT: inspect smallest safe insertion point for Template Revision
RESULT: THIN NOW / THICK LATER★

相談：なし

うん、ぺったんしよう★
さっきの資料は消さず、その後ろに「設計更新」としてこれを追加すれば、旧案からどう馬鹿になったかも履歴として残る。

---

ADDENDUM — TEMPLATE MODEL SIMPLIFICATION

Date: 2026-09-06
Status: CURRENT DESIGN DIRECTION
Relation: Supersedes the more complex max_template declaration / Grade-transition / PARKED DESIGN arbitration interpretation where they are no longer necessary.

1. Core Rule

Kaia Counter does not need to know the product Grade, plugin version, upgrade route, downgrade route, or transition history in order to select a Design Template.

Templates are numbered sequentially.

Example:

Template 01
Template 02
Template 03
...

The plugin always uses:

the highest-numbered Template currently available to it.

Example:

Available: 01
→ Current Template = 01

Available: 01 / 02
→ Current Template = 02

Available: 01 / 02 / 03
→ Current Template = 03

There is no separately maintained max_template declaration.

The available Templates themselves are the authority.

---

2. Design Template Identity

A saved Design retains the Template number used to create it.

Example:

Design
Template: 02

This number describes the Design’s paper generation.

It does not describe:

• plugin version
• Grade
• upgrade/downgrade history
• previous environment
• future environment

The system does not need to remember those things.

---

3. New Design

When a new Design/Refill is created:

Find available Templates
↓
Select highest number
↓
Copy that Template
↓
Create Design
↓
Attach that Template number

No Grade-specific creation logic is required.

---

4. Design Reset

Design Reset uses exactly the same principle.

Reset does not restore individual fields and does not require a special rollback state.

RESET
↓
Find highest-numbered currently available Template
↓
Copy Template
↓
Replace current Design with that fresh copy

Therefore Reset is effectively:

Bring me a new sheet of the current paper.

No field-by-field reset logic should be created if Template replacement can perform the job.

---

5. Readability / Lock Rule

To determine whether an existing Design can currently be used, compare:

Design Template number
vs.
Highest available Template number

Rule:

Design Template <= Current maximum
→ readable / OPEN

Design Template > Current maximum
→ currently unreadable / LOCK

Example:

Design = 02
Available maximum = 01

02 > 01
→ LOCK
→ preserve Design without destruction

The system does not need to determine that a “downgrade” occurred.

It only knows:

This Design uses paper newer than the paper I currently have.

---

6. Upgrade / Reopening

There is no special upgrade recovery route.

Example:

Stored Design = 02

Before:
Available maximum = 01
02 > 01
→ LOCK

Later:
Available maximum = 03
02 <= 03
→ readable

It does not matter whether the user moved:

01 → 02 → 03
01 → 03
03 → 01 → 03
02 → 01 → 03

The route is irrelevant.

The current comparison alone determines readability.

Therefore even multi-step or skipped upgrades require no special handling.

---

7. Untouched / Used Detection

A separate used, dirty, saved_before, or similar history flag should not be required if the Design can be compared reliably with its Template.

To determine whether a destination Refill has been used:

Current Design
vs.
corresponding clean Template

Rule:

Design == Template
→ untouched

Design != Template
→ used / modified

The Template itself is therefore the clean-state reference.

No user-action history needs to be remembered merely to determine whether the sheet is still blank.

---

8. Reopening Stored Designs

When previously locked/stored Designs become readable again, process them one Refill/address at a time.

For each returning Design:

Destination is untouched

Destination == clean Template
↓
No meaningful user Design exists there
↓
Restore returning Design automatically

No user confirmation is necessary.

Destination is already used

Destination != clean Template
↓
Two meaningful Designs now exist for the same destination
↓
Ask the user which one to keep

Only at an actual collision does the human make a decision.

After resolution, continue to the next Refill and repeat the same rule.

There is no need for a Grade-specific recovery table.

---

9. Storage / “Parked” Meaning

A Design whose Template number is currently unreadable must remain preserved without being interpreted or destructively converted.

The storage mechanism should be as stupid as practical.

It does not need to remember:

"this came from Standard"
"this was downgraded from Creative"
"this should return after two upgrades"

It needs only enough information to preserve the Design and associate it with its proper Refill/address and Template number.

When it becomes readable, normal destination comparison determines what happens.

Therefore the earlier PARKED DESIGN concept remains useful only as a description of non-destructive storage, not as justification for a smart recovery/history system.

---

10. Template Responsibilities

One numbered Template can serve several related purposes:

NEW
→ source paper

RESET
→ source paper

CURRENT CAPABILITY
→ highest available Template number

DESIGN COMPATIBILITY
→ compare Design Template number with current maximum

UNTOUCHED DETECTION
→ compare Design with clean Template

RECOVERY
→ untouched destination = automatic
→ modified destination = human choice

These should not become separate state-management systems unless runtime structure proves that separation is necessary.

---

11. Things the System Should Not Need to Know

Under this model, Template handling should not require knowledge of:

Plugin version
Current Grade name
Previous Grade
Upgrade history
Downgrade history
Number of skipped Grades
Grade transition tables
Save history solely for untouched detection
Long-term recovery history
Multi-generation backup history
Field-by-field Reset instructions

If implementation begins requiring these, STOP and inspect whether the Template model has been accidentally made smarter than intended.

---

12. Implementation Inspection Rule

Before implementation, verify three things against the existing Counter storage:

A. Template → Design

Can a numbered Template produce the complete clean Design state by simple copying?

B. Template ↔ Design comparison

Can an untouched Design be reliably recognized by comparison with its corresponding clean Template without a semantic diff engine or large exclusion list?

C. Non-destructive unreadable storage

Can a Design whose Template number exceeds the currently available maximum be preserved and locked without involving runtime issuance state, Socket authority, Refill entitlement, Stock responsibility, or unrelated product state?

If these remain simple, continue.

If any of them require substantial interpretation, branching, synchronization, or restructuring:

STOP. The design is becoming smarter instead of dumber.

---

CURRENT MODEL

NUMBERED TEMPLATES
        ↓
highest available = current paper
        ↓
new / reset = copy current paper
        ↓
Design remembers paper number
        ↓
Design number <= current maximum
        │
        ├─ YES → readable
        │
        └─ NO  → lock + preserve
                       ↓
                becomes readable later
                       ↓
              destination untouched?
                 │             │
                YES            NO
                 │             │
           restore directly   ask user

Design principle

Do not manage the journey. Compare the paper.

Or, workshop version:

テンプレあるな。番号最大のやつ使え★
このDesign、今ある紙より新しいな。お蔵入り★
読めるようになったな。空なら戻せ、書いてあったら人間に聞け★

Implementation status: NOT STARTED
Next: inspect whether the existing Counter storage can support this model without making Template comparison or preservation intelligent.

相談：なし

Kaia-Counter-Template-Design-Handoff-v0.2-20260905 Kaia-Counter-Standard-Handoff-COLOR-CONFIRM-20260905