午後10時起床，晴れ．__asm int 3 が NOP に書き換えられてしまうという問題についてもう少し食い下がってみる．VS 2017 を起動するとき，「管理者権限で起動」しないようにすれば書き換えできないのではないか？と考えてやってみたが効果なかった．昨日のログでは，①バックアップに戻してから，②ipchのフォールバック位置を設定したあとにノーマルな状態に戻っているので，この操作を試してみる．⇒何の効果もない．
STOPに相当する関数__debugbreakを見つけたが，動作はまったく同じだ．つまり，一度ヒットすると0xCCの位置に0x90が書き込まれてしまう．結局#define STOP __asm int 3 とまったく同じ動作になる．これ以上粘っても仕方ないだろう．これを受け入れるしかない．STOPで停止したところに手操作でブレークポイントを設定することにした．
ASSERT_NEVER などの場合はマクロの中にマクロがネストしているので多少厄介だが，ASSERT_NEVERで停止するということはすでにその時点で検定に失敗していることを意味するのだから，動作を反復テストする必要性はないと考えられる．これでようやく腰を据えてデバッグできる．
エラーを無視して走らせるとSUWになり，以下の図面が表示される．
上図を見ると，ＡＩはＡＦの下流に存在しているが，明らかにＡＦの優先ノードはＡＤでなくてはならないように思われる．優先ノードの設定はTribeDecomposition→ MakeTribeBox で実施されている．この論理が誤っているように思われる．先祖リストに列挙されるノードは以下の5つだ．ＡＭ，ＡＮ，ＡＦ，ＡＥ，ＡＯ．ＡＩはＡＭ系列に含まれるので，それがＡＦを先祖とする系列に再登場するという点がおかしい．
いや，それは違う．「結婚」は夫ないし妻のいずれかの「場所」で一度だけ展開されるが，親子関係は必ず「その場所」で展開されるから複数の親を持つ場合には複数の仮ノードが生成されるというのが常態だ．ＡＦからＡＩに至る経路は2つある．ＡＦ→ ＡＤ→ ＡＢ→ ＡＡ→ ＡＩとＡＦ→ ＡＤ→ ＡＧ→ＡＩだ．ＡＥからＡＩに至る経路も2つあり，ＡＥ→ ＡＢ→ ＡＡ→ ＡＩとＡＥ→ ＡＣ→ ＡＡ→ ＡＩだ．
ＡＩは親を二組持っているから，出現は2箇所つまり，ＡＩの仮ノードは2つある．ＡＦはＡＥよりも先に展開されているから，ＡＦの優先ノードがＡＩになるというのは誤りではない．従って，ＡＩ(1)がＡＥ系列に属するという点に誤りがある．ＡＢ＋ＡＣ→ ＡＡがＡＦ系列で処理されていないのが問題だ．ＡＢ＋ＡＣは家内婚になっているが，どうもこの辺りで変則的な動作になっているような気がする．確かにそのようだ．ここでは家内婚を遅延処理するような調整が入っているが，それを外すことで簡単に描画できた．
確かにどこかで，このような調整を行った記憶はある．「家内婚は左手本人預かりとする」という仕様変更を2018-11-08に実施している．しかし，このような遅延処理が不可能ないし矛盾したものであるとは考えられないので，なぜこの論理が通用しないのかを考えてみよう．系列優先ノードは系列分解フェーズで決定されるが，結婚の展開はそれよりあとのGODOWNSTREAMで実施されているためだ．障害が発生するのはさらにそのあとのMAKEUPTREEフェーズ．現行論理では系列優先ノードの付け替えというのは普通にやっているので，それが適用可能かどうかを見ることにしよう．
EstablishMajorTribeChain はそのようなシチュエーションに適用可能な関数と思われる．いや，この関数はあまり完備したものではない．もう一度一から探し直すような処理が必要だ．IsConnectedでは付け替えができない．IsConnectedを適用するためにはYリストが整備されている必要がある．TRIBEBOX::AlternateTribeRealNodeにも包括的な付け替え論理が入っているが，この場合は優先仮ノードは固定で実ノードの代替品を探すという論理になっている．系列枠オブジェクトの右枝に先祖ノードが配置されていないまったくの空白状態から代替優先ノードを探す論理を一から起こすしかない．
Windows の以前のバージョンを削除しますか？という通知が入っている．ディスクスペースが逼迫しているためだ．タブレットには余分なものは一切置かないようにする必要がある．と言ってもユーザ領域は1GBも使っていない．Windows.oldをバックアップして潰すしかないだろう．約4GBだ．