輪郭選り手抜控機能整備を概ね終え，ようやく出振るい出来た。追い追い修正していけばいい程度の軽微な不具合はいくつか見つかったが，抜控機能整備についてはここで一段落とすることにした。

この出振るいにより，中途半端な実装だった輪郭選り手抜控機能に一通りの機能が揃った。下書き抜控一覧も使えるようになり，抜控の把握が容易になった。予てから欲しかった新規描出フォームの消去・復元ボタンも抜控の削除のため追加した。18日の開発で実装した描写拡縮ボタンも使えるようになった。また，周辺の交度整理も大きく進み，理腑としての意義も大きかった。

利便性・信頼性の向上はもちろんのこと，昨年から中途半端な状態で引きずってきた当努が片付いたことによる精神衛生上の効果も大きい。昨年来の他の当努は本格的に着手していないか，着手して間もないので，ここから思考を整理しやすくなる。

抜控機能整備が長引いた最大の原因は，他にやりたいことが多過ぎたことだが，これ自体も決して簡単な作業ではなかった。ただ，この間に設計方針が変わったり深刻な不具合に気付いたりしたので，時間をかけたことで円滑に片付いた面もある。

再描出は知番でいいとして，新規描出の鍵をどうするか，というのは難しい問題の一つだった。昨年7月28日6歩から検索語を鍵に含めるようにして悪くなかったので，基本的にこれを踏襲することにした。ただし，全知検索窓から未送信の検索語まで取っていたため，これを書き換えると意図せず他の抜控を上書きしたり消去してしまう可能性があった（4月28日20歩で書いた消失不具合の原因だろう）。これは求頼文字列から取ることで回避した。

下書き抜控一覧についても，表示条件や領当てなど色々考えることが多かった。検討の結果，再描出下書きは，検索語無しの場合（上部メニュー同様）のみ輪郭一覧の上に表示（画面撮り），新規描出下書きは，他の抜控がある場合のみ新規描出フォームの上に常に表示させることにした（画面撮り）。邪魔になり過ぎない程度に気付きやすい。また，4月10日の開発で決めた通り，一覧は省略などせずにそのまま表示することにした。描写部のように高さ固定することも考えたが，やはり，用合いの複雑化と抜控を溜め込み過ぎる懸念があるため見送った。抜控の溜め込みは性能低下，消失リスクの増大（あるいはそれを補う作業コストの増大）に繋がる。目障りになったら消化するようにしてもらいたい。

一番難しかったのは鍵仕様の設計だった。一応，鍵仕様変更時の更新方法は考えていたが，手間を考えるところころ変えるわけにもいかないので，長期的視野に立って設計する必要があった。これもなんとか落とし所が見つかった。一時，鍵に仕様変更日時を含めることを考えていたが，これは複雑化を招くだけなので廃案とし，Aejs_DG_rev に判別用の文字列を入れておくことにした。新規描出下書き抜控の鍵には自我知番を含め，自我の切り替えにも対応した。

その他，これまで描写のみ保存していたのを知名にも対応する，消去ボタン・復元ボタンを実装する，などこまごまとした問題を片付ける必要があった。

出振るい後，軽微な不具合がいくつか見つかったが，一番気になったのが，鍵仕様の更新処理の失敗だった。領下で十分な手定めをしたつもりだが，本番環境では一部の鍵が1回の処理で更新出来なかった。結果的に，3回実行する必要があった。開発者通類で localStorage の内容を見ても交度を見返しても心当たりがない。

少し迷ったが，時間が経つにつれ重要性が急速に低下する部分なので，調査は打ち切ることにした。最も使用頻度の高い私や常連用者達が出振るい後も普通に使えていることから，深刻な問題は発生していないと判断した。今後，同様の処理を書く際の注意点として記憶しておく。

CSS 変数（カスタムプロパティ）の導入と舞覧（ブラウザ）五年対応原則の採用を決めて終了。今後デライトでは，「5年以内に離立された版存の主要舞覧」を中心に対応していく。

希哲15年3月1日の開発から「デライト推奨動作環境」として同様の定義を考えてはいたが，当時は，古い舞覧対応の努力はするが推奨はしない程度の，もっと緩やかなものを想定していた。

希哲13年に ECMAScript 2015，HTML5，CSS3 と比較的新しいウェブ標準の導入を決めてからだいぶモダンにはなったが，まだデライトの舞覧対応方針には感覚的で保守的なところがあった。感覚的に，影響範囲の広い付徴は主要舞覧の対応から10年，影響範囲の狭い付徴は5年を目安に導入を考えていた。rem ですら必要以上には使わなかった。

