@scemoon/cdh 1.0.8 → 1.0.9-beta.2

package/ai-dlc-skill/cross-tool/onecode/export.sh

@@ -0,0 +1,27 @@
+#!/bin/bash
+# Registers ai-dlc-skill for OneCode via symlink
+
+set -euo pipefail
+
+CANONICAL_SKILL_DIR="${HOME}/.cdh/skills/ai-dlc-skill"
+DEV_SKILL_DIR="$(cd "$(dirname "$0")/../.." && pwd)"
+
+if [ -d "$CANONICAL_SKILL_DIR" ]; then
+    SKILL_DIR="$CANONICAL_SKILL_DIR"
+else
+    SKILL_DIR="$DEV_SKILL_DIR"
+fi
+
+ONECODE_SKILLS_DIR="${HOME}/.onecode/skills"
+SYMLINK_TARGET="$ONECODE_SKILLS_DIR/ai-dlc-skill"
+
+mkdir -p "$ONECODE_SKILLS_DIR"
+
+if [ ! -L "$SYMLINK_TARGET" ]; then
+  ln -s "$SKILL_DIR" "$SYMLINK_TARGET"
+  echo "Created symlink: $SYMLINK_TARGET -> $SKILL_DIR"
+else
+  echo "Symlink already exists: $SYMLINK_TARGET"
+fi
+
+echo "ai-dlc-skill registered for OneCode"

package/ai-dlc-skill/cross-tool/opencode/export.sh

@@ -0,0 +1,38 @@
+#!/bin/bash
+# Registers ai-dlc-skill for OpenCode via symlink + config check
+
+set -euo pipefail
+
+CANONICAL_SKILL_DIR="${HOME}/.cdh/skills/ai-dlc-skill"
+DEV_SKILL_DIR="$(cd "$(dirname "$0")/../.." && pwd)"
+PROJECT_ROOT="$(cd "$DEV_SKILL_DIR/.." && pwd)"
+
+if [ -d "$CANONICAL_SKILL_DIR" ]; then
+    SKILL_DIR="$CANONICAL_SKILL_DIR"
+else
+    SKILL_DIR="$DEV_SKILL_DIR"
+fi
+
+OPENCODE_DIR="$PROJECT_ROOT/.opencode"
+SYMLINK_TARGET="$OPENCODE_DIR/skills/ai-dlc-skill"
+
+mkdir -p "$OPENCODE_DIR/skills"
+
+if [ ! -L "$SYMLINK_TARGET" ]; then
+  ln -s "$SKILL_DIR" "$SYMLINK_TARGET"
+  echo "Created symlink: $SYMLINK_TARGET -> $SKILL_DIR"
+else
+  echo "Symlink already exists: $SYMLINK_TARGET"
+fi
+
+CONFIG="$OPENCODE_DIR/config.json"
+if [ -f "$CONFIG" ]; then
+  if grep -q '"skills"' "$CONFIG" 2>/dev/null; then
+    echo "skills.paths already configured in $CONFIG"
+  else
+    echo "WARNING: config.json missing skills.paths. Add:"
+    echo '  "skills": { "paths": [".opencode/skills"] }'
+  fi
+fi
+
+echo "ai-dlc-skill registered for OpenCode"

package/ai-dlc-skill/phases/debug/entry.md

@@ -0,0 +1,48 @@
+---
+name: ai-dlc-debug
+description: "Debug Phase: TCB/云函数日志排查 → 问题定位与追踪"
+entry_point: phases/debug/entry.md
+triggers:
+  - debug
+  - tcb-debug
+  - tcb-logs
+  - 排查日志
+  - 日志排查
+  - requestId
+  - 调用链
+---
+
+# Debug Phase (调试)
+
+TCB 云函数日志排查、requestId 追踪、CLS 日志检索。
+
+## Lifecycle
+
+See `lifecycle.md` for the full phase flow.
+
+## 当被委派时
+
+0. 确认排查目标（函数名、requestId、环境）
+1. 收集环境信息 `tcb env info`
+2. 列出函数 `tcb fn list --env $TCB_ENV_ID`
+3. 基础日志查询 `tcb fn logs --name <fn> --limit 50`
+4. **如有 requestId**：通过 CLS 控制台或 API 查询调用链
+5. 分析日志输出，定位问题根因
+6. 输出诊断报告与修复建议
+
+## 产出
+
+- 问题定位报告
+- 相关日志片段
+- 修复建议
+
+## TCB Debug Decision Tree
+
+```
+需要排查 TCB 问题？
+├── 函数部署/运行问题 → tcb fn logs / tcb fn invoke
+├── 需要追踪特定请求 → CLS 日志检索 (requestId)
+├── 数据库问题 → tcb db query
+├── 托管/静态网站问题 → tcb hosting detail
+└── MCP 连接问题 → cdh cloudbase status
+```

