# 工作坊链路接入（2026-11-01）

本次调整数据接口、字段适配与 Skill，并在成员页复用原有表格列出逐项目进展；没有修改 CSS、组件样式或布局设计。看板公开查看，不增加登录。服务写入由已有受限令牌授权，员工/Agent 归属是业务记录，不冒充认证账号。

## 实际数据库信息

本次查库：`_User` 账号表为空；11 条旧 Session 有 studentName / groupId / stage 等字段。26 条旧成果有 ownerName、ownerSession、uploadedByKey、agentName、agentId、uploadMethod、uploadedAt；9 张旧机会卡有类似信息。

现存 Agent 名称有“康师傅产品创新助手”“品类调研 Agent”“概念设计 Agent”；未发现“王刚001”的实际业务记录。因此新上传必须从当前对话上下文取实际 Agent 名称，不能把这些旧默认值当作所有机器人的身份。

## 数据约定

- `KfSession.meta.attribution`：发送者稳定键的工作坊内摘要、显示名、身份来源、Agent 实际名称/标识、会话、渠道；真实 userRef 有则引用，无则不创建账号。
- `KfArtifact`：报告原文、看板 report 章节结构、阶段、工作坊、小组、员工与 Agent、来源、待补项。课堂成果为 `dashboardState=workshop`，不伪造员工确认；正式报告确认流程保留。
- `KfOpportunity`：独立机会对象，关联报告及会话，不仅保存报告里的一个段落。
- `KfProject`：由已选机会建立，关联工作坊、小组/负责人、当前阶段与方案版本。这里的“立项”是课堂项目，不代表康师傅正式审批。
- `KfStageEvent`：项目创建、成果提交、阶段推进、卡住、恢复、方案保存、课堂完成，事务内连续记录。
- `KfConcept`、`KfFormulaItem`：方案版本、规格包装、买点、工艺路线与原料用量；未知项保留待验证。真实资料通过既有结构化导入函数入库，来源与模式保持一致。

msgCount 只在渠道确实提供消息数时保存，不把任务调用次数当消息数。不同姓名/稳定键/小组不串项目；同名学员的展示附加组号或身份摘要以作区分。

## 公开读取

新增 `ksfGetPublicBoard` 无需身份登录，返回当前看板所需的六类数据并分页。服务器明确挑选可展示字段，不返回密钥、私密会话键或整份来源 rawPayload。旧展示数据继续保留；新课堂成果有说明；一般未发布正式报告和仅导入的私密原文不会自动公开。

客户端在原有样式与页面中读取该投影，兼容 stageCode / projectRef，修复新数据阶段为空、项目关联丢失的问题。显式 blocked 状态进入现有“卡住”区。仍保留原有页面评分/改状态行为，本轮没有扩大或收紧旧表权限。

成员页的项目进展表显示每个课堂项目的负责人、当前阶段、成果数、方案是否保存、最后活动与状态；项目名可打开其最新阶段报告。继续沿用既有表格和手机布局，没有重做看板视觉。

## 当前交付与验收

- `server/`：已部署云函数的源码、构建及本次增量部署脚本。仅发布 8 个目标函数，无 Schema、权限或凭据修改。核心正式报告确认与发布代码不变。
- `skills/ksf-workshop-runtime/`：新版技能。保留原业务入口与冻结锁；新增 workshop 命令。现有 credential-binding.json 不随包分发，安装时原样保留。
- `scripts/install-workshop-skill.mjs`：数字人容器中升级，先核验全部文件，再备份与写入，最后更新 SKILL.md。不改网关，不重启。
- `scripts/verify-workshop-live.mjs`：管理机使用相同 Skill 模块的远端技术联调；全部内容明确 sample，不是真实员工对话、消费者采集或企业产品立项。
- `scripts/verify-workshop-readback.mjs`：只读核查上述已有样例编号，不重放写入。
- `scripts/verify-workshop-browser.mjs`：实际浏览器打开工作台/成员/阶段/报告，确认公开读取、员工/Agent、正文与手机视口。

安装完成后，还需从新的企微消息真实执行一次“登记实际身份→保存阶段成果→回读”，才能说容器已使用新版 Skill。不要把管理机联调或磁盘安装当成企微调用证据。

## 操作

```sh
npm test
npm run test:workshop
npm run build:workshop
node server/scripts/deploy-workshop.mjs           # 只读生成部署计划
node server/scripts/deploy-workshop.mjs --apply   # 增量部署八个函数
node scripts/verify-workshop-live.mjs             # 使用固定键的 sample 技术联调
node scripts/verify-workshop-readback.mjs         # 后续只读核查，不重复写入
```

管理连接只在部署脚本读取受控配置；数字人只用已有加密受限令牌。令牌有效期仍为 2026-11-06 18:42（北京时间），本轮没有自动续期。

