cloudbase-all-in-one

# CloudBase All-In-One

## Scope

Only handle tasks that are part of building, integrating, or maintaining a CloudBase application — including UI design, spec planning, and other development activities when they are in service of a CloudBase app. If the request has no CloudBase application context at all, stop and tell the user this skill only covers CloudBase-based development.

## Activation Contract

### Use this first when

- The task is a CloudBase app build, integration, or repair and the workspace already contains an application implementation.
- The request mixes auth, database, storage, and frontend work in one CloudBase application task.

### Do this before broad exploration

- Inspect the existing implementation surfaces first:
  - `src/lib/backend.*`
  - `src/lib/auth.*`
  - `src/lib/*service.*`
  - route guards
  - the page handlers bound to the active form submit buttons
- If these files contain TODOs, implement those TODOs in place before creating new helpers, examples, or replacement pages.
- Do not start with UI redesign or design-spec output unless the user explicitly asks for visual changes.
- Do not start with project-management loops such as repeated `TaskCreate` / `TaskUpdate` when the task is a single targeted repair. Read the active files and edit them directly.

### Route quickly to the minimum needed skills

- Web app execution -> `./web-development/SKILL.md`
- Web auth provider readiness -> `./auth-tool/SKILL.md`
- Web auth implementation -> `./auth-web/SKILL.md`
- WeChat Pay / Official Account OAuth through CloudBase Integration Center -> `./cloudbase-wechat-integration/SKILL.md`
- Browser-side document database CRUD -> `./no-sql-web-sdk/SKILL.md`
- Browser-side file upload -> `./cloud-storage-web/SKILL.md`
- Platform overview only when capability selection is still unclear -> `./cloudbase-platform/SKILL.md`

### High-yield guardrails

- **Change Safety Protocol**: Before any non-trivial code or configuration change, you must strictly follow `cloudbase-platform/references/protocols/change-safety-protocol.md` (declare impact → obtain user confirmation → verify after change → escalate to root cause analysis after 3 occurrences of the same symptom).
- **Deployment Gate**: Before any deployment, publish, custom domain, CloudRun, or public exposure work, you must complete the checks in `cloudbase-platform/references/protocols/deployment-gate.md` and present the mandatory declaration template.
- If the same path fails 2-3 times, stop retrying and reroute. Check platform skill, auth domain, runtime, and permission model before editing more code.
- Always specify `EnvId` explicitly in code, configuration, and command examples when initializing CloudBase clients or manager operations. Do not rely on the current CLI-selected environment or implicit defaults.
- If the conversation only provides an environment alias, nickname, or other shorthand, resolve it with `envQuery(action=list, alias=..., aliasExact=true)` and use the returned canonical full `EnvId` before calling `auth.set_env`, generating console links, or writing config/code. If the alias is ambiguous or missing, stop and ask the user to confirm.

### Do NOT use this as

- A reason to read every CloudBase skill before touching code.
- A reason to start from platform overview when the existing code already reveals the stack and the missing pieces.

## Working rules

1. **BaaS-first, functions as last resort**:
   - Before writing any cloud function or CloudRun service, ask: can the JS SDK handle this directly? (`db.collection(...).get()`, `auth`, `storage`)
   - Use the JS SDK directly for: data reads/writes, file uploads, real-time updates, simple queries including leaderboards, lists, aggregations.
   - Only drop down to cloud functions when: the logic requires server-side permission enforcement that cannot be expressed in database rules, calling third-party services (payment, SMS, external APIs), or background jobs not triggered by the user.
   - Only drop down to CloudRun when: persistent connections (WebSocket), long-running compute, or custom runtimes are genuinely required.

2. Existing application with TODOs:
   - Treat it as a targeted repair task, not a greenfield build.
   - Prefer the shortest path from current code to working flow.

2. Auth tasks:
   - If the account identifier is a plain username such as `admin`, `editor`, or another string without `@`, treat `usernamePassword` login as a blocking prerequisite.
   - First call `queryAppAuth(action=\"getLoginConfig\")`.
   - If `loginMethods.usernamePassword !== true`, immediately call `manageAppAuth(action=\"patchLoginStrategy\", patch={ usernamePassword: true })`.
   - In code, use `auth.signUp({ username, password })` and `auth.signInWithPassword({ username, password })`.
   - Never use `signUpWithEmailAndPassword` or `signInWithEmailAndPassword` for these username-style account flows.
   - Once readiness is confirmed, return to the active frontend handler and finish the real login/register flow.

3. Database and storage tasks:
   - Reuse the current shared `app`, `auth`, `db`, and storage helpers instead of creating parallel SDK wrappers.
   - For CloudBase Web SDK `db.collection(...).add(...)`, persist the created document ID from `result._id`.
   - For writes, validate the actual SDK result instead of assuming success.

4. Targeted repair tasks:
   - Functional closure beats exploration.
   - Avoid broad repo sweeps, UI redesign, and detached demo code.
   - Keep file discovery narrow. Prefer direct reads of the known active files over `Glob` / broad search across the whole project.