@clawos-dev/clawd 0.2.207 → 0.2.209-beta.415.57f6599

package/dist/deploy-kit/.secrets/aliyun.env

@@ -1,5 +1,5 @@
 # 阿里云 RAM AccessKey（publish.sh source 这个文件）
 # 在阿里云控制台 → 访问控制 RAM → 用户 → AccessKey 生成
 # 需要权限：AliyunFCFullAccess + AliyunSTSAssumeRoleAccess
-ALIBABA_CLOUD_ACCESS_KEY_ID=LTAI5tAi7P7oySa3ohAzaYbj
-ALIBABA_CLOUD_ACCESS_KEY_SECRET=NS470lOWTLeeAP9RUADXkpKNOrH5QX
+ALIBABA_CLOUD_ACCESS_KEY_ID=LTAI5t5qJRW2xnUXPALffUsc
+ALIBABA_CLOUD_ACCESS_KEY_SECRET=xD1jUDLKnDz7HQ3Z1XFdOpmjbkr9Lf

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

@@ -1,15 +1,14 @@
 {
-  "_comment": "preinstall ship 进 daemon defaults，daemon 启动时 refreshDaemonManagedDirs 把这文件同步到 ~/.clawd*/personas/persona-app-builder/.mcp.json。cc CLI 启动时（cwd=projects/<name>/）会向上找 persona dir 的 .mcp.json 自动加载。用 @aliyun-rds/supabase-mcp-server Mode 2 单实例直连（不再用 aliyun AK），底下接阿里云托管 supabase（公网 endpoint 121.196.249.178:80，项目 ra-ae0i57kef06s6ix / clawd-app-builder，杭州可用区J）。三件套（url + anon + service + jwt）明文写进这里跟旧的 aliyun AK 模式一样属于共享 demo 凭证——该 supabase 实例只承载 clawd demo 数据，泄漏面锁定在这个实例本身（不会波及阿里云账号内其它资源）。旧自建 supabase 120.26.157.138 已退役，旧共享 aliyun AK LTAI5tSebp9pyBLk2nxF5wDg 已 revoke。",
+  "_comment": "preinstall ship 进 daemon defaults，daemon 启动时 refreshDaemonManagedDirs 把这文件同步到 ~/.clawd*/personas/persona-app-builder/.mcp.json。cc CLI 启动时（cwd=projects/<name>/）会向上找 persona dir 的 .mcp.json 自动加载。用 @aliyun-rds/supabase-mcp-server（阿里云 RDS 包装，跟 clawos / lovagent / extension-kit 一致），底下连阿里云自建 supabase 实例 120.26.157.138。AK 是共享 demo 凭证（跟 .secrets/aliyun.env 同性质，PR #808 设计前提），跟 lovagent .mcp.json 用同一把（RDS 权限）。",
   "mcpServers": {
     "supabase": {
       "type": "stdio",
       "command": "npx",
       "args": [
         "@aliyun-rds/supabase-mcp-server",
-        "--supabase-url", "http://121.196.249.178:80",
-        "--supabase-anon-key", "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJvbGUiOiJhbm9uIiwiaWF0IjoxNzgzMzEwODU1LCJleHAiOjEzMjkzOTUwODU1fQ.sHLZH8q2SGWYbNPEFOzTFlQEtjVK3z1DlEqoU_5Uyyg",
-        "--supabase-service-role-key", "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJvbGUiOiJzZXJ2aWNlX3JvbGUiLCJpYXQiOjE3ODMzMTA4NTUsImV4cCI6MTMyOTM5NTA4NTV9.MdlymSh0DaJdiOVRmM3QnukUDtkOf_Eljh8_fpdLi8Q",
-        "--jwt-secret", "P9ThaB8USJCYLQa3tcBB3oYGtKWu95LelFpQD3fo"
+        "--aliyun-ak", "LTAI5tSebp9pyBLk2nxF5wDg",
+        "--aliyun-sk", "DnkOBhZ9pLympYlwcLuQbsaGRIitwG",
+        "--aliyun-region", "cn-hangzhou"
       ]
     }
   }

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

@@ -178,13 +178,13 @@ createProject 成功后 daemon 自动：
 
 ## 后端：supabase MCP
 
-**`supabase`** —— 后端数据/认证/存储，唯一的 MCP 支柱。这份 Supabase **是阿里云托管 supabase 实例**（`http://121.196.249.178:80`），全局 MCP / clawos / lovagent / moltoffer / clawd 都指向这一台。**不是**云上 `supabase.com` 的实例。**旧自建 supabase 120.26.157.138 已退役**，老项目一并迁过来，不再"共用两台"。开工前确认能连上：
+**`supabase`** —— 后端数据/认证/存储，唯一的 MCP 支柱。这份 Supabase **是阿里云自建实例**（`http://120.26.157.138:80`），全局 MCP / clawos / lovagent / moltoffer 都共用这一台。**不是**云上 `supabase.com` 的实例。开工前确认能连上：
 
 - 读表结构、跑 SQL、看 auth 用户都走这个 MCP，不要凭记忆猜 schema
-- 模板里 `extension-kit/config.env` + `server/.env.example` 已对齐这台阿里云托管实例（SUPABASE_URL / SUPABASE_KEY），创建 project 时拷进项目目录的 `.env` 也是同一套
+- 模板里 `extension-kit/config.env` + `server/.env.example` 已对齐这台阿里云自建实例（SUPABASE_URL / SUPABASE_KEY），创建 project 时拷进项目目录的 `.env` 也是同一套
 - **红线**：这是共享生产库。建表 / 迁移前先 `list_tables` 看清现状，新项目的表**必须**用 `${APP_NAME}_${SLUG}_` 前缀沉到 `public` schema（如 `helloworld_a1b2_click_counter`，`APP_NAME` 和 `SLUG` 都从项目 `ext.conf` 读，scaffold 时 bake，**不要自己另起一套 slug**），避免和 clawos / 其它项目 / 别人同名 app 的表撞名；**绝不** drop / alter clawos 已有的表，不确定哪些是 clawos 的就先问老板
 
-**易踩的坑**：MCP 工具连的就是 `121.196.249.178`，假如哪一步把 `.env` / `config.env` 写成云上 `qmhqmopgwsbmfxiqagay.supabase.co`（历史旧默认）或者残留的 `120.26.157.138`（旧自建，已退役），就会**MCP 建表落阿里云 / server 通过 supabase-js 查别处**，两台 PostgREST schema cache 各自独立 → `PGRST205 schema cache 找不到表`。看到 PGRST 系列错码先 `grep -rE 'supabase.co|120\.26\.157\.138'` 自查模板配置，再怀疑 schema cache。
+**易踩的坑**：MCP 工具走阿里云自建那台，假如哪一步把 `.env` / `config.env` 写成云上 `qmhqmopgwsbmfxiqagay.supabase.co`（曾经的旧默认），就会**MCP 建表落阿里云 / server 通过 supabase-js 查云上**，两台 PostgREST schema cache 各自独立 → `PGRST205 schema cache 找不到表`。看到 PGRST 系列错码先 `grep -r supabase.co` 自查模板配置，再怀疑 schema cache。
 
 ## 阿里云凭证：在共享 deploy-kit 的 `.secrets/aliyun.env`，用时现读
 

package/dist/persona-defaults/persona-app-builder/extension-kit/config.env

@@ -8,15 +8,14 @@ REGION=cn-hangzhou
 FC_RUNTIME=custom.debian12
 NODE_LAYER=acs:fc:cn-hangzhou:official:layers/Nodejs22/versions/1
 
-# Supabase(阿里云托管 supabase 实例!建表务必加 <app>_ 前缀沉到 public schema,避免撞名)
-# 公网 endpoint 121.196.249.178:80(项目 ra-ae0i57kef06s6ix / clawd-app-builder,杭州可用区J)
-# 全局 MCP / clawos / lovagent / moltoffer / clawd 都指向这一台。
-# 旧自建 supabase 120.26.157.138 已退役,老项目也一起迁到这里,不再"共用两台"。
+# Supabase(clawos 共享阿里云自建实例!建表务必加 <app>_ 前缀沉到 public schema,绝不动 clawos 已有表)
+# 注意:这是阿里云自建 supabase(120.26.157.138),不是云上 supabase.com 实例 ——
+# 全局 MCP / clawos / lovagent / moltoffer 都共用这一台,跟 supabase MCP 操作的也是这台。
 # 之前误指云上 qmhqmopgwsbmfxiqagay.supabase.co 导致 MCP 建表落阿里云,server 走 supabase-js
-# 查云上,两台 PostgREST schema cache 独立 → PGRST205 找不到表。托管后同样要盯紧 .env 别串。
-SUPABASE_URL=http://121.196.249.178:80
-# anon/publishable key(公开可暴露,客户端用)。阿里云托管实例的 anon key,跟 supabase MCP 用同一把。
-SUPABASE_KEY=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJvbGUiOiJhbm9uIiwiaWF0IjoxNzgzMzEwODU1LCJleHAiOjEzMjkzOTUwODU1fQ.sHLZH8q2SGWYbNPEFOzTFlQEtjVK3z1DlEqoU_5Uyyg
+# 查云上,两台 PostgREST schema cache 独立 → PGRST205 找不到表。
+SUPABASE_URL=http://120.26.157.138:80
+# anon/publishable key(公开可暴露,客户端用)。阿里云自建实例无 project-ref 概念。
+SUPABASE_KEY=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJvbGUiOiJhbm9uIiwiaWF0IjoxNzY3OTU0MTY0LCJleHAiOjEzMjc4NTk0MTY0fQ.quOr1bQZ2OCQ49_UCto8LGY-n90Hlku1IbJYltFVWPc
 
 # FC 资源规格(够跑轻量 extension;按需改)
 FC_CPU=0.35

package/package.json

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