Files

T

weichen aba1d6a3d6 Record the user approval of the U5 action scope

Why: The user ruled on the three questions (categories and ranges
approved as proposed; C-class limited to plugin KV plus task ledger;
confirm UX reuses the inline card); the proposal becomes the approved
scope and unblocks the U5 implementation task.

Evidence: Ruling collected via the session question panel on
2026-10-11; implementation task feature/generative-ui-u5 starts under
policy/delivery.md.

Impact: Documents-only (proposal r2 + index status).

Refs: r2 master record U5; Dev task feature/generative-ui-u5
EOF
)

2026-10-11 14:09:20 +00:00

6.3 KiB

Raw Blame History

title, date, type, revision, status, product_contract_source

title	date	type	revision	status	product_contract_source
Generative UI U5 action-scope proposal	2026-10-11	feat	r2	approved	generative-ui-r2-U5-clause

Generative UI U5 动作范围提案（待用户评审）

依据：主记录 r2《Generative UI 调研与插件方案》U5 条款「必须先评审本阶段动作范围」。本文是该评审的提案稿：给出动作分类与开放范围、审批挂接要求、明确排除项与验收条件。用户裁定前不实施；实施另行开任务（U5 实现）。

负责人：裁定 weichen（用户）；起草 Agent；更新时间 2026-10-11。

一、动作分类与本增量开放范围

类	定义	U5 开放范围	通道
A 客户端本地	零副作用：页签切换、折叠展开、排序筛选、复制、doc-ref 打开工件预览	全部开放（U4 已具雏形）	纯前端，不经命令总线、不审计（无副作用可审）；模型不能把 A 类标成"已执行"
B 白名单命令绑定	把既有命令目录中的命令绑定为页面动作按钮	机制全量建设，第一版白名单为空（见下）	cmdbus 四入口同源分发：审计信封、参数 Schema 校验、DangerHigh 确认卡
C 插件自身低危写	generative-ui 表单提交落插件自有存储（Host.KVPut / 后台任务台账），不触发任何业务系统变更	开放（场景 3「方案选择和需求表单」的实现面）	新插件命令 `generative-ui.submit`，经同一分发/审计/幂等
D 业务写与高危	业务系统写（任务/项目/工件/知识库变更、对外发布、外发消息）、DangerHigh 命令直执、跨 owner/跨项目资源、代码执行	全部不开放	U6+ 逐类单独评审后按 B 类机制逐条加白

B 类第一版白名单为空的依据（2026-10-11 源码事实）：当前内置命令为 builtin.help / system.intent / conversation.create / runtime.mock / models.set / conversation.profile——除 help/intent 外均为中危写命令，不存在可安全首开的内置只读命令。结论：U5 交付「绑定-审计-幂等-确认」管道与测试，白名单从空起步，此后每加一条都走独立评审（增量为零的机制 + 可验证的拒绝路径，先把地基打牢）。

二、审批挂接要求（映射 r2 KTD6 与现有机制，全部为既有能力复用）

生成的按钮不是批准：页面动作提交 → 宿主校验（启停/epoch/revision/权限/参数）→ cmdbus.Dispatch（Entrance=button，归一入审计信封）。模型只能引用允许的 action 名称，不能伪造执行结果。
DangerHigh 自动挂既有确认卡：命中 spec.Danger == high 且未 Confirmed 时走现有内联确认卡 + pendingStore 持久化 + Confirm 回道二次分发——用户点卡确认是唯一批准来源； Confirmed 标志只能由卡回道置位，模型路径无法携带（红测断言）。
幂等：requestId 由客户端生成；服务端绑定 (owner, surfaceId, revision, actionId, requestId, 参数哈希)。重复 requestId 同参数 → 返回已有回执；同 requestId 异参数 → 拒绝（对齐 KTD6）。
旧修订受控：动作提交带 revision；revision ≠ 当前 latest → 拒绝并提示刷新（旧按钮不重放）。
禁用语义：activation 关闭后新动作 403；在途按 U2 KTD7 表（已提交业务操作按命令台账收尾，不承诺撤销）。
表单草稿不进模型：草稿由前端按 surfaceId/nodeId 管理，未提交不上传、不进 ctxasm（KTD4/KTD8；测试断言上下文不含未提交字段值）。
参数校验：动作参数按命令 ParamsSchema 服务端校验（validateParams 既有），拒绝越权资源引用（owner 作用域）。

三、交付范围（实施任务的文件面，供参考）

Backend：POST /api/surfaces/{id}/actions（提交动作，走 surfacesvc 守卫 + cmdbus）；幂等台账迁移（新表，纯增量）；genui 目录文档补 action 绑定语法与「仅允许引用宿主下发的 action 清单」纪律。
UI：UIRenderer actions 分支已有渲染，补 onAction 桥到宿主提交（SurfaceView 转发）。
Frontend：SurfaceView onAction → 动作端点；确认卡复用现有 HITL 卡 UI；表单草稿本地态（提交前不外发）。
Core：优先零变更（action 绑定用服务端表，不扩 UINode 契约）。

四、明确排除（本增量不做）

业务实体写路径、跨会话/跨项目动作、自动触发的动作（只响应用户点击）、动作结果自动改写页面（回执展示后由用户或 Agent 显式重组织）、 MCP/外部 HTTP 直连、任意命令即时全开。

五、验收条件（R7 映射，实施任务的判定线）

场景 3 表单可提交、校验失败可修改重试；提交落插件台账可回读。
旧 revision / 越权 action / 重复 requestId 异参数 → 拒绝（红测矩阵）。
DangerHigh 路径必须经确认卡；模型伪造 Confirmed 被拒（红测）。
用户未提交的表单字段不出现在下一轮模型上下文（测试断言）。
禁用后动作 403；A 类本地行为不受影响。
幂等重放返回相同回执（并发双击一次生效）。

六、裁定记录（2026-10-11，用户已裁定）

三点均经用户裁定同意（推荐项全取）：

分类与范围：A 全开 / B 机制先行白名单空起步 / C 限插件自有写 / D 全关——同意。
C 类边界：限定 KV + 后台任务台账，不建新业务事实表——同意。
确认卡 UX：复用现有内联确认卡，不新建审批 UI——同意。

本文升级为已批准范围；U5 实施按 policy/delivery.md 开任务（feature/generative-ui-u5），验收线以第五节为准。

七、原裁定请求（历史留档）

分类与范围：A 全开、B 机制先行白名单空起步、C 限插件自有写、D 全关——是否同意？
C 类边界：插件自身写是否限定为 KV + 后台任务台账（不建新的业务事实表）？
确认卡 UX：复用现有内联确认卡（不新建审批 UI）——是否同意？

裁定后：U5 实施按 policy/delivery.md 另行开任务；本文升级为已批准范围并回填裁定记录。

6.3 KiB Raw Blame History Unescape Escape