@tencent-rtc/trtc-agent-skills 0.1.0 → 0.1.3

package/skills/trtc-onboarding/reference/usersig-handling.md

@@ -1,140 +1,134 @@
-# UserSig Handling (Console-issued test UserSig)
+# UserSig Handling (Conference Web)
 
-> Referenced during login code generation in A2-Q3 (when processing a login-auth
-> slice) and A1 (when configuring demo credentials).
+> Referenced during login code generation in A2-Q2 / A2-Q3 (login-auth slice),
+> official-roomkit completion, and A1 (demo credentials).
 >
-> **There is NO automatic UserSig generation path.** The skill does NOT generate
-> UserSig — not via MCP, not via client-side signing, not via any local script.
-> Test UserSig is ALWAYS obtained by the user from the TRTC console and pasted in.
-> Your job is to (1) emit placeholders, (2) wire up input fields, and (3) hand
-> off clear "how to get & fill UserSig" instructions.
+> Conference Web supports **three** `usersig_source` branches (from A2-Q1.5):
+>
+> | Value | Dev use | Login UI |
+> |-------|---------|----------|
+> | `local-dev` | Config + bundled signing lib | UserID only → `getBasicInfo(userId)` |
+> | `console` | Paste test UserSig from TRTC console | UserID + SDKAppID + UserSig inputs |
+> | `backend` | Production | UserID + API-fetched userSig |
+>
+> **Production** MUST use `backend`. `local-dev` and `console` are for development only.
+
+---
 
-## Why no auto-generation
+## Path A — `local-dev`（config 本地自动签名，推荐）
 
-- **No MCP path.** Do NOT call any `get_usersig` MCP tool. Do NOT tell the user
-  "I'll generate a UserSig for you via MCP." This capability is intentionally not
-  part of the flow — never reference it, never attempt it, never imply it.
-- **No client-side signing.** Generating UserSig in the browser/client requires
-  the `SecretKey`, which must never be shipped to a client. Forbidden (see § Never).
-- **Production** UserSig MUST be issued by the developer's own backend.
+Uses the bundled signing lib (same as medical-consultation template):
+
+```
+skills/trtc/room-builder/assets/local-usersig/
+```
 
-## Generation Protocol (placeholder + console handoff)
+| File | Purpose |
+|------|---------|
+| `basic-info-config.ts` | `SDKAPPID`, `SDKSECRETKEY`, `getBasicInfo(userId)` |
+| `lib-generate-test-usersig-es.min.js` | Tencent test UserSig signer (dev only) |
+| `lib-generate-test-usersig-es.min.d.ts` | TypeScript declarations |
 
-### Step 1: Decide the test userID(s)
+### A2-Q2 (local-dev)
 
-Use `userXXX` (zero-padded 3-digit), default `user001`. If the scenario needs
-two participants (caller + callee, host + audience), also prepare `user002`.
-Honor any userID/naming preference the user already expressed.
+Ask **SDKAppID** + **SecretKey** (控制台 → 应用管理 → 应用信息).
 
-### Step 2: Emit placeholder credentials in the generated code
+- Write `SDKAPPID` to `credentials.sdkappid` in session (reporting).
+- Write both into `src/config/basic-info-config.ts` — **never** persist SecretKey in `.trtc-session.yaml`.
 
-Do NOT fill a real UserSig. Emit clearly-marked placeholders:
+### Login UI
+
+UserID (+ meeting id). On submit: `login(getBasicInfo(userId))`.
 
 ```typescript
-// ================================================
-// Test credentials (development only)
-// ================================================
-const SDK_APP_ID = {sdkAppId};        // your SDKAppID (numeric; 0 if unknown)
-const USER_ID = 'user001';            // test user
-const USER_SIG = 'YOUR_USERSIG';      // ← paste a test UserSig from the TRTC console
-
-// ⚠️ A console-issued test UserSig is for development only and expires
-//    (typically ~24h–7d depending on the console setting).
-//    For production, issue UserSig from YOUR OWN backend.
-//    See: https://trtc.io/document/34385
+import { getBasicInfo } from '@/config/basic-info-config';
+await login(getBasicInfo(userId));
+```
+
+### Handoff
+
+```
+1. 控制台复制 SDKAppID + SecretKey → 填入 src/config/basic-info-config.ts
+2. 登录页输入 UserID（如 user001）— userSig 自动按 UserID 生成
+⚠️ SecretKey 仅本地调试；生产请后端签发。
 ```
 
