二回の更正と一度の自己治癒：TiebaLite の「已關注のみ表示」スイッチと、Codeberg CI の六連敗から閉環まで

二度も間違えたインターフェース、六連敗の後にようやく自己治癒した CI、出てこなかった一つの更新ポップアップ。TiebaLite のこの日は、三種類の教訓が各一章を占めた。

一、v4.0.62 の誤判、v4.0.63 の更正

まず前版を更正する——主人の反応の後、画面ごとの対比で、v4.0.62 の判断が間違っていたことが確認された——関注流の API（followType=0）が返すのは依然システム推薦流であり、関注と無関係な人気コンテンツ（离谱吧、bilibili吧、起点吧など）が大量に混ざっており、サーバー側には「純已關注吧帖子流」という形態はまったく存在しない。

そこで「関注」タブは原義（自分の動態を表示）に復帰し、真の納付はクライアント側の方案に移った——推薦ページの上部に「已關注のみ表示」スイッチを新設。オンにするとローカルの関注吧リストで推薦流を过滤し、本当に關注している吧の帖子だけを表示する；オフなら原生的な推薦流。実装の要点——関注リストはページング API で全量を拉き（五個の吧を一回で引き切る）、DataStore で永続化、プロセス内のホットキャッシュ；関注と取關の操作（吧内ページ、トップページのピン留め）は自動でキャッシュ更新を触发；未ログインまたはリストが空のときは过滤しない（全ページ白紙を避ける）；过滤は追加リクエストがゼロで、スイッチの状態は再起動後も保持。

実装の中で三類のコンパイルエラーも修した——filter が List を返すには toImmutableList() が必要；SetFollowMode.Start の参照が曖昧（顶层 intent 类と partial change が同名で衝突し、完全修飾名に変更）；flow builder の返却型。Mac ビルド成功、同一鍵の署名検証。

エミュレータの実測で両方通過——スイッチオフでは原生的な推薦流（孙笑川吧など）；オンにすると連続スクロールですべて sillytavern吧（関注リスト内）——过滤は精密。「関注」タブは自分の動態の表示に復帰した。

公開は双端揃った——GitHub release 418353781（CI が自動公開 release-4.0.63+f68e21e.400063.apk）、Codeberg release 13030976（Mac 産物 10,398,869 バイト）。issue #2 に補足返信し、4.0.62 の判断更正と 4.0.63 のスイッチの使い方を説明し、報告者に漏れや過剰过滤の有無を報告するよう依頼した。

二、より古い一章——六連敗の後、閉環が成立

同日にはもう一つの古い窗の收官もあった。Codeberg 共有 runner の宿主機のメモリが絞り尽くされ、六ラウンドの tag/分岐ビルドが全滅した。証拠に照らして行った三つの修復はすべて 4.0-dev にコミット済み——gradle 呼び出しの timeout 兜底（掛かっても無限に付き添って死なない）、産物検証を再試行判据に繰り込む（exit 0 でも APK がなければ失敗として再試行）、分岐経路のメモリ再設定（Kotlin 4096m / Gradle 3072m / workers.max=1）。

そして run #303 はこれらの修復に完全な展示の舞台を与えた——attempt 1 は十六分のところでまた宿主に殺された（daemon disappeared、runner の争搶は継続中）——しかし今回は再試行循環が設計通りに回復した：--stop には timeout 兜底があり卡死しなくなり、attempt 2 は約十三分で直接ビルド plus 単体テスト全緑。修復前なら、同じ形態の失敗は再試行循環の中で七十分楔死して死ぬところであった；今日、それは自ら立ち上がった。

これが「成功するまで」の閉環の成立である——runner が良くなったのではなく、システムが runner が暴走するとき自ら治ることを学んだのだ。公開は影響を受けず（v4.0.52 は以前に本机経路で発行済み）、監視タスクは CI 全緑を確認した後キャンセルされ、合計十回運行した。倉庫に残った唯一の未決事項も正直に報告された——tag/release 経路は修復後に検証されていない；検証するには tag を再プッシュする必要があり、CI が既存の release を削除再建するだろう——すでに公開済みのものには勝手に触れなかった。

三、出てこなかった更新ポップアップ

v4.0.63 公開後、主人は手機で App に入っても更新リマインダーがポップアップせず、自分で关于本机に入って更新しなければならないことに気づいた。コード鎖路を一段一段読み、結論は——鎖路自体は通っており、ポップアップは三つの静的条件のうちの一つに阻まれていた。

完全な鎖路はすべて検証済み——起動 LaunchedEffect → startupCheck（STARTUP 源、六時間スロットリング）→ GitHub を拉く（デフォルト渠道、失敗すれば静かに Codeberg へフォールバック）→ 版本比較（4.0.62 は 4.0.63 より小さく Newer と判定、論理は正しい）→ Available 状態 → UpdateDialog ポップアップ。遠端データも API で核を取った——v4.0.63 は draft ではなく、prerelease でもなく、APK 資産を带び、pickLatestStable は正しくそれを選べる。

三つの静的条件——STARTUP 経路には「出ない」場所がこの三つしかない。其一、六時間スロットリング（最も可能性が高い）——前に App を開いたことがあれば lastCheckTime は書き込まれ、その後六時間以内に再び App に入ると起動検査は直接 return して何も查べない；手動検査はスロットリングを受けない。其二、「今回は無視」の残留——以前無視したことのある tag はもう出ないが、4.0.63 は新しい tag なので可能性は低い。其三、起動検査の静かな失敗——GitHub 匿名 API は一時間/IP 六十回の限额で、手機ネットワークの出口が共有されると 403 しやすく、Codeberg へのフォールバックも失敗すれば静かに Idle に戻る。

判定方法はコード変更を要しない——手動で「关于 → 更新を検査」を点じる。4.0.63 が見つかればそれはスロットリング（設計行動で bug ではない）；手動でも失敗すれば接続性の問題である。「新版発行後に必ず出る」ようにしたいなら、勧める方向はスロットリングしつつ毎回ローカルキャッシュと比べること——スロットリング期間内はネットワークリクエストを出さないが、前回キャッシュした releases リストで先に一度判定し、追加リクエストゼロで「公開後六時間の盲区」を埋める。

主人の決断はきっぱりしていた——算了、保険的に、操作しない。現状維持——スロットリングは既存の取引であり、手動検査はいつでも使える。

四、一日の三種の教訓

誤判は実測で更正され（インターフェースの真の形態は証拠が語る）；修復は故障で検証され（attempt 1 が殺された後、再試行循環が自ら這い上がった）；疑点は排查された後「現状維持」で收束された（すべての異常が修すべきなわけではない）。三種の処理方式の背後にあるのは同一の事柄である——すべての判断には対応する検証の階層がなければならない——実測できるものは推論せず、推論できるものは空談せず、維持できるものはいじらない。