For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /pt/docs/web/content.md (or send Accept: text/markdown).
Gestão de conteúdo
Entradas CMS tipadas com um ciclo de vida livre e um limite de leitura público.
Passo a passo para iniciantes
Pré-requisitos: Leia os dois guias para iniciantes abaixo, conclua a configuração local da Web e abra este monorepo na raiz do seu editor. As configurações da Web pertencem a apps/web/.env.local; Next.js não lê a raiz .env. /dashboard no modo falso padrão é uma demonstração sem banco de dados; /auth precisa de um banco de dados migrado.
Termos rápidos: um espaço de trabalho consiste em usuários, dados e configurações separados de uma equipe. O servidor é o back-end confiável; mantenha as chaves do provedor fora do navegador e do código do telefone. Uma migração é uma alteração de versão do banco de dados que cria ou atualiza tabelas. Um modelo de IA é o mecanismo que responde; o catálogo de modelos é a lista do servidor de IDs e preços de modelos disponíveis. Um provedor é um serviço externo, como IA, e-mail ou serviço de cobrança. Um direito é uma concessão que permite que um espaço de trabalho use um recurso. Um webhook é uma mensagem que um serviço envia para o URL de outro serviço.
1. Faça login como proprietário ou administrador do espaço de trabalho, abra /content e use o formulário para criar uma postagem, página, documento ou relatório com um slug exclusivo. Salve-o como rascunho e publique-o.
2. Confirme a alteração do status para publicado; um slug ou membro duplicado sem acesso de gerenciamento deverá falhar.
3. Para um teste fechado, use required_entitlement=ai.reference-task; sem concessão verificada, a página deverá exibir apenas seu teaser.
Para código personalizado, comece com o prompts/README.md fornecido e copie o prompt mais próximo: prompts/new-app-screen.md para uma tela de aplicativo ou prompts/new-landing-page.md para uma página pública. Para trabalho de servidor, banco de dados ou provedor, dê ao seu agente de codificação a tarefa deste guia e peça-lhe para ler AGENTS.md, .ai/PROJECT_CONTEXT.md e espelhos .ai/ correspondentes; inspecione os arquivos de origem exatos nomeados aqui; listar arquivos e verificações antes de editar; preservar a propriedade do espaço de trabalho e os segredos apenas do servidor; e mostrar a diferença. Informe o comportamento desejado, campos de entrada e saída, funções permitidas, sucessos e erros esperados e a conta de teste, provedor ou dispositivo. Use valores de amostra; nunca cole um segredo real.
Criar entradas de espaço de trabalho
O gerenciador /content manipula entradas post, page, doc e report. As linhas content_entry têm estado de rascunho/publicado/arquivado, slugs e autoria no escopo do espaço de trabalho. As ações de gerenciamento exigem a função apropriada de proprietário/administrador.
Este CMS é separado do catálogo público docs/blog digitado do kit em src/resources. Um produto pode renderizar entradas CMS por meio de sua própria composição de página.
Gate o corpo no servidor
required_entitlement é anulável: entradas não definidas não são bloqueadas. Para entradas bloqueadas, o content-queries.ts somente para servidor projeta conteúdo legível ou um teaser bloqueado com corpo vazio. content-access.ts possui a projeção; nunca confie em uma reivindicação de direito fornecida pelo cliente.
A publicação emite content.published; resumos programados podem resumir as entradas recentes da equipe de publicação. O conteúdo de autoria também participa da exportação da conta.
Verifique a publicação e o acesso
Teste a visibilidade do rascunho, transições de publicação/arquivamento, slugs duplicados, espaço de trabalho errado, entradas gratuitas e concessões pagas inativas. Use o bloco de acesso pago para apresentação enquanto o servidor permanece responsável pelo acesso.
Instalação e configuração
A superfície de workspace /content gere entradas CMS — post, page e doc são os tipos sugeridos, mas a coluna aceita qualquer tipo de produto seguro para URL (minúsculas, dígitos, hífenes, underscores, até 64 caracteres). A tabela content_entry delimita cada linha por workspaceId, regista createdBy e mantém os slugs únicos por workspace e tipo.
As entradas percorrem um ciclo de vida livre draft ↔ published ↔ archived — o evaluateContentStatusChange em src/content.ts rejeita transições inválidas ou inalteradas, e o publishedAt é marcado na primeira publicação e sobrevive a despublicações posteriores, para que os leitores mantenham a data original.
/content workspace CMS surface
src/content.ts input + lifecycle rules
src/content-actions.ts member+ mutations
content_entry workspaceId, type, slug, statusFluxo de implementação
Membros e acima criam entradas — cada mutação resolve a sessão, o workspace ativo e pelo menos o papel de membro através de requireWorkspaceWriter (workspace-access.ts), pelo que convidados ficam só de leitura. O normalizeContentEntryInput valida o tipo, um título de 1–255 caracteres e um slug seguro para URL antes de qualquer escrita.
O listPublishedContentEntries é o limite de leitura público deliberado: recebe um workspaceId explícito, não precisa de sessão e devolve apenas linhas publicadas — o caminho que páginas de vitrine, blogs e docs usam para renderizar conteúdo do workspace. Publicar emite um webhook de saída content.published, e as entradas criadas entram na exportação de dados GDPR.
Verificação e resolução de problemas
Exercita um ciclo completo draft → publish → archive, um slug duplicado dentro do mesmo tipo e uma leitura entre workspaces. Confirma que o limite público nunca devolve rascunhos nem linhas de outro workspace, e que o content.published dispara uma vez por ação de publicação.