BuildShaftLineの既存論理を完全に廃止して，FindJikusenAncestorの事前検定で決定された軸線ノードのセットに準拠して軸線を構成するようにしたが，まだ一箇所だけ軸線の折れ曲がりが残っている．重婚クラスタ図をエクスポートできるようになったので，デバッグ時に別アプリでこのファイルをインポートして参照できるようにしておきたい．最近のバージョンでは一覧表のインポート・エクスポートが実行不能になっていたので，新しい版をリリースする必要がある．Version 2.2.0.022 Release 2021-02-02を暫定リリースすることにした．
この版をインストールしてデスクトップから実行すると，下図のように完全に軸線の通った図面が出力された．
非常に喜ばしい結果だが，同時に大きな問題でもある．デバッグモードとリリースモードの動作が異なるというのは突き止めることが困難な「バグ」とみなされる．デバッグ版，リリース版ともに世代数は9段で同じ．異なるところは，デバッグ版ではbaselistが多重カードになって2箇所に出現しているという点だ．baselistには親が2人いる．topologyとtribelistだ．tribelistはtopologyの子どもなのでデバッグ版ではbaselistと同じ箱に入っているが，リリース版ではtopologyの子ども枠に入っているbaselistはLDRになってtopology→LDR→baselistのように接続されている．この動作上の差異を突き止めなくてはならない．
一般にこのような場合には，デバッグ用のコードが実動作に影響している可能性がもっとも高いと考えられるが，関係するコードを見つけるのはかなり難しい．表示されているbaselistの仮ノードは2つしかない．(0)がtopologyの子ども枠の中にあるノードで，(1)がtribelistの直下にあるものだ．baselist(0)がデバッグモードでLDRになれない原因を調べてみよう．⇒NAMEBOX::EraseGhostNameでUnErasableがERR_UNERASABLEを返している．⇒UnErasableでは軸線ノードは消去不可としているためだ．これは結局軸線ノードのマーキングが間違っているためと考えられるが，リリース版ではなぜそれが起きないのか？
開発環境ではリリースモードとデバッグモードの動作に差異はない．つまり，リリースモードでもbaselistが多重カードになるという動作だ．⇒インストールしたつもりだったが，バージョンが変化していない．アンインストール→再インストールでリリース版でも同じ状況になることが確認できた．つまり，軸線が通る図面を出力していたのは，一つ前のバージョンだったということになる．そこまで戻るというのもあまり意味がないので，このままシューティングを進めよう．
baselistの2つの仮ノードがどちらも軸線のマークを持っているというのは，マーキングの論理の不整備だ．⇒そのノードの人名リンクが軸線であるというだけでなく，軸線グラフ上の枝をチェックして結婚枠の親ノードが軸線ノードであることを確認するようにしてこの問題は解決したが，その後の動作が悪い．TRIBELIST::SortTribeListでCheckTribeListのエラーが発生し，その後もエラーが連続発生して続行不能になる．
「TYW仮ノードは消去された」というダンプが出ているので，baselist（0）がTYW婚に組み込まれたことは間違いない．軸線ノードは抽出枠やTYW婚に転換できないという論理はすでに組み込まれているが，これを「軸線人名リンクから派生するすべての人名ノードは抽出・TYW転換禁止」とする以外なさそうだ．軸線を構成するための論理は硬質で融通が利かないので，フロート婚TYWの自由度とは相容れないということだろう．これでZTモジュール構成図 TEST2.ZELの問題は解決した．
▲ZTシステム構成図7.ZELを#1 couplingで開いて，PAIRBOX：MoveChannelToで停止した．(!movesingle && IsBundled())という理由だ．movesingleがONなら単体ノード対の移動，OFFなら端点共有束全体を移動する．端点共有束移動の場合は，引数のノード対は共有束の代表ノードでなくてはならないという条件だ．⇒呼び出し側のRepairPairBoxを修正して，単体ノード対の移動をサポートした．
▲上記サンプルを血統軸線図で開いて，MARGBOX::MoveExpandBoxで停止した．「結婚枠世代不一致」が発生している．障害ノードはMARGBOX #732：#823 描画Ｙリスト(0)＋→．この結婚枠は軸線枠ではない．しかし，軸線図を設定しているので，影響している可能性はある．TRIBELIST::GoDownStreamで最初にMARGBOX::DecideRoleで結婚枠のownerを設定した時点では一致している．
人名枠側の世代が2世代分下に下がっている（+2している）．つまり，世代関係が逆転してしまっている．このノードの世代番号は4→3→６のように変化している．⇒CARDLINK::DownStreamで「軸線枠は軸線ノードの下で展開される＠20210201」とする修正にミスがあった．すでに展開済みの結婚を展開する動作になっていた．⇒これを修正してもまだ，エラーが残っている．軸線なしでは発生していないので，軸線に関わるものと思われる．軸線グラフを出してみよう．
このサンプルの基準ノードはcouplingで軸線は，
coupling[0]→… pagesetup[6]→ treeview[7]→ Bobject[8]→… nodule[10]→NODULE[0]
の6ノードだが，世代的にはcouplingの世代0からpagesetupの世代6までかなりの開きがある．Bobject[8]とnodule[10]の間も1世代空いている．このような状態でうまく軸線を引くことができるのだろうか？かなり難しいような気がする．重婚クラスタ図を出力してみよう．
これで見ると世代が分離しない軸線が存在するかのように見えるが，クラスタ的には繋がっていても，内部のノードがそれに対応しているという訳ではない．しかし，軸線グラフで取り出された軸線が本当に最長軸線になっているかどうか？という点に関してはかなりの疑問がある．
coupling→pagesetupとなっているが，familytreeを通るパスの方が長いのではないか？クラスタ図の方はおそらく間違いの入る余地はないと思われるが，「ハッセ図検定の後でこのグラフを取り出すと上の方がちょん切れたようなものになっている．ハッセ図検定のロジックの検証はまだ取り掛かっていない部分だが，少なくともハッセ図検定の出口ではそれに対応したクラスタ図が出力できるようになっていなくてはならないと思う．どちらも荷の重い課題になりそうだ．
先に軸線グラフの正当性を検証することにしよう．これは軸線図の方が簡単だという訳ではないのだが，少なくも出力は単純なチェーンなのでわかり易いShir．FindJikusenAncestorのステージ【1】の軸線グラフを見た限りでは，coupling→ familytree→ topology→ graph1→ complist→…→DATALIST→ nodule→ NODULEというパスが一番長いように思われる．このパス上のノードは11個でpagesetupのパスより5つも多い．このパスが選ばれなかったのはなぜだろう？