dsh-crwu-workbench 0.0.38 → 0.0.39

package/CHANGELOG.md

@@ -7,6 +7,14 @@
 `cordis_define` + `cordis_run` 装配，版本号用 DSH 的 `pkg-N`）；它已在本仓收尾时删除
 （见 `0.0.1` 一节），下面 `legacy · pkg-43` 及更早的记录是它的历史。
 
+## package · 0.0.39 · 2026-10-05 · feat · 审核 Skill 默认发布最终 HTML 与 JSON 到 OSS
+
+- 新增 `crwu-audit/references/15-oss-result-publish.md`，把默认 OSS 双文件发布、精确文件名逐项写后验证、受信目标和非阻塞失败收尾纳入 Skill，而非仅依赖插件提示词。
+- 编排顺序为步骤 14 成对校验与渲染最终结果 → 15 OSS 发布 → 16 独立钉钉归档与通知；完整保留两阶段复核与必要隔离补审，不上传会话内容。
+- 插件提示词显式传入 HTML/JSON `files`，不再把结果 JSON 当可选文件。交付认证/授权失败仅停止受影响通道，保留本地审核成果并分别报告，不能冒充完全交付成功。
+- 沿用现有 OSS Tool 的受信配置、流水号对象前缀和同名覆盖行为；不新增年月/时间戳归档，不改变 Host 审核范围与主会话绑定机制。
+- 更新 Skill 路由、CLI 守卫与提示词契约测试，新增双文件 Tool 成功、JSON 缺失与写后大小不符用例。
+
 ## package · 0.0.38 · 2026-09-30 · fix · 发起失败的手工兜底必须先把会话切成「完全权限」（并把怎么切写清楚）
 
 用户口径（2026-09-30）：「手工兜底那里要加上『打开完全权限』—— 用户可能不知道这个怎么打开，

package/README.en.md

@@ -12,6 +12,8 @@ auto-upload deliverables to Aliyun OSS → open the cloud-hosted audit opinion.
 The audit process itself is **not** in this repository; the `crwu-audit` skill family runs it.
 This repository only *dispatches, watches, and ships back*.
 
+The audit Skill's completion contract generates and validates final HTML/JSON after both audit phases, then explicitly uploads and verifies both files under the [OSS publishing contract](skills/crwu/crwu-audit/references/15-oss-result-publish.md). OSS failure preserves local results and is reported separately while independent DingTalk archive and notification continue. Conversation content is not uploaded.
+
 One form only: `src/` is the single source, bundled by tsdown into `lib/index.js` (Host) and
 `lib/client.js` (Client), distributed as a DSH **package** plugin (npm / tarball / git).
 Migration history: [`PORTING.md`](PORTING.md).

package/README.md

@@ -10,6 +10,8 @@ AI 审核子会话 → 盯住它的运行状态、可随时停止/重启 → 交
 
 审核流程本体不在本仓：它由 `crwu-audit` 技能族执行（见「依赖」）。本仓只负责**发起、盯状态、交付件回传**。
 
