@clawos-dev/clawd 0.2.546 → 0.2.548

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 下发（本机 ~/.clawd/secrets/supabase.env，云上 gateway 注入），来龙去脉见 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。 clawd-app-builder：本 persona 自己的 stdio MCP（design 2026-09-19-persona-mcp-single-source §3.2）——项目 scaffold / 发布 / 拆除三件必须持宿主凭据的事在它进程里做。代码在本目录 `mcp/clawd-app-builder/`（mcp-server.cjs + deploy-kit/，daemon 构建时由 copy-defaults 放进 persona-defaults、每次启动整份换新）；args 里的 `${CLAWD_PERSONA_DIR}` 是 args 唯一放行的占位（persona 目录不是凭据），本机 daemon / 云上 pod-setup 渲成绝对路径；使用者工作区不在这里写，插件读宿主 env `CLAWD_WORK_DIR`。env 只列它要的四个：kit 模板渲进项目 .env / FC 环境的 SUPABASE_URL / SUPABASE_KEY（anon key），publish / remove 脚本要的两个阿里云 AK——本机放 ~/.clawd/secrets/{supabase,aliyun}.env，云上来自仓库 Secrets。",
   "mcpServers": {
     "github": {
       "type": "http",
@@ -11,12 +11,27 @@
     "supabase": {
       "type": "stdio",
       "command": "npx",
-      "args": ["@aliyun-rds/supabase-mcp-server"],
+      "args": [
+        "@aliyun-rds/supabase-mcp-server"
+      ],
       "env": {
         "SUPABASE_URL": "${SUPABASE_URL}",
         "SUPABASE_ANON_KEY": "${SUPABASE_ANON_KEY}",
         "SUPABASE_SERVICE_ROLE_KEY": "${SUPABASE_SERVICE_ROLE_KEY}"
       }
+    },
+    "clawd-app-builder": {
+      "type": "stdio",
+      "command": "node",
+      "args": [
+        "${CLAWD_PERSONA_DIR}/mcp/clawd-app-builder/mcp-server.cjs"
+      ],
+      "env": {
+        "SUPABASE_URL": "${SUPABASE_URL}",
+        "SUPABASE_KEY": "${SUPABASE_KEY}",
+        "ALIBABA_CLOUD_ACCESS_KEY_ID": "${ALIBABA_CLOUD_ACCESS_KEY_ID}",
+        "ALIBABA_CLOUD_ACCESS_KEY_SECRET": "${ALIBABA_CLOUD_ACCESS_KEY_SECRET}"
+      }
     }
   }
 }

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

@@ -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` 定位
-- **发布脚本在共享 deploy-kit**（`$HOME/.clawd/deploy-kit/`，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 每次启动整份换新）。这些脚本**一律由 `clawd-app-builder` 的 tool 起，你不要自己 `bash` 它们**——supabase 的 url / key 只在那个 tool 进程的 env 里，你起的 Bash 拿不到，脚本会停在「占位符无对应 env 变量」
 
 ## 何时找你
 
@@ -111,18 +111,17 @@
 - 工具链 `aliyun` CLI + Serverless Devs（`s`）由 `deploy-kit/scripts/ensure-toolchain.sh` 在 publish / remove 前自动检测 + 安装，接管发布失败时**不必再排查「CLI 没装」**
 - 实时推送用 Supabase Realtime（FC 不维持长连接）
 
-## 阿里云凭证：使用者自带，放共享 deploy-kit 的 `.secrets/`
+## 阿里云凭证：进凭据表，不放文件
 
-clawd **不随包 ship 任何一把 AK**。AK/SK 放在 `$HOME/.clawd/deploy-kit/.secrets/`、全 FC persona 共用，不在系统环境变量里：
+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 已泄露、不可再用；读法已删）。
 
-- **`aliyun.env.local`** — 使用者自己的 AK，永远不被 OTA 覆盖。复制 `aliyun.env.local.example` → `aliyun.env.local` 填值
-- **`aliyun.env`**（可有可无）— 也会被读，`.local` 覆盖它。老机器上 2026-09-18 之前 OTA 留下的这份里的 AK 已泄露、不可再用
-- 云上没有这两个文件，AK 由 gateway 经 MCP server 的 env 注入
-
-手动排障要跑 `aliyun` / `s` 命令时，在**同一条 Bash** 里加载再用（shell 变量不跨调用留存）：
+手动排障要跑 `aliyun` / `s` 命令时，在**同一条 Bash** 里把 AK 与 config.env 加载进 env 再用（shell 变量不跨调用留存）：
 
 ```bash
