chore: sync config from main

Author: github-actions[bot]

airules/codebuddy/rules/ai-model-nodejs/rule.md

@@ -1,7 +1,7 @@
 ---
 name: ai-model-nodejs
 description: "Use this skill for Node.js backend AI via @cloudbase/node-sdk (>=3.16.0) — cloud functions, CloudRun, Express, Koa, NestJS, serverless APIs, scheduled jobs, LLM proxies. Only SDK supporting image generation (ai.createImageModel + generateImage). Text models via ai.createModel with groups cloudbase, hunyuan-exp, or custom-*. Model IDs (deepseek-v4-flash, deepseek-v3.2, hunyuan-2.0-instruct-20251111, glm-5, kimi-k2.6) go in the model field of generateText/streamText. MUST run two-step preflight before code — see body. Keywords: backend, 云函数, 云托管, serverless, LLM proxy, agent orchestration, generateText, streamText, generateImage, createModel, hunyuan-image, Token Credits, TokenHub, Hunyuan, DeepSeek, GLM, Kimi, MiniMax. NOT for browser/Web (use ai-model-web) or Mini Program (use ai-model-wechat)."
-version: 2.23.3
+version: 2.23.4
 alwaysApply: false
 ---
 

airules/codebuddy/rules/ai-model-web/rule.md

@@ -1,7 +1,7 @@
 ---
 name: ai-model-web
 description: "Use this skill when a browser/Web app (React, Vue, Angular, Next, Nuxt, static sites, SPAs, dashboards, AI chat UI) needs AI models via @cloudbase/js-sdk. Default routing for page/页面/Web/前端/frontend/网页/H5 AI — call directly from browser, do NOT propose a Node.js proxy. Covers generateText and streamText. Models via ai.createModel with groups cloudbase, hunyuan-exp, or custom-*. Model IDs (deepseek-v4-flash, deepseek-v3.2, hunyuan-2.0-instruct-20251111, glm-5, kimi-k2.6) go in the model field. MUST run two-step preflight before code — see body. Keywords: 页面, Web, 前端, React, Vue, Next, Nuxt, SPA, AI chat UI, generateText, streamText, createModel, hunyuan-exp, Token Credits, TokenHub, Hunyuan, DeepSeek, GLM, Kimi, MiniMax. NOT for Node.js backend (use ai-model-nodejs), Mini Program (use ai-model-wechat), or image generation (Node SDK only)."
-version: 2.23.3
+version: 2.23.4
 alwaysApply: false
 ---
 

airules/codebuddy/rules/ai-model-wechat/rule.md

@@ -1,7 +1,7 @@
 ---
 name: ai-model-wechat
 description: "Use this skill for WeChat Mini Program AI via wx.cloud.extend.AI (小程序, 企业微信小程序, wx.cloud apps). Features generateText and streamText with callbacks (onText, onEvent, onFinish). Models via wx.cloud.extend.AI.createModel with groups hunyuan-exp (小程序成长计划), cloudbase (main managed), or custom-*. Model IDs (deepseek-v4-flash, deepseek-v3.2, hunyuan-2.0-instruct-20251111, glm-5, kimi-k2.6) go in the data wrapper model field. API differs from JS/Node SDK — streamText needs data wrapper, generateText returns raw response. MUST run two-step preflight before code — see body. Keywords: Mini Program AI, wx.cloud.extend.AI, 小程序成长计划, ai_miniprogram_inspire_plan, Token Credits 资源包, generateText, streamText, createModel, hunyuan-exp, TokenHub, Hunyuan, DeepSeek, GLM, Kimi, MiniMax. NOT for browser/Web (use ai-model-web), Node.js backend (use ai-model-nodejs), or image generation (use ai-model-nodejs)."
-version: 2.23.3
+version: 2.23.4
 alwaysApply: false
 ---
 

airules/codebuddy/rules/auth-nodejs/rule.md

@@ -1,7 +1,7 @@
 ---
 name: auth-nodejs-cloudbase
 description: CloudBase Node SDK auth guide for server-side identity, user lookup, and custom login tickets. This skill should be used when Node.js code must read caller identity, inspect end users, or bridge an existing user system into CloudBase; not when configuring providers or building client login UI.
-version: 2.23.3
+version: 2.23.4
 alwaysApply: false
 ---
 

