前言¶

智能體在真實項目裏連續交付多個任務時，常見三類問題：任務狀態只存在對話裏，跑完的任務沒法覈對改動，循環派活沒有人卡驗收。qiqll/dsh-task-suite 把 Claude 的 task-* 任務體系移植到 DeepSeek Harness（DSH），提供一份磁盤上的任務池，加上狀態機、主會話調度、後臺 worker 和機器驗收。

它沒有 Web 任務板，backlog.md 就是看板；也不強制 git，沒有 git 倉庫時用文件快照完成基線比對、改動歸屬和回滾。下面介紹它的安裝、目錄結構、用法和驗收邏輯。

一、這是什麼¶

qiqll/dsh-task-suite 是 DSH 的本地插件，維護者 qiqll，許可證爲 MIT（見 package.json），運行要求 Node >= 20。

它把四個角色拆進一份任務池加一套工具：主 agent 負責與需求方對話、排期、派活、驗收；後臺 subagent 在全新上下文裏完成單個任務並輸出結構化報告。任務池是磁盤上的 Markdown，需求方可以直接看、直接改。

與已有做法的區別：Claude 的 task-* 生態狀態目錄在 .claude/，本插件只使用 .dsh/tasks/，默認不碰 .claude/ 池。它沒有內置心跳或 cron，長循環需要外部定時器提醒主會話 tick；也沒有 Web 任務板。

二、安裝與啓用¶

從 GitHub 源碼安裝，這是當前推薦的方式：

dsh plugin add qiqll/dsh-task-suite

npm 包發佈後也可以直接按包名安裝：

dsh plugin add dsh-task-suite
# 或指定 profile
dsh plugin --profile web add dsh-task-suite

桌面版在 設置 → 插件 裏搜索 dsh-task-suite 安裝。首次安裝後工具與三個 skill（task-admin / task-loop / task-worker）自動註冊，無需重啓。

插件按 awesome-dsh-plugin 的收錄格式準備，市場卡片、安裝與更新由該目錄和 npm 版本驅動。這是社區目錄，與 DeepSeek / 幻方無官方從屬關係。

本地開發時把本目錄用 link: 指向 profile 的依賴即可；改代碼後對該插件行禁用再啓用，就完成熱重載。

三、狀態目錄與狀態機¶

任務池落在 .dsh/tasks/：

.dsh/tasks/
├── backlog.md          # 需求方入口：P0–P3 表、待決策、人工阻塞、ID 規則
├── dev-plan.md         # AI 維護：當前批次、進行中、技術前置
├── dev-progress.md     # 已完成歸檔（按月）
├── inbox/              # 需求方/調度方投遞（task_*.json），merge 後移到 .merged/
└── auto/               # 運行時狀態，整目錄 gitignore
    ├── current.json    # 當前任務：nonce / startSha / 髒文件 / 階段
    ├── session.json    # 循環會話：active / max / hours / done / noprog
    ├── run.log         # 運行流水
    ├── STOP            # 停機標記
    └── snapshots/      # 非 git 模式：開工快照 + manifest（確認後刪）
        └── T-001-<nonce>/
            ├── manifest.json
            └── files/

task_init 在 git 倉庫裏會把 .dsh/tasks/ 加進 .gitignore，非 git 目錄不創建該文件。每個工作區獨立一份池；任務池是運行態，不進業務提交。

狀態機：

待開始 → 進行中 → 待驗證 → 已完成
             └→ 阻塞 / 待決策 → 待開始
             └→ 打回 → 進行中

同一時刻只允許一個「進行中」；P0 可中斷，舊任務記錄斷點。

四、建池與錄入¶

先用 task_init 建目錄，再用 task_add 錄入任務：

task_init                                   # 建 .dsh/tasks/（git 倉庫裏順帶寫 .gitignore）
task_add items=[{title, module, priority, deps, acceptance, note}]
task_status                                 # 全局視圖 / 待決策 / 阻塞 / 流水

task_add 一次可以錄入 1..N 條，會自動判重、分配 ID、檢查依賴和驗收字段，參數有 items[] 和 source。task_status 給出全局視圖與下一步建議。

單步手動模式：

task_pick mode=manual task_id=T-001         # 自己認領並實施
task_accept report="<報告塊>"               # 機器驗收
task_confirm task_id=T-001 conclusion="..." # 需求方確認後歸檔

五、自動循環與後臺 worker¶

自動循環是推薦用法：

task_loop action=start max=10 hours=8
task_loop action=tick        # 返回 worker_prompt
# 把 worker_prompt 原樣交給 subagent 工具；然後結束回合等完成通知
# 收到 worker 的最後一條消息後：
task_accept report="<整段報告塊>"
# 通過 → 待驗證；需求方確認 → task_confirm；不通過 → task_reject
task_loop action=tick        # 派下一個

task_loop 的 action 有 start / tick / stop / halt / resume / requeue / status。正常停機用 task_loop action=stop reason="..."；中途叫停要先調用 interrupt_agent，再 task_loop action=halt，halt 保留提交但不回滾。叫停後繼續用 action=resume（同一任務帶斷點重派），放回隊列用 action=requeue。

沒有內置心跳，長循環可以用 schedule_create 定時提醒主會話 tick。

