internal/cli/version_test.go：新增 fallback 與 version 輸出一致性測試。
驗證： gofmt 無差異、go vet 與 go test ./... 全綠；乾淨環境（隔離 GOPATH/GOMODCACHE/GOCACHE）實測 go install …@v0.1.0 建置成功且 go version -m 確認 module 版本 v0.1.0；clone 本分支後 go build 顯示 v0.1.1-0.20260912160956-5a48fdd590b2（工作樹有修改時 +dirty）。
先說通過的部分：gofmt 無差異、go vet 與 go test ./... 全綠（我在乾淨 clone 的 PR 分支上重跑確認）；@latest 解析到 v0.1.0、建置成功；公開倉庫預設 GOPROXY/GOSUMDB 可解析、免 GOPRIVATE——這些與說明一致。buildVersion 讀 build info 的做法本身也合理，新測試在 go test 環境（Main.Version 為 (devel)）運作正常。
但有兩處「顯示版本」的宣稱與實測不符：
「go install …@v0.1.0 建置的二元檔顯示 v0.1.0」不成立。tag v0.1.0 打在 36a50b9（#39 合併點），早於本 PR 的 5a48fdd，因此 @v0.1.0 建置出的二元檔不含 buildVersion 變更。我在隔離 GOPATH/GOMODCACHE/GOCACHE 的乾淨環境實測：
go install gitea.alterminal.com/alterminal/teai/cmd/teai@v0.1.0 → teai version 輸出「teai version 0.1.0-dev」（go version -m 確認 module 版本為 v0.1.0，即確實裝到 tag，但顯示的是舊行為）。
「tag 安裝顯示 tag 版本」要等本 PR 合併後發佈的下一個 tag（如 v0.1.1）才成立。請修 README 安裝章節的驗證行（目前寫「teai version # 驗證：teai version v0.1.0」）與 PR 說明：例如以 @latest 為例、並註明 v0.1.0 早於本變更仍顯示 0.1.0-dev，自下一個 tag 起才顯示安裝版本。
「clone 建置退回 0.1.0-dev」在現行工具鏈不成立。git clone 本 PR 分支後直接 go build（實測 go1.26.5、預設 GOFLAGS），Main.Version 會帶 pseudo-version 而非 (devel)：本分支 HEAD 實測輸出「teai version v0.1.1-0.20260912160956-5a48fdd590b2」，工作樹有修改時為「…+dirty」。(devel) → 退回 Version 只在無 VCS 資訊（例如從 tarball 解壓）或 go test 環境成立（實測 go test 下 Main.Version 為 (devel)，這也是新測試能通過的原因；PR 說明「本機 build 顯示 v0.1.0+dirty」應是站在 tag commit 上建置的結果，推送到分支的實際行為並非如此）。請擇一處理：(a) README「從原始碼建置」的驗證行改為如實描述（clone 建置顯示 pseudo-version，如 v0.1.1-0.<時間>-，無 VCS 資訊時才顯示 0.1.0-dev）；或 (b) 調整 buildVersion 對 pseudo-version 的處理（例如視為開發版退回 Version），並在註解說明預期行為。
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
alex
延續 #38（tag 已發佈，見 issue 留言）：
變更：
internal/cli：version輸出改用debug.ReadBuildInfo()——go install …@<tag>（含本變更的 tag，如 v0.1.1 起）建置的二元檔顯示該 tag；clone 建置顯示 pseudo-version（如v0.1.1-0.<時間戳>-<commit>，工作樹有修改時附+dirty）；Main.Version為(devel)／空（go test、無 VCS 資訊的 tarball 建置）時退回0.1.0-dev。註：v0.1.0 本身早於本變更，@v0.1.0安裝仍顯示0.1.0-dev。README.md：安裝章節改以go install @latest（可@v<版本>）為主，clone 建置降為開發用輔助；如實說明各建置方式的版本顯示（tag／pseudo-version／+dirty／(devel)退回 dev），並註明@v0.1.0因早於本變更仍顯示0.1.0-dev；說明公開倉庫免 GOPRIVATE、無法經公用 proxy 時的 GOPRIVATE 設定。internal/cli/version_test.go：新增 fallback 與 version 輸出一致性測試。驗證： gofmt 無差異、
go vet與go test ./...全綠；乾淨環境（隔離 GOPATH/GOMODCACHE/GOCACHE）實測go install …@v0.1.0建置成功且go version -m確認 module 版本 v0.1.0；clone 本分支後go build顯示v0.1.1-0.20260912160956-5a48fdd590b2（工作樹有修改時+dirty）。複審修正（9a4887a）： 依審核意見修正 README 安裝章節與 PR 說明中兩處與實測不符的宣稱——(1)
@v0.1.0建置的二元檔不含 buildVersion 變更、仍顯示0.1.0-dev，已改以@latest為例並註明自包含本變更的 tag（v0.1.1 起）才顯示安裝版本；(2) 現行工具鏈 clone 建置顯示 pseudo-version 而非0.1.0-dev，已採方案 (a) 如實描述（pseudo-version、+dirty、無 VCS 資訊才退回0.1.0-dev），並同步修正buildVersion與測試檔註解。審核結果：本次不合併，請修正後再留言，我再複審。
先說通過的部分：gofmt 無差異、go vet 與 go test ./... 全綠（我在乾淨 clone 的 PR 分支上重跑確認）；@latest 解析到 v0.1.0、建置成功；公開倉庫預設 GOPROXY/GOSUMDB 可解析、免 GOPRIVATE——這些與說明一致。buildVersion 讀 build info 的做法本身也合理，新測試在 go test 環境（Main.Version 為 (devel)）運作正常。
但有兩處「顯示版本」的宣稱與實測不符：
「go install …@v0.1.0 建置的二元檔顯示 v0.1.0」不成立。tag v0.1.0 打在 36a50b9（#39 合併點），早於本 PR 的 5a48fdd，因此 @v0.1.0 建置出的二元檔不含 buildVersion 變更。我在隔離 GOPATH/GOMODCACHE/GOCACHE 的乾淨環境實測：
go install gitea.alterminal.com/alterminal/teai/cmd/teai@v0.1.0 → teai version 輸出「teai version 0.1.0-dev」（go version -m 確認 module 版本為 v0.1.0，即確實裝到 tag，但顯示的是舊行為）。
「tag 安裝顯示 tag 版本」要等本 PR 合併後發佈的下一個 tag（如 v0.1.1）才成立。請修 README 安裝章節的驗證行（目前寫「teai version # 驗證：teai version v0.1.0」）與 PR 說明：例如以 @latest 為例、並註明 v0.1.0 早於本變更仍顯示 0.1.0-dev，自下一個 tag 起才顯示安裝版本。
「clone 建置退回 0.1.0-dev」在現行工具鏈不成立。git clone 本 PR 分支後直接 go build（實測 go1.26.5、預設 GOFLAGS），Main.Version 會帶 pseudo-version 而非 (devel)：本分支 HEAD 實測輸出「teai version v0.1.1-0.20260912160956-5a48fdd590b2」，工作樹有修改時為「…+dirty」。(devel) → 退回 Version 只在無 VCS 資訊（例如從 tarball 解壓）或 go test 環境成立（實測 go test 下 Main.Version 為 (devel)，這也是新測試能通過的原因；PR 說明「本機 build 顯示 v0.1.0+dirty」應是站在 tag commit 上建置的結果，推送到分支的實際行為並非如此）。請擇一處理：(a) README「從原始碼建置」的驗證行改為如實描述（clone 建置顯示 pseudo-version，如 v0.1.1-0.<時間>-，無 VCS 資訊時才顯示 0.1.0-dev）；或 (b) 調整 buildVersion 對 pseudo-version 的處理（例如視為開發版退回 Version），並在註解說明預期行為。
兩處都屬文件與說明與實際行為不符——本 PR 一半是 docs，驗證步驟照著走會看到不同輸出，故先不合併。issue #38 的實質驗收（乾淨環境 @v0.1.0 可建置並可執行 teai version、README 以 tag 安裝為主）已達成，tag 亦已發佈，剩下的只是把這幾段文字改準確。修正後請在本 PR 留言，我再複審合併。
@alex 感謝審核，兩處都已在
9a4887a修正（方案 (a)，如實描述），分支已更新：@v0.1.0顯示宣稱：README 安裝範例改以@latest為例（驗證行註明「顯示安裝的 tag 版本（見下方說明）」），並明確註記：讀 build info 顯示安裝版本的支援自包含本變更的 tag（v0.1.1 起）才生效，v0.1.0 早於此變更，@v0.1.0（或此變更前的@latest）仍顯示0.1.0-dev。PR 說明同步改寫。v0.1.1-0.<時間戳>-<commit>，並補一段說明 clone 建置的版本顯示規則：位於 tag 顯示該 tag、其後 commit 顯示 pseudo-version、工作樹有修改附加+dirty、無 VCS 資訊（tarball）時Main.Version為(devel)才退回0.1.0-dev。buildVersion與version_test.go的註解也同步修正。本機複驗（go1.26.5）：乾淨隔離環境
go install …@v0.1.0→teai version 0.1.0-dev（go version -m確認 module 版本 v0.1.0，與您的實測一致）；clone 本分支go build→v0.1.1-0.20260912160956-5a48fdd590b2，工作樹有修改時+dirty；修正 commit 建置顯示v0.1.1-0.20260912162840-9a4887a677c7。gofmt 無差異、go vet、go test ./...全綠。PR 說明中原「本機 build 顯示 v0.1.0+dirty」確如您推測，是站在 tag commit 上建置的結果，已一併更正。再麻煩複審。
複審通過：兩處宣稱已如實修正並實測吻合——(1) README 以 @latest 為例並註明 v0.1.1 起才顯示安裝版本，我在隔離 GOPATH/GOMODCACHE/GOCACHE 實測 @v0.1.0 與 @latest 均顯示 0.1.0-dev、go version -m 確認 module v0.1.0；(2) clone 建置實測 v0.1.1-0.20260912162840-9a4887a677c7、工作樹修改後 +dirty，與 README 說明一致。gofmt 無差異、go vet 與 go test ./... 全綠。buildVersion 僅用標準庫 runtime/debug，fallback 邏輯有測試涵蓋。驗證通過。