@clawos-dev/clawd 0.2.619 → 0.2.621

package/dist/persona-defaults/persona-app-builder/.claude/skills/app-builder-projects/scripts/collect-files.mjs

@@ -1,17 +1,10 @@
 #!/usr/bin/env node
-// 把项目目录里该进仓库的文件收成 GitHub MCP `push_files` 要的 `[{ path, content }]`。
-//
-// 过滤规则 = 项目根 `.gitignore`（模板那份：node_modules/ dist/ .env .publish.log s.yaml s.*.yaml server/bootstrap .s/ …）
-// + 永远排掉 `.git` 和 `.clawd-project.json`（插件的记账文件：publish / record-push 都会改它，进了仓库或哈希就会
-// 「每推一次都变一次」，而且里面的 deployments / pushedCommit 也不是源码）。**不要**在这里另写一份排除表：publish.sh 渲进项目目录的 s.int.yaml / s.prod.yaml 含 supabase key，
-// 它进不进仓库只该由 .gitignore 一处决定。
-// 二进制（前 8KB 含 NUL）和超过 512KB 的文件跳过并列进 `skipped`——push_files 只收文本，
-// 而且每个字节都要经模型上下文走一遍；agent 看到 skipped 里有该进仓库的东西要自己判断。
-//
+// 收集 GitHub MCP push_files 的文本文件；过滤以项目 .gitignore 为准，避免 s.*.yaml 中的 key 被提交。
+// 始终排除 .git 及根 .clawd-project.json，记账变化不属于源码，不能进入推送或树哈希。
+// 二进制（前 8KB 含 NUL）及超过 512KB 的文件列入 skipped，不进哈希；调用方需判断是否另行处理。
 // 用法：collect-files.mjs --project <项目目录绝对路径>
 // 输出：{ files: [{ path, content }], skipped: [{ path, reason }], treeHash }
-//   treeHash = files 按 path 排序后 sha256(path\0content\0…)。record-push.mjs 把它记进元数据，
-//   publish tool 再跑一次本脚本比对——不一致就是「改了没推」，拒绝发布。skipped 里的文件不进哈希。
+// treeHash 为按 path 排序的 sha256(path\0content\0…)；publish 重算后与 record-push 记账比较，拒绝未推的改动。
 import { createHash } from 'node:crypto'
 import { readdir, readFile, stat } from 'node:fs/promises'
 import { join, relative, sep } from 'node:path'
