以 status 子指令回報安裝與環境現況 #29
Notifications
Due Date
No due date set.
Blocks
Depends on
#30 改寫 README 與 AGENTS.md 對齊 npm 佈署
plugins/tea-sdlc
#26 以 npm 安裝並建立 tea-sdlc 指令入口
plugins/tea-sdlc
Reference: plugins/tea-sdlc#29
Reference in New Issue
Block a user
母議題
#25 — 以 npm 佈署並提供 tea-sdlc 指令
要做出什麼
使用者要能在出事前問一句「我現在到底是什麼狀態」。
tea-sdlc status用一行 JSON 回答四件事:裝的是哪個版本、正本實際解析到哪個目錄(順帶揭露是不是npm link開發模式)、node/git/tea在不在 PATH、Gitea 登入還有沒有效。登入那層要查,即使它會打網路:
status存在的理由就是在出事前先知道,而 token 失效是實務上最常見的故障;一次使用者主動發起的查詢很便宜,為它多開一個旗標是把判斷推回給使用者。ok與健康狀態必須分離。ok在既有契約裡的意思是「這支指令跑成功了」,不兼差表達環境好壞:環境不健康時ok仍為true,健康旗標是data.healthy。混用會讓呼叫端分不出「status 掛了」和「status 成功查到你環境有問題」,而這兩件事的下一步完全不同。各平台轉接檔現況(
platforms)不在這張票:平台目錄結構的知識依模組邊界專屬於 #17 的安裝器,這裡不複製一份。驗收標準
tea-sdlc status輸出單行 JSON,data含 version、root、linked、healthy、environmentenvironment含 node、git、tea、login 四項root為入口實際解析到的套件目錄;npm link情境下指向 working tree 且linked為truegit或tea時對應欄位為 false,且healthy為 falseok仍為true、healthy為falseplatforms阻擋於
已於 #36(merge commit
dcbd71c)交付,八條驗收標準勾了七條。未勾選:「不回報
platforms」。 這條與 #17 的「補上tea-sdlc status的platforms欄位」直接衝突。兩張票在同一輪一起交付,因此以 #17 為準,status有回報platforms。本票原本的理由(平台目錄結構的知識專屬於 #17 的安裝器,這裡不複製一份)仍然成立且有被遵守:
platforms的內容由scripts/install.js匯出的platformReport()產生,scripts/status.js不知道任何平台目錄結構。