+审核 Skill 的收尾契约：完整两阶段审核后生成并校验最终 HTML/JSON，按 [OSS 发布契约](skills/crwu/crwu-audit/references/15-oss-result-publish.md) 显式上传双文件并逐项写后验证。OSS 失败保留本地成果、如实报告，继续独立的钉钉归档与通知；不上传会话内容。
+
 源码在 `src/`，构建产物是 `lib/index.js` + `lib/client.js`，按 **DSH 包插件**（npm）分发安装。
 维护规范见 [`AGENTS.md`](AGENTS.md)，完整发版步骤见
 [`docs/releasing.md`](https://github.com/mmungdong/crwu-ai/blob/main/plugins/dsh-crwu-workbench/docs/releasing.md)，
@@ -428,65 +430,23 @@ CI（`.github/workflows/ci.yml`）在 Ubuntu + Windows × Node 22/24 上跑同
 
 ## 五、npm 发布（包形态的正式分发）
 
-包形态是长期维护的那一半，按 npm 包分发。仓库已配好发布链路，**不要手工 `npm publish`**：
-
-```bash
-npm run version:set 0.0.2     # 改 package.json + VERSION（并同步 lockfile 根版本）
-# 在 CHANGELOG.md 加一节 `## package · 0.0.2 · <日期>`
-npm run check                 # 本地门禁：version:check + typecheck + test + build + smoke:built
-npm run pack:assert           # 核对真正打进 tarball 的文件清单
-git commit -am "release(dsh-crwu-workbench): 0.0.2" && git push
-git tag plugin-v0.0.2 && git push origin plugin-v0.0.2
-```
-
-`plugin-v*` tag 会触发仓根的 [`.github/workflows/release.yml`](../../.github/workflows/release.yml)
-（`v*` 留给仓里的 Go CLI，两条发布线分开）：先断言
-**tag 与 `package.json` / `VERSION` 一致**，再跑完整门禁与产物自检，最后发布。
-
-**当前发布方式（0.0.12 及以后）：只走 tag → GitHub Actions → CI 发布，禁止在本机手工 `npm publish`。**
-推 `plugin-v0.0.12` 这类 tag 时，`release.yml` 会校验 tag 与 `package.json` / `VERSION` 一致，
-再由 CI 用仓库 Secret `NPM_TOKEN` 执行 `npm publish --provenance`（provenance 来自 GitHub Actions OIDC）；
-**Trusted Publishing 尚未启用**，它只是 `docs/releasing.md` §3.3 记录的未来迁移方案。
-本机只允许 `npm publish --dry-run`（dry-run 不是发布）。
-
-下面这段是 **0.0.10 初次建包时的历史记录**，只用于解释 provenance 的本机限制，
-**不得**照它去发 0.0.12 或任何后续版本（那时包还不存在，才必须在本机建包）：
-
-**首次发布（引导）必须在本机做，而且不能带 `--provenance`**（2026-09-28 实测）：
-`--provenance` 只在受支持的 CI（GitHub Actions 的 OIDC）里成立，本机 provider 是 `null`，
-npm 会直接以 `EUSAGE: Automatic provenance generation not supported for provider: null` 拒绝发布。
-所以 `publishConfig` 里**不要**写 `provenance: true`（有测试钉住这一点），本机首发用：
+正式发布优先走 `plugin-v<version>` tag 触发的 GitHub Actions。版本查看、修改、登录检查、空跑与
+应急手动发布都由仓库根目录 Makefile 提供统一入口：
 
 ```bash
-npm login --registry=https://registry.npmjs.org
-npm run build && npm run check && npm run pack:assert:strict
-npm publish                      # 不带 --provenance
+make plugin-version
+make plugin-version-set PLUGIN_RELEASE_VERSION=<version>
+make plugin-pack
+make plugin-publish-dry-run
 ```
 
-**当前真实工作流（0.0.12 仍在用）**：`.github/workflows/release.yml` 读 GitHub Secret
-`NPM_TOKEN`（`NODE_AUTH_TOKEN`），在 tag `plugin-v<版本>` 上执行 `npm publish --provenance` ——
-provenance（构建来源证明）由 GitHub Actions 的 OIDC 在 CI 里产生，**不是**本机发布。
-**Trusted Publishing 目前没有启用**：它只是 `docs/releasing.md` §3.3 记录的**未来可迁移方案**，
-在真的改完工作流之前，不要把"已采用无 token 发布"当成当前事实。
-
-未来若迁移到 Trusted Publisher（npm 网页给这个包配 repo `mmungdong/crwu-ai`
-+ workflow `release.yml`）；之后的版本由 CI 用 **OIDC** 发布 —— 不需要任何长期 token，
-npm 会**自动**附带 provenance attestation，`NPM_TOKEN` secret 也可以删掉。
-也可以在 Actions 里用 `workflow_dispatch` 跑一次 dry-run：只打包与校验，不发。
-
-**`prepublishOnly` 会挡住不该发的包**：先 `pack:assert`（缺入口、误打 `tests/`/`install/`
-一律失败），再 `check`。所以哪怕有人绕过 tag 手工发布，也过不了这两道。
-
-**发布目标钉在官方 registry**：`publishConfig.registry = https://registry.npmjs.org`，与 CI 里
-`setup-node` 的 `registry-url` 一致（`tests/unit/host-package.test.mjs` 会核对两者相同）。
-不钉的话，本机 `~/.npmrc` 若指向镜像（国内开发机常见），手工 `npm publish` 会往镜像上发，
-而 `--provenance` 在镜像上根本不成立 —— 一条命令同时踩两个坑。装依赖仍然走你的镜像，不受影响。
+`make plugin-version` 会显示本地版本、npm `latest` 和建议的下一个 patch 版本。`plugin-pack` 会运行完整
+门禁并核对真实 tarball；`plugin-publish-dry-run` 会先检查干净工作树、npm 登录和版本递增，再构建并空跑。
+插件名默认由 Makefile 顶部的 `PLUGIN` 指定，也可在命令行覆盖。
 
-发之前可以先空跑一次，它会真的跑完 `prepublishOnly` 并打印将要发布的清单（不会上传）：
-
-```bash
-npm publish --dry-run    # 期望看到：Publishing to https://registry.npmjs.org …（dry-run）
-```
+只有 tag 流程不可用且维护者明确选择应急发布时，才运行带精确确认值的
+`make plugin-publish CONFIRM_PUBLISH=<package>@<version>`。完整步骤、门禁和失败恢复见
+[`docs/releasing.md`](docs/releasing.md)。
 
 ### npm 分发路径也实测过
 

package/bin/manifest.json

@@ -1,6 +1,6 @@
 {
   "schemaVersion": "crwu.plugin-bin-manifest.v1",
-  "generatedAt": "2026-09-29T23:54:02.539Z",
+  "generatedAt": "2026-10-05T06:35:26.570Z",
   "platforms": [
     {
       "platform": "darwin-arm64",
@@ -12,9 +12,9 @@
           "source": "repo-build",
           "sourceVersion": "0.0.1",
           "target": "darwin/arm64",
-          "buildCommit": "19cc856be361d1c7eb9284e5c561ccb1f895a189",
+          "buildCommit": "7d713b651b913e99b0e7094ae64a8402f27957a6",
           "size": 7351330,
-          "sha256": "af3da82f605a146333100e7981cdcb45e847691b4abaf5682f4540240e24ea7f"
+          "sha256": "1d989a152e2ee0d8e1724ba1ceeb6fc425eb5d41da5f967e56dd78d9fc199318"
         },
         {
           "tool": "ossutil",
@@ -50,9 +50,9 @@
           "source": "repo-build",
           "sourceVersion": "0.0.1",
           "target": "windows/amd64",
-          "buildCommit": "19cc856be361d1c7eb9284e5c561ccb1f895a189",
+          "buildCommit": "7d713b651b913e99b0e7094ae64a8402f27957a6",
           "size": 8128000,
-          "sha256": "690bc62316cafd575eb65a1092bea339c3674cd4f1a060b68687b80078b5f476"
+          "sha256": "14a97c0c3cccd89735bac07f12685f21563f82d141d9dd87dabc94240eccdf81"
         },
         {
           "tool": "ossutil",

package/lib/index.js

@@ -231,7 +231,7 @@ const PLUGIN_INJECT = [
 * 还会让打包器的 JSON 插件成为隐式依赖。代价是升版本时要同时改这里 ——
 * `tests/unit/host-package.test.mjs` 有一条断言盯着它必须等于 `package.json` 的 version。
 */
-const PLUGIN_VERSION = "0.0.38";
+const PLUGIN_VERSION = "0.0.39";
 /**
 * `ping` / `boot` 应答里的版本指纹，形如 `pkg-0.0.5`。
 *
@@ -2451,6 +2451,7 @@ function toolSection() {
 		"随包 vendored 的 DWS 技能（`dingtalk-*`）**不参与**本次自动审核编排：自动审核的取数与交付只走上表 Tool。",
 		"",
 		"**登录与授权（必须照做）**：任何 Tool 返回「需要先允许工作台访问本机账号和配置」（`not-authorized`）或「未登录 / 会话过期」时：**立即停止本次审核**，在汇报里写明「需要员工回到工作台完成账号连接（氚云 / 钉钉）或允许本机访问」，并把已经完成的步骤列清楚。",
+		"上述审核停止规则用于取数与审核阶段；步骤 14 已成功生成并校验本地 HTML/JSON 后，交付通道的认证/授权失败只停止该通道，保留本地成果并继续其他独立交付，分别报告失败。",
 		"",
 		"**绝对不许**：自己执行登录（`login` 类命令 / 打开浏览器扫码 / 让用户扫码）、去系统钥匙串或用户目录里翻找凭据、改 `PATH` 或去找别的命令、把「登录失败」当成本次审核的结论。你的审批策略是 `never`：任何需要审批的动作都只会被确定性拒绝。",
 		""
@@ -2621,14 +2622,14 @@ function legacyAuditPrompt(task) {
 		L.push("调用一次：");
 		L.push("");
 		L.push("```text");
-		L.push("crwu_audit_oss_publish({ caseDir: \"" + caseDir + "\", seqNo: \"" + seq + "\" })");
+		L.push("crwu_audit_oss_publish({ caseDir: \"" + caseDir + "\", seqNo: \"" + seq + "\", files: [\"审核意见." + seq + ".html\", \"审核结果." + seq + ".json\"] })");
 		L.push("```");
 		L.push("");
 		L.push("要求：");
-		L.push("1. **HTML 必须上传**（`审核意见." + seq + ".html`）。结果 JSON（`审核结果." + seq + ".json`）存在就一并上传；不存在时 Tool 会跳过它，你需要在汇报里说明「结果 JSON 未生成」。");
+		L.push("1. 先读取 crwu-audit 的 `references/15-oss-result-publish.md`：完整两阶段审核及必要补审后，步骤 14 必须成对生成并校验最终 HTML/JSON；显式上传上面两个文件，不省略 `files`，不上传初审、中间产物或会话。成对生成或校验失败则停止本地交付，不调用上传。");
 		L.push("2. bucket / endpoint / 对象前缀由 Tool 从部署配置读取，**不要提交、也不要自己拼 `oss://` 地址**；凭据已经配在本机，**不要问我要 AccessKey，不要回显任何密钥**。");
-		L.push("3. Tool 会在上传后**真的列举一次**核对目标对象与字节数；你必须在汇报里写出 Tool 返回的 `key`、`sizeBytes` 与 `ok`。");
-		L.push("4. 上传失败**不要静默略过**，把 Tool 返回的 `error` 原文（已脱敏）贴出来。");
+		L.push("3. Tool 会在上传后**真的列举一次**核对目标对象与字节数；只有整体 `ok:true`、`results` 按精确 `name` 唯一命中两个预期文件且各项 `ok:true`、`key` 非空、`sizeBytes` 非零并无失败/缺项，才报告 OSS 双文件上传成功。分别汇报 `name`、`key`、`sizeBytes`、`ok`，不能只看 `uploaded` 或 HTML 成功。");
+		L.push("4. 上传失败/部分成功**不要静默略过**，保留本地成果，报告 Tool 返回的 `errorKind`、`error`（已脱敏）与失败/缺项；继续独立的钉钉归档与通知，不改写审核结论、不循环重试、不绕过权限。明确区分本地审核完成与 OSS 交付状态，不冒充完全交付成功。");
 	}
 	if (seq !== "" && caseDir !== "") {
 		L.push("");

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-crwu-workbench",
-  "version": "0.0.38",
+  "version": "0.0.39",
   "description": "中瑞世联工作台 / CRWU audit workbench for DeepSeek Harness: pick a pending audit report, dispatch one AI audit subagent, watch and stop/restart it, auto-upload deliverables to Aliyun OSS.",
   "keywords": [
     "deepseek-harness",

package/skills/crwu/crwu-audit/SKILL.md

@@ -53,7 +53,8 @@ H0 的机制 owner 是 `references/00-input-and-route-profile.md`，隐藏区的
 13. [11-html-delivery-spec.md](references/11-html-delivery-spec.md)：阶段一定稿冻结后、阶段二对照与交付（步骤 14）时读取；**送达与交付层正文**（CRWU 审核意见 HTML 送达规范 v1.6：AuditResult 单一事实源、JSON 校验先行、员工单文件 HTML + 同源监控 JSON、双证据链、两阶段门禁、客观命中率与验收清单）。
 14. [12-leaf-common-contract.md](references/12-leaf-common-contract.md)：加载任一 `crwu-audit-asset-*` / `crwu-audit-biz-*` 叶子时读取；**叶子共同约束**（轴边界、输入、一级根装配、二级选择、执行顺序、条目状态、来源优先级、证据出处、capability gap）。公共规则只在该文件写一份，叶子不各自复述；叶子与它冲突时以它为准。
 15. [13-dingtalk-result-publish.md](references/13-dingtalk-result-publish.md)：步骤 14 已生成最终态监控 JSON 后读取；定义固定组织/团队空间/结果目录的精确解析、按审核年月建目录、带生成时间戳文件名、DWS 上传与写后验证契约。
-16. [14-orchestration-workflow.md](references/14-orchestration-workflow.md)：**正式执行前必读**；router 运行时执行顺序与条件分支的唯一落点——脚本运行时（Python）、路由流程步骤 1–15、KB 兼容与运行时装配边界；步骤 14 的交付细节仍以 `11-html-delivery-spec.md` 为权威、钉钉回传仍以 `13-dingtalk-result-publish.md` 为权威，本文件不复述它们的正文。
+16. [15-oss-result-publish.md](references/15-oss-result-publish.md)：步骤 14 成对生成并校验最终 HTML/JSON 后、步骤 15 上传前读取；定义默认双文件 OSS 发布、受信目标、逐文件写后验证和非阻塞失败契约。
+17. [14-orchestration-workflow.md](references/14-orchestration-workflow.md)：**正式执行前必读**；router 运行时执行顺序与条件分支的唯一落点——脚本运行时（Python）、路由流程步骤 1–16、KB 兼容与运行时装配边界；交付、OSS 与钉钉细节分别以 11、15、13 为权威，本文件不复述它们的正文。
 
 ## 输入
 
@@ -81,10 +82,10 @@ H0 的机制 owner 是 `references/00-input-and-route-profile.md`，隐藏区的
 
 router 的运行时执行顺序与条件分支**只在** [14-orchestration-workflow.md](references/14-orchestration-workflow.md) 维护；入口不复述、不并行维护第二份。
 
-1. **正式执行前必须读取** `references/14-orchestration-workflow.md`——Python 运行时、路由流程步骤 1–15、KB 兼容与运行时装配边界都在那里。
-2. 必须**按 14 的步骤 1–15 顺序执行**：不得跳步、不得调序、不得改写已冻结的阶段产物。
+1. **正式执行前必须读取** `references/14-orchestration-workflow.md`——Python 运行时、路由流程步骤 1–16、KB 兼容与运行时装配边界都在那里。
+2. 必须**按 14 的步骤 1–16 顺序执行**：不得跳步、不得调序、不得改写已冻结的阶段产物。
 3. **阶段一隔离与冻结、阶段二复核不得合并**：读取任何复核记录前，阶段一正式意见与 `route_profile` 必须已定稿并冻结。
-4. Python 运行时与 KB 装配边界服从 14；交付与送达服从 [11-html-delivery-spec.md](references/11-html-delivery-spec.md)（**JSON 校验先行**、`validate` → `render --json-out` 调用序列与字段契约以 11 为唯一权威）；钉钉回传服从 [13-dingtalk-result-publish.md](references/13-dingtalk-result-publish.md)。
+4. Python 运行时与 KB 装配边界服从 14；交付与送达服从 [11-html-delivery-spec.md](references/11-html-delivery-spec.md)（**JSON 校验先行**、`validate` → `render --json-out` 调用序列与字段契约以 11 为唯一权威）；OSS 发布服从 [15-oss-result-publish.md](references/15-oss-result-publish.md)；钉钉回传服从 [13-dingtalk-result-publish.md](references/13-dingtalk-result-publish.md)。
 5. 任一步门禁失败**按「失败与冲突」处理**，不得静默跳过，也不得降级叙述成"材料缺失"。
 
 ## 失败与冲突
@@ -95,6 +96,7 @@ router 的运行时执行顺序与条件分支**只在** [14-orchestration-workf
 - ROUTE001–004 只按 06 挂起受影响的业务/范围/资产标签、基准日或价值类型及其依赖规则；未受影响的技能继续执行。证据冲突不得静默任选一边。
 - 单个专业技能 `pending`、未注册、下载失败或执行失败时逐标签记录原因，其他 `available` 技能和满足条件的公共能力继续执行。
 - 钉钉回传的目标组织、团队空间或结果根目录零命中/多命中时停止回传；只有审核年份和月份目录允许缺失后创建。回传失败不删除本地交付件，也不得换组织、选相似目录或覆盖同名远端文件。
+- OSS 交付失败只停止该通道，保留已验证本地双文件并继续钉钉交付；各通道分别报告，不能把本地审核完成冒充完全交付成功。
 - 只有所有分发维度均无可靠命中时，才停止专业审核结论，输出已知画像、证据、缺口与候选，请求人工确认；表格等不依赖画像的公共能力仍可按条件执行，但不得冒充专业结论。
 
 ## 输出
@@ -148,5 +150,6 @@ dispatch.skills_to_load = stable_unique(
 - `references/11-html-delivery-spec.md`（v1.6 送达规范）要求的逐条裁定、复核对照与综合对比、《本次审核记录清单》、未检查项，以及最终**员工单文件 HTML + 内部同源监控 JSON**（AuditResult 单一事实源渲染）。
 - 脚本目录、用法与维护入口见 [scripts/README.md](scripts/README.md)（脚本清单、命令用法、强制校验规则与维护规则）；交付字段与编排层调用映射仍以 `references/11-html-delivery-spec.md` 为唯一权威，本入口不复述。
 - `references/13-dingtalk-result-publish.md` 要求的钉钉回传状态：成功时保留精确远端路径与节点 ID；失败时保留失败层级与真实原因。
+- `references/15-oss-result-publish.md` 要求的 OSS 状态：双文件分别保留验证结果与对象键；失败/部分成功时保留真实错误与缺项，不改写审核结论。
 
 无专业技能可用时仍交付画像、逐标签 gap 与已执行公共能力结果，不以“无能力”空返。

package/skills/crwu/crwu-audit/references/11-html-delivery-spec.md

@@ -876,6 +876,6 @@ renderer 只能按上表映射展示，不能新增业务字段或另造统计
 
 约定：`digest` 与 `render` 使用同一规范化序列化（排序键、UTF-8、无多余空白），因此冻结指纹可复现、`fileTrace.sourceDigest` 可与冻结摘要互校；脚本仅依赖 Python 标准库，退出码 `0` 通过 / `1` 失败。`render` 的执行顺序固定为：载入输入 → **JSON 校验** → 内存渲染 → 提取 HTML 内嵌对象 → 渲染态校验 → 成对写出；禁止在 JSON 合规前进入 HTML 渲染逻辑。
 
-### 14.2 最终 JSON 钉钉回传
+### 14.2 最终结果远端发布
 
-步骤 14 只负责产生员工 HTML 与最终态内部监控 JSON；其后的远端归档属于独立传输边界。步骤 15 必须读取本技能 `references/13-dingtalk-result-publish.md`，只把已经通过渲染后校验的配套 JSON 回传到固定组织与团队空间。远端失败不得反向改写 AuditResult、HTML 或审核结论，也不得用“本地已生成”代替“远端已验证”。
+步骤 14 只负责产生员工 HTML 与最终态内部监控 JSON；其后的远端发布属于独立传输边界。步骤 15 读取本技能 `references/15-oss-result-publish.md`，显式发布已经通过最终态校验的 HTML/JSON 双文件；步骤 16 读取 `references/13-dingtalk-result-publish.md`，只把配套 JSON 归档到固定组织与团队空间，再把 HTML 发给自己并 DING。各通道独立报告，OSS 失败不阻断钉钉交付。远端失败不得反向改写 AuditResult、HTML 或审核结论，也不得用“本地已生成”代替“远端已验证”。

package/skills/crwu/crwu-audit/references/14-orchestration-workflow.md

@@ -5,9 +5,9 @@
 >
 > 本文件**不复制**以下权威正文：输入字段与五轴画像定义见 `00-input-and-route-profile.md`；
 > 交付与送达规范见 `11-html-delivery-spec.md`（步骤 14 只回指）；钉钉回传契约见
-> `13-dingtalk-result-publish.md`；并集算法与公共能力触发事实源见 `08-union-dispatch-rules.md`。
+> `13-dingtalk-result-publish.md`；OSS 发布契约见 `15-oss-result-publish.md`；并集算法与公共能力触发事实源见 `08-union-dispatch-rules.md`。
 >
-> **导航**：§1 脚本运行时（Python） → §2 路由流程（步骤 1–15） → §3 KB 兼容与运行时装配边界
+> **导航**：§1 脚本运行时（Python） → §2 路由流程（步骤 1–16） → §3 KB 兼容与运行时装配边界
 
 ## 1. 脚本运行时（Python）
 
@@ -88,7 +88,7 @@ Invoke-DshPython '<load_workspace_dependencies 返回的绝对 Python 路径>' @
 这条兼容层只针对 Windows 子代理脚本；macOS / Linux 仍按上面的 POSIX 命令直接执行。
 不能因为包装器失败就改用系统解释器、搜索 PATH 或取消 `workspace-write`。
 
-## 2. 路由流程（步骤 1–15）
+## 2. 路由流程（步骤 1–16）
 
 1. **消费 Host 已准备的输入快照（不要再定位、不要重复取数）**：报告已由 Host 按精确 ObjectId 定位并取数一次，结果落在案例目录的 `输入快照/` 下——完整记录 `报告记录.json`、附件清单 `附件清单.json`、元数据 `快照元数据.json`。`schemaCode` 是 Host 的基础设施状态：**核验记录事实一律以 `报告记录.json` 为准**，不要提交、不要猜测 `schemaCode`，也不要再调 `records list` / 搜表单 / 重新取记录。仅在启动指令明确说明「输入快照缺失」时，才允许**一次**兜底：调 `crwu_h3yun_record_get({objectId,caseDir})`（它由 Host 自己解析 `schemaCode`）。附件元数据直接读 `附件清单.json`（字段：附件字段、文件名、类型、大小、`fileId`）并分类；只有快照缺失时才对同一 `objectId` 调一次 `crwu_h3yun_files_list({objectId,caseDir})`；附件名只用于隔离决策和待抽验提示。（工具**不返回**带会话鉴权的下载 URL，也不需要。）
 2. **阶段一安全下载门禁**：先把一至四级复核意见、质控意见、底稿/在线底稿意见、外审意见、答复文件等归为复核记录。源材料**只按单附件定向下载**取回：对每个源材料附件调 `crwu_h3yun_file_get({fileId, caseDir, relativePath: '材料-源/<文件名>'})`（fileId 来自步骤 1 的元数据）；**复核件绝不下载、绝不进入阶段一工作集**——只在《阶段一排除清单》记元数据。**本链路没有「整单下载」这个能力**：`crwu_h3yun_file_get` 一次只取一个附件，失败就是失败，不存在退化成批量下载的路径。若 `crwu_h3yun_file_get` 不可见或返回 capability gap、或记录含无法可靠区分源材料/复核件的附件，立即停止并记录 capability gap，绝不能接触复核正文。**被排除的复核件必须落盘《阶段一排除清单》**（`排除清单.json`：`[{fileId,name,sizeBytes}]`），供阶段二按 `scripts/fetch_review_records.py --manifest 排除清单.json` 定向取回——取回只认该清单、落 `复核-人工/`、禁写 `材料-源/`、逐件校验字节数（闭环，防越权取件）。
@@ -107,7 +107,8 @@ Invoke-DshPython '<load_workspace_dependencies 返回的绝对 Python 路径>' @
 12. **阶段二复核对照**：AI 意见固定后才在阶段二上下文读取复核记录。**先抽复核件媒体证据**：复核件经 `scripts/fetch_review_records.py` 落 `复核-人工/` 后，跑 `python3 scripts/prepare_materials.py --case <案例目录> --src 复核-人工 --label 复核`（产出 `复核盘点.json` / `复核媒体索引.json` / `媒体证据-复核/`，**绝不覆盖阶段一冻结的 `材料盘点.json`**），把复核意见附件里的图与独立图片同样导出并交宿主多模态读图——人工用截图提出的问题必须按其 `locator` 逐条进入复核事项全集，不得因"复核件里只有图、没有文字"而漏进 `B·AI 新增`。按发生顺序登记 `reviewFiles[]`，并把每条复核意见写入 `reviewItems[]`，记录复核级次、问题模块、`exact/partial/miss`、关联阶段一 issueId、复核原文和处理结果；再做双向三条带：AI∩复核、AI 新增、复核独有。**复核独有项必须先做「在件核验」，再定性**：逐条核验该事项在被审件**最终版**（定稿/终稿）中是否已落实，核验须给出**在件位置**（文件 + 行号/单元格）作为证据，与复核原文出处并列留痕。核验结论四态：`L-resolved`（在件已落实 → 不计漏检、不进命中率分母，仅作人工工作成果呈现。**凡 AI 未命中（`matchStatus=miss`）的复核意见，必须先判断是否因该事项“已被修改/已不存在”而导致 AI 不可能命中：属此情形记 `L-resolved` 并从命中率分母中剔除，且必须给出在件原文（`inFileEvidence.quote`）作为“确已修改”的证明；无法证明已修改的，只能记 `L-open` 并计入漏检**）；`L-open`（在件未落实 → 漏检候选，进步骤 13 隔离补审）；`L-uncheckable`（材料不可读或缺失 → 记未检查项，不臆断）；`L-unclosed`（答复称已改但被审件未落地 → 优先回客户，并同时给 `closureEvidence` 与 `inFileEvidence`）。**禁止**跳过在件核验直接按复核独有项启动补审或计入漏检；不得拿复核文本直接改写阶段一意见。**能力边界与分母剔除（强制）**：①交付件必须显式声明「本工具当前暂不支持底稿文件审核」，底稿类复核意见（`reviewComparison.outOfScopeItems[]`）不计入 AI 命中率、不计漏检，但必须登记备查、可见可展开；②交付件必须逐条列出**不计入命中率分母的条目及其剔除依据**（已修改/已落实、材料缺失或不可读、能力边界三类），使分母可审计；③被剔除的 `L-resolved` 项若为 AI 未命中，须给在件原文证明。客观指标按明细重算：`evaluable=total-L-resolved-L-uncheckable`；**命中率=`(exact+partial)/evaluable`**（**部分命中计为命中，只是层次较低**），并同时输出**命中层次**：精确命中率=`exact/evaluable`、部分命中率=`partial/evaluable`、未命中率=`miss/evaluable`，全部用百分数；综合率先汇总分子分母，不平均各组百分比。**禁止**以 `exact/evaluable` 作为「命中率」主指标（那等于把部分命中当未命中）。每条复核意见必须给出 `hitExplanation`（`reviewerScope` 笼统/具体、`matchedAspects` AI 命中内容、`unmatchedAspects` 未命中内容、`rationale` 判定理由）：复核条目**笼统**（员工写得宽）而 AI 的发现已覆盖其全部实质诉求、只是更细更深时，判 **exact**，不得因深度差异降为 partial；只有复核条目含多个诉求、AI 确有一部分未触及时才判 **partial**。人工指出或在件核验发现的 AI 错误追加进 `selfAuditErrors[]`（`discoveredAt=复审`）。
 13. **隔离补审**：发现漏检候选后，只能由阶段二编排器创建不继承复核文本和阶段二历史的新子任务或隔离执行上下文。该上下文只接收阶段一源材料工作集、已验证的 DWS 规则快照，以及步骤 11 在复核读取前已冻结的完整命中模块集合；应重跑全部阶段一命中模块或完整阶段一审核。禁止传复核原文、摘要、结论，也禁止用复核事项派生、改写、提示、选择或缩窄补审范围。隔离执行先产出并固定不可变的补审结果，再回到阶段二上下文对照。无法建立该隔离上下文时不补审，记录 capability gap 并交人工复核；需要长期修复时登记 `crwu-dev-audit-optimize`。
 14. **交付与回填**：按技能内 `references/11-html-delivery-spec.md`（v1.6 送达规范）执行，**不再引用知识库输出契约**。以 **AuditResult JSON 为单一事实源**汇总阶段一 findings、适用规则集快照、逐条裁定、复核文件与逐条对照、客观命中率及《本次审核记录清单》（AI 检查项、知识库业务/资产必检项、评估数据核查、监管覆盖核查、风险覆盖核查、未检查项及阶段二对照/归因，逐条给证据，对比项两端都给依据）。**每条问题的 `problemDescription` 必须按 §4.6 写成员工可直接核对的「两段式」**：首句 ≤60 字一句话说清问题是什么；其后另起一行写 2–4 行明细（写明差异与影响，并给出本次材料中的具体文件、sheet、单元格或页码）。首句与明细均不得出现规则编号、知识库路径、内部代号或绝对路径——规则叫什么、出自哪本规则库，属于默认折叠的「展开判断依据与规则」，不占员工首屏。报告读者是资产评估师：读不懂的描述等于没审出来，校验器会直接拦截并拒绝渲染。发布前必须通过送达规范 **JSON 校验**：规则性缺陷双证据链齐备、五段式判定完整、问题描述两段式可读、未检查项显式、统计可重算、无绝对路径/`nodeId`/凭据。**每个项目向员工只交付一个自包含单文件 HTML** `审核意见.<项目ID>.html`；内部同步留档 `审核结果.<项目ID>.json` 供审核监控统计，且必须与 HTML 内嵌 AuditResult 完全一致。页面首屏使用三行行动摘要，计数卡可跳转；正文按序呈现 AI 问题、需要人工确认、AI 外部核验、人工复核与客观评分卡；问题位置醒目展示，完整说明与专业轨迹按需展开。落地实现见本技能 `scripts/audit_delivery.py`、`scripts/audit_result.schema.json` 与 `template/audit-report.html`。**编排层交付调用序列（按序执行，不得跳步）**：① 汇总产出 AuditResult 输入 JSON；② `python3 scripts/audit_delivery.py validate 审核意见.<项目ID>.json`（失败 → 停止交付、逐条报告精确 JSON 路径，HTML 与配套 JSON 均不得生成）；③ 仅在通过后执行 `python3 scripts/audit_delivery.py render 审核意见.<项目ID>.json --out 审核意见.<项目ID>.html --json-out 审核结果.<项目ID>.json`（脚本再次 JSON 校验并做渲染后自检，全部通过才成对落盘）；④ 员工侧交付 HTML，内部监控读取配套 JSON。仅当运行时技能副本缺少上述脚本、Schema 或模板时记 capability gap，此时只保留输入 JSON 与校验错误报告，**不得跳过 JSON 校验直接出 HTML**。契约 04 统计台账仍须由本次 `crwu-dws` 实时下载后回填。
-15. **钉钉结果回传**：步骤 14 的最终态 `审核结果.<项目ID>.json` 生成后，调 `crwu_audit_dingtalk_archive({caseDir, seqNo})`（契约见 `references/13-dingtalk-result-publish.md`）；再把 HTML 发给自己并 DING：调 `crwu_audit_dingtalk_notify_self({caseDir, seqNo})`。组织、团队空间、结果根目录、`YYYY/MM` 两级目录全部由 Tool 按契约精确解析（只有年月允许自动创建），**不要提交这些标识、不要手工指定目录**。远端文件名追加 `fileTrace.generatedAt` 时间戳，已存在同名文件时拒绝覆盖。上传失败保留本地交付件并显式报告“钉钉回传失败”，不得把审核完成等同于回传成功。
+15. **OSS 双文件发布**：步骤 14 成对生成并校验最终 HTML 与监控 JSON 后，必须读取并执行 `references/15-oss-result-publish.md`，调 `crwu_audit_oss_publish({caseDir, seqNo, files})`，显式列出本案例的 `审核意见.<报告流水号>.html` 与 `审核结果.<报告流水号>.json`。只发布完整两阶段审核（含必要的隔离补审）后的最终结果；成功必须按精确文件名核对两项写后验证，不能只看整体 `ok` 或上传数量。失败保留本地双文件，显式报告失败/部分成功及真实原因，继续步骤 16，不改写审核结论、不绕过 Host 权限。
+16. **钉钉结果回传**：步骤 14 的最终态 `审核结果.<项目ID>.json` 生成后，独立于 OSS 成败调 `crwu_audit_dingtalk_archive({caseDir, seqNo})`（契约见 `references/13-dingtalk-result-publish.md`）；再把 HTML 发给自己并 DING：调 `crwu_audit_dingtalk_notify_self({caseDir, seqNo})`。组织、团队空间、结果根目录、`YYYY/MM` 两级目录全部由 Tool 按契约精确解析（只有年月允许自动创建），**不要提交这些标识、不要手工指定目录**。远端文件名追加 `fileTrace.generatedAt` 时间戳，已存在同名文件时拒绝覆盖。上传失败保留本地交付件并显式报告“钉钉回传失败”，不得把审核完成等同于回传成功。
 
 ## 3. KB 兼容与运行时装配边界
 

package/skills/crwu/crwu-audit/references/15-oss-result-publish.md

@@ -0,0 +1,49 @@
+# 最终审核结果 OSS 发布契约（结构化 Tool）
+
+本契约只负责上传步骤 14 成对生成并通过最终态校验的 HTML 与内部监控 JSON。默认执行，不因启动提示词未提及而省略；不上传会话、推理记录、源材料、冻结快照或 AuditResult 输入 JSON，不参与审核判断。
+
+## 输入与执行时点
+
+- 完成阶段一冻结、阶段二复核对照及必要的隔离补审后，按 `11-html-delivery-spec.md` 执行 `validate` → `render --json-out`。只发布本轮最终结果，不提前发布初审或中间版本。
+- 两个文件必须来自同一次成功渲染：`审核意见.<报告流水号>.html` 与 `审核结果.<报告流水号>.json`，均非空，HTML 内嵌 AuditResult 与配套 JSON 完全一致。文件名中的项目 ID 使用本案例的报告流水号，与 `seqNo` 一致；不读取旧轮产物补齐缺件。
+- 成对生成或最终态校验失败时，不调用上传；按步骤 14 处理本地交付失败，不能只传 HTML 冒充完整结果。
+
+**执行入口只有 `crwu_audit_oss_publish`，必须显式列出两个文件：**
+
+```text
+crwu_audit_oss_publish({
+  caseDir: "<案例目录绝对路径>",
+  seqNo: "<报告流水号>",
+  files: ["审核意见.<报告流水号>.html", "审核结果.<报告流水号>.json"]
+})
+```
+
+`caseDir` 使用本次 Host 交接的案例目录，`seqNo` 使用已核验的报告流水号。`files` 只提交这两个案例内相对文件名，不省略、不扩大清单：Tool 的默认清单会跳过缺失文件，不满足本契约的双文件要求。
+
+## 目标与 Host 边界
+
+Tool 是 Workbench Host 提供的外部能力，不随单独复制 Skill 自动安装。它核验当前调用会话的审核范围、案例目录及流水号，按受信配置解析 `oss.enabled`、bucket、endpoint 和 prefix；模型不得提交存储目标、基础设施标识或凭据，不自行拼 `oss://` 地址。
+
+对象键沿用现有 Tool 契约：`<受信 oss.prefix>/<报告流水号>/<文件名>`。同一案例同名对象会覆盖为本轮结果；**没有年月目录、生成时间戳文件名或禁止覆盖保证**。钉钉的年月与时间戳规则仅属于 `13-dingtalk-result-publish.md`，不能套用到 OSS。本步骤不提供跨版本留档或双对象原子提交保证。
+
+手工创建主会话后粘贴提示词，不等于已取得 Host 审核范围。Tool 拒绝该调用时保留拒绝事实，不伪造范围、不换案例目录、不绕过授权；本契约不改变会话绑定机制。
+
+## 写后验证与成功判据
+
+Tool 对每个文件上传后实际列举目标对象，核对对象存在、远端字节数与本地一致且非零。模型不用另行调用命令行验证。
+
+只有以下条件**同时成立**才报告“OSS 双文件上传成功”：
+
+1. 返回结构化结果，整体 `ok:true`。
+2. `results[]` 按精确 `name` 分别唯一命中本次请求的 HTML、JSON；两项均 `ok:true`，且包含真实 `key` 和非零 `sizeBytes`（Tool 写后验证所得）。
+3. 没有失败项或缺项；不以退出码、`uploaded` 数量、整体 `ok:true` 或仅 HTML 成功替代逐文件核对。
+
+汇报每个文件的 `name`、`key`、`sizeBytes`、`ok`。`key` 只引用 Tool 返回的普通对象键；不输出签名 URL、凭据、私有 endpoint 或未经脱敏的底层日志。
+
+## 失败与收尾
+
+- Tool 不可见、能力缺失、配置关闭/缺失、认证/权限/范围拒绝、上传失败或写后验证不通过，都属于 OSS 交付失败。停止本通道，不自动循环重试、不改目标；需要重试时先解决失败原因，结果重新生成则重新成对校验再发布。
+- 保留本地已验证 HTML 与 JSON，不回滚审核、不改写已冻结产物或审核结论。只证明一个文件成功时报告“OSS 部分成功”，列出成功项与失败/缺项；无法确认的对象状态标记为“未确认”，不声称未上传或成功。
+- 对 Tool 失败，保留返回的 `errorKind`、已脱敏 `error` 及逐文件结果；对返回不完整，列明缺失的预期文件/验证字段。Tool 不可见时写明 `capability gap：缺少 crwu_audit_oss_publish`，不虚构返回。
+- **OSS 失败不阻断步骤 16 的钉钉归档与通知**；各通道独立调用、独立报告结果。即使交付阶段遇到认证/授权失败，也只停止受影响通道，不把已完成的本地审核称为失败；不得自行登录、查找凭据或改走 shell / Python / 裸业务命令。
+- 最终回复分开说明本地审核、OSS、钉钉归档、钉钉通知。例如：“本地审核完成；OSS 上传失败/部分成功（具体原因）；钉钉归档与通知各自状态。”允许本地审核完成但云端交付失败，**不得冒充所有通道完全交付成功**。

package/skills/crwu/crwu-audit/references/99-maintenance.md

@@ -22,8 +22,10 @@
 | 能力 gap 与待建提案 | `10-capability-gap-proposal.md` |
 | 送达与交付层规范（AuditResult/单文件 HTML、双证据链、两阶段门禁、验收清单） | `11-html-delivery-spec.md` |
 | 最终 AuditResult 的钉钉组织门禁、年月归档、文件命名与上传验证 | `13-dingtalk-result-publish.md` |
+| 最终 HTML/JSON 的 OSS 双文件发布、写后验证与失败收尾 | `15-oss-result-publish.md` |
 | HTML 页面结构、左侧目录、CSS 与打印样式 | `template/audit-report.html` |
-| 总体 workflow、加载指针与输出步骤 | `SKILL.md` |
+| 总体 workflow 与运行时执行顺序 | `14-orchestration-workflow.md` |
+| 加载指针与输出门禁 | `SKILL.md` |
 
 规则正文和检查点不属于本技能族的 owner；只允许按编号和知识库层级路径引用。**例外**：送达与交付层正文（CRWU 审核意见 HTML 送达规范 v1.4）为本技能内正式规范，owner 是 `11-html-delivery-spec.md`，不经知识库下载。
 

package/skills/crwu/crwu-audit/scripts/README.md

@@ -4,6 +4,7 @@
 规范正文（唯一事实源）：本技能 `references/11-html-delivery-spec.md`。
 
 > **归档与通知只走结构化 Tool，本目录不含任何业务 CLI 执行路径。**
+> OSS 双文件发布由 `crwu_audit_oss_publish` 完成（契约见 [15-oss-result-publish.md](../references/15-oss-result-publish.md)）。
 > 钉钉回传由 `crwu_audit_dingtalk_archive`（契约见 `references/13-dingtalk-result-publish.md`）与
 > `crwu_audit_dingtalk_notify_self` 完成；Skill 自带脚本**不得**用 `subprocess` / `child_process` /
 > shell / 裸命令调用 `crwu` / `dws` / `ossutil`。这条边界由 `npm run skills:cli-guard`
@@ -27,7 +28,7 @@
 | `examples/audit-result.sample.json` | 【示意】样例（数值与名称为占位，禁止当真值使用） | §9.3 |
 | `test_audit_delivery.py` | 契约测试（Schema 语义、门禁、证据链、统计可重算、隐私、模板、目录、渲染确定性、转义、打印、空态） | §13.4 |
 | `test_fetch_review_records.py` | `fetch_review_records.py` 的契约测试（清单边界、字节数校验、禁写源材料目录） | [14-orchestration-workflow.md](../references/14-orchestration-workflow.md) 步骤 2、步骤 12 |
-| `test_audit_multiaxis_router.py` | 多轴 router 契约测试（注册表、并集派发、装配路径键、渐进披露与入口尺寸） | [SKILL.md](../SKILL.md) + `references/00–14` |
+| `test_audit_multiaxis_router.py` | 多轴 router 契约测试（注册表、并集派发、装配路径键、渐进披露与入口尺寸） | [SKILL.md](../SKILL.md) + `references/00–15` |
 
 ## 用法
 

package/skills/crwu/crwu-audit/scripts/test_audit_delivery.py

@@ -1669,7 +1669,7 @@ class DeliveryContractDocumentationTest(unittest.TestCase):
 
         router_test_owner = _owner_cell("test_audit_multiaxis_router.py")
         self.assertIn("SKILL.md", router_test_owner, "router 测试必须回指 router 入口")
-        self.assertIn("references/00–14", router_test_owner, "router 测试必须回指 router references 全段")
+        self.assertIn("references/00–15", router_test_owner, "router 测试必须回指 router references 全段")
         self.assertNotIn("§13.4", router_test_owner, "router 测试不归交付规范 §13.4")
 
 

package/skills/crwu/crwu-audit/scripts/test_audit_multiaxis_router.py

@@ -95,6 +95,7 @@ EXPECTED_REFERENCE_FILES = (
     "12-leaf-common-contract.md",
     "13-dingtalk-result-publish.md",
     "14-orchestration-workflow.md",
+    "15-oss-result-publish.md",
     "99-maintenance.md",
 )
 
@@ -401,11 +402,11 @@ class AuditMultiaxisRouterContractTest(unittest.TestCase):
                 f"references/{ORCHESTRATION_REFERENCE} 必须承载运行时细节 {token}",
             )
 
-        # 4) 14 必须按序保留步骤 1–15（执行顺序不得丢步或改序）。
+        # Execution order includes OSS publishing before DingTalk delivery.
         steps = [int(number) for number in re.findall(r"(?m)^(\d+)\.\s", reference)]
         self.assertEqual(
-            list(range(1, 16)), steps,
-            f"references/{ORCHESTRATION_REFERENCE} 必须按序保留 1–15 全部步骤，实际={steps}",
+            list(range(1, 17)), steps,
+            f"references/{ORCHESTRATION_REFERENCE} 必须按序保留 1–16 全部步骤，实际={steps}",
         )
 
         # 5) 14 必须保留阶段隔离、Python 运行时与 KB 装配边界的稳定标识。