前端需按现有站点发布流程上线，代码通过浏览器验证与正式站点是否已发布须分别记录。当前工作不能代替真实面类资料准备、真实学员彩排或 30–40 人并发验收。

截至本次交付：本地 88 项测试通过；浏览器 22 项检查通过，覆盖匿名读取、逐项目阶段/负责人/完成状态、桌面和 390px 手机阅读。八个云函数已部署回读且 Schema/权限保持原样。管理机样例项目 `Z-IEjZg0qZ`、方案 `NSM6FzDsiX`、报告 `5u4xzJW5DY` 已独立回读，所有成果仍为 sample / workshop，未正式发布报告。

数字人升级包 `ksf-workshop-skill-20261101.zip` 和看板数据发布包 `ksf-board-data-20261101.zip` 由 `scripts/package-workshop.mjs <绝对交付目录>` 生成。用户确认前端由王刚001或平台后台发布；本轮未直接推 Git、未发布前端、未安装 Hermes 容器。容器安装器在隔离目录验证过首次升级、重复安装、未知修改拒绝、坏包拒绝和加密绑定保留。

## 11 月 1 日数字人安装回报核对

用户转发的 Hermes 原始输出显示：技能已更新四项，顶层 11/11、技能 7/7 校验通过；skills_list / skillview 已重新读取。I 轮 status 成功，J 轮 workshop-search 由新 `ksf-workshop.mjs` 执行，实际返回既有样例项目 `Z-IEjZg0qZ`。整包、wrapper、新旧入口的四个 SHA-256 均与本机交付件一致。此处依据转发输出验收，不表示 Codex 直接登录容器检查。

本阶段已具备“数字人安装并调用新入口进行只读服务查询”的证据；尚无升级后真实员工对话生成并保存阶段成果的证据。凭据配置未改变，status/search 的加密包装器实际进行了内存解密与子进程注入，不能称为“完全未使用凭据”。

同期独立读取线上前端：board-service.js 仍未使用 loadPublicBoard，members 尚无逐项目进展，新 workshop-data.js 地址返回 HTML 页面而非 JavaScript。HTTP 200 不能作为该模块已发布的证据。下一步由王刚001或平台后台合并发布第二包，再从新的真实企微消息验收员工/Agent 归属、阶段成果入库与线上显示。核对结果保存在本机 work/hermes-install-IJ-review-20261101.json 和 work/online-frontend-IJ-20261101.json。

## 生产发布独立验收（2026-11-01 23:29，北京时间）

运维 bot 回报已向核实的静态站点目录发布固定提交 d14d02fd358c6c5dedfabc96c53fb29add8bd021。本机随后独立读取生产域名，九个运行文件的完整 SHA-256 全部匹配发布清单，Content-Type 均为 JavaScript；首页仍为原有 1943 字节，SHA-256 与发布前一致。服务端目录、进程与配置情况来自运维 bot 的回报，本机未直接登录源站核查。

使用实际浏览器访问生产域名，22 项检查全部通过：工作台、成员、阶段和样例报告正常加载，项目负责人、S5 与课堂完成状态可见；样例正文和 Agent 名称可见；成员页和报告页 390px 视口无横向溢出；读取走公开云函数，没有直接扫描 Parse 类。该次验收没有业务写入，也不代表新企微消息已经提交过阶段成果。

证据保存在本机 work/workshop-production-verification.json 和 work/workshop-browser.json。剩余第一轮验收是由真实参与者在新的企微消息中登记当前员工与 Agent、提交阶段成果，并用新取得编号独立回读数据库和生产看板；此后继续机会卡、项目和方案的真实对话演练。

## 11 月 1 日管理机补推前端代码

数字人容器报告本地提交 `1f7c028bc075ece78b33b1b5f6d1cb109fd336f4` 因缺 Git 凭据未能推送。管理机使用原有 Git 凭据管理器中的身份，经 Gogs API 确认写权限后，在独立 worktree 提交同一批九个运行文件及 `.gitignore` 精确例外规则，并成功推送到远端 main：`d14d02fd358c6c5dedfabc96c53fb29add8bd021`。没有传递凭据给 Hermes，没有写入凭据文件，没有推送本机 server/skills 等其他未提交开发文件。

主工作区 main 已对齐远端新提交，核对原有 608 个工作文件内容均未改变，其余开发文件保留。容器的旧本地提交无需重复推送；站点发布使用远端 main 的 `d14d02f`，需要同步容器源码时使用新 worktree，避免覆盖原工作区及备份。

