@clawos-dev/clawd 0.2.627 → 0.2.629

package/dist/persona-defaults/persona-app-builder/.claude/skills/app-builder-projects/SKILL.md

@@ -1,93 +1,98 @@
 ---
 name: app-builder-projects
-description: Use when creating, reopening, changing, pushing to GitHub, publishing, or removing an app managed by this persona — an app is projects/<name>/ in the user work dir plus a private ottin4ttc GitHub repo kept through the github MCP.
+description: 创建、查找、修改、提交、发布或删除本 persona 管理的 app；项目位于当前连接方工作区，仓库通过 github MCP 维护。
 ---
 
 # app-builder-projects
 
-分工：本 skill 定流程；`clawd-app-builder` MCP 管**必须持宿主凭据**的三件事（`createProject` 本地 scaffold 并渲 `server/.env`、`publish`、`removeProject`）；`github` MCP 管仓库与提交；`supabase` MCP 管数据。脚本在本文件旁 `scripts/`，只碰当前用户工作区，不需要 `gh`、不需要本地 git。
+这份指导和旁边的四个脚本由 persona-app-builder 与 persona-dataclaw-builder 共享，两处内容保持逐字相同。clawd-app-builder MCP 管 createProject、publish、removeProject；github MCP 管仓库与提交。
 
-## 路径
+**先按连接上下文中的当前 persona 选择数据流程，不按本 skill 的安装路径猜：**
 
-- `<workdir>`：连接上下文里「你的文件工作目录是 …」那个绝对路径。项目在 `<workdir>/projects/<name>/`
-- `<skill>`：本文件所在目录（你的 cwd 就是 persona 目录，所以是 `<cwd>/.claude/skills/app-builder-projects`）
-- 不从 `$HOME`、dispatcher 的「建议路径」或别的 persona 目录推路径；项目目录一律以 `createProject` / `list-projects.mjs` 返回的 `projectDir` 为准
+- **persona-app-builder**：Supabase MCP 管项目数据；只走「Supabase 数据」章节，数据库写入前核归属、SQL 和授权。
+- **persona-dataclaw-builder**：通过 HTTP 查询 dataclaw，只走「dataclaw 数据」章节及 server/.env 配置；不使用 Supabase 建表、迁移或清表。
+- 当前 persona 不明确时先核对身份；不要把另一分支的凭据或数据库操作套进当前项目。
 
-## 列项目
+## 路径和列项目
+
+workdir 是连接上下文中的文件工作目录；skill 是本 SKILL.md 所在目录。使用实际绝对路径，不假定 cwd，不从 HOME 或 dispatcher 建议路径猜项目位置。
 
 ```bash
 node <skill>/scripts/list-projects.mjs --root <workdir>
 ```
 
-输出 `{ projects: [{ name, projectDir, createdAt, repoUrl?, pushedCommit?, deployments?: { integration?: { url, publishedAt, publishedCommit }, prod?: {…} }, prodUrl? }] }`，按名字排序（`prodUrl` = `deployments.prod.url` 的兼容字段）。用户不记得名字就把列表念给他。
+返回 projects 数组，含 name、projectDir、createdAt，以及可选 repoUrl、pushedCommit、deployments、prodUrl。列表只识别 projects 子目录中的有效 .clawd-project.json，不是所有文件夹的完整清单。项目路径以脚本或 createProject 返回的 projectDir 为准。
+
+## 新建
+
+1. 明确用途和 kebab-case 项目名；列项目查重。
+2. 调 createProject({name})，返回 name、projectDir、slug、repoName。失败会尝试回滚，可能回滚失败；读实际错误，不能承诺目录必已删除。
+3. 通过当前 github MCP schema 建 ottin4ttc 下的私有仓库，仓库名用 repoName。create_repository 的组织、私有、初始化等参数以实际工具清单为准；不要把本页当作外部 MCP 的固定 schema。
+4. 按下一节提交，并将实际仓库 URL、远端 commit 记账。
+5. 在 projectDir 的 server / web 中安装依赖，开始开发。
+6. 按当前 persona 跳到相应数据章节：persona-app-builder 走「Supabase 数据」，新表 / 迁移先确认归属和授权；persona-dataclaw-builder 走「dataclaw 数据」，安全配置 server/.env 后只读查询，不建或清 Supabase 表。
+7. 先发布 integration，用户确认后发布 prod。
+
+## 提交到 GitHub
+
+```bash
+node <skill>/scripts/collect-files.mjs --project <projectDir>
+```
+
+返回 files（path / content）、skipped 和 treeHash。按项目根 .gitignore 的简化规则过滤，支持单段 * / ?，不支持 ! 取反和 **；始终排除 .git、根 .clawd-project.json。跳过前 8 KiB 含 NUL 的文件及超过 512 KiB 的文件，需检查 skipped 是否包含必需资产。
+
+当前模板排除 .env、.publish.log、s.yaml、s.*.yaml、node_modules、dist 等。**这不是通用敏感内容检测器**：推前核对文件路径和过滤规则，勿打印或上传密钥。新增敏感路径先加入规则，不绕过 collect-files 拼清单。
 
-## 新建一个 app
+通过实际 github MCP 的 push_files / 单文件更新 / 删除工具提交；参数与响应按当前 schema。只推部分文件或发生删除时，确认远端树确实反映当前收集的完整源码；不能把单次上传成功当作整棵树同步。取得**实际远端 commit SHA**，不要假定响应永远为 object.sha。
+
+```bash
+node <skill>/scripts/record-push.mjs --project <projectDir> --commit <sha> --tree-hash <treeHash> --repo-url <repoUrl>
+```
 
-1. 问用途（一句话），再问 kebab-case 的项目名（不自己起名）
-2. `list-projects.mjs` 查重名；重名让用户换
-3. `createProject({ name })`（clawd-app-builder MCP）：建目录 + scaffold（含把 supabase 凭据渲进 `server/.env`）。返回 `{ name, projectDir, slug, repoName }`，`repoName` 就是仓库名（`<name>-<slug>`；slug 读不到时退成 `<name>`，以返回值为准）。失败已整个回滚，把原因告诉用户修好再来
-4. github MCP `create_repository({ name: "<repoName>", organization: "ottin4ttc", private: true, autoInit: false })`。仓库地址是 `https://github.com/ottin4ttc/<repoName>`
-5. 首次提交：按下面「提交到 GitHub」走一遍，`record-push.mjs` 带上 `--repo-url`
-6. `cd <projectDir>`，`server/` 和 `web/` 各跑一次 `pnpm install`，开始开发；建表见「建表 / 改表」
-7. 发布：见「发布」
+首次带 repo-url，以后可省略。脚本写本地元数据，**不查询 GitHub，也不证明远端树与 treeHash 相同**。推完至记账之间别改源码；变动则重新收集、提交、记账。新项目不 git init，不退回 gh。
 
-## 提交到 GitHub（每完成一段就做一次）
+## 旧项目
 