六、工具一覽¶

七、Worker 報告契約¶

worker 最後一條消息只輸出結構化報告塊：

=== TASK-AUTO REPORT ===
NONCE: <current.json 的口令>
RESULT: DONE | NEEDS_DECISION | BLOCKED | BASELINE_RED | FAILED | GATE_PENDING_REVIEW
TASK: T-001
START_SHA: <開工 SHA>
COMMITS: <sha...>
TEST_CMD: <[cd dir &&] 單條測試命令 路徑...>
TEST_RESULT: 基線 x passed, y failed → 交付後 z passed, w failed；既有失敗：...
TEST_CHANGES: 僅新增 / 無改動 / 有修改（說明）
GATE: <code-reviewer H×n M×n；跳過原因；...>
ACCEPTANCE: <對照驗收標準>
ASSUMPTIONS: — / ...
DECISION: — / 問題 / 選項 / 推薦
BLOCKER: — / ...
DERIVED:
- [P2] 標題 | 涉及文件 ... | 來源 ...
BRIEF:
給需求方的 1–3 句人話說明
=== END REPORT ===

task_accept 校驗 nonce、任務歸屬、階段、提交信息裏的任務 ID、髒文件、測試範圍與基線失敗集合、測試是否被改弱、高風險路徑。通過後把任務落到「待驗證」並生成衍生任務；失敗則按 RESULT 進入待決策 / 阻塞 / 自動失敗計數。

GATE_PENDING_REVIEW 時驗收暫停在 review_pending：調度員自己看 start_sha..HEAD，通過就再調用 task_accept 並傳 review="pass: ..."（同一報告即可）；不通過就把發現發回 worker 修復並重交。

八、兩種基線模式¶

mode 默認 auto：能拿到 git HEAD 就用 git 模式，否則自動用文件模式；也可以強制 mode: file / mode: git。

快照默認排除 .git、node_modules、.venv/venv、__pycache__、dist/build、.dsh/tasks 等。項目很大時用 snapshotIgnore 排除更多目錄，或調大 snapshotMaxBytes / snapshotMaxFiles。任務確認/打回後快照會刪除，默認只保留最近 10 份快照。

文件模式的 TEST_CMD、測試改弱審計、nonce、遺留文件檢查與 git 模式完全一致；只是「提交歸屬」換成「快照差異歸屬」。

九、驗收與防作弊¶

1、nonce：每次 claim 生成一次性口令，舊報告/重複通知直接丟棄。
2、提交歸屬（git）：git log START_SHA..HEAD 裏每個 commit 的 message 必須含任務 ID；出現別人的 commit 就停下，不自動處理。
3、改動歸屬（文件）：與開工快照比對，新增/修改/刪除都列出；報告 CHANGES 與實際不符會告警。
4、基線比對：當前測試失敗時，在 git worktree 的 START_SHA（git）或快照副本（文件）上重跑同一命令，只有「基線也失敗」的用例纔算既有失敗；新失敗 → 打回。
5、測試範圍：TEST_CMD 必須是單條命令，禁止 ; | & $( > < 與 -k/--deselect/--ignore/--lf/--collect-only/--passWithNoTests；改動/刪除的測試文件必須落在命令路徑參數覆蓋範圍內。
6、改弱審計：刪除用例、移走文件、skip/xfail、註釋斷言、斷言淨減少、測試配置 ignore 都會產生告警；DONE 帶告警 → 轉「待決策」。
7、高風險路徑：認證、支付、遷移、部署、CI、依賴清單等；命中時要求報告寫 GATE 與 ASSUMPTIONS，否則轉人工 review。

機器驗收在原 verify_tests.sh / check_test_weakening.sh 的基礎上重寫爲 Node 實現，判定口徑保持一致。

十、配置項¶

插件配置寫在 cordis.patch.yml 的 config，可以覆蓋以下默認值：

十一、適用場景與注意¶

適合需要在本地項目裏連續做多個任務、希望每一條交付都有驗收和歸檔的 DSH 使用者；也適合沒有 git 倉庫，但仍要區分「這次改動屬於哪個任務」的場景。

需要注意幾點：插件以當前 dsh 進程的權限運行，會寫 .dsh/tasks/，並按配置做快照、git worktree 和測試命令回放。安裝前應閱讀源碼與許可證，確認測試命令、進程派生與文件操作範圍符合項目要求。

開發自測可以直接執行：

cd dsh-task-suite
node selftest.mjs

自測覆蓋兩種模式：git 下的建池/錄入/解析、認領、報告解析、DONE 驗收與歸檔、FAIL_NEW 基線比對、測試改弱、inbox、待決策、循環啓停、halt/resume/requeue；非 git 下的快照認領、快照差異歸屬、DONE 驗收、FAIL_NEW 基線、測試改弱、失敗回滾。

結尾¶

dsh-task-suite 把 task-* 的排期、派活、驗收三件事落到磁盤上：backlog.md 可讀可改，驗收由機器按基線比對與改弱審計完成，git 倉庫和非 git 目錄都能跑。目錄頁在 https://www.skillhub.cn/plugins/qiqll/dsh-task-suite，源碼在 https://github.com/qiqll/dsh-task-suite。