Gestão de conteúdo

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-tanstack/.env.local; TanStack Start 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.

• Antes de começar
• Noções básicas sobre terminais
• Configuração local da Web
• Avisos do agente e memória do projeto

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.

• Tutorial sobre conteúdo pago
• Resumos de conteúdo
• Apresentação do acesso pago

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, status

Fluxo 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.