物理世代番号の計算を最終的にクリアしてしまおう．系列ポテンシャルを決定する途中計算で物理世代番号を参照しているというのがそもそもの間違いなのではないか？これを回避するためには，やはり動的に系列ポテンシャルを決定する仕組みが必要なのではないかと思う．系列木は木構造になっていて，その頂点に始系列があるという構成になっているが，最古世代系列は必ずしも始系列とは限らないため多少ややこしい話になっている．この辺りを整理する必要がある．
- getpotential potentialを返す
- GetPotential 系列枠のポテンシャル値（設定すべき値）を取得
- getPotential 系統（始系列）のポテンシャル値を取得
- getMax 系列最大物理世代番号取得
- getMin 系列最小物理世代番号取得
- getGeneration 系列枠の（最小）常用世代番号
- DEV2LOG 物理世代番号→論理世代番号
- LOG2DEV 論理世代番号→物理世代番号
- DEV2GEN 物理世代番号→常用世代番号
- GEN2DEV 常用世代番号→物理世代番号
- MakeTribesPotential 系列を系統に分解し系統ポテンシャル値を設定→使われていない
- callSetpotential 系列枠のポテンシャル値を設定
- Setpotential 系列枠のポテンシャル値を設定
- setPotential 系統ポテンシャルを設定する
- TRIBELIST::setStartPotential
- TRIBELIST::SetAbsolutePotential 絶対世代番号系と物理世代番号系を一致させる
▲子ども一人の結婚枠では結婚枠背景色が描画されていない．→TYW婚は結婚リンクを持たないので，MARGBOX：Drawでは描画されない．
一番の問題はTRIBELIST::GetTheEldestの中でgetFloorを使っている点ではないだろうか？最古世代の検出に物理世代番号を使わない方法を編み出す必要がある．⇒実装した．
▲TRIBELIST::CheckAbsoluteGeneは実行されていない．TRIBEBOX：CheckAbsoluteGeneではsetnodegeneでCARDLINKの絶対世代番号を設定している．つまり，絶対世代番号は確立されていない．⇒絶対世代番号は多重カードクラスタ検定の中で計算されている．この計算には抽象グラフ検証系が必要であるため，暫定的に停止してある．
▲最小反例307.zelで@23のカードを削除してTRIBEBOX::MakeUpTreeのエラーが発生する．同じカードにMakeUpが重複して掛かっている．その後， (nbox->hideflag == HIDE_UNKNOWN)というカードが検出されている．これは，MakeUp重複ノードと同一カードだ．該当ノードは#4213@31で@47の子ども．カードテーブル上では先祖ノードの@35よりも前にある．どうも，ClearTableでリセットされなかったのではないか？という気がする．子どもを３人持っているが，親は@47だけの普通のカードだ．⇒確かに初期化がパスされている．
CARDLINKは#1522だ．このリンク自体が無視されている．ClearTableに入る前にMakingLookupが実行されていない．MakingLookupはCommandEndで実行しているのではなかったろうか？CommandEndでTopologicalSortの直前にMakingLookupを実行するようにして動作するようになったが，カード削除ではlookupでアクセスできなくなるというのはやや不審だ．⇒カードテーブル上の位置は不変だが，lookup->countが減っているのではないだろうか？
初期状態ではlookup[1]の位置に入っている．更新するとlookup[0]になる．つまり，削除されたカードはlookup[0]にあったものだ．どうも，lookupの操作に何かバグがあるのではないだろうか？⇒かなりおかしい．逆順になっている．どこかで並び替えしているのだろうか？