CloudBase All-In-One / TencentCloudBase-CloudBase-AI-Toolkit

CloudBase All-In-One

Flujo de trabajo

Cada tarea de CloudBase sigue este proceso de tres etapas:

1. Exploración  →  Lee la habilidad correspondiente por completo antes de escribir cualquier código.
                   Búscala si es necesario, luego lee el contenido completo de SKILL.md.
                   Solo comienza a implementar después de entender los patrones de la API,
                   las trampas y el uso correcto según el documento de la habilidad.
2. Implementación
   ├── 2a. Preparación de recursos → Prefiere MCP para preparar recursos backend
   │     (habilitar proveedores de autenticación, crear tablas de base de datos, configurar dominios de almacenamiento,
   │      establecer reglas de seguridad — antes de escribir código frontend).
   │     Si faltan herramientas MCP en ESTA sesión, configura MCP para la próxima vez y
   │     usa la CLI `tcb` ahora (`./cloudbase-cli/SKILL.md`).
   └── 2b. Implementación frontend → Escribe código, instala dependencias, inicia el servidor, prueba
3. Cierre  →  Ejecuta cloudbase-code-review, corrige todos los errores, declara finalizado

Restricciones clave:

• La etapa 2a (preparación de recursos) debe venir antes del código frontend. Prefiere herramientas MCP; cuando aún no estén cargadas (primera sesión / antes de reiniciar), recurre a la CLI tcb después de configurar MCP. No escribas código frontend que dependa de recursos no creados (tablas, proveedores de autenticación, buckets de almacenamiento) — el evaluador fallará.
• No omitas la etapa 3. El cierre detecta trampas conocidas que los agentes suelen pasar por alto durante la implementación.

Alcance

Solo maneja tareas que sean parte de construir, integrar o mantener una aplicación de CloudBase — incluyendo diseño de UI, planificación de especificaciones y otras actividades de desarrollo cuando estén al servicio de una aplicación de CloudBase. Si la solicitud no tiene ningún contexto de aplicación de CloudBase, detente e informa al usuario que esta habilidad solo cubre el desarrollo basado en CloudBase.

Contrato de activación

Úsalo primero cuando

• La tarea sea construir, integrar o reparar una aplicación de CloudBase y el espacio de trabajo ya contenga una implementación de la aplicación.
• La solicitud mezcle trabajo de autenticación, base de datos, almacenamiento y frontend en una misma tarea de aplicación de CloudBase.

Haz esto antes de una exploración amplia

