huaweicloud-devkit 1.1.0-next.8 → 1.1.0

package/plugins/huaweicloud-core/skills/huawei-sandbox/SKILL.md

@@ -52,6 +52,8 @@ Domain expertise for Huawei Cloud Sandbox (DevStation) instances and workspace t
 | `huaweicloud_sandbox_exec_one_shot`     | One-shot execution (fresh connection; best for long/heavy commands)         |
 | `huaweicloud_sandbox_upload_file`       | Upload a local file into the sandbox (chunked base64 write + md5 verify)    |
 | `huaweicloud_sandbox_upload_project`    | Upload a local project directory to sandbox (HTTP tunnel, tar.gz + extract) |
+| `huaweicloud_sandbox_deploy_nginx`      | Deploy nginx config with permissions fix and reload in one call             |
+| `huaweicloud_sandbox_deploy_check`      | Run deployment completeness check (nginx, DevBridge, URL, QR if needed)     |
 | `huaweicloud_sandbox_close_session`     | Close a persistent terminal session                                         |
 
 ### Tool Selection Guide
@@ -63,6 +65,8 @@ Domain expertise for Huawei Cloud Sandbox (DevStation) instances and workspace t
 | `curl`, health checks, quick tests | Either — `exec_one_shot` preferred | Stateless, fast                                              |
 | Server startup (background)        | `exec_with_session`                | Need to `nohup ... &` then check output in same session      |
 | Deployment scripts                 | `exec_one_shot+shot`               | Long script, fresh connection avoids session timeouts        |
+| nginx configuration                | `deploy_nginx`                     | Auto-generates correct template + permissions + reload       |
+| Deployment completeness check      | `deploy_check`                     | Verifies nginx, DevBridge, URL, QR before reporting success  |
 | Single file upload (<1MB)          | `upload_file`                      | Base64 chunked, reliable for small files                     |
 | Project directory upload (>1MB)    | `upload_project`                   | HTTP tunnel, much faster than base64 for multi-file projects |
 
@@ -74,6 +78,12 @@ Domain expertise for Huawei Cloud Sandbox (DevStation) instances and workspace t
 
 **Session recovery**: if `exec_with_session` returns `session is not ready`, the WebSocket connection has dropped. Do NOT retry the same session — fall back to `exec_one_shot` for that command instead. To recover state (cd, env vars), reconstruct them explicitly in the one-shot command.
 
+**Timeout recovery**: if `exec_one_shot` returns a timeout error, check whether partial output is available before declaring failure:
+
+- For build commands: check `tail -30 /tmp/build.log` — the build may have completed but the tee pipe didn't flush before timeout
+- For long scripts: split into independent `exec_one_shot` calls (max 5 sub-commands per call, 15s timeout per call)
+- Do NOT retry the same composite command — split and retry individual steps
+
 ## Workflow
 
 Setup is a **plugin-side preflight** — the developer should be asked a question only once, when the agreement actually needs signing:
@@ -85,19 +95,32 @@ Setup is a **plugin-side preflight** — the developer should be asked a questio
 2. **Real-name verification only** (`HDKIT_NOT_REALNAME`): tell the developer once, "Huawei Cloud requires real-name verification before using the sandbox — please complete it in the Huawei Cloud console (实名认证)." and stop — do not retry `connect` in a loop
 3. **Sign agreement only** (`HDKIT_NOT_AGREEMENT`): **STOP and do NOT sign on your own.** Ask the developer: "Huawei Cloud sandbox requires signing the latest developer service agreement. May I sign it for you?" Then **wait for the developer to explicitly agree** (e.g. "签署" / "确认" / "sign it"). Only after explicit consent call `huaweicloud_sandbox_sign_agreement` and return its result (`signed`/`signedCount`) to the developer. **Never sign a legal agreement on the developer's behalf without their explicit, unambiguous consent.** Do not expose the underlying sandbox/DevBridge service as a separate entity the developer must understand or sign up for
 4. **Both missing** (`HDKIT_NOT_REALNAME_AND_AGREEMENT`): present **both** requirements together in one message — the real-name verification steps (console, step 2) **and** the agreement-signing request (step 3, wait for explicit consent) — so the developer can complete both at once
-5. **Connect**: `huaweicloud_sandbox_connect` — returns `session_id`, `dev_stage_id`, `connection_id`, `connection_address`
-6. **Cleanup previous deployments** (after first connect to a sandbox): nginx configs and DevBridge tunnels from previous deployments can cause port conflicts and quota errors. Run cleanup immediately after connect:
+5. **Connect**: `huaweicloud_sandbox_connect` — returns `session_id`, `dev_stage_id`, `connection_id`, `connection_address`. The `source` parameter identifies the calling agent (valid values: `CLI`, `WEB`, `VSCODE`, `WEBVNC`, `WEBPTY`, `WEBIDE`, `CURSOR`, etc. — case-sensitive, all uppercase). The `git` parameter (with `repo_url`, `repo_name`, `target_path`) is accepted but does NOT auto-clone the repository — always clone manually.
+6. **Cleanup previous deployments** (after first connect to a sandbox): nginx configs, DevBridge tunnels, and stale web processes from previous deployments can cause port conflicts and quota errors. Run cleanup immediately after connect:
 
    ```bash
+   # Kill stale Node.js web processes from previous deployments
+   pkill -9 -f "next-server" 2>/dev/null || true
+   pkill -9 -f "next start" 2>/dev/null || true
+   pkill -9 -f "nuxt" 2>/dev/null || true
+   sleep 1
    # Remove stale nginx configs from previous deployments
-   sudo rm -f /etc/nginx/conf.d/app.conf /etc/nginx/conf.d/*.conf.bak 2>/dev/null
+   sudo rm -f /etc/nginx/conf.d/*.conf /etc/nginx/conf.d/*.conf.bak 2>/dev/null
    # Remove stale DevBridge tunnels
    devbridge delete-all 2>/dev/null || true
    # Reload nginx to apply
    sudo nginx -s reload 2>/dev/null || true
    ```
 