推送后独立核查线上九个运行文件：原有 vendor 依赖一致，其余八个业务文件仍未更新；新 workshop-data.js 地址依旧返回 HTML。现有身份无仓库 hook 管理读取权限（403），未取得可用构建状态或站点发布入口。仓库 deploy.sh 是依赖 OBS_BUCKET/obsutil 的部署模板，本机没有对应配置，不能据此猜测实际生产路径。已向用户询问实际平台项目页或部署脚本/目标目录；推送成功尚不等于站点上线。

本机证据：work/frontend-push-result-20261101.json、work/frontend-online-after-push-20261101.json、work/frontend-deploy-status-20261101.json。凭据只用于目标服务认证，不在这些证据内保存。

## 11 月 1 日发布脚本与线上前缀复核

已在干净的独立 worktree 执行 `bash scripts/deploy.sh prod --check-only`，退出码 0。静态体检、core 单测、本地模块图均通过；脚本在上传步骤前退出，没有调用 OBS。生成的临时 index.html / prefix 文件已恢复到本次提交，未影响主工作区。

实际线上 `/` 的 HTML 为 1943 字节，`base href=/`，入口 `/src/app.js`，importmap 均引用 `/lib/vendor/...`。`/kangshifu/` 返回同一根首页，而 `/kangshifu/src/services/board-service.js` 返回同一 HTML，不是 JavaScript；根路径 `/src/services/board-service.js` 才返回真实 JS。故脚本的 prod 默认 `/kangshifu/` 只证明模板的配置，不足以证明当前生产对象前缀。域名根路径仍可能通过 CDN originPath 映射到桶内某个目录，该映射需要真实配置核实，不能从 URL 推断。

响应头 ETag `6ae57be3-797` 的前半段可解码为 `2026-10-31T05:25:55.000Z`，后半段 `0x797=1943`，分别吻合 Last-Modified 和 Content-Length。这符合 Nginx 静态文件 ETag 的时间/大小格式，不能证明源站为 OBS 或识别桶名。当前缺少的是生产配置记录中的源站类型、源站地址、回源目录与发布授权方式；若确认使用 OBS，再核桶名、端点/区域和 CDN originPath。没有要求用户在聊天传 AK/SK。

Git 已推送、prod 模板本地体检已通过，实际站点发布仍未执行。不要在尚未核对生产源站配置时直接运行完整 prod 脚本；该脚本会重写首页前缀并先删后传首页。

## 九文件定向发布工具（备用，未执行生产发布）

新增 `scripts/publish-workshop-files.mjs` 与 `deploy/workshop-files-20261101.json`。白名单固定为本次提交的九个运行文件，已包含新增 workshop-data.js；不包含 index.html、.gitignore、服务端或技能。默认对维护人确认的文件系统目录只读预检，`--apply` 才实际写入；不猜源站、不联网、不接受凭据、不刷新 CDN。对象存储需要对应的上传方式，不能拿该目录工具当 OBS 客户端。

预检核对交付内容、目标旧版/新版、首页指纹、真实目录和软链接。实际写入先在站点目录外备份，再逐文件原子替换与回读；最后再次确认首页字节未变。失败尝试回滚，回滚遇外部改动则保留该版本并报告未完全恢复。文件系统核验与域名最终验收分别报告。

新增四项发布测试通过。另以实际交付九文件、Git 原基线和独立读取的首页，在隔离 work 目录真实运行打包后的 CLI 预检及 apply，两次退出码均为 0，九文件一致且首页未变。此演练不在生产源站执行，不构成线上发布证据。

交付包 `ksf-board-delta-publisher-20261101.zip`：46,297 字节，SHA-256 `6f5f7c168e22ff827e563fb4778559f9b94f7d14967883774da86fdb45c2f6e6`，12 项内容清单均核验通过，无首页或凭据。使用前仍需维护人确认实际源站类型/目录或提供现有发布方式。

## 数字人审读回报与行尾差异复核

用户转发回报显示定向发布包 12/12 校验、源码审读、独立线上首页指纹核对均通过，未执行生产预检或 apply。按用户安排，部署及权限协调暂缓，工具作为备用。

回报中七个运行文件原始 SHA-256 不同，不能据此判断“本地是初版、d14d02f 是代码最终版”或宣布本地提交作废。已独立解读两个原始交付 ZIP：最初看板发布包为七文件 CRLF，Git 提交提取的定向包为 LF；其余二文件字节相同。九个运行文件统一行尾后全部逐字节一致，回报中的七个本地哈希前缀也均对应最初交付件。此结论比较的是两份交付件，没有直接检查容器 1f7c028 的完整提交对象。证据为 work/board-payload-line-endings-20261101.json。

首页指纹一致能识别内容副本，不能单独证明目标目录正在被生产域名使用；仍需维护人确认真实站点映射及执行环境能访问对应目录。当前线上更新与真实企微阶段成果保存后的页面验收尚待后续完成。