@lark-base-open/base-database-cli 1.0.0 → 1.1.1

package/skills/lark-base-database/references/permission-design.md

@@ -1,6 +1,6 @@
-# 数据库应用权限与访问设计
+# Base Database 权限与访问设计
 
-本文负责应用的访问与权限设计：在平台权限模块之外，用 bindings、SQL Function 和 FaaS 校验把「谁能看什么、谁能做什么」设计成可验证的事实。用法是「访问模型先行」：理解需求时先形成访问模型，再让它约束 binding、SQL 与写入链路的实现。实现层协议见[代码开发手册](development.md)与 [SQL Function 专项](sql-function.md)；原生多维表格侧的角色与高级权限配置见[原生 Base 能力发现与路由](base-capability-routing.md)。
+本文负责应用的访问与权限设计：在平台权限模块之外，用 bindings、SQL Function 和 FaaS 校验把「谁能看什么、谁能做什么」设计成可验证的事实。用法是「访问模型先行」：理解需求时先形成访问模型，再让它约束 binding、SQL 与写入链路的实现。实现层协议见[FaaS 协议](faas.md)与 [SQL Function 专项](sql-function.md)；原生多维表格侧的角色与高级权限配置见[原生 Base 能力发现与路由](base-capability-routing.md)。
 
 本文内容分两层：**平台安全模型**是当前平台的事实，不是设计选项，所有方案都必须在它成立的前提下推导；**设计默认路径**（成员表配方、分表方式等）是被验证过的出发点而非唯一解——可以按业务另择实现，但替换方案必须重新通过对应小节的判定问题。
 
@@ -8,8 +8,8 @@
 
 应用在飞书里是一篇多维表格文档。当前平台的权限事实：
 
-- **准入只有一道门**：能打开线上应用的人 = 对这篇应用文档有阅读权限的人。范围由文档分享设置决定，掌握在用户手里，应用代码无法收窄它。Preview 环境只有应用 owner 本人能访问。
-- **门内以 owner 身份执行**：应用读写 Base 数据一律以应用 owner 的身份进行，访问者本人对底层 Base 有没有协作权限不参与判定。底表的原生高级权限（行列权限）不约束应用访问者的读取——原生权限管的是直接打开多维表格的人，应用是另一个入口，两边要分别设计；应用内的读取范围由 SQL Function 自己写了什么决定。
+- **应用访问准入**：能打开 Prod 应用的人 = 对这篇应用文档有阅读权限的人。范围由文档分享设置决定，掌握在用户手里，应用代码无法收窄它。Preview 环境只有应用 owner 本人能访问。Prod/Preview 是发布态，与 CLI 的部署环境分别判定。
+- **数据访问以 owner 身份执行**：应用读写 Base 数据一律以应用 owner 的身份进行，访问者本人对底层 Base 有没有协作权限不参与判定。底表的原生高级权限（行列权限）不约束应用访问者的读取——原生权限管的是直接打开多维表格的人，应用是另一个入口，两边要分别设计；应用内的读取范围由 SQL Function 自己写了什么决定。
 - **调用面对全体访问者开放**：任何能打开应用的人都可以用任意参数调用任何已发布的 SQL/FaaS Function，并且可以对 bindings 内的每张表直接使用平台记录写入通道（批量创建、更新、删除），不经过页面 UI。UI 显隐、路由守卫和前端校验只是体验，不是边界。
 - **唯一可信身份在 SQL 层**：`CURRENT_USER_ID()` 是访问者身份唯一可信的来源，由平台服务端注入、页面无法伪造，且只能在 SQL Function 内使用。Page 和 FaaS 的业务代码拿不到可信的访问者 user id，任何「当前用户是谁」的判断都必须落到 SQL。
 - **FaaS 不是更高权限**：FaaS 与 Page 的数据读写权限完全相同。FaaS 的安全价值是提供「访问者改不了的校验位置」，不是提权。
@@ -20,19 +20,19 @@
 
 理解需求时，与用户角色、核心对象一起回答三个问题，形成一份紧凑的访问模型（放在内部规划中，不创建额外文档）：
 
-1. **谁能打开应用**：分享范围是团队内、全组织还是更大？这是用户手里的旋钮，把它当输入而不是假设；需求未说明时按「全组织可见」的口径设计门内权限。数据越敏感，越不能让安全性依赖「反正没分享给别人」。
-2. **门内谁能看什么**：哪些数据全员可见，哪些只能看与自己相关的（「我的 X」），哪些按角色区分？
+1. **谁能打开应用**：分享范围是团队内、全组织还是更大？分享范围是设计输入；未说明时采用保守的访问者范围评估数据暴露，但不代表已设置全组织分享，也不授权扩大分享范围。
+2. **应用内谁能看什么**：哪些数据全员可见，哪些只能看与自己相关的（「我的 X」），哪些按角色区分？
 3. **谁能做什么**：哪些写入人人可做，哪些限定角色，哪些只属于管理员（owner）？
 
-三问答案都是「全员一样」的应用不需要角色结构，不为不存在的需求预建成员表和权限判定；但身份过滤（第 2 问）与写入校验的通用规则仍然适用。只有数据所有权、权限或安全存在实质歧义时才询问用户，口径与[风格手册](style-guide.md)一致。
+三问答案都是「全员一样」的应用不需要角色结构，不为不存在的需求预建成员表和权限判定；但身份过滤（第 2 问）与写入校验的通用规则仍然适用。只有数据所有权、权限或安全存在实质歧义时才询问用户，口径与[工程质量](style-guide.md)一致。
 
-## Bind 即暴露
+## 绑定范围
 
 **原则**：一张表 bind 进应用，等于把 owner 权限内该表的全部行列同时置于两个暴露面之下——读的一侧是「SQL Function 写什么就能查什么」，写的一侧是「平台写入通道全开」。未 bind 的表读写都会被服务端拒绝：bindings 是当前唯一有平台强制力的收窄手段。
 
 **判定**：对每张要 bind 的表问——它最敏感的字段被分享范围内任何人读到、最关键的记录被任何人改掉或删掉，业务能否接受？
 
-**默认路径**：只 bind 页面与 Function 实际需要的表。读判定不通过时，回到数据建模按权限边界分表（风格手册的业务设计原则），让敏感字段留在不 bind 的表里。写判定不通过时要清楚：FaaS 校验只约束走 FaaS 的路径，挡不住直调平台写入通道的访问者——篡改需要主动构造请求，普通使用不会发生，但有能力的访问者可以做到。这是当前平台的已知残余风险：是否可接受由数据敏感度和分享面共同决定，不可接受时不把该数据放进应用，或与用户确认收窄分享面，并把结论写进交付说明。
+**设计目标与当前限制**：绑定范围应只包含业务可接受暴露的表。当前 CLI init 会绑定目标 Base 全部表，不支持选表初始化；执行前按[工程与环境](workspace.md#需求与-base-定位)核对范围。不能将“只绑定必要表”当成现有 CLI 参数。读判定不通过时，重新选择可整体绑定的数据范围；当前 init 不支持在同一 Base 内仅将敏感字段分表后排除绑定。写判定不通过时要清楚：FaaS 校验只约束走 FaaS 的路径，挡不住直调平台写入通道的访问者。这条绕过路径不能由页面或 FaaS 校验阻止。这是当前平台的已知残余风险：是否可接受由数据敏感度和分享面共同决定，不可接受时不把该数据放进应用，或与用户确认收窄分享面，并把结论写进交付说明。
 
 ## 读路径：SQL Function 就是策略面
 
@@ -46,19 +46,19 @@
 - 按角色区分可见性时，在查询 SQL 中关联成员表完成判定（见下节），而不是发布「高权限版」和「低权限版」两个 Function 靠前端选择调用。
 - 敏感列不进 SELECT 就不会泄露；不用「全量查出、前端隐藏」。
 
-## 操作权限：成员表配方
+## 操作权限：成员表方案
 
 需要「某些人能、其他人不能」时的默认路径（不是唯一解，但替换方案必须同样以 `CURRENT_USER_ID()` 为判定源）：
 
-1. **成员表**：一张成员表，人员字段存用户、受控单选存角色，bind 进应用。注意成员表自身就是典型的写敏感表，同样处于上节的残余风险之下；团队内场景通常可接受，敏感场景按上节处理并在交付中说明。
+1. **成员表**：一张成员表，人员字段存用户、受控单选存角色，bind 进应用。注意成员表自身就是典型的写敏感表，同样处于上节的残余风险之下；是否可接受须结合明确的业务风险与访问范围判断，不能仅凭“团队内使用”推断；无法保护角色来源时，不承诺严格角色隔离。
 2. **whoami**：一个固定 SQL Function 按 `CURRENT_USER_ID()` 查成员表，返回当前访问者的成员记录与角色；查不到按「无角色」处理，业务层默认拒绝。
 3. **前端显隐**：页面用 whoami 的结果决定入口与视图的显隐——这是体验优化，真正的边界在读写路径。
-4. **角色敏感写入走 FaaS**：FaaS 先调用含 `CURRENT_USER_ID()` 的固定校验 SQL（角色、归属、状态尽量并入一次查询，见[代码开发手册](development.md#远程调用与写入链路设计)），通过后再执行写入，不通过返回稳定业务码。
+4. **角色敏感写入走 FaaS**：FaaS 先调用含 `CURRENT_USER_ID()` 的固定校验 SQL（角色、归属、状态尽量并入一次查询，见[FaaS 协议](faas.md#远程调用与写入链路设计)），通过后再执行写入，不通过返回稳定业务码。
 5. **操作者与审计**：写入需要记录「谁做的」时，操作者身份取自可信 SQL 的查询结果，不取页面传值；需要审计的 operation 在业务字段中显式记录操作者与时间。
 
-owner 专属的管理功能用平台下发的 `isOwner` 信号做门控（服务端裁决，缺失按 false 处理），参考 starter 中的现有用法。
+owner 身份采用平台下发的 `isOwner` 信号（缺失按 false 处理），不能由页面自行比较用户 ID。身份判定与入口显示条件分别处理：starter 的“编辑应用”入口仅在 `isOwner === true && getDatabaseContext().env === 'prod'` 时显示；Preview 中 owner 身份为 true，不代表需要展示该入口。其他业务管理功能是否允许在 Preview 使用取决于需求，不能一律套用 Prod 限制。上述页面显隐不替代服务端授权。
 
-### 配方示例
+### 实现示例
 
 以报销应用为例：全员可提交报销单，管理员可见全部并审批，普通成员只能看自己的。示例展示默认路径的关键写法；角色档位、判定并入查询还是拆分按业务调整，但判定源必须是 `CURRENT_USER_ID()`，SQL 语法约束以 [SQL Function 专项](sql-function.md)为准。
 
@@ -89,42 +89,36 @@ WHERE "用户".userId = CURRENT_USER_ID()
 LIMIT 1
 ```
 
-角色判定并入业务查询（管理员看全部，成员只看自己的），用派生表带出当前访问者的角色，不发布高低权限两个版本：
+普通成员的个人记录查询直接在目标表使用可信身份过滤，例如：
 
 ```sql
-SELECT e.rec_id AS record_id, e."标题" AS title, e."金额" AS amount, e."状态" AS status
-FROM "报销单" AS e
-CROSS JOIN (
-  SELECT COUNT(rec_id) AS admin_count
-  FROM "成员"
-  WHERE "用户".userId = CURRENT_USER_ID() AND "角色" = '管理员'
-) AS me
-WHERE me.admin_count > 0 OR "申请人".userId = CURRENT_USER_ID()
-ORDER BY e.rec_id DESC
+SELECT rec_id AS record_id, "标题" AS title, "金额" AS amount, "状态" AS status
+FROM "报销单"
+WHERE "申请人".userId = CURRENT_USER_ID()
+ORDER BY rec_id DESC
 LIMIT 50
 ```
 
-FaaS 写前校验（审批动作，`$1` 声明为 `RECORD_ID`）——角色、目标记录存在性和状态并入一次查询，FaaS 只在结果为 1 时执行写入：
+FaaS 需要判断管理员身份时，可以调用固定的无参数 SQL：
 
 ```sql
-SELECT COUNT(e.rec_id) AS approvable
-FROM "报销单" AS e
-CROSS JOIN (
-  SELECT COUNT(rec_id) AS admin_count
-  FROM "成员"
-  WHERE "用户".userId = CURRENT_USER_ID() AND "角色" = '管理员'
-) AS me
-WHERE e.rec_id = $1 AND e."状态" = '待审批' AND me.admin_count > 0
+SELECT COUNT(rec_id) AS admin_count
+FROM "成员"
+WHERE "用户".userId = CURRENT_USER_ID() AND "角色" = '管理员'
 ```
 
-FaaS 调用 SQL 与写入的协议见[代码开发手册](development.md#faas-开发)。
+该查询只证明当前访问者的角色；写入前仍要验证目标记录、合法状态和业务要求。能在支持集内合并的检查可合并，不能为了减少一次调用使用未经支持的聚合派生表 JOIN。
+
+按角色返回不同数据范围的读取，必须在每个已发布查询内部完成身份与范围判定。不能由 FaaS 先查角色后调用一个对所有访问者开放的无过滤“管理员查询”来实现读取隔离。角色关系无法用当前 SQL 支持集表达时，报告该方案的能力限制，不发布可绕过的查询。上述示例不承诺成员表不可被平台写入通道修改，仍受绑定范围一节的限制。
+
+FaaS 调用 SQL 与写入的协议见[FaaS 协议](faas.md#faas-开发)。
 
-## 常见失分点
+## 常见权限设计错误
 
 最常见的失误例子，不是完备清单——没列到的情况回到威胁模型推导：
 
 - 通过参数传 user id 实现「我的 X」，任何人换个参数就能看别人的数据。
-- 全量查询后由前端过滤敏感行列——数据已经离开服务端，过滤只是表演。
+- 全量查询后由前端过滤敏感行列——数据已经离开服务端，客户端过滤不能撤销已经返回的数据。
 - bind 了敏感表，靠「页面没做那个功能」当保护。
 - 以为底表开了高级权限，应用访问者也随之受约束。
 - FaaS 校验的依据是页面传入的 user id、角色或 isAdmin 标记。
@@ -133,6 +127,6 @@ FaaS 调用 SQL 与写入的协议见[代码开发手册](development.md#faas-
 ## 交付与验收
 
 - 交付说明中包含访问模型结论：分享面假设、按人/按角色的可见性设计，以及写敏感表的残余风险（如有）。
-- 对外分发或扩大分享范围前，提醒用户核对应用文档的分享设置——这是唯一的准入旋钮，且不在代码里。
+- 对外分发或扩大分享范围前，提醒用户核对应用文档的分享设置——该设置决定访问准入，不能由页面代码代替。
 - 角色化行为在 Preview 无法由 owner 之外的人验证（Preview 仅 owner 可访问，`CURRENT_USER_ID()` 恒为 owner）；多角色验收在 Prod 环境用真实账号完成，交付时说明这一限制。
-- 修改原生 Base 角色或高级权限、删除 binding 属于危险操作，按 [Skill 主流程](../SKILL.md#危险操作确认)执行两阶段文字确认。
+- 修改原生 Base 角色或高级权限、删除 binding 属于危险操作，按 [Skill 主流程](../SKILL.md#外部操作与授权)核对具体目标和影响范围的授权。

package/skills/lark-base-database/references/release.md

@@ -1,81 +1,89 @@
-# 数据库应用发布与验收
+# 发布与交付
 
-常规发布只使用 `npx @lark-base-open/base-database-cli deploy`。CLI 内部固定执行：生成 Function metadata → 全量 SQL 校验并汇总失败项 → 根据依赖指纹安装必要依赖并构建 → 归档 → Functions 全量更新 → Artifact 上传与源码回读 → Preview 发布与状态轮询。存在任一 SQL 校验失败时不会安装依赖或执行 Page/FaaS build；依赖指纹未变化且对应 `node_modules` 仍存在时自动跳过 `npm ci`，但仍重新执行 build。仅在排障时使用 `--force-install` 强制重装或用 `--no-install` 无条件跳过安装。
+发布任务进入本流程。故障定位和用户明确要求的专项验收见[诊断与验收](verification.md)。环境与命令前缀见[工程与环境](workspace.md)；本流程适用于一方与三方。
+
+## 发布前
+
+确认工程与 应用 一致、保留需求外 Function，完成本次修改的静态检查。涉及视觉的变更按[前端设计指导](frontend-design-guide.md#交付前自检)检查；涉及通知先按[通知集成](notifications.md)确定路由、资源范围和启停策略。
+
+依赖安装使用 CLI 随包固定的 npm，不受宿主 PATH 中 npm 版本影响。安装失败时保留子项目路径、npm 版本与原始错误：lock 不一致先核对本次 `package.json` 变更，按 CLI 错误提示修复该子项目的 lock 并检查差异，再重试一次；网络或权限错误先解决对应原因。不要盲删 lock、循环切换 npm 版本，也不要用 `--no-install` 掩盖安装失败；重试仍失败时保留证据并定位原因，不自动报告部署成功。
 
 ## Preview
 
-每次 Preview / Prod 发布成功后还会自动生成、安装或更新本应用专属 Skill。交付时按 `agentGuide.skill.status` 报告安装结果并提示用户后续可直接使用本应用能力；生成文件每次部署覆盖更新，函数及 Schema 则在使用时实时发现。Preview 的 Skill 仍只指向正式版。安装失败单独报告，不重发应用；修复见[应用能力 Skill](database-capability-skill.md)。
+在含 `base-database.jsonc` 的目录执行：
 
 ```bash
-npx @lark-base-open/base-database-cli deploy
+base-database-cli deploy
 ```
 
-该命令通常需要约 30 秒到 1 分钟，中间不显示阶段进度。
+CLI 负责 Function metadata、全量 SQL 校验、必要依赖安装、Page/FaaS build、归档、Functions 全量更新、Artifact 上传与源码回读、Preview 发布和轮询。SQL 校验失败时不会继续构建；依赖指纹未变且 node_modules 有效时可跳过安装，但仍 build。安装选项仅在有相应排障依据时使用，不通过跳过校验掩盖失败。
 
-成功结果包含制品大小、SHA-256、publish ID 和设置 `mode=edit` 的顶层 `baseAppUrl`。CLI 只读取成功态发布轮询的 `result.baseAppUrl`，不使用 `catalog.json` 或 OpenAPI GetProject 兜底；成功态缺少该字段时立即报错。命令结果不返回管理后台 URL、旧 Preview URL、`preview`/`production` URL 对象或发布平台静态资源 `appUrl`/`staticUrl`；静态资源地址仅保存在内部 Preview 回执。
+等待命令完成，进程仍在运行不代表失败，不重复启动部署。只有发布成功响应中的顶层 `baseAppUrl` 是可信交付入口，制品大小、SHA-256 和 publish ID 用于追溯。不能用历史 URL、管理后台、Catalog 或内部 `staticUrl` 替代缺失入口。
 
-部署成功后，从零创建了新 Base 的应用先完成下述“示例数据闭环”；复用已有 Base 或修改已有应用时不擅自添加示例记录，直接提供顶层 `baseAppUrl`、本次变更摘要和短验收清单。Agent 始终不展示管理后台 URL、旧 Preview URL 或内部静态资源 `staticUrl`。用户继续在飞书登录态确认：
+发布成功后按顺序处理：
 
-1. 路由不是 404/5xx；
-2. HTML 与静态资源加载成功；
-3. 页面出现本次版本内容；
-4. SQL Function 能读取真实 Base 数据；
-5. 平台支持 FaaS 时，从页面写入并由 SQL Function 回读同一记录。
-6. 页面通过 `createArgusCsrfPlugin()` 加载 Argus Runtime；真实 JSSDK 写请求携带 `x-secsdk-csrf-token`，且端到端调用成功。
+1. 本次创建新 Base：完成下述示例数据验证；复用已有 Base 或修改 应用 不擅自写示例记录。
+2. 本次涉及原生通知：完成[通知入口与状态收尾](notifications.md)，保留原有启停状态。
+3. 按下述[应用能力 Skill 安装](#应用能力-skill-安装)读取安装结果，再汇总已验证范围、业务成果和未完成项，交付 Preview 并等待体验。
 
-提示用户体验完成后回复“部署正式版”。
+普通建站的自动运行态验证限定为示例数据闭环；Page 写入、UI 交互和多角色行为未测试时明确列为未验证，不宣称 E2E 通过。用户明确要求验收或排障时进入[诊断与验收](verification.md)，而不是受本次交付停止条件限制。
 
-### 从零搭建应用示例数据闭环
+部署已取得 publish ID 后超时或中断，使用[发布任务查询](verification.md#发布任务查询)恢复观察，不启动第二次部署。
 
-这是从零搭建应用在 Preview 发布后的窄范围运行态验收，也是“发布后不调用 Function”通用规则的唯一例外：
+## 从零建站示例数据验收
 
-1. 从 `catalog.json` 读取真实 Base/table/字段信息，通过当前项目的 Base Database CLI 路由先执行 `lark-cli base +field-list`，再执行 `lark-cli base +record-batch-create` 写入小而完整、带稳定可见标记的非敏感示例数据；没有项目级路由时直接使用同名 `lark-cli ... --as user`。不得静默自动播种或使用静态 fixture。
-2. 校验 `record_id_list` 数量和 `ignored_fields`。存在业务数据展示时，再通过 `/open-apis/base/v3/sites/:site_token/invoke_function/:function_id?env=preview` 调用页面实际使用的 SQL Function，确认示例记录、关系和聚合已经进入真实 Base；不得用写入返回值、`+record-list` 或 mock 代替展示链路验收。
-3. 失败时保存脱敏 `code`、`msg` 和 LogID。重试前先用同一 SQL Function 确认是否已经部分写入；写入问题检查 Catalog、CellValue、关联 ID 和权限，查询问题必须修改 SQL Function、参数或响应解析。实现问题修复后重新 `deploy` 再验证。
-4. 只有认证、权限或平台服务存在证据充分的外部阻塞时才停止并标记 `blocked`；写入或 SQL 回读未通过时不得交付为完成。通过后停止运行态验收，再执行必要的通知入口收尾并向用户交付 Preview。
+本节只适用于本次创建了新 Base 的从零建站；复用已有 Base、修改已有 应用 时不得擅自添加示例记录。先设计小而完整的非敏感示例，覆盖核心对象、典型状态和必要关联，在可见业务主字段使用稳定的“示例”标记，不新增仅用于播种的字段。构造记录 payload 前读取当前 lark-base 的 CellValue 协议，不能直接复用 FaaS 下游请求的字段格式；两条链路可能有不同的输入归一化。
 
-此闭环不需要浏览器，不授权发布 Prod、删除示例数据或读取用户凭证，也不替代 Page 写入与 UI 的 E2E 验收。
+示例数据使用 lark-cli 的输入契约。`+record-batch-create --help` 提供常用格式，完整类型与日期时间支持形态按当前 lark-base 的 CellValue 文档核对；文档位置通过 `lark-cli skills read lark-base` 的路由查找。下表区分两条链路，执行前仍核对安装版本的协议与真实字段：
 
-### 原生通知入口收尾
+| 字段 | 开发期 lark-cli 写入 | FaaS 应用记录 写入 |
+| --- | --- | --- |
+| 单选 | `["待处理"]`，数组最多一项 | `"待处理"`，合法选项名字符串 |
+| 多选 | `["标签一", "标签二"]` | 同为选项名数组 |
+| 人员 | `[{"id":"ou_..."}]`，由当前 CLI 通讯录查询取得 open_id | `[{"id":"内部 user_id"}]`，由 starter 人员选择器的 `User.user_id` 取得 |
+| 日期时间 | 按当前 lark-base CellValue 文档确认带时区文本、Base 时区文本或毫秒值的支持形态；命令帮助只提供常用文本示例 | 按[FaaS CellValue](faas.md#base-读写协议)格式提交 |
 
-发布前逐个检查 `LarkMessageAction`，按固定优先级确定入口：用户明确要求进入多维表格时使用 `base_action`；用户明确要求通知纯展示、无需点击入口时使用 `informational`；其他所有与应用业务对象关联的通知一律使用 `site_action`。不得从通知正文足够完整或用户未指定跳转目标推断 `informational`。
+两条写入链路的格式不能直接互用，也不能仅替换 ID 前缀。最小 CLI 请求示例（字段名、选项和 ID 均需替换为真实查询结果）：
 
-1. Page 先实现通知对应的真实功能路由。新 `site_action` workflow 在 Preview 发布前不创建；从零搭建应用还必须等示例数据闭环通过后再创建，避免示例记录触发真实通知。不得用 `$.<trigger>.recordLink`、Base URL、管理后台 URL 或自行拼接 URL 兜底。
-2. `deploy` 成功后只使用响应返回的顶层 `baseAppUrl` 作为用户入口。新 workflow 在保留 `mode=edit` 等既有查询参数的前提下加入 Page 已实现的功能定位参数和 workflow 上下文中的目标对象标识；已有 workflow 才先 `+workflow-get`，再用完整定义执行 `+workflow-update`。例如访客接待通知进入当前访客登记详情，考试通知进入对应考试详情或答题页；不得使用内部静态资源 `staticUrl`。
-3. `informational` 只有在用户明确要求通知纯展示、无需任何点击入口时才允许 `btn_list=[]`，并必须记录用户原文。空按钮列表不代表原生通知不可点击，也不能证明它不会沿平台默认行为跳转 Base。
-4. `base_action` 只在用户明确要求通知进入多维表格时使用；回读并记录该授权语义，不得将 Base `recordLink` 描述成应用入口。
-5. 执行 `+workflow-enable`，随后 `+workflow-get` 回读全部 `LarkMessageAction`：核对入口策略、启用状态、按钮列表；`site_action` 还要确认业务按钮基于本次顶层 `baseAppUrl`，并能从 URL 参数定位到当前 Preview 应用中对应的功能与业务对象。任一条件不满足时立即执行 `+workflow-disable`，并把结果标记为 partial 或 blocked。
-6. 在 Preview 交付清单中记录每个相关 workflow ID、入口策略、按钮字段路径，以及环境无关的功能定位参数；没有按钮时记录平台默认跳转限制。Prod 切换必须复用这份清单，不得只更新碰巧记得的一个按钮。
-7. 完成后立即交付 Preview；不得借此继续修改 Page、调用 Function 或发布 Prod。
+```json
+{"create_records":[{"任务名称":"示例：准备评审","状态":["待处理"],"负责人":[{"id":"ou_example"}]}]}
+```
+
+1. 从 `catalog.json` 读取真实 `baseToken`、table ID、字段类型和选项。先通过项目路由执行 `base-database-cli lark-cli -- base +field-list --base-token <base-token> --table-id <table-id>` 核对可写字段，再使用 `base-database-cli lark-cli -- base +record-batch-create --base-token <base-token> --table-id <table-id> --json '<payload>'` 写入已经设计的示例数据。当前环境提供等价的 Base Database CLI 命令时只替换命令前缀，不改变 `lark-cli` shortcut、参数或 payload；没有项目级路由时才直接执行同名 `lark-cli base +... --as user`。只写存储字段，单批不超过 200 条，不写 formula、lookup、系统字段或附件。
+2. `--json` 使用 `{"create_records":[{...}]}`；成功必须返回与请求数量一致的 `record_id_list`，并检查可选 `ignored_fields`。多表或有关联记录时按真实依赖串行写入，后续关联只使用前一步返回的 record ID。
+3. 存在列表、详情、看板、统计等业务数据展示时，通过项目路由调用页面实际使用的 SQL Function，而不是用 `+record-list` 代替展示链路验收：`base-database-cli lark-cli -- api POST /open-apis/base/v3/sites/<app-token>/invoke_function/<function-id> --params '{"env":"preview"}' --data '{"params":[...]}' --json`。检查 Function 顶层业务码与 ResultJSON，并确认刚写入的示例记录、关系和统计真实可见。
+4. 重复验证或修复后重试前，先用同一 SQL Function 按稳定示例标记或已返回的 record ID 确认当前状态，只补写缺失数据。创建结果未知时禁止盲目重试，避免生成重复记录。
+5. `lark-cli` 写入失败、返回记录数不符、SQL Function 返回非零业务码、响应结构不符合契约，或查询不到已确认写入的数据，都视为示例数据闭环未完成。保存脱敏错误和 LogID；写入问题检查 Catalog、字段、CellValue、关联 ID 和权限，查询问题检查 SQL、参数及响应解析。实现问题修复后重新 `deploy`，再从本节第 1 步验证。
+6. 只有认证、权限或平台服务存在证据充分的外部阻塞时才标记 `blocked`；不得声称示例数据或整体从零建站已完成。示例写入与 SQL 回读均通过后，才进入通知 workflow 收尾并向用户交付 Preview。
+
+该闭环不需要浏览器，也不替代用户对 Page 真实写入流程、交互状态和 UI 的 E2E 验收，更不构成 Prod 发布授权。不得读取、输出或代填用户凭证。
 
 ## Prod
 
-只有用户体验本次 Preview 后明确回复“部署正式版”，才执行：
+用户体验本次 Preview 并明确授权发布同一制品后执行；授权判定见[主流程](../SKILL.md#外部操作与授权)。
 
 ```bash
-npx @lark-base-open/base-database-cli deploy --production --yes
+base-database-cli deploy --production --yes
 ```
 
-CLI 校验 Preview 记录、应用 token 和 Artifact SHA-256，随后直接发布同一制品，不重建、不替换。`--yes` 只表示调用方已经取得本次 Prod 授权；不能用任务开始时笼统的“搭建并发布”代替，也不能由 Agent 自行验收后授权。
+CLI 读取 `.base-database-cli/state/preview.json`，校验 应用 appToken、Artifact SHA-256 与工作区输入指纹，发布同一份制品，不重建或上传替代品。缺少 Preview 记录、旧回执缺少指纹、制品或源码/配置/文件结构变化时，重新生成 Preview 并取得针对新制品的确认。`--yes` 只是向 CLI 传递已有授权。
 
-`deploy --production` 只发布应用制品，不会自动更新 Base workflow。Prod 发布成功后，只要 Preview 交付清单包含通知入口，就必须对清单中的每个 workflow 执行 `get` → 完整 `update` → `get`。`site_action` 使用响应返回的顶层 `baseAppUrl`，只替换环境入口，逐字保留对应的功能定位参数、动态对象参数、其他步骤和启用状态；`informational` 和 `base_action` 不改写入口语义，只复核按钮列表、平台限制或用户明确要求仍然成立。回读验收必须同时满足：每个应用业务 `openLink` 都基于生产 `baseAppUrl`、功能定位参数与 Preview 阶段一致、链接中不再包含 `mode=edit`，且 workflow 启用状态未变化。`site_action` 不得退化为应用首页、Base 记录或应用管理后台。
+Prod 发布不会自动更新 Base workflow。存在通知集成时，按 Preview 留存的清单逐个完成[生产入口切换](notifications.md#生产入口切换)。切换失败则明确报告“Prod 已发布，但通知入口切换未完成”，保存失败对象与证据；不重复发布 应用 来掩盖外部配置失败。
 
-Prod 应用发布成功但任一 workflow 更新或回读失败时，不要重新发布 Prod，也不要报告整体完成；明确告知用户“Prod 已发布，但通知入口切换未完成”，附上失败的 workflow ID 和脱敏错误，修复后重新执行 `get` → `update` → `get` 收尾。
+## 应用能力 Skill 安装
 
-## 发布状态
+普通 deploy 在本次 Preview / Prod 轮询成功后，CLI 自动从模板生成并安装/更新本应用专属 Skill，到当前执行用户的 `$CODEX_HOME/skills`（未配置时为 `~/.codex/skills`）。同一 应用 和平台环境使用固定目录，只更新本工具管理的 SKILL.md，不覆盖附加文件或其他 Skill；不需要 Agent 另行重复安装。
 
-CLI 使用 publish 响应中的 `publishId`，并通过 query 调用 status：
+交付时先读取 `agentGuide.skill.status`：installed/updated 时报告 name、path 与入口；failed 时只报告 error，不读取不存在的 name 或宣称已安装。结合 agentGuide.message 说明使用条件；先确认路径属于目标客户端的 Skill 发现目录，目录正确但未刷新时再提示刷新或开启新会话。Preview 安装的 Skill 仍只发现正式版，不代表本次 Preview，也不授权自动发现、调用 Function 或发布 Prod。
 
-```text
-GET /open-apis/base/v3/sites/:site_token/publish_status?publishId=:publish_id
-```
+通过 deployments status（含 --wait）确认成功，仅证明原发布任务成功；该命令不安装本应用 Skill，也不返回 agentGuide。缺少安装证据时报告“安装状态未确认”，需要补装时使用[应用能力 Skill 安装命令](database-capability-skill.md#安装与恢复)，不重新 deploy。
 
-每 5 秒轮询，最多 3 分钟：`0/1` 继续，`10` 成功，`20` 失败，未知状态停止。只有成功态的 `publish.result` 返回 `staticUrl` 和 `baseAppUrl`；CLI 只使用其中的 `baseAppUrl`，不读取本地 `catalog.json`，也不调用 OpenAPI GetProject。缺少 `baseAppUrl` 时发布命令失败，不猜测用户入口。Preview 设置 `mode=edit`，Prod 移除 `mode`；发布平台静态资源 `result.staticUrl` 不向用户暴露。
+安装失败不会撤销已成功的发布，单独报告原因。修复、重新生成或安装到其他客户端时读取[应用能力 Skill](database-capability-skill.md)，不重新部署掩盖安装问题。托管环境的执行用户目录不等于终端用户电脑，不能把沙箱安装描述成已安装到用户本机。
 
-## 故障证据
+## 交付结果
 
-失败时保存环境、应用 token、阶段、publish ID、脱敏响应和 LogID/Edge request ID。
+默认提供访问链接、业务功能或本次变更、用户可执行的体验步骤、实际通过的验证以及影响使用的限制。示例数据要说明覆盖的业务对象和回读结果；命令、Function ID、制品摘要、workflow 清单保留为可追溯证据，按研发或排障需要展示，不要求业务用户检查 header 或 SDK 协议。
 
-依赖安装使用 CLI 随包固定的 npm，不受宿主 PATH 中 npm 版本影响。安装失败时保留子项目路径、npm 版本与原始错误：lock 不一致先核对本次 `package.json` 变更，按 CLI 错误提示修复该子项目的 lock 并检查差异，再重试一次；网络或权限错误先解决对应原因。不要盲删 lock、循环切换 npm 版本，也不要用 `--no-install` 掩盖安装失败；重试仍失败时保留证据并定位原因，不自动报告部署成功。
+明确区分发布成功、验证通过、整体完成；未验证不等于失败，也不等于通过。示例数据或关键业务检查未完成时，不报告整体完成：可交付部分结果标记 partial，存在外部阻塞才标记 blocked；定义见[完成条件](../SKILL.md#完成条件)。
 
-写请求失败时先排除登录、权限和业务错误；若未加载 Argus Runtime 或请求缺少 `x-secsdk-csrf-token`，升级 JSSDK 并重新构建发布，不得手写 Token。
+普通 Preview 交付后等待用户体验；后续用户提出修改或诊断时继续相应工作。Prod 交付使用本次生产 `baseAppUrl`，附件需求按[文件传输](file-transfer.md)核对目标环境支持范围，不把尚未开通或未验证的能力写成已实现。

package/skills/lark-base-database/references/sql-function.md

@@ -122,6 +122,8 @@ LIMIT $3
 
 无参数 Function 可以省略 `meta` 或 `meta.params`；归档统一补成 `{"params":[]}`。
 
+SQL 的 `inputSchema` 由 CLI 根据参数顺序与 kind 生成固定长度数组 Schema，不在 SQL meta.json 中手写；TIMESTAMP 与 DURATION 使用毫秒整数。FaaS 则必须显式声明，见[FaaS 开发](faas.md#faas-开发)。
+
 ## 查询约束
 
 只编写只读 `SELECT`，页面输入只能进入位置参数。查询使用以下支持集：
@@ -130,7 +132,7 @@ LIMIT $3
 - 不要用 SQL Function 实现纯常量、纯参数、仅 `FROM (SELECT ...)`、仅 CTE 常量或仅 `UNNEST(...)` 的查询；这些查询没有真实表依赖，会在绑定 Base 的 Validate 或 Execute 阶段失败。与 Base 数据无关的常量在 Page/FaaS 中用代码返回。
 - 查询结构使用显式投影、`WHERE`、`GROUP BY`、`HAVING`、`ORDER BY` 和有界 `LIMIT`；不使用 `SELECT *` 或 `table.*`。`GROUP BY` 最多 5 项。
 - 连接使用 `INNER JOIN`、`LEFT JOIN`、`CROSS JOIN` 或逗号连接。每个 JOIN 的右侧保持为一个表或一个带别名的派生表；`UNNEST` 只能写成逗号连接或 `CROSS JOIN UNNEST(...)`，禁止生成 `LEFT JOIN UNNEST` 或 `INNER JOIN UNNEST`。不要把含 `GROUP BY`、`COUNT`、`SUM`、`AVG`、`MIN` 或 `MAX` 的聚合派生表再 `JOIN` 回主表。单条查询的 JOIN 总数不超过 16。
-- 非递归顶层 CTE 可用；正常应用开发优先用带别名的 `FROM (SELECT ...) AS alias`，不要写递归 CTE 或嵌套 CTE。
+- 非递归顶层 CTE 可用；正常建站优先用带别名的 `FROM (SELECT ...) AS alias`，不要写递归 CTE 或嵌套 CTE。
 - 子查询优先作为带别名的 `FROM` 派生表使用，外层通过派生表输出列名引用结果；不使用投影、`WHERE` 或 `ORDER BY` 表达式里的标量子查询。表达式位置的 `EXISTS`、`ARRAY` 子查询默认也不生成，除非已有实测能通过当前项目发布校验与运行态调用。
 - 列表使用有界 `LIMIT` 和稳定排序；排序值可能重复时最后按 `rec_id` 排序。需求需要任意翻页或全量导出时，不用前端对截断结果伪造完整分页，明确记录当前分页限制。
 - 返回字段逐列列出并使用 `AS snake_case`。
@@ -230,10 +232,21 @@ LIMIT 20
 
 ## 调用与结果
 
-页面和 FaaS 调用都传数组：
+SQL 的业务参数在两条链路上都是数组，但调用入口不同。Page 使用 starter 的 runtime client，不传 projectId：
+
+```ts
+import { invokeDatabaseFunction } from '../lib/database-runtime'
+
+await invokeDatabaseFunction<{ rows: unknown[] }>(
+  'searchTasks',
+  ['%评审%', '待处理', 20],
+)
+```
+
+FaaS handler 内部使用 context，projectId 为当前 应用 的工程常量：
 
 ```ts
-await invokeFunction({
+await context.invokeFunction({
   projectId: PROJECT_ID,
   functionId: 'searchTasks',
   params: ['%评审%', '待处理', 20],
@@ -273,4 +286,4 @@ await invokeFunction({
 
 ## 校验
 
-`base-database-cli deploy` 会统一归档并调用服务端 SQL 校验，以该命令的最终结果为准。Preview 发布后停止，由用户从页面体验真实查询。失败时一次性保留编译错误和 LogID，不更换参数类型或响应 envelope 猜测绕过。
+`base-database-cli deploy` 统一调用服务端 SQL 校验。编译成功仅证明编译阶段；实际读取按[发布与交付](release.md)或用户要求的[专项验收](verification.md)执行。失败时保留具体错误节点和 LogID，按 Catalog、参数与支持边界修复，不猜测响应 envelope 绕过。

package/skills/lark-base-database/references/style-guide.md

@@ -1,12 +1,12 @@
-# 数据库应用风格手册
+# Base Database 工程质量
 
-本文汇总业务系统、数据、后端与前端的稳定设计原则。具体平台命令见 [Skill 主流程](../SKILL.md)，具体 ABI 见 [代码开发手册](development.md)。
+本文汇总业务系统、数据、后端与前端的稳定设计原则。具体平台命令见[工程与环境](workspace.md)，Page 协议见[Page 开发](development.md)，写入协议见[FaaS](faas.md)，视觉设计见[前端设计指导](frontend-design-guide.md)。
 
 ## 业务与数据设计
 
 1. 先明确用户、目标、核心流程、状态变化和失败路径，再设计表与页面。
 2. 具有独立生命周期、权限或统计需求的业务事实使用独立表，并明确数据所有权、归档和追溯要求。
-3. 每张表有可读主字段、稳定业务标识、状态、负责人、时间和必要关系。
+3. 每张表有可读主字段；存在独立生命周期时设计状态，存在责任分配时设计负责人，按业务与审计需求配置时间、标识和关系。
 4. 状态使用受控单选并定义合法转换；关系、金额、日期、人员使用对应 Base 字段。
 5. 页面围绕用户任务组织，不按表机械生成 CRUD。
 6. 每个 operation 定义固定输入、输出、权限、失败语义和影响范围。
@@ -22,7 +22,6 @@
 - 创建、更新、删除、权限校验和状态转换使用 FaaS。
 - FaaS 需要读取时复用固定 SQL Function；页面和 FaaS 不使用 Base records 读 OpenAPI。
 - 公式和 lookup 只承载需要长期显示在 Base 中的派生结果，避免重复保存易漂移数据。
-- 从零搭建应用的示例数据必须进入真实 Base：Preview 发布后通过 `lark-cli base +record-batch-create` 写入，并由展示页使用的 SQL Function 查询；不在 Page、FaaS 或本地存储维护一份平行 mock 数据。
 
 ## FaaS 一致性与调用链
 
@@ -31,13 +30,13 @@
 - 使用满足业务语义的最短远程调用链。写前查询、写后回读和补偿请求只有在能够降低明确且不可接受的业务风险时才加入。
 - 同一张表的多条操作优先使用批量接口；不同表或不同请求之间没有数据依赖时并发执行，只有后一步依赖前一步结果时才串行。
 - 允许弱一致性时，可以复用页面已经取得的非安全敏感状态；身份、权限、租户隔离和其他关键约束必须由服务端可信数据确认。
-- Base 不具备事务、唯一约束或原子条件更新能力时，不用“先查再写”、失败回滚等多次请求模拟强一致性；业务依赖这些能力时记录为不支持或改用具备相应原语的存储。
+- Base 不具备事务、唯一约束或原子条件更新能力时，不用“先查再写”、失败回滚等多次请求模拟强一致性；业务依赖这些能力时记录限制；只有用户明确同意改变后端架构时才采用其他存储。
 - 多路写入必须区分全部成功、部分成功和全部失败。未知结果或非幂等创建不自动整体重试，避免产生重复记录。
 
 ## 后端与安全
 
 - 一个 FaaS Function 对应一个明确业务动作；输入从 `unknown` 校验。
-- 应用 token、table ID、字段名、origin、method、project ID 和 function ID 固定在代码中。
+- 应用 appToken、table ID、字段名、origin、method、project ID 和 function ID 固定在代码中。
 - 按 operation 契约校验身份、权限、字段、状态转换和批量数量；只有底层存在可靠幂等原语时才承诺严格幂等，失败返回稳定业务码与可读信息。
 - 当前访问者的查询权限使用 SQL `CURRENT_USER_ID()`，不相信页面传入的用户 ID。
 - 不记录或返回 token、secret、cookie 和不必要的敏感数据。
@@ -81,8 +80,7 @@
 
 - Preview 的 production build、SQL 编译校验和发布状态由 `base-database-cli deploy` 统一完成。
 - 检查核心 operation 中连续出现的远程 `await`：后一个调用必须真实依赖前一个响应；仅用于取得关联 ID 的串行 SQL 优先合并，输入已确定的无副作用请求必须并发。
-- 记录首屏和核心交互的远程往返次数；每增加一次调用都应有按需加载、权限/失败隔离、结果规模或平台能力方面的明确理由。
+- 首屏和核心交互检查远程往返次数；在实现评审中说明实际依赖和必要拆分，不将内部调用拓扑作为普通用户必读的交付内容。
 - 页面无 starter 文案、无效按钮、伪成功状态和未使用依赖。
-- 从零搭建应用发布 Preview 后先用 `lark-cli` 写入最小示例数据，再调用展示页实际使用的 SQL Function 完成回读；写入或查询失败先修复并重新发布，不能用静态 mock 掩盖。通过后只交付命令返回的顶层 `baseAppUrl` 和体验路径并停止，由用户继续体验；不展示管理后台 URL、旧 Preview URL 或内部静态资源 `staticUrl`。
 
 参考：[React Effect 边界](https://react.dev/learn/you-might-not-need-an-effect)、[Vite 性能](https://vite.dev/guide/performance)。

package/skills/lark-base-database/references/verification.md

@@ -0,0 +1,57 @@
+# 诊断与验收
+
+用户要求排查故障、验证运行态或针对交付结果继续检查时读取。本流程不自动创建资源或发布 Prod；只诊断的请求输出原因与证据，要求修复时继续完成受影响的实现和验证。
+
+## 确定范围
+
+记录目标 应用、环境、工程来源、出错动作和预期结果。优先复用已有工程与日志；资源不明时按[工程与环境](workspace.md)定位。区分构建/SQL 校验、发布、Page 加载、Function 执行、原生配置及权限问题，再读取对应协议。
+
+| 失败阶段 | 首先检查 | 恢复边界 |
+| --- | --- | --- |
+| 命令或认证 | 当前版本、help、身份与具体授权错误 | 按当前 CLI 文档恢复原身份，不自动切 bot |
+| 初始化/恢复 | 已创建资源、宿主来源、配置和本地文件 | 创建结果未知先确认现状，不以重跑 init 掩盖失败 |
+| SQL 校验 | Catalog、参数声明、失败节点与支持集 | 缩小到具体错误，不通过猜参数类型绕过 |
+| 构建 | Page/FaaS 编译错误、依赖与模板调用契约 | 修复实现，不伪造类型让错误协议编译通过 |
+| 发布 | publish ID、真实状态、制品与返回入口 | 使用[发布任务查询](#发布任务查询)确认现状，不盲目启动第二次发布 |
+| Page/Function | HTTP 状态、业务码、输入输出与 invoke LogID | 按 [Page](development.md)、[SQL](sql-function.md)、[FaaS](faas.md) 分层定位；旧工程或 CSRF 失败按[专项检查](#旧工程与-csrf-排查)处理 |
+| 通知与原生配置 | 目标资源完整定义、入口、状态与失败节点 | 按[通知状态](notifications.md#状态与失败处理)保留授权范围 |
+
+## 发布任务查询
+
+部署输出已给出 publish ID，但等待超时或进程中断时，在该 应用 的工程目录执行：
+
+```bash
+base-database-cli deployments status <publish-id>
+base-database-cli deployments status <publish-id> --wait
+```
+
+首条查询一次，`--wait` 轮询至成功或失败/超时。命令也接受第二个位置参数作为工程目录，并读取其中的 `base-database.jsonc`。publish ID 来自本次部署输出或已确认属于该任务的记录，不能以历史回执中的其他 ID 代替。
+
+状态 `0/1` 表示处理中，`10` 表示成功，`20` 表示失败。查询成功不等于发布成功，按 status 判断；成功后使用返回的 `baseAppUrl`。失败、未知状态或再次超时先保存证据，再决定修复，不自动再次 deploy。没有 publish ID 时先检查已有输出和任务记录，不通过创建新发布寻找结果。
+
+状态查询不安装或更新应用能力 Skill，也不返回 `agentGuide`。恢复发布成功后按[安装与恢复](database-capability-skill.md#安装与恢复)处理安装证据；不能把发布成功当作已安装，也不能为补安装重新 deploy。
+
+## 旧工程与 CSRF 排查
+
+1. 先区分浏览器请求、父页面代理与 FaaS 下游失败，排除登录、资源权限和业务参数问题。单独的 403 不足以判定为 CSRF，也不是无条件升级依赖的依据。
+2. 检查恢复工程的 `page/vite.config.ts` 是否从 `@lark-base-open/base-site-js/vite` 引入并配置 `createArgusCsrfPlugin()`，以及当前依赖是否实际导出该函数。插件缺失时按当前 starter 接入；依赖不具备该能力时升级到与 starter 兼容的版本并更新锁文件，不复制插件实现。
+3. 核对构建后的 HTML 是否注入 Argus Runtime，并在可用浏览器中检查脚本是否加载成功。请求缺少 `x-secsdk-csrf-token` 时沿插件配置、依赖能力、构建注入和运行时加载定位；已正确接入却仍失败时保留诊断证据，继续检查加载或平台问题，不反复升级。
+4. 修复配置或依赖后重新构建并发布 Preview，按授权范围复验对应写入路径。没有运行态条件时仅报告已完成的静态修复和待验证项，不宣称问题已解决；Prod 仍需针对新制品确认。
+
+不得手写 `x-secsdk-csrf-token`、复制插件实现、读取或输出用户凭证来绕过检查。
+
+## 验证方法
+
+静态检查、构建、SQL 编译、部署成功分别证明对应阶段，不证明完整业务链路。新建 Base 的常规验证或发布后补齐示例数据，先完整读取并执行[示例数据验收](release.md#从零建站示例数据验收)，其中包含 CLI 写入格式和页面 SQL 回读的实际路径；用户明确要求运行态验收时可以追加本次范围内的只读 SQL 调用和可用浏览器检查。
+
+写入验收先确认目标、测试数据和用户授权，尤其已有 Base、业务通知和不可逆操作。不得仅为测试而创建生产业务记录或外发消息。用户要求的写入验证完成后，清理仍遵守同一资源操作的授权要求。
+
+浏览器不可用、没有必要登录态或 Preview 不支持多角色时，报告未验证项和恢复条件，不索取或输出原始 Cookie/Token。Preview 仅 owner 可访问，不能将 owner 单账号通过作为多角色权限验收；生产账号检查需在已授权的生产任务中进行。
+
+## 重试与失败证据
+
+只在错误可恢复且请求语义允许时重试。创建结果未知先只读检查；部分成功保留已完成结果，只恢复缺失步骤。实现问题应修复后重验，同一错误无新证据时停止重复请求并说明当前判断。
+
+保存环境、应用、阶段、必要的 method/path、publish ID、HTTP/业务码、脱敏摘要与 LogID/Edge request ID；访问 URL 返回 404/5xx 时保存真实 URL 和响应证据。不记录凭证、完整 headers、堆栈或与问题无关的数据，不猜替代域名或回退其他环境。
+
+输出本次检查范围、证据、定位结论、已修复项和未验证项。证据不足时区分推断与已确认事实；按[完成条件](../SKILL.md#完成条件)报告状态。