package/ai-dlc-skill/phases/debug/lifecycle.md

@@ -0,0 +1,284 @@
+# AI-DLC Phase 5: Debug (调试)
+
+TCB 云函数日志排查与 requestId 追踪。
+
+## Goal
+
+通过系统化的日志排查流程，快速定位 TCB 云函数问题根因：
+- 函数部署失败
+- 函数执行异常/超时
+- 特定请求调用链追踪
+- 数据库/存储操作问题
+
+## Flow
+
+```
+接收排查任务 (requestId / 函数名 / 环境)
+    │
+    ▼
+收集环境信息
+    - tcb env info
+    - tcb env list
+    │
+    ▼
+确认函数状态
+    - tcb fn list --env $TCB_ENV_ID
+    - tcb fn detail --name <fn> --env $TCB_ENV_ID
+    │
+    ▼
+基础日志查询 (无 requestId 时)
+    - tcb fn logs --name <fn> --limit 50 --env $TCB_ENV_ID
+    - tcb fn logs --name <fn> --keyword error --env $TCB_ENV_ID
+    │
+    ▼
+高级日志查询 (有 requestId 时) → CLS
+    - 控制台: SCF_logset → SCF_RequestId:<requestId>
+    - 或 API: cdh cls search --request-id <id> --function <fn>
+    │
+    ▼
+分析日志输出
+    - SCF_RequestId, SCF_Message, SCF_Duration, SCF_StatusCode
+    - 定位错误行、耗时、调用链
+    │
+    ▼
+输出诊断报告
+    - 问题根因
+    - 相关日志片段
+    - 修复建议
+```
+
+## Method 1: CLI 基础日志查询
+
+### 环境检查
+
+```bash
+tcb env info
+tcb env list
+```
+
+### 函数列表与详情
+
+```bash
+tcb fn list --env $TCB_ENV_ID
+tcb fn detail --name <function-name> --env $TCB_ENV_ID
+```
+
+### 函数日志 (TCB CLI)
+
+```bash
+tcb fn logs --name <function-name> --env $TCB_ENV_ID
+tcb fn logs --name <function-name> --limit 100 --env $TCB_ENV_ID
+tcb fn logs --name <function-name> --keyword error --env $TCB_ENV_ID
+tcb fn logs --name <function-name> --tail --env $TCB_ENV_ID
+```
+
+**限制**: TCB CLI `tcb fn logs` 不支持通过 requestId 查询。
+
+## Method 2: CLS 日志检索 (requestId 追踪)
+
+### 为什么需要 CLS
+
+腾讯云 SCF 日志自动投递至日志服务 CLS，支持：
+- 通过 `SCF_RequestId` 检索特定调用
+- 时间范围检索
+- 多条件组合检索
+- 调用链分析
+
+### CLS 控制台查询 (手动)
+
+1. 登录 [腾讯云日志服务控制台](https://console.cloud.tencent.com/cls)
+2. 选择地域（与 SCF 函数相同）
+3. 进入 `SCF_logset` 日志集
+4. 选择对应的日志主题：`SCF_logtopic_{函数名}_{命名空间}`
+5. 检索条件：
+   ```
+   SCF_RequestId:req-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
+   ```
+
+### CLS 日志字段
+
+| 字段名 | 类型 | 含义 |
+|--------|------|------|
+| `SCF_RequestId` | text | 请求 ID（调用链追踪键） |
+| `SCF_FunctionName` | text | 函数名称 |
+| `SCF_Namespace` | text | 命名空间 |
+| `SCF_Message` | text | 日志内容 |
+| `SCF_StartTime` | long | 调用开始时间 (Unix ms) |
+| `SCF_Duration` | long | 运行时间 (ms) |
+| `SCF_StatusCode` | long | HTTP 状态码 |
+| `SCF_Level` | text | 日志级别 (INFO/WARN/ERROR) |
+| `SCF_MemUsage` | double | 内存使用 (bytes) |
+| `SCF_RetryNum` | long | 重试次数 |
+
+### CLI + CLS API 查询 (自动化)
+
+使用 `cdh cls search` 工具：
+
+```bash
+cdh cls search --request-id req-xxxxx --function hello --env $TCB_ENV_ID
+cdh cls search --function hello --keyword error --limit 100 --env $TCB_ENV_ID
+cdh cls search --function hello --start-time "2026-08-04 10:00:00" --end-time "2026-08-04 12:00:00"
+```
+
+### Python API 调用
+
+```python
+from cdh.tools.cls_search import CLSLogSearcher
+
+searcher = CLSLogSearcher(region="ap-shanghai")
+
+# 通过 requestId 查询
+logs = searcher.search_by_request_id(
+    request_id="req-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
+    function_name="hello"
+)
+
+# 关键词查询
+logs = searcher.search_scf_logs(
+    query="ERROR",
+    function_name="hello",
+    limit=100
+)
+
+for log in logs:
+    print(f"[{log['time']}] {log['message']}")
+```
+
+## Method 3: SCF 控制台查询
+
+1. 进入 [SCF 控制台](https://console.cloud.tencent.com/scf)
+2. 选择函数 → **日志页签**
+3. 点击 **高级检索**
+4. 输入检索条件：`SCF_RequestId:req-xxxxx`
+
+## Debug Workflow Examples
+
+### Workflow: 函数执行报错
+
+```bash
+# 1. 获取函数详情
+tcb fn detail --name hello --env $TCB_ENV_ID
+
+# 2. 查看最近日志
+tcb fn logs --name hello --limit 100 --env $TCB_ENV_ID
+
+# 3. 查看错误日志
+tcb fn logs --name hello --keyword error --env $TCB_ENV_ID
+
+# 4. 重新调用并观察
+tcb fn invoke --name hello --params '{}' --env $TCB_ENV_ID
+```
+
+### Workflow: 特定请求调用链追踪
+
+```bash
+# 1. 获取 requestId（通常在错误响应或客户端日志中）
+# 例如: req-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
+
+# 2. CLS 控制台查询
+# 登录 https://console.cloud.tencent.com/cls
+# 检索: SCF_RequestId:req-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
+
+# 3. 或使用 CLI/API
+cdh cls search --request-id req-xxxxxxxx --function hello --limit 50
+```
+
+### Workflow: 性能问题排查
+
+```bash
+# 1. 查看超时/慢请求日志
+tcb fn logs --name hello --limit 100 --env $TCB_ENV_ID
+
+# 2. 通过 CLS 查询耗时
+# 检索条件: SCF_FunctionName:hello AND SCF_Duration:>5000
+
+# 3. 查看内存使用
+# 检索条件: SCF_FunctionName:hello AND SCF_MemUsage:>1000000000
+```
+
+## MCP Tool 调用
+
+当 MCP server 连接时，可使用：
+
+```javascript
+// 获取函数日志 (TCB MCP)
+const logs = await MCPTool(server="cloudbase", tool="get_function_logs", arguments={
+  name: "hello",
+  envId: "env-xxxxx",
+  limit: 50
+});
+
+// CLS 日志检索 (需额外配置)
+const traces = await MCPTool(server="cloudbase", tool="search_logs", arguments={
+  requestId: "req-xxxxx",
+  functionName: "hello",
+  region: "ap-shanghai"
+});
+```
+
+## Output Template
+
+```markdown
+# TCB Debug Report
+
+## 问题概述
+- **函数**: <function-name>
+- **环境**: <env-id>
+- **时间**: <timestamp>
+- **问题类型**: <deployment/ invocation/ timeout/ error>
+
+## 环境信息
+```
+<tcb env info 输出>
+```
+
+## 函数状态
+```
+<tcb fn detail 输出>
+```
+
+## 日志分析
+### 基础日志
+```
+<相关日志片段>
+```
+
+### CLS 调用链 (如有 requestId)
+```
+<requestId 关联日志>
+```
+
+## 根因分析
+<问题根因描述>
+
+## 修复建议
+1. <建议1>
+2. <建议2>
+3. <建议3>
+
+## 相关链接
+- [SCF 控制台](https://console.cloud.tencent.com/scf)
+- [CLS 日志服务](https://console.cloud.tencent.com/cls)
+- [函数详情](https://console.cloud.tencent.com/scf/detail/<region>/<env-id>/<function-name>)
+```
+
+## 常见问题快速检索
+
+| 场景 | 检索条件 |
+|------|----------|
+| 特定请求追踪 | `SCF_RequestId:<requestId>` |
+| 错误日志 | `SCF_Message:error OR SCF_Level:ERROR` |
+| 超时请求 | `SCF_Duration:>60000` |
+| 内存超限 | `SCF_MemUsage:>1536000000` |
+| HTTP 5xx | `SCF_StatusCode:>=500` |
+| 特定函数 | `SCF_FunctionName:<functionName>` |
+| 特定命名空间 | `SCF_Namespace:<namespace>` |
+
+## Gate
+
+**排查完成标准:**
+- [ ] 环境信息已确认
+- [ ] 函数状态已确认
+- [ ] 相关日志已获取
+- [ ] 问题根因已定位
+- [ ] 修复建议已给出

package/ai-dlc-skill/phases/deliver/entry.md

@@ -0,0 +1,35 @@
+---
+name: ai-dlc-deliver
+description: "Deliver Phase: Stack Preview → e2e → Production + BVT"
+entry_point: phases/deliver/entry.md
+triggers:
+  - deliver
+  - deploy
+  - release
+---
+
+# Deliver Phase (交付)
+
+Deploy full stack, run cross-stack e2e, human approval, production BVT.
+
+## Lifecycle
+
+See `lifecycle.md` for the full phase flow.
+See `rules.md` for enforceable rules (DLV-001 to DLV-004 + STK-001 to STK-006).
+See `prompt.md` for the sub-agent delegation prompt template.
+
+## 当被委派时
+
+0. 先调用 `TodoClear` 清除上阶段遗留的 todos，确保从空白计划开始
+1. `aidlc/tools/deploy_stack.sh --env preview` 统一部署
+2. 运行 per-component e2e + cross-stack e2e
+3. Staging 部署 + smoke test
+4. Human approval gate
+5. Production 部署 + BVT + 自动回滚
+
+## 产出
+
+- `STACK_URL` / `BACKEND_URL`
+- 各组件 e2e 报告
+- 跨栈 e2e 报告
+- Stack BVT 报告

package/ai-dlc-skill/phases/deliver/lifecycle.md

@@ -0,0 +1,185 @@
+# AI-DLC Phase 4: Deliver (交付)
+
+Deploy the **full stack** together, verify per-component and cross-stack e2e against the unified preview, release with stack-level BVT.
+
+## Goal
+
+Deliver verified code to production as a coherent stack with full confidence — preview environment, per-component e2e, cross-stack e2e, stack-level BVT, and rollback at the stack level.
+
+## Flow
+
+```
+All Verify gates passed (per-component + contract + cross-stack)
+  │
+  ▼
+Unified Stack Preview Deploy (dynamic URL from cloud provider)
+  - backend (functions + DB migrate)
+  - web (hosting build with BACKEND_URL)
+  - native (build with BACKEND_URL; package + upload)
+  - desktop (build with BACKEND_URL; package + upload)
+  - wxa / mya / tta (build with BACKEND_URL; upload to mini-program platform)
+  │
+  ▼
+Per-component BDD e2e (against component preview URL or stack URL)
+  │
+  ▼
+Cross-stack e2e (full app ↔ web ↔ backend against unified stack URL)
+  │
+  ▼
+Staging Stack Deploy + Smoke
+  │
+  ▼
+Human Approval Gate
+  │
+  ▼
+Production Stack Deploy (whole stack as one unit)
+  │
+  ▼
+Stack BVT (Build Verification Test) — backend /health, app launch probe, web smoke, DB
+  │
+  ▼
+Archive: contract-diff.md + e2e reports + BVT report
+  │
+  ▼
+Gate: BVT pass → done | BVT fail → stack rollback
+```
+
+## Unified Stack Preview Deploy
+
+The whole stack is deployed as one unit. The preview URL is the **backend gateway**; all client components (`web`, `native`, `desktop`, `wxa`, `mya`, `tta`) receive it as a build-time or runtime config.
+
+```bash
+# TCB (default)
+deploy_stack --preview
+# → backend: tcb fn deploy --env preview
+# → backend: tcb db migrate --env preview
+# → web:     tcb hosting deploy --env preview --build-env BACKEND_URL=${STACK_URL}
+# → native:  build with BACKEND_URL=${STACK_URL}, upload to internal distribution
+# → desktop: build with BACKEND_URL=${STACK_URL}, upload to internal distribution
+# → wxa:     build with BACKEND_URL=${STACK_URL}, upload to mini-program platform
+# → mya:     build with BACKEND_URL=${STACK_URL}, upload to mini-program platform
+# → tta:     build with BACKEND_URL=${STACK_URL}, upload to mini-program platform
+# → STACK_URL = https://{env-id}.tcb-preview.com
+
+# Aliyun
+deploy_stack --preview
+# → backend: fun deploy --env preview
+# → web:     oss + cdn deploy with build env
+# → native:  build with BACKEND_URL, package
+# → desktop: build with BACKEND_URL, package
+# → wxa:     build with BACKEND_URL, upload to mini-program platform
+# → mya:     build with BACKEND_URL, upload to mini-program platform
+# → tta:     build with BACKEND_URL, upload to mini-program platform
+# → STACK_URL = https://{gateway}.{region}.fc.devs.com
+```
+
+The `deploy_stack` tool resolves the preview URL dynamically per platform and exports it as `STACK_URL` (or `BACKEND_URL` for components to consume).
+
+## Per-Component BDD E2E
+
+```bash
+export STACK_URL=$(deploy_stack --preview --output url)
+export BACKEND_URL=$STACK_URL
+
+# Backend
+pytest apps/backend/tests/e2e/ --base-url $BACKEND_URL
+
+# Web (against web hosting URL; uses BACKEND_URL as API root)
+export WEB_URL=$(deploy_stack --preview --output web_url)
+pytest apps/web/tests/e2e/ --base-url $WEB_URL --api-url $BACKEND_URL
+
+# Native (against installed package or emulator; uses BACKEND_URL)
+pytest apps/native/tests/e2e/ --backend-url $BACKEND_URL
+
+# Desktop (against installed package or emulator; uses BACKEND_URL)
+pytest apps/desktop/tests/e2e/ --backend-url $BACKEND_URL
+
+# Mini-programs (wxa, mya, tta) (against emulator or device; uses BACKEND_URL)
+pytest apps/wxa/tests/e2e/ --backend-url $BACKEND_URL
+pytest apps/mya/tests/e2e/ --backend-url $BACKEND_URL
+pytest apps/tta/tests/e2e/ --backend-url $BACKEND_URL
+```
+
+## Cross-Stack E2E
+
+```bash
+pytest aidlc/tests/cross-stack/ --stack-url $STACK_URL --verbose
+# Runs the full multi-client ↔ backend flow defined in aidlc/features/cross-stack/
+```
+
+**Rule STK-001:** All `cross-stack` scenarios must pass before staging or production.
+
+## Staging
+
+```bash
+deploy_stack --env staging
+export STAGING_URL=$(deploy_stack --env staging --output url)
+pytest aidlc/tests/cross-stack/ --stack-url $STAGING_URL
+smoke-test $STAGING_URL
+```
+
+## Human Approval
+
+Production deployment requires explicit human approval. Approval is a **stack** decision — the reviewer sees the per-component e2e results, the cross-stack e2e results, the staging smoke, and the `contract-diff.md`.
+
+## Production Stack Deploy
+
+```bash
+deploy_stack --env production
+# → Same as preview/staging but with prod env IDs and production secrets
+```
+
+## Stack BVT (Build Verification Test)
+
+Automated health and functionality checks against the **production stack**:
+
+```bash
+bvt ${PRODUCTION_URL}
+# Checks:
+#  1. backend /health returns 200
+#  2. web home page returns 200 (SSR) or shell loads (SPA)
+#  3. native/desktop/mini-program launch probe (deep link resolves against BACKEND_URL)
+#  4. Core end-to-end flow (login) succeeds
+#  5. Database connectivity (probe query)
+#  6. No error rate spikes (5xx < 0.1%, p99 < 500ms)
+```
+
+**Rule DLV-003:** BVT must pass. If BVT fails, automatic **stack** rollback to the previous stable stack version.
+
+## Stack Rollback
+
+Rollback is at the stack level — all components revert together so the stack stays internally consistent.
+
+```bash
+# Automatic on BVT failure
+deploy_stack --rollback ${LAST_STABLE_STACK_VERSION}
+
+# Manual on demand
+deploy_stack --rollback --stack-version v1.2.3
+```
+
+The previous stable stack version is identified by the `aidlc/contracts/CHANGELOG.md` version at the time of the last green BVT.
+
+## Artifacts
+
+| Artifact | Purpose |
+|----------|---------|
+| `STACK_URL` / `BACKEND_URL` | Dynamic, per-platform, per-env |
+| Per-component e2e report | Scenario pass/fail per component |
+| Cross-stack e2e report | Full flow pass/fail |
+| `aidlc/openspec/changes/{id}/contract-diff.md` | Final contract change record |
+| BVT report | Stack-level health check results |
+| Deploy log | Stack version, timestamp, component versions |
+
+## Gate
+
+**Before marking complete:**
+- [ ] Unified stack preview deploy succeeded; `STACK_URL` and `BACKEND_URL` resolved
+- [ ] All per-component BDD e2e tests pass against their preview URLs
+- [ ] All cross-stack e2e tests pass against the unified stack URL
+- [ ] Staging smoke tests pass
+- [ ] Human approval received (covers per-component + cross-stack + staging + contract diff)
+- [ ] Production stack deploy succeeded
+- [ ] Stack BVT passed
+- [ ] (If BVT failed) Stack rollback executed and confirmed
+- [ ] `aidlc/openspec/changes/{id}/contract-diff.md` archived

package/ai-dlc-skill/phases/deliver/prompt.md

@@ -0,0 +1,54 @@
+# Deliver Phase Agent Prompt
+
+你是一个 AI-DLC Deliver Phase Agent。
+由 Master Agent 委派处理部署交付。
+
+## 输入
+- `{spec_dir}/contract-diff.md`
+- 所有 e2e 测试报告
+
+## 路径约定
+
+产物路径遵循 `aidlc/CONFIG.md` 中的变量定义。
+
+## 任务
+
+1. **Unified Stack Preview**
+   - `aidlc/tools/deploy_stack.sh --preview --provider {tcb|aliyun} [--compute-mode {fc|sae}]`
+   - 输出 STACK_URL + per-component URLs
+
+2. **Per-Component e2e**
+   - 对每个 affected component 运行 e2e 测试
+   - 使用动态解析的 URL
+
+3. **Cross-Stack e2e**
+   - `pytest {cross_test_dir}/ --stack-url ${STACK_URL}`
+
+4. **Staging Deploy + Smoke**
+   - `aidlc/tools/deploy_stack.sh --env staging`
+   - 运行 smoke-test + health-check
+
+5. **Production Gate + Deploy**
+   - 将预览和测试结果返回给 Master Agent，由 Master Agent 通过 AskUser 等待 Human Approval
+   - `aidlc/tools/deploy_stack.sh --env production`
+   - BVT 验证 + 自动回滚
+
+## 输出产物
+- 动态 URLs（STACK_URL / BACKEND_URL / WEB_URL）
+- e2e 测试报告（per-component + cross-stack）
+- BVT 报告
+- 部署日志
+
+## 约束
+- 开始前先调用 `TodoClear` 清除可能遗留的 todos，确保从空白计划开始
+- 遵守 DLV-001 到 DLV-004
+- 遵守 STK-004 到 STK-006（统一部署 + 构建配置注入 + stack 级回滚）
+
+## 完成报告
+
+完成后返回以下信息给 Master Agent（用于写入 Registry）：
+- `phase: "deliver"`
+- `status: "completed"`
+- `artifacts: [部署URL、BVT报告路径列表]`
+- `gatePassed: true/false`
+- `deployUrl: 生产环境URL`