airules/codebuddy/rules/auth-tool/rule.md

@@ -1,7 +1,7 @@
 ---
 name: auth-tool-cloudbase
 description: CloudBase auth provider configuration and login-readiness guide. This skill should be used when users need to inspect, enable, disable, or configure auth providers, publishable-key prerequisites, login methods, SMS/email sender setup, or other provider-side readiness before implementing a client or backend auth flow.
-version: 2.23.3
+version: 2.23.4
 alwaysApply: false
 ---
 

airules/codebuddy/rules/auth-web/rule.md

@@ -1,7 +1,7 @@
 ---
 name: auth-web-cloudbase
 description: CloudBase Web Authentication Quick Guide for frontend integration after auth-tool has already been checked. Provides concise and practical Web authentication solutions with multiple login methods and complete user management.
-version: 2.23.3
+version: 2.23.4
 alwaysApply: false
 ---
 

airules/codebuddy/rules/auth-wechat/rule.md

@@ -1,7 +1,7 @@
 ---
 name: auth-wechat-miniprogram
 description: CloudBase WeChat Mini Program native authentication guide. This skill should be used when users need mini program identity handling, OPENID/UNIONID access, or `wx.cloud` auth behavior in projects where login is native and automatic.
-version: 2.23.3
+version: 2.23.4
 alwaysApply: false
 ---
 

airules/codebuddy/rules/cloud-functions/checklist.md

@@ -8,17 +8,21 @@ Use this checklist before creating or updating a CloudBase function.
    - Event Function: `exports.main(event, context)`, SDK/timer driven
    - HTTP Function: `req` / `res`, listens on port `9000`
 2. Pick the runtime before creation and state it explicitly.
-3. For HTTP Functions, confirm `scf_bootstrap` exists and the Node.js binary path matches the runtime (e.g. `Nodejs18.15` → `/var/lang/node18/bin/node`).
-4. Confirm the function root path points to the parent directory, not the function directory itself.
-5. For HTTP Functions that need public access, configure the function security rule with `managePermissions(action="updateResourcePermission", resourceType="function")` after creation. Default rules reject unauthenticated callers with `EXCEED_AUTHORITY`. Note: anonymous login is disabled by default — use `rule: "true"` for public endpoints.
-6. If the request is really for a long-running container service, reroute to `cloudrun-development`.
+   - For a managed runtime, choose a language runtime (e.g. `Nodejs18.15`).
+   - For a container-image HTTP Function, set `runtime: "CustomImage"` and provide `imageConfig` (`imageUri` with tag; `registryId` for enterprise TCR). The image still listens on port `9000`. See `references/http-functions-custom-image.md`.
+3. For HTTP Functions on a managed runtime, confirm `scf_bootstrap` exists and the Node.js binary path matches the runtime (e.g. `Nodejs18.15` → `/var/lang/node18/bin/node`). Custom Image functions do not use `scf_bootstrap`.
+4. Confirm the function root path points to the parent directory, not the function directory itself. (Not needed for Custom Image deploys — the code lives in the image.)
+5. For Custom Image deploys, confirm TCR, the CloudApp build, and SCF are in the same region, and the image tag is unique (not `:latest`). Remember Stage A (CloudApp custom build → TCR push) is a raw Tencent Cloud API path, not covered by MCP tools.
+6. For HTTP Functions that need public access, configure the function security rule with `managePermissions(action="updateResourcePermission", resourceType="function")` after creation. Default rules reject unauthenticated callers with `EXCEED_AUTHORITY`. Note: anonymous login is disabled by default — use `rule: "true"` for public endpoints.
+7. If the request is really for a long-running container service, reroute to `cloudrun-development`.
 
 ## Common failure patterns
 
 - Choosing the wrong function type and compensating later.
 - Mixing Event Function and HTTP Function handler shapes in the same implementation.
 - Forgetting that runtime cannot be changed after creation.
 - Mismatching the `scf_bootstrap` Node.js binary path with the function runtime.
+- For Custom Image functions: using `:latest`, mismatched regions across TCR/CloudApp/SCF, or assuming MCP covers the CloudApp build → TCR push stage (it does not).
 - Forgetting to configure function security rules for HTTP Functions that need public access.
 - Treating Cloud Functions as the default answer for Web authentication.
 

