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 /it/docs/tanstack/content.md (or send Accept: text/markdown).
Gestione dei contenuti
Voci CMS tipizzate con ciclo di vita libero e un confine di lettura pubblico.
Procedura dettagliata per principianti
Prerequisiti: leggi le due guide per principianti di seguito, completa la configurazione locale del Web e apri questo monorepo alla radice nel tuo editor. Le impostazioni Web appartengono a apps/web-tanstack/.env.local; TanStack Start non legge la radice .env. /dashboard nella modalità falsa predefinita è una demo senza database; /auth necessita di un database migrato.
Termini rapidi: uno spazio di lavoro è costituito da utenti, dati e impostazioni separati di un team. Il server è il backend affidabile; mantenere le chiavi del provider fuori dal browser e dal codice del telefono. Una migrazione è una modifica del database con versione che crea o aggiorna tabelle. Un modello AI è il motore che risponde; il catalogo dei modelli è l'elenco del server degli ID e dei prezzi dei modelli disponibili. Un fornitore è un servizio esterno come un servizio di intelligenza artificiale, posta elettronica o fatturazione. Un diritto è una concessione che consente a un'area di lavoro di utilizzare una funzionalità. Un webhook è un messaggio che un servizio invia allo URL di un altro servizio.
1. Accedi come proprietario o amministratore dell'area di lavoro, apri /content e utilizza il modulo per creare un post, una pagina, un documento o un report con uno slug univoco. Salvalo come bozza, quindi pubblicalo.
2. Confermare le modifiche allo stato in pubblicato; uno slug o un membro duplicato senza accesso di gestione dovrebbe fallire.
3. Per un test con gate, utilizzare required_entitlement=ai.reference-task; senza una concessione verificata, la pagina deve mostrare solo il suo teaser.
Per il codice personalizzato, inizia con prompts/README.md in dotazione e copia il prompt più vicino: prompts/new-app-screen.md per la schermata di un'app o prompts/new-landing-page.md per una pagina pubblica. Per il lavoro su server, database o provider, assegna al tuo agente di codifica il compito di questa guida e chiedigli di leggere AGENTS.md, .ai/PROJECT_CONTEXT.md e i mirror .ai/ corrispondenti; controllare gli esatti file sorgente nominati qui; elencare file e controlli prima della modifica; preservare la proprietà dello spazio di lavoro e i segreti solo del server; e mostrarti la differenza. Indicagli il comportamento desiderato, i campi di input e output, i ruoli consentiti, i successi e gli errori previsti e l'account, il fornitore o il dispositivo di prova. Utilizzare valori campione; non incollare mai un vero segreto.
Creare voci nell'area di lavoro
Il gestore /content gestisce le voci post, page, doc e report. Le righe content_entry hanno lo stato bozza/pubblicato/archiviato, slug con ambito area di lavoro e paternità. Le azioni di gestione richiedono il ruolo di proprietario/amministratore appropriato.
Questo CMS è separato dal catalogo pubblico docs/blog digitato del kit in src/resources. Un prodotto può eseguire il rendering delle voci CMS attraverso la propria composizione della pagina.
Porta il corpo sul server
required_entitlement è annullabile: le voci non impostate non hanno un gate. Per le voci delimitate, content-queries.ts solo server proietta contenuto leggibile o un teaser bloccato con un corpo vuoto. content-access.ts possiede la proiezione; non fidarsi mai di una richiesta di titolarità fornita dal cliente.
La pubblicazione emette content.published; i riepiloghi pianificati possono riassumere le voci recenti del team editoriale. Anche il contenuto creato partecipa all'esportazione dell'account.
Verifica la pubblicazione e l'accesso
Testare la visibilità delle bozze, le transizioni di pubblicazione/archiviazione, slug duplicati, spazio di lavoro sbagliato, voci gratuite e sovvenzioni a pagamento inattive. Utilizza il blocco paywall per la presentazione mentre il server rimane responsabile dell'accesso.
Installazione e configurazione
La superficie di workspace /content gestisce le voci CMS — post, page e doc sono i tipi suggeriti, ma la colonna accetta qualsiasi tipo prodotto sicuro per l'URL (minuscole, cifre, trattini, underscore, fino a 64 caratteri). La tabella content_entry delimita ogni riga per workspaceId, marca createdBy e mantiene gli slug unici per workspace e tipo.
Le voci attraversano un ciclo di vita libero draft ↔ published ↔ archived — evaluateContentStatusChange in src/content.ts rifiuta transizioni non valide o invariate, e publishedAt viene marcato alla prima pubblicazione e sopravvive alle rimozioni successive, così i lettori mantengono la data originale.
/content workspace CMS surface
src/content.ts input + lifecycle rules
src/content-actions.ts member+ mutations
content_entry workspaceId, type, slug, statusFlusso di implementazione
I membri e i ruoli superiori creano le voci — ogni mutazione risolve sessione, workspace attivo e almeno il ruolo di membro tramite requireWorkspaceWriter (workspace-access.ts), quindi gli ospiti restano in sola lettura. normalizeContentEntryInput valida tipo, un titolo di 1–255 caratteri e uno slug sicuro per l'URL prima di qualsiasi scrittura.
listPublishedContentEntries è il confine di lettura pubblico deliberato: prende un workspaceId esplicito, non richiede sessione e restituisce solo righe pubblicate — il percorso che pagine vetrina, blog e documentazione usano per renderizzare i contenuti del workspace. La pubblicazione emette un webhook in uscita content.published, e le voci create entrano nell'export dati GDPR.
Verifica e risoluzione dei problemi
Esercita un ciclo completo draft → publish → archive, uno slug duplicato nello stesso tipo e una lettura tra workspace. Conferma che il confine pubblico non restituisca mai bozze o righe di un altro workspace, e che content.published scatti una volta per azione di pubblicazione.