2つもボケを連発してしまった．一つは，「Verification Testで検証に失敗」の件で，これは明らかに，うっかりどこかのボタンを押してテストが停止していたのを「検定に失敗」と誤認したものだ．画面に「Verification Failed」と出ていたので錯覚するのも無理はないとも言えるが，その場合にはメッセージパネルが出るはずであり，単純な停止とは区別できたはずなのだが…B面ではVerifyボタンはStopに変化するが，それ以外のボタンではラベルを書き換えていない．しかし，他のボタンを押しているのならその検定を実行しているはずだから，当然RTFテキストボックスの内容も書き換えられていなくてはならない．
V1.05, V1.06, V1.07のすべてで問題の区間でエラーが発生していないことを確認しているので，原因がうっかりテストを止めたことにあることは間違いないが，他の検定を実行しないでそれが可能なのか確認しておく必要がある．⇒いや，B面でVerificationを実行しているときには，他のボタンはすべて隠蔽されていて，アクティブなボタンはVerifyから変化したStopボタンしかない．実際，これを押して止めたことは明らかだ．障害が起きたバージョンで現物テストしているのだから間違いない．このときの状態は確かに騒動が起きたときの状態と同じになっている．StopボタンはVerifyに戻り，RTFボックスにはVerification Test Failed!が出ている．メール送信ボタンはアクティブになっていて，表示されたテキストのボトムはThanks in advanceだ．
最新版ではこのような場合には，Verification Test Stopped at xxxx のよな表示が出るようになっている．進捗率と所要時間も表示される．停止した場合にも，その結果を送信することは意味があるから，Click…Thanks in advance となっているのは問題ない．メール送信ボタンも送信可能になっている．まず，これでよいのではないか？
もう一つのボケは，「Facebookに2000人分の友だちを抹消されてしまった」という騒動だ．これは明らかに勘違いで，数学基礎etcにコメントを付けようとしてログインしたとき，常用のアカウント以外の別のアカウントでログインしていたためだ．ただし，このアカウントは長期間放置されていたもので，パスワードも忘れ，変更手続き中だったのだが，マイクロソフトからは認証を拒否された状態になっていた．
アカウントに登録された情報との一致が認められる有効な身分証明書をお送りいただけるまで、このアカウントへのアクセスは認められず、お客様のリクエストにはお応えいたしかねます。
これは，ウェブカメラで撮った顔を左右に振る動画とパスポートの顔写真が一致しないと判定されたためだが，パスポートを更新するお金もヒマもないので（その必要もなくなった）放置していたので，本来ならログインできないはずなのだが…上記の拒絶通知の日付は2021/12/28で，その後，2022/01/04に「アカウントのロックが解除されました」というメールが入っていた．これは，頻繁に入ってくる「いつもと違う場所からFacebookにログインしましたか？」という通知に似ていたので，多分同種のものと思って見過ごしていた．このメールがoutlook.jpアカウント向けのものであることに注意すれば分かったはずなのだが…ともかく，古いFBアカウントが復活したことは喜ばしい．
確かにこのアカウントは使っていた痕跡はあるが，復活させようとしていたアカウントとはまた，別のものだ．わたしが復活させたいと思っているアカウントはプロフィール画像に百舌鳥の写真を使っているもので，アカウントは本名で登録されている．theory-edgeなど，過去の数学領域での活動はすべてM.N.で行っていたので，これを使いたいと思っているのだが…このアカウントではそもそも，メールアカウントとして何を使っていたのかも分かっていない状態だ．（時期的に見て）AYANETのアカウントである可能性はほぼないとは思うのだが…AYANETのアカウントはとっくの昔に死んでいる．
AYANETに連絡を取って，このアカウントを復活させるということも考えられなくはないが…それができれば古い友人たちとのコンタクトを復活させるのにも一番早いのだが…AYANETとはもう10年以上前から解約交渉を進めていて，ずるずるとここまで来ているのだが…まぁ，もちろんコラッツ問題の賞金が入ってくれば，恒久的にこのサイト（冷たい森）を維持することも難しい話ではなくなる，とは言えるのだが…
Facebookから電話番号変更の通知が届いた．OutlookのアカウントとGmailのアカウトで同じ番号を登録しているためだが，古い電話番号を「他の人が登録しています」という状態になっている．Outlookではすでに電話番号を変更しているので，上記のモズアカウントだろうか？Facebookは本来実名登録が原則だ（だった）が，実際には複数アカウトの使い回しを認めているようなので，多分同じ番号でも通るだろう．（アカウント分だけのスマホを持つなんて不可能だし…）
最新版の動作に一つ問題がある．Verifyを実行して，ボタンが「Stop」になっているとき，これを押すと停止してStopped at xxxx が表示されるが，その直前に何かのダンプが瞬間的にスクロールしている．おそらく，Stopを押したタイミングではまだ検証論理が別スレッドで走っているから，このタイミングでフラグが落とされたためにダンプが可視化されているのではないか？これは画面が停止したときには上書きされているので，実害はないと言えばないのだが，あまり芳しくない．
アノーマルな停止の仕方ないし出力画面の更新には複数の場合がある．①Stopボタンが押されて停止，②検証テストが失敗したために停止，③実行時なんらかのシステム障害が発生して停止，④メール送信エラーが発生してエラー情報をダンプ．⇒始業時バックアップと仕掛り版で異なる動作になっている．どこかいじってしまったのだろうか？⇒確かに一箇所修正が入っていた．Running_Click_1の冒頭で
If Working and Not Runflag Then
となっているところで and Not Runflag を削っている．このように修正すると，Stopボタンを押したタイミングで例外が発生するようになる．オリジナルではStopボタンではこの論理を通らない．Working というのは，検証テスト中でかつ，検査ルーチンのGetTheSequenceとGetTheNumberのペアを実行中という意味だ．Runflag というのは，検証テスト中という意味だから，どこかでRunflag が落とされた場合には無視するという意味になる．しかし，もう少し進んだところで出口に向かうようになっている．しかし，この論理もややおかしい．出口に分岐する前に実行しているのは各種パラメータの初期化だが，ここで開始時刻なども設定されている．
しかし，それにしては正しい値が表示されているようにも見えるのだが…おそらくこれは，上書きされているため正しい表示になっているのだろう．本来はこの処理はフラグだけ変更して抜けるべきものだと思う．この意味で上記のNot Runflag を外した修正というのは正しい．⇒Not Runflag を外すことで余分な処理を実行することはなくなったが，逆につねに Test Completeになってしまう．RunFlagを落としてやればよいのだろうか？⇒そのようだ．気持ちよく止まるようになった．
これ以外のアノーマルケースの動作も確認しておこう．②は問題なく動作する．②の検証テスト失敗と，③の実行時システム障害は本質的に同じだ．③ではたとえば，整数演算でエラーが発生するなどのことが考えられるが，メモリ不足を除けば，これらすべては論理ミスということになると考えられる．メモリ不足は避けられないが，これもある意味では「検証テスト失敗」と呼べなくもないので，同じ扱いでよい．メール送信エラー時にはすでに検定は完了しているのだが，その後に発生したエラーをログとして記録するという趣旨なので，現状でよいと思われる．
メール送信結果はメッセージパネルで通知されるが，ユーザとの応答をテキストボックス上でやっているのだから，ここにも何か残した方がよい．⇒対処した．これで完成だ！リリース版を起こしてみよう．⇒所要時間は24時間制になっているが，24時間を超える場合もあり得る．dayまで表示するようにしておいた方が安全なのではないか？⇒対処した．一日を超える場合にだけ日数をdays.hh:mm:ssの形式で表示するようにした．これで完成というところかな？
このパッケージには，高さ8の3-正則コラッツ木のサンプルをPDFファイル形式で添付する予定だ．Collatz Tree Generator のCSV出力をゼルコバの木にインポートして，CubePDFに出力し，LibreOfficeで調整したものだ．全766点というゼルコバの木としては大型のサンプルになったが，「正則コラッツ木」というものがどういうものか，直感的に理解してもらうにはちょうど手頃のサンプルではないかと思う．V1.1.0とした．今度は24時間を超えても対応できるので，予備機では少し欲張って2^28という設定で仕掛けた．24時間くらいあれば完了できるのではないかと思うのだが…
開発機にも仕掛けておくことにしよう．予備機の受け持ち区間の続きをやらせることにする．こちらは，ちょっと無茶だが，2^32まで仕掛けてみる．スタート時点ですでにかなり大きい数になっているので，どういうことになるのか…まぁ，一種の限界テストないし耐久テストということでやってみる．⇒さすがにこれは少々無理っぽいという感じもする．いつまで経っても0.01%まで上がってこない．⇒予備機の方は，30分で1%くらいなので，1時間で2%として，50時間，ということは丸2日は掛かりそうだ．開発機の方はもっと遅く，30分でわずか0.15%だ．うまく行っても，3時間で1%くらいだろうか？何日掛かるのか見当もつかない…1ヶ月は掛からないとは思うが，1週間では終わらないだろう．