@clawos-dev/clawd 0.2.620 → 0.2.622

package/dist/persona-defaults/persona-dataclaw-builder/extension-kit/hooks/pre-deploy.sh

@@ -2,7 +2,6 @@
 # dataclaw 发布前置：从生成 app 的 server/.env 读出建页人填的 apikey，export 供 s.yaml 占位符替换。
 # 由 deploy-kit/publish.sh 在渲染 s.yaml 前 source（共享 EXT_DIR/APP_NAME/PERSONA_KIT 等作用域）。
 
-# 建页人提供的 dataclaw apikey 写在生成 app 的 server/.env（DATACLAW_API_KEY）。
 # .env 被 server/.fcignore 排除、不进部署包，所以这里读出来、经 s.yaml 注入 FC 环境变量。
 ENV_FILE="$EXT_DIR/server/.env"
 if [ -f "$ENV_FILE" ]; then
@@ -17,5 +16,4 @@ if [ -z "${DATACLAW_API_KEY:-}" ]; then
 fi
 export DATACLAW_API_KEY
 
-# service url：config.env / ext.conf 已 source 进来；兜底公网地址。
 export DATACLAW_SERVICE_URL="${DATACLAW_SERVICE_URL:-https://120.48.21.36}"

package/dist/persona-defaults/persona-dataclaw-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-dataclaw-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-dataclaw-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-dataclaw-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}"

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

@@ -1,12 +1,7 @@
 #!/usr/bin/env bash
-# ============================================================
-# 清理一个 extension:删 FC 资源(函数+触发器+域名,integration / prod 两套)+ 可选删它的 Supabase 表（通用，persona 无关）
-# 用法: remove-extension.sh <extension目录> <persona根目录>
-# 删哪些表:读 ext.conf 的 SUPABASE_TABLES(extension 自己声明的**基础名**,如 visits;非 supabase persona 留空即跳过)。
-#   每个基础名打两套 DROP:<APP_NAME>_<SLUG>_int_<t>(integration)与 <APP_NAME>_<SLUG>_<t>(prod)。
-#   值若已带完整前缀 <APP_NAME>_<SLUG>_ 视为双环境之前声明的完整表名,只打一条。
-# 安全:① 校验 <APP_NAME>_<SLUG>_ 前缀防误删 clawos / 同名 app 别人副本 ② 列出 DROP 让 agent 用 supabase MCP 接力 ③ 数据不可逆
-# ============================================================
+# Remove published FC resources and print optional database DROP statements for the caller to execute.
+# Legacy fully prefixed table declarations expand once; base names expand for integration and production.
+# Deletion is irreversible: restrict emitted table names to this extension prefix.
 set -euo pipefail
 
 KIT_DIR="$(cd "$(dirname "$0")/.." && pwd)"            # deploy-kit 根（persona 目录 mcp/clawd-app-builder/deploy-kit/）
@@ -19,27 +14,20 @@ PERSONA_KIT="$PERSONA_ROOT/extension-kit"
 [ -f "$EXT_DIR/ext.conf" ] && source "$EXT_DIR/ext.conf"
 APP_NAME="${APP_NAME:-$(basename "$EXT_DIR")}"
 SUPABASE_TABLES="${SUPABASE_TABLES:-}"
-# SLUG 由 new-extension.sh scaffold 时 bake;空 = 老项目(本改动前 scaffold)走 legacy 表前缀。
-# prod 表名形如 ${APP_NAME}_${SLUG}_<table>,integration 多一段 int_;老项目走旧的 ${APP_NAME}_<table>。
+# Missing SLUG retains the legacy project prefix.
 TABLE_PREFIX="${APP_NAME}_${SLUG:+${SLUG}_}"
 TABLE_PREFIX_INT="${TABLE_PREFIX}int_"
 
-# 确保工具链就绪(缺 s / aliyun 则装,已装跳过)—— 下面 s remove 依赖它
 source "$KIT_DIR/scripts/ensure-toolchain.sh"
 ensure_toolchain
 
-# 阿里云凭证（进程 env：本机 daemon 从凭据表渲进 MCP server env，云上 pod-setup 渲）+ deploy-kit 私有的 s profile
 source "$KIT_DIR/scripts/ensure-credentials.sh"
 ensure_credentials
 
-# 1) 删 FC 侧(函数 + 触发器 + 自定义域名):integration / prod 各自有一份 publish.sh 渲的 s 文件
-#（s.int.yaml / s.prod.yaml;双环境之前渲的叫 s.yaml),有哪份删哪份——从未发过的环境没有产物,跳过。
 removed=0
 for s_file in s.int.yaml s.prod.yaml s.yaml; do
   [ -f "$EXT_DIR/$s_file" ] || continue
