dsh-odoo-sdd

workflow已测通过npmMIT

面向 Odoo 的规范驱动开发流水线：15 个工具把需求从不可变规范推进到架构、再到模块代码或线上配置，最终要求一个由真实 Odoo 实例证据支撑的持久判定；闸门 fail-closed，批量操作需在声明的环境中经人工批准，复用 Odoo 自带的 CSV／Excel 导入器，并有一份可回滚本插件所写数据的日志。

下载量 / Downloads

1,813

依赖体积 / node_modules

15.62 MB

测试时间 / Tested

2026-11-06

DSH 版本 / Version

0.2.2-rc.1

安装

dsh plugin --profile web add dsh-odoo-sdd

沙箱测试结果

阶段	结果
1 安装	✓
2 列装	✓
3 挂载	✓
4 启动	—

四阶段在隔离沙箱里跑：安装（有网）→ 列装 → 挂载 → 启动（后三步断网）。

README

</p>

面向 Odoo 的规范驱动开发

<h3>把 DeepSeek Harness 变成一个闭环的 Odoo 工坊：<br/>spec → 架构 → 代码 → 验证，全程面对真实实例</h3>

<!-- npm 徽章指向已发布的包。如果这个项目被 fork 到别处，

请更新 GitHub 徽章里的 owner/repo。 -->

</p>

<a href="README.md"><b>🇬🇧 English</b></a>  • 

<a href="README.es.md"><b>🇪🇸 Español</b></a>  • 

</p>

<b>作者：</b> <a href="https://github.com/fhidalgodev">Franyer Hidalgo</a> — <code>fhidalgo.dev@gmail.com</code>

</p>

<tr>

⭐ <strong>如果这个插件帮你省下了时间，一颗 star 就是很大的帮助</strong> — 它是让这条流水线持续维护下去的信号。

🐛 <strong>发现了 bug，或者想要某个功能？</strong> 用任何语言提 issue 都可以。可复现的报告，以及诚实的"这个不管用"的说明，是你最有价值的反馈。

</td>

</tr>

</table>

</div>

⚡ 概述

dsh-odoo-sdd 把 DeepSeek Harness 变成一条规范驱动（SDD）的 Odoo

开发流水线。有两个理念把它撑起来：

闭环反馈 —— agent 会安装和升级模块、读取服务器 traceback，并针对一个

真实运行中的 Odoo 实例重试。插件从不启动 Docker 或 odoo-bin：你通过一个

被 gitignore 的 .env 把它指向你已有的实例（dev/staging），工具之间只说

标准 JSON-RPC。

流水线安全 —— 每个阶段都持久化到磁盘，门禁在缺少显式 APPROVED 标记时

fail-closed，连续三次失败会强制做根因诊断，verify/fix 迭代次数有上限，

stop.md 会中止一切，而且结论是诚实的：失败的验证会持久化为 FAILED，

永远不可能被报告成成功。

没有 spec 就没有变更 —— 在流水线关闭之后才到来的请求是一次新的变更，

哪怕它出现在同一个对话里（"顺便把 X 也改了"）：它要么得到自己的（小份）spec，

要么得到你显式的 waive。这道守卫对实例变更和源码编辑一视同仁，并且会说明三条

出路里哪一条可用，而不是悄悄改掉。

[!NOTE]

它不是什么： 不是基础设施编排器，不是通过聊天管理凭据的管家，也不是

自动提交器。它不写任何 commit，也从不向你索要密码。

环境要求

需求 · 原因

DSH ≥ 0.2.2-rc.1，运行在 Node ≥ 20 上 · 插件以 Cordis bundle 的形式挂载，并使用 tools 服务；该宿主自身要求 Node ≥ 24.9.0，因此实际运行时的下限是 Node 24（插件代码本身可在 20 上运行）

一个可通过 HTTP(S) 访问的现有 Odoo 实例 · 闭环需要一台真实服务器来安装模块并读取 traceback

一个可丢弃的 dev/staging 数据库 · 验证过程会安装模块并写入测试数据

（可选） 一个 Playwright 浏览器工具 · 仅用于验证的 UI 层以及叙述式手册的截图；没有它时，这些场景会被标记为需要人工检查

（可选） playwright-core ≥ 1.63.0 · 作为可选依赖随插件发布；截图引擎会驱动 Chromium、Chrome 或 Edge，一个都找不到时会返回 NEEDS_BROWSER 并附上一行补救命令

🔭 工作原理