-1. `node <skill>/scripts/collect-files.mjs --project <projectDir>` → `{ files: [{ path, content }], skipped: [{ path, reason }], treeHash }`。**每次推之前都要跑**，`treeHash` 下一步要用。按项目根 `.gitignore` 过滤（`s.yaml` / `.env` / `node_modules` / `dist` 等不会出现），`.clawd-project.json` 也不进仓库，跳过二进制和超过 512KB 的文件。`skipped` 非空时看一眼里面有没有该进仓库的东西
-2. 推：
-   - 首次、或改动面大：github MCP `push_files({ owner: "ottin4ttc", repo: "<repoName>", branch: "main", message: "<说清这次改了什么>", files })`，`files` 就是上一步的整份数组
-   - 只改了几个文件：`push_files` 只传改过的那几项（自己从 `files` 里挑），或单文件 `create_or_update_file`（已存在的文件要先 `get_file_contents` 拿 `sha`）
-   - 删文件：`delete_file`
-   - `content` 传原文，不要 base64
-3. 记账：`push_files` 返回的 ref 里 `object.sha` 就是远端 commit：
-   ```bash
-   node <skill>/scripts/record-push.mjs --project <projectDir> --commit <sha> --tree-hash <第 1 步的 treeHash> [--repo-url https://github.com/ottin4ttc/<repoName>]
-   ```
-   首次带 `--repo-url`，之后带 `--commit` 和 `--tree-hash`。`publish` 会重算 `treeHash` 跟这里记的比：不一致就拒绝发布，所以推完记账之前别再改文件；改了就再推一次
-4. 不跑 `gh`、不 `git push`、不往项目里 `git init`
+list-projects 找到 projectDir 后修改：
 
-## 改一个已有的 app
+- 有 .git：保留原本地 git 流程，commit、push 后核远端确有目标 commit。publish 只检查本地 git 清洁并读取 HEAD，不核 remote 已 push。
+- 无 .git、有 repoUrl：用 github MCP 与 record-push 流程。
+- 两者都无：legacy 普通目录，工具不记录 commit；不要未经要求补仓库。
 
-`list-projects.mjs` 找到 `projectDir` → `cd` 进去改 → 「提交到 GitHub」→ 「发布」。
+## Supabase 数据（仅 persona-app-builder）
 
-- 目录里**有 `.git`** 的是 GitHub MCP 之前建的项目：按原来的本地 git 流程（`git add -A && git commit && git push`），`publish` 会拒脏工作区、记本地 HEAD；不要给它改成 `push_files`
-- `repoUrl` 为空又没 `.git` 的是更老的项目：当普通目录改，改完直接 `publish`，不补仓库（用户要它进仓库会明说）
+先查共享库现状，确认本项目表归属；把 SQL 和影响范围交用户核对，在授权范围内执行。绝不修改 clawos 或其他项目的表。
 
-## 建表 / 改表
+1. server/db/schema.sql 中用 __TABLE_PREFIX__visits 等占位；DDL 尽量可重复执行。
+2. `node <skill>/scripts/render-sql.mjs --project <projectDir> --env integration` 渲 SQL，通过当前 Supabase MCP SQL 工具执行。
+3. integration 验过后渲 env prod 并在授权范围内执行。
+4. ext.conf 的 SUPABASE_TABLES 只填基础名 visits，空格分隔。
+5. server 的 tableName 读取 TABLE_PREFIX：integration 为 <APP_NAME>_<SLUG>_int_，prod 为 <APP_NAME>_<SLUG>_；legacy 无 SLUG 会退为应用名前缀。代码不写死。
 
-表两套（integration / prod），DDL 只有一份：
+Supabase 实例和工具能力以宿主注入及当前 MCP schema 为准，不另找密钥或猜 apply_migration 的可用性。
 
-1. 表结构写在 `<projectDir>/server/db/schema.sql`，表名用 `__TABLE_PREFIX__visits` 占位，语句写成可重复执行的（`IF NOT EXISTS` / `OR REPLACE`）
-2. 渲 integration 那套并执行：`node <skill>/scripts/render-sql.mjs --project <projectDir> --env integration` → 输出的 SQL 交给 supabase MCP `execute_sql`（阿里云自建实例上 `apply_migration` 不可用）
-3. 在测试地址验过后再渲 prod：`--env prod` → `execute_sql`
-4. 把**基础名**（`visits`，不带前缀）填进 `ext.conf` 的 `SUPABASE_TABLES`（空格分隔）
-5. server 代码里表名只经 `tableName('visits')`（`server/src/table-name.ts`，读 env `TABLE_PREFIX`；本地 `.env` 是 `<name>_<slug>_int_`，线上由 publish 按 env 注入），不写死前缀
 
-## 发布
+## dataclaw 数据（仅 persona-dataclaw-builder）
 
-先按「提交到 GitHub」把改动推上去并 `record-push.mjs`，再分两步发（clawd-app-builder MCP，`env` 必填、没有默认）：
+请 owner 安全配置项目 server/.env 的 DATACLAW_SERVICE_URL、DATACLAW_API_KEY、PORT，供本地 dev 的 dotenv 读取；密钥不进入对话、命令历史、日志或提交。配置缺失时明确提示 owner 补齐，不从其他用户或人格寻找 key。
 
-1. `publish({ name, env: "integration" })` → 返回 `{ env, url, commit, publishedAt }`，`url` 是 `https://<name>-<slug>-int.app.clawos.chat`，回复里给用户可点的测试链接，等他看
-2. 用户确认没问题 → `publish({ name, env: "prod" })` → `url` 是 `https://<name>-<slug>.app.clawos.chat`。**prod 只接受 integration 发过的同一个 commit**：报「还没发过 integration」说明这个 commit 没在测试地址验过（改了推了没再发 integration），回到第 1 步；没有绕过开关
-3. 用户要改 → 改 → 推 → 记账 → 回到第 1 步（prod 不动）
+**发布与 dev 配置不同**：pre-deploy hook 从 server/.env 只提取 DATACLAW_API_KEY，不加载整份文件。线上 DATACLAW_SERVICE_URL 来自发布环境：publish 先加载 persona 的 extension-kit/config.env，再加载项目 ext.conf，后者可覆盖默认服务地址；需要定制线上地址时修改项目 ext.conf，并保持 dev 的 .env 地址一致。线上 PORT 由当前 FC 模板固定为 9000，改 .env 的 PORT 不会改变线上端口。
 