-  # 老 s.yaml 与 s.prod.yaml 可能指同一个 prod 函数(app-builder:DEPLOY_NAME 不带标签,name: 相同):
-  # 那就只按 s.prod.yaml 拆,对同一资源 s remove 两次第二次会因「不存在」失败。
-  # name: 不同(dataclaw 双环境之前 functionName 不带 slug)= 两个函数,两份都拆。
+  # Avoid removing the same legacy/prod resource twice; different template names still require both removals.
   if [ "$s_file" = s.yaml ] && [ -f "$EXT_DIR/s.prod.yaml" ] \
      && [ "$(grep -m1 '^name:' "$EXT_DIR/s.yaml")" = "$(grep -m1 '^name:' "$EXT_DIR/s.prod.yaml")" ]; then
     continue
@@ -50,14 +38,8 @@ for s_file in s.int.yaml s.prod.yaml s.yaml; do
 done
 [ "$removed" = 1 ] || echo "==> 没有渲染过的 s 文件(从未发布过),FC 侧无资源可删"
 
-# 2) 列出要删的 Supabase 表(脚本不直接调 DB,改打印 DROP 让 agent 用 supabase MCP 跑)。
-# bash 调不到 MCP(MCP 是 LLM 通道),pg 直连要密码 agent 拿不到 —— 最干净:打印 DROP,
-# 让 agent 看到 Bash tool stdout 后用 mcp__supabase__execute_sql 接力。
 if [ -n "$SUPABASE_TABLES" ]; then
-  # 基础名(visits)展开成两套完整表名;已带完整前缀 ${TABLE_PREFIX} 的是 legacy 完整表名,原样一条
-  #(判据用完整前缀而不是 ${APP_NAME}_:基础名本身以 <APP_NAME>_ 开头——shop 的 shop_items——是合法的)。
-  # 安全锁:展开后每个表必须 ${TABLE_PREFIX} 前缀(int 那套自然也满足),否则拒绝
-  #(防误伤 clawos / 同名 app 别人副本的表)。
+  # Match the complete extension prefix, not APP_NAME alone: base names can legitimately start with APP_NAME.
   FULL_TABLES=""
   for t in $SUPABASE_TABLES; do
     case "$t" in

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

@@ -1,17 +1,7 @@
 #!/usr/bin/env bash
-# 发布后健康检查:可达性 + Content-Type + 【是否被强制下载】
-# 用法: verify.sh <url> [--allow-content-disposition]
-#
-# 失败语义（spec 2026-06-03-app-builder-publish-scaffold-design follow-up）：
-#   首页非 200 → exit 1。
-#   检测到 Content-Disposition 强制下载 → 默认 exit 1；带 --allow-content-disposition 时
-#   只警告不失败 —— FC 默认域名（*.fcapp.run）对所有响应强制注入这个头，没有自定义域名就
-#   消不掉，而「使用者自带 key」履约的验收口径本来就只到「公网可访问」（design ③）。
-#   调用方只在那条路径上传这个 flag，别当通用开关用。
-#   publish.sh 不加 `|| true` 兜底，verify 失败会让 publish.sh 整体 exit 非 0，
-#   触发 daemon runner 的 publish-failed 路径：广播帧 + 回灌 chat user_text 让 assistant 接管修复。
-#
-# 信息原则：失败原因 echo 到 stderr（runner 的 errorSummary 抠 stderr 最后 20 行）。
+# Usage: verify.sh <url> [--allow-content-disposition]
+# Fail non-200 responses or Content-Disposition, except the explicit FC default-domain allowance.
+# Write failure reasons to stderr for the daemon error summary.
 set -euo pipefail
 URL="${1:?用法: verify.sh <url> [--allow-content-disposition]}"
 ALLOW_CD=0
@@ -22,7 +12,6 @@ code=$(curl -s -o /dev/null -w "%{http_code}" --max-time 30 "$URL/" || echo 000)
 ctype=$(curl -s -o /dev/null -w "%{content_type}" --max-time 30 "$URL/" || echo "")
 echo "首页: HTTP $code  ($ctype)"
 
-# 关键检查: 有 Content-Disposition 说明会被浏览器当文件下载(没绑自定义域名的典型症状)
 hdr=$(curl -s -D - -o /dev/null --max-time 30 "$URL/" || true)
 has_cd=0
 if echo "$hdr" | grep -qi 'content-disposition'; then
@@ -42,7 +31,6 @@ if [ "$code" = "200" ] && { [ "$has_cd" = "0" ] || [ "$ALLOW_CD" = "1" ]; }; the
   exit 0
 fi
 
-# 失败：原因写 stderr 供 runner 抠成 errorSummary，UI / assistant 都能看清楚
 if [ "$code" != "200" ]; then
   echo "❌ verify failed: 首页 HTTP $code (期望 200)；查 s logs 找原因" >&2
 fi