@@ -58,7 +51,6 @@ function ignored(rel, isDir, rules) {
   const segments = rel.split('/')
   for (const rule of rules) {
     if (rule.anchored) {
-      // 前缀匹配：rel 等于它、或在它下面
       for (let i = 1; i <= segments.length; i++) {
         const head = segments.slice(0, i).join('/')
         if (rule.re.test(head) && (!rule.dirOnly || isDir || i < segments.length)) return true
@@ -67,7 +59,6 @@ function ignored(rel, isDir, rules) {
     }
     for (let i = 0; i < segments.length; i++) {
       if (!rule.re.test(segments[i])) continue
-      // dirOnly：命中的这一段得是目录——要么它不是最后一段（后面还有东西），要么 rel 本身就是目录
       if (!rule.dirOnly || i < segments.length - 1 || isDir) return true
     }
   }
@@ -78,7 +69,7 @@ let rules = []
 try {
   rules = parseGitignore(await readFile(join(root, '.gitignore'), 'utf8'))
 } catch {
-  // 没有 .gitignore：只排 .git
+  // 无法读取 .gitignore 时仍排除 .git 和根 .clawd-project.json。
 }
 
 const files = []
@@ -109,7 +100,7 @@ async function walk(dir) {
 }
 
 await walk(root)
-// 按字节序排，不用 localeCompare：不同机器 locale 不同会让同一棵树排出两种顺序
+// 按字符串序而非 localeCompare 排序，避免不同机器 locale 改变树哈希。
 files.sort((a, b) => (a.path < b.path ? -1 : a.path > b.path ? 1 : 0))
 const hash = createHash('sha256')
 for (const f of files) hash.update(f.path).update('\0').update(f.content).update('\0')

package/dist/persona-defaults/persona-app-builder/.claude/skills/app-builder-projects/scripts/list-projects.mjs

@@ -24,8 +24,7 @@ for (const dirName of names) {
   try {
     const value = JSON.parse(await readFile(join(projectsRoot, dirName, '.clawd-project.json'), 'utf8'))
     if (value?.name !== dirName || typeof value.createdAt !== 'string') continue
-    // 双环境后发布记录在 deployments.{integration,prod}；prodUrl 保留作兼容字段 = prod 那份的 url。
-    // 插件还没读写过的老文件顶层就有 prodUrl，原样带出。
+    // prodUrl 兼容字段优先取 deployments.prod.url，缺席时保留 legacy 顶层值。
     const prodUrl = value.deployments?.prod?.url
     projects.push({ ...value, ...(prodUrl ? { prodUrl } : {}), projectDir: join(projectsRoot, dirName) })
   } catch {

package/dist/persona-defaults/persona-app-builder/.claude/skills/app-builder-projects/scripts/record-push.mjs

@@ -1,9 +1,7 @@
 #!/usr/bin/env node
-// 经 GitHub MCP 建仓 / push 之后记账：把 repoUrl、远端 commit sha、push 那一刻的文件树哈希写进项目的 .clawd-project.json。
-// publish tool 对没有本地 git 的项目：重算文件树哈希与 pushedTreeHash 比，不一致拒绝发布；一致就记 pushedCommit
-// 当 publishedCommit（「线上 = 仓库里的哪个 commit」）。
-//
-// 用法：record-push.mjs --project <项目目录绝对路径> --commit <push_files 返回的 object.sha> --tree-hash <collect-files.mjs 输出的 treeHash> [--repo-url <https://github.com/ottin4ttc/...>]
+// GitHub MCP push 后记 repoUrl、pushedCommit 和 pushedTreeHash 到 .clawd-project.json。
+// 无本地 git 的项目发布时重算树哈希；一致才以 pushedCommit 记 publishedCommit。
+// 用法：record-push.mjs --project <项目目录绝对路径> --commit <object.sha> --tree-hash <treeHash> [--repo-url <https://github.com/ottin4ttc/...>]
 // 输出：写回后的元数据 JSON
 import { readFile, writeFile } from 'node:fs/promises'
 import { join } from 'node:path'

package/dist/persona-defaults/persona-app-builder/.claude/skills/app-builder-projects/scripts/render-sql.mjs

@@ -1,9 +1,7 @@
 #!/usr/bin/env node
-// 把项目的 server/db/schema.sql 渲成某个环境的 SQL 打到 stdout：`__TABLE_PREFIX__` → 该环境的表前缀。
-// 表结构只有这一份源，integration / prod 各渲一次再喂给 supabase MCP 的 execute_sql——两套表结构
-// 不会漂移。前缀口径与 publish.sh / remove-extension.sh 相同：
-//   integration → <APP_NAME>_<SLUG>_int_    prod → <APP_NAME>_<SLUG>_
-// ext.conf 没 SLUG 的老项目退成 <APP_NAME>_int_ / <APP_NAME>_。
+// 渲 server/db/schema.sql 的 __TABLE_PREFIX__ 到 stdout，共用一份 DDL。
+// 前缀与 publish/remove 一致：integration 为 <APP_NAME>_<SLUG>_int_，prod 为 <APP_NAME>_<SLUG>_。
+// legacy 无 SLUG 时分别退为 <APP_NAME>_int_ / <APP_NAME>_。
 import { readFile } from 'node:fs/promises'
 import { join } from 'node:path'
 
@@ -27,7 +25,7 @@ function fail(msg) {
   process.exit(1)
 }
 
-/** ext.conf 是 bash 赋值文件；这里只认 `KEY=value` / `KEY="value"` 单行，够 APP_NAME / SLUG 用。 */
+/** 只解析单行 KEY=value 及单/双引号，不执行 ext.conf 的 shell 内容。 */
 function readConf(text) {
   const out = {}
   for (const line of text.split('\n')) {

package/dist/persona-defaults/persona-app-builder/extension-kit/examples/nestjs-react/server/src/app.module.ts

@@ -1,12 +1,6 @@
 import { Module } from '@nestjs/common';
 
-// 默认空白骨架 —— 没有任何业务 controller / service / module 注册。
-// 历史背景：之前导入 MessagesModule 自带留言板 API + Supabase repo，用户起 dev server 时 nest
-// 启动会初始化 supabase 模块（控制台 noise + 旁边业务代码会暗示 assistant 沿用留言板风格）。
-// 瘦身后只留启动骨架，业务逻辑由 assistant 按用户需求从零加（添 controller/module 进 imports 即可）。
-//
-// vite middleware / 静态资源 serve 路径仍由 main.ts 处理（dev mount vite，prod express.static），
-// 不需要 ServeStaticModule。
+// 留空启动骨架，由项目按需求注册业务模块；静态资源由 main.ts 托管，无需 ServeStaticModule。
 @Module({
   imports: [],
 })

package/dist/persona-defaults/persona-app-builder/extension-kit/examples/nestjs-react/server/src/main.ts

@@ -5,11 +5,8 @@ import { AppModule } from './app.module';
 import { TABLE_PREFIX } from './table-name';
 import * as path from 'node:path';
 
-// 两种跑法：
-//   - dev：`cd server && pnpm dev`（nest watch）+ 另开一个终端 `cd web && pnpm dev`（vite 独跑，
-//     /api 走 web/vite.config.js 的 proxy 转到本进程）
-//   - prod / FC：nest 直接 serve web 的打包产物（publish.sh 的 BUILD_CMD 把 web/dist 拷进 dist/public）
-// FC_SERVER_PORT 是 FC 运行时注入的端口；PORT 给本地调试。
+// dev 由 Vite 独跑并代理 /api；FC 托管拷入 dist/public 的 web 产物。
+// 端口优先 FC_SERVER_PORT，其次本地 PORT。
 async function bootstrap() {
   const app = await NestFactory.create<NestExpressApplication>(AppModule);
 
@@ -18,10 +15,7 @@ async function bootstrap() {
 
   app.setGlobalPrefix('api', { exclude: ['/'] });
 
-  // 静态资源两条路（覆盖 FC 部署与本地 monorepo 启动两种场景）：
-  //   1. FC（CODE_DIR=./server 只上传 server/，运行时 __dirname=dist/）：publish.sh BUILD_CMD 末尾
-  //      把 ../web/dist 拷进 dist/public，跟着 server 一起上传，所以优先用 __dirname/public
-  //   2. 本地 `node dist/main.js`：__dirname/public 不存在时 fallback 到 ../../web/dist
+  // FC 仅上传 server/，优先托管 dist/public；本地构建可回落到 web/dist。
   const fs = await import('node:fs');
   const fcStaticDir = path.resolve(__dirname, 'public');
   const monorepoStaticDir = path.resolve(__dirname, '..', '..', 'web', 'dist');

package/dist/persona-defaults/persona-app-builder/extension-kit/examples/nestjs-react/server/src/polyfill.ts

@@ -1,14 +1,8 @@
-// Dev 模式 .env loader：`nest start --watch` 不会经过 `node --env-file=.env`，
-// server 拿不到 SUPABASE_URL/KEY → createClient 跑了但 process.env 是空 → PGRST 系列错码。
-// 这里在 nest bootstrap 之前显式 require dotenv 把 .env 填进 process.env。
-// prod 路径（node --env-file=.env dist/main.js）Node 自带 loader 已经填了，dotenv 看到
-// 已存在的 env 不会覆盖（默认行为），行为对齐。
+// nest watch 不经过 Node --env-file；bootstrap 前加载 .env，dotenv 不覆盖已注入的 env。
 require('dotenv/config');
 
-// Node < 22 没有原生 WebSocket,而 @supabase/supabase-js 的 realtime 客户端
-// 初始化时需要它。在应用启动前补一个全局 WebSocket,使任意 Node 版本
-// (FC 运行时给的 node 可能是 18/20)下都能正常 createClient。
-// 注意:不要用 `WebSocket` 作为局部变量名,会与 DOM lib 的全局类型重声明冲突。
+// Supabase Realtime 初始化需要 WebSocket；缺原生实现时（如 Node 18/20）用 ws 补全。
+// 局部构造器避免命名为 WebSocket，以免与 DOM 全局类型冲突。
 const WsCtor = require('ws');
 if (!(globalThis as any).WebSocket) {
   (globalThis as any).WebSocket = WsCtor;

package/dist/persona-defaults/persona-app-builder/extension-kit/examples/nestjs-react/server/src/table-name.ts

@@ -1,7 +1,5 @@
-// Supabase 表名的唯一入口：表名 = TABLE_PREFIX + 基础名。
-// 两个环境（integration / prod）两套表，靠前缀区分：本地 dev 由 server/.env 给 <APP_NAME>_<SLUG>_int_，
-// 线上由 publish 按 env 注进 FC 的环境变量。代码里凡碰表的地方都走 tableName('visits')，不写死前缀。
-// 表结构写在 server/db/schema.sql（同样用 __TABLE_PREFIX__ 占位），见那边注释。
+// Supabase 表名统一为 TABLE_PREFIX + 基础名，按 integration / prod 隔离。
+// prefix 从 dev .env 或 FC env 注入；DDL 使用同源 __TABLE_PREFIX__ 占位。
 
 const prefix = process.env.TABLE_PREFIX;
 if (!prefix) {
@@ -13,7 +11,6 @@ if (!prefix) {
 
 export const TABLE_PREFIX: string = prefix;
 
-/** `tableName('visits')` → `<APP_NAME>_<SLUG>_int_visits`（integration）/ `<APP_NAME>_<SLUG>_visits`（prod） */
 export function tableName(base: string): string {
   return `${TABLE_PREFIX}${base}`;
 }

package/dist/persona-defaults/persona-app-builder/extension-kit/examples/nestjs-react/web/src/App.jsx

@@ -1,11 +1,4 @@
-// 默认空白页骨架 —— 让 createProject + startDevServer 起来时 iframe 第一帧就是干净白板，
-// 不会闪一下 demo 内容再被 assistant 改成用户实际想要的页面。
-//
-// 历史背景：之前模板自带留言板 demo（App.jsx + messages controller），用户从「新建项目 →
-// 起 dev server → 假设 assistant 改 App.jsx 成 hello world」整个流程里第一眼看到的是留言板
-// UI，HMR 替换后才变成真正的内容 —— 视觉闪动 + 业务代码被模板暗示带偏（spec follow-up
-// 2026-06-03 老板拍）。瘦身后骨架只保留 vite + nest + react 可启动结构，内容由 assistant
-// 按用户需求从零写。
+// 空白起手页，避免模板 demo 暗示业务方向；内容由项目按需求补充。
 export default function App() {
   return <div />;
 }

package/dist/persona-defaults/persona-app-builder/mcp/clawd-app-builder/deploy-kit/scripts/ensure-credentials.sh

@@ -1,30 +1,11 @@
 #!/usr/bin/env bash
-# ============================================================
-# 发布/清理动手前把阿里云凭证准备好（publish.sh / remove-extension.sh 共用）。
-# 被 `source` 进来，再调 ensure_credentials。跟 ensure-toolchain.sh 是一对：
-# 那个管「命令在不在」，这个管「命令拿什么身份跑」。
-#
-# 硬约束：**全程不碰用户全局 ~/.s，凭证不落盘**。clawd 发布用的是 clawd 自己那份 AK（本机 ~/.clawd/secrets/aliyun.env 经 daemon 渲进
-# MCP server env，云上是 pod-setup 渲的 env），而 ~/.s/access.yaml 里的 default 是用户自己账号的
-# Serverless Devs 凭证——它是用户的东西，不是我们的。做法对齐本 kit 处理 aliyun CLI 的方式（凭证只进本次进程的 env）：
-# s v3 的 @serverless-devs/credential 有 getEnvKeyPair——进程 env 里同时有 AccountID / AccessKeyID / AccessKeySecret 三个变量，
-# 就自动合成一个叫 `$system_environment_access` 的 access（实测 s 3.1.10 源码），不需要任何 access.yaml。
-# Serverless Devs 的配置家目录仍指到 deploy-kit 名下，但那里只剩组件缓存和日志，没有凭证。
-# ============================================================
+# Source this file and call ensure_credentials before publish/remove.
+# Credentials stay in process env; never overwrite the user global Serverless Devs credentials.
 
-# s 的 access 名 = s 自己给「从 env 合成的那份」起的固定名字（字面量，$ 不是 shell 变量）。刻意不用 default：
-# env 没齐时 s 找不到这个名字就 `Not found access: $system_environment_access` 硬报错，而不是默默拿用户
-# ~/.s/access.yaml 里的 default 凭证把 extension 部署进别人的账号。调 s 时都显式带 `--access "$S_ACCESS_ALIAS"`：
-# 命令行参数覆盖 s.yaml 里的 access 字段，老项目（s.yaml 写着 clawd-fc / default）照样走这条。
+# Use the literal environment access alias so missing env cannot silently fall back to the user profile.
 S_ACCESS_ALIAS='$system_environment_access'
 
-# 阿里云 AK 只从进程 env 来（design 2026-09-19-persona-mcp-single-source §3.2）：本脚本由 clawd-app-builder MCP server 起，
-# AK 在那个进程的 env 里——本机由 daemon 从凭据表（~/.clawd/secrets/aliyun.env）渲进 .mcp.json 声明的 per-server env，
-# 云上由 pod-setup 从仓库 Secrets 渲进 config.toml 的 [mcp_servers.clawd-app-builder].env。不落盘是有意的：
-# 写成文件的话 agent 一个 `cat` 就看见了。deploy-kit 目录下曾经的 `.secrets/aliyun.env[.local]` 两条读法已删。
-#
-# clawd **不随包 ship 任何一把 AK**（2026-09-18 起，见 specs/2026-09-18-aliyun-ak-leak-rotate-design.md：
-# 上一把随 npm 包发出去 69 秒就被 TruffleHog 收割，主账号被风控锁）。env 里没有 = 使用者还没配，fail-loud。
+# Require caller-injected AK values; never ship credentials or read fallback kit credential files.
 ensure_aliyun_env() {
   if [ -z "${ALIBABA_CLOUD_ACCESS_KEY_ID:-}" ] || [ -z "${ALIBABA_CLOUD_ACCESS_KEY_SECRET:-}" ]; then
     echo "❌ 没有阿里云 AK：本机把 ALIBABA_CLOUD_ACCESS_KEY_ID / ALIBABA_CLOUD_ACCESS_KEY_SECRET 两行写进 ~/.clawd/secrets/aliyun.env（daemon 起 clawd-app-builder 时渲进它的 env）；云上由 gateway 注入。" >&2
@@ -33,17 +14,7 @@ ensure_aliyun_env() {
   export ALIBABA_CLOUD_REGION_ID="${REGION:?config.env 缺 REGION}"
 }
 
-# 调 aliyun CLI 的**唯一入口**：把凭证和 region 作为显式参数交出去，不依赖环境变量的隐式优先级。
-#
-# 为什么非这样不可（实测 aliyun 3.3.17，`--mode AK`）：`ALIBABA_CLOUD_ACCESS_KEY_ID` /
-# `_SECRET` / `_REGION_ID` 这三个环境变量在这个模式下**根本不被消费**，于是
-#   - 机器上没有 `~/.aliyun/config.json`（全新用户的常态，ensure_toolchain 只装 CLI、
-#     从不跑 `aliyun configure`）→ `ERROR: region can't be empty`，第一次发布就跑不起来；
-#   - 机器上有 profile（比如用户自己配过阿里云）→ **静默走用户自己的 profile**，等于拿
-#     用户的阿里云身份去部署 extension，跟 access.yaml 那个坑是同一类。
-# 补 `--region` 一个 flag 不够，AK 也必须是 flag——两者都试过。
-#
-# 用法跟 aliyun 一样，省掉 `--mode AK` 和三个凭证参数：aliyun_ak sts GetCallerIdentity
+# Pass AK and region explicitly: aliyun AK mode can otherwise fall back to the user profile.
 aliyun_ak() {
   aliyun --mode AK \
     --access-key-id "${ALIBABA_CLOUD_ACCESS_KEY_ID:?aliyun_ak 需要先 ensure_aliyun_env}" \
@@ -52,41 +23,33 @@ aliyun_ak() {
     "$@"
 }
 
-# 把 s 要的三个变量放进本进程 env（AccountID 从 GetCallerIdentity 现取），并把 Serverless Devs 的配置家目录
-# （组件缓存 / 日志）指到 deploy-kit 名下——不写 access.yaml，凭证不落盘。
-# s v3 的 rootHome = `$serverless_devs_config_home/.s`（默认 `$HOME/.s`），`s -v` 打印的 s-home 就是它。
-# 前置：ensure_toolchain（aliyun 可执行）+ ensure_aliyun_env（AK 进 env）。
-# 家目录放 $KIT_DIR 下（= persona 目录的 mcp/clawd-app-builder/deploy-kit/.s-home/）：只有缓存、没有秘密；
-# persona 仓库的 gitignore 模板（daemon deploy/templates.ts GITIGNORE_LINES）忽略 .s-home/（缓存不该进仓库）；
-# 本机每次 daemon 启动 mcp/ 整份换新，组件缓存跟着清，下次 publish 重装一次。
+# Derive AccountID through STS and isolate Serverless Devs cache/config under KIT_DIR; do not write credentials.
 ensure_s_access() {
   local kit="${KIT_DIR:?ensure_s_access 需要调用方先设 KIT_DIR}"
   local s_home="$kit/.s-home"
   local ident acc
 
   ident="$(aliyun_ak sts GetCallerIdentity 2>&1)" || {
-    # 别只说「检查凭证」——凭证不对只是可能之一，region 缺失 / CLI 装坏 / 网络不通报的是别的话。
-    # 把 CLI 原文摆出来，让读的人按原文判断。
+    # Preserve CLI diagnostics: identity failures are not necessarily bad credentials.
     echo "❌ aliyun sts GetCallerIdentity 失败，拿不到 AccountId。aliyun 原文：" >&2
     echo "$ident" >&2
     echo "   排查顺序：① 上面这行 CLI 原文说的是什么 ② 进程 env 里的 AK 是否有效（本机 ~/.clawd/secrets/aliyun.env、云上仓库 Secrets）——2026-09-18 之前 OTA 发的那把已泄露、不可再用，得换自己的 ③ config.env 的 REGION" >&2
     return 1
   }
-  # 用 node 不用 python3：目标机器保证有 node（clawd 本身就是 node 跑的），不保证有 python
-  # —— 清理路径尤其不该多一个装不上就跑不了的依赖。
+  # Node is guaranteed by clawd; do not add a Python runtime prerequisite.
   acc="$(printf '%s' "$ident" | node -e 'console.log(JSON.parse(require("fs").readFileSync(0,"utf8")).AccountId)')" || {
     echo "❌ 解析 AccountId 失败,aliyun 输出非 JSON:" >&2
     echo "$ident" >&2
     return 1
   }
 
-  # s 认的三个变量名就是它 access.yaml 里的键名（KEY_PAIR_IMPORTANT），大小写照它的
+  # Serverless Devs credential environment keys are case-sensitive.
   export AccountID="$acc"
   export AccessKeyID="$ALIBABA_CLOUD_ACCESS_KEY_ID"
   export AccessKeySecret="$ALIBABA_CLOUD_ACCESS_KEY_SECRET"
   export serverless_devs_config_home="$s_home"
   mkdir -p "$s_home/.s"
-  # 老版本脚本（2026-09-19 之前）把凭证写在这里；本机残留的顺手删掉，别让一份过期 AK 躺在 persona 目录里
+  # Remove legacy persisted credentials from the kit cache.
   rm -f "$s_home/.s/access.yaml"
 }
 

package/dist/persona-defaults/persona-app-builder/mcp/clawd-app-builder/deploy-kit/scripts/ensure-toolchain.sh

@@ -1,19 +1,7 @@
 #!/usr/bin/env bash
-# ============================================================
-# 确保发布/清理用到的工具链就绪：Serverless Devs (s) + 阿里云 CLI (aliyun)。
-# 检测环境、缺啥装啥、已装则跳过（幂等）。被 publish.sh / remove-extension.sh
-# 在调用 aliyun/s 之前 `source` 进来，再调 ensure_toolchain。
-#
-# 为什么需要它：FC 发布全靠 aliyun CLI + s 两个外部命令，二者都不随 clawd 安装。
-# 新机器上它们不在 PATH → ensure-credentials.sh 的 `aliyun_ak sts ...` stdout 为空 →
-# JSON.parse 空串报错，且死在第一个 ::stage:: marker 之前 → daemon 只能报 [unknown] 阶段。
-# 这个脚本补的就是这一环。
-#
-# 注意它**只装不配**：不会跑 `aliyun configure`，所以机器上不会因此有 `~/.aliyun/config.json`
-# ——凭证由 ensure-credentials.sh 的 aliyun_ak 每次显式传参，不依赖任何本机 profile。
-# ============================================================
+# Source and call ensure_toolchain before credential setup; install missing CLI tools without configuring user profiles.
 
-# aliyun CLI 官方 release 兜底版本（仅在无 brew、走二进制下载时用；brew 路径不读它）。
+# Pinned fallback applies only to direct binary download, not Homebrew.
 CLAWD_ALIYUN_CLI_VERSION="${CLAWD_ALIYUN_CLI_VERSION:-3.3.21}"
 
 ensure_s() {
@@ -26,12 +14,10 @@ ensure_s() {
 ensure_aliyun() {
   command -v aliyun >/dev/null 2>&1 && return 0
   echo "==> 安装阿里云 CLI (aliyun)…"
-  # 优先 brew（有 brew 的 mac 最省事，装到已在 PATH 的 /opt/homebrew/bin | /usr/local/bin）
   if command -v brew >/dev/null 2>&1; then
     brew install aliyun-cli
     return 0
   fi
-  # 兜底：官方 release 二进制（没装 brew 的新机器 / Linux server）。
   local os arch bindir="$HOME/.clawd/bin"
   case "$(uname -s)" in
     Darwin) os=macosx ;;
@@ -57,7 +43,7 @@ ensure_toolchain() {
   ensure_aliyun
 }
 
-# 直接执行（bash ensure-toolchain.sh）= 自检；被 source 时不自动跑，留给调用方显式 ensure_toolchain。
+# Direct execution checks the toolchain; sourcing leaves execution to the caller.
 if [ "${BASH_SOURCE[0]}" = "${0}" ]; then
   set -euo pipefail
   ensure_toolchain

package/dist/persona-defaults/persona-app-builder/mcp/clawd-app-builder/deploy-kit/scripts/new-extension.sh

@@ -1,8 +1,5 @@
 #!/usr/bin/env bash
-# 从模板源目录展开一个新 extension（通用，persona 无关）。
-# 用法: new-extension.sh <name> <模板源目录绝对路径> <目标项目目录绝对路径>
-#   - 模板源目录：persona 的 extension-kit/examples/<tmpl>（daemon 按 persona 解析后传入）
-#   - 目标目录：daemon createProject 已建好（含 .clawd-project.json）的 projects/<name>/
+# Usage: new-extension.sh <name> <template-directory> <precreated-project-directory>
 set -euo pipefail
 
 NAME="${1:?用法: new-extension.sh <name> <模板源目录> <目标目录>}"
@@ -14,20 +11,15 @@ DEST="${3:?缺目标目录}"
   echo "❌ 目标目录无效（必须已存在且含 .clawd-project.json）: $DEST" >&2; exit 1
 }
 
-# 目标须只含 .clawd-project.json（daemon 预建），否则视为脏目录拒绝
+# Refuse to overwrite a project containing anything beyond the daemon-created marker.
 remaining="$(find "$DEST" -mindepth 1 -maxdepth 1 ! -name '.clawd-project.json' -print -quit)"
 [ -z "$remaining" ] || { echo "❌ 目标已有内容（非空目录）: $DEST" >&2; exit 1; }
 
-# 排除 node_modules:模板可能被 install 过,pnpm 的 node_modules 里有指向**模板绝对路径**的软链
-# (tslib 等传递依赖)。cp 到新项目后这些软链 dangling(仍指模板原始路径);而 pnpm install 见
-# node_modules 已在 + lockfile 没变会直接 skip、不重建软链 → 运行/打包时 Cannot find module。
-# 新项目本来就要 install,故 scaffold 一律不拷 node_modules(保留 lockfile 以锁版本)。
+# Exclude node_modules: copied pnpm symlinks can retain template paths, and install may skip rebuilding them.
 rsync -a --exclude='node_modules' "$SRC/" "$DEST/"
 
-# 全局唯一 slug (4 hex chars, ~65k 散列空间)：同名 app 多用户/多副本部署到共享 FC + 共享
-# Supabase 时,FC functionName / 子域名 / SQL 表前缀都得唯一。一次 scaffold 锁定,
-# publish.sh 和 remove-extension.sh 都 source ext.conf 共用同一个 slug。
-# Agent 命名 Supabase 表时务必带上: <APP_NAME>_<SLUG>_<table>（见 CLAUDE.md「后端：supabase」）。
+# Persist a random slug to reduce shared FC/DNS/table name collisions; publish and removal reuse it.
+# Table names must include APP_NAME and SLUG to isolate this extension.
 SLUG="$(openssl rand -hex 2)"
 {
   echo ""
@@ -39,11 +31,7 @@ SLUG="$(openssl rand -hex 2)"
   echo "SLUG=${SLUG}"
 } >> "$DEST/ext.conf"
 
-# 模板里的 *.env.example 只有 ${VAR} 引用没有值（凭据不随 OTA 落进 persona 目录），
-# 这里用**本进程 env**（daemon spawn 时从凭据表注进来的，见 daemon/src/deploy/secret-table.ts）
-# 展开成同目录的 .env，新项目 pnpm dev 就能直接跑。
-# 通用实现（persona 无关）：扫到哪个 ${VAR} 就取哪个同名变量，没有的渲成空串 + 提示，不 fail
-# ——scaffold 不该因为一把 key 没配就整个失败，缺什么在 .env 里一眼看得出来。
+# Render examples from process env, preserving existing files; missing variables warn and become empty.
 render_env_example() {
   local src="$1" dst="${1%.example}"
   local sed_args=() ph var val
@@ -56,14 +44,13 @@ render_env_example() {
       echo "  ⚠️  $(basename "$src") 引用了 \$$var，但本次 scaffold 的环境里没有 → 渲成空串" >&2
     fi
     val="${val//\\/\\\\}"; val="${val//|/\\|}"; val="${val//&/\\&}"
-    # sed BRE 里 `{` `}` 是普通字符，`$` 用 [$] 转成字面量（\$ 后接 \{ 会被当区间量词）
+    # BRE braces are literal; [$] avoids treating the placeholder as a regex anchor.
     sed_args+=(-e "s|[\$]{$var}|$val|g")
   done
   if [ ${#sed_args[@]} -eq 0 ]; then cp "$src" "$dst"; else sed "${sed_args[@]}" "$src" > "$dst"; fi
   echo "  📄 渲染 ${dst#$DEST/}（值来自本次进程 env，不写回模板）"
 }
-# 本地 pnpm dev 一律连 integration 那套表（spec 2026-09-15-app-builder-integration-env-design §3.4）：
-# 这两个值在渲 .env 之前就地定死，不从进程 env 取——scaffold 的环境里就算有同名变量也不该漏进来。
+# Local development always uses integration names, overriding inherited environment values.
 export APP_ENV=integration
 export TABLE_PREFIX="${NAME}_${SLUG}_int_"
 while IFS= read -r f; do render_env_example "$f"; done < <(find "$DEST" -name '*.env.example' -not -path '*/node_modules/*')

package/dist/persona-defaults/persona-app-builder/mcp/clawd-app-builder/deploy-kit/scripts/publish.sh

@@ -1,13 +1,5 @@
 #!/usr/bin/env bash
-# ============================================================
-# 通用一键发布 extension 到阿里云 FC（persona 无关）
-# 用法: publish.sh <extension目录> <persona根目录> <env>
-#   - <persona根目录>: daemon 按 session persona 解析后传入（.../personas/<id>）
-#   - <env>: integration | prod（必填，无默认）。integration 发到 <APP_NAME>-<SLUG>-int（测试地址），
-#     prod 发到 <APP_NAME>-<SLUG>（老地址不变）。见 spec 2026-09-15-app-builder-integration-env-design
-#   - 脚本骨架/bootstrap 来自本脚本所在的 deploy-kit（persona 目录 mcp/clawd-app-builder/ 下）；平台凭证在进程 env
-#   - persona 注入值/占位符/特化逻辑/persona 密钥来自 <persona根>/extension-kit
-# ============================================================
+# Usage: publish.sh <extension-directory> <persona-root> <integration|prod>
 set -euo pipefail
 
 KIT_DIR="$(cd "$(dirname "$0")/.." && pwd)"            # deploy-kit 根（persona 目录 mcp/clawd-app-builder/deploy-kit/）
@@ -16,10 +8,9 @@ EXT_DIR="$(cd "$EXT_DIR" && pwd)"
 PERSONA_ROOT="${2:?缺 persona 根目录}"
 PERSONA_KIT="$PERSONA_ROOT/extension-kit"
 
-# 1) 配置：persona config.env（含平台值+注入值）+ extension 自身 ext.conf（覆盖）
 [ -f "$PERSONA_KIT/config.env" ] && source "$PERSONA_KIT/config.env"
 [ -f "$EXT_DIR/ext.conf" ] && source "$EXT_DIR/ext.conf"
-# env 在 source 之后赋值：位置参数是唯一来源，config.env / ext.conf 里就算写了同名变量也盖不过它
+# Set env after sourcing config: only the positional argument chooses the deployment environment.
 APP_ENV="${3:?缺 env（integration|prod）}"
 case "$APP_ENV" in integration|prod) ;; *) echo "❌ env 只能是 integration|prod，收到：$APP_ENV" >&2; exit 1;; esac
 APP_NAME="${APP_NAME:-$(basename "$EXT_DIR")}"
@@ -27,81 +18,54 @@ CODE_DIR="${CODE_DIR:-./server}"
 FC_ENTRY="${FC_ENTRY:-dist/main.js}"
 BUILD_CMD="${BUILD_CMD:-}"
 
-# 全局唯一身份:APP_NAME (人读身份/表前缀根) + SLUG (4 位散列)。一次性 scaffold 时
-# 由 new-extension.sh 锁定 + bake 进 ext.conf。这里的 fallback 兜底两种历史情况:
-#   1) 老项目 (本改动前 scaffold) ext.conf 无 SLUG → 现场生成 + bake,保后续稳定
-#   2) 手动 rm SLUG 或损坏 ext.conf → 同上,fail-safe
-# 派生 (按 env):
-#   DEPLOY_NAME=${APP_NAME}-${SLUG}[-int]  → FC functionName/子域名/s 项目名 (DNS-safe 连字符)
-#   TABLE_PREFIX=${APP_NAME}_${SLUG}_[int_] → Supabase 表 (SQL-safe 下划线,见 remove-extension.sh)
+# Persist a missing slug before deriving stable deployment and table names.
 if [ -z "${SLUG:-}" ]; then
   SLUG="$(openssl rand -hex 2)"
   printf '\nSLUG=%s\n' "$SLUG" >> "$EXT_DIR/ext.conf"
   echo "  📝 锁定 SLUG=$SLUG (含 4 位散列防同名冲突,已 bake 进 ext.conf)"
 fi
 BASE_NAME="${APP_NAME}-${SLUG}"
-# 环境名 integration / prod 是人读的；进资源名的是短标签 ENV_TAG：int / （prod 为空，保持老地址不变）。
-# 一眼看域名：带 -int 的就是测试环境。派生段与 publish.spec.ts 的 DERIVE_SNIPPET 同步。
+# Keep resource-name derivation aligned with publish.spec.ts DERIVE_SNIPPET.
 if [ "$APP_ENV" = integration ]; then
   ENV_TAG=int;  DEPLOY_NAME="${BASE_NAME}-int"; TABLE_PREFIX="${APP_NAME}_${SLUG}_int_"
 else
   ENV_TAG=prod; DEPLOY_NAME="${BASE_NAME}";     TABLE_PREFIX="${APP_NAME}_${SLUG}_"
 fi
-# 两个环境各自的渲染产物；s 用 name: 键状态，DEPLOY_NAME 不同即隔离。
 S_FILE="s.${ENV_TAG}.yaml"
 echo "  🎯 env=$APP_ENV → $DEPLOY_NAME (表前缀 $TABLE_PREFIX, 渲到 $S_FILE)"
-# 渲出来的 s 文件含 supabase key，靠项目 .gitignore 挡在仓库外。模板已有 s.*.yaml；双环境之前 scaffold 的
-# 存量项目只有 s.yaml 一行，s.int.yaml 会被当源码推上 GitHub——像 bake SLUG 一样幂等地补一行（改了
-# .gitignore 下次 publish 会被「先推再发」拦一次，推上去的只是 .gitignore，无害）。
+# Generated YAML contains secrets; add the wildcard ignore rule for older projects too.
 if ! grep -qxF 's.*.yaml' "$EXT_DIR/.gitignore" 2>/dev/null; then
   printf 's.*.yaml\n' >> "$EXT_DIR/.gitignore"
   echo "  📝 .gitignore 补 s.*.yaml (渲出的 s.int.yaml / s.prod.yaml 含 key，不进仓库；记得把 .gitignore 推上去)"
 fi
 
-# 2) 工具链 + 阿里云凭证（进程 env，本机云上同一条；见 ensure-credentials.sh）
 source "$KIT_DIR/scripts/ensure-toolchain.sh"
 ensure_toolchain
 source "$KIT_DIR/scripts/ensure-credentials.sh"
 ensure_credentials
 
-# 3) persona hook（可选）：校验/导出 persona 特化运行时变量（如 SESSION_SECRET / APP_BASE_URL / persona 密钥）
 if [ -f "$PERSONA_KIT/hooks/pre-deploy.sh" ]; then
   source "$PERSONA_KIT/hooks/pre-deploy.sh"
 fi
 
-# 4) build（框架相关）
 echo "::stage::build"
 if [ -n "$BUILD_CMD" ]; then
   echo "==> build: $BUILD_CMD"
   ( cd "$EXT_DIR" && eval "$BUILD_CMD" )
 fi
 
-# 5) bootstrap（共享，框架无关）
 cp "$KIT_DIR/contract/bootstrap" "$EXT_DIR/$CODE_DIR/bootstrap"
 chmod +x "$EXT_DIR/$CODE_DIR/bootstrap"
 
-# 6) 通用占位符替换渲染 s.yaml：扫 persona s.yaml.tmpl 的所有 __X__，从 env 取同名变量
-#（APP_ENV / TABLE_PREFIX 也走这条：模板里 __APP_ENV__ / __TABLE_PREFIX__ 渲进 FC 的 environmentVariables）
-#
-# 自定义域名段按履约拼接（M1b Step 5c）：APP_DOMAIN_SUFFIX 非空 = 部署级履约（域名与通配符
-# 证书都在我们自己的阿里云账号上）→ 把 s.yaml.domain.tmpl 接上；空 = 使用者自带 key，
-# 发布落在他自己的账号里，那里既没有我们的 DNS 也没有我们的证书 → 整段不渲染，用 FC 默认域名。
-# 拼完再走同一套占位符替换，渲染契约本身不分叉。
 TMPL="$PERSONA_KIT/contract/s.yaml.tmpl"
 [ -f "$TMPL" ] || { echo "❌ 缺 $TMPL" >&2; exit 1; }
-# **判据是「这个 persona 有没有 s.yaml.domain.tmpl」**，不是光看 APP_DOMAIN_SUFFIX：
-# 没有那个文件的 persona（persona-dataclaw-builder）把自定义域名段写死在自己的 s.yaml.tmpl 里，
-# 它压根不参与这套切换，替它选分支只会把它的发布路径改坏。
+# Only personas with a separate domain template participate in domain selection; others keep their own template policy.
 DOMAIN_TMPL="$PERSONA_KIT/contract/s.yaml.domain.tmpl"
 TMPL_RENDER="$TMPL"
 TMPL_COMBINED=""
 if [ -f "$DOMAIN_TMPL" ]; then
   if [ -n "${APP_DOMAIN_SUFFIX:-}" ]; then
-    # mktemp 落 EXT_DIR 之外：占位符缺失时下面直接 exit，别在用户项目目录里留残骸。
-    # **必须写全 XXXXXX 模板**：BSD mktemp（macOS）的 `-t prefix` 会自己补随机后缀，
-    # GNU coreutils（Linux，= M1b 的 Pod）要求模板以 ≥3 个 X 结尾，`mktemp -t s-yaml-tmpl`
-    # 直接 `too few X's in template` 退 1（coreutils 9.1 实测），`set -e` 下当场打死这条
-    # 默认路径。deploy-kit 的脚本两套 userland 都要跑，别用 BSD/GNU 语义有分歧的写法。
+    # Keep temporary templates outside the project and use XXXXXX for both BSD and GNU mktemp.
     TMPL_COMBINED="$(mktemp "${TMPDIR:-/tmp}/s-yaml-tmpl.XXXXXX")"
     trap 'rm -f "$TMPL_COMBINED"' EXIT
     cat "$TMPL" "$DOMAIN_TMPL" > "$TMPL_COMBINED"
@@ -114,19 +78,16 @@ fi
 sed_args=()
 for ph in $(grep -oE '__[A-Z0-9_]+__' "$TMPL_RENDER" | sort -u); do
   var="${ph#__}"; var="${var%__}"
-  # declare -p 测「是否定义」（含空字符串），兼容 bash 3.2；未定义即 fail-loud
+  # declare -p distinguishes missing from empty variables on Bash 3.2.
   if ! declare -p "$var" >/dev/null 2>&1; then
     echo "❌ s.yaml.tmpl 占位符 $ph 无对应 env 变量 \$$var" >&2
-    # 最常见的成因不是「漏配」，而是**这个脚本被手动跑了**：凭据由 daemon 在 spawn 时注进
-    # 它起的那个子进程，别的地方起的 shell 拿不到。把这条写进报错里，是因为读它的下一个
-    # 读者往往是 agent——不给方向它就会去翻凭据、手动 export 或写回 config.env，
-    # 正好把「值不落 persona 目录」这条纪律拆掉。
+    # Missing injected credentials must be fixed through the daemon credential table, never written into templates.
     echo "   如果你是手动跑这个脚本：凭据只注给 daemon 起的那个进程，手动跑必然缺。" >&2
     echo "   正确做法是改调 clawd-app-builder 的 publish tool 重跑；**不要**去找 key 手动 export，也不要写回 config.env。" >&2
     echo "   确实是漏配（新增了占位符 / 换了实例）：改 daemon 的凭据表（~/.clawd/secrets/），不是改模板。" >&2
     exit 1
   fi
-  # 转义 sed 替换串里的特殊字符（密钥/URL 可能含 \ | &），顺序：先 \ 再 | / &
+  # Escape backslashes before the other sed replacement characters.
   val="${!var}"
   val="${val//\\/\\\\}"
   val="${val//|/\\|}"
@@ -135,24 +96,13 @@ for ph in $(grep -oE '__[A-Z0-9_]+__' "$TMPL_RENDER" | sort -u); do
 done
 sed "${sed_args[@]}" "$TMPL_RENDER" > "$EXT_DIR/$S_FILE"
 
-# 7) deploy + verify
 echo "::stage::deploy"
 echo "==> s deploy ($DEPLOY_NAME, env=$APP_ENV)"
 ( cd "$EXT_DIR" && s deploy -y -t "$S_FILE" --access "$S_ACCESS_ALIAS" )
 
 echo "::stage::verify"
-# 产物 URL 怎么取，取决于**这个 persona 参不参与 5c 的域名段方案**（判据同上面渲染那步，
-# 不许各判各的）：
-#   有 s.yaml.domain.tmpl（app-builder）：
-#     APP_DOMAIN_SUFFIX 非空 → 自定义域名，从 custom-domains 精确匹配
-#     APP_DOMAIN_SUFFIX 为空 → 使用者自带 key，FC 默认域名，从 httpTrigger 取
-#   没有（persona-dataclaw-builder 等）：自定义域名段写死在它自己的 s.yaml.tmpl 里，
-#     **原样走老路**——它的 functionName 规则、域名策略都跟这套无关，别替它选分支。
-#
-# JSON 解析用 node 不用 python3：目标机器保证有 node（clawd 本身就是 node 跑的），不保证有
-# python。而且原先 `2>/dev/null | python3 -c` 把 CLI 的 stderr 吞了再让 python 抛
-# JSONDecodeError，`set -e` 下脚本直接崩在 traceback 上，真凶（凭证不对 / 超时）全丢——
-# 下面的 fc_get 保留 CLI 原文并 fail-loud。
+# URL discovery must use the same domain-template predicate as rendering.
+# Preserve CLI stderr before parsing JSON with the guaranteed Node runtime.
 fc_get() {  # fc_get <path>：调 FC OpenAPI；失败把 CLI 原文写 stderr 后 return 1
   local out rc
   out="$(aliyun_ak fc GET "$1" 2>&1)" && rc=0 || rc=$?
@@ -174,16 +124,13 @@ console.log((d.customDomains || []).some((c) => c.domainName === target) ? targe
 PROD_URL=""
 ALLOW_CD=""
 if [ -f "$DOMAIN_TMPL" ] && [ -z "${APP_DOMAIN_SUFFIX:-}" ]; then
-  # 单条 GetTrigger 而不是集合 ListTriggers：triggerName 由 persona 的 s.yaml.tmpl 契约固定
-  # 为 httpTrigger（写死是确定的，不是猜的）。
+  # The template contract fixes the trigger name to httpTrigger.
   PROD_URL="$(fc_get "/2023-03-30/functions/${DEPLOY_NAME}/triggers/httpTrigger" | node -e '
 const d = JSON.parse(require("fs").readFileSync(0, "utf8"));
 console.log((d.httpTrigger && d.httpTrigger.urlInternet) || "");
 ')"
   MISS_HINT="未取到 FC 默认域名（函数 ${DEPLOY_NAME} 的 httpTrigger urlInternet 为空），检查 s deploy 是否真的建出了 httpTrigger"
-  # FC 默认域名（*.fcapp.run）对所有响应强制注入 Content-Disposition: attachment，没有
-  # 自定义域名就消不掉。使用者自带 key 履约的验收口径本来就是「公网可访问即可」
-  # （design ③：per-user 部署用 FC 默认域名，不要求品牌域名），所以降级成警告不判失败。
+  # FC default-domain Content-Disposition is tolerated only on the no-custom-domain path.
   ALLOW_CD="--allow-content-disposition"
 else
   EXPECTED_DOM="${DEPLOY_NAME}.${APP_DOMAIN_SUFFIX:-app.clawos.chat}"