CloudBase All-In-One

O que CloudBase All-In-One faz?

Fluxo de trabalho

Toda tarefa do CloudBase segue este processo de três estágios:

1. Exploração  →  Leia o skill correspondente completamente antes de escrever qualquer código.
                   Pesquise por ele se necessário, depois leia o conteúdo completo do SKILL.md.
                   Só comece a implementar após entender os padrões da API,
                   armadilhas e uso correto a partir do documento do skill.
2. Implementação
   ├── 2a. Preparação de recursos → Prefira MCP para preparar recursos de backend
   │     (ativar provedores de autenticação, criar tabelas de banco de dados, configurar domínios de armazenamento,
   │      definir regras de segurança — antes de escrever código do frontend).
   │     Se as ferramentas MCP estiverem ausentes nesta sessão, configure MCP para a próxima vez e
   │     use o CLI `tcb` agora (`./cloudbase-cli/SKILL.md`).
   └── 2b. Implementação do frontend → Escreva código, instale dependências, inicie o servidor, teste
3. Fechamento  →  Execute cloudbase-code-review, corrija todos os erros, declare concluído

Restrições-chave:

• O estágio 2a (preparação de recursos) deve vir antes do código do frontend. Prefira ferramentas MCP; quando elas ainda não estiverem carregadas (primeira sessão / pré-restart), recorra ao CLI tcb após configurar MCP. Não escreva código de frontend que dependa de recursos não criados (tabelas, provedores de autenticação, buckets de armazenamento) — o avaliador falhará.
• Não pule o estágio 3. O fechamento captura armadilhas conhecidas que os agentes comumente perdem durante a implementação.

Escopo

Lide apenas com tarefas que fazem parte da construção, integração ou manutenção de uma aplicação CloudBase — incluindo design de UI, planejamento de especificações e outras atividades de desenvolvimento quando estiverem a serviço de uma aplicação CloudBase. Se a solicitação não tiver nenhum contexto de aplicação CloudBase, pare e informe ao usuário que este skill cobre apenas desenvolvimento baseado em CloudBase.

Contrato de Ativação

Use este primeiro quando:

• A tarefa é uma construção, integração ou reparo de aplicação CloudBase e o espaço de trabalho já contém uma implementação de aplicação.
• A solicitação mistura trabalho de autenticação, banco de dados, armazenamento e frontend em uma única tarefa de aplicação CloudBase.

Faça isso antes de exploração ampla:

• Leia o skill relevante antes de escrever qualquer código. Pesquise o skill correspondente com searchKnowledgeBase(mode="skill", skillName=...), depois Read o caminho do arquivo retornado para obter o conteúdo completo do SKILL.md. Não comece a implementar baseado apenas no resumo do resultado da pesquisa — o documento completo contém assinaturas de API, esquemas de parâmetros e avisos de armadilhas.
• Inspecione primeiro as superfícies de implementação existentes:
  • src/lib/backend.*
  • src/lib/auth.*
  • src/lib/*service.*
  • guardas de rota
  • os manipuladores de página vinculados aos botões de envio de formulário ativos
• Se esses arquivos contiverem TODOs, implemente esses TODOs no lugar antes de criar novos helpers, exemplos ou páginas de substituição.
• Não comece com redesign de UI ou saída de especificação de design, a menos que o usuário peça explicitamente por mudanças visuais.
• Não comece com loops de gerenciamento de projeto, como repetidos TaskCreate/TaskUpdate, quando a tarefa é um único reparo direcionado. Leia os arquivos ativos e edite-os diretamente.

Roteie rapidamente para os skills mínimos necessários:

• Demo Web + banco de dados mínimo / caminho rápido BaaS estilo Lovable -> ./minimal-web-baas-demo/SKILL.md (padrão para demo frontend-backend mínimo; BaaS-first, sem funções cloud)
• Execução de aplicação Web -> ./web-development/SKILL.md
• Prontidão de provedor de autenticação Web -> ./auth-tool/SKILL.md
• Implementação de autenticação Web -> ./auth-web/SKILL.md
• Dados de aplicação CloudBase PostgreSQL/PG -> ./postgresql-development/SKILL.md
• Pagamento WeChat / OAuth de Conta Oficial através do Centro de Integração CloudBase -> ./cloudbase-wechat-integration/SKILL.md
• CRUD de banco de dados documento no lado do navegador -> ./no-sql-web-sdk/SKILL.md
• Upload de arquivo no lado do navegador -> ./cloud-storage-web/SKILL.md
• Visão geral da plataforma apenas quando a seleção de capacidades ainda não estiver clara -> ./cloudbase-platform/SKILL.md
• Se usar searchKnowledgeBase(mode="skill"), passe o id do diretório de referência como postgresql-development-cloudbase ou minimal-web-baas-demo, não um alias adivinhado.

Guardrails de alto rendimento:

• Prepare recursos de backend antes de escrever código do frontend. Prefira MCP para provedores de autenticação, tabelas de banco de dados, domínios de armazenamento e regras de segurança. Se as ferramentas MCP estiverem ausentes nesta sessão, configure MCP para a próxima sessão e use o CLI tcb agora — não pare esperando reinicialização. Código de frontend escrito contra recursos inexistentes causará falhas no avaliador.
• Protocolo de Segurança de Mudança: Antes de qualquer alteração não trivial de código ou configuração, você deve seguir rigorosamente cloudbase-platform/references/protocols/change-safety-protocol.md (declarar impacto → obter confirmação do usuário → verificar após a alteração → escalar para análise de causa raiz após 3 ocorrências do mesmo sintoma).
• Portão de Implantação: Antes de qualquer trabalho de implantação, publicação, domínio personalizado, CloudRun ou exposição pública, você deve completar as verificações em cloudbase-platform/references/protocols/deployment-gate.md e apresentar o modelo de declaração obrigatória.
• Se o mesmo caminho falhar 2-3 vezes, pare de tentar e redirecione. Verifique o skill da plataforma, domínio de autenticação, runtime e modelo de permissão antes de editar mais código.
• Sempre especifique EnvId explicitamente em código, configuração e exemplos de comando ao inicializar clientes CloudBase ou operações de gerenciamento. Não confie no ambiente atualmente selecionado pelo CLI ou em padrões implícitos.
• Se a conversa fornecer apenas um alias de ambiente, apelido ou outra abreviatura, resolva com envQuery(action=list, alias=..., aliasExact=true) e use o EnvId completo canônico retornado antes de chamar auth.set_env, gerar links do console ou escrever config/código. Se o alias for ambíguo ou ausente, pare e peça ao usuário para confirmar.

NÃO use isso como:

• Uma razão para ler todo skill do CloudBase antes de tocar no código.
• Uma razão para começar pela visão geral da plataforma quando o código existente já revela a pilha e as peças faltantes.

Regras de trabalho

1. BaaS-first, funções como último recurso:

   • Para demos frontend-backend mínimos / estilo Lovable, roteie primeiro para ./minimal-web-baas-demo/SKILL.md. Ordem: conector pronto → template warmup durante espera de credencial → envQuery → travar um DB → esquema MCP → @cloudbase/js-sdk CRUD → pré-visualizar. Contagem padrão de funções cloud = 0.
   • Antes de escrever qualquer função cloud ou serviço CloudRun, pergunte: a superfície correta do JS SDK pode lidar diretamente com isso? Use db.collection(...).get() apenas para coleções NoSQL confirmadas; use app.rdb().from(...) para tabelas CloudBase PG; use auth/storage do skill correspondente.
   • Use a superfície correta do JS SDK diretamente para: leituras/escritas de dados, uploads de arquivos, atualizações em tempo real, consultas simples incluindo rankings, listas, agregações.
   • Só desça para funções cloud quando: a lógica exigir imposição de permissão no lado do servidor que não pode ser expressa em regras de banco/RLS, chamar serviços de terceiros (pagamento, SMS, APIs externas), ou trabalhos em segundo plano não acionados pelo usuário.
   • Só desça para CloudRun quando: conexões persistentes (WebSocket), computação de longa duração, ou runtimes personalizados forem genuinamente necessários.

2. Aplicação existente com TODOs:

   • Trate como uma tarefa de reparo direcionado, não uma construção do zero.
   • Prefira o caminho mais curto do código atual para o fluxo funcional.

3. Tarefas de autenticação:

   • Se o identificador da conta for um nome de usuário simples como admin, editor ou outra string sem @, trate o login usernamePassword como um pré-requisito bloqueante.
   • Primeiro chame queryAppAuth(action="getLoginConfig").
   • Se loginMethods.usernamePassword !== true, imediatamente chame manageAppAuth(action="patchLoginStrategy", patch={ usernamePassword: true }).
   • No código de login Web, use auth.signInWithPassword({ username, password }).
   • Não assuma que auth.signUp({ username, password }) direto na Web está disponível para todo ambiente ou versão do SDK; verifique sdkHints / comportamento do SDK instalado primeiro. Se o registro por nome de usuário for necessário e o cadastro direto não for suportado, roteie o registro através de um backend ou caminho de API de gerenciamento que crie usuários CloudBase Auth, sem expor chaves secretas no código do navegador.
   • Nunca use signUpWithEmailAndPassword ou signInWithEmailAndPassword para esses fluxos de conta estilo nome de usuário.
   • Uma vez que a prontidão seja confirmada, retorne ao manipulador do frontend ativo e finalize o fluxo real de login/registro.

4. Tarefas de banco de dados e armazenamento:

   • Reutilize os helpers compartilhados atuais app, auth, db e armazenamento em vez de criar wrappers paralelos do SDK.
   • Se a tarefa mencionar CloudBase PG, PostgreSQL, Postgres, modo PG, JS SDK v3 PostgreSQL, app.rdb(), queryPgDatabase, managePgDatabase, mysqldb OpenAPI, ou RLS, leia ./postgresql-development/SKILL.md antes de tocar no código do banco de dados.
   • Para CloudBase PG, use queryPgDatabase/managePgDatabase para esquema e gerenciamento; não roteie trabalho PG para MySQL queryMysqlDatabase/manageMysqlDatabase ou APIs de coleção NoSQL.
   • Para consulta OpenAPI, chame searchKnowledgeBase({ mode: "openapi", apiName: "mysqldb" }) diretamente. Não passe valores adivinhados de action como getApiDocs ou listEndpoints; eles não pertencem a nenhum modo de ferramenta suportado.
   • Para CRUD Web CloudBase PG, prefira JS SDK v3 app.rdb() e APIs de armazenamento documentadas app.storage.from() antes de HTTP bruto.
   • Para upload de armazenamento CloudBase do lado do navegador a partir de Vite/preview local, verifique o host:porta real do navegador nos domínios de segurança primeiro (envQuery(action="domains"), depois envDomainManagement(action="create") se ausente). Um upload de capa falho não deve pular silenciosamente a inserção subsequente do artigo PG.

• Para db.collection(...).add(...) do Web SDK CloudBase, persista o ID do documento criado a partir de result._id.
• Para escritas, valide o resultado real do SDK em vez de assumir sucesso.
• Cartão de PARADA de API legada: Se a tarefa disser PostgreSQL, CloudBase PG, modo PG, app.rdb(), queryPgDatabase, managePgDatabase, PostgREST ou RLS, não escreva exemplos NoSQL de memória. Use app.rdb().from(...) para CRUD Web, queryPgDatabase/managePgDatabase para gerenciamento e auth.getSession() para guardas de autenticação Web. Não use app.database(), db.collection(...), .where(), .orderBy(), app.uploadFile(), getLoginState() ou auth.getUser() como padrão para PG/auth.

4. Tarefas de reparo direcionado:
   • Fechamento funcional supera exploração.
   • Evite varreduras amplas do repositório, redesign de UI e código de demonstração destacado.
   • Mantenha a descoberta de arquivos estreita. Prefira leituras diretas dos arquivos ativos conhecidos em vez de Glob/busca ampla por todo o projeto.