-7. **Inject credentials** (optional): `huaweicloud_sandbox_credentials` — enables cloud API access from sandbox
+7. **Inject credentials** (optional): `huaweicloud_sandbox_credentials` — enables cloud API access from sandbox. After injection, credentials are also written to `/tmp/hw_creds.sh` for shell access:
+
+   ```bash
+   # Source credentials in any sandbox shell before using hcloud/devbridge:
+   source /tmp/hw_creds.sh 2>/dev/null && echo "Credentials loaded"
+   ```
+
+   If `source /tmp/hw_creds.sh` returns empty, the credentials injection may not have completed — re-run `huaweicloud_sandbox_credentials`.
+
 8. **Execute commands**: use `huaweicloud_sandbox_exec_with_session` for interactive work (cd, env setup), or `huaweicloud_sandbox_exec_one_shot` for long-running builds/installs. See [Tool Selection Guide](#tool-selection-guide).
 9. **Upload project** (if deploying local code): `huaweicloud_sandbox_upload_project` to transfer a local project directory into `/workspace/<name>` — uses HTTP tunnel, much faster than base64 for multi-file projects. Use `huaweicloud_sandbox_upload_file` for single files.
 10. **Expose the deployed app and return the public URL**: set up a public access link for the app port and give the URL to the developer as the final result (see "Expose the deployed app (public URL)") — this step uses an internal tunnel mechanism that must never be mentioned to the developer
@@ -184,31 +207,53 @@ fi
 export PATH=$PATH:$HOME/.huawei/bin   # installer only writes ~/.bashrc; session shells do not re-source it
 ```
 
-**Login** (non-interactive, credentials come from the developer's local agent — the vault or HW_ACCESS_KEY/HW_SECRET_KEY; never echo them):
+**Login** (non-interactive; credentials from `huaweicloud_sandbox_credentials` are available via `/tmp/hw_creds.sh`). If `source /tmp/hw_creds.sh` returns empty, the credentials injection has expired (sandbox session reconnection resets them) — re-run `huaweicloud_sandbox_credentials` first:
 
 ```bash
-devbridge auth login --huaweicloud --access-key "$AK" --secret-key "$SK"
+source /tmp/hw_creds.sh 2>/dev/null
+devbridge auth login --huaweicloud --access-key "$HW_ACCESS_KEY" --secret-key "$HW_SECRET_KEY"
 ```
 
 - The `--huaweicloud` flag is required for AK/SK login; without it the CLI tries an interactive browser login, which fails in the sandbox.
-- Write the AK/SK to temp files with `umask 077` (or shell vars) and delete them right after login. Verify with `devbridge auth status`.
+- Credentials are stored in `/tmp/hw_creds.sh` (chmod 600) — source it before login, never echo the values.
+- Verify with `devbridge auth status`. If `$HW_ACCESS_KEY` is empty, ensure `huaweicloud_sandbox_credentials` was called first.
 
 **Expose** (run the web server and the tunnel in the background, then read the URL from the log; the app lives in the workspace mount, e.g. `/workspace/<repo-name>`):
 
 ```bash
-# 0. Pre-cleanup: remove stale tunnels to avoid quota exceeded
+# 0. Pre-cleanup: kill old processes and stale tunnels
+pkill -f "devbridge host" 2>/dev/null || true
+sleep 2
 devbridge delete-all 2>/dev/null || true
 
 # 1. Start tunnel
 nohup devbridge host -p <port> -e 8 > /tmp/host.log 2>&1 &
 sleep 10 && cat /tmp/host.log
+
+# 2. Extract tunnel URL and health-check before returning
+TUNNEL_URL=$(grep -oP 'Tunnel URL: \K.*' /tmp/host.log)
+HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$TUNNEL_URL" 2>/dev/null || echo "000")
+if [ "$HTTP_CODE" = "200" ] || [ "$HTTP_CODE" = "304" ]; then
+  echo "Tunnel verified: $TUNNEL_URL (HTTP $HTTP_CODE)"
+else
+  echo "WARN: Tunnel URL unreachable (HTTP $HTTP_CODE). Rebuilding tunnel..."
+  pkill -f "devbridge host" && sleep 2
+  devbridge delete-all 2>/dev/null || true
+  nohup devbridge host -p <port> -e 8 > /tmp/host.log 2>&1 &
+  sleep 10
+  TUNNEL_URL=$(grep -oP 'Tunnel URL: \K.*' /tmp/host.log)
+  HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$TUNNEL_URL" 2>/dev/null || echo "000")
+  echo "Retry tunnel: $TUNNEL_URL (HTTP $HTTP_CODE)"
+fi
 ```
 
+**Never return a tunnel URL without verifying it first** — a stale URL (from a killed tunnel process) will silently fail. Always curl-check before giving the URL to the developer.
+
 **Quota recovery**: if the tunnel creation fails with `10006: quota exceeded`:
 
 ```bash
 # Step A: List all tunnels (both active and stale)
-devbridge ls --all
+devbridge list -j
 # Step B: Remove all stale tunnels
 devbridge delete-all
 # Step C: Retry tunnel creation
@@ -220,6 +265,7 @@ This eliminates the most common deployment failure — historical tunnels from p
 
 - The public URL has the form `https://<id>-<port>.cn-north-4-bridge.myhuaweicloud.com` (from the `Tunnel URL:` line).
 - **Return this URL to the developer as the deployment result link.** Keep the host process running (do not close the session before handing over the URL).
+- Tunnel `description` (`-d`) accepts only Chinese characters, letters, and digits (0-64). Symbols such as `-`/`_`/spaces are rejected (`Invalid tunnel description`).
 - Internal docs: https://huaweicloud.github.io/devspace-devbridge/
 
 **No local downgrade**: if the tunnel tooling cannot be installed in the sandbox, STOP and report a generic error ("无法生成访问地址") without technical detail. Never install it on the developer's local machine — a local install would defeat the purpose of sandbox deployment.
@@ -309,6 +355,16 @@ if command -v apt-get >/dev/null 2>&1; then echo "PKG_MGR=apt"; elif command -v
 
 Use the detected `PKG_MGR` for all package installations below.
 
+**Architecture awareness**: the sandbox runs Linux aarch64 (ARM64). Native binaries built on x64 (Windows/macOS Intel) will not execute. Always install dependencies and build inside the sandbox. For projects with native addons (Taro `@swc/core`, Prisma, `esbuild`, `node-gyp`), local x64 pre-build + upload of `dist/` output is a viable alternative when sandbox builds fail.
+
+**GitCode SSL**: if `git clone` from GitCode fails with SSL certificate errors, use a one-shot override (do NOT set it globally — that would disable cert verification for every repo):
+
+```bash
+git -c http.sslVerify=false clone <repo-url>
+```
+
+Then retry the clone. This bypasses SSL verification only for this single clone.
+
 #### 3b: Install nginx (before project upload)
 
 ```bash
@@ -325,27 +381,24 @@ If nginx cannot be installed, skip to Python HTTP server fallback (see `referenc
 
 #### 3c: Verify remaining tools
 
-Before installing project dependencies, verify the sandbox has the required runtime tools. Run this pre-flight check via `exec_one_shot`:
+Before installing project dependencies, verify the sandbox has the required runtime tools. **Run each check as a separate `exec_one_shot` call with 15s timeout** — do not bundle all checks into one command. A single hung subcommand (e.g., `make --version` or `hugo version`) will timeout the entire check, blocking deployment:
 
-```bash
-# Core tools (expected pre-installed in sandbox image)
-echo "=== Checking core tools ==="
-if command -v node >/dev/null 2>&1; then node --version; else echo "MISSING: node"; fi
-if command -v npm >/dev/null 2>&1; then npm --version; else echo "MISSING: npm"; fi
-if command -v nginx >/dev/null 2>&1; then nginx -v 2>&1; else echo "MISSING: nginx"; fi
-if command -v git >/dev/null 2>&1; then git --version; else echo "MISSING: git"; fi
-if command -v python3 >/dev/null 2>&1; then python3 --version; else echo "MISSING: python3"; fi
-if command -v curl >/dev/null 2>&1; then curl --version | head -1; else echo "MISSING: curl"; fi
-if command -v wget >/dev/null 2>&1; then wget --version | head -1; else echo "MISSING: wget"; fi
-if command -v make >/dev/null 2>&1; then make --version | head -1; else echo "MISSING: make"; fi
-
-# Framework-specific tools (install on demand)
-echo "=== Checking framework tools ==="
-if command -v pnpm >/dev/null 2>&1; then pnpm --version; else echo "MISSING: pnpm"; fi
-if command -v yarn >/dev/null 2>&1; then yarn --version; else echo "MISSING: yarn"; fi
-if command -v hugo >/dev/null 2>&1; then hugo version; else echo "MISSING: hugo"; fi
-if command -v devbridge >/dev/null 2>&1; then devbridge version; else echo "MISSING: devbridge"; fi
 ```
+Check 1: node --version       (timeout: 15s)
+Check 2: npm --version         (timeout: 15s)
+Check 3: nginx -v 2>&1         (timeout: 15s)
+Check 4: git --version         (timeout: 15s)
+Check 5: python3 --version     (timeout: 15s)
+Check 6: curl --version | head -1 (timeout: 15s)
+Check 7: wget --version | head -1 (timeout: 15s)
+Check 8: make --version | head -1 (timeout: 15s)
+Check 9: pnpm --version        (timeout: 15s)
+Check 10: yarn --version       (timeout: 15s)
+Check 11: hugo version         (timeout: 15s)
+Check 12: devbridge version    (timeout: 15s)
+```
+
+For each check, parse the output: if stdout contains `MISSING:` or the tool wasn't found, install it. **Skip framework-specific tools not needed for the current project** (e.g., skip Hugo for React apps).
 
 **Install only missing tools** — parse the pre-flight output and install only tools reported as `MISSING`. Use OS-aware commands:
 
@@ -385,6 +438,15 @@ echo "NODE_ENV=${NODE_ENV:-development}"
 
 This must run via `exec_with_session` so the exported variables persist for subsequent build commands in the same session.
 
+**Prisma / ORM compatibility**: Prisma CLI (`prisma generate`, `prisma db push`, `prisma migrate`) only reads `.env` by default, NOT `.env.local` or `.env.development`. If the project uses `.env.local` for `DATABASE_URL`, link it before any Prisma command:
+
+```bash
+# Prisma requires .env (not .env.local) — symlink if needed
+if [ -f .env.local ] && [ ! -f .env ]; then ln -sf .env.local .env 2>/dev/null || cp .env.local .env; fi
+# Then re-source
+set -a && source .env 2>/dev/null; set +a
+```
+
 #### 4b: Install Dependencies
 
 Use `exec_one_shot` for install (no shared state needed). Skip if `node_modules` already exists:
@@ -395,6 +457,30 @@ cd /workspace/<dirname> && [ -d node_modules ] && echo "SKIP: node_modules exist
 
 Wait for install to complete. For large projects on aarch64 sandboxes (1000+ packages), set `timeout_ms` to 180000 (3 min).
 
+**Node version compatibility**: if `npm install` fails with native module errors (e.g., `rollup 4`, `@esbuild`, `node-gyp`), check the Node version:
+
+```bash
+node -v
+```
+
+Node v24+ uses musl-based binaries on some sandbox images, which may break native addons built for glibc. If native modules fail:
+
+- Try `npm install --force` or `npm install --legacy-peer-deps`
+- For rollup 4 projects, consider `npm install rollup@3` as fallback
+- If webpack/rollup native addon errors persist, add `--ignore-scripts` then manually rebuild: `npm rebuild`
+
+**Prisma / database initialization**: if `prisma/schema.prisma` exists in the project, initialize the database after install and before build. Prisma Client generation (`prisma generate`) is usually handled by `postinstall`, but `prisma db push` (SQLite) or `prisma migrate deploy` (PostgreSQL/MySQL) must be run manually:
+
+```bash
+cd /workspace/<dirname>
+if [ -f prisma/schema.prisma ]; then
+  echo "Prisma schema detected — initializing database..."
+  npx prisma db push --skip-generate 2>/dev/null || npx prisma migrate deploy 2>/dev/null || echo "WARN: skip db init"
+fi
+```
+
+> `--skip-generate` avoids redundant generation when `postinstall` already ran `prisma generate`. For SQLite, `DATABASE_URL="file:./dev.db"` must be set in `.env`/`.env.local` before this step.
+
 #### 4c: Build
 
 **Timeout strategy by framework type:**
@@ -424,6 +510,20 @@ grep -r "outDir\|outputDir\|dest\|distDir" /workspace/<dirname>/.vitepress/confi
 
 If a custom outDir is found, use that instead of the framework-detected default for all subsequent checks.
 
+**Post-build output verification**: after a successful build, verify the actual `index.html` location. Framework-returned `outputDir` may be inaccurate (e.g., uni-app v3 framework: `dist`, actual: `dist/build/h5`):
+
+```bash
+# Find the real index.html after build
+REAL_INDEX=$(find /workspace/<dirname>/<outputDir> -name "index.html" -type f 2>/dev/null | head -1)
+if [ -n "$REAL_INDEX" ] && [ -f "$REAL_INDEX" ]; then
+  REAL_OUTDIR=$(dirname "$REAL_INDEX")
+  echo "Actual output dir: $REAL_OUTDIR"
+  # Use REAL_OUTDIR for nginx config instead of framework-reported outputDir
+fi
+```
+
+If `REAL_OUTDIR` differs from `<outputDir>`, use `REAL_OUTDIR` for all subsequent steps (nginx config, port check, etc.).
+
 **Post-timeout recovery**: if `exec_one_shot` returns a timeout error (Request timed out), do NOT fail immediately. First dump any captured build log, then check the output directory:
 
 ```bash
@@ -468,6 +568,73 @@ tail -5 /tmp/build.log 2>/dev/null
 - For Hugo/static sites where `installCmd` is `null`, skip install entirely.
 - For static sites where `buildCmd` is `null`, skip build entirely.
 
+#### 4c-aux: Build Failure Response
+
+Build failures fall into two categories. Handle them differently:
+
+| Failure Type            | Behavior                                                                                                                                           |
+| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Timeout** (timed out) | Check `/tmp/build.log` tail and output directory — build may have completed but `tee` pipe didn't flush. See Post-timeout recovery above.          |
+| **Non-zero exit code**  | **STOP immediately.** The build engine explicitly rejected the output. Do NOT retry, modify source, or tweak env vars. Follow the procedure below. |
+
+**When a build exits with non-zero exit code:**
+
+1. **STOP** — do NOT retry, do NOT modify source code, do NOT change environment variables
+2. **Extract the error** from `/tmp/build.log`:
+   ```bash
+   tail -30 /tmp/build.log
+   ```
+3. **Present the failure to the developer** with:
+   - The app name and build command that failed
+   - The key error message (last meaningful lines from the build log)
+   - A brief diagnosis of the likely cause
+4. **Offer fix options** (1-3 choices) and **wait for the developer to choose** before applying any fix:
+   - Never modify project source files (configs, scripts, etc.) without explicit approval
+   - If the fix requires editing source code, tell the developer what to change and where
+5. **After the developer selects a fix**, apply it, then restart only the failed build — do NOT rebuild already-succeeded apps
+
+| Rule                   | Rationale                                                      |
+| ---------------------- | -------------------------------------------------------------- |
+| No blind retry         | Retrying without diagnosis wastes time and obscures real error |
+| No silent source edits | Modifying project files without consent destroys trust         |
+| Developer decides fix  | Different projects have different fix preferences              |
+| Only rebuild failed    | Avoid redundant work in monorepo deployments                   |
+
+**Monorepo-specific**: if one sub-app build fails while others succeed, report the failure immediately — do NOT delay until all builds complete. Continue other builds in parallel if possible, but notify the developer as soon as a failure is detected.
+
+#### 4d: Fix Build Output Permissions
+
+After a successful build, fix directory traverse permissions on the build output. Build tools (webpack, vite, uni-app) may create directories with restrictive permissions that block nginx from traversing to `index.html`. **Always resolve symlinks first** — `chmod` does not follow symlinks on Linux:
+
+```bash
+# Fix directory execute permissions for nginx traverse
+REAL_OUTDIR="<outputDir>"   # use actual output dir from post-build verification
+PROJECT_ROOT="/workspace/<dirname>"
+
+# Resolve symlinks — monorepo sub-apps may be symlinked
+REAL_ROOT=$(readlink -f "$PROJECT_ROOT" 2>/dev/null || echo "$PROJECT_ROOT")
+REL_OUTDIR=$(echo "$REAL_OUTDIR" | sed "s|$PROJECT_ROOT/||")
+REAL_OUTDIR="${REAL_ROOT}/${REL_OUTDIR}"
+
+# Fix permissions on resolved real paths
+find "$REAL_ROOT" -path "*/${REAL_OUTDIR}" -prune -o -type d -exec chmod o+x {} \; 2>/dev/null || true
+chmod -R o+rX "$REAL_ROOT" 2>/dev/null || true
+chmod -R +x "$REAL_ROOT/node_modules/.bin" 2>/dev/null || true
+```
+
+This prevents the most common deployment failure: nginx 500 with `stat() ... Permission denied` caused by missing `o+x` on intermediate directories.
+
+#### 4e: Write Deployment Fingerprint
+
+After a successful build, write a deployment fingerprint into the output directory. This enables `deploy_check` to verify the nginx-served content belongs to the current deployment (not a stale process from an earlier session):
+
+```bash
+echo "deployed-$(date +%s)-<dirname>" > /workspace/<dirname>/<outputDir>/.deploy_fingerprint
+chmod o+r /workspace/<dirname>/<outputDir>/.deploy_fingerprint 2>/dev/null || true
+```
+
+> For SSR proxy type, nginx does not serve static files from `.next` — the fingerprint check will gracefully SKIP in `deploy_check`. The fingerprint is still written as a deployment marker for debugging.
+
 ### Step 5: Port Availability Check
 
 **Before configuring nginx or starting the app**, verify the target ports are free. Port conflicts from previous deployments cause silent failures:
@@ -518,17 +685,33 @@ If the port cannot be freed (different user/process), increment to the next avai
 
 #### Configure Nginx
 
-Check `references/nginx-templates.md` for the correct template based on `nginxType`:
+Use `huaweicloud_sandbox_deploy_nginx` to write the correct template, fix directory permissions, and reload nginx — all in one call:
+
+```json
+{
+  "nginx_type": "<nginxType>",
+  "port": <port>,
+  "project": "<dirname>",
+  "output_dir": "<outputDir>",
+  "node_port": <nodePort>,
+  "public_port": <publicPort>
+}
+```
+
+- `nginx_type` — `spa` (SPA/SSG/cross-platform), `proxy` (SSR), or `static` (Hugo/Hexo) from `detect_framework`
+- `port` — listen port from framework detection
+- `project` — project dir name under `/workspace`
+- `output_dir` — build output dir relative to `/workspace/<project>`
+- `node_port` — Node.js app port for SSR proxy. Defaults to `<port> + 1` if omitted, and the result includes `nodePort` so you know which port to bind the Node process to.
+- `public_port` — public listen port for SSR proxy (optional, defaults to `port`)
 
-| nginxType | Template                | When                        |
-| --------- | ----------------------- | --------------------------- |
-| `spa`     | Template 1 (try_files)  | SPA, SSG, cross-platform H5 |
-| `proxy`   | Template 2 (proxy_pass) | SSR (Next.js, Nuxt)         |
-| `static`  | Template 3 (plain root) | Hugo, Hexo, static sites    |
+The tool automatically handles:
 
-Replace `<port>`, `<project>`, `<outputDir>` (and `<nodePort>`/`<publicPort>` for SSR) with detected values.
+- Writing the correct nginx template (SPA try_files, SSR reverse proxy, or static)
+- Fixing `o+x` directory traverse permissions on the project path
+- Reloading nginx
 
-Write the config with `sudo tee`, then reload nginx. If nginx fails, fall back to Python HTTP server (see `references/nginx-templates.md`).
+If the tool returns `ok: false`, nginx may not be installed — fall back to Python HTTP server (see `references/nginx-templates.md`).
 
 **Verify nginx is serving** — curl-check the app before proceeding to DevBridge:
 
@@ -538,48 +721,97 @@ curl -s -o /dev/null -w "nginx status: %{http_code}\n" http://localhost:<port>
 
 If the status code is not 2xx/3xx:
 
-- **403** — likely file permissions: run `chmod -R o+rX /workspace/<project>/<outputDir>` and re-test
+- **403** — run `chmod -R o+rX /workspace/<project>/<outputDir>` and re-test
 - **000 (connection refused)** — nginx not listening: check `sudo nginx -t` for config errors
 - **Other** — check nginx error log: `sudo tail -20 /var/log/nginx/error.log`
 
 > If `curl` is unavailable, check port via `lsof -i :<port>` or `netstat -tlnp | grep :<port>`
 
-### Step 6: Start the App
+### Step 6: Start the App [REQUIRED]
 
 - **Static (SPA/SSG/cross-platform)**: nginx is already serving. Skip.
-- **SSR**: run `<serveCmd>` via `exec_with_session` to start the Node process in background.
+- **SSR**: `PORT=<nodePort>` prefix is REQUIRED before `<serveCmd>`. nginx `proxy_pass` targets `<nodePort>`, not `<port>` — the two must differ. `deployNginx` returns `nodePort` in its result (defaults to `<port> + 1` for proxy type).
+
+  **Runtime environment variables**: SSR apps often need `DATABASE_URL`, `NEXTAUTH_URL`, `NEXTAUTH_SECRET`, etc. at runtime. Before starting, verify env vars from Step 4a are still loaded, and re-source `.env` if the shell session was reset:
+
+  ```bash
+  cd /workspace/<dirname>
+  # Re-load env vars (SSR apps need them at runtime, not just build time)
+  if [ -f .env ]; then set -a && source .env 2>/dev/null; set +a; echo "Loaded .env"; fi
+  if [ -f .env.local ]; then set -a && source .env.local 2>/dev/null; set +a; echo "Loaded .env.local"; fi
+  # Verify critical vars
+  echo "DATABASE_URL=${DATABASE_URL:-<NOT SET>}"
+  echo "NEXTAUTH_URL=${NEXTAUTH_URL:-<NOT SET>}"
+  ```
 
-### Step 7: Expose via DevBridge
+  Then start with `PORT=<nodePort> <serveCmd>` via `exec_with_session` to run the Node process in background.
+
+### Step 7: Expose via DevBridge [REQUIRED — deployment incomplete without this]
 
 Follow the standard [Expose the deployed app](#expose-the-deployed-app-public-url) procedure. The app is already running on the detected port — only DevBridge tunnel setup is needed.
 
 Use `exec_with_session` to background DevBridge. For SSR, DevBridge tunnels the nginx public port (not the Node port directly).
 
-**Pre-flight**: always run `devbridge delete-all` before creating a new tunnel to prevent `10006: quota exceeded` from accumulated stale tunnels. If you still get quota error, list tunnels with `devbridge ls --all`, delete stale ones, and retry.
+**Pre-flight**: always run `devbridge delete-all` before creating a new tunnel to prevent `10006: quota exceeded` from accumulated stale tunnels. If you still get quota error, list tunnels with `devbridge list -j`, delete stale ones, and retry.
 
-### Step 8: Return URL
+Extract the tunnel URL from DevBridge output. The public URL has the form `https://<id>-<port>.cn-north-4-bridge.myhuaweicloud.com`. **Return this URL to the developer as the deployment result.**
 
-Extract the tunnel URL from DevBridge output and return it to the developer.
+#### Cross-platform H5 QR code
 
-**For cross-platform H5 apps** (Taro, uni-app), also generate a QR code for mobile scanning:
+**If `detect_framework` returned `type: "cross-platform"` (Taro, uni-app)**, after exposing the tunnel, generate a QR code for mobile scanning:
 
 ```bash
 TUNNEL_URL="<extracted-tunnel-url>"
 
-# Method 1 (preferred): PNG via curl API (works on all terminals)
-curl -s "https://api.qrserver.com/v1/create-qr-code/?size=300x300&data=$(python3 -c "import urllib.parse, sys; print(urllib.parse.quote(sys.argv[1]))" "$TUNNEL_URL")" -o /workspace/qr.png
-chmod o+r /workspace/qr.png
-echo "QR code saved. Scan QR to access on mobile."
+# Generate QR inside nginx-served output directory so it is accessible via the tunnel URL
+curl -s "https://api.qrserver.com/v1/create-qr-code/?size=300x300&data=$(python3 -c "import urllib.parse, sys; print(urllib.parse.quote(sys.argv[1]))" "$TUNNEL_URL")" -o /workspace/<dirname>/<outputDir>/qr.png
+chmod o+r /workspace/<dirname>/<outputDir>/qr.png
+echo "QR code URL: ${TUNNEL_URL}/qr.png"
 echo "Desktop URL: $TUNNEL_URL"
+```
+
+**Do NOT use `qrencode -t ANSI256`** — terminal ANSI/ASCII QR codes have low precision and phone cameras cannot scan them. Also, never save the QR image outside the nginx root (e.g., `/workspace/qr.png`) — it must be inside the output directory so it is served by nginx alongside the app.
+
+**After generating the QR code**, return both URLs to the developer:
+
+```
+桌面访问: <tunnel-url>
+手机扫码: <tunnel-url>/qr.png
+```
+
+#### Deployment Completion Check [REQUIRED]
 
-# Method 2 (fallback): terminal ANSI QR (requires qrencode, may not render on all terminals)
-# apt-get install -y qrencode || yum install -y qrencode
-# qrencode -t ANSI256 -m 1 -s 2 "$TUNNEL_URL"
+**Before reporting success, call `huaweicloud_sandbox_deploy_check`** to verify the deployment is complete:
+
+```json
+{
+  "port": <port>,
+  "project": "<dirname>",
+  "output_dir": "<outputDir>",
+  "framework_type": "<type>"
+}
 ```
 
-If the sandbox cannot reach `api.qrserver.com`, fall back to installing `qrencode` for terminal QR output. Always `chmod o+r` the generated QR image file.
+The tool checks:
+
+- **nginx_serving** — nginx responds with 2xx/3xx on the app port
+- **output_dir** — build output directory exists and is non-empty
+- **devbridge_tunnel** — DevBridge tunnel is active
+- **tunnel_url_accessible** — tunnel URL returns 200/304
+- **qr_code** (cross-platform only) — QR image exists in output dir
+
+Returns `complete: true/false`, `score`, and `nextStep` to fix missing items.
+
+**If `complete` is false, follow `nextStep` to resolve before reporting success.** Do not return a deployment URL until `complete: true`.
+
+| Framework Type              | Must Return               |
+| --------------------------- | ------------------------- |
+| `cross-platform`            | Desktop URL + QR code URL |
+| `spa` / `ssg` / `static`    | Desktop URL               |
+| `ssr`                       | Desktop URL               |
+| `monorepo` (cross-platform) | Desktop URL + QR code URL |
 
-Return both the QR code and the URL to the developer. For cross-platform apps, mention: "手机扫描二维码即可访问".
+**If the framework is cross-platform and the QR code was not generated, the deployment is incomplete — go back and generate it before reporting success.**
 
 ## References
 
@@ -597,8 +829,12 @@ Return both the QR code and the URL to the developer. For cross-platform apps, m
 | CLI PATH                             | The installer only writes `~/.bashrc`; run `export PATH=$PATH:$HOME/.huawei/bin` in the session before using `devbridge`                                                                                                                |
 | Never install tunnel tooling locally | If the sandbox cannot install it, report a generic error and stop — installing on the developer's machine defeats sandbox deployment                                                                                                    |
 | Return the deployment URL            | Always hand the public URL from the host log to the developer as the final result                                                                                                                                                       |
+| Deploy is not just nginx             | Configuring nginx does NOT complete the deployment. Steps 7 (DevBridge expose) and deploy_check are REQUIRED — `deploy_nginx` returns `nextStep: expose_via_devbridge` as a reminder. Do not stop after nginx.                          |
+| Call deploy_check before success     | Always call `huaweicloud_sandbox_deploy_check` before reporting deployment success. A green nginx status does not mean the tunnel is accessible — verify end-to-end with the tool.                                                      |
 | Session state persists               | `exec_with_session` preserves `cd`, env vars, aliases between calls                                                                                                                                                                     |
 | Long commands prefer one-shot        | `exec_one_shot` creates a fresh connection per call — more stable for builds, installs, and scripts >30s. See [Tool Selection Guide](#tool-selection-guide).                                                                            |
+| SSR nginx/Node ports must differ     | nginx `proxy_pass` targets `<nodePort>`, not `<port>`. `deploy_nginx` auto-defaults `nodePort` to `<port>+1` — always start the Node process with `PORT=<nodePort>` to match. Same-port = EADDRINUSE.                                   |
+| HTTP 200 ≠ correct content           | A green HTTP check does not guarantee the right project is serving — old processes from a previous session bound to the same port will still return 200. `deploy_check` verifies the deployment fingerprint to catch this.              |
 | Destructive commands blocked         | `rm -rf /`, `mkfs`, `dd if=`, fork bombs are denied by safety policy                                                                                                                                                                    |
 | Workspace ID = dev_stage_id          | Use `dev_stage_id` from `sandbox_connect` as `workspace_id` for terminal exec                                                                                                                                                           |
 | Projects live in `/workspace`        | Clone/install project code under `/workspace/<repo-name>` (filesystem-root workspace mount, not `$HOME/workspace`), never in `/tmp` — ephemeral locations lose the project when the sandbox session restarts                            |
@@ -607,6 +843,8 @@ Return both the QR code and the URL to the developer. For cross-platform apps, m
 | Node.js >= 22 required               | Sandbox terminal uses built-in WebSocket (globalThis.WebSocket); if Node.js is missing, install it from the Huawei Cloud mirror (see "Node.js in the sandbox")                                                                          |
 | Sandbox restart kills processes      | After sandbox restarts, all user processes (nginx, Node.js, Python servers) are stopped. Re-run startup commands and verify ports are listening before proceeding.                                                                      |
 | Cross-platform binaries incompatible | The sandbox runs Linux. Native binaries built on Windows/macOS (e.g., Prisma client, `node_modules/.prisma/`, platform-specific native addons) will not execute. Always install and build dependencies inside the sandbox, not locally. |
+| Cross-platform needs QR code         | When `detect_framework` returns `type: "cross-platform"` (Taro, uni-app), generating a QR code image is **mandatory** — the deployment is incomplete without it. Check the Deployment Completion Check table in Step 7.                 |
+| Build fails do NOT auto-fix          | When a build exits with non-zero exit code, STOP and present the error + fix options to the developer. Do not silently retry, modify configs, or change source files without explicit approval. See 4c-aux.                             |
 
 ## Node.js in the sandbox
 

package/plugins/huaweicloud-core/skills/huawei-sandbox/references/nginx-templates.md

@@ -42,6 +42,7 @@ sudo tee /etc/nginx/conf.d/app.conf > /dev/null << 'NGINX_EOF'
 server {
     listen <publicPort>;
     server_name _;
+    large_client_header_buffers 4 32k;
 
     location / {
         proxy_pass http://127.0.0.1:<nodePort>;
@@ -54,6 +55,9 @@ server {
         proxy_set_header X-Forwarded-Proto $scheme;
         proxy_cache_bypass $http_upgrade;
         proxy_read_timeout 60s;
+        proxy_buffer_size 128k;
+        proxy_buffers 4 256k;
+        proxy_busy_buffers_size 256k;
     }
 }
 NGINX_EOF

package/plugins/huaweicloud-core/skills/huawei-smn-dms/SKILL.md

@@ -8,7 +8,7 @@ version: 1
 
 **STOP - Do not answer from general knowledge.** Follow the procedure below.
 
-Always run `hcloud SMN <Operation> --help` or `hcloud DMS <Operation> --help` before constructing commands.
+Always run `hcloud SMN <Operation> --help`, `hcloud Kafka <Operation> --help`, `hcloud RabbitMQ <Operation> --help`, or `hcloud RocketMQ <Operation> --help` before constructing commands.
 
 ## Overview
 
@@ -38,21 +38,28 @@ Domain expertise for SMN (Simple Message Notification) and DMS (Distributed Mess
 
 ## DMS
 
-### Service Types
+> **DMS 是产品统一品牌**，涵盖 Kafka、RabbitMQ、RocketMQ 三种引擎。在 KooCLI 中，三种引擎被拆分为独立服务，**不存在 `hcloud DMS` 命令**。
 
-| Type     | KooCLI Service |
-| -------- | -------------- |
-| Kafka    | `hcloud DMS`   |
-| RabbitMQ | `hcloud DMS`   |
-| RocketMQ | `hcloud DMS`   |
+### Engine → KooCLI Service Mapping
+
+| Engine   | KooCLI Service    | Description          |
+| -------- | ----------------- | -------------------- |
+| Kafka    | `hcloud Kafka`    | 高吞吐分布式消息队列 |
+| RabbitMQ | `hcloud RabbitMQ` | AMQP 消息代理        |
+| RocketMQ | `hcloud RocketMQ` | 低延迟金融级消息队列 |
 
 ### Common Workflows
 
-| Task                  | Operation                                          |
-| --------------------- | -------------------------------------------------- |
-| List instances        | `ListInstances --cli-region=<r> --project_id=<p>`  |
-| Create Kafka instance | `CreateInstance --cli-region=<r> --project_id=<p>` |
-| List Kafka topics     | `ListTopics --cli-region=<r> --project_id=<p>`     |
+| Task                     | Service    | Operation                                                          |
+| ------------------------ | ---------- | ------------------------------------------------------------------ |
+| List Kafka instances     | `Kafka`    | `ListInstances --cli-region=<r> --project_id=<p>`                  |
+| List RabbitMQ instances  | `RabbitMQ` | `ListInstancesDetails --cli-region=<r> --project_id=<p>`           |
+| List RocketMQ instances  | `RocketMQ` | `ListInstances --cli-region=<r> --project_id=<p>`                  |
+| Create Kafka instance    | `Kafka`    | `CreatePostPaidKafkaInstance --cli-region=<r> --project_id=<p>`    |
+| Create RabbitMQ instance | `RabbitMQ` | `CreatePostPaidInstanceByEngine --cli-region=<r> --project_id=<p>` |
+| Create RocketMQ instance | `RocketMQ` | `CreateInstanceByEngine --cli-region=<r> --project_id=<p>`         |
+| List Kafka topics        | `Kafka`    | `ListInstanceTopics --cli-region=<r> --project_id=<p>`             |
+| List RocketMQ topics     | `RocketMQ` | `ListRocketInstanceTopics --cli-region=<r> --project_id=<p>`       |
 
 Discover exact parameters with `--help` before executing any command.