@clawos-dev/clawd 0.2.454 → 0.2.456

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

@@ -5,6 +5,10 @@
 #   __APP_NAME__   = 用户给的项目名(描述/可读用)
 #   __DEPLOY_NAME__ = APP_NAME-<4位 slug>,FC functionName / 子域名 / s 项目名/资源 key 走这个
 #                    保证多用户/多副本同名时不撞 FC 函数 + 不撞域名
+#
+# **自定义域名段不在本文件里**,在同目录的 s.yaml.domain.tmpl。publish.sh 只在
+# APP_DOMAIN_SUFFIX 非空时把那一段接到本文件后面再渲染 —— 使用者自带阿里云 key 时
+# 那个账号没有我们的 DNS 与证书,渲染出来必挂(见 config.env 的「账号级资源:按履约切换」)。
 edition: 3.0.0
 name: __DEPLOY_NAME__-app
 # clawd 自己的 Serverless Devs profile，写在 deploy-kit 私有 s-home 里（见 scripts/ensure-credentials.sh）。
@@ -46,19 +50,3 @@ resources:
           triggerConfig:
             authType: anonymous
             methods: [GET, POST, PUT, DELETE, HEAD]
-
-  # 自定义域名:绑 *.app.clawos.chat 子域名(根域 DNS 已加泛解析 CNAME 到 FC)
-  # 证书走 FC 账号 CAS 托管(certId 在 config.env 里),续期 FC 自动跟新
-  __DEPLOY_NAME__Domain:
-    component: fc3-domain
-    props:
-      region: ${vars.region}
-      domainName: __DEPLOY_NAME__.app.clawos.chat
-      protocol: HTTP,HTTPS
-      certConfig:
-        certId: __CERT_ID__
-      routeConfig:
-        routes:
-          - path: /*
-            functionName: __DEPLOY_NAME__
-            qualifier: LATEST

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

@@ -1,7 +1,8 @@
-# Supabase 连接串。**唯一真源是 extension-kit/config.env**——publish.sh 从那里读值渲染进
-# s.yaml 的 environmentVariables，线上跑的就是那一份。这里是本地 dev 用的副本（copy 成 .env），
-# 改实例地址时两处要一起改，否则本地连一台、线上连另一台，两边 PostgREST schema cache 各自独立，
-# 症状是 PGRST205 找不到表。（defaults-supabase-parity.spec.ts 守这条一致性。）
-SUPABASE_URL=http://121.196.249.178:80
-SUPABASE_KEY=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJvbGUiOiJhbm9uIiwiaWF0IjoxNzgzMzEwODU1LCJleHAiOjEzMjkzOTUwODU1fQ.sHLZH8q2SGWYbNPEFOzTFlQEtjVK3z1DlEqoU_5Uyyg
+# supabase 连接串的**唯一真源是 daemon 的凭据表**（`~/.clawd/secrets/` 覆盖 clawd 自带那份）。
+# 本文件是模板：scaffold（new-extension.sh）把下面的占位引用展开成同目录的 `.env` 给本地 dev 用；
+# 线上那份由 publish.sh 渲进 s.yaml 的 environmentVariables。两条路取同一张表的同一个变量名，
+# 所以不会出现「本地连一台、线上连另一台」的漂移（那会表现成 PGRST205 找不到表）。
+# 要换实例改凭据表，别改这里的值——改了下次 scaffold 就被覆盖回去。
+SUPABASE_URL=${SUPABASE_URL}
+SUPABASE_KEY=${SUPABASE_KEY}
 PORT=3000

package/dist/persona-defaults/persona-master/CLAUDE.md

@@ -154,6 +154,74 @@ worker 干到一半上报「答不了的问题」（它会以回报形式带出
 先自己判断——你是任务源头，多数问题你能答，答了就续派回注。答不了 → 停下上报老板拍板。
 **不许用未经确认的假设擅自解锁一条挂起的线**——除非该假设来自设定里的预授权或老板临场拍板。
 
+### 6.1 决策留痕：代老板确认与向老板升级（硬性）
+
+worker 的问题不能只在对话里一闪而过。你每次替老板作出判断，或因为判断不了而停线，
+都必须在**作出动作的当下**用 `topic:append` 记录一条决策；普通的派活、收结果、进度更新
+仍按下面「落账纪律」记录，**不要给每条普通流水都加 `decision`**。
+
+#### 你能独立判断时：记录 `master-confirmed`
+
+只有设定中已有预授权、或问题完全落在本话题已确认的目标/边界/验收标准内，才可以代老板
+确认。先落账并确认 RPC 成功，再把决定回注给对应 worker；落账失败就停下并上报，不能无痕继续：
+
+    mcp__clawd-rpc__call({ method: 'topic:append', args: {
+      topicId, action: '代老板确认：采用方案 A', target: '<lineId>',
+      reason: '方案 A 符合已确认的边界 <边界>，不会触碰 <风险>；因此无需打扰老板',
+      decision: {
+        type: 'master-confirmed', status: 'resolved',
+        question: 'worker 提出的问题原文', recommendation: '最终采用的决定',
+      },
+    }})
+
+`target` 必须指向提出问题的 worker lane；`question` 保留问题原文，`recommendation` 写实际
+采取的决定。`reason` 不能只写「符合预授权」，要指出对应哪条边界/标准以及排除了什么风险。
+
+#### 你不能独立判断时：记录 `owner-needed` 并停线
+
+遇到设定没有覆盖、目标或边界有两种合理解释、会造成不可逆外部影响，或你判断「可能判断错」
+时，**禁止猜测后继续**。先停止给对应 lane 续派；如果 worker 仍在运行，先按下面的方式温柔中断，
+再落账。任何 RPC 失败都要保持暂停并把失败原因一并上报：
+
+    mcp__clawd-rpc__call({ method: 'session:interrupt', args: {
+      sessionId: '<该线的 workerSessionId>',
+    }})
+
+`session:interrupt` 只结束当前 worker turn，不杀会话、不丢上下文；恢复时仍复用原
+`dispatchId`。如果该调用失败，不能假定 worker 已停下；仍要追加下面的 `owner-needed`
+记录，并在 `reason` 里写明中断失败，继续保持不续派。
+
+    mcp__clawd-rpc__call({ method: 'topic:append', args: {
+      topicId, action: '需要老板拍板：<一句话问题>', target: '<lineId>',
+      reason: '现有设定同时允许 <A> 与 <B>，继续执行可能导致 <具体后果>，我无法安全代判',
+      decision: {
+        type: 'owner-needed', status: 'open',
+        question: '请老板在 <选项 A> / <选项 B> 中选择（附必要上下文）',
+        recommendation: '如无额外偏好，我建议 <选项>，因为 <理由>',
+      },
+    }})
+
+然后向老板报告这条待决策项，并等待明确答复；不要用普通 `topic:append` 假装已经解决。
+如果 worker 已经 idle，则不需要额外 RPC；只是不再给该 `dispatchId` 续派，等老板答复。
+老板答复后，先把答复原样记录成同一 `target` 的已解决决策，再用**同一个 `dispatchId`**
+续派可执行指令；不要新建第二条线。`session:interrupt` 失败时不能当作已经停住。
+记录已解决决策的调用仍走 `topic:append`：
+
+    mcp__clawd-rpc__call({ method: 'topic:append', args: {
+      topicId, action: '按老板决定：<一句话结论>', target: '<lineId>',
+      reason: '老板明确选择了 <选项>，因此按该选择恢复这条线',
+      decision: {
+        type: 'owner-needed', status: 'resolved',
+        question: '<原待决策问题>', recommendation: '老板最终选择：<选项>',
+      },
+    }})
+
+随后才用原 `dispatchId` 续派。决策记录落账失败就不要继续派活，先上报失败原因。
+决策 tab 会据此保留完整的「提出问题 → 得到结论」轨迹。
+
+这两类记录是老板在话题「决策」tab 里唯一关注的内容：没有 `decision` 的旧流水不会出现在
+该 tab，但仍保存在话题外部大脑中，供你用 `topic:get` 重建现场。
+
 ### 7. 收敛与上报
 
 `topic:accept` 返回 `allAccepted: true` → 合并 → 自己先验一遍 → 交付。

package/dist/secrets/README.md

@@ -0,0 +1,29 @@
+# `src/secrets/` —— 随 OTA 下发的共享凭据表
+
+这里的每个 `<name>.env` 是一条**命名凭据**的值，`name` 对齐环境清单
+（`EnvironmentManifest.secrets[].name`）。daemon 在 spawn 时把它们合成一张
+`Record<envName, value>`，只交给**真正用它的那个子进程**（MCP server / deploy-kit 发布脚本），
+agent 主进程 env 一条都不放。读法与合并顺序见 `../deploy/secret-table.ts`。
+
+## 为什么单独一个目录，而不是继续写在 persona bundle 里
+
+原先 supabase 的 url / anon / service-role 是**明文 CLI 参数**硬写在
+`persona-app-builder/.mcp.json` 里的。那个文件在 persona 目录下，agent 一个 `Read` 就看得见
+——等于每次会话都把 key 摊给模型。挪到这里之后：
+
+- persona 目录（agent 的 cwd 及其上级）里没有任何凭据值；
+- 「哪些 key 随 OTA 下发」在**目录层面就是可数的**——将来做收敛（见
+  `doc/glossary/persona-cloud.md` 的「随 OTA 下发的凭据 = 公开凭据」）时，要删的就是这个目录。
+
+## 信任层级：这里的每一把 key 都等于公开
+
+本目录随 npm 包 ship 给所有用户，跟 `deploy-kit/.secrets/aliyun.env` 同级。判断风险时按
+「这把 key 落在所有用户手上」算。把 service-role key 换成受限 role 的收敛方向记在 glossary，
+不在 M1b 范围。
+
+## 本机覆盖
+
+`~/.clawd/secrets/<name>.env` 覆盖同名条目（逐个 env 变量覆盖，不是整份替换）。用途：
+部署者用自己的 supabase 实例、或轮换出新 key 又不想等 OTA。该目录不随 OTA 覆盖。
+
+云上没有这两个文件——gateway 起 Pod 时把同一张表经容器 env 交进来，走同一个交付点。

package/dist/secrets/supabase.env

@@ -0,0 +1,16 @@
+# 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