-If the SDKAppID is known (the user provided it during onboarding), fill it in.
-Otherwise leave the `0` / `YOUR_SDKAPPID` placeholder. The UserSig is ALWAYS a
-placeholder.
+---
 
-### Step 3: Provide a user-input entry
+## Path B — `console`（控制台获取 UserSig 后粘贴）
 
-The generated login page / component MUST include input fields (or a config
-mechanism) that let the user paste their own userID and userSig at runtime.
+Original flow — **retained**. User generates UserSig in TRTC console and pastes it.
 
-**For Web (Vue/React):**
-- Input fields for userID and userSig in the login form
-- Pre-fill userID with `user001`; leave userSig empty or `YOUR_USERSIG`
-- Allow the user to type their own values before clicking login
+### A2-Q2 (console)
 
-**For Native (iOS/Android/Flutter):**
-- A config struct/object with the test defaults and a placeholder userSig
-- Clear comments marking where to paste the console-issued UserSig
-- Optionally: text fields on the login screen if the UI supports it
+Ask **SDKAppID** only (same as before). Do not collect SecretKey.
 
-**Template pattern (Web Vue example):**
+### Generated code
 
-```vue
-<template>
-  <div class="login-form">
-    <input v-model="userId" placeholder="UserID" />
-    <input v-model="userSig" placeholder="Paste UserSig from TRTC console" type="password" />
-    <button @click="handleLogin">Login</button>
-  </div>
-</template>
+```typescript
+const SDK_APP_ID = {sdkAppId};
+const USER_ID = 'user001';
+const USER_SIG = 'YOUR_USERSIG';  // ← paste from TRTC console
+```
 
-<script setup>
-import { ref } from 'vue';
+Login form MUST include:
 
-// Pre-filled test userID; UserSig must be pasted from the console
-const userId = ref('user001');
-const userSig = ref(''); // ← paste a console-issued test UserSig
+- UserID input (pre-fill `user001`)
+- SDKAppID input (pre-fill if known)
+- UserSig input (`type="password"`) — empty or placeholder
 
-// SDKAppID (numeric); fill from your TRTC console
-const sdkAppId = {sdkAppId};
+**Pairing rule (MUST surface in UI):**
 
-async function handleLogin() {
-  // login logic using userId.value, userSig.value, sdkAppId
-}
-</script>
-```
+> UserSig 是按 **UserID** 在控制台签发的，两者必须一一对应。
+> 在「UserSig 生成&校验」里填写的 UserID 必须与登录页一致。
 
-### Step 4: Multiple test users (optional)
+### Handoff — 如何获取并填入 UserSig
 
-If the scenario needs multiple users, emit a placeholder slot for each, clearly
-labeled. The user generates one UserSig per userID in the console:
+```
+⚠️ 还差一步才能登录：代码里的 userSig 是占位符，需从控制台获取。
 
-```typescript
-// User A (e.g., host / caller)
-const USER_A_ID = 'user001';
-const USER_A_SIG = 'YOUR_USERSIG_FOR_user001';  // ← from console
+1. 打开 https://console.trtc.io/（国内站 https://console.cloud.tencent.com）
+2. 进入「快速跑通 / UserSig 生成&校验」
+3. 输入与登录页相同的 UserID（如 user001）生成 UserSig
+4. 将 userSig 填入 <文件路径> 的 USER_SIG / 登录表单 UserSig 框
+   SDKAppID 填入 <文件路径> 的 SDK_APP_ID / SDKAppID 框
 
