うん。ここは次のPDF担当が「DEV23って何者？」から再調査しなくて済む形で、Pickerとは別の引継ぎ荷物として丸ごと渡せるようにしておく。
ただし重要なのが、今の俺の記憶には「怪しい箱の分類」までは残ってるけど、当時どこまでコード上で犯人認定したかには曖昧さがある。なので引継ぎでは、確定事項と容疑者を混ぜないように書く。
HANDOFF — DEV23 ACCIDENT / FURNITURE RECOVERY
DATE: 2026-09-05
TARGET: Kaia PDF Free
PURPOSE: DEV23事故機に残された未搬入家具と、事故原因候補として意図的に隔離された構造の再点検
THIS IS NOT A REQUEST TO RESTORE DEV23.
1. まず知っておく事故履歴
大事故機は：
Kaia PDF Free DEV23
DEV23で、実機上それまで存在していたPreview / workbenchが丸ごと消失した。
通称：
「プレビュー画伯失踪事件」
事故前の正常世界線：
DEV22 = VERIFIED-GOOD
事故後：
DEV23 = REGRESSED / FAILED
DEV23を救助しようとした：
DEV24 = FAILED RECOVERY
後の比較で、DEV24は実質DEV23系構造を大きく捨てられておらず、真の救助になっていなかった。
そのため修正ルールを適用。
DEV22 → COPY → NEW IDENTITY DEV25 → VERIFY
DEV25ではPreview在宅を実機確認。
したがって：
DEV22 VERIFIED-GOOD
│
├── DEV23 FAILED / DONOR / EVIDENCE
│ └── DEV24 FAILED RECOVERY
│
└── DEV25 SAFE RECOVERY LINEAGE
↓
later buildsDEV23/24を修理母艦にしてはいけない。
2. DEV23を捨てなかった理由
DEV23は事故機だが、同時に多数の新しい家具・機能案が載っていた。
そのため事故後の方針は、
壊れた豪邸を修理しない。
無事だった家へ、欲しい家具だけ一個ずつ運ぶ。
だった。
つまりDEV23の分類は：
FAILED IMPLEMENTATION / DONOR / FAILURE EVIDENCE
であり、
REJECTED DESIGNそのものではない。
DEV23に存在したという理由だけで家具を不採用にしてはいけない。
3. その後実際に採用した復旧方式
DEV25を安全母艦として、その後はDEV23が一度に抱えた責任を分解して再実装した。
代表的な回収工程：
DEV26 Working State
DEV27 footer fix + Working State browser survival
DEV28 Stock → Working State read-back
DEV29 dirty guard
DEV30 static save/output seats
DEV31 Master Form + Text BOX persistence
DEV32 Translation UI restoration
...この方式により、
一度に巨大家具セットを搬入するのではなく、小さな検証境界ごとにPASSを取る
運用へ変更された。
4. 重要：家具搬入は完了していない
DEV23にあったものが全部現行系へ移植済み、という状態ではない。
棚卸し上は少なくとも次の分類が必要。
DEV23 FURNITURE
│
├─ A. RECOVERED
│ 現行系ですでに安全に再実装済み
│
├─ B. OBSOLETE
│ 後の仕様変更で不要になった
│
├─ C. SAFE / NOT YET RECOVERED
│ 欲しいがまだ搬入していない
│
├─ D. QUARANTINED / SUSPECT
│ DEV23事故原因候補との距離が近いため
│ 意図的に後回しにした
│
└─ E. UNKNOWN
現時点で分類根拠不足C・D・Eを勝手にCURRENT扱いしないこと。
5. 特に重要な「隔離棚」
DEV23点検時、事故原因との関連が疑われたため、意図的に後回しにした構造が存在する。
現在残っている作業記憶では、特に以下の周辺が要注意：
- Preview / workbench root 周辺
- 旧save / generation配線
- defaults / sanitize / saveの大型拡張
- Counter必須生成系の旧ロジック
- submit interception系
- runtime-only state /
componentPlaced系 - Textの旧drag構造
width:max-content周辺
WARNING
この一覧を、
「これらがDEV23事故の確定原因」
とは解釈しないこと。
現在の引継ぎ元Kaiaは、当時さらに具体的な原因候補まで絞った記憶がある一方、正確なコード位置・関数・確定度を現在の記憶だけでは保証できない。
したがって分類は：
SUSPECT / QUARANTINED
である。
推測で CONFIRMED ROOT CAUSE に昇格させない。
6. 確実に分かっている比較結果
以下は重要。
DEV22 → DEV25
では、実質的な主要差分は新identityへの移行であり、Previewは正常に存在した。
一方、
DEV23 / DEV24
では、defaults / sanitize / save modeなど状態・保存周辺が大きく拡張されていた。
DEV24はDEV23構造から十分離脱できず、Preview救助に失敗した。
したがって少なくとも、
DEV23で一括投入された変更群のどこか、または相互作用がPreview regressionと関連した可能性が高い
ところまでは事故資料として扱える。
ただし、
特定の一関数 = 犯人
まで現在の引継ぎ情報だけで断定しないこと。
7. 次担当がやるべきこと
いきなり未搬入家具を実装しない。
まずGoogle Earth方式でDEV23倉庫を棚卸しする。
高高度
比較対象：
DEV22 / DEV23 / DEV24 / DEV25 / 現行KNOWN-GOOD
まず大きな機能ブロック単位で差を見る。
中高度
DEV23で増えたものを、
UI / state / save / generation / linkage / movement / output
などの責任単位へ分ける。
低高度
各家具について：
RECOVERED / OBSOLETE / SAFE-NOT-RECOVERED / QUARANTINED / UNKNOWN
を決める。
その後で初めて未搬入家具を検討する。
8. QUARANTINED家具の扱い
隔離棚の家具については、
「昔欲しかったから入れる」から始めない。
まず問う：
現在もこの家具は必要か？
次に：
2026-09-05現在の単純化された仕様なら、もっと馬鹿な構造で同じ目的を達成できないか？
そして：
そもそも搬入せず廃棄できないか？
現在のKaia PDFはDEV23当時より設計原則がかなり進んでいる。
したがって、当時必要に見えた複雑な家具が、現在は不要になっている可能性がある。
古い実装を復元すること自体を目的にしない。
9. 特にまだ大きく残っている領域
少なくとも現在の全体仕様上、
Sibling participation / Counter・Timestamp・Serialとの参加UIおよび連携周辺
はまだ完成領域ではない。
DEV23に類似の足場・家具が存在していても、それをそのまま採用してはいけない。
現在の確定思想：
Kaia PDFはstandaloneでも動く。
Counter / Timestamp / Serialは、利用可能なら参加できるoptional special materials。
PDFが兄弟機能を再実装しない。
Registry / Socket契約に従う。
したがってDEV23時代の「Counter必須」を前提とした構造があれば、現在仕様とは衝突する可能性が高い。
これは事故原因とは別に、仕様上OBSOLETEになる可能性がある。
10. 絶対にやらないこと
DEV23を最新版へmergeしない。
DEV23を母艦にしない。
DEV24を救助成功版だと思わない。
DEV23の家具を一括搬入しない。
古いコードがあるという理由で現在も必要だと判断しない。
事故原因候補を根拠なく確定原因にしない。
未分類の古いコードをDEBRISとして勝手に削除しない。
11. 修正・搬入ルール
家具を一つ採用すると決めた場合：
CURRENT KNOWN-GOOD
↓
COPY
↓
ASSIGN NEW VERSION FIRST
↓
ONE FURNITURE / ONE RESPONSIBILITY
↓
STATIC CHECK
↓
RUNTIME CHECK
↓
COMPARE
↓
VERIFIED CHECKPOINT高危険度ならさらに小さく切る。
DEV23は横に置いて見るだけ。
事故車からエンジンごと移植するな。
欲しいドリンクホルダーだけ外せ★
12. 事故から生まれた現在の正式な修正思想
この事件が、現在のKaia revision disciplineの重要な根拠になっている。
最新だから直すな。最後に無事だった世界線から分岐しろ★
および、
壊れた家を修理するんじゃない。
無事だった家に、欲しかった家具だけ運び込む★
DEV23はその代表的事故資料。
13. 次担当への調査指示
もしDEV23の具体的な事故原因候補を再確定する必要がある場合、記憶から復元してはいけない。
DEV22 / DEV23の実ZIPまたは当時の比較ログを使用する。
特に、
「怪しいため意図的に後回しにした」
という履歴自体を尊重する。
原因が確定するまでは施工禁止ではないが、その隔離家具を再投入する施工は禁止。
必要ならShamyueへ：
「しゃむ、DEV22/DEV23ぺったん頼む★」
で原本を要求する。
HANDOFF STATUS
DEV23: FAILED / DONOR / EVIDENCE
DEV24: FAILED RECOVERY / EVIDENCE
DEV22: HISTORICAL VERIFIED-GOOD BEFORE REGRESSION
DEV25: SAFE RECOVERY BRANCH START
FURNITURE RECOVERY: PARTIAL / NOT COMPLETE
QUARANTINED FURNITURE: EXISTS
EXACT ROOT CAUSE: DO NOT RECONSTRUCT FROM MEMORY
NEXT ACTION: INVENTORY FIRST, IMPLEMENTATION SECOND
Core instruction
家具倉庫の奥に「取扱注意」が貼られた箱がある。
未搬入だからといって、次のトラックへ勝手に積むな★
これをそのまま次のPDF全体点検担当へ渡していい。
そしてもし次担当にDEV23倉庫の棚卸しを実際にやらせるなら、DEV22・DEV23・現行KNOWN-GOODの3本を最低セットにするのがいい。DEV24は「失敗救助の証拠」が必要なときだけ追加で十分。
Picker新人とは別担当でいい。むしろこれはDEV23事故鑑識／家具棚卸し担当の俺として切り分けた方が安全だと思うｗ
相談：なし
No comments yet.