會員系統擴大到87站，抓到存取漏洞
8月25日的重點是喵宇宙的會員系統擴大上線，途中抓到一個真正的存取控制問題；另外也解開了一個關於「網站合併後多久會自動上線」的認知落差。
會員系統擴大，途中抓到一個存取漏洞
這天把跨站共用的會員系統（帳號、收藏、個人資料一套通用機制）開放的站台從11個擴大到87個。上線前的檢查中，找到並修掉一個真正的存取控制問題：部分讀寫使用者個人收藏資料的功能，原本會優先採信網址參數裡指定的站別，而不是登入時綁定的站別——理論上，任何一個已經接上這套系統的站，都有可能藉著更改這個參數，讀到或寫到使用者記錄在別的站底下的資料。我們查證了當時已經在用的四個站台，確認沒有任何一個站依賴這種行為，才把規則改成一律只採信登入時綁定的站別，再繼續擴大開放的站數。
同一輪工作也把刪除帳號這個功能補齊。原本只有一支不對外開放的管理員硬刪除工具，而且先前一份紀錄一度誤以為完全沒有這個功能。這次新增了軟性刪除與30天保留期，保留期內都能救回，30天後才真的清除；使用者自助刪除帳號的功能也做了，但預設關閉。
盤點過程也發現，這套會員系統的程式碼其實從來沒有被好好地版本控制過——它長期只存在於一台機器上的工作目錄裡，近期的多次修改都沒有存檔備份。前一天已經另外建立一個獨立的程式碼庫保存下來，這天再把新增的修改補進去。
另外，有一個還沒上線的獨立站台頁面上寫著「目前僅供展示、正式上線前需經專業人員審閱」，但站內資料其實早在17天前就已經標記為xmy本人已經審閱過——文案沒有跟上實際狀態，對外等於用「尚未審閱」誤導可能的訪客。發現後已經把這段文字拿掉，這個站台目前仍未正式上線。
合併不等於上線：一個網站的部署謎團
這天稍早，一份針對自己的個人網站英文版關於頁面的公開文案審查（核對頁面上所有具體數字與經歷是否都能對回既有公開資料）通過確認後正式合併。理論上網站應該會很快自動更新，結果兩個多小時後，英文版的新頁面依然顯示找不到網頁。追查後發現問題不在程式碼——原始碼是完整的，而是這個網站幾個月前已經悄悄從原本會自動部署的平台，搬到了Google的雲端服務上；新的部署方式需要人工執行兩個步驟（把程式碼送去雲端組建，再切換正式流量指到新版本），而且這兩步都設有人工核准的關卡。當天沒有執行這兩步，新頁面因此停留在核准前的狀態，並未真正遺失或損毀任何內容。這個發現也連帶更正了先前一份工作紀錄裡「合併進主線幾十秒後就會自動上線」的舊說法——那個說法已經不適用於這個網站。
這天其他出錯的地方
- 其中一個網站有一批法規機關名稱的更新，一開始把哪個單位被併入哪個單位的方向寫反了，經覆核後當天更正，影響9個檔案裡74處提到這個機關名稱的地方。
- 另一個網站原本有兩個平行存放文章的資料夾，篇數一度對不上，原因是先前一次任務不小心遺失了檔案、後來的還原又只做了一半。這天補齊後，兩邊資料夾都變回117篇一致。
- 在對60個站的網域設定做全面掃描後，抓到2個真正有問題的站：其中一站的一個備用網址其實只是重複內容，另一站的一個備用網址則指向舊的部署版本、不是最新內容——兩者都已修正，重新指到現行版本。
其他進展
這天也完成了一次跨平台的存取盤點，把先前一份報告裡幾個算錯或估錯的地方一次修正：原本以為密鑰集中存放在一個雲端保管服務裡，查證後那個服務其實是空的，真正在用的密鑰分散存放在別的系統，持有那些系統寫入權限的人等於已經拿到好幾把正式密鑰；原本粗估部署平台有80多個專案，實際分頁算過後是463個，其中只有104個是真正在使用的正式站，其餘是各種測試與已棄用的專案；先前說本機硬碟有四分之三的檔案被雲端硬碟自動清出本機，其實混雜了兩種完全不同範圍的統計——版本控制紀錄有99.9%被清出（這也是為什麼版本控制完全損毀），但實際工作檔案只有29.7%被清出，大部分程式碼其實還在。
另外，對於要不要把一位協助者在雲端平台的權限直接升到最高等級，雲端平台本身的規則擋了下來——沒有設定好組織架構的專案，沒辦法用指令直接開通最高權限，只能透過網頁介面一個個專案送出邀請，對方接受後才生效（邀請效期7天）。目前這位協助者對雲端專案仍只有唯讀權限，等xmy逐一送出邀請、對方接受後才會真的取得存取權。