TRASHCANとUNDOSYSTEMというZTシステムの重要な機能のモジュール化に成功した．TRASHCANは完全なネィティブnoduleクラスとして確立され，UNDOSYSTEMもその基幹部分をUNDOBASEというネイティブクラスとして切り出すことができた．これでシステムの不透明な部分が相当程度グラスボックス化したと言える．時期は不明だが，前に一度試みて不成功に終わったUNDO機能と関わりがあるNODULE::numberという変数も廃止することができた．アプリ終了時には，ゴミ箱の内容を廃棄してから delete CAN を実行しているが，これもストレートに delete CAN だけで済むことを確認した．しかし，delete CAN でゴミ箱の中身が消えるのはなぜだろう？CleanSlotではすべてのスロットをdeleteしているが，スロットゼロは除外されているはずなのだが…
▲下図のような大量のカードを一括削除して，TRIBEBOX::SetPrimeLinkで停止した．
(prmtype && !marglink && PHASE <= TRIBERELOCATION && CENTERLINE != CENTERLINE_SEXIAL)という理由だ．始系列ではないのに優先ノードが結婚リンクを持っていない．⇒BUG20-12-19 17-32-21.zelで反例サンプルを保全した．この障害は2020/12/02のリリース版でも発現するので，最近の修正とは無関係と思われる．
TRIBEBOX::GetAlternativePrimeNodeの論理に穴が空いていた．先祖ノード#238 FAMILYTREEの対象系列#534は優先仮ノード#166 extraslot2の相手方を見つけられなかったため，代替として#226 COUPLINGを選択した．相手方#154 couplingは系列#528 先祖=#426 couplingの本人（先祖）ノードだが，既存コードには相手方が先祖の場合が抜けていた．優先仮ノードの結婚リンクは，すでにパートナーを見つけた時点で決定可能なので，既存コードは不要と思われる．
▲源氏物語6のテーマを切り替えようとして，「フェーズのイレギュラーな遷移」エラーが発生した．DRAWSTAGEからTOPOLOGICALSORTに移行しようとしている．テーマを切り替えただけではトポロジーには変化はないが，図形のサイズ・位置には変化が現れるのでレイアウトの再計算を実施する必要がある．系統並び替えを実施しないで再描画するUpdateDiagramという関数はあるが，これで間に合うだろうか？spannodcount > 0 ということは系統並び替えが必要ということを意味するのだが… TOPOLOGY::UpdateDiagramでは「写真を表示しているときは調整不能，系統並び替えが必要」としている．⇒ここでは，FAMILYTREE::updatespannodで強制的にフェーズをINITIALIZEDに落とすということにしておこう．
▲ZTシステム構成図7.ZELを開いた後，BUG20-12-19 17-32-21.ZELを開こうとしてエラーになった．COUPLING::initializeの出口で(TemplateBuff)が起きている．⇒再現しない．⇒再現した．源氏6の後，ZTシステム構成図7.ZELを開いて起きた．ただし，再現するには何か条件が必要なようだ．TemplateBuffは記録ページテンプレートを保持するためのバッファで，COUPLING::SaveTemplateで使われている．しかし，この関数は呼び出されている形跡がない．⇒いや，VBのSaveFileからの呼び出しがある．
SaveTemplateだけでなく，LoadTemplateというのもある．「記録ページテンプレート」というのは過去の遺物だ．以前は記録ページのレコードをカテゴライズするためのテンプレートファイルというのを持っていたが，いまは完全に仕様から落とされている．TemplateBuffは廃止でよいと思われるが，エラーが発生する状況をもう少し詳しく確認しておきたい．ひょっとしたら，バッファオーバーランのようなことが起きている可能性もある．SaveTemplateはファイル保存時に実行されているので，ファイルを保存してみれば分かるだろう．
確かに実行されているが，サイズはゼロだ．ただし，COUPLING：SaveTemplate側ではサイズ＋4の領域を確保しているので，サイズゼロでもメモリブロックの取得は実行される．記録ページテンプレートはCOUPLING::SerializeHeaderで読み込まれている．この部分の論理は残しておかないと古いファイルが読み込み不能になる可能性がある．また，現状では書き込みの部分も作動しているはずだから，この論理を止めるためには「REVISIONのアップデート」が必要だ．⇒片付いた．REVISIONを更新したので，ここで一度リリース版を起こしておこう．Version 2.2.0.019 Release 2020-12-20とした．
▲源氏6.1の318点から48点を一括削除してTRIBEBOX::SetPrimeLinkでエラーが発生した．BUG20-12-20 00-37-44.ZELで再現できる．問題の系列は先祖#404 ※３の系列枠#921で，本来の優先ノードは#338 明石中宮だったのだが，このノードが系列所属ノードの中に入ってこない．どこかでancestryリンクを書き換えてしまっているのだろうか？元々は先帝系列に属していたようだ．ancestry値はTOPOLOGY：FilteringKinship→ GetkinshipDegree→ …→ CARDLINK：getKinshipDegreeで設定されているが，TribeDecompositionの入口で一度リセットされ，→…CARDLINK::KinshipDegreeで再設定される．
どうも現行方式の原理的欠陥が露呈してしまっているような気がする．現行方式では一度設定された先祖リンクは変更できないようになっているが，場合によっては不可避の系列優先ノードというのが存在する．つまり，外部に接点を持つカードがそれしかない場合には，そのノードは複数の系列にダブル登録するしかないのではないか？おそらく「逆婚姻関係」というのはそのような矛盾を解消するための苦肉の策だったのだろう．しかし，「逆婚姻関係」はある限られた範囲でしか成立しない．そもそもMakeUpTreeの段階になって，GetAlternativePrimeNodeを実行しなくてはならないというところがこの弱点の現れだ．
系列の連結関係を「婚姻関係」に限定すれば，現行方式でもカバーできているのかもしれない．婚姻関係なら一方を系列に属する本人，他方を配偶者として連結することができる．しかし，「親元関係」ではそういう訳にはゆかない．どちらも「本人ノード」として立てなければならないからだ．逆に言えば，そのような欠陥があるにも関わらず，部外の明石中宮が優先ノードとして選択されているということは抜け道はあるということだろう．なぜこの選択がリジェクトされることになったのかその理由を見てみよう．
TRIBEBOX::GetRealnodeで弾かれているためだ．明石中宮は仮ノードを2つ持っている．#339 明石中宮(0)が※３系列，#1112 明石中宮(1)は按察の大納言（若紫）系列だが，(1)はIsSolidNameBoxで弾かれている．これは，按察の大納言（若紫）系列が※３系列より後方にあるためと思われる．明石中宮は先帝系列に属しているのに，それに属する人名枠が存在しないのはなぜだろう？多分，これが一番の問題点なのではないかと思う．⇒．#339 明石中宮(0)は最初に先帝系列に編入されている．TRIBELIST::GoDownStreamで※３に切り替わっている．