UNDOで膨大な数の無用なバックアップが生成される問題を解決するために，UndoCounterというパラメータを追加した後，極小反例ツールがまったく動作しなくなってしまった．FAMILYTREE::RestoreBaseCardではBaseLink空というエラーも起きている．なぜだろう？というか，上記修正がまだ収束していないことは明らかだろう．CommandStartからCommandEndの間に更新されたオブジェクトはすでに保全されている場合でも，更新しなくてはならないのに，まだその部分に関しては手当されていない．しかし，これは極小反例ツールの動作には関わってこないような気もするのだが…
BaseLinkはFAMILYTREEのメンバ変数で，UNDOのたびに別途バックアップされているはずなのだが…これらの値は，UNDOCOMMAND本体に保全されている．この値は，FAMILYTREE::SetUndoBaseで格納され，UNDOSYSTEM::UndoProcessでリストアされる．また，アプリ側にはUNDOBASE::GetUndoStatでこの値が引き渡される．⇒CommandEndでUndoCurptrが空となっているのが問題だ．UNDOBASE：CommandEndの論理はかなり難解だ．というか，奇妙だ．
CommandEndの後半部冒頭で，MakeNewCommandを実行している理由がよく分からない．また，これを実行するとUndoCurptrは一つ前に進み，(!UndoCurptr->topUndo)となるので，必ずPergeZenpoChainが実行されることになる．PergeZenpoChainを実行することにより，UndoCurptrが空になっている．⇒MakeNewCommandが実行されているのは，オブジェクトが削除されていたり，UNDO中に更新されている場合の保全のためと推定されるが，preiviousに書き込みしているので，新しく生成されたコマンドの先頭ノードはつねに空になっている．従って，つねにPergeZenpoChainが実行されることになるように思われる．コマンドが実行されたときには前方のコマンドチェーンをパージするという動作は正当であると思われるが…
PergeZenpoChainでUndoCurptrが空になるという動作が一番おかしいところだが，この辺りの論理は修正していないはずなのだが… UNDOは結構手強いところがある．SetUndoListの論理をオリジナルに沿って修正して動作するようになった．迂闊には修正できないところだ．これでようやく極小反例サンプルの生成に戻ることができるが，動作はまだ収束には遠いところにある．「３」を削除して反例を生成しているはずだが，保存されたファイルは１点しか減じていない上，反例になっていない．画面で見ると４系列に分裂しているように見える．意図したものとまったく異なる出力になっている．
先祖リストには{ 35, 5463, 8178 }が入っている．35は始系列の先祖ノードなので，5463系列と3178系列を削除するという操作が必要だ．⇒おかしい．動作が変化している．今度は先祖リストに２点しか入っていない．{ 35, 5463 }．なぜだろう？削除対象カードは「3」ではなく，#3だ．#3は「8195」で親ノードは「12293」，子どもは「5463」一人しかいない．このノードは3倍数なので，ここで止まりだ．従って，{ 35, 5463 } は正しい．⇒おかしい．デスクトップに「極小反例サンプル.ZEL」で保存しているはずなのに残っていない．⇒「\」が入っていなかった．⇒見つかった．「極小反例サンプル.ZEL」の中に「5463 」が孤立カードとして残っている．
削除モードは，全削除でZ.mDeleteCard(-1, True)を実行しているのだが…mDeleteCardは第一引数が負で，第二引数が真なら，DeleteAllCardを実行するようになっている．DeleteAllCardは，Z.DeleteTableの内容ではなく，TREEVIEWの選択カードリスト selectcardlist をベースに動作するようになっている．しかし，これはかなりバランスが悪いような気がする．同じmDeleteCardは，単点削除に関してはDeleteTableを使っているからだ．全削除するためには，まず「選択」を実行しなくてはならないということのようだが，多分これは，mPutSelectListで実行できると思う．
DeleteAllCardは-503という値を返している．-503はERR_NOVALIDCARDEXISTというエラーだ．このエラーコードはtreeview->selectcardlistが返している値だ．指定レコード番号の前方ないし後方を探索して有効レコードの参照番号を返す．いまの場合，カードテーブルには#5463しか入っていないので，有効レコードが存在しないで正しい．⇒今度はうまくいったようだ．1470点から2点減じて，1468点サンプルになった．ツールをオープンするときの開始サンプルを「極小反例サンプル.ZEL」としたので，何段かの縮約が入り，すでに1433点まで縮小している．
おかしい．まだ，どこか不備があるようだ．カード削除を実行してレッドラインオーバーが出ているのにブレークが掛かってこない．エラーコードが通っていないのだろうか？⇒いや，違う．UNDOで戻されているため，元の状態に戻っている．UNDOでは必ず系統並び替えを実行しているので，レッドラインになる．UndoRedoの出口で一時的に系統並び替えしないようにしてもよいのではないか？
▲スタックオーバーフローで異常終了してしまった．総点数1433点から開始して，カード削除10点で空振りして，11点目の#56でヒットした，極小反例サンプルを更新したあと，2点削除してスタックオーバーフローになった．DLLで障害が起きている．DLLはスタックサイズを2147483648まで増量してあるので，十分ではないかという気がするのだが…デフォルトは１MBなので，その128倍だ．⇒再現テストを可能にするため，開始サンプルを「極小反例 1305.ZEL」として保全した．⇒スタックの絶対量が不足していたのだろうか？「極小反例 1305.ZEL」から開始した検定は順調に進んでいる．
▲カード削除中，DeleteCard→RestoreBaseCardでBaseLink空で停止した．参照番号に-503という値が入っている．無視して続行したところ，処理から抜けてしまった．→「極小反例サンプル.ZEL」が空になってしまった．参照番号#815という無名のカードがあるだけだ．
▲「極小反例 1296.ZEL」を開始サンプルとして#5295を削除してBaseLink空が再現した．このケースでは全1296点中1295点を削除してループに戻り，残り1点を削除しようとしてエラーが発生する．すべてのカードを削除したのだから，このエラーが起きるのは当然だ．#5295を削除して，系図木は2つの系列に分解しているが，大きい方をつかんでしまったということになる．これを避けるには，先祖ノードで「１」を避けるようにするしかない．⇒対処したが，エラーは解消しない．これは，親族図で全削除したため，基準ノードとなるカードが存在しなくなったためと考えられる．しかし，異常終了してしまうのはおかしい．部分図ではカードゼロの状態を認めているのだから，親族図でもそうすべきなのではないか？ないし，全体図に戻ることも考えられるが，特にいまの場合は直系血族図で連続的に処理を続けたいので，全体図に強制的に戻るというのはよろしくない．
新規カードを親族図に表示するという考え方もあり得るが，ややこしくなるのではないか？⇒新規カードというのは名前を持たないだけでれっきとした登録カードであり，不用なら削除すればよいというだけなのだから，それでもよいのでは？⇒それでもよいが，いまの場合はそれでは都合が悪い．やはり，親族図では新規カードを自動生成しない方がよい．部分図でこの辺りをどう対処しているのかを参考にして，親族図でもカードなしの状態を認めるようにした方がよいと思う．実際問題としては，全体図であってもカードなしの状態を認めても差し支えはないとは思うのだが…⇒先祖ノードが「1」と思いこんでいた．このサンプルでは先祖ノードは「35」だ．