airules/codebuddy/rules/cloud-functions/references.md

@@ -27,6 +27,15 @@ Read this when the task is about:
 - `scf_bootstrap`
 - browser/public access paths for HTTP Functions
 
+### `./references/http-functions-custom-image.md`
+
+Read this when the task is about:
+
+- deploying an HTTP Function from a **container image** (`Runtime: CustomImage`)
+- `imageConfig` / `ImageUri` / TCR image addresses
+- the zip → COS → CloudApp custom build → TCR → SCF image pipeline
+- choosing between a managed-runtime HTTP Function, a Custom Image HTTP Function, and a CloudRun container
+
 ### `./references/operations-and-config.md`
 
 Read this when the task is about:
@@ -44,3 +53,4 @@ Read this when the task is about:
 - HTTP Function code shape: `req` / `res` web server on port `9000`
 - HTTP Access for Event Functions is a gateway configuration, not the HTTP Function runtime model
 - CloudRun is the right route when the task is actually a long-lived service or broader container workload
+- Custom Image HTTP Function (`Runtime: CustomImage`) still listens on the fixed port `9000` and is request-driven — distinct from a CloudRun container, which listens on the injected `PORT` and runs long-lived

airules/codebuddy/rules/cloud-functions/references/http-functions-custom-image.md

