| content |
{"Commits":[{"Sha1":"b69710a74 {"Commits":[{"Sha1":"b69710a74604d55a435971103dc033025cbc6e6b","Message":"docs(治理): 建宿主协议签收单目录——C-3 附条件的执行面，六份逐域单全部未签收\n\n立项这件事在本体系里已经被裁过：决策批次-2026-09-16 的 C-3（✅ 采纳）把九个契约域的\n运行宿主裁给上层既有宿主，附条件写死「宿主协议……签收才算准入」，Q01 原文还有两句更硬的\n——「签收前不运行」与「不得以『方便实现』自动新增 M8」。裁决当天的执行顺序 §3 第 4 条\n即为「C-3 宿主协议逐域签收 → Catalog 六项去向」，而建本目录之前，全仓「宿主协议」四字\n只出现在三篇设计文档里，零份签收材料：空着的不是立项，是签收。\n\n本次按十三项最小内容（能力ID / 数据Owner / 运行Owner / 库 / 对外契约 / 鉴权 / 备份 /\nSLO / 值班 / 依赖 / 预算 / 升级退出 / 消费者清单）逐域建单，五份对应 C-3 承接表：\nC15 跨域流程、C16 企业 IM、C17 数据分析、C18 统一体验、C19 成本与容量，状态一律「未签收」。\n每份代填的只有本仓可机器核验的字段（规则文件与行数、域测试、失败关闭夹具例数、Catalog\n登记与 blockers、本域特有约束），宿主侧字段一律空缺；本目录不代任何 Owner 签字，\n不改任何 Catalog 字段——Catalog 去向登记是签收之后的动作，须走 CHG。\n\n三处不能读岔的，逐单复写：\n- C19 的宿主按 C-3 是「复用 C17 选定宿主」，C17 未签收前它的宿主栏无从填起；且 C-15 改案\n 把订阅计量与出账并入本域，范围改写材料 CHG-017 待签，签前须先确认适用哪版范围。\n- C18 的宿主是劈成两半的：企业业务 Shell 归数字员工基座（本单要签的那半），平台自身入口\n 由本仓独立工作台承载（CHG-018 修正，不走宿主签收）。工作台已在本机 dev 跑起来，\n 不构成把 enterprise-experience 读成「已有承接」的理由。\n- C15 是六域里唯一带「无合格宿主则另提运行承接裁决」口子的，那是 Q01 给新建运行承接\n （含本仓模块）留的唯一合法入口，走它要附至少两个宿主方案的成本与迁移影响，不是跳过签收。\n\nC01 注册中心单列为「不适用」：C-3 的承接表只覆盖 C11—C19，注册中心是 C01、责任在\nCatalog Owner / 平台工程，权威状态是获批的 Git 内容，没有「托管到某个上层业务应用」这个选项。\nA-2 附条件里「注册中心项已由 CHG-013 / 014 处理」指的是登记面（code_truth 改指、证据归零），\n不是运行承接裁决。它真正卡的是六条 blocker（DEC-009/010/011/012/031/032）的落地面——\n六条都已 approved，所以不是等裁决，是这些裁决在本域还没有对应实现。\n\n一条五份单共同的前置（机器实测 2026-09-18）：六个域在 contracts/ 里已登记的 HTTP 契约与\nFact 都是 0——contracts/contracts/ 的 7 份 OpenAPI 全属七模块，facts.json 对六域一条没有。\n按仓纪律 1「模块新增端口 / Fact 必须先登记 contracts/」，登记对外契约必须发生在签收之前，\n否则宿主签的是一份没有接口定义的协议。\n\n同时在 Q01 的「待改产物 / 责任」后补一段「签收面」指向本目录，避免新目录成为孤儿文档。\n门禁：治理层 check-workspace-consistency 重跑，除在案常驻的 L9 COMPOSE_PROJECT_COLLISION\n外无新增问题；七份新文档的相对链接与锚点逐条实测可达。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T18:46:22-07:00"},{"Sha1":"7dd4429a2d0400fdd2f2e9ec2b93e8cfb6e52609","Message":"docs(工作台): 订正实现记录里「回绑」那句 —— 本轮只回绑了 runtime 作用域的两份\n\n21b0821 写记录时那句是「报告回绑单独成提交跟在本提交之后」，写的是打算而不是结果。\n实际只做到一半，记录里现在把一半的边界画出来：naming 与 fork-readiness 已在 21b0821 上\n以 worktreeDirty=false 回绑（edff342）；module-imports 的输入集确实被本轮动到，但取证时\n仓根不干净——树里有并行会话正在写的未跟踪产物 docs/能力设计/宿主协议/——按仓根算就是\ndirty，回绑等于把现有 clean 绑定降级，留给干净树上补；caddy 的输入本轮一个都没动，\n不需要跟着走。\n\n也就是说这两项在 21b0821 上的证据形态是门禁 stdout 与退出码，不是回绑报告。记录 §6 改成\n一张处置表，不再是一句笼统的「只在本提交之后单独回绑」。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T18:46:05-07:00"},{"Sha1":"edff342c2c4e3a7b11920e51d87c32905d58280b","Message":"chore(reports): naming 与 fork-readiness 回绑 @ 21b0821 —— 根级两份这轮拿不到 clean\n\n工作台改版（21b0821）动的是 runtime/apps/workbench，naming 与 fork-readiness 的输入集\n覆盖整个 runtime/，所以这两份必须跟着走，否则 check:evidence 会把它们判成过期。两份都在\nruntime 作用域的干净树上重跑，exit 0、worktreeDirty=false。\n\n同一时刻**没有**回绑的两份，以及为什么：\n- reports/module-imports.latest.json：输入集含工作台（规则 3「工作台不得静态 import 任何\n @juhai/module-*」），确实被 21b0821 动到，但它的 provenance 按仓根算——树里有并行会话\n 正在写的 docs/能力设计/宿主协议/（未跟踪，18:43 起），按仓根算就是 dirty=true。回绑一份\n worktreeDirty=true 的报告等于把现有的 clean 绑定降级，不如留着，等干净树上补。\n- reports/caddy.latest.json：同样只能绑 dirty=true，但它的输入（modules.json、\n caddy-routes.json、两个 Caddyfile）21b0821 一个都没动，本来就不需要跟着走。\n\n本轮这四项门禁在 21b0821 上都跑过 exit 0（module-imports、caddy 的证据形态因此是门禁\nstdout，不是回绑报告）。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T18:45:42-07:00"},{"Sha1":"21b0821a2898e0e2d6f4660b8c50744600dd96bb","Message":"feat(workbench): 服务目录重做与交互完善——三处「设计写了、WB-1 没落」的缺口一并补上\n\n本轮只动 runtime/apps/workbench 的前端代码：读的还是原来那三个管理读面与随构建附带的\n目录快照，不新增接口、不新增数据来源、不新增写操作，因此不改变任何模块的验收等级、\n发布档位与 Catalog 状态。\n\n先补的三处不是新功能，是已签署设计里写了而 WB-1 没实现的：\n- 快照的 conflicts / status 此前被整个忽略，页面只渲染 entries。对外交付设计 §3.1 要求\n 「来源冲突展示冲突及证据，不静默挑选更乐观的结果」，现在冲突块排在条目之前，为空时\n 明写「0 处来源冲突」——不靠「没看见」表示没有。\n- §5.3 的「显示来源、环境和更新时间」此前一处都没有。现在每个区块各自显示取数时刻、\n 可单独重取，页脚给出平台接口地址与快照路径。\n- nonce 一直是生成并随授权请求发出，回调里却从未与 id_token 比对（§8 关键验收场景 2\n 要求 PKCE / state / nonce 都正确）。现在 nonce 与 aud 在建立会话之前校验，任一不符即\n 拒绝、不落 sessionStorage；iss 不符只降级为「主体未知」并说明原因——那是 D-10 的部署\n 配置问题，不是这次登录不合法。顺带收了 expires_in 被丢弃的问题：过期令牌此前会补水成\n 「导航栏显示已登录、每个读面都报缺凭证」。\n\n服务目录从一张静态表重做成可取景的服务中心：搜索、四个筛选、排序、分组、选中条目与是否\n对照运行时整体进 URL（默认值一律不写进去，认不出的参数退回默认而不是把页面打空），筛出来\n的视图因此可以直接贴给别人。五列可排序，层按 P0 / P1 / P2 层序、模块档位按 shape →\nauthority → e2 推进序——代码注释与页面 title 都写明这是固定显示顺序、不是优劣排名。详情\n从行内展开改成宽屏常驻面板 / 窄屏行内，六个区加快照自带的 flags 口径提醒；稳定标识、包名、\ncode_truth、绑定提交与 HTTP 前缀都带复制按钮，复制的是完整值而不是截断显示的短号。快照的\ncounts 原样成摘要条，不用筛选结果重算——那是两个时刻的两件事。\n\n新增的「对照运行时」开关默认关：目录页读的是静态快照，不该因为打开一个页面就去打需要令牌\n的接口；开关进 URL，是因为收到链接的人有权知道这个视图会额外取一份数据。打开后表格多一列\n已装载 / 未装载、详情多一节运行时对照。读面失败时只在表格上方说一次（分类 + 原因 + 重试），\n行内用 —，详情那节指回去——同一条 401 不连同同一个重试按钮摆三遍。\n\n运行信息页给出模块与项目的映射及跳回目录的深链（模块 id identity 与项目标识\nenterprise-idp 不是一回事），查不到映射就不给链接。交互面另有：深色模式真正接上（此前\n.dark 变量是死代码），首帧前由内联脚本应用偏好、不闪一帧浅色；焦点环写成原生 outline 而\n不是 @apply ring-*，焦点环消失是可达性缺陷、不该由主题配置的颜色键决定；方向键只在焦点\n落进表格后接管，全局劫持等于抢走页面滚动；窄屏改为收列而不是横向滚动，上一版的详情被困在\n表格的横向滚动容器里、手机上要左右刮着读。\n\n实测与未闭环见 docs/工作台交互与服务目录完善记录-2026-09-18.md。要点两条：nonce / aud\n校验只有单测级证据，托管登录要人工输口令、本轮没走完整授权码流程；工作台仍无仓内测试装置，\n那些断言未进 pnpm check。门禁在本轮的脏树上跑绿（workbench typecheck / lint / build、\ncheck:module-imports、check:naming、check:fork-readiness、check:caddy），报告回绑单独\n成提交跟在本提交之后。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T18:44:46-07:00"},{"Sha1":"ef1f95e091db917900dd98bf11f6385e6b176387","Message":"docs(部署): 登记「装载全部模块」——1/7 不是回归，是 :3101 的 profile 只写了 identity\n\n§11.4 与 §18.3 两处记的「已装载 1/7」都是当时的实测，本节不追改，补的是成因，\n而成因只在一条链上：常驻容器 :53001 由 compose 注入七个 profile，一直是 7/7；\n工作台读的那条链末端是裸 dev 进程 :3101，它的 PLATFORM_PROFILES 取自\n.secrets/enterprise-platform-identity-dev.env，值是 PF-07 阶段 identity 单启时的\n出厂值 'identity'。同一块读面，两个运行面给的答案差六个模块。\n\n改动一处且在仓外：该 env 第 28 行扩成七个（原件备份 .bak-20260919-profiles），\n七个 DATABASE_URL_\u003cMODULE\u003e 本来就齐、与容器指同一台 PG（容器内 postgres:5432 =\n本机 127.0.0.1:55470），迁移无须补跑；Redis 逻辑库 dev 用 5、容器用 14，不撞。\n按 .claude/launch.json 停 pid 19008、重起为 39237，:3098 / :3010 未动，\n未重建镜像、13 个 stack 容器一个没动。仓内零改动。\n\n实测（§19.3，作用域 = 本机 dev，证据等级 = 运行态链路）：启动日志七模块全装载、\n10 条模块作业句柄注册、RLS enforce 校验通过；/api/platform/modules 直打 :3101 与\n经 :3098 代理均 7 条；浏览器 :3010 总览「已装载 / 已登记模块 7 / 7」。端口提供方\n四项由模块承接，其中 factExport 与 serviceCredential 改前是 fail-closed，\npermission / audit 改前走 local-tenant-scope / local-log 回退。\n\n同节写明三条不得读岔的：credential-shape 与 scope 都是 shape 档形状实现、不是权威实现；\n七个模块只有 identity 有 health 探针；装上 ≠ 有能力 ≠ 环境健康。\n\n§19.4 留下四条：① mode 仍是 local（PLATFORM_PORTS_MODE 未设置、非生产按设计回退），\n与容器的 fail-closed 不同档，要不要一并改未裁；② 两个进程现在连同一批模块库，\n队列虽按 Redis 逻辑库分开、作业也要入队才跑，但从 :3101 入队会写容器在读写的库；\n③ env 文件名 identity-dev 与内容（七模块）已名实不符，只登记；④ 本节证据不绑提交——\n裸进程没有 PLATFORM_SOURCE_SHA，且取证时工作区 dirty（工作台改版 WIP）。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T18:36:44-07:00"}],"HeadCommit":{"Sha1":"b69710a74604d55a435971103dc033025cbc6e6b","Message":"docs(治理): 建宿主协议签收单目录——C-3 附条件的执行面，六份逐域单全部未签收\n\n立项这件事在本体系里已经被裁过：决策批次-2026-09-16 的 C-3（✅ 采纳）把九个契约域的\n运行宿主裁给上层既有宿主，附条件写死「宿主协议……签收才算准入」，Q01 原文还有两句更硬的\n——「签收前不运行」与「不得以『方便实现』自动新增 M8」。裁决当天的执行顺序 §3 第 4 条\n即为「C-3 宿主协议逐域签收 → Catalog 六项去向」，而建本目录之前，全仓「宿主协议」四字\n只出现在三篇设计文档里，零份签收材料：空着的不是立项，是签收。\n\n本次按十三项最小内容（能力ID / 数据Owner / 运行Owner / 库 / 对外契约 / 鉴权 / 备份 /\nSLO / 值班 / 依赖 / 预算 / 升级退出 / 消费者清单）逐域建单，五份对应 C-3 承接表：\nC15 跨域流程、C16 企业 IM、C17 数据分析、C18 统一体验、C19 成本与容量，状态一律「未签收」。\n每份代填的只有本仓可机器核验的字段（规则文件与行数、域测试、失败关闭夹具例数、Catalog\n登记与 blockers、本域特有约束），宿主侧字段一律空缺；本目录不代任何 Owner 签字，\n不改任何 Catalog 字段——Catalog 去向登记是签收之后的动作，须走 CHG。\n\n三处不能读岔的，逐单复写：\n- C19 的宿主按 C-3 是「复用 C17 选定宿主」，C17 未签收前它的宿主栏无从填起；且 C-15 改案\n 把订阅计量与出账并入本域，范围改写材料 CHG-017 待签，签前须先确认适用哪版范围。\n- C18 的宿主是劈成两半的：企业业务 Shell 归数字员工基座（本单要签的那半），平台自身入口\n 由本仓独立工作台承载（CHG-018 修正，不走宿主签收）。工作台已在本机 dev 跑起来，\n 不构成把 enterprise-experience 读成「已有承接」的理由。\n- C15 是六域里唯一带「无合格宿主则另提运行承接裁决」口子的，那是 Q01 给新建运行承接\n （含本仓模块）留的唯一合法入口，走它要附至少两个宿主方案的成本与迁移影响，不是跳过签收。\n\nC01 注册中心单列为「不适用」：C-3 的承接表只覆盖 C11—C19，注册中心是 C01、责任在\nCatalog Owner / 平台工程，权威状态是获批的 Git 内容，没有「托管到某个上层业务应用」这个选项。\nA-2 附条件里「注册中心项已由 CHG-013 / 014 处理」指的是登记面（code_truth 改指、证据归零），\n不是运行承接裁决。它真正卡的是六条 blocker（DEC-009/010/011/012/031/032）的落地面——\n六条都已 approved，所以不是等裁决，是这些裁决在本域还没有对应实现。\n\n一条五份单共同的前置（机器实测 2026-09-18）：六个域在 contracts/ 里已登记的 HTTP 契约与\nFact 都是 0——contracts/contracts/ 的 7 份 OpenAPI 全属七模块，facts.json 对六域一条没有。\n按仓纪律 1「模块新增端口 / Fact 必须先登记 contracts/」，登记对外契约必须发生在签收之前，\n否则宿主签的是一份没有接口定义的协议。\n\n同时在 Q01 的「待改产物 / 责任」后补一段「签收面」指向本目录，避免新目录成为孤儿文档。\n门禁：治理层 check-workspace-consistency 重跑，除在案常驻的 L9 COMPOSE_PROJECT_COLLISION\n外无新增问题；七份新文档的相对链接与锚点逐条实测可达。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T18:46:22-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/51e311bf417385a994296f20da3b9458761bdee8...b69710a74604d55a435971103dc033025cbc6e6b","Len":5}... |