-// User B (e.g., audience / callee) — use in a second browser tab or device
-const USER_B_ID = 'user002';
-const USER_B_SIG = 'YOUR_USERSIG_FOR_user002';  // ← from console
+注意：控制台 userSig 仅开发联调，会过期；生产环境必须由后端签发。
 ```
 
-## Completion handoff — UserSig fill guidance (MUST surface to the user)
+Do **not** copy the signing bundle for `console`.
 
-Code comments alone are not enough. Because the generated login code NEVER
-contains a working pre-filled UserSig, you MUST — at the end of the integration
-(topic Step 4 area / official-roomkit completion / `integrate-feature` A2-Q4) —
-include a short, explicit **"如何获取并填入 UserSig"** block in the chat handoff,
-not buried in code comments. Template (translate to the user's language):
+---
 
-```
-⚠️ 还差一步才能登录:这套代码里的 userSig 是占位符,需要你从控制台获取真实值后填入。
+## Path C — `backend`（生产）
 
-获取测试 userSig(开发联调用):
-1. 打开 https://console.trtc.io/  →  选择你的应用
-2. 进入「快速跑通 / UserSig 生成&校验」,输入一个 userId(如 user001)生成 UserSig
-3. 把生成的 userSig 填到 <文件路径>:<行号>(变量 `USER_SIG` / 登录表单的 UserSig 输入框)
-   SDKAppID 填到 <文件路径>(变量 `SDK_APP_ID`)
+- No signing bundle, no SecretKey in client.
+- Emit `fetch('/api/conference/usersig')` skeleton + TODO.
+- `userSig` from API response at login time.
 