@@ -0,0 +1,209 @@
+# HTTP Functions — Custom Image Deployment Reference
+
+Use this reference when an HTTP Function must run from a **container image** instead of the managed Node.js/Python runtime. This is the `Runtime: CustomImage` path: the code is packaged as a Docker image, pushed to TCR (Tencent Container Registry), and SCF runs that image.
+
+## When to choose Custom Image (vs the other two HTTP options)
+
+| Deployment form | Choose when | How it deploys |
+| --- | --- | --- |
+| **Managed runtime** (default, see `http-functions.md`) | Plain Node.js / Python, dependencies are simple | `manageFunctions(createFunction)` + `scf_bootstrap` + zip |
+| **Custom Image** (this file) | Need custom system libraries / arbitrary runtime, but still want SCF request-driven execution and scale-to-zero | CloudApp custom build → TCR → SCF image function |
+| **CloudRun container** (see `cloudrun-development`) | Long-lived process, persistent connections, listens on injected `PORT` | `manageCloudRun` |
+
+Keep Custom Image HTTP Functions distinct from CloudRun containers — both use a Dockerfile, but:
+
+- **Custom Image HTTP Function**: container listens on a **fixed port `9000`**, request-driven, scales to zero. SCF gateway sends each HTTP request into the container.
+- **CloudRun container**: container listens on the **injected `PORT`** env var, long-lived process.
+
+Do not blend the two contracts.
+
+## End-to-end pipeline (6 steps)
+
+The link between the two stages is the TCR image address:
+
+```text
+ImageUri = {TCR_REGISTRY}/{TCR_NAMESPACE}/{ServiceName}:{VersionName}
+example:   ccr.ccs.tencentyun.com/your-ns/demo-app:demo-app-001
+```
+
+```text
+Stage A — build the image (CloudApp custom build pipeline)
+  ① DescribeCloudAppCosInfo   -> get COS upload credentials + UnixTimestamp
+  ② PUT zip to COS            -> upload source
+  ③ CreateCloudApp            -> trigger docker build + docker push to TCR
+  ④ DescribeCloudAppVersion   -> poll until Status=SUCCESS, read VersionName
+
+Stage B — deploy to SCF (based on the TCR image)
+  ⑤ createFunction / updateFunctionCode  -> SCF image function
+  ⑥ getFunctionDetail (optional)         -> confirm Status=Active
+```
+
+## Tooling boundary (read this before acting)
+
+- **Stage B (SCF image deploy) is covered by `manageFunctions`.** Use `manageFunctions(action="createFunction")` with `func.runtime="CustomImage"` + `imageConfig`, and `manageFunctions(action="updateFunctionCode")` + `imageConfig` for later iterations. The Manager SDK auto-fills `ImageType=enterprise` and `ImagePort=9000`, and strips Handler / dependency install for image functions.
+- **Stage A (CloudApp custom build → TCR) is NOT covered by MCP tools.** The `manageApps` / `queryApps` tools only support `static-hosting`. The custom-build pipeline (`DeployType=custom`, `CustomSteps`, `DescribeCloudAppCosInfo` with `DeployType=custom`) is a **raw Tencent Cloud API path**. Treat it as a `callCloudApi` fallback:
+  - Confirm the exact action name, parameters, and `X-TC-Version` from official docs **before** calling — do not guess payloads from memory.
+  - CloudApp build APIs are on `tcb.tencentcloudapi.com` (`X-TC-Version: 2018-06-08`).
+  - SCF APIs are on `scf.tencentcloudapi.com` (`X-TC-Version: 2018-04-16`).
+- **Region must match.** TCR, the CloudApp build, and SCF must be in the same region (e.g. all `ap-shanghai`). Cross-region image pulls time out.
+
+## Stage B with `manageFunctions` (the supported path)
+
+### Create (first deploy)
+
+```javascript
+manageFunctions({
+  action: "createFunction",
+  func: {
+    name: "my-scf-func",
+    type: "HTTP",
+    runtime: "CustomImage"
+  },
+  imageConfig: {
+    imageType: "enterprise",
+    imageUri: "ccr.ccs.tencentyun.com/your-ns/demo-app:demo-app-001",
+    registryId: "tcr-xxxxxxxx",
+    command: "python",
+    args: "-u app.py",
+    imagePort: 9000,
+    containerImageAccelerate: true
+  }
+});
+```
+
+### Update image (later iterations)
+
+Only the tag changes; no local code packaging.
+
+```javascript
+manageFunctions({
+  action: "updateFunctionCode",
+  functionName: "my-scf-func",
+  imageConfig: {
+    imageType: "enterprise",
+    imageUri: "ccr.ccs.tencentyun.com/your-ns/demo-app:demo-app-002",
+    registryId: "tcr-xxxxxxxx"
+  }
+});
+```
+
+### `imageConfig` fields
+
+| Field | Required | Notes |
+| --- | --- | --- |
+| `imageUri` | yes | Full address **with tag**: `{domain}/{ns}/{image}:{tag}`. Never `:latest`. |
+| `imageType` | — | `"enterprise"` (TCR enterprise) or `"personal"`. Defaults to `enterprise`. |
+| `registryId` | enterprise only | TCR instance id `tcr-xxxxxxxx`. Required when `imageType=enterprise`. |
+| `command` | — | Overrides `ENTRYPOINT`. Omit to use the Dockerfile default. |
+| `args` | — | Overrides `CMD`, space-separated. |
+| `imagePort` | — | Web Server: `9000` (default). Job-style image: `-1`. |
+| `containerImageAccelerate` | — | Image acceleration; enable for large images to cut cold-start time. |
+
+After deploy, confirm readiness with `queryFunctions(action="getFunctionDetail", functionName="my-scf-func")` and look for `Status=Active`. For public/browser access, create gateway access explicitly with `manageGateway(action="createAccess", type="HTTP")` and set the function security rule (anonymous login is disabled by default — see `http-functions.md`).
+
+## Source packaging (Stage A input)
+
+Package the **contents** of the project root, with a `Dockerfile` at the root — do not nest an extra top-level folder.
+
+```bash
+# correct: zip the contents from inside the project root
+cd ./my-app
+zip -r ../my-app.zip .
+
+# wrong: this nests an extra my-app/ layer after extraction
+zip -r my-app.zip my-app/
+```
+
+After extraction the build container sees:
+
+```text
+/  (workspace root)
+├── Dockerfile          <- must be at the root
+├── package.json / requirements.txt / pom.xml ...
+├── src/
+└── ...
+```
+
+## Dockerfile contract for SCF image functions
+
+```dockerfile
+FROM python:3.11-slim
+WORKDIR /app
+COPY . .
+RUN pip install --no-cache-dir -r requirements.txt
+EXPOSE 9000              # SCF Web Server functions must listen on 9000
+CMD ["python", "-u", "app.py"]
+```
+
+SCF image constraints:
+
+| Constraint | Detail |
+| --- | --- |
+| Web Server functions listen on `9000` | The SCF gateway sends HTTP requests into the container on this port. |
+| The image must start an HTTP server on its own | Not a CLI tool, not a blocking script. |
+| Image size ideally ≤ 500MB | Large images cold-start slowly; enable `containerImageAccelerate`. |
+| Container start ≤ health-check timeout | Default 60s. |
+
+## TCR credentials (Stage A push, raw API)
+
+Use STS temporary credentials + TCR `CreateInstanceToken` to obtain a short-lived registry login, instead of storing any long-term TCR password:
+
+- The build container injects STS credentials as `$API_SECRET_ID` / `$API_SECRET_KEY` / `$API_TOKEN`.
+- In the build step, sign a TCR `CreateInstanceToken` call (`tcr.tencentcloudapi.com`, `X-TC-Version: 2019-09-24`) with those credentials to get a temporary token.
+- `docker login` with that token (always via `--password-stdin`), then `docker push`.
+
+Security red lines:
+
+- Never print `$API_SECRET_*` / `$API_TOKEN` or pass them outside the container.
+- Always use `docker login --password-stdin` so credentials never appear in `ps` or logs.
+
+## Build-container variables (Stage A, custom build)
+
+Use these inside `CustomSteps` commands:
+
+| Variable | Meaning |
+| --- | --- |
+| `$CLOUDBASE_SERVICE_NAME` | Service name (= the `ServiceName` input) |
+| `$CLOUDBASE_VERSION_NAME` | Version name — **use this as the image tag**; available at build time, unique, traceable |
+| `$CLOUDBASE_VERSION_NUMBER` | Numeric version (e.g. `001`) |
+| `$CLOUDBASE_ENV_ID` | Environment id |
+| `$BUILD_TYPE` | `zip` / `git` |
+| `$ZIP_FILE_URL` | Zip download URL (injected automatically in zip mode) |
+| `$API_SECRET_ID` `$API_SECRET_KEY` `$API_TOKEN` | STS credentials (never print) |
+
+- Reserved prefixes that must NOT be declared in `Env`: `API_*`, `CLOUDBASE_*`, `CODE_*`, `BUILD_TYPE`, `ZIP_FILE_URL`.
+- Do NOT reference non-existent variables such as `$BUILD_ID`, `$CLOUDBASE_BUILD_ID`, `$CLOUDBASE_VERSION` — use `$CLOUDBASE_VERSION_NAME` for the tag.
+
+## Common errors
+
+### Stage A (build)
+
+| Symptom | Likely cause |
+| --- | --- |
+| `Source 不能为空` | `Source.Type` empty; zip flow must set `"zip"` |
+| `Commands 和 CustomSteps 不能同时为空` | Provide at least one `CustomSteps` entry |
+| COS upload 403 | Missing one of the `UploadHeaders`, or the upload URL expired (>15 min) |
+| `检出 ZIP 包` failed | `CosTimestamp` missing or wrong (must reuse the `UnixTimestamp` from step ①) |
+| `docker push :tag` empty tag | Used a non-existent variable; use `$CLOUDBASE_VERSION_NAME` |
+| `docker login unauthorized` | TCR namespace not authorized; check `TCR_INSTANCE_ID` |
+| `AuthFailure.SignatureFailure` | Push script `REGION` does not match the TCR instance region |
+
+### Stage B (deploy)
+
+| Symptom | Likely cause |
+| --- | --- |
+| `ResourceNotFound.ImageConfig` | `imageUri` does not exist or the tag is wrong |
+| `InvalidParameterValue.ImageUri` | Wrong format; must be `{domain}/{ns}/{image}:{tag}` |
+| SCF image pull timeout | TCR and SCF are not in the same region |
+| SCF image pull denied | `SCF_QcsRole` not authorized to pull from TCR |
+| Function start timeout (60s) | Image too large or startup too slow; enable image acceleration / slim the image |
+| Port 9000 no response | Dockerfile `EXPOSE` / `CMD` does not actually start an HTTP server on 9000 |
+
+## Best practices
+
+- Image tag = `$CLOUDBASE_VERSION_NAME` — available at build time, unique, traceable.
+- TCR push via STS + `CreateInstanceToken` — no long-term secrets to manage.
+- `Runtime` must be `"CustomImage"`, not a language runtime.
+- `imageUri` must include a tag — never `:latest`.
+- Keep TCR, CloudApp build, and SCF in the same region.
+- SCF image ≤ 500MB + enable acceleration to control cold-start time.