• Lee la habilidad relevante antes de escribir cualquier código. Busca la habilidad correspondiente con searchKnowledgeBase(mode="skill", skillName=...), luego Read la ruta del archivo devuelto para obtener el contenido completo de SKILL.md. No empieces a implementar basándote solo en el resumen del resultado de búsqueda — el documento completo contiene firmas de API, esquemas de parámetros y advertencias sobre trampas.
• Inspecciona primero las superficies de implementación existentes:
  • src/lib/backend.*
  • src/lib/auth.*
  • src/lib/*service.*
  • guardias de ruta
  • los manejadores de página vinculados a los botones de envío de formularios activos
• Si estos archivos contienen TODO, implementa esos TODOs en su lugar antes de crear nuevos ayudantes, ejemplos o páginas de reemplazo.
• No empieces con rediseño de UI o salida de especificaciones de diseño a menos que el usuario lo solicite explícitamente.
• No empieces con bucles de gestión de proyectos como repetidos TaskCreate / TaskUpdate cuando la tarea sea una reparación dirigida única. Lee los archivos activos y edítalos directamente.

Enruta rápidamente a las habilidades mínimas necesarias

• Demo web + base de datos mínima / ruta rápida BaaS tipo Lovable -> ./minimal-web-baas-demo/SKILL.md (por defecto para demos frontend-backend mínimas; primero BaaS, sin funciones en la nube)
• Ejecución de aplicación web -> ./web-development/SKILL.md
• Preparación de proveedor de autenticación web -> ./auth-tool/SKILL.md
• Implementación de autenticación web -> ./auth-web/SKILL.md
• Datos de aplicación CloudBase PostgreSQL / PG -> ./postgresql-development/SKILL.md
• WeChat Pay / OAuth de Cuenta Oficial a través del Centro de Integración de CloudBase -> ./cloudbase-wechat-integration/SKILL.md
• CRUD de base de datos documental desde el navegador -> ./no-sql-web-sdk/SKILL.md
• Carga de archivos desde el navegador -> ./cloud-storage-web/SKILL.md
• Visión general de la plataforma solo cuando la selección de capacidades aún no esté clara -> ./cloudbase-platform/SKILL.md
• Si usas searchKnowledgeBase(mode="skill"), pasa el ID del directorio de referencia como postgresql-development-cloudbase o minimal-web-baas-demo, no un alias adivinado.

Guardarraíles de alto rendimiento

• Prepara los recursos backend antes de escribir código frontend. Prefiere MCP para proveedores de autenticación, tablas de base de datos, dominios de almacenamiento y reglas de seguridad. Si faltan herramientas MCP en esta sesión, configura MCP para la próxima sesión y usa la CLI tcb ahora — no te detengas esperando un reinicio. El código frontend escrito contra recursos inexistentes causará fallos en el evaluador.
• Protocolo de seguridad para cambios: Antes de cualquier cambio no trivial en código o configuración, debes seguir estrictamente cloudbase-platform/references/protocols/change-safety-protocol.md (declarar impacto → obtener confirmación del usuario → verificar después del cambio → escalar a análisis de causa raíz después de 3 ocurrencias del mismo síntoma).
• Puerta de despliegue: Antes de cualquier trabajo de despliegue, publicación, dominio personalizado, CloudRun o exposición pública, debes completar las comprobaciones en cloudbase-platform/references/protocols/deployment-gate.md y presentar la plantilla de declaración obligatoria.
• Si la misma ruta falla 2-3 veces, deja de reintentar y redirige. Revisa la habilidad de la plataforma, el dominio de autenticación, el tiempo de ejecución y el modelo de permisos antes de editar más código.
• Siempre especifica EnvId explícitamente en código, configuración y ejemplos de comandos al inicializar clientes de CloudBase u operaciones de gestión. No confíes en el entorno seleccionado por la CLI actual o en los valores predeterminados implícitos.
• Si la conversación solo proporciona un alias de entorno, apodo u otra abreviatura, resuélvelo con envQuery(action=list, alias=..., aliasExact=true) y usa el EnvId completo canónico devuelto antes de llamar a auth.set_env, generar enlaces de consola o escribir config/código. Si el alias es ambiguo o falta, detente y pide al usuario que lo confirme.

NO uses esto como

• Una razón para leer todas las habilidades de CloudBase antes de tocar el código.
• Una razón para empezar desde la visión general de la plataforma cuando el código existente ya revela la pila y las piezas faltantes.

Reglas de trabajo

1. Primero BaaS, funciones como último recurso:

   • Para demos frontend-backend mínimas / tipo Lovable, enruta primero a ./minimal-web-baas-demo/SKILL.md. Orden: conector listo → plantilla de calentamiento durante la espera de credenciales → envQuery → bloquear una DB → esquema MCP → CRUD con @cloudbase/js-sdk → vista previa. Número de funciones en la nube por defecto = 0.
   • Antes de escribir cualquier función en la nube o servicio CloudRun, pregúntate: ¿puede la superficie correcta del SDK JS manejar esto directamente? Usa db.collection(...).get() solo para colecciones NoSQL confirmadas; usa app.rdb().from(...) para tablas CloudBase PG; usa auth / storage de la habilidad correspondiente.
   • Usa la superficie del SDK JS correspondiente directamente para: lecturas/escrituras de datos, cargas de archivos, actualizaciones en tiempo real, consultas simples incluyendo tablas de clasificación, listas, agregaciones.
   • Solo recurre a funciones en la nube cuando: la lógica requiera aplicación de permisos del lado del servidor que no se pueda expresar en reglas de base de datos/RLS, llamar a servicios de terceros (pago, SMS, APIs externas), o trabajos en segundo plano no activados por el usuario.
   • Solo recurre a CloudRun cuando: se requieran conexiones persistentes (WebSocket), cómputo de larga duración o tiempos de ejecución personalizados de forma genuina.

2. Aplicación existente con TODOs:

   • Trátala como una tarea de reparación dirigida, no como una construcción desde cero.
   • Prefiere el camino más corto desde el código actual hasta el flujo de trabajo.

3. Tareas de autenticación:

   • Si el identificador de la cuenta es un nombre de usuario simple como admin, editor u otra cadena sin @, trata el inicio de sesión usernamePassword como un requisito previo bloqueante.
   • Primero llama a queryAppAuth(action="getLoginConfig").
   • Si loginMethods.usernamePassword !== true, llama inmediatamente a manageAppAuth(action="patchLoginStrategy", patch={ usernamePassword: true }).
   • En el código de inicio de sesión web, usa auth.signInWithPassword({ username, password }).
   • No asumas que auth.signUp({ username, password }) web directo está disponible para todos los entornos o versiones del SDK; verifica primero sdkHints / el comportamiento del SDK instalado. Si se requiere registro con nombre de usuario y el registro directo no es compatible, canaliza el registro a través de una ruta de backend o API de gestión que cree usuarios de CloudBase Auth, sin exponer claves secretas en el código del navegador.
   • Nunca uses signUpWithEmailAndPassword o signInWithEmailAndPassword para estos flujos de cuenta con nombre de usuario.
   • Una vez que se confirme la preparación, regresa al manejador frontend activo y completa el flujo real de inicio de sesión/registro.

4. Tareas de base de datos y almacenamiento:

   • Reutiliza los ayudantes compartidos actuales de app, auth, db y almacenamiento en lugar de crear envoltorios paralelos del SDK.
   • Si la tarea menciona CloudBase PG, PostgreSQL, Postgres, modo PG, JS SDK v3 PostgreSQL, app.rdb(), queryPgDatabase, managePgDatabase, OpenAPI mysqldb o RLS, lee ./postgresql-development/SKILL.md antes de tocar el código de la base de datos.
   • Para CloudBase PG, usa queryPgDatabase / managePgDatabase para esquema y gestión; no enrutes trabajo PG a queryMysqlDatabase / manageMysqlDatabase de MySQL o a APIs de colecciones NoSQL.
   • Para búsqueda de OpenAPI, llama directamente a searchKnowledgeBase({ mode: "openapi", apiName: "mysqldb" }). No pases valores adivinados de action como getApiDocs o listEndpoints; esos no pertenecen a ningún modo de herramienta compatible.
   • Para CRUD web de CloudBase PG, prefiere las APIs del SDK JS v3 app.rdb() y de almacenamiento app.storage.from() documentadas antes que HTTP sin formato.
   • Para la carga de almacenamiento de CloudBase desde el navegador en Vite/previsualización local, verifica primero el host:port real del navegador en los dominios de seguridad (envQuery(action="domains"), luego envDomainManagement(action="create") si falta). Una carga de portada fallida no debe saltar silenciosamente la inserción posterior del artículo PG.

• Para db.collection(...).add(...) del SDK web de CloudBase, persiste el ID de documento creado desde result._id.
• Para escrituras, valida el resultado real del SDK en lugar de asumir éxito.
• Tarjeta de STOP de API heredada: Si la tarea dice PostgreSQL, CloudBase PG, modo PG, app.rdb(), queryPgDatabase, managePgDatabase, PostgREST o RLS, no escribas ejemplos NoSQL de memoria. Usa app.rdb().from(...) para CRUD web, queryPgDatabase / managePgDatabase para gestión, y auth.getSession() para guardias de autenticación web. No uses app.database(), db.collection(...), .where(), .orderBy(), app.uploadFile(), getLoginState() o auth.getUser() como valor predeterminado para PG/autenticación.

4. Tareas de reparación dirigida:
   • El cierre funcional supera a la exploración.
   • Evita barridos amplios del repositorio, rediseño de UI y código de demostración independiente.
   • Mantén el descubrimiento de archivos limitado. Prefiere lecturas directas de los archivos activos conocidos en lugar de Glob / búsqueda amplia en todo el proyecto.