臨時休業したためのんびり作業したが，収穫はそこそこだった。

まず，輪郭選り手抜控機能整備の出振るい後，気になった問題を概ね解消した。これで気持ち良く次の当努に移れる。今後の作業方針についての考えもまとまりつつある。色々な気付きもあったが，早く寝たいので作業時に書く。

• 再描出下書き抜控の読み取りを自我毎に出来ていなかった問題を修正。
• 実質内容のない新規描出下書き抜控が残りやすい問題に暫定対応。
• 知名・描写の片方しか下書き抜控がない場合でも合体選り手を開くように修正。
  • 挙動面でまだ若干混乱があるため暫定対応。
• 新規描出下書き抜控一覧のラベルを「下書き」から「他の下書き」に変更。
  • 再描出下書き抜控一覧とともに「下書き」で統一，波括弧・角括弧のみで区別していたが，性質の違いが分かりにくかった。
  • 付け加え過ぎると冗長感が強くなり，かえって直感的な理解を妨げるのでこのあたりが落とし所か。

ここで録入り状態照合処理実装に入ることにした。

作業方針まとめで終了。

違了処理整備，輪郭選り手抜控機能整備などを経てデライトの信頼性は飛躍的に向上したが，録入り状態の不整合による下書き消失が無視出来ない問題として残っている。

先日の見直しで強制録落ちの確率はかなり低下したはずだが，事故ではなく，こまめに録落ちしたり，自我を頻繁に切り替える場合にも問題になる。後縁で録落ちしていると番無しで新規描出してしまうし，自我が切り替わっていると再描出に失敗して下書きだけが消える。

書いた文章の消失も大きなストレスだが，常に消失リスクを心配していなければならないのも用者体験にとって足枷だ。折角ここまで来たのだから，万全にしておきたい。

録入りページへの誘導などの作り込みは後回しでいいので，最低限必要な処理だけ実装しておく。

輪郭選り手抜控機能整備を早く片付けたい一心で日曜日も休まず作業していたため，流石に疲労感が出てきた。

キリの良い所なので，今日は軽い作業と夜の散歩のみで早く寝て，明日は半休にすることにした。

まだ早寝は出来ていないが今日も絶好調だった。

開発ではようやく輪郭選り手抜控機能整備が一段落した。収穫も多大だが，昨年から一番中途半端に引きずってきた当努だったため，気持ちの区切りとしても大きく，非常にすっきりした。

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

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

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

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

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

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

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

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

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

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

輪郭選り手抜控機能整備。

実装はほぼ完了したが交度整理に時間がかかり出振るいはお預け。

輪郭選り手抜控機能整備。

軽微な不具合はあったものの概ね成功。

ここで輪郭選り手抜控機能整備は一段落とすることにした。

輪郭選り手抜控機能整備。

出振るい作業を開始。

途中で終了。

輪郭選り手抜控機能整備。

途中で終了。

輪郭選り手抜控機能整備。

途中で終了。