先日，前次記法実装でグリッド領当てを導入したが，これはちょうど主要舞覧で使えるようになってから5年ほど経つ機能だった。一記法の装体に過ぎなかったこともあり，ここまでは辛うじて良かったが，他にも色々応用したいことが出てきて舞覧対応方針見直しの必要を感じていた。

決め手は，デライトのダークテーマ対応も見据えて CSS 変数の導入を考え始めたことだった。CSS 変数も主要舞覧の対応から5年ほど経つが，本格的に導入するとなると影響範囲が広がり過ぎる。

Can I use で対応舞覧をよく調べるようになってから，「5年以内に離立された版存の主要舞覧」が意外に普及していることに気付いた。大体90％以上はある。

地域にもよるだろうが，確かに，今時古い舞覧を使い続ける方が難しいかもしれない。個人機なら5年は平均的な買い替え周期であり，スマートフォンなら古い部類だろう。自動更新も標準的になった。昔と違って，多数派の“普通の人”ほど新しい舞覧を使っている。

あえて古い舞覧を使い続ける場合というと，一昔前なら古い個人機の再利用というのがあったが，格安インターネット端末が普通に流通している今，新しい舞覧が使えないほど古い端末を使い続ける費用対効果は疑わしく，制危も考えれば推奨出来ることではない。

一番面倒なのが舞覧の更新が許されない企業内利用だが，そもそもそんな保守的な環境でデライトが利用出来るとは考えにくい。

こう考えていくと，デライトにとって古い舞覧への対応の重要性は極めて低いと言わざるをえない。

奇しくも，新生デライトの完成を目指している6月の15日に，IE11 のサポート終了がある。中途半端な気もする内容だが，いわゆるモダンではない舞覧最後の砦が崩壊する。新しいウェブ標準への社会的移行の象徴的な出来事にはなる。

ある程度古い舞覧への対応を考慮してきたのは，企業体力がついた将来，対応を拡充することを考えていたからだったが，これもよく考えると合理性が怪しい。

“技術的負債”は簡単に金で返せるものではない。大企業が肥大化した交度にいかに苦しめられているかを考えれば，合理的に古い舞覧への対応が出来る日が来るかどうかも分からない。むしろ，組織が大きくなった時にこそ見通しの良さが重要になる。

もっと根本的なことを言えば，デライトはウェブ標準という盤本の“キラーアプリ”になるべきものだ。新しいウェブ標準の普及を牽引していくくらいの考えがなくてはいけない。

その伝証（デモ）の足掛かりがすでにこれだけ普及していれば十分過ぎるだろう。

舞覧五年対応原則の導入によって，ウェブの理想と現実における汚い現実の大部分だった古い舞覧を正しく切り捨てることが出来るようになり，前縁整備はもちろん，デライト文書整備でも大きな効率化がもたらされるだろう。文書整備では，対応舞覧についてどう説明していくかが一つの課題だった。ここまで絞り込めば説明もすっきりする。

デライト開発を劇的に合理化した描出公開原則とともに「デライト二大原則」と呼ぶべきかもしれない。思えば描出公開原則もデライト正式離立という大きな節目を目前にして生み出したものだった。

Aejs 整備。

途中で終了。

数式，交度，埋め込みツイートの表示もリアルタイムで出来るようになり，あとは領当て調整などをすれば下見機能はほぼ完成というところまで来た。

Aejs 整備。

輪郭選り手周りの交度の整理が終わりつつある。用合いの感触もだいぶ良くなった。

Aejs 整備。

不具合から久しぶりに事象周りの交度を見直し，良い発見があった。

続きは明日にして今日はここで寝ることにした。

12日の脳爆発を引きずってまだ脳疲労感が残っていた。一ヶ月分にも相当するであろう収穫だったのだから仕方ないと，気分転換も兼ねて，半年ほど放置していた Aejs 整備を再開してみることにした。

まずは交度の見直しと軽く違了修正程度出来ればいいと始めたものの，驚くべきことに，作業の続きがよく捗った。これだけ間があくと，作業方針を思い出すのと再整理に時間がかかるのではないかと思っていたが，むしろ中断前より捗った気がする。この半年間での環境整備や設計方針の洗練，知見の蓄積がそれだけ大きかったのだろう。当時は，ゆとりがなく混沌とした状況でもあった。

金風で中断してからなかなか再開出来ず，中途半端な状態で出振るいも出来ず，前縁周りの作業が非常に進めにくい状況ではあったが，この間の収穫を考えれば仕方ないと思っていた。設計面・仕様面での変化も小さくなかったので，再修正の手間も省けた。唯一の懸念だった作業再開にかかる負担が全くと言っていいほど無かったのだから，仕方ないどころか大正解だったと言うべきだろう。

Aejs 整備の中断経緯について記録を振り返っている内に，もう一つの放置課題だった KNEST 隠し実装についても再整理が急速に進んだ。

