WHY / 症狀
目前的 impl workflow 是:
code → test (pytest) → lint (ruff) → typecheck (mypy) → build (npm) → PR
缺少 build .app → 實際執行 → 檢查 runtime log 有無異常 的步驟。
這導致 frozen-build-only 的 bug 在 PR 階段無法被發現——例如 #174(check_update() 在 .app 中因 importlib.metadata.version() 找不到 package metadata 而失效),在 uv run 開發模式下完全正常,只在 PyInstaller 打包的 .app 中浮現。
需求
討論並決定:impl 在送 PR 前是否應該:
- Build
.app:./deploy.sh build
- 啟動
.app:open dist/simple-edge-tts.app
- 檢查 log:讀取
~/Library/Logs/simple-edge-tts/ 中最新的 log 檔,確認無 ERROR / exception / failed 等異常
- 關閉 app 後才送 PR
待討論
- 誰該做?Impl 送 PR 前?Reviewer 審查時?Lead post-merge?
- 建議:Impl 送 PR 前必做(跟跑 test/lint 一樣,是 pre-PR gate)
- Reviewer:若 diff 觸及
src/**(Python backend / frozen 路徑相關),也該 build 驗證
- Lead:post-merge 已跑
deploy.sh build(LEAD.md §11.1),但那是最後一道防線,不該是第一道
- 頻率:每次 PR 都做?還是只有涉及
src/** / frozen 路徑的 PR?
- 建議:涉及
src/** 的 PR 必做;純 frontend / docs / config 可跳過
- 自動化:能否在 CI 中跑?還是只能手動?
- macOS
.app 在 CI 可跑(open + sleep + log check),但需要 macOS runner
- 短期手動、長期 CI 化
Related
🤖 opened by: lead (set-team-lead)
WHY / 症狀
目前的 impl workflow 是:
缺少 build
.app→ 實際執行 → 檢查 runtime log 有無異常 的步驟。這導致 frozen-build-only 的 bug 在 PR 階段無法被發現——例如 #174(
check_update()在.app中因importlib.metadata.version()找不到 package metadata 而失效),在uv run開發模式下完全正常,只在 PyInstaller 打包的.app中浮現。需求
討論並決定:impl 在送 PR 前是否應該:
.app:./deploy.sh build.app:open dist/simple-edge-tts.app~/Library/Logs/simple-edge-tts/中最新的 log 檔,確認無ERROR/exception/failed等異常待討論
src/**(Python backend / frozen 路徑相關),也該 build 驗證deploy.sh build(LEAD.md §11.1),但那是最後一道防線,不該是第一道src/**/frozen路徑的 PR?src/**的 PR 必做;純 frontend / docs / config 可跳過.app在 CI 可跑(open+sleep+logcheck),但需要 macOS runnerRelated
🤖 opened by: lead (set-team-lead)