flowchart TD
    A(["想法或需求"]) --> C1["1 CLARIFY<br/>访谈与安全问题"]
    C1 --> R2["2 READ_SPEC<br/>不可变的 spec.md"]
    R2 -->|APPROVED| A3["3 ARCHITECTURE<br/>模型、视图、安全、测试计划"]
    A3 -->|APPROVED| W4["4 WRITE_CODE<br/>模块源码与 OCA 文档"]
    W4 --> V5["5 VERIFY<br/>静态、安装、RPC、UI"]
    V5 -->|PASSED| D9(["handoff.md - DONE"])
    V5 -->|FAILED| F6["FIX_LOOP<br/>根因，最多 5 次迭代"]
    F6 --> V5
    W4 -.-> M7["odoo_module install 或 upgrade"]
    M7 -.->|traceback| E8["odoo_errors"]
    E8 -.-> F6

规范是唯一的真相来源，而且它不可变：代码去适应 spec，绝不反过来。门禁默认由

人来回答；当你选择自主模式时，也可以把它们委派给一个人工代理 agent。

✨ 核心特性

🎯 永远先有 spec，再写代码。 spec.md 携带编号的验收标准；磁盘上没有

持久化的 PASSED 结论，就永远到不了 DONE。

🧬 稳定的需求标识。 每个需求块获得一个稳定的 REQ-<AREA>-NN id（章节 slug + 序号），

外加一枚提交到 req-baseline.json 的指纹。在已有 id 之下改写需求措辞就是 DRIFT：

在你回退它或显式接受它（sdd_phase operation=baseline）之前，推进会被拒绝，这样一份

计划或一个测试就绝不会悄悄引用一条已经不再那么说的需求。

🔗 双向覆盖。 用 # REQ-<AREA>-NN 标注代码和测试，odoo_validate module_dir=… spec_dir=…

会同时检查两个方向 —— 没有实现的需求，以及 spec 已不再声明的孤立标注。下限：

must/shall 在 1.0 处阻断，should 在 0.8 处报告，may 仅作信息。每条需求都会落在

covered / untested / test-only / unimplemented 这架梯子上。

🔍 歧义 lint（建议性）。 mark_spec_loaded 报告没有量化的形容词、含糊的量词、

TBD 占位符、没有施动者的被动句以及 and/or 复合句，每一条都给出具体改写 —— 只是建议，

绝不是门禁。

🧪 真的会失败的测试。 odoo_tests 检查安装日志看不见的测试套件：Odoo 从不导入的

测试文件（没有任何东西加载它）、什么都不断言的测试、被吞掉的异常、破坏逐测试回滚的

cr.commit()、time.sleep、跳过 —— 并把每一条验收标准映射到提到它的测试。scaffold

写出 RED 桩（在实现之前一直抛错），而不是空洞的通过。

🔴 修 bug 时先 RED 后 GREEN。 在 mode=bug 下，流水线拒绝离开 WRITE_CODE，

直到 test-plan.md 记录了先失败的复现（red (evidence: …)，修复后则是

pass (red first: …)）—— 一个从未失败过的回归测试证明不了任何东西。

🔁 真实的反馈闭环。 odoo_module install 返回服务器自己的输出或

traceback；odoo_errors 读取 ir.logging；失败会变成一个持久化的 FAILED

结论，而不是一份乐观的总结。

🧾 不只是模块。 同一套机器也会跑功能型 spec（mode=functional）：

配置一个在线实例，并以人工批准的批次加载数据，CSV/Excel 走 Odoo 自己的

导入器，最后用一份别人能照着复现的 runbook 收尾。

→ [功能路径](#-功能路径配置与导入)

🔒 有凭据不等于有授权。 一个项目打开第一个 socket 之前，需要一份绑定

url + db + user 的显式人工授权（.sdd/grants.json）。

⏪ 说真话的回滚。 checkpoint 会快照文件，并记录每一次 odoo_execute

的前像；restore 总会报告 checkpoint 之后创建的文件。撤销不了的东西，它会直说。

🧱 文档也是门禁。 odoo_docs 产出 OCA 的 readme/ 片段、Apps 的

index.html 和强制的 changelog 条目 —— 而且它对一个没有 spec、没有阶段、

没有实例的已有

…(truncated)

以上内容来自 npm 上的 README，我们只做格式化，不改内容。

版本

npm 上共发布：14，最后更新 2026-11-05

链接

GitHub · Homepage · npm

dsh-odoo-sdd

安装

沙箱测试结果

README

面向 Odoo 的规范驱动开发

⚡ 概述

环境要求

🔭 工作原理

✨ 核心特性

版本

链接

同类插件