-export KIT_DIR="$HOME/.clawd/deploy-kit"
+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

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

@@ -6,15 +6,14 @@
 
 FC 对应用只有一条要求:**一个监听 `$PORT` 的 HTTP server**。所以固化的是「发布管道」,不是技术栈。
 
-- **共享 deploy-kit(凭证 + 脚本骨架 + bootstrap,全 FC persona 一份)**:`$HOME/.clawd/deploy-kit/`(`scripts/` + `contract/bootstrap` + `.secrets/aliyun.env.local`)
+- **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`)
 
 ## 目录
 
 ```
-# 共享 deploy-kit($HOME/.clawd/deploy-kit/,daemon 维护,全 persona 共用)
+# 本 persona 的 deploy-kit($HOME/.clawd/personas/persona-app-builder/mcp/clawd-app-builder/deploy-kit/,daemon 维护)
 deploy-kit/
-├── .secrets/aliyun.env.local  阿里云凭证(单源,使用者自己写;bundle 只带 *.example)
 ├── contract/bootstrap      FC 启动入口(Node 参考实现:find node + cd + exec)
 └── scripts/
     ├── new-extension.sh    从示例生成新 extension(纯 copy,daemon 自动跑)
@@ -31,10 +30,10 @@ extension-kit/
 
 ## 用法
 
-日常发布 happy path 由 daemon 自动跑(createProject 内联 scaffold、「发布上线」按钮触发 publish),你一般不手动调脚本。需手动跑时(如发布失败接管)用共享 deploy-kit 的绝对路径,**第二参是本 persona 根**:
+日常发布 happy path 由 daemon 自动跑(createProject 内联 scaffold、「发布上线」按钮触发 publish),你一般不手动调脚本。需手动跑时(如发布失败接管)用本 persona 目录下 deploy-kit 的绝对路径,**第二参是本 persona 根**:
 
 ```bash
-PR="$HOME/.clawd/personas/persona-app-builder"; DK="$HOME/.clawd/deploy-kit"
+PR="$HOME/.clawd/personas/persona-app-builder"; DK="$HOME/.clawd/personas/persona-app-builder/mcp/clawd-app-builder/deploy-kit"
 
 # 1) scaffold(daemon 已自动跑;手动签名: new-extension.sh <name> <模板源目录> <目标目录>)
 
@@ -61,7 +60,7 @@ PR="$HOME/.clawd/personas/persona-app-builder"; DK="$HOME/.clawd/deploy-kit"
 ## 清理一个 extension
 
 ```bash
-"$HOME/.clawd/deploy-kit/scripts/remove-extension.sh" <projDir> "$HOME/.clawd/personas/persona-app-builder"
+"$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` 删它的表。
@@ -92,7 +91,7 @@ PR="$HOME/.clawd/personas/persona-app-builder"; DK="$HOME/.clawd/deploy-kit"
 
 ### ⚠️ bootstrap 归 daemon 管,改了会被还原
 
-`publish.sh` 用的是**共享 deploy-kit** 那份:`$HOME/.clawd/deploy-kit/contract/bootstrap`
+`publish.sh` 用的是**本 persona 的 deploy-kit** 那份:`mcp/clawd-app-builder/deploy-kit/contract/bootstrap`
 (不是本目录下的)。而 `deploy-kit/contract/` 和本 `extension-kit/` 一样,**每次 daemon 启动
 都会被 bundle 版本无条件覆盖**——就地改它,下次重启就没了,而且没有 `.secrets/*.local`
 那样的个人 override 豁免。

package/dist/persona-defaults/persona-app-builder/extension-kit/contract/s.yaml.tmpl

@@ -14,9 +14,10 @@
 # 那个账号没有我们的 DNS 与证书,渲染出来必挂(见 config.env 的「账号级资源:按履约切换」)。
 edition: 3.0.0
 name: __DEPLOY_NAME__-app
-# clawd 自己的 Serverless Devs profile，写在 deploy-kit 私有 s-home 里（见 scripts/ensure-credentials.sh）。
+# clawd 自己的 Serverless Devs access：s 从进程 env（AccountID / AccessKeyID / AccessKeySecret）合成的那份，
+# 固定叫 $system_environment_access（见 deploy-kit/scripts/ensure-credentials.sh）；publish.sh 调 s 时还会显式 --access 覆盖这里。
 # 刻意不用 default —— 那是用户自己账号的 profile，不该被 clawd 读也不该被 clawd 写。
