 Leo
|
5c0bddacc4
|
v0.18.20：失敗清單改摺疊式＋修指紋閘的自我參照
## UI（leo 實測版面被壓扁）
失敗清單改用原生 `<details>`：只列檔名、旁邊三角形、**預設收合**，
點開才看原因。先前把原因攤在檔名旁邊，中文檔名被擠成一行一個字。
## 🔴 指紋閘三修：帳本自己不能算進指紋（經典自我參照）
`.version-source.json` 就住在 `collector/` 底下 ⇒ 戳版號寫入它、指紋跟著變
⇒ **同一輪連續打 win/mac/msix，第二支就被自己的閘擋下**（實撞）。
查證過才修（沒有亂放寬）：
· `gen-icons.py` 產的 .ico **位元一致**，不是它
· `dist/` 早就 gitignore，不在名單裡
· 真兇只有帳本
⇒ **只排除帳本一個檔**。一度想順手排掉整個 `build/`，那會讓「換 app icon」
不算原始碼變更＝在閘上挖洞，已收回。
驗：連跑兩次版本號相同（冪等）。
## 三種產物都備齊（在共用資料夾）
`Arcrun-win-v0.18.20.exe`／`送審用/Arcrun-v0.18.20.dmg`／`送審用/Arcrun-v0.18.20.msix`
⚠️ MSIX 的 **Identity 三值仍是佔位**（`PLACEHOLDER.ArcrunRAG`）⇒ **不能送 Store**，
需 leo 從 Partner Center 提供 `IDENTITY_NAME`／`PUBLISHER`／`PUBLISHER_DISPLAY` 再重打。
## 未送達
線上仍 v0.18.8。推遠端需 leo 開 D20 閘。
|
2026-08-06 22:39:42 +08:00 |
|
|
Leo
|
6e0b65a2bb
|
mistakes：Workers AI 額度用完／掃描版 PDF——兩個「不是 bug 但要說清楚」的已知現象
|
2026-08-06 20:48:01 +08:00 |
|
|
Leo
|
6698f9fbda
|
v0.18.10：讓「同步引擎沒在跑」說出死因（leo Windows 實測①②的診斷前置）
leo 08-06 Windows 回報：「一直在『看守中』和『沒有在跑』中間閃，要我重啟但重啟無效，
我覺得它在跑個迴圈不停重複」＋「加一個資料夾明顯沒產生看守資料夾」。
朋友的一般 PC（非 ARM）也一樣，停在等待中 ⇒ **不是 ARM 模擬的問題，是 Windows 通用**。
## 已定位的機制（不是根因，是「為什麼查不出根因」）
閃爍＝子行程一啟動就死 → supervisor 退避重拉 → 狀態在 Starting（alive=true）與
Error（false）之間彈跳 ⇒ 畫面跟著閃。而**死因一直被記在 Status().LastError 裡，
從來沒有上過畫面、也沒寫進 app.log** ⇒ 使用者只看到閃爍與「請重新開啟」，
重開當然無效（死因沒變）。這是「安靜地略過」的同一種病換地方發作。
## 這版做的
- 死因上畫面：重試 >= 3 次改顯示「同步引擎一直啟動失敗，已自動重試 N 次｜原因：…」，
且**黏住不閃**（不受重起過程中的 Starting 影響）
- 每次異常結束寫進 app.log（同錯誤 10 次內只記一次，避免洗爆）
## 排除掉的嫌疑（查過，不是）
- PDF 引擎（pdfium/wasm）：**延遲初始化**，第一次讀 PDF 才啟動 ⇒ 不會在啟動時炸
- ARM 模擬：leo 朋友的一般 x64 PC 同樣症狀
- 待查嫌疑：Wails 的 Windows 版是 `-H windowsgui`（GUI subsystem，無主控台），
而 v0.18.8 的 collector.exe 是 `go build` 的 console subsystem——
v0.18.9 合併成單一 binary 後，子行程換成 GUI subsystem 的自己。**尚未證實。**
## 順帶修好自己的閘（它擋對了我）
指紋閘擋下「v0.18.10 已對應另一份原始碼」——因為第一次打包失敗、版號卻已被戳。
⇒ 加判準：**磁碟上沒有該版號產物＝從未出貨，允許重戳**（不用去手改 JSON，
那種爛示範遲早被改成「都放行」）。
## 安裝程式（leo ③）尚未兌現，誠實記錄
`wails build -nsis` 需要 makensis；Homebrew 的 3.12 在這台 macOS **連兩行的最小腳本
都在寫檔階段丟 std::bad_alloc**，zlib/bzip2/lzma 三壓縮器全崩，brew extract 舊版
被 homebrew/core 擋。且帶 -nsis 會讓 wails 整個中止、連 exe 都不產
⇒ build-win.sh 改成**先煙霧測試 makensis**，壞的就只出裸 exe 並大聲警告。
|
2026-08-06 18:27:08 +08:00 |
|
|
Leo
|
0b8bc83bd1
|
版本指紋閘（同一版號只准一份原始碼，實測有效）＋落帳封測兩病與 md 真相
|
2026-08-06 16:17:40 +08:00 |
|
|
Leo
|
b783b870e6
|
版本號改由 changelog 決定：從頭到尾沒有人打過數字，且與更新內容天生綁定
## 為什麼推翻自己幾小時前的做法
上一版用「動過 collector/ 的 commit 數」當 patch。確實不用手打，但
**每個 commit 都變成一版**（一天 5 個 commit 就跳 5 版），
每跳一版還要補一段 changelog ⇒ 把機械化變成新的手工活。leo 要的不是這個。
## 現在的機制（daemon-version.py）
單一真相源＝docs-site/.../help/changelog.md：
· 要出新版 ⇒ 最上面加一段 `## 下一版（未發佈）`，底下寫白話更新內容
· 打包時腳本把它**戳成正式版號**（上一版 patch+1）並補今天日期
· 沒有「未發佈」段 ⇒ 版本＝最上面那一版（重打同一版，冪等不虛增）
⇒ 版本號沒有人打過；且不可能「升了版卻沒人知道改什麼」，
也不可能「寫了內容卻忘了升版」——兩者出自同一段文字。
換線（0.18→0.19）只改 DAEMON_LINE，下一版自動從 0.19.0 起。
刪掉 daemon-version.sh 與 DAEMON_PATCH_BASE（一版的殘留）。
## 驗（實測輸出）
· `## 下一版（未發佈）` --stamp→ `## v0.18.7（2026-08-06）`（腳本自己改的）
· 沒有未發佈段時重跑 → 仍回 v0.18.7（冪等，不虛增）
· ./build-win.sh 全程通 → dist/Arcrun-win-v0.18.7.exe（27,445,248 bytes）
strings 抽內嵌版本 = v0.18.7
· ./build-dmg.sh 全程通 → dist/Arcrun-v0.18.7.dmg（10M）
掛載後 strings 抽 App 內嵌版本 = v0.18.7
Info.plist CFBundleShortVersionString = 0.18.7（以前永遠是 1.0.0）
⇒ **兩條打包線第一次在同一個版本號上對齊**——這正是 08-06 那個病
（只重打 Mac DMG、Windows 沒動、manifest 卻宣告新版）的根治。
· 未驗：Windows／Mac 真機行為；未出貨 ⇒ ◐
|
2026-08-06 13:16:14 +08:00 |
|