前言¶
在 DSH 裏讓智能體寫測試和實現代碼時，常見做法是口頭約定「先寫失敗測試再寫實現」。模型仍可能跳過 RED、改測試湊綠，或在沒有真實測試命令的情況下宣稱通過。DeepSeek Harness 採用插件化擴展；社區目錄 skillhub.cn 上的工作流類插件，可以把階段約束落到 ToolRuntime 工具與本地子進程證據上。
下面介紹維護者 LIghtJUNction 發佈的 @lightjunction/dsh-red-green（倉庫 LIghtJUNction/dsh-red-green）。它在用戶明確請求 TDD 之後，才啓動 RED → GREEN → REFACTOR → COMPLETE 循環，用固定測試命令的輸出與文件內容指紋綁定證據，而不是默認接管每個會話。
這是什麼¶
一句話定位：面向 DSH 0.2.1-rc.2、Node 24+ 的可選 TDD 工作流插件（簡介：Evidence-driven RED GREEN REFACTOR workflow for DSH）。
加載插件後，每個會話默認處於 idle；只有用戶在對話中明確要求使用 TDD 時，調用方纔應帶 userRequested: true 啓動週期。Real ToolRuntime 工具會執行你聲明的測試命令，並把結果與跟蹤文件內容關聯。
核心功能¶
顯式 opt-in¶
插件不會在加載後自動進入 TDD，也不提供默認 TDD 提示或強制 TDD。週期由 tdd_start 開啓，由 tdd_reset 結束並移除守衛；tdd_reset 不會回滾磁盤上的文件。
四階段與 revision¶
典型推進方式：
- 先創建測試文件（以及你聲明的源碼路徑）。
- 用戶說「use TDD」或等價明確請求後，調用
tdd_status、tdd_start。 - 每次改代碼後調用
tdd_run，使用上一次結果返回的revision作爲下一次變異的參數。 - 識別到失敗的斷言後，從 RED 進入 GREEN，並鎖定測試內容；實現通過後進入 REFACTOR，再運行直至 COMPLETE。
tdd_status 會報告自上次證據以來，跟蹤文件是否相對快照發生變化。調用會拒絕過期的 revision 與重疊的變異。
RED 階段的工具守衛¶
在 RED 階段，插件會限制名稱中包含 write、edit、patch、bash、shell、exec 或 terminal 的工具。僅允許對聲明列表裏、且路徑完全匹配的測試文件做編輯；實現代碼與 shell 類工具在觀察到失敗測試之前會被拒絕。RED 之外，工作流約束多爲建議性質；自定義工具別名、直接寫主機文件或其他插件的編輯不在守衛邊界內。
證據與指紋¶
測試、源碼以及 root 內的 symlink 目標會被指紋化；遍歷或指向 root 外的 symlink 會被拒絕。測試命令運行期間若跟蹤文件被改動，結果會被丟棄。RED 之後若再改測試內容，需要 tdd_reset 後重新開始。非零退出碼加上可識別的失敗文本（如 not ok、AssertionError、FAIL/FAILED 或失敗計數）用於啓發式判斷 RED；語法或模塊錯誤不會推進 RED。GREEN/REFACTOR 依賴退出碼爲零，應配置真實測試 runner，不要用空操作命令。標準輸出/錯誤僅保留最後 64 KiB。
作用域與生命週期¶
每個週期綁定到 agent 與 canonical workspace；無 agent 的調用有獨立狀態。Abort、超時、卸載會終止並回收 Unix 進程組；agent 銷燬會移除其週期。狀態在內存中，卸載即消失；無磁盤歷史、覆蓋率、Pi TUI、斜槓命令或手動繞過證據。
安裝與啓用¶
要求：DSH 0.2.1-rc.2、Node >= 24。安裝包內含 dsh.bundle patch；若 profile 未啓用 HMR，安裝後需重啓 DSH。
README 給出的安裝模式（說明爲 pattern，不表示該 release 一定已發佈）：
dsh plugin --profile headless add https://github.com/LIghtJUNction/dsh-red-green/releases/download/v0.1.0/lightjunction-dsh-red-green-0.1.0.tgz
可選 profile 配置（cordis.patch.yml 中示例）：
- id: dsh-red-green
name: '@lightjunction/dsh-red-green'
config:
root: /absolute/host/project
timeoutMs: 120000
root 默認爲調用 agent 的工作目錄；無 agent 的調用必須設置 root。timeoutMs 範圍爲 100–600000 ms。TypeScript 直接註冊時使用 import * as plugin 與 await ctx.plugin(plugin, { root, timeoutMs: 120000 })。
包版本在 package.json 中爲 0.1.0，許可證 MIT。
典型用法¶
README 示例：先建測試文件，用戶明確要求 TDD 後依次調用：
tdd_status {}
tdd_start {"revision":0,"userRequested":true,"task":"return one","command":["node","--test","test/example.test.cjs"],"tests":["test/example.test.cjs"],"files":["src/example.cjs"]}
tdd_run {"revision":1}
後續每一步使用返回的 revision。實現行爲後再次 tdd_run 進入 REFACTOR，重構後再運行直至完成。需要停止週期時：
tdd_reset {"revision":4}
（示例中的 revision 需與當前會話實際返回值一致。）
適用場景與注意¶
適合：已在本地用 Node 跑真實測試命令、希望 agent 在 DSH ToolRuntime 內按 RED-GREEN-REFACTOR 推進、並願意在用戶口頭 opt-in 後再啓動週期的開發者。
環境與限制（摘自 README Limits）：
- 僅支持主機本地 Node 文件系統與子進程；遠程 DSH world/sandbox 不支持。命令繼承 DSH 主機環境，以主機權限運行，未沙箱化；無 shell 展開，顯式調用 shell 時 shell 同樣享有主機權限。
- 所有跟蹤文件必須事先存在；須在
tdd_start中聲明相關源碼、測試與 fixture；未跟蹤的依賴、併發編輯在最終快照前被還原等情況無法檢測。快照是內容校驗，不是 OS 級事務，也不能防 hostile symlink 競態。 userRequested: true由調用方斷言，插件無法證明人類已請求；工具描述要求模型必須取得用戶明確請求。- 僅 Unix；Windows 進程生命週期未實現。安裝前請閱讀倉庫源碼與 LICENSE，確認命令不會打印密鑰等敏感信息。
社區目錄頁：skillhub.cn - LIghtJUNction/dsh-red-green（獨立站點，與 DeepSeek / 幻方無官方從屬關係）。源碼與問題跟蹤：GitHub。
結尾¶
@lightjunction/dsh-red-green 把 TDD 循環做成 DSH 裏可選、證據驅動的工作流：真實測試命令、revision 協議、RED 寫守衛與文件指紋，用於減少「沒跑測試就宣稱完成」的漂移。默認不打擾 idle 會話；需要時在用戶明確請求後 tdd_start，按 tdd_run 返回的 revision 逐步推進即可。
