Contentbeheer

Walkthrough voor beginners

Vereisten: Lees de twee onderstaande beginnershandleidingen, voltooi de lokale webconfiguratie en open deze monorepo in de root van uw editor. Webinstellingen horen thuis in apps/web/.env.local; Next.js leest de root .env niet. /dashboard in de standaard nepmodus is een demo zonder database; /auth heeft een gemigreerde database nodig.

Korte termen: een werkruimte bestaat uit de afzonderlijke gebruikers, gegevens en instellingen van één team. De server is de vertrouwde backend; houd providersleutels uit de browser- en telefooncode. Een migratie is een versiebeheer van de database, waarbij tabellen worden gemaakt of bijgewerkt. Een AI-model is de motor die antwoord geeft; de modelcatalogus is de serverlijst met beschikbare model-ID's en prijzen. Een provider is een externe service, zoals een AI-, e-mail- of factureringsservice. Een recht is een subsidie ​​waarmee een werkruimte een functie kan gebruiken. Een webhook is een bericht dat de ene service naar de URL van een andere service verzendt.

1. Meld u aan als eigenaar of beheerder van de werkruimte, open /content en gebruik het formulier om een bericht, pagina, document of rapport met een unieke slug te maken. Sla het op als concept en publiceer het vervolgens.

2. Bevestig de statuswijzigingen naar gepubliceerd; een dubbele slak of lid zonder beheertoegang zou moeten mislukken.

3. Gebruik required_entitlement=ai.reference-task voor een gated test; zonder een geverifieerde toestemming mag de pagina alleen de teaser weergeven.

Voor aangepaste code begint u met de meegeleverde prompts/README.md en kopieert u de dichtstbijzijnde prompt: prompts/new-app-screen.md voor een app-scherm of prompts/new-landing-page.md voor een openbare pagina. Voor server-, database- of providerwerk geeft u uw codeeragent de taak van deze handleiding en vraagt ​​u hem om AGENTS.md, .ai/PROJECT_CONTEXT.md en overeenkomende .ai/-mirrors te lezen; inspecteer de exacte bronbestanden die hier worden genoemd; maak een lijst van bestanden en controleer deze voordat u deze bewerkt; behoud van het eigendom van de werkruimte en geheimen voor de server; en laat je het verschil zien. Vertel het gewenste gedrag, invoer- en uitvoervelden, toegestane rollen, verwacht succes en fouten, en het testaccount, de provider of het apparaat. Gebruik voorbeeldwaarden; plak nooit een echt geheim.

• Voordat u begint
• Basisbeginselen van de terminal
• Lokale webinstellingen
• Agentprompts en projectgeheugen

Werkruimte-items maken

De /content-manager verwerkt post-, page-, doc- en report-gegevens. content_entry-rijen hebben de status concept/gepubliceerd/gearchiveerd, slugs in de werkruimte en auteurschap. Beheeracties vereisen de juiste rol van eigenaar/beheerder.

Deze CMS staat los van de getypte openbare docs/blog-catalogus van de kit in src/resources. Een product kan CMS-items weergeven via zijn eigen paginasamenstelling.

Gate het lichaam op de server

required_entitlement is nulbaar: niet-ingestelde vermeldingen zijn niet-geactiveerd. Voor gated entry's projecteert de server-only content-queries.ts leesbare inhoud of een vergrendelde teaser met een lege body. content-access.ts is eigenaar van de projectie; Vertrouw nooit op een door de klant aangeleverde claim.

Publiceren zendt content.published uit; geplande samenvattingen kunnen de recente bijdragen van het publicatieteam samenvatten. Geschreven inhoud neemt ook deel aan de accountexport.

Verifieer publicatie en toegang

Test de zichtbaarheid van concepten, publiceer/archiveer overgangen, dubbele slugs, verkeerde werkruimte, gratis toegang en inactieve betaalde subsidies. Gebruik het betaalmuurblok voor presentatie terwijl de server verantwoordelijk blijft voor de toegang.

• tutorial met betaalde inhoud
• Inhoudsoverzichten
• Paywall-presentatie

Setup en configuratie

Het workspace-oppervlak /content beheert CMS-items — post, page en doc zijn de voorgestelde types, maar de kolom accepteert elk URL-veilig producttype (kleine letters, cijfers, streepjes, underscores, tot 64 tekens). De tabel content_entry begrenst elke rij per workspaceId, stempelt createdBy en houdt slugs uniek per workspace en type.

Items doorlopen een vrije draft ↔ published ↔ archived-lifecycle — evaluateContentStatusChange in src/content.ts weigert ongeldige of ongewijzigde overgangen, en publishedAt wordt gestempeld bij de eerste publicatie en overleeft latere depublicaties, zodat lezers de oorspronkelijke datum behouden.

/content                    workspace CMS surface
src/content.ts              input + lifecycle rules
src/content-actions.ts      member+ mutations
content_entry               workspaceId, type, slug, status

Implementatieworkflow

Members en hoger schrijven items — elke mutatie resolveert de sessie, de actieve workspace en minimaal de member-rol via requireWorkspaceWriter (workspace-access.ts), dus guests blijven read-only. normalizeContentEntryInput valideert type, een titel van 1–255 tekens en een URL-veilige slug vóór elke schrijfbewerking.

listPublishedContentEntries is de bewuste publieke leesgrens: hij neemt een expliciete workspaceId, vereist geen sessie en geeft alleen gepubliceerde rijen terug — het pad dat storefront-pagina's, blogs en docs gebruiken om workspace-content te renderen. Publiceren zendt een uitgaande content.published-webhook, en geschreven items komen mee in de GDPR-data-export.

Verificatie en probleemoplossing

Test een volledige draft → publish → archive-ronde, een dubbele slug binnen hetzelfde type en een cross-workspace-read. Bevestig dat de publieke grens nooit drafts of rijen van een andere workspace teruggeeft, en dat content.published één keer per publicatie-actie afgaat.