床に就く直前だったのですでに朦朧としていたが，工具類を引っ張り出して無我夢中に取り組むうち何とか水栓を止めて分解するところまではできたので，あとはそのままにしてぐたっと寝込んだ．
カインズに行けば多分パーツを見つけることができるとは思うが，このところ昼夜が逆転しているので，しばらくは昼間表に出られない．ともかく，（よほど太物でない限り）シャワーで流せることだけは確認してある．（もともとこのトイレにはトイペーというものは置かれていない．シャワーでお尻を洗うとき，ついでに便器も洗うというだけだ）
多重カードが最小値の5ではなく，7になってしまう原因がわかった．TribeRelocationに続くメインループTRIBELIST::MainExprerimentで打ち切っていたためだ．多重カード数が下限と推定される値に達したときには処理を打ち切ってループから脱出するようになっていた．推定下限値にはこれまでsameGeneCyclesが当てられてきたが，現行ではTOPOLOGY::Inevitables「多重不可避カード数」が適用されている．これらの値は（源氏7をサンプルとしたときの）多重カードの最小値より大きいため，最小値まで削減される前に終了してしまっている．
この脱出条件を止めると，処理は多重カード数が静定するまで続行するので，最小値が確実に実現されるようになる．実際，このように手配した後では，「重婚クラスタ循環を子ノード側で切断」する場合も「親ノード側で切断」した場合も同じ結果になる．つまり，重婚クラスタ循環を切断するためのカットセットは必ずしも一意ではないが，最終出力としては同じ結果が得られると言える．これで重婚クラスタ循環が存在する場合を含めて，つねに最適結果を出力することができるようになった．別の言葉を使って言えば，「系図作図問題の原理的な完全解」を得ることができた，つまり，「系図作図問題が初めて原理的に解かれた」と言える．（思えば長い道程だった…）
軸線図がおかしい．#1 光源氏の軸線図が紫の上で止まってしまう．光にはまだ他の子どもがいる．もっと長い軸線があるはずなのだが… どうしたのだろう？軸線図はすでに仕上がっているはずだったのだが…
軸線図処理は2つのパートからなっている．①TOPOLOGY：FindJikusenAncestorはDECOMPOSITIONフェーズで系列分解処理TribeDecompositionの中から呼び出されて「軸線最長鎖」を決定し，②TOPOLOGY::CallBuildShaftLineは，TribeRelocationの中からBUILDCENTERLINEフェーズで呼び出されて．軸線グラフから血統軸線を構築する．①では最初に直系血族グラフを生成し，このグラフからGetLongestChainで軸線最長鎖を切り出している．
直系血族グラフの生成は単純な処理なので間違いないと思われるが，GetLongestChainでは明らかにやり損なっている．GetLongestChainでは最初にGetHasseDiagramを呼び出して枝グラフからハッセ図を生成している．このグラフをインポートしてみよう．
この図から見ると，最長で8世代に渡る軸線が存在する．先祖ノードは※３，末裔ノードは若宮（匂宮の）だ．これから軸線を切り出すのは容易であるように思われるのだが… この後，MakeAntiChainListで反鎖リストと呼ばれるものを生成する．反鎖リストは同世代ノードリストとも呼ばれ，同世代ノードを成分とする成分分解リストである．反鎖リストもCSV形式でエクスポートできる．90度回転させるとこんな図になる．
GetLongestChainの最終出力である軸線最長鎖は間違っていない．FindJikusenAncestorの最終出力も正しい．先祖ノード：CARDLINK：#1473 ＠50※３[0] 末裔ノード：CARDLINK:#1482 ＠51若宮（匂宮の）[0]となっている．結局，CallBuildShaftLineでやり損なっているということになる．CallBuildShaftLineは重婚クラスタ検定の前に実施される．この後の重婚クラスタ検定で軸線が崩されている可能性が高い．軸線が成功するためには，紫の上の下に明石中宮が来なくてはならないのだが，実際の出力でその辺りがどうなっているのかを見てみよう．
明石中宮は世代的には紫の上(0)の下の世代に配置されているが，紫の上のもう一つのカードである紫の上(1)に連結されている．これを紫の上(0)の直下に持ってこなくてはならない．確かにこれは難しい問題だ．結婚枠（子ども枠）は親（のいずれか）の直下に配置されることになっている．明石中宮の親は光源氏＋紫の上であり，その意味では光源氏の直下か，ないしその配偶者である紫の上（1）の直下しか居場所はない．紫の上(0)は光源氏の娘（養女）ではあってもその配偶者ではないからだ．
軸線を描画するためにこの原則を曲げることは可能だろうか？光源氏→ 紫の上で止まるより，光源氏→ 明石中宮→ 匂宮→ 若宮 （匂宮の）の方が長い．実際，光源氏の軸線を考えるなら，その方が妥当だろう．つまり，光源氏→ 紫の上という関係を軸線から外して考える必要がある．しかし，光源氏→ 紫の上が親子関係（養親子関係を含む）にあること自体が問題という訳ではない．そもそも光源氏＋紫の上→明石中宮という関係そのものが養親子関係だ．
軸線に反映する親子関係を実親子関係に限定するという割り切り方もあるのではないか？いや，それもやや疑問だ．光源氏→ 紫の上を実親子関係，光源氏＋紫の上→明石中宮を実親子関係としても同じ問題が発生する．一番わかり易いのは，重婚クラスタ検定を経た後の「正則系図」上で軸線を考えるということではないだろうか？多系列にまたがる軸線というのを描画できるだろうか？現状では少し難しいように思われる．
現行枠組みを維持したまま，軸線図検定で光源氏→ 紫の上という親子関係をパージするというのがもっとも望ましいのだが… 重婚クラスタ検定を系列分解より前に実施することは可能だろうか？重婚クラスタ検定で用いているのは，①婚姻関係と②親子関係だけであり，系列という概念は持ち込まれていないはずだ．重婚クラスタ検定を先行実施できれば，「正則系図（絶対世代番号を付与されたハッセ図）」上で軸線を考えるということも可能になるのではないだろうか？不可能ではないような気がするので挑戦してみよう．
重婚グラフ検定はBuildSameGeneMarriageGraphとGetHasseDiagramという2つのパートに分かれていて，TRIBERELOCATIONとSAMEGENEMARRIAGEという2つのフェーズにまたがる大きな処理だが，一つにまとめることができる．これをまず，関数化しておこう．⇒TOPOLOGY::CheckWeddingClusterとしてみた．⇒まったく問題なさそうだ．少し面白くなってきた．⇒ダメだ．反例が出てしまった．桐壷院でソートしたら，EstablishMajorTribeChainで収束しないようになってしまった．⇒これは改修する前の版でも起きる．まず，このバグを取らなくてはならない．
▲源氏物語全系譜7.ZELを#1041 桐壷院でソートして，AFTERMARGSAMEGENEフェーズでTOPOLOGY：EstablishMajorTribeChainが収束しない．主系列が決定できないのは，TRIBEBOX #189411 先祖=#183114 三位中将(0)[27] 優先=#192114 夕顔(2)→#190999 夕顔(1)だ．系列接続種別は婚姻関係，系列優先仮ノードの夕顔(2)は消去された仮ノード属性を持ち，始系列の一院系列所属の優先実ノードの夕顔(1)は実ノード属性を持っている．何の問題もないように見えるのだが…
実ノードの絶対世代番号が物理世代番号と一致しないという理由だ．