-注意:控制台生成的 userSig 仅用于开发联调,会过期(约 24h–7d);生产环境必须由你的后端签发。
-```
+---
+
+## Shared rules
+
+### Never
+
+- Call any `get_usersig` MCP tool.
+- Hand-roll with `crypto-js` / `pako` / `HmacSHA256` / custom `src/utils/usersig.ts`
+  (outside the bundled lib for `local-dev` only).
+- Present dev paths as production-ready.
+
+### Allowed
 
-Fill in the real `<文件路径>:<行号>` from the code you just generated. Never claim
-the userSig was auto-generated — it is always a placeholder the user must fill.
+| Branch | Allowed |
+|--------|---------|
+| `local-dev` | `SDKSECRETKEY` in `basic-info-config.ts` + bundled `lib-generate-test-usersig-es.min` |
+| `console` | Placeholder `YOUR_USERSIG` + login form paste fields; no SecretKey |
+| `backend` | API skeleton only; no SecretKey |
 
-## Never
+### Branch self-check
 
-- **Never call any `get_usersig` MCP tool**, and never tell the user the skill can
-  generate a UserSig for them via MCP. This path does not exist.
-- Never hardcode a real `SecretKey` in generated code (client OR sample).
-- Never generate userSig manually (HMAC-SHA256) in client code, and never add
-  browser-side signing dependencies (`crypto-js`, `pako`, `tls-sig-api-v2`).
-- Never create a `**/usersig.*` or `**/generate-usersig.*` signer file.
-- Never present a test userSig as "production-ready" — always mark it test/dev
-  only with an expiry warning, and direct production issuance to the user's backend.
+| `usersig_source` | Expect | Forbid |
+|------------------|--------|--------|
+| `local-dev` | `getBasicInfo`, signing lib in `src/config/` | UserSig input on login page |
+| `console` | UserSig + SDKAppID inputs, `YOUR_USERSIG` placeholder | Signing bundle, `SDKSECRETKEY` |
+| `backend` | fetch skeleton | Signing bundle, SecretKey, UserSig placeholder as final value |

package/skills/trtc-search/SKILL.md

@@ -180,6 +180,13 @@ Bidirectional Chinese↔English translation for common vocabulary is delegated t
 | 踢人 | `kick`, `kickUserOutOfRoom` | Exact method name is non-intuitive |
 | 音效 | `audio-effect`, `changer`, `reverb`, `ear-monitor` | Multiple sub-capabilities under one colloquial term |
 | 观众 | `audience`, `LiveAudienceStore` | Associated Store name is not what a user would guess |
+| 100211 / take-seat | `room-lifecycle`, standard room | Non-seat room internal sync; usually ignorable |
+| 100006 / live room only | `room-lifecycle`, `official-roomkit-api` | Live API called in standard conference room |
+| MediaPermissionCheck / getUserMedia 门禁 | `prejoin-check`, `device-control` | Lightweight browser gate vs Atomicx full prejoin test |
+| DeviceDetector / 两套设备检测 | `prejoin-check`, `device-control` | Dual detection paths need layered responsibilities |
+| 检查遗漏 / 业务流程 / 对照官方 | `conference/integration-audit` (meta slice) | Route to Path B intent F, not code review |
+| 进房失败 | `login-auth`, `room-lifecycle` | Conference Web join/create flow |
+| UserSig 过期 / 6206 | `login-auth` | IM auth layer; cross-product |
 
 For any phrasing NOT listed: let the LLM do its own Chinese↔English bridging, then match against `tags` / `name` / `description` directly. Do NOT expand this table defensively with obvious translations — it only pays for its maintenance cost on the non-obvious ones.
 

package/skills/trtc-topic/SKILL.md

@@ -74,10 +74,9 @@ STOP the normal topic flow immediately. Do NOT show scenario capabilities, do
 NOT run `init_slice_queue.py`, do NOT call `next_slice.py`, do NOT read slice
 files for implementation, do NOT write composables, and do NOT run `apply.py`.
 
-Instead, run the "Headless Web Atomicx / no-UI API-direct mode" Phase H1
-business-flow audit below:
+Instead, run the **TRTC AtomicX API 无 UI 集成** Phase H1 business-flow audit below:
 
-1. Identify the request as "Vue3 Web no-UI Atomicx API-direct integration".
+1. Present the request as: **使用 TRTC AtomicX API 实现无 UI 集成**（composables / stores，界面由业务自行实现）。
 2. Extract business role names only. Do not classify the request as education,
    medical, interview, consultation, or any other vertical scenario just because
    the prompt mentions role names such as teacher/student or doctor/patient.
@@ -133,10 +132,11 @@ Each scenario file declares its own format. Open `${CLAUDE_PLUGIN_ROOT}/${CLAUDE
     enhancement_level: minimal | complete   # minimal = P0 only; complete = P0 + P1
   ```
 - **Form B coverage multi-select (`## 能力展示与 coverage 选择` with a 必装骨架 + 可选模块 multi-select)**: some scenarios (e.g. `general-conference`) are NOT "install everything" — they have an always-on skeleton plus optional modules that must be picked à la carte. When the scenario file declares this variant, follow its "执行规则" verbatim:
-  1. Pre-select ONLY the optional modules that match the session's `target_features` / original prompt (do NOT default-select the rest — this is what caused "user didn't ask for 美颜 but got it").
-  2. Run the file's `AskUserQuestion` multi-select (split into ≤4-option groups if needed).
-  3. Write `confirmed_plan = 必装骨架 + selected optional modules` to `${CLAUDE_PROJECT_DIR}/.trtc-session.yaml`. `confirmed_plan` is the source of truth for `init_slice_queue.py` and everything downstream — unselected modules MUST NOT appear in it.
-  4. If the user's original request was explicitly "完整版 / give me everything", select all optional modules.
+  1. Pre-select ONLY the optional modules that match the session's `target_features` / original prompt (do NOT default-select the rest).
+  2. **Confirm-first shortcut:** when `target_features` already maps cleanly to optional modules (non-empty, unambiguous), show the matched list and ask ONE confirmation question ("以上增强能力无误，继续？") with options: (1) 确认，按此集成; (2) 需要调整能力范围 → then run multi-select. Do NOT re-ask the user to pick features they already named in the initial prompt.
+  3. Only when `target_features` is empty/ambiguous OR the user chose "需要调整", run the file's `AskUserQuestion` multi-select (split into ≤4-option groups if needed).
+  4. Write `confirmed_plan = 必装骨架 + selected optional modules` to `${CLAUDE_PROJECT_DIR}/.trtc-session.yaml`. `confirmed_plan` is the source of truth for `init_slice_queue.py` and everything downstream — unselected modules MUST NOT appear in it.
+  5. If the user's original request was explicitly "完整版 / give me everything", select all optional modules.
 
   Do NOT fall back to "walk the whole `slices:` frontmatter array" for a coverage-multi-select scenario — that re-introduces the over-integration bug.
 
@@ -217,7 +217,7 @@ For each step in the (filtered) scenario sequence:
      **Anti-padding rule (do NOT game the gate):** The gate only checks that the slice's *entry* symbol appears in real code and that there are no duplicate-declaration collisions. It is not a license to manufacture occurrences. NEVER add a redundant destructure, a wrapper function, or a duplicate declaration just to make a symbol show up. If a required symbol is already destructured from one composable, do NOT destructure the same name again from another (`subscribeEvent` from two `use*()` calls) and do NOT also declare it as a `function`/`const` (`getCameraList`) — that is a duplicate declaration that will not compile. When two composables genuinely export the same name, alias one: `const { subscribeEvent: subscribeParticipantEvent } = useRoomParticipantState()`. apply fails on these collisions, but the goal is to never write them in the first place.
    - **G4: Modular structure** — Break implementations into separate files with clear single responsibilities. Don't put all logic into one massive file. Each file should be focused and manageable.
    - **G5: Compilable by default** — Generated code must be compilable when added to a project with the correct SDK installed. Include all necessary imports, type declarations, and protocol conformances. If something can't compile without additional context, note it with a `// TODO:` comment explaining what's needed.
-   - **G6: No client-side UserSig signing** — NEVER generate `src/utils/usersig.ts` or any browser-side UserSig signing utility. NEVER add `crypto-js`, `pako`, `tls-sig-api-v2` as dependencies. NEVER expose `SecretKey` in client code. For login/auth steps, follow `../trtc-onboarding/reference/usersig-handling.md`: emit placeholder values with TODO comments pointing the user to the TRTC console to generate a test UserSig (the skill does NOT auto-generate UserSig). If your generated code contains `HmacSHA256`, `generateUserSig`, `SecretKey` in a non-comment assignment, or imports `crypto-js`/`pako` — STOP, discard, and regenerate following the protocol.
+   - **G6: UserSig per `usersig-handling.md`** — `local-dev`: bundled lib + `getBasicInfo(userId)`; `console`: UserSig paste fields + placeholder; `backend`: API skeleton. No hand-rolled `crypto-js`/`pako`/`src/utils/usersig.ts`.
    - **G7: No invented package versions** — Never write a SemVer range from memory for a Tencent SDK package. Training data goes stale; a guessed range that doesn't exist on the registry breaks `pnpm install` on first run.
 
      - Tencent SDKs (`@tencentcloud/*`, `tuikit-*`, `trtc-sdk-v5`, `trtc-js-sdk`): use `"latest"`.
@@ -232,7 +232,7 @@ For each step in the (filtered) scenario sequence:
 
      | Slice | Decision keys | Effect on generated code |
      |---|---|---|
-     | `conference/login-auth` | `usersig_source` | `"backend"` → emit `fetch('/api/conference/usersig')` skeleton + TODO; `"console"` → emit `'YOUR_USERSIG'` + console-link comment（用户自行到 TRTC 控制台生成测试 UserSig 并填入，skill 不自动签发）|
+     | `conference/login-auth` | `usersig_source` | `"local-dev"` → bundled lib + `getBasicInfo`; `"console"` → paste fields + placeholder; `"backend"` → fetch skeleton |
      | `conference/login-auth` | `userid_strategy` | `"direct"` → `userId = employee.id`; `"uuid-mapping"` → emit mapping fetch skeleton |
      | `conference/login-auth` | `on_session_lost` | `"redirect-login"` / `"auto-refresh"` / `"prompt-user"` → different `onLoginExpired` handler |
      | `conference/room-lifecycle` | `roomid_origin` | `"frontend"` → `createAndJoinRoom`; `"backend-precreated"` → `joinRoom` only + backend fetch; `"join-only"` → no create at all |
@@ -263,7 +263,7 @@ For each step in the (filtered) scenario sequence:
      1. Read the current slice's frontmatter `business_decisions:` field. Does it exist?
      2. If yes → for each key listed there, look up `session_context.business_decisions[<slice-id>][<key>]` in session.
      3. Any key unset? → check its `tier`: `blocking` (or unset) → STOP, route back to A2-Q1.5. `deferrable` → use its `default` + inject TODO, continue.
-     4. All keys resolved (answered or deferred-to-default) → branch the generated code per the values. Verify final code does not contain placeholders / hardcoded values that the decisions were supposed to resolve (e.g. `userSig: 'YOUR_USERSIG'` should only appear if `usersig_source = "console"`).
+     4. All keys resolved → branch per `usersig_source` (`local-dev` / `console` / `backend`).
 
 4. **Highlight the gotchas** — surface the ALWAYS/NEVER rules that apply to this step. Frame them as "the common mistakes I've seen" rather than abstract rules.
 5. **Pause and confirm** — after presenting code and running `apply.py --slice <id>`, ALWAYS pause and wait for user confirmation before proceeding to the next step. See **Step 3 progression rules** below.
@@ -311,28 +311,19 @@ cache it for the whole session. `official-roomkit` is conference-only.
 1. `${CLAUDE_PLUGIN_ROOT}/skills/trtc/room-builder/SKILL.md` — use its
    "官方 RoomKit 集成模式" section as the source of truth.
 2. `${CLAUDE_PLUGIN_ROOT}/skills/trtc-onboarding/reference/usersig-handling.md`
-   — use it as the source of truth for test UserSig handling. Do not generate a
-   client-side signer or write `SecretKey` into `src/`.
+   — local-dev: bundled signing lib + `getBasicInfo(userId)`; backend: no SecretKey in client.
 3. The official quick-start and UI customization docs linked from that section
    when exact package imports, component names, or customization API details
    matter.
 
-**At skill entry, if `ui_mode = headless`, follow the "Headless Web Atomicx /
-no-UI API-direct mode" section below.**
+**At skill entry, if `ui_mode = headless`, follow the「TRTC AtomicX API 无 UI 集成」section below.**
 
-**Headless Web Atomicx / no-UI API-direct mode (MANDATORY when `ui_mode = headless` and `product = conference`, `platform = web`):**
+**TRTC AtomicX API 无 UI 集成（`ui_mode = headless`，`product = conference`，`platform = web`）：**
 
-This is the path for customers who are not using the official demo, not copying a
-template, and not mounting the full RoomKit UI. They already have, or plan to
-build, their own business UI and want code that calls the Web no-UI Atomicx APIs
-directly.
+客户不使用官方 RoomKit 完整界面，自行实现业务 UI，通过 AtomicX API 接入会议能力。
 
-Treat this as a **general Web no-UI API integration**, not an education,
-medical, meeting, interview, consultation, or any other vertical scenario. Words
-such as "teacher/student", "doctor/patient", "host/member", "agent/customer",
-or "interviewer/candidate" are only business role names. Map them to SDK roles
-and permissions (`Owner` / `Admin` / `Member`) without changing the underlying
-API route.
+Treat this as **使用 TRTC AtomicX API 实现无 UI 集成**, not a vertical scenario template. Role names
+(teacher/student, doctor/patient, etc.) map to SDK roles only.
 
 **Official capability whitelist:**
 
@@ -359,7 +350,7 @@ When the customer gives a coarse prompt (for example an MCP-reported "check
 whether the business flow has major omissions" prompt), do NOT start by writing
 code. First return:
 
-1. Recognition: "Vue3 Web no-UI Atomicx API-direct integration", plus the
+1. Recognition: **使用 TRTC AtomicX API 实现无 UI 集成**, plus the
    extracted business role names as role names only.
 2. Covered flow: list what the customer's sentence already covers.
 3. Major omissions: list missing decisions that affect code generation.
@@ -458,9 +449,10 @@ Generate small, embeddable modules for the customer's existing Vue 3 project:
 - Do not generate meeting-classic theme code or `ui-*` based meeting SFCs.
 - Do not use `@tencentcloud/roomkit-web-vue3` `ConferenceMainView` /
   `ConferenceMainViewH5` as the no-UI solution.
-- Do not generate any browser-side UserSig signer, expose `SecretKey`, or add
-  signing dependencies such as `crypto-js`, `pako`, `HmacSHA256`, or
-  `tls-sig-api-v2`.
+- Do not hand-roll UserSig signing (`src/utils/usersig.ts`, `crypto-js`, `pako`,
+  `HmacSHA256`, `tls-sig-api-v2`). Branch per `usersig_source` and
+  `usersig-handling.md`: `local-dev` → bundled lib in `src/config/` only;
+  `console` → paste fields, no SecretKey; `backend` → API-fetched userSig only.
 - Do not call `createAndJoinRoom` / `joinRoom` before `login` and
   `setSelfInfo` finish.
 - Do not treat `scheduleRoom` as joining the audio/video room; scheduling is
@@ -492,18 +484,14 @@ Generate small, embeddable modules for the customer's existing Vue 3 project:
 | `ui_mode` | Output shape | Strategy |
 |---|---|---|
 | `official-roomkit` | Official RoomKit integration files | Integrate `@tencentcloud/roomkit-web-vue3` official components (`ConferenceMainView` / `ConferenceMainViewH5` inside `UIKitProvider`，`UIKitProvider` 从 `@tencentcloud/uikit-base-component-vue3` 导入) into the existing Vue 3 app. Verify the resolved RoomKit version is `>=5.4.3` before using UI customization APIs. Use `conference.login()`, `setSelfInfo()`, `createAndJoinRoom()` / `joinRoom()`, room events, and official customization APIs from room-builder's "官方 RoomKit 集成模式". Do NOT generate meeting-classic SFCs, `ui-*` class templates, or theme assets. |
-| `headless` | Web no-UI Atomicx composables + stores + types + README | Follow "Headless Web Atomicx / no-UI API-direct mode" above. First run Phase H1 business-flow audit when the customer prompt is under-specified. After the flow is clear, generate `src/trtc/composables/*.ts`, `src/trtc/types/index.ts`, and a top-level `README.md`. Do NOT generate any `.vue` files unless the user explicitly asks for a small integration example; if they do, keep it as a thin example that consumes the composables and does not become a demo/template. |
+| `headless` | AtomicX composables + stores + types + README | Follow「TRTC AtomicX API 无 UI 集成」above. Phase H1 audit when prompt is under-specified. Generate `src/trtc/composables/*.ts`, etc. No `.vue` unless user asks for a thin example. |
 | `null` or unset | Topic's default strategy | Fall back to the per-slice code-example approach (pre-ui_mode behavior). Unchanged. |
 
 **Official RoomKit mode acceptance check:**
 
 - The generated app imports and renders the official RoomKit components, not a
   recreated meeting UI.
-- Login code obtains `userSig` through the user's business backend, runtime
-  input, or a placeholder filled from the TRTC console. It must not create
-  `src/utils/usersig.ts`, expose `SecretKey` in client config, or use
-  `crypto-js` / `pako` / `HmacSHA256` / `tls-sig-api-v2` to sign in browser
-  code.
+- Login per `usersig_source`: `local-dev` → `getBasicInfo(userId)`; `console` → paste UserSig from console (UserID must match); `backend` → API-issued userSig.
 - UI changes are implemented through official APIs only:
   `setWidgetVisible()`, `registerWidget()`, `onWill()`, and documented
   `setFeatureConfig()` calls.
@@ -521,13 +509,9 @@ The scenario file may reference slices with `status: planned`. When you hit one
 
 ### Step 4: Verify
 
-**Before the checklist — UserSig fill guidance (MUST):** the generated login
-code always uses a placeholder userSig (the skill does NOT auto-generate one).
-Surface the **"如何获取并填入 UserSig"** handoff block from
-[`../trtc-onboarding/reference/usersig-handling.md`](../trtc-onboarding/reference/usersig-handling.md)
-→ "Completion handoff" to the user, with the real file path / line filled in.
-Direct the user to the TRTC console to generate a test userSig; never claim the
-userSig was auto-generated.
+**Before the checklist — UserSig handoff (MUST):** surface the matching block from
+`usersig-handling.md`: Path A (`local-dev`), Path B (`console` — 如何获取并填入 UserSig),
+or Path C (`backend`). Always remind: UserID 与 UserSig 必须匹配。
 
 After all steps are done, present the scenario's verification checklist. Walk through each item: