@clawos-dev/clawd 0.2.541 → 0.2.542

package/dist/cli.cjs

@@ -70911,7 +70911,7 @@ function computeMethodAccess(args) {
 }
 
 // src/version.ts
-var version = "0.2.541".length > 0 ? "0.2.541" : "dev";
+var version = "0.2.542".length > 0 ? "0.2.542" : "dev";
 
 // src/cli-probe/probe.ts
 var fs78 = __toESM(require("fs"), 1);

package/dist/persona-defaults/persona-app-builder/.mcp.json

@@ -1,5 +1,5 @@
 {
-  "_comment": "preinstall ship 进 daemon defaults，daemon 启动时 refreshDaemonManagedDirs 把这文件同步到 ~/.clawd*/personas/persona-app-builder/.mcp.json。**这里只有声明，没有值**：`${VAR}` 占位由 daemon 在 spawn 时从凭据表渲进 per-server env / headers（见 daemon/src/persona/mcp-secret-render.ts），渲染产物是另一份 0600 文件、同名 server 压过本文件，所以 agent 在 persona 目录里读不到任何 key。supabase：用 @aliyun-rds/supabase-mcp-server Mode 2 单实例直连（不再用 aliyun AK），底下接阿里云托管 supabase。这三个 env 名不是我们发明的——该包的 commander option 默认值就取 process.env.SUPABASE_URL / SUPABASE_ANON_KEY / SUPABASE_SERVICE_ROLE_KEY，所以不再传 --supabase-* CLI 参数（参数会进 ps 输出，等于没藏）。**不要往这里加 --jwt-secret / SUPABASE_AUTH_JWT_SECRET**：jwt-secret 是该实例的 JWT 签发密钥，拿到它可以自签任意 role/任意 user 的 token（含 service_role），下发出去等于把 anon/service key 的轮换能力一起交出去；而 MCP server 里它唯一的用处是 verify_jwt_secret 这个自检工具报个 found/preview。github：GitHub 官方远程 MCP（spec 2026-09-14-app-builder-github-mcp-design），建仓 / 提交文件都由 agent 按 .claude/skills/app-builder-projects 走它，本机不再依赖 gh CLI。Authorization 走 `${GITHUB_TOKEN}` 占位而不是留空让 Claude Code 自己 OAuth：没占位的 http server 不进 daemon 的渲染产物，只剩 cwd 里这份项目级声明，daemon 起的 headless 会话过不了 Claude Code 的「项目 MCP 待批准」和交互式 OAuth 两关（2026-09-14 实测）。`GITHUB_TOKEN` 是保留变量名 = 当前用户的 GitHub 身份（spec 2026-09-15-github-auth-unify §4.1）：本机由 daemon 从机器级身份（设置 → 账号关联，存在 git 的凭据存储；~/.clawd/secrets/github.env 是 git 没配 helper 时的退路）渲进产物；云上由中心从使用者的 GitHub 身份供值、代理时注 Bearer，不填 PAT。值本身随 OTA 下发的边界与收敛方向见 doc/glossary/persona-cloud.md。",
+  "_comment": "preinstall ship 进 daemon defaults，daemon 启动时 refreshDaemonManagedDirs 把这文件同步到 ~/.clawd*/personas/persona-app-builder/.mcp.json。**这里只有声明，没有值**：`${VAR}` 占位由 daemon 在 spawn 时从凭据表渲进 per-server env / headers（见 daemon/src/persona/mcp-secret-render.ts），渲染产物是另一份 0600 文件、同名 server 压过本文件，所以 agent 在 persona 目录里读不到任何 key。supabase：用 @aliyun-rds/supabase-mcp-server Mode 2 单实例直连（不再用 aliyun AK），底下接阿里云托管 supabase。这三个 env 名不是我们发明的——该包的 commander option 默认值就取 process.env.SUPABASE_URL / SUPABASE_ANON_KEY / SUPABASE_SERVICE_ROLE_KEY，所以不再传 --supabase-* CLI 参数（参数会进 ps 输出，等于没藏）。**不要往这里加 --jwt-secret / SUPABASE_AUTH_JWT_SECRET**：jwt-secret 是该实例的 JWT 签发密钥，拿到它可以自签任意 role/任意 user 的 token（含 service_role），下发出去等于把 anon/service key 的轮换能力一起交出去；而 MCP server 里它唯一的用处是 verify_jwt_secret 这个自检工具报个 found/preview。github：GitHub 官方远程 MCP（spec 2026-09-14-app-builder-github-mcp-design），建仓 / 提交文件都由 agent 按 .claude/skills/app-builder-projects 走它，本机不再依赖 gh CLI。Authorization 走 `${GITHUB_TOKEN}` 占位而不是留空让 Claude Code 自己 OAuth：没占位的 http server 不进 daemon 的渲染产物，只剩 cwd 里这份项目级声明，daemon 起的 headless 会话过不了 Claude Code 的「项目 MCP 待批准」和交互式 OAuth 两关（2026-09-14 实测）。`GITHUB_TOKEN` 是保留变量名 = 当前用户的 GitHub 身份（spec 2026-09-15-github-auth-unify §4.1）：本机由 daemon 从机器级身份（设置 → 账号关联，存在 git 的凭据存储；~/.clawd/secrets/github.env 是 git 没配 helper 时的退路）渲进产物；云上由中心从使用者的 GitHub 身份供值、代理时注 Bearer，不填 PAT。值不随 OTA 下发（本机 ~/.clawd/secrets/supabase.env，云上 gateway 注入），来龙去脉见 doc/glossary/persona-cloud.md。",
   "mcpServers": {
     "github": {
       "type": "http",

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

@@ -92,15 +92,15 @@
 
 ## 后端：supabase MCP
 
-**`supabase`** —— 后端数据/认证/存储，唯一的 MCP 支柱。这份 Supabase **是阿里云托管 supabase 实例**（`http://121.196.249.178:80`），全局 MCP / clawos / lovagent / moltoffer / clawd 都指向这一台。**不是**云上 `supabase.com` 的实例。开工前确认能连上：
+**`supabase`** —— 后端数据/认证/存储，唯一的 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` 渲好，直接 `pnpm dev` 就能连上——**不要**去别处找 key 往文件里抄
+- **凭据值你看不到，也不需要看到**：`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 往文件里抄
 - **红线**：这是共享生产库。建表 / 迁移前先 `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`），不写死
 - 建了表记得把**基础名**（如 `visits`）填进 `ext.conf` 的 `SUPABASE_TABLES`（空格分隔），`removeProject` 据此打印两套清理语句
 
-**易踩的坑**：唯一真源是 **daemon 的凭据表**（`~/.clawd/secrets/` 覆盖 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` 的 `SUPABASE_URL` 是不是被人动过。
 
 ## 部署：阿里云 FC（serverless）
 

package/dist/persona-defaults/persona-app-builder/extension-kit/examples/nestjs-react/server/.env.example

@@ -1,4 +1,4 @@
-# supabase 连接串的**唯一真源是 daemon 的凭据表**（`~/.clawd/secrets/` 覆盖 clawd 自带那份）。
+# supabase 连接串的**唯一真源是 daemon 的凭据表**（本机 `~/.clawd/secrets/supabase.env`，云上 gateway 经 env 注入）。
 # 本文件是模板：scaffold（new-extension.sh）把下面的占位引用展开成同目录的 `.env` 给本地 dev 用；
 # 线上那份由 publish.sh 渲进 s.yaml 的 environmentVariables。两条路取同一张表的同一个变量名，
 # 所以不会出现「本地连一台、线上连另一台」的漂移（那会表现成 PGRST205 找不到表）。

package/dist/secrets/README.md

@@ -1,32 +1,47 @@
-# `src/secrets/` —— 随 OTA 下发的共享凭据表
+# `src/secrets/` —— 凭据表的 bundle 目录（只有占位模板，没有值）
 
-这里的每个 `<name>.env` 是一条**命名凭据**的值，`name` 对齐环境清单
-（`EnvironmentManifest.secrets[].name`）。daemon 在 spawn 时把它们合成一张
+每个 `<name>.env.example` 是一条**命名凭据**的占位模板，`name` 对齐环境清单
+（`EnvironmentManifest.secrets[].name`）。daemon 在 spawn 时把凭据表合成一张
 `Record<envName, value>`，只交给**真正用它的那个子进程**（MCP server / deploy-kit 发布脚本），
 agent 主进程 env 一条都不放。读法与合并顺序见 `../deploy/secret-table.ts`。
 
-## 为什么单独一个目录，而不是继续写在 persona bundle 里
+## 这里不放值：clawd 不随包 ship 任何凭据
 
-原先 supabase 的 url / anon / service-role 是**明文 CLI 参数**硬写在
-`persona-app-builder/.mcp.json` 里的。那个文件在 persona 目录下，agent 一个 `Read` 就看得见
-——等于每次会话都把 key 摊给模型。挪到这里之后：
+本目录随 npm 包 / OTA 发给所有用户，**放进来的每一把 key 都等于公开**——不是比喻：
+
+- deploy-kit 的阿里云 AK 曾以「共享 demo 凭证」身份放在 `deploy-kit/.secrets/aliyun.env`，随 npm 包发出去
+  **69 秒**就被 TruffleHog 收割、90 天内被 100+ 个境外 IP 验证约 600 次，最后主账号被阿里云风控锁
+  （`specs/2026-09-18-aliyun-ak-leak-rotate-design.md`）。
+- 这里的 supabase 三件套（url / anon / **service-role**）曾经也是这么 ship 的。service-role 绕过 RLS，
+  等于整库管理员；而那台实例除 app-builder 的 demo 表外还承载 clawd 自己的 `clawd_prod` schema
+  （`persona_cloud_api_keys` / `device_bindings` / `lark_bot_bindings` 的明文 app_secret……）——
+  随包公开等于把中心库交出去（`specs/2026-09-18-supabase-key-leak-design.md`）。
+
+所以 2026-09-18 起：`*.env` 不进 git（`clawd/.gitignore`），不进 dist（`scripts/copy-defaults.mjs`
+平移时只放行 `*.example` 与本 README），desktop OTA 打的是 dist 所以同样没有。
 
-- persona 目录（agent 的 cwd 及其上级）里没有任何凭据值；
-- 「哪些 key 随 OTA 下发」在**目录层面就是可数的**——将来做收敛（见
-  `doc/glossary/persona-cloud.md` 的「随 OTA 下发的凭据 = 公开凭据」）时，要删的就是这个目录。
+## 值从哪来
 
-## 信任层级：这里的每一把 key 都等于公开
+| 环境 | 来源 |
+| --- | --- |
+| 本机 | **`~/.clawd/secrets/<name>.env`**（凭据表覆盖目录，不随 OTA 覆盖）。照同名 `.example` 抄一份填值即可。改了下一个会话就生效，不用重启 daemon |
+| 云上 | persona 仓库的 GitHub Secrets（同名）→ `register.mjs` → gateway 起 Pod 时经容器 env 交进来，走同一个交付点。**不读这两个目录** |
 
-本目录随 npm 包 ship 给所有用户。判断风险时按「这把 key 落在所有用户手上」算——不是比喻：
-deploy-kit 的阿里云 AK 曾经也这么 ship，随 npm 包发出去 **69 秒**就被 TruffleHog 收割、90 天内被
-100+ 个境外 IP 验证约 600 次，最后主账号被阿里云风控锁；2026-09-18 起它不再随包分发
-（`specs/2026-09-18-aliyun-ak-leak-rotate-design.md`）。这里的 supabase 三件套（含 service-role）
-仍在 ship，是同一类风险。把 service-role key 换成受限 role 的收敛方向记在 glossary，
-不在 M1b 范围。
+本机什么都没配：凭据表为空，`persona/mcp-secret-render.ts` 会 warn 缺哪个变量名并渲成空串，MCP server
+起不来时在会话里响亮报错；deploy-kit 的 `publish.sh` 对缺失占位符 fail-loud。**不会静默用错实例。**
 
-## 本机覆盖
+开发者在 repo checkout 里跑 `tsx src/index.ts` 想图省事，也可以把真值放在本目录的 `<name>.env`——它是
+gitignored 的，且 `pnpm build` 不会把它带进 dist。
+
+## 为什么单独一个目录，而不是写在 persona bundle 里
+
+原先 supabase 的 url / anon / service-role 是**明文 CLI 参数**硬写在
+`persona-app-builder/.mcp.json` 里的。那个文件在 persona 目录下，agent 一个 `Read` 就看得见
+——等于每次会话都把 key 摊给模型。挪到凭据表之后：
 
-`~/.clawd/secrets/<name>.env` 覆盖同名条目（逐个 env 变量覆盖，不是整份替换）。用途：
-部署者用自己的 supabase 实例、或轮换出新 key 又不想等 OTA。该目录不随 OTA 覆盖。
+- persona 目录（agent 的 cwd 及其上级）里没有任何凭据值，只有 `${VAR}` 占位；
+- 「消费方要哪些变量名」在**目录层面就是可数的**——就是这里的 `*.example`。
 
-云上没有这两个文件——gateway 起 Pod 时把同一张表经容器 env 交进来，走同一个交付点。
+**不放 JWT 签发密钥**（`SUPABASE_AUTH_JWT_SECRET`）：它能自签任意 role / 任意 user 的 token（含
+`service_role`），交出去等于连「日后轮换 anon/service key」这个能力一起交出去；MCP server 里它唯一的用处是
+`verify_jwt_secret` 自检。

package/dist/secrets/supabase.env.example

@@ -0,0 +1,17 @@
+# supabase 凭据（app-builder 系 persona 的 supabase MCP + deploy-kit 发布脚本用）。
+#
+# clawd 不随包 ship 任何一把 supabase key：把自己实例的值写进 **~/.clawd/secrets/supabase.env**
+# （daemon 的凭据表覆盖目录，不随 OTA 覆盖，见 ../deploy/secret-table.ts）。这个目录里的 *.env
+# 不进 git（clawd/.gitignore）、不进 dist（scripts/copy-defaults.mjs 只平移 *.example 与 README）。
+# 云上不用文件：persona 仓库的 GitHub Secrets（同名四个）→ register.mjs → gateway 起 Pod 时经 env 注入。
+#
+# 四个名字都要给：前三个是 @aliyun-rds/supabase-mcp-server 的 commander option 默认值
+# （process.env.SUPABASE_URL / SUPABASE_ANON_KEY / SUPABASE_SERVICE_ROLE_KEY）；SUPABASE_KEY 是
+# deploy-kit（s.yaml environmentVariables / 项目 server/.env）的历史名字，值同 anon。
+#
+# **不放 JWT 签发密钥**（SUPABASE_AUTH_JWT_SECRET）：它能自签任意 role 的 token，MCP 里唯一用途是
+# verify_jwt_secret 自检，摘掉零功能损失。
+SUPABASE_URL=http://replace-me:80
+SUPABASE_ANON_KEY=replace-me
+SUPABASE_SERVICE_ROLE_KEY=replace-me
+SUPABASE_KEY=replace-me

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@clawos-dev/clawd",
-  "version": "0.2.541",
+  "version": "0.2.542",
   "description": "Standalone clawd daemon — Claude Code (and future Codex) session server over WebSocket",
   "type": "module",
   "license": "MIT",

package/dist/secrets/supabase.env

@@ -1,16 +0,0 @@
-# supabase —— 阿里云托管 supabase 实例（公网 endpoint 121.196.249.178:80，
-# 项目 ra-ae0i57kef06s6ix / clawd-app-builder，杭州可用区J）。
-# 消费方两处，都经 daemon 的凭据表交付、都不落 persona 目录：
-#   - supabase MCP server（persona-app-builder/.mcp.json 的 ${...} 占位）
-#     —— @aliyun-rds/supabase-mcp-server 的 commander option 默认值就读这三个名字，
-#        所以不再传 --supabase-* CLI 参数（参数会出现在 ps 输出里）。
-#   - deploy-kit 的 publish.sh / new-extension.sh（渲染进 s.yaml 的 environmentVariables
-#     与项目 server/.env）—— 那两处历史上叫 SUPABASE_KEY，值同 anon。
-#
-# **不放 JWT 签发密钥**：它能自签任意 role / 任意 user 的 token（含 service_role），
-# 下发出去等于把 anon/service key 的轮换能力一起交出去；而 MCP server 里它唯一的用处是
-# verify_jwt_secret 这个自检工具报个 found/preview。摘掉零功能损失。
-SUPABASE_URL=http://121.196.249.178:80
-SUPABASE_ANON_KEY=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJvbGUiOiJhbm9uIiwiaWF0IjoxNzgzMzEwODU1LCJleHAiOjEzMjkzOTUwODU1fQ.sHLZH8q2SGWYbNPEFOzTFlQEtjVK3z1DlEqoU_5Uyyg
-SUPABASE_SERVICE_ROLE_KEY=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJvbGUiOiJzZXJ2aWNlX3JvbGUiLCJpYXQiOjE3ODMzMTA4NTUsImV4cCI6MTMyOTM5NTA4NTV9.MdlymSh0DaJdiOVRmM3QnukUDtkOf_Eljh8_fpdLi8Q
-SUPABASE_KEY=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJvbGUiOiJhbm9uIiwiaWF0IjoxNzgzMzEwODU1LCJleHAiOjEzMjkzOTUwODU1fQ.sHLZH8q2SGWYbNPEFOzTFlQEtjVK3z1DlEqoU_5Uyyg