-access: clawd-fc
+access: $system_environment_access
 
 vars:
   region: __REGION__

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

@@ -0,0 +1,96 @@
+#!/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 名下，但那里只剩组件缓存和日志，没有凭证。
+# ============================================================
+
+# 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）照样走这条。
+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。
+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
+    return 1
+  fi
+  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
+aliyun_ak() {
+  aliyun --mode AK \
+    --access-key-id "${ALIBABA_CLOUD_ACCESS_KEY_ID:?aliyun_ak 需要先 ensure_aliyun_env}" \
+    --access-key-secret "${ALIBABA_CLOUD_ACCESS_KEY_SECRET:?aliyun_ak 需要先 ensure_aliyun_env}" \
+    --region "${ALIBABA_CLOUD_REGION_ID:?aliyun_ak 需要先 ensure_aliyun_env}" \
+    "$@"
+}
+
+# 把 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 重装一次。
+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 原文摆出来，让读的人按原文判断。
+    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
+  # —— 清理路径尤其不该多一个装不上就跑不了的依赖。
+  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），大小写照它的
+  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 目录里
+  rm -f "$s_home/.s/access.yaml"
+}
+
+ensure_credentials() {
+  ensure_aliyun_env
+  ensure_s_access
+}

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

@@ -5,12 +5,12 @@
 #   - <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
+#   - 脚本骨架/bootstrap 来自本脚本所在的 deploy-kit（persona 目录 mcp/clawd-app-builder/ 下）；平台凭证在进程 env
 #   - persona 注入值/占位符/特化逻辑/persona 密钥来自 <persona根>/extension-kit
 # ============================================================
 set -euo pipefail
 
-KIT_DIR="$(cd "$(dirname "$0")/.." && pwd)"            # 共享 deploy-kit 根
+KIT_DIR="$(cd "$(dirname "$0")/.." && pwd)"            # deploy-kit 根（persona 目录 mcp/clawd-app-builder/deploy-kit/）
 EXT_DIR="${1:?用法: publish.sh <extension目录> <persona根目录> <env>}"
 EXT_DIR="$(cd "$EXT_DIR" && pwd)"
 PERSONA_ROOT="${2:?缺 persona 根目录}"
@@ -58,7 +58,7 @@ if ! grep -qxF 's.*.yaml' "$EXT_DIR/.gitignore" 2>/dev/null; then
   echo "  📝 .gitignore 补 s.*.yaml (渲出的 s.int.yaml / s.prod.yaml 含 key，不进仓库；记得把 .gitignore 推上去)"
 fi
 
-# 2) 工具链 + 阿里云凭证（使用者自己的 .secrets/aliyun.env.local，云上是 env；见 ensure-credentials.sh）
+# 2) 工具链 + 阿里云凭证（进程 env，本机云上同一条；见 ensure-credentials.sh）
 source "$KIT_DIR/scripts/ensure-toolchain.sh"
 ensure_toolchain
 source "$KIT_DIR/scripts/ensure-credentials.sh"

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

@@ -9,7 +9,7 @@
 # ============================================================
 set -euo pipefail
 
-KIT_DIR="$(cd "$(dirname "$0")/.." && pwd)"            # 共享 deploy-kit 根
+KIT_DIR="$(cd "$(dirname "$0")/.." && pwd)"            # deploy-kit 根（persona 目录 mcp/clawd-app-builder/deploy-kit/）
 EXT_DIR="${1:?用法: remove-extension.sh <extension目录> <persona根目录>}"
 EXT_DIR="$(cd "$EXT_DIR" && pwd)"
 PERSONA_ROOT="${2:?缺 persona 根目录}"
@@ -28,7 +28,7 @@ TABLE_PREFIX_INT="${TABLE_PREFIX}int_"
 source "$KIT_DIR/scripts/ensure-toolchain.sh"
 ensure_toolchain
 
-# 阿里云凭证（使用者自己的 .secrets/aliyun.env.local，云上是 env）+ deploy-kit 私有的 s profile
+# 阿里云凭证（进程 env：本机 daemon 从凭据表渲进 MCP server env，云上 pod-setup 渲）+ deploy-kit 私有的 s profile
 source "$KIT_DIR/scripts/ensure-credentials.sh"
 ensure_credentials