輪郭選り手抜控機能整備がなかなか進まなかったことで Aejs 整備に入ったのが昨年9月9日だった。14日11歩を最後にそれも止まり，代わりに HTML 隠し実装からの KNEST 隠し実装に重点を移すことにした。頭の整理をしているうちに18日になり，金風が起きた。以後は何度か再開を試みているが継続出来ず，そのまま第二次快調期に突入した。

金風があまりに大きい出来事だったので，このあたりで記憶が分断されている感覚がずっとあった。特に Aejs 整備と KNEST 隠し実装は，第二次快調期でも置き去りになっていた部分で心残りだった。第四次宣伝攻勢に向けて新生デライト開発も佳境というところで二つの強力な武器を上手く取り戻せた。言うまでもなく，極めて大きな収穫だ。

ただ，結局どっちを向いても脳爆発で，脳疲労は癒えなかった。

今日は疲労回復のため休みにしたが，次回の陶練からランニングを再開することにした。

これも第二次快調期からほとんど出来なくなっていた。忙しさもあったが，生活習慣の乱れに寒さが重なり，1月には風邪を引いたりもしていたため，大事を取っていた。最近は，少しずつ生活習慣改善も再開出来，暖かくなってきたので大丈夫だろう。

最近の生活習慣改善を「第四次生活習慣改善」とするかと考えたところで，すでに金風以後の生活習慣改善を指して使っていたことを思い出した。用語として考えた12月9日から間もなく第二次快調期に入ったので，目まぐるしさで忘れていたのだろう。とりあえず「第四次生活習慣改善の再開」としておくことにした。

（16日の振り返り日記）

（進捗時限記録中略）

今後の Dex 設計方針についての検討で終了。これから越化参照が大活躍しそうだ。

まず，課題だった脚注記法の実装方針について検討している内に，越化参照が部区間通信に活用出来ることに気付いた。

部区毎に越化条件の変化などがあることから，各記法の解釈は部区個体に任せたい。しかし，脚注記法のように最上位部区との出与え共有が必要な記法もある。

このような場合，単純に考えれば指示体を通して部区個体間で変数を共有するということになるが，この種の記法が増えるたびに目的別の指示体を増やすのは設計として美しくない。汎用的な変数一つに集約するのも，効率性や厳密性の観点から難がある。

ここでふと，越化参照が使えることに気付いた。下位の部区個体で中途解釈した記法には目印となる越化参照を付け，上位の部区個体で変換処理を完了させる。

これに似た部区間通信の手法は Dex 初期実装から現 &_skp; で使い続けているが，どちらかというと「邪道」だと感じていたため，意図的に応用範囲を広げなかった。紆余曲折を経て，これが一番単純性・効率性・保守性のバランスが良いということが分かった。

これで脚注記法や目次記法の実装は容易になった。他にも，輪郭情報の参照が必要な記法など，部区間通信が必要な場面全般で越化参照が活用出来るだろう。

もう一つ，処理済み対象の識別に関しても進展があった。

1月21日4歩で，&_tgt; や &_fin; のような目印を付加することを考えていたが，付加的な越化参照では結局正規表現の複雑化が避けられないため，実用化出来ていなかった。

昨日終えた客体表現への書き換えで Dex 初期実装の交度を整理している時，再置換を避けるため記法の一部を越化参照（当時の疑似実体参照）に置換する手法を使っていたことを思い出した。これもあまり積極的に応用範囲を広げなかった手法だが，思っていたより合理的であることに気付いた。

例えば，http は &_http; のように一時的に置換してしまえばいい。考えてみれば単純なことだが，灯台下暗しのごとく単純なことの真価を理解するには時間がかかるということを改めて学んだ。経験不足だと，どうしてもより高度そうなことに目移りしてしまう。

面白いことに，どちらも原点回帰のような発見だった。

直感で編み出した Dex 初期実装の手法を再評価する十分な経験が出来たこともあるが，「越化参照」という概念が完成し，積極的な活用を考えられるようになったことも大きいのだろう。中途半端だった「疑似実体参照」から発展したのはつい先月のことだ。

（進捗時限記録中略）

Cμ 文字列処理改良，rgx_T の置換道手の引数順序変更，客体表現への書き換え。

込み入っていた数式記法と交度記法の越化処理を代置子方式で統一しつつ，客体表現化を終えた。これをもって既存記法の客体表現への書き換えは完了とする。

この作業により交度の見通しが劇的に良くなり，多少体感出来る程度の高速化も出来た。基本的に理腑なので解決していない不具合もまだ多いが，今後の不具合修正は捗りそうだ。

Cμ 文字列処理改良はまだ緒戦だが，この段階で期待以上の高速化が出来たことは嬉しい。客体表現の強力さも実感出来た。