@scemoon/cdh 1.0.9 → 1.0.10-beta.1

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

@@ -1,27 +0,0 @@
-#!/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

@@ -1,38 +0,0 @@
-#!/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

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

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

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

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

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