新着確認機能調整で終了。

先頭輪郭の再描出時，取得時印更新による更新有り表示抑止が効かないことが目立ったため，現在日時に1秒加えて取得時印とすることでいったん解決。秒単位なので後縁の遅延やわずかなずれが原因だろう。

（進捗時限記録中略）

URL 内にデラング記法として解釈出来る文字列があるとタグを巻き込んで変換してしまう不具合（報告1，2，3）の修正で終了。出振るい・手定め済み。

だいぶ前に用者の描出で気付いたが，デラング周りの整理が進まず良い解決策が見つからなかった。HTML 崩れの問題を起こす事例が増えてきたため，交度記法と同じ手法で全体を越化するようにしていったん解決。

ついでに丸括弧との組み合わせで前後に文字列がある場合にも対応しておいた（これまでは URL 単体のみ対応）。他の括弧類や文字装飾記法などとの組み合わせについても検討しておく。

厄介な不具合だったのですっきりした。

給湯は一日問題無し。

古い給湯器があまりにも良い仕事をしてくれたので交換前に拝んでおきたくなり，ほとんど見なかった設置場所を見てみた。型式は GTH-2427AWX3H と書いてあった。

聞いていた水漏れは想像していたよりひどく，ぽたぽた程度かと思ったら給湯器の下からぼたぼた漏れていた。トイレに入ると晴れなのに雨音のような音が聞こえることが以前からあり不思議だったが，原因が判明した。水道代から考えて常時これではないはずだが，水もかなり無駄にしていたらしい。使用量にしては少し高いとは思っていた。

たまにあったガス臭も給湯器が原因だったのかもしれない。

とにかく，早く解決して良かった。

1時間ほど家事など。

また面白い偶然が二つもあった。

一つは，1月中旬頃に雑務の種になるはずだった問題が思いがけず解消したこと。もう一つは，早くて2月頃の見通しだった給湯器交換工事が急に明後日に決まったことだ（整清記録）。特に給湯器問題は驚くほど都合良く起こり都合良く解決してしまった。この問題のおかげで組計にゆとりが出来たし，21日に半日湯が出なかっただけで，古い給湯器もよく持ってくれている。

駄目押しで組計にゆとりが出来，必要なら1月までは新生デライト開発や輪郭整備にほとんどの時間を使えそうだ。どこまでリスクを取るかにもよるが，そのリスクも大したことではない。状況を見ながら天秤にかけていく。

結局，あれよあれよという間に，デライト3周年までの完全な成功を目指すには最適な組計が出来てしまった。完全な成功までの距離から言えば，ここで作れた一ヶ月は，金風で作れた一年にも劣らない価値がある。悔いのないように使いたい。

姉と姪達が泊まりにきて騒がしい一日だった。

（28日の振り返り日記）

新生全知検索整備の再開

10月から中断していた新生全知検索整備を再開した。

中途半端なまま放置していたため，まずは出振るい可能な状態に整理することにした。いつものことではあるが，心配していた割にあっさり記憶が戻ってきて復習は円滑に進んだ。

dg_fnd() の輪数取得処理組み込みを概ね終えて，未出振るいのまま全知検索演算子 ?? の実装に入っていたが，検索群類の追加周りの交度整理で止まっていた。いったん輪数取得処理組み込みまでの出振るいが出来るように整理し，基本的な動作確認を終えた。

明日，一通り点検してから出振るいしてみることにした。

その他

Chrome で @loc.jmp() のスムーススクロール無効化機能が働いていない問題を修正。

輪郭一覧動的更新対応後の新規描出では，スムーススクロール無効化をして輪郭一覧先頭に戻る仕様だったが，Chrome では無効化されていないことに気付いた。ここがスムーススクロールになると若干煩わしい。

利用していた @loc.jmp() 内では，location.href への代入前後で scroll-behavior の切り替えを行っていたが，この時の scroll-behavior: smooth の復元が Chrome では早過ぎたらしい。0.1秒遅来させて解決。

吊るし輪郭でデラング見出し階層が1階層下にずれていることに気付き修正。輪郭情報取得改良で吊るし輪郭向けの見出し階層設定を忘れていた。

修正は簡単だったが，新生全知検索整備の途中で単独出振るい出来ないため未出振るい。

前縁の問題をいくつも解消。特に諸場用合いはだいぶ良くなった。

輪郭小窓のスクロール不具合修正（Android 版 Chrome）

Android 版 Chrome で，全知検索窓を捕活している（ソフトウェアキーボードが表示される）時に輪郭小窓が表示されると全知検索窓までスクロールしてしまう問題を修正。iOS Safari 含め他の舞覧では再現しなかった。

とりあえず，touchend で document.activeElement.blur() を使って捕活を外すことにした。

輪郭小窓の誤移動不具合修正（iOS 版 Safari）

iOS 版 Safari で輪郭小窓が開く前に輪結先に移動してしまうことがある問題を修正。

iOS 版 Safari でのみ同じようにタップしても10回に1回程度の割合で生じる謎の現象だったが，実験を繰り返した結果，どうも click 事象が余計に発生しているようだった。

いったん click 事象を抑制し，touchend で輪結先に移動するようにしたら，意図しない移動がなくなった代わりに，同程度の頻度でタップしても輪郭小窓が開かない問題が生じるようになった。条件はありそうだが，感覚的には全くの不規則なのでどうしようもない。

ちょっとした用事を片付け，第二次快調期からまともに出来なくなっていた書類整理も少し進め，あとは大輪郭整備や考え事をして過ごした。

考え事での大きな収穫として，文書整備にかかわるデライト用語体系の方針がまとまった。

デライト用語体系に関しては，従来の輪郭法新用語体系を基礎に，初心者向けの分かりやすい代替用語の導入などを検討していたが，これはやめ，基本的に新用語体系をそのまま踏襲し，説明体系を洗練させていくことにした。

例えば，知名を「輪郭名」，知番を「輪郭番号」などと説明することを考えていたが，元々技術としての固有性・独立性が高い知番に関しては早々に断念していた。「輪郭名」などを補助的に導入するかどうかで最後まで迷っていたのが知名だった。この問題を考える上で，「知名」という用語の妥当性についても再考する必要があった。

「知名」の必然性について直感的な確信はあったものの，言語化が意外と難しかった。それを象徴するかのように，いつからか，輪郭「知名」の選り手は開きっぱなしで，再描出下書き抜控一覧を実装した頃から常に表示されている唯一の輪郭になっている。

知名は単なる「記事名」でも「題名」でもなく，森羅万象に付けることが出来る認知上の名前であり，その性質は既成語では表現出来ない。更に，「輪郭の名前」として輪郭に従属するものではなく，あくまでも「知の名前」として理解される必要がある。そうでなければ，そもそも輪郭が何を目的として何を扱っているのか分からなくなってしまうし，自己目的化しかねない。ここに知名という用語の必然性がある。輪郭とは，知の名前と知の番号を鍵に知そのものを具現化するものだ。

この方向で説明体系を洗練させていけば，代替用語は複雑化を招くだけのものになる。「急がば回れ」で，多少時間はかかってもデライトを正しく理解出来る説明をしていくべきだろう。この点において，特に「輪郭」「知名」「知番」「描写」といった基礎用語には動かしがたい“正しさ”があり，それは十分わかりやすく説明出来る。ようやくその確信が持てた。