Leo
|
f32e82bab5
|
清掉三個假 Arcrun:退役 fyne 版 .app 不再進版控
leo 08-05:Launchpad 搜 arc 跑出 4 個 Arcrun,「這很奇怪」。
## 實查:只有一個是真的
/Applications/Arcrun.app v0.18.5 ← 真正安裝的
collector/cmd/arcrun-app/build/bin/Arcrun.app v0.18.5 ← 建置產物(未版控)
collector/cmd/arcrun-tray/Arcrun.app v0.0.1 ← **退役 fyne 版,被 commit 進 repo**
collector/cmd/arcrun-tray/Arcrun RAG.app v0.0.1 ← 同上,更舊的名字
Spotlight 索引磁碟上任何 .app ⇒ repo 裡的產物全冒到 Launchpad。
危險在於**點到 v0.0.1 那兩個就是 t184 的病**(在非 /Applications 執行 ⇒ 更新不了),
等於我們自己的 repo 天天在給用戶擺陷阱。
## 處置
· git rm 兩個 v0.0.1 的 .app(build 產物本來就不該版控;Wails 換代後 arcrun-tray 已退役)
· 刪掉磁碟上三個非安裝版本
· .gitignore 加 collector/cmd/**/*.app
· 兩個 build 目錄放 .metadata_never_index,讓 Spotlight 不再索引產物
驗:mdfind 'Arcrun*.app' 現在只回 /Applications/Arcrun.app 一個。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-05 18:47:57 +08:00 |
|
Leo
|
6bf0daa786
|
修首頁狀態說謊+DMG 補上拖曳版面(leo 08-05 封測回報 ①②)
## ② 首頁狀態是壞的
leo:「拖新的檔案進資料夾,完成本地萃取、上傳,但自始至終 daemon 的首頁都顯示
『有變動就自動開始』『等待中』,都顯示綠燈沒動,實際上已經做完了。」
兩個獨立的真兇:
**A. 「同步中」判斷用錯依據(回歸)**
t191 早就做好機制:collector 開工印 phase:"start"、跑完印 "done",
supervisor 據此維護 StateSyncing。**換 Wails 時 App 沒接這條線**,改看 sync-now 訊號檔:
① 訊號檔只有手動按「立刻同步」才產生 ⇒ 拖檔進資料夾(自動觸發)整輪不亮燈
② 就算手動按,collector 是**先刪檔再跑**(consumeSyncNowSignal)⇒ 真正在跑時檔早沒了
⇒ 改讀 sup.Status().State == StateSyncing。**接回既有機制,不發明第三種判斷法。**
**B. 做完的證據被下一輪抹掉**
ExtractedOK/ExtractFailed 是**本輪**計數、每輪覆寫整份 status.json
⇒ 有產出那輪寫下 N,十幾秒後空轉的一輪把它蓋成 0
⇒ 「上一輪 N 份」永遠空白、四步時間軸的綠燈只靠「跑過任何一輪」判斷=與實際進度脫鉤。
⇒ 新增 last_activity_{at,ok,failed}:有產出記本輪、空轉沿用上一輪(CarryForwardActivity)。
首頁改顯示「幾點整理了幾份」,綠燈只在真的整理過東西時才亮。
## ① Mac DMG 少了「看得出要拖」的版面
leo:「要跳出虛擬隨身碟,打開一個 finder 的視窗,**顯示 Arcrun 和 Application 的捷徑**,
用戶把 App 拖進 Application」。
原本 DMG 內容是對的(Arcrun.app+Applications 捷徑),但**沒設版面**
⇒ 預設清單視圖、位置隨機,看不出「要往右拖」。
⇒ build-dmg.sh 改走 UDRW → Finder AppleScript 設大圖示/視窗大小/左右並排 → 轉 UDZO。
best-effort:無桌面工作階段時只警告不中止(版面是加分,不該讓打包掛掉)。
⚠️ 真正讓 leo 拿到 zip 的原因不在這裡——是**線上 portal 還沒出貨**(見下)。
## 驗(實測輸出)
· collector 全測綠;新增 TestCarryForwardActivity 四子測(含「空轉不該抹掉上次成果」)
· 掛載 dist/Arcrun-v0.18.5.dmg 實查:
內容剛好兩項(Arcrun.app + Applications→/Applications 捷徑)
.DS_Store 6148 bytes(版面已存進去)
Contents/MacOS/ 有 arcrun-app **和 arcrun-collector**
CFBundleShortVersionString = 0.18.5(不是 1.0.0)/LSUIElement = true/codesign -v 通過
· 三支機械閘 check-cis/check-render/check-tray 全 PASS
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-05 18:01:17 +08:00 |
|
Leo
|
1a1478260b
|
打包產物不進版控(dist/ dist-msix/)
dmg/zip/msix 都是可重現的產物,真身走 bundles repo 出貨
(github.com/youlinhsieh/arcrun-rag-bundles)。
進版控只會讓 repo 膨脹、每次重編都變動、每次都來吵未推警察。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-08-05 17:25:45 +08:00 |
|
Leo
|
133bfdbc84
|
修 Info.plist 版本永遠是 1.0.0+skill 補「用戶視角驗收」
leo 開 DMG 檢查時抓到:CFBundleShortVersionString = **1.0.0**(Wails 預設),
不是 v0.18.4 ⇒ 使用者在 Finder/「關於」看到的版本永遠不變
⇒ 無從判斷自己是不是新版(同「版本號是唯一驗收介面」的病)。
真因:wails.json 沒有 info.productVersion,而 wails build **沒有 CLI 旗標**可指定。
修:build-mac.sh/build-win.sh 建置前把版本寫進 wails.json 的 info,
建完用 trap 還原(不污染版控)。
驗:重打後 Info.plist = 0.18.4 ✅、wails.json 無殘留 ✅
DMG 用戶視角實測(掛載後看):
剛好兩項 Arcrun.app + Applications 捷徑 ✅(拖進去的標準畫面)
MacOS/ 內含 arcrun-app + arcrun-collector ✅(沒同綑=裝了不會同步)
LSUIElement=true ✅(不佔 Dock)|codesign -v 通過 ✅
skill 補兩段:
· 3.5「把 DMG/zip 真的打開,用使用者第一次看到的樣子檢查」(含五項判準與漏掉的後果)
· 開頭「這支 skill 自己的失效模式」——leo:「你寫完一個 skill 然後每個我要提醒你,
表示這個 skill 無效」。根因是憑印象列步驟沒走過使用者的路;
訂三條鐵律(每條要有可貼的實測輸出/使用者看得到的東西一律真的打開/
被 leo 問出來的缺口當場補進 skill)。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-08-05 16:52:34 +08:00 |
|
Leo
|
d80e9e1357
|
t196:Windows 版重編(Wails)+MSIX 打包——在 Mac 上交叉編譯,不需 Windows 機器
leo 08-05:「Windows 版一定要重編,因為我只有 Mac,我需要人家測試,
要做到最完善不要給人家找麻煩,然後當測試者給我截圖安裝成功就要提交 ms store」
## 缺口
Windows 打包腳本全在**舊的 arcrun-tray(fyne 版)**,
新的 arcrun-app(Wails,t193/t194 整批 UI 重做)**完全沒有 Windows 產線**
⇒ Windows 封測者只能拿到 v0.15.7 的舊 fyne 版。
## 新增
· tray_windows.go — Windows 系統匣(energye/systray)
行為與 macOS 版逐項對齊:左鍵開視窗/右鍵只有「結束 Arcrun」/關窗不結束。
⚠️ 為什麼 Windows 能用 systray 而 macOS 不能(wiki 有全文):
macOS 上它在 Wails 之下根本不建托盤(setInternalLoop 只在 systray.Run() 呼叫),
改用 systray.Run() 又搶 macOS 主 loop ⇒ macOS 最後走原生 NSStatusItem。
**Windows 走 Win32 訊息迴圈,沒有主執行緒限制**,所以這裡用 systray 是對的,
不是抄 macOS 失敗的做法。
trayApp 與 ICO 都在本檔自帶(tray_darwin.go 有 //go:build darwin,Windows 看不到)。
· build-win.sh — 交叉編譯 zip(CGO_ENABLED=1 + mingw-w64,Wails Windows 要 WebView2 綁定)
**同綑 collector.exe**:daemon 本體是 collector direct,沒同綑=裝了不會同步
(t194 在 Mac 版就漏過一次)。supervise.go 的 collectorBinPath() 已處理 .exe 副檔名。
· build-msix.sh — MS Store 用的 msix(沿用 makemsix,Mac 上就打得出來)
與舊 fyne 版差別:**Wails 是兩個 exe**,兩個都要進 msix root。
Identity 三值走環境變數(要與 Partner Center 完全一致),預設佔位並印警告。
## 驗
· Windows zip:兩個檔都是正牌 PE(MZ 標頭)/Arcrun.exe 11.4MB+collector.exe 16.1MB
· 退避修復確實編進 Windows 版(不剝符號重編一份,grep 到 MarkFailed/ShouldRetry/
retrySkipReason 各 2 處;出貨版用 -s -w 剝符號故查不到,屬預期)
· MSIX:16 檔、含 AppxBlockMap;zip 回讀兩個 exe 的 sha256 與原檔**逐一相符**;
manifest Executable="Arcrun.exe"、Version=0.18.4.0
· **macOS 版不受影響**:編譯通過、三支機械閘全過
## 兩個踩到的坑(已修)
· zip 用相對路徑在 cd 後失效(zip I/O error,fallback 湊巧成功但不可靠)⇒ 改絕對路徑
· 全形括號緊接變數會被當成變數名(腳本自己的註解就警告過)⇒ 改 ${VAR}
## 殘項
· Identity 仍是 PLACEHOLDER ⇒ **這顆 msix 還不能送 Store**,等 leo 給 Partner Center 三值
· 未在真 Windows 上跑過(誠實界定:只證明編得出來,不證明跑起來對)
|
2026-08-05 15:50:57 +08:00 |
|
Leo
|
369eef07d4
|
修 check-render 誤報:server 沒收乾淨導致連跑會抓到舊頁面
實撞:同一份 build 連跑三次,一次綠兩次紅,白追一輪
(先誤判「深色模式壞了」→ 實際渲染截圖一看深色是好的)。
真因:trap 用 `kill %1`(job spec),在子 shell/連續執行時抓不到
⇒ 上一次的 http.server 佔住 8799 ⇒ 下一次抓到舊頁面。
修:改記 PID 收;並在啟動前先 lsof 清掉殘留在該 port 的 server。
順帶修 mock.js:t193 三修起 main.js 啟動會依 localStorage 覆寫成預設淺色
⇒ 光改 <html data-theme> 會被 JS 蓋掉,要在 module 之前寫 localStorage
(key=arcrun_app_theme)。
驗:連跑三次全過(原本會紅);三支閘 check-cis/check-render/check-tray 全過。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-08-05 15:22:48 +08:00 |
|
Leo
|
d787bfc47d
|
t195:燈號不再說謊+加診斷 log(leo:「燈號是真的還是假的?」→ 是假的)
## leo 實撞
丟 PDF 進 youlinhsieh-test1 沒反應;按「立刻同步」後畫面顯示
「正在整理知識卡」,但**卡從來沒產出**。
## 燈號為什麼是假的
舊版 describeStatus 只看「sync-now 訊號檔存不存在」就顯示「同步中…」。
那只代表**排隊了**,不代表有人處理:leo 的 collector 在 11:25 跑完最後一輪,
他 11:38 按同步 ⇒ 訊號檔沒人消化 ⇒ 畫面一直說在整理,實際 13 分鐘沒跑過。
**這比沒有燈號更糟——它在說謊。**
修:燈號要有憑有據——
· collector 沒在跑 → 明說「同步引擎沒有在跑」並告訴他怎麼辦
· 有排隊 **且** 引擎活著 → 才是「同步中」
· 其餘 → 看守中
## 順手補上診斷 log(~/.arcrun-rag/app.log)
startSupervisor 以前只 Stat(config) 就靜默 return,出問題完全查不到
(我這次也是繞了很久才確定它有啟動)。現在每個 return 點都留痕。
## 🔴 但真正擋住產卡的是另一個 401(未修,需 leo 裁)
實測鏈路:掃到 PDF ✅ → /portal/daemon/extract ✅ 200 → 寫 kbdb ❌ 401
curl -X POST https://arcrun-kbdb.youlin-hsieh-dev.workers.dev/entries(無 token)→ 401
真兇:workflows/rag-ingest-card.local.yaml 打 __KBDB_BASE__/entries
**完全沒帶 Authorization**,但 kbdb 要 Bearer KBDB_INTERNAL_TOKEN。
⚠️ 與今天修的 t189 不同:那是 extract 端點入口(現已 200),這是 workflow 內部寫 kbdb。
修法命中 D36 金鑰鐵律(「只能拿 key,送出時自動拉 value」)
⇒ 應寫 {{credential.kbdb_internal_token}} 由 resolve_credentials 回填,
而非讓安裝器 sed 把 token 值塞進定義。**已停下等 leo 裁**。
## CP 對帳
「丟檔→產卡」= ❌ 斷(卡產不出來)。本次只修好「燈號誠實」與「可診斷」,
**未送達用戶**(daemon 新版尚未出貨、401 未修)。
|
2026-08-05 11:45:07 +08:00 |
|
Leo
|
5860ef72df
|
t194 四修:托盤改用原生 NSStatusItem——energye/systray 在 Wails 之下根本不建托盤
leo:右鍵仍然沒用。這次先做**最小重現**才動手,結果推翻了我前兩次的判斷。
## 真兇(實測,非推論)
systray.go:83 的 setInternalLoop(true) **只在 systray.Run() 裡呼叫**;
RunWithExternalLoop 沒有 ⇒ registerSystray() 第一行就
`if (!internalLoop) return;` ⇒ **delegate 從沒建立**
⇒ onReady 不會被呼叫、enable_on_click 不會執行、左右鍵事件根本不存在。
最小重現(scratchpad/traytest):RunWithExternalLoop + onReady 印 "READY"
⇒ **READY 從未印出**。托盤自始至終沒被建立過。
(左鍵之所以「第一次能開」是 Wails 自己開的窗,與托盤無關。)
## 正解:原生 NSStatusItem(tray_darwin.m + tray_darwin.go)
左鍵=開視窗;右鍵=暫時掛選單、performClick、再拿掉(不常駐 setMenu:,
否則按鈕 action 不會被呼叫、左鍵也會變成彈選單——與 systray 那個坑同源)。
## 過程中踩到、也寫進閘的三個坑
① dispatch_async(main_queue) **無效**:Wails 佔住主執行緒後不跑標準 run loop,
排進去的 block 永遠不執行(log 只印到 "dispatching…")⇒ 改 performSelectorOnMainThread
② NSStatusBar 需要 NSApp 已初始化:在 wails.Run() 之前呼叫 ⇒ 靜默失敗、icon 不出現
③ 🔴 **我一度對著 `go build` 產的 stub 除錯**——沒帶 Wails build tags 的執行檔
一跑就印 "Wails applications will not build without the correct build tags" 並退出,
我卻以為是「托盤沒建起來」,白繞一圈。**驗 Wails App 一定要用 wails build 的產物。**
## 實測證據(AppleScript 從 UI 層查,最貼近使用者看到的)
menu bar 數=2,status item 數=1 ← 選單列 icon 真的存在
collector 同步啟動、正常結束無孤兒
三支機械閘全過(閘也改成驗原生實作:不可 dispatch_async/必須
performSelectorOnMainThread/不可常駐 setMenu/不可再依賴 energye/systray)。
⚠️ 仍未驗:左右鍵的**實際點擊行為**要 leo 手動點。
|
2026-08-05 02:56:41 +08:00 |
|
Leo
|
a02eed539a
|
t194 三修:右鍵選單——正解是「**少寫**一段」,不是再補一段
leo 實測:右鍵仍然沒有 quit 選單。
## 真兇:我把函式庫本來就會做對的事,換成一個更脆弱的版本
讀 systray_darwin.go 的 systray_on_rclick():
func systray_on_rclick() {
if onRClick != nil { onRClick(st) } else { C.show_menu() }
}
⇒ **沒註冊 SetOnRClick 時,函式庫自己就會把選單叫出來**;
而且 C 層的 show_menu 內部已經處理好整套:
create_menu() → [statusItem.button performClick:nil] → set_menu_nil()
我卻註冊了自己的 handler、還加 `if menu != nil` 防呆
⇒ 等於用一個判斷把「本來會動的預設行為」擋掉。
修:**刪掉 SetOnRClick 註冊**。左鍵仍自訂(要開視窗),右鍵交還函式庫。
## 判準(已寫進 mistakes)
用第三方函式庫時,**先讀它的預設行為再決定要不要覆寫**。
「多註冊一個 handler」看起來是加功能,實際上常是**關掉**原本正確的行為。
## 閘也跟著改
check-tray.sh 原本驗「SetOnRClick 有註冊且順序對」——**那是在守一個錯的寫法**。
改成反向:**出現 systray.SetOnRClick 就擋下**,並說明原因。
實跑 7 項全過;App 活著 pid 14081、crash 0。
|
2026-08-05 02:27:23 +08:00 |
|
Leo
|
c400292c01
|
新增 check-tray.sh:托盤行為的機械閘(交付警察攔下後補)
leo 真機測出的四個 bug **編得過也跑得起來**,只有真的去點才會發現;
我改完只驗「build ok」就想交 ⇒ 把「點不下去的部分」用可機械檢查的前置條件守住:
① template icon:22/44 RGBA、**不透明 <50%**(否則會顯示成方塊)、顏色種類
② 呼叫順序:AddMenuItem → SetMenuNil → SetOnClick/SetOnRClick
(順序錯=滑鼠事件全失效,正是 leo 撞到的②③)
③ ShowWindow 必須有 Unminimise/Show/SetAlwaysOnTop 三者(缺一就叫不回被蓋住的窗)
④ 結束路徑:有 signal.Notify+waitCollectorGone(否則只能強制結束、留孤兒)
實跑 7 項全過。這支+check-cis+check-render 三支都要過才准交。
|
2026-08-05 01:47:58 +08:00 |
|
Leo
|
fcdb1df71d
|
t194 二修:托盤 icon/右鍵選單/重複點擊/正常結束(leo 實測四點)
leo 真機測出四個問題,每個都查到真兇後才動手:
## ① 托盤 icon 變方塊
真兇:我塞 1024x1024 的**彩色 app icon** 當 template icon。
macOS 選單列規格是 **16-22pt、純黑+alpha**(由系統依深淺色自動上色)
⇒ 彩色大圖被縮成一坨方塊是必然。
修:用 CIS 的 chevron-double.svg 渲成 44x44 純黑 template icon。
## ②③ 右鍵沒選單/第一次能開之後就不再跳
真兇(energye/systray 原始碼註解白紙黑字寫著):
「該方法主動調用後 如果托盤菜單已創建則添加進去, **之後鼠標事件失效**」
⇒ 只要用 AddMenuItem 建了選單,SetOnClick/SetOnRClick **全部失效**。
修:SetMenuNil() 移除選單讓滑鼠事件生效,右鍵時自己 ShowMenu()。
另外 ShowWindow 只呼叫 WindowShow 對「已開但被蓋住」無效
⇒ 補 Unminimise + AlwaysOnTop 閃一下搶焦點。
## ④ 只能用強制結束
真兇:Wails 的 loop 不理 SIGTERM,且 collector 是我們自己 Start 的子行程
⇒ 主程式被殺後**子行程變孤兒繼續跑**。
實測(機械驗證,非目視):
修前 kill -TERM → App 沒退、collector 孤兒還在
修後 kill -TERM → App 正常退出 ✅、collector 一起收掉 ✅、殘留 0
修:installSignalHandler 收 TERM/INT → stopSupervisor() →
waitCollectorGone(3s) 確認子行程真的不見(逾時補一刀)→ 才 os.Exit。
「關了卻還在同步」比沒關更糟。
實跑驗證:App 活著 pid 88466、自己拉起 collector、crash 0、兩支機械閘全過。
|
2026-08-05 01:41:31 +08:00 |
|
Leo
|
643acc0f74
|
t194 修:托盤必須在主執行緒建立——交付警察攔下,實跑才發現會 crash
交付警察問「leo 現在去測會不會發現你沒發現的東西」⇒ 我去真的跑一次,
**發現這版根本起不來**。我原本只驗了「打包產物有沒有那些檔案」,沒驗它會不會活著。
## 兩個 crash,都要真機跑才看得到
① `systray.Run()` 自己開 loop ⇒ 與 Wails 搶 macOS 主 loop
⇒ SIGTRAP `signal arrived during cgo execution`
② 改用 RunWithExternalLoop 但在 OnStartup/goroutine 裡呼叫 start
⇒ SIGABRT `NSWindow should only be instantiated on the main thread!`
(NSStatusItem 內部會 new NSWindow,AppKit 規定只能在主執行緒)
⚠️ 我一度想「加個 sleep 丟 goroutine」——那只是拖延,goroutine 永遠不是主執行緒。
## 正解
main() 一開始(還在主執行緒)就 RunWithExternalLoop 註冊並 trayStart(),
它**不阻塞**,接著把主執行緒交給 wails.Run();defer trayEnd() 收尾。
## 實測(跑真的 .app,非只看檔案)
App 活著 pid 59162 ✅
它拉起自己的 collector ✅(arcrun-app/.../arcrun-collector,與舊 fyne 版並存不衝突)
crash 訊號 0 ✅/log 僅 1 行 ✅
兩支機械閘仍全過。
⚠️ 未驗:托盤左右鍵的**點擊行為**要人真的去點(我點不了)。
|
2026-08-05 00:46:52 +08:00 |
|
Leo
|
549834f343
|
t194:托盤收成 Google Drive 式(點 icon 開視窗/右鍵只有結束)+同綑 collector
leo 2026-08-05:「依照 google drive,托盤裡只剩下按右鍵會結束,
其他設定都在這個頁面,點擊托盤的 icon 就立刻展開界面」
## 托盤
Wails v2 沒有內建托盤 ⇒ 用 energye/systray(Wails 相容分支,支援左鍵事件)。
- 左鍵:直接展開主視窗,**不彈選單**
- 右鍵:只有一項「結束 Arcrun」
- 設定全部留在視窗裡,托盤不再是第二套 UI
(fyne 版把設定塞下拉選單,leo 早說過「不可能統統塞在下拉選單」)
- 關窗=隱藏不結束(daemon 常駐;按 × 就停止同步不符預期)
- Dock 不出現 icon:Wails v2.13 的 mac.ActivationPolicy 還沒開放(原始碼是註解掉的)
⇒ 改走 Info.plist 的 LSUIElement,與 fyne 版同一個做法
## 🔴 順手抓到自己的大漏:這個 App 根本沒有啟動 collector
daemon 的**本體**是 `collector direct`(監看/萃卡/上傳),Wails 版我一路沒接
⇒ 照這樣出貨會是「裝了也不會同步」的空殼。
修:新增 supervise.go,**複用既有 supervisor 套件**(重起退避/狀態機/
t191 的 phase:start/done ⇒「同步中…」),不複製一份(複製=會漂移)。
go.mod 用 replace 指回 collector 主模組。
加/刪資料夾、改 AI 設定後都會 restartWatch(),設定立刻生效。
## 打包
新增 build-mac.sh:編 collector → wails build → **同綑進 .app** → ad-hoc 重簽。
沒同綑就等於沒有 daemon。
實測(v0.18.0):collector 同綑 15M ✅/LSUIElement=true ✅/版本注入 ✅/已簽 ✅
兩支機械閘全過。
⚠️ 未驗:托盤左右鍵的實際行為要真機點(我開不了視窗)。
|
2026-08-05 00:31:52 +08:00 |
|
Leo
|
5a48abb784
|
t193 四修:裁淨版 lockup+側邊欄選中態照 portal(leo 兩點)
## ① logo 比例不對+深色仍有白底+旁邊大量空白
三個症狀同一個根:**我用的是未裁淨的原始 PNG**。
portal 的註解早就寫著:原始 1840x560 **只有 32% 高度是實際字形**,上下大留白
⇒ 同 height 字看起來很小;留白處露出 paper-on-ink 自帶的 Ink 底板=白底。
portal 用的是裁淨版(986x176),但**只內嵌在它的 HTML base64 裡**,我抄不到才用了原始圖。
修:
- 從 portal 的 base64 抽出兩張裁淨版,存成 arcrun-cis/trimmed/ 供全站共用
- 兩張**都是透明底**(實測四邊留白 0)⇒ 深色模式**拿掉 Ink 底板**
- 空白是**版面**造成:側欄 232px 扣 padding 剩 184px,logo 高 24px 只有 134px ⇒ 空 50px
⇒ 側欄對齊 portal 的 216px,logo 改 width:100% 填滿可用寬度
實測(渲染後量像素):
logo 26px 高 × 151px 寬,右側剩餘空白 1px(原本 50px)
深色:側欄底(18,18,18) vs logo 上下皆(18,18,18) ⇒ 落差 0,無白底
## ② 側邊欄選中態太粗糙
leo:「參考現在 Portal 的格式⋯⋯這個比現在膠囊反紅精緻,重點是跟 portal 的形象符合」
修:逐字照 portal 的 #sidenav .nav.on ——
**不是實心膠囊**,而是 amber 字色 + 8% amber 底 + 右側 2px amber 邊。
側欄右緣也照 portal 用 2px amber 35%。
實測:選中列底(237,228,222)=amber 8%、右緣(176,74,47)=Relation、未選(242,241,237)=Canvas。
## 機械閘加三項守衛
- 不准用未裁淨的原始 lockup(字會太小)
- 選中態必須有 border-right-color: var(--amber)
- 不准再出現 border-radius:999px(膠囊,leo 已否決)
兩支閘全過;style.css 仍 0 個 hex。
|
2026-08-05 00:02:46 +08:00 |
|
Leo
|
751ee74f19
|
t193 三修:每庫一頁+狀態時間軸+預設淺色(leo 六點回饋)
## ① logo 尺寸不對導致白邊
真兇:我寫死 height:22px **沒給 width:auto** ⇒ 容器一壓就變形、露出底板邊緣。
修:照 portal 側欄同一條 clamp(22px,5vw,28px) + width:auto + max-width:100%,
並依 CIS「clear space = one chevron height」在四邊留白。
實測:logo 底板與品牌區落差 **0**(原本是明顯方塊)。
## ② 深色跟網頁不同/「它有淺色佈景?」
是——**portal 預設淺色**,深色由使用者切換並存 localStorage。
我卻硬跟系統走 ⇒ 兩邊當然不同。
修:改成與 portal 同一套(預設淺色+切換鈕+localStorage),
按鈕規格也逐字對齊 portal 的 .btn/.btn3(padding/font-size/radius/border)。
實測淺色:品牌區(253,252,251)=Paper、側欄(242,241,237)=Canvas,與 CIS 一致。
## ③ 「開啟知識庫網頁」開到錯的庫
真兇:它在首頁、寫死取 accounts[0] ⇒ 有兩個庫必然開錯。
修:移到**各庫頁的上方**,開的就是那個庫。
## ④⑤ 30 個資料夾放不下/「加入資料夾」會加到哪個帳號?
修:**每個知識庫一個獨立分頁**(側邊欄動態列出,附資料夾數)。
「加入資料夾」在庫頁裡,**作用對象就是那個庫**,不會加錯。
## ⑥ 首頁要顯示 status(看守/發現變化/萃取/上傳)
修:首頁改成**狀態時間軸**四步,進行中那步的圓點會呼吸。
誠實邊界:collector 目前回報「整輪」而非逐檔階段,
所以同步中時後三步一起標進行中,**不假裝有更細的進度**。
兩支機械閘全過(check-cis.sh 14 項/check-render.sh 深淺色皆驗)。
style.css 仍是 0 個 hex(顏色全走 var)。
|
2026-08-04 23:35:49 +08:00 |
|
Leo
|
3d13e5a54e
|
t193 二修:側邊欄版面+共用 CSS+App 內更新+兩支視覺機械閘
leo 08-04 看過 v0.17.0 後的四點,逐條回應:
## ① 「不會這裡又寫了一個新的 CSS?」——是,我又寫了一份
真兇:portal 的樣式內嵌在 HTML 裡,沒有獨立檔 ⇒ 四個站各抄一份、本來就在漂移。
解:抽出 InkStoneCo/arcrun-cis/css/arcrun-cis.css 當唯一真相源。
daemon 的 style.css 現在**一個 hex 都沒有**,顏色全走 var(--...)。
## ② 「完全模仿 gdrive,左方側邊欄,在右方替換頁面」
底部 nav bar 拿掉(leo:「幾乎沒看過這種 nav bar 在下方的」)。
改成左側邊欄四頁:首頁/同步資料夾/AI 設定/版本與更新,右側換頁。
設定不再開 popup;只有「確認移除資料夾」才用覆蓋層。
## ③ 「既然是 Web,你做的時候無法檢視?」——可以,我之前沒做
新增 check-render.sh:headless Chrome 真的渲染一次並**量像素**。
它抓到一個肉眼容易誤判的真 bug:
arcrun-lockup-h-paper-on-ink.png **自帶不透明 Ink 底板**(實測左上像素 RGBA=23,24,26,255),
設計前提是貼在純 Ink 表面;我們背景有紙張紋理 ⇒ 出現突兀方塊。
修:深色模式把品牌區做成純 Ink。實測落差 4(原本會是一個明顯方塊)。
過程中也發現自己對著**舊的 dist**除錯,浪費一輪——這支閘同時防這個。
## ④ 「檢查更新連到 docs,不正確,是直接在這裡進行」
新增「版本與更新」頁:顯示**現在版本 vs 最新版本**,
三段式全在 App 內完成——檢查/下載並安裝/重新啟動套用。
selfupdate 邏輯逐字沿用 arcrun-tray(含 t186 走 raw、t184 蓋正在跑的 .app),不重寫。
## 交貨閘(leo:「你做為檢查有嗎?沒有怎麼交貨?」)
check-cis.sh 擴充:版面檔不准出現任何 hex + 共用底層色票逐項比對。
兩支閘實跑全過。
|
2026-08-04 23:09:54 +08:00 |
|
Leo
|
bd0cead00e
|
t193:daemon UI 換 Wails——CIS 是硬要求,fyne 做不到
leo 2026-08-04 看過 v0.16.0 畫面後:
「功能都有了,但美感非常糟糕⋯⋯跟 CIS 完全無關,每個功能都開一個小小的 popup 視窗,
非常缺乏整體感,這要理解的是原始的技術選擇是否出錯?」
「我的要求是符合 CIS,在風格上跟 portal 一樣」
「CIS 已經提供規範,你做的連 Logo 都沒放上去,這跟美不美有關係嗎?
要求放進 CIS 是硬要求,你做為檢查有嗎?沒有怎麼交貨?」
## 我的兩個錯
1. **動工前沒提醒做不到**——decisions-summary.md:314 的 D-daemon-UI
是我 07-27 自己寫的調研(結論:fyne 全自繪、CSS 套不進去),寫完就沒再看。
今天動工前該查它卻直接開寫,浪費 leo 的時間與 token。
2. **沒做 CIS 檢查就交貨**——連 logo 都沒放。
## 換 Wails(WebView 殼)
前端就是 HTML/CSS ⇒ 可以直接用 portal 那份色票與 lockup。
- style.css 的色票/字體/紙張紋理**逐字取自** portal 的 :root
(matrix/arcrun:console-ui/public/portal/index.html),不自創任何顏色
- CIS lockup 官方 PNG,淺色 ink 版/深色 paper 版,切換規則同 portal
(避開 08-01 作廢的自產 SVG——字腔缺失)
- 對話框改**內嵌覆蓋層**,不再每個功能開一個小 popup
- 原生資料夾選擇器(macOS powerbox 會自動授予該資料夾存取權,
fyne 自繪 picker 拿不到;未來上 Mac App Store 是硬需求)
- 同步中的圓點會呼吸 ⇒ 看得出來在動(issue #17)
- 無帳號時是 onboarding 引導,不是空白面板
## 連線邏輯逐字沿用,不重寫
connect.go 的 normalizePortalURL/fetchConfigByLogin 取自 arcrun-tray/main.go,
含 t86 個資外洩事故的防線(不同實例=新增帳號,絕不覆蓋舊帳號的資料夾)。
今天已犯過一次「重寫別人修好的東西還修得更差」,不再犯第二次。
## 新增 check-cis.sh(交貨前必跑)
機械檢查六類:官方色票逐個到齊/**不准出現非 CIS 色**/logo 真的放進去/
不可用作廢 SVG/深色模式/字體與紙張紋理同 portal/app icon。
實跑 14 項全過。以後「沒跑過就不准交」。
⚠️ 未驗:實際畫面要 leo 開來看(我開不了視窗)。
|
2026-08-04 22:19:41 +08:00 |
|