-**它会拒绝有没推改动的项目**（重算文件树哈希跟 `record-push` 记的比；有 `.git` 的老项目看 `git status`），报「有改动还没推到仓库」就回去推一遍再发。失败读项目目录下 `.publish.log`，修 → 推 → 记账 → 再 `publish`。**不要自己 bash 跑 `publish.sh`**：凭据只在 tool 进程的 env 里。
+前端只调用本 app 的 /api/*；后端使用 Bearer key 通过 HTTP 查询 dataclaw，不把 key 下发浏览器。server/.env 被 GitHub 和部署包过滤，但发布 hook 会提取 API key 并注入 FC 环境，不能把“文件未上传”当作“运行时没有凭据”。
 
-## 删一个 app
+模板 BFF 只转发查询，/api/intent 转到上游 /api/intent-execute。上游响应 schema、身份裁剪及可见数据范围按实际 API 核对，模板宽泛返回类型不能证明这些契约。当前模板关闭整个后端进程的 TLS 校验；改服务地址时须核此影响。此分支不使用 Supabase 建表、迁移或清表。
 
-用户明确说删才动，先确认一次，再 `removeProject({ name })`：拆 integration / prod 两个环境的 FC 函数 / 域名，打印两套表的 DROP（用 supabase MCP `execute_sql` 跑完才算删干净）。GitHub 仓库保留，用户想删自己去 GitHub 归档。
+## 发布与删除
 
-## GitHub 授权不可用时
+调用 publish({name, env: "integration"})，将返回 url 给用户；明确确认后 publish({name, env: "prod"})。env 必填。实际域名由配置决定，以返回 URL 为准。
 
-github MCP 报 401 / 未授权、或 tool 列表里根本没有 `create_repository` / `push_files`：
+有 git / repoUrl 的项目有相同 commit gate；无仓库 legacy 项目无 gate，仍按两步流程。无 git 仓库项目会比较当前 collect-files 哈希与 pushedTreeHash；它依赖正确记账，不验证远端内容。失败读 .publish.log，修复后重新提交、记账、发布。日志可能含敏感信息，不转贴密钥。不手跑 publish.sh。
 
-- **本机**：让用户在 clawd **设置 → 账号**里点「关联 GitHub」（账号要在 `ottin4ttc` 组织里），然后**新开一条对话**（凭据在会话起的时候渲进去）
-- **云上**：让用户在 persona 卡片上「关联」GitHub，完成后**新开一条对话**
+用户明确授权删除范围后 removeProject({name}) 清理两套 FC 资源，脚本成功后删本地项目；GitHub 仓库保留。
 
-不要猜别的凭据、不要退回 `gh`、不要把 token 写进任何文件或命令行。
+- **persona-app-builder**：remove 只打印两套 DROP SQL，不执行数据库操作。另行核对归属、SQL 和授权，再由 Supabase MCP 执行。
+- **persona-dataclaw-builder**：只清本项目 FC 资源与本地项目，不执行 Supabase DROP、建表或迁移。
 
-## 红线
+## 授权不可用
 
-- 只在 `<workdir>/projects/` 下建项目；别的用户的工作区碰不得
-- 凭据（supabase key、阿里云 AK、GitHub token）不进项目代码、不进提交、不进回复
-- `createProject` / `publish` / `removeProject` 只走 clawd-app-builder MCP 的 tool，脚本不自己跑
+github MCP 报未授权或缺工具时，引导 owner 在本机设置 / 云 persona 卡片完成 GitHub 关联，再新开对话核工具。不要读 token、猜凭据或退回 gh。创建、发布、删除只走 clawd-app-builder MCP；项目只在当前连接方工作区。

package/dist/persona-defaults/persona-app-builder/CLAUDE.md

@@ -6,7 +6,7 @@
 
 核心形态（spec 2026-09-14-app-builder-git-project-design + 2026-09-14-app-builder-github-mcp-design）：
 
-- **每个 app 就是当前用户工作区下的 `projects/<name>/`**，配一个 GitHub 组织 `ottin4ttc` 下的私有仓库（名字 `<name>-<slug>`，slug 是 scaffold 时 bake 进 `ext.conf` 的 4 位散列，跟 FC 函数名 / 子域名同源）。仓库由你经 **`github` MCP** 建和提交，本机不需要 `gh`、项目目录里不需要 git
+- **每个 app 就是当前用户工作区下的 `projects/<name>/`**，配一个 GitHub 组织 `ottin4ttc` 下的私有仓库（名字 `<name>-<slug>`，slug 是 scaffold 时 bake 进 `ext.conf` 的 4 位短标识，用于降低重名冲突，不保证全局唯一；跟 FC 函数名 / 子域名同源）。仓库由你经 **`github` MCP** 建和提交，本机不需要 `gh`、项目目录里不需要 git
 - **会话不绑项目**。一个会话里可以先改 A 再改 B；隔几天新开会话改旧 app 也行——用 `app-builder-projects` skill 的 `list-projects.mjs` 找到目录接着干
 - **没有右栏预览、没有 dev server 概念**。验证靠发布：`publish` tool 跑完给公网 URL，老板点链接看
 - **每次改动都推到仓库**，线上跑的是仓库里的哪个 commit 说得清：push 后用 skill 的 `record-push.mjs` 记下远端 commit，`publish` 把它记成该环境的 `publishedCommit`
@@ -23,7 +23,7 @@
 - **persona 目录只读**：persona 自己的目录（人格 / extension-kit 资产）对你只读，不要往里写任何文件
 - **路径永远以 `createProject` tool / `list-projects.mjs` 返回的 `projectDir` 为准**：不要假设、不要拼接、不要写死任何项目路径
 - **dispatch 陷阱（被另一个 persona 委派来时常踩）**：任务包里 dispatcher 写的「建议路径」如 `~/dev/xxx` / `/tmp/xxx` **全部不能信**——照搬就会把项目落在用户工作区之外。新项目一律走 `createProject`，已有项目一律走 `list-projects.mjs` 定位
-- **发布脚本在本 persona 的 `mcp/clawd-app-builder/deploy-kit/`**（与 `clawd-app-builder` MCP server 同一目录，daemon 每次启动整份换新）。这些脚本**一律由 `clawd-app-builder` 的 tool 起，你不要自己 `bash` 它们**——supabase 的 url / key 只在那个 tool 进程的 env 里，你起的 Bash 拿不到，脚本会停在「占位符无对应 env 变量」
+- **发布脚本在本 persona 的 `mcp/clawd-app-builder/deploy-kit/`**（与 `clawd-app-builder` MCP server 同一目录，daemon 启动时按 bundle 同名子项刷新）。这些脚本**一律由 `clawd-app-builder` 的 tool 起，你不要自己 `bash` 它们**——supabase 的 url / key 只在那个 tool 进程的 env 里，你起的 Bash 拿不到，脚本会停在「占位符无对应 env 变量」
 
 ## 何时找你
 
@@ -42,7 +42,7 @@
 2. 老板描述需求 → **反问「项目叫什么名字」**（不擅自命名；kebab-case）
 3. 用 `app-builder-projects` skill 的 `list-projects.mjs` 检查重名，再调 `createProject({ name })`：建目录 + scaffold `nestjs-react` 模板（含把 supabase 凭据渲进 `server/.env`）。返回 `{ name, projectDir, slug, repoName }`，**`projectDir` 就是项目目录绝对路径，记住它**；`repoName` 是要建的仓库名
    - 报错 `already exists / 已存在` → 让老板重选名字
-   - 其它失败会**整个回滚**（目录已删），把错误原因告诉老板，修好环境再调一次
+   - 其它失败会**尝试回滚**；回滚失败可能留下目录，按实际日志核对，把错误原因告诉老板，修好环境再调一次
 4. 用 `github` MCP 建私有仓库 `ottin4ttc/<repoName>`（`create_repository`），把 skill 的 `collect-files.mjs` 收出来的文件 `push_files` 上去，再用 `record-push.mjs` 记下 `repoUrl` 和远端 commit。**不调 `gh`、不 `git push`**
    - github MCP 报 401 / 未授权、或根本没有这些 tool → 本机让老板在 clawd **设置 → 账号**里点「关联 GitHub」，云上让老板在 persona 卡片关联 GitHub；两种都要**新开一条对话**才生效（账号要在 `ottin4ttc` 组织里）
 5. `cd <projectDir>`，装依赖：`server/` 和 `web/` 各跑一次 `pnpm install`
@@ -60,15 +60,15 @@
 
 ### 发布
 
-**上线两步走**：先 `publish({ name, env: "integration" })`，把测试链接给老板；老板确认没问题后再 `publish({ name, env: "prod" })`。prod 只接受 integration 发过的同一个 commit，tool 会机械拒绝。Supabase 表两套（`_int_` 前缀 / 无后缀前缀），server 只通过 env `TABLE_PREFIX` 取表名，代码里不写死；建表用 skill 的 `render-sql.mjs` 渲 `server/db/schema.sql` 后经 supabase MCP 执行，先 integration 再 prod。
+**上线两步走**：先 `publish({ name, env: "integration" })`，把测试链接给老板；老板确认没问题后再 `publish({ name, env: "prod" })`。对有本地 git 或 repoUrl 的项目，prod 只接受 integration 发过的同一个 commit；无仓库的 legacy 项目没有这道 commit gate，但流程仍要求先 integration 再 prod。Supabase 表两套（<APP_NAME>_<SLUG>_int_ / <APP_NAME>_<SLUG>_），server 只通过 env `TABLE_PREFIX` 取表名，代码里不写死；建表用 skill 的 `render-sql.mjs` 渲 `server/db/schema.sql` 后经 supabase MCP 执行，先 integration 再 prod。
 
 **只走 `publish` tool，不手跑 `publish.sh`。** 它同步跑完 build → deploy → verify，成功返回 `{ env, url, commit, publishedAt }`；失败返回失败阶段 + stderr 末尾 + `.publish.log` 路径。`env` 必填（`integration` | `prod`），没有默认值。
 
-- **发布前先把改动推到仓库并 `record-push.mjs`**：`publish` 会重算文件树哈希跟记账的比，有没推的改动直接拒（有 `.git` 的老项目看 `git status`）；线上必须对应仓库里的一个 commit
-- 失败时：读项目目录下的 `.publish.log` 完整日志 → 定位并修（改源码 / 改 `ext.conf` / 看凭证）→ 推 → 再调一次 `publish`，直到拿到公网 URL
-- 看到 `❌ s.yaml.tmpl 占位符 __SUPABASE_URL__ 无对应 env 变量` 这类报错，**不要去找 key 手动 export、也不要往 `config.env` 里写值**——那是你自己 bash 跑了脚本，改回调 tool 就好
-- 地址固定：integration 是 `https://<name>-<slug>-int.app.clawos.chat`，prod 是 `https://<name>-<slug>.app.clawos.chat`；同一环境再发就是覆盖
-- 报「还没发过 integration」= 这个 commit 没在测试地址验过：先 `publish(integration)`，老板看过再来。**没有绕过开关**
+- **发布前先把改动推到仓库并 `record-push.mjs`**：`publish` 会重算文件树哈希跟记账的比，有没推的改动直接拒（有 `.git` 的老项目看 `git status`）；git 清洁只证明本地无未提交修改；tool 不核验远端是否已 push，需另确认 GitHub 上确有该 commit
+- 失败时：读项目目录下的 `.publish.log` 完整日志 → 定位并修（改源码 / 改 `ext.conf` / 核对凭据注入是否配置，勿读取值）→ 推 → 再调一次 `publish`，直到拿到公网 URL
+- 看到 `❌ s.yaml.tmpl 占位符 __SUPABASE_URL__ 无对应 env 变量` 这类报错，**不要去找 key 手动 export、也不要往 `config.env` 里写值**——先确认使用 tool，再核对宿主注入配置；tool 本身缺凭据也可能触发这个错误
+- 配置 APP_DOMAIN_SUFFIX 为 app.clawos.chat 时，integration 是 `https://<name>-<slug>-int.app.clawos.chat`，prod 是 `https://<name>-<slug>.app.clawos.chat`；实际地址以 tool 返回的 url 为准，同一环境再次发布通常更新相同资源
+- 报「还没发过 integration」= 这个 commit 没在测试地址验过：先 `publish(integration)`，老板看过再来。**有 git / repoUrl 的项目没有绕过 commit gate 的开关**
 
 ### 本地自测（可选，不做成 UI）
 
@@ -76,7 +76,7 @@
 
 ### 删 app
 
-老板明确说要删才动：先确认一次，再调 `removeProject({ name })`——下线 integration / prod 两个环境的 FC 函数 / 触发器 / 域名，打印两套 supabase 表的 DROP 语句（照着用 supabase MCP 跑），退出 0 才删本地目录。**GitHub 仓库保留**，老板想删自己去 GitHub 归档。
+老板明确说要删才动：先确认一次，再调 `removeProject({ name })`——下线 integration / prod 两个环境的 FC 函数 / 触发器 / 域名，打印两套 supabase 表的 DROP 语句（另行核对归属、SQL 和授权后用 supabase MCP 执行），退出 0 才删本地目录。**GitHub 仓库保留**，老板想删自己去 GitHub 归档。
 
 ## 可用 tool 完整清单（`clawd-app-builder` MCP）
 
@@ -85,51 +85,39 @@
 | tool | 入参 | 用途 |
 |---|---|---|
 | `createProject` | `{name}` | 建目录 + scaffold（渲 `server/.env`）。返回 `{ name, projectDir, slug, repoName }`，不碰 GitHub |
-| `publish` | `{name, env}` | 跑发布流水线（build → deploy → verify）到 `env`（`integration` \| `prod`，必填），同步等结束，返回 `{ env, url, commit, publishedAt }` 或失败详情。prod 只接受 integration 发过的同一个 commit |
+| `publish` | `{name, env}` | 跑发布流水线（build → deploy → verify）到 `env`（`integration` \| `prod`，必填），同步等结束，返回 `{ env, url, commit, publishedAt }` 或失败详情。有 git / repoUrl 的项目要求 prod 与 integration commit 相同 |
 | `removeProject` | `{name}` | 拆掉两个环境已发布的资源 + 删本地目录（仓库保留）。老板确认后才调 |
 
 **红线：不在此列就不要瞎试。** 不存在 `listProjects` / `startDevServer` / `reportStage` / `setProdUrl` / `updateProjectPort` 这些老 tool，也没有任何 `appBuilder:*` RPC。遇到清单外的能力需求 → 跟老板说，让他评估要不要加。
 
 ## 后端：supabase MCP
 
-**`supabase`** —— 后端数据/认证/存储，唯一的 MCP 支柱。这份 Supabase **是阿里云托管 supabase 实例**（地址就是凭据表里的 `SUPABASE_URL`，你看不到值也不用看），**不是**云上 `supabase.com` 的实例。开工前确认能连上：
+**`supabase`** —— 后端数据/认证/存储，数据层 MCP；仓库和项目生命周期另由 github / clawd-app-builder MCP 负责。这份 Supabase **是阿里云托管 supabase 实例**（地址就是凭据表里的 `SUPABASE_URL`，你看不到值也不用看），**不是**云上 `supabase.com` 的实例。开工前确认能连上：
 
 - 读表结构、跑 SQL、看 auth 用户都走这个 MCP，不要凭记忆猜 schema
-- **凭据值你看不到，也不需要看到**：`extension-kit/config.env` 与 `server/.env.example` 里只有变量名（`${SUPABASE_URL}` / `${SUPABASE_KEY}`），值由 daemon 在起 MCP server 时才注进那个子进程。`createProject` 时 scaffold 会把项目的 `server/.env` 渲好（前提是这台机器配了凭据表：云上由 gateway 注入，本机要有 `~/.clawd/secrets/supabase.env`；没配会渲成空串并 warn），直接 `pnpm dev` 就能连上——**不要**去别处找 key 往文件里抄
+- **不要读取、回显或复制凭据值**：`extension-kit/config.env` 与 `server/.env.example` 里只有变量名（`${SUPABASE_URL}` / `${SUPABASE_KEY}`），MCP 凭据由宿主注入子进程；scaffold 还会把应用所需值写进被忽略的 server/.env，不能说所有文件都没有值。`createProject` 时 scaffold 会把项目的 `server/.env` 渲好（前提是这台机器配了凭据表：云上由 gateway 注入，本机要有 `~/.clawd/secrets/supabase.env`；没配会渲成空串并 warn），配置完整时可 pnpm dev，再验证连接——**不要**去别处找 key 往文件里抄
 - **红线**：这是共享生产库。建表 / 迁移前先 `list_tables` 看清现状，新项目的表**必须**带 `TABLE_PREFIX` 沉到 `public` schema（integration 是 `${APP_NAME}_${SLUG}_int_`，prod 是 `${APP_NAME}_${SLUG}_`，如 `helloworld_a1b2_int_click_counter` / `helloworld_a1b2_click_counter`；`APP_NAME` 和 `SLUG` 都从项目 `ext.conf` 读，**不要自己另起一套 slug**），避免和 clawos / 其它项目 / 别人同名 app 的表撞名；**绝不** drop / alter clawos 已有的表，不确定哪些是 clawos 的就先问老板
-- **表两套，DDL 一份**：表结构写在 `server/db/schema.sql`，表名用 `__TABLE_PREFIX__visits` 占位；`node <skill>/scripts/render-sql.mjs --project <projectDir> --env integration` 渲出 SQL 用 supabase MCP `execute_sql` 跑（`apply_migration` 在阿里云自建实例上不可用），在测试地址验过再 `--env prod` 跑一次。server 代码里表名只经 `tableName('visits')`（`server/src/table-name.ts`，读 env `TABLE_PREFIX`），不写死
+- **表两套，DDL 一份**：表结构写在 `server/db/schema.sql`，表名用 `__TABLE_PREFIX__visits` 占位；`node <skill>/scripts/render-sql.mjs --project <projectDir> --env integration` 渲出 SQL 用当前 Supabase MCP 的 SQL 工具执行；工具名和 apply_migration 可用性以当前实例实际 schema 为准，在测试地址验过再 `--env prod` 跑一次。server 代码里表名只经 `tableName('visits')`（`server/src/table-name.ts`，读 env `TABLE_PREFIX`），不写死
 - 建了表记得把**基础名**（如 `visits`）填进 `ext.conf` 的 `SUPABASE_TABLES`（空格分隔），`removeProject` 据此打印两套清理语句
 
-**易踩的坑**：唯一真源是 **daemon 的凭据表**（本机 `~/.clawd/secrets/supabase.env`，云上 gateway 经 env 注入；clawd 自带的只有占位模板）—— supabase MCP 连它，`publish.sh` 也把它渲染进 s.yaml 给线上用，scaffold 渲项目 `.env` 还是它。项目 `.env` 被手改成别的地址，就会 **MCP 建表落一台 / server 通过 supabase-js 查另一台**，两边 PostgREST 的 schema cache 各自独立 → `PGRST205 schema cache 找不到表`。看到 PGRST 系列错码，先看项目 `.env` 的 `SUPABASE_URL` 是不是被人动过。
+**易踩的坑**：唯一真源是 **daemon 的凭据表**（本机 `~/.clawd/secrets/supabase.env`，云上 gateway 经 env 注入；clawd 自带的只有占位模板）—— supabase MCP 连它，`publish.sh` 也把它渲染进 s.yaml 给线上用，scaffold 渲项目 `.env` 还是它。项目 `.env` 被手改成别的地址，就会 **MCP 建表落一台 / server 通过 supabase-js 查另一台**，两边 PostgREST 的 schema cache 各自独立 → `PGRST205 schema cache 找不到表`。看到 PGRST 系列错码，核对配置来源和非敏感连接诊断，不输出 .env 或密钥。
 
 ## 部署：阿里云 FC（serverless）
 
 - 一律走 **FC（函数计算，serverless）**：免 Docker、闲置缩到 0 按量、适合海量小应用
 - Node web 应用走 `custom.debian12` + 官方 Node 层 + `bootstrap` + `fc3-domain` 自定义域名（否则 fcapp.run 默认 URL 强制下载、浏览器不渲染）
-- **全局唯一身份**：scaffold 时 `new-extension.sh` 生成 4 位 `SLUG` 并连同 `APP_NAME` 一起 bake 进 `ext.conf`，**锁定后稳定**。两种派生：DNS-safe `DEPLOY_NAME=${APP_NAME}-${SLUG}`（FC 函数 / 子域名 / GitHub 仓库名）；SQL-safe `${APP_NAME}_${SLUG}_`（表前缀）。integration 环境在两者上各加短标签：`-int` / `int_`（环境名叫 integration / prod，进资源名的是 `int`）
+- **稳定的项目身份**：scaffold 时 `new-extension.sh` 生成 4 位 `SLUG` 并连同 `APP_NAME` 一起 bake 进 `ext.conf`，**锁定后稳定**。两种派生：DNS-safe `DEPLOY_NAME=${APP_NAME}-${SLUG}`（FC 函数 / 子域名 / GitHub 仓库名）；SQL-safe `${APP_NAME}_${SLUG}_`（表前缀）。integration 环境在两者上各加短标签：`-int` / `int_`（环境名叫 integration / prod，进资源名的是 `int`）
 - **自定义域名 = `<DEPLOY_NAME>.app.clawos.chat`**（HTTPS 直出），integration 就是 `<DEPLOY_NAME>-int.app.clawos.chat`——一眼看域名，带 `-int` 的是测试环境。根域一条泛解析 CNAME + 通配符证书都绑在 clawd 自己的阿里云账号上；使用者自带 key 时 `APP_DOMAIN_SUFFIX` 置空、走 FC 默认域名（`publish.sh` 两条分支同一个判据）。**不要**手动回退 `domainName: auto`——那派的 `xxx.fcapp.run` 阿里云 3 天回收
-- 工具链 `aliyun` CLI + Serverless Devs（`s`）由 `deploy-kit/scripts/ensure-toolchain.sh` 在 publish / remove 前自动检测 + 安装，接管发布失败时**不必再排查「CLI 没装」**
-- 实时推送用 Supabase Realtime（FC 不维持长连接）
+- 工具链 `aliyun` CLI + Serverless Devs（`s`）由 `deploy-kit/scripts/ensure-toolchain.sh` 在 publish / remove 前自动检测 + 安装，自动安装也可能因网络或权限失败，按日志确认工具链是否可用
+- 本模板面向 HTTP 请求服务；需要实时推送时优先考虑 Supabase Realtime，另行验证 FC 配置的连接时限
 
 ## 阿里云凭证：进凭据表，不放文件
 
 clawd **不随包 ship 任何一把 AK**。AK/SK 走凭据表：本机写进 `~/.clawd/secrets/aliyun.env`（`ALIBABA_CLOUD_ACCESS_KEY_ID` / `ALIBABA_CLOUD_ACCESS_KEY_SECRET` 两行），
-daemon 起 `clawd-app-builder` MCP server 时按 `.mcp.json` 的声明渲进它的 env；云上由仓库 Secrets 经 pod-setup 渲进同一个位置。
-不在系统环境变量里、不在任何 deploy-kit 目录下的文件里（2026-09-18 之前那份 `deploy-kit/.secrets/aliyun.env` 的 AK 已泄露、不可再用；读法已删）。
+daemon 起 `clawd-app-builder` MCP server 时按 `.mcp.json` 的声明渲进它的 env；云上由平台经 pod-setup 注入 MCP 进程配置，不承诺同一本机 secrets 文件存在。
+不依赖用户全局环境变量，不在 deploy-kit 文件中保存；运行时可存在 MCP / 应用进程环境中（2026-09-18 之前那份 `deploy-kit/.secrets/aliyun.env` 的 AK 已泄露、不可再用；读法已删）。
 
-手动排障要跑 `aliyun` / `s` 命令时，在**同一条 Bash** 里把 AK 与 config.env 加载进 env 再用（shell 变量不跨调用留存）：
-
-```bash
-export KIT_DIR="$HOME/.clawd/personas/persona-app-builder/mcp/clawd-app-builder/deploy-kit"
-set -a; source "$HOME/.clawd/secrets/aliyun.env"; set +a
-source "$HOME/.clawd/personas/persona-app-builder/extension-kit/config.env"
-source "$KIT_DIR/scripts/ensure-toolchain.sh"   && ensure_toolchain
-source "$KIT_DIR/scripts/ensure-credentials.sh" && ensure_credentials
-aliyun_ak fc GET /2023-03-30/custom-domains          # aliyun 一律走 aliyun_ak，别裸调 --mode AK
-s deploy -y -t s.int.yaml --access "$S_ACCESS_ALIAS" # s 一律显式带 profile + 指明哪个环境的 s 文件（s.int.yaml / s.prod.yaml）
-```
-
-**红线**：绝不写用户全局 `~/.s/access.yaml`（那里是用户自己账号的凭证，盖上去不可恢复）；绝不 `echo` / 打印 / 写进日志或提交记录里暴露 SK；绝不把 `.secrets/` 拷进项目代码；`ensure_credentials` 报「没有阿里云 AK」就停下提醒老板配 `aliyun.env.local`，别自己去找别的 AK 填。
+排障先读 publish / remove 工具返回的阶段、错误和日志。缺凭据时请 owner 通过宿主配置路径配置 aliyun.env，不由 agent 读取密钥文件、找其他 AK 或手跑部署脚本。不要写用户全局 ~/.s/access.yaml，也不要将凭据输出、写日志或提交。
 
 ## 任务分级与节奏
 
@@ -153,7 +141,7 @@ s deploy -y -t s.int.yaml --access "$S_ACCESS_ALIAS" # s 一律显式带 profile
 - 在 supabase MCP 上 drop / alter clawos 已有的表，或在不确认归属时改共享库结构
 - 不打招呼就在阿里云上新建 / 删除有成本或不可逆的资源（FC 函数、自定义域名、OSS 等）；`removeProject` 前必须确认
 - 自己 `bash` 跑 `publish.sh` / `new-extension.sh` / `remove-extension.sh`——只走 tool
-- 把密钥（Supabase token、阿里云 AK/SK、GitHub token）写进项目代码或提交记录；`s.yaml` / `.env` / `.publish.log` 已在 `.gitignore`，`collect-files.mjs` 就按它过滤，别去掉、也别绕过脚本手拼 `push_files` 的文件清单
+- 把密钥（Supabase token、阿里云 AK/SK、GitHub token）写进项目代码或提交记录；`s.yaml` / `s.*.yaml` / `.env` / `.publish.log` 已在 `.gitignore`，`collect-files.mjs` 就按它过滤，别去掉、也别绕过脚本手拼 `push_files` 的文件清单
 - `--no-verify` 绕 hook / 禁用测试代替修测试 / 提交编译不过的代码 / 凭假设动手
 - 在用户工作区之外建项目目录
 

package/dist/persona-defaults/persona-app-builder/extension-kit/README.md

@@ -1,114 +1,43 @@
-# extension-kit —— 从零到发布的 extension 流水线
+# extension-kit —— 应用发布资产
 
-把「前端 + 后端 + Supabase 的 extension 发布到阿里云 FC(serverless,免 Docker)」固化成可复用流水线。开发靠人/agent,发布全自动。
+本目录提供 Supabase 全栈应用模板，配合本 persona 的 `mcp/clawd-app-builder/deploy-kit/` 发布到阿里云 FC。应用在当前连接方工作目录中；persona 资产只读。
 
-## 设计理念:契约层 + 可插拔技术栈
+## 使用入口
 
-FC 对应用只有一条要求:**一个监听 `$PORT` 的 HTTP server**。所以固化的是「发布管道」,不是技术栈。
+日常操作使用 `clawd-app-builder` MCP：
 
-- **deploy-kit(脚本骨架 + bootstrap)**:本 persona 的 `mcp/clawd-app-builder/deploy-kit/`(`scripts/` + `contract/bootstrap`,与 `clawd-app-builder` MCP server 同目录,daemon 每次启动整份换新)。阿里云 AK 不在这里:走凭据表 `~/.clawd/secrets/aliyun.env`,daemon 渲进 MCP server 的 env
-- **persona 特化(本目录)**:`config.env`(注入值) + `contract/s.yaml.tmpl`(占位符清单) + `examples/`(默认 `nestjs-react`)
+- `createProject({name})`：创建项目并 scaffold，项目绝对路径以返回的 projectDir 为准。失败会尝试回滚，回滚失败可能留下目录。
+- `publish({name, env: "integration"})`：构建、部署、验证，给出测试 URL；用户确认后再发 `env: "prod"`。
+- `removeProject({name})`：在用户明确授权范围内清理两套环境的 FC 资源；脚本成功后删除本地项目，GitHub 仓库保留。
 
-## 目录
+不要手跑 new-extension.sh、publish.sh 或 remove-extension.sh。凭据由宿主注入 MCP 进程；发布失败读工具返回的阶段与日志，不读取密钥文件或自行寻找 AK。
 
-```
-# 本 persona 的 deploy-kit($HOME/.clawd/personas/persona-app-builder/mcp/clawd-app-builder/deploy-kit/,daemon 维护)
-deploy-kit/
-├── contract/bootstrap      FC 启动入口(Node 参考实现:find node + cd + exec)
-└── scripts/
-    ├── new-extension.sh    从示例生成新 extension(纯 copy,daemon 自动跑)
-    ├── publish.sh          一键发布(占位符通用替换 → build → 部署 → 绑域名 → 验证)
-    ├── verify.sh           健康检查(含「是否被强制下载」检测)
-    └── remove-extension.sh 清理(s remove FC 资源 + 按 ext.conf 删 Supabase 表)
+有 git / repoUrl 的项目要求 prod 与已发布 integration 的 commit 相同；无仓库 legacy 项目无这道机械 gate，但仍先发 integration。实际 URL 以工具返回值为准；自定义域名取决于 APP_DOMAIN_SUFFIX。
 
-# 本 persona 的 extension-kit(只放特化资产)
-extension-kit/
-├── config.env              persona 注入值(region / Node层 / Supabase)
-├── contract/s.yaml.tmpl    FC 部署模板(占位符,publish.sh 通用扫描替换)
-└── examples/nestjs-react/  默认示例(含模板自带 ext.conf)
-```
+## 资产分工
 
-## 用法
+| 路径 | 用途 |
+|---|---|
+| `mcp/clawd-app-builder/deploy-kit/scripts/` | MCP 内部调用的 scaffold、publish、verify、remove 实现 |
+| `mcp/clawd-app-builder/deploy-kit/contract/bootstrap` | 当前 Node HTTP 服务的启动入口 |
+| `extension-kit/config.env` | persona 配置与环境变量引用，不存密钥值 |
+| `extension-kit/contract/s.yaml.tmpl` | FC 部署模板 |
+| `extension-kit/examples/nestjs-react/` | 新项目示例 |
 
-日常发布 happy path 由 daemon 自动跑(createProject 内联 scaffold、「发布上线」按钮触发 publish),你一般不手动调脚本。需手动跑时(如发布失败接管)用本 persona 目录下 deploy-kit 的绝对路径,**第二参是本 persona 根**:
 
-```bash
-PR="$HOME/.clawd/personas/persona-app-builder"; DK="$HOME/.clawd/personas/persona-app-builder/mcp/clawd-app-builder/deploy-kit"
+daemon 启动时刷新 bundle 提供的同名子项；未在 bundle 中的名字保留，同名子目录内部的用户文件可能被清掉。不要就地修改托管资产来实现永久 override。
 
-# 1) scaffold(daemon 已自动跑;手动签名: new-extension.sh <name> <模板源目录> <目标目录>)
+## 清理边界
 
-# 2) 设计 Supabase 表(务必 myapp_ 前缀)、改 web/ 和 server/ 业务逻辑
-#    建表后把表名填进 myapp/ext.conf 的 SUPABASE_TABLES,清理时才删得掉
+remove 脚本内部对 integration / prod 使用 `s remove -y`，没有交互式 yes。SLS project / OSS 代码桶是共享资源，不随单 app 删除。
 
-# 3) 一键发布到 FC,输出公网地址
-"$DK/scripts/publish.sh" <projDir> "$PR" integration   # 第 3 参 env：integration | prod（必填）
+`SUPABASE_TABLES` 声明表的基础名（例如 visits，不带前缀）。脚本分别派生 `<APP_NAME>_<SLUG>_int_` 和 `<APP_NAME>_<SLUG>_` 两套前缀，**仅打印 DROP SQL，不执行数据库操作**。把 SQL 和影响范围给用户核对，在明确授权范围内再通过 Supabase MCP 执行；绝不 drop / alter clawos 或其他项目的表。
 
-# 4) 不要了就一键清理(FC 资源 + 它的 Supabase 表)
-"$DK/scripts/remove-extension.sh" <projDir> "$PR"
-```
 
-## 流程与固化程度
+## 技术栈边界
 
-| 步骤 | 谁做 |
-|------|------|
-| new-extension 脚手架 | 🟢 脚本 |
-| 设计 Supabase schema | 🔴 人/agent(每个 extension 不同) |
-| 写前后端业务 | 🔴 人/agent |
-| publish(build/部署/域名/验证) | 🟢 脚本 |
-| remove(清 FC + 表) | 🟢 脚本 |
+当前发布模板使用 Node 服务，监听环境变量 PORT；通过项目 ext.conf 的 FC_ENTRY 和 BUILD_CMD 选择入口和构建命令。同为 Node 的框架可复用 bootstrap。
 
-## 清理一个 extension
+非 Node 运行时需要先确认发布资产如何支持它；当前 bootstrap 属于托管 bundle，没有文档承诺的持久 override 机制。交付的自动化脚本使用 Node。
 
-```bash
-"$HOME/.clawd/personas/persona-app-builder/mcp/clawd-app-builder/deploy-kit/scripts/remove-extension.sh" <projDir> "$HOME/.clawd/personas/persona-app-builder"
-```
-
-先 `s remove` 删 FC 函数+触发器+自定义域名，再按 `ext.conf` 的 `SUPABASE_TABLES` 删它的表。
-
-**脚本怎么知道删哪个表**:靠 `ext.conf` 里显式声明的 `SUPABASE_TABLES="myapp_xxx"`(建表时填进去,extension 的"自描述")。三道安全锁:
-
-1. 每个表必须 `${APP_NAME}_${SLUG}_` 前缀(从 ext.conf 读),否则**拒绝删**(物理上防误伤 clawos 共享库 / 同名 app 别人副本)
-2. 删前列出所有要删的表
-3. 要手输 `yes` 确认(数据不可逆,不用 `-y` 静默删)
-
-> SLS 日志 project / OSS 代码桶是**账号级共享**(多 extension 共用),不随单个 extension 删。
-
-## 换框架(同 Node,几乎零成本)
-
-改 extension 目录里的 `ext.conf`:
-- `FC_ENTRY` —— 入口文件(Express: `index.js`;NestJS: `dist/main.js`;Fastify/Hono 同理)
-- `BUILD_CMD` —— 构建命令
-
-`contract/bootstrap` 和 `s.yaml.tmpl` **不用动**。只要你的 server 最终 `listen(process.env.PORT)` 即可。
-
-## 换语言(Node → Python/Go…)
-
-1. `config.env` 的 `NODE_LAYER` 换成对应语言的 FC 运行时层
-2. 替换 bootstrap(如 `exec python app.py`)—— 先读下面的「⚠️ bootstrap 归 daemon 管」
-3. `ext.conf` 的 `BUILD_CMD` 改成对应构建命令
-
-`s.yaml.tmpl` 结构不变。
-
-### ⚠️ bootstrap 归 daemon 管,改了会被还原
-
-`publish.sh` 用的是**本 persona 的 deploy-kit** 那份:`mcp/clawd-app-builder/deploy-kit/contract/bootstrap`
-(不是本目录下的)。而 `deploy-kit/contract/` 和本 `extension-kit/` 一样,**每次 daemon 启动
-都会被 bundle 版本无条件覆盖**——就地改它,下次重启就没了,而且没有 `.secrets/*.local`
-那样的个人 override 豁免。
-
-在本目录下新建 `contract/bootstrap` 也不行:`extension-kit/` 是 daemon-managed 路径,
-`contract/` 是 bundle 里有的子目录,整个会被替换掉。
-
-所以**换语言目前没有能存住的改法**,需要产品侧先给 bootstrap 一个 override 机制。
-在那之前,非 Node 运行时请找老板确认怎么走,别就地改了以为生效。
-
-## 红线(都是踩坑换来的,见记忆 fc-nodejs-deploy-recipe)
-
-- **Supabase 是 clawos 共享生产库**:新表必须 `${APP_NAME}_${SLUG}_` 前缀(从 ext.conf 读),**绝不 drop/alter clawos 已有表**
-- **必须绑自定义域名**(`<DEPLOY_NAME>.app.clawos.chat`,HTTPS 直出,certId 在 config.env),否则 `fcapp.run` 默认 URL 强制下载网页、浏览器不渲染 + 阿里云 3 天回收
-- **不用 SAE**(Node 无代码包,只能镜像=要 Docker);不用 `custom.debian10`/裸 command(node 找不到 / CAExited)
-- **长连接 / WebSocket 推送不适合 FC** → 用 Supabase Realtime(FC 不维持长连接)
-
-## 不固化的(留给人/agent)
-
-数据模型设计、业务逻辑、建表前的归属判断、发布失败时的异常排查。
+本模板面向 HTTP 请求服务。实时推送或长连接需求需另核实际 FC 配置与连接时限，可考虑 Supabase Realtime；不要将模板取舍当作 FC 所有配置的能力限制。

package/dist/persona-defaults/persona-clawd-butler/.claude/skills/clawd-config-editor/SKILL.md

@@ -1,39 +1,20 @@
 ---
 name: clawd-config-editor
-description: 老板要改 persona 配置（CLAUDE.md / persona.json / sandbox）、profile 里的 displayName、联系人授权文件之类的本地配置时触发
+description: 老板要修改已有 persona 的人格、默认模型、公开可见性或沙箱配置时触发；不通过直接改状态文件管理联系人或 owner 身份。
 ---
 
-# 本机配置修改
+# 配置修改
 
-老板讲"改一下 xxx persona 的 CLAUDE.md、加个字段到 profile、给 xxx 加联系人授权"就用这个 skill。
+先用 clawd-rpc list 查方法表，persona:get 读当前配置，再按字段提交 persona:update。修改前说明目标与影响，按会话已有授权执行；扩大权限或外部影响缺授权时先确认。
 
-## 怎么答
-
-按老板要改的东西挑对应 md：
-
-| 老板要改 | fetch |
+| 要改 | 文档 |
 |---|---|
-| persona 的 CLAUDE.md / persona.json / iconKey / model | `${CLAWOS_API}/api/docs/config/persona-config.md` |
-| persona 的 sandbox-settings.json | `${CLAWOS_API}/api/docs/config/sandbox-settings.md` |
-
-**本机路径**：
-
-- `~/.clawd/personas/<id>/CLAUDE.md` persona 人格
-- `~/.clawd/personas/<id>/.clawd/persona.json` persona 元信息（label / model / iconKey / public）
-- `~/.clawd/personas/<id>/.clawd/sandbox-settings.json` persona sandbox 授权
-- `~/.clawd/profile.json` owner profile（displayName 等）
-- `~/.clawd/contacts.json` 联系人 + 授权（T-35 后授权数据全在这一份）
-
-## 改之前先说清
-
-改配置前**一句话**告诉老板：改啥文件、改啥字段、为啥这么改。老板一眼看不对能拦住。
-
-改完提一句**是否需要重启 daemon**（persona label / profile.displayName 等要重启 daemon 才让别的 persona 看到；sandbox / CLAUDE.md 下次开 session 生效）。
-
-## fetch 失败了
+| 人格 / label / tool / model / public | `${CLAWOS_API}/api/docs/config/persona-config.md` |
+| Claude / Codex guest 沙箱 | `${CLAWOS_API}/api/docs/config/sandbox-settings.md` |
+| 联系人建联 / 远程操作权限 | `${CLAWOS_API}/api/docs/orchestration/contacts-guide.md` |
 
-具体字段 schema 拉不到时**别硬改**——告诉老板"这个字段我需要文档但拉不到，稍后再试或让 David 看一眼"。已知的字段（比如 profile.json 里的 displayName）沿用会话上下文里的经验即可。
+预装人格用 personalityLocal 补充层；自建人格经 personality 更新，daemon 同步 CLAUDE / AGENTS 镜像。tool / model / effort 只影响后续新会话；RPC 更新 label 不需重启。Codex 沙箱用 patch.codexSandbox 局部合并；Claude sandboxSettings 不在 persona:update 参数表中，不能发明字段。
 
-## 回答风格
+不直接读写 profile.json、contacts.json 或凭证文件，也不调用 contact:list。owner 身份/称呼按连接上下文与支持的界面设置管理，不能给未知 profile 字段杜撰产品效果。
 
-改文件用 Edit（不动其它字段）。别用 Write 覆写整个文件，除非老板明确要重写。
+文档拉不到时用 RPC schema 和当前返回值；字段或修改入口无法确认就停在该字段，不沿用旧文件经验。只改老板要求的字段，保留其它配置。

package/dist/persona-defaults/persona-clawd-butler/.claude/skills/clawd-introspection/SKILL.md

@@ -13,7 +13,7 @@ description: 老板问本机 clawd 状态时触发——装了哪些 persona/ext
 
 **文档只解释结构，不代表当前状态。** 需要了解字段含义时 fetch `${CLAWOS_API}/api/docs/introspection/file-map.md` 或 `state-schemas.md`；故障表征参考 `common-issues.md`。
 
-**不直接读凭证或扫目录列状态。** `auth.json`、带凭证的 tunnel / owner identity 文件和含 connectToken 的 `contacts.json` 不读、不贴、不落盘；不调会返回 connectToken 的 `contact:list`。联系人授权通过界面或方法表里不返回凭证的接口查看。
+**不直接读凭证或扫目录列状态。** `auth.json`、含 authToken 的 `state.json`、带凭证的 tunnel / owner identity 文件和含 connectToken 的 `contacts.json` 不读、不贴、不落盘；不调会返回 connectToken 的 `contact:list`。联系人授权通过界面或方法表里不返回凭证的接口查看。
 
 RPC 不可用时说明无法确认当前状态。诊断可按用户的时间窗读取 `~/.clawd/log/clawd.log`、`frpc.log` 等日志，禁止把 persona 目录、旧 JSON 或远端不在本机的文件当作实时清单。读会话走 `history:read`，一定加 `slim:true`。
 
@@ -23,4 +23,4 @@ fetch 不到文档时仍先用 RPC 方法表与返回结果回答；需要的结
 
 ## 回答风格
 
-对老板讲人话。读本机文件时如果关键字段有值/无值直接讲结论，不要把整个 json 甩过去。
+对老板讲人话。对 RPC 的安全字段讲结论，不把含凭证的原始 JSON 贴给用户。

package/dist/persona-defaults/persona-clawd-butler/.claude/skills/clawd-orchestration/SKILL.md

@@ -19,7 +19,7 @@ description: 老板要 dispatch 任务给别的 persona、给联系人发 DM、
 | 授权联系人 / 撤销授权 / 看谁授过我啥 | `${CLAWOS_API}/api/docs/orchestration/contacts-guide.md` |
 | 频道 / 话题（多分身拆线并行 + 逐条验收） | `${CLAWOS_API}/api/docs/orchestration/channel-topic-guide.md` |
 
-**能调的 MCP 工具**（daemon 已自动注入，直接调）：
+**能调的 MCP 工具**（以当前会话实际工具清单为准）：
 
 - `mcp__clawd-dispatch__personaDispatch` / `personaDispatchList` / `personaDispatchComplete`
 - `mcp__clawd-inbox__sendDm`
@@ -51,4 +51,4 @@ call({ method: "persona:list" })   # clawd-rpc MCP tool
 
 ## 回答风格
 
-发出去之前简述会做啥、发给谁、大概啥内容。老板看着不对能拦住。不要问过多确认——凭判断做，太不可逆的动作（撤授权、发跨设备消息）先说一句再动手。
+发出去之前简述会做啥、发给谁、大概啥内容。老板看着不对能拦住。按会话中老板已有授权执行；没有外发/写操作授权时先确认，不能把“先说一句”当获得同意。联系人标识从用户或安全界面取得，不读 contacts.json、不调 contact:list。

package/dist/persona-defaults/persona-clawd-butler/.claude/skills/clawd-product/SKILL.md

@@ -18,7 +18,7 @@ description: 老板问 clawd 是什么、能干什么、mobile 或 desktop 有
    | desktop 能干什么 | `${CLAWOS_API}/api/docs/product/desktop.md` |
    | mobile 能干什么 | `${CLAWOS_API}/api/docs/product/mobile.md` |
    | extension 是啥、怎么装 | `${CLAWOS_API}/api/docs/product/extensions.md` |
-   | 远程接入 / 邀请码 | `${CLAWOS_API}/api/docs/product/tunnel.md` |
+   | 远程接入 / 手机配对 / 访客链接 | `${CLAWOS_API}/api/docs/product/tunnel.md` |
 
 3. WebFetch 拉回来照着答