riverbankcms 0.1.0 → 0.2.0

package/dist/cli/init-docs/content/cli-reference.md

@@ -914,14 +914,14 @@ riverbankcms event get summer-fest
 riverbankcms event upsert summer-fest --file ./content/events/summer-fest.json
 riverbankcms event cancel summer-fest
 riverbankcms event delete summer-fest --yes
-riverbankcms event occurrence list summer-fest
-riverbankcms event occurrence add summer-fest \
+riverbankcms event occurrence list summer-fest summer-run
+riverbankcms event occurrence add summer-fest summer-run \
   --starts-at 2026-08-01T10:00 \
   --duration-minutes 60
-riverbankcms event occurrence update summer-fest <occurrence-uuid> \
+riverbankcms event occurrence update summer-fest summer-run <occurrence-uuid> \
   --capacity 20
-riverbankcms event occurrence cancel summer-fest <occurrence-uuid>
-riverbankcms event occurrence delete summer-fest <occurrence-uuid> --yes
+riverbankcms event occurrence cancel summer-fest summer-run <occurrence-uuid>
+riverbankcms event occurrence delete summer-fest summer-run <occurrence-uuid> --yes
 ```
 
 `event upsert` and `push events` accept canonical event files with `path` and `blocks`. Events use native page authority: an `eventOffering` or `eventSeries` subject owns a page surface, and that surface owns its route, field content, publication state, and slots. `path` updates the page-surface route. `blocks` maps slot keys to surface-slot blocks, for example `blocks.main` for the built-in event template. Use stable block identifiers so repeat pushes update existing slot blocks safely. Unknown slot keys or block kinds fail validation; default slots accept enabled SDK `custom.*` blocks, while explicit template `allowedBlocks` lists remain authoritative. Ordinary editorial entries continue to use the separate `entry` commands and content-entry model described above.
@@ -932,7 +932,9 @@ riverbankcms event occurrence delete summer-fest <occurrence-uuid> --yes
 series. Mutation commands always use the occurrence UUID shown by `list`; a
 calendar date is never accepted as an identity.
 
-- `list <event-identifier>` shows all future dates, including cancelled dates.
+- `list <event-identifier> <run-identifier>` shows all future dates, including
+  cancelled dates. The parent Event and run are both explicit, so multi-run
+  Events never rely on an ambiguous identifier.
   Add `--all` to include history or `--status scheduled|cancelled|completed` to
   filter. The CLI follows the API's bounded pages, while `--json` keeps the
   canonical UTC instants in its single result envelope.

package/dist/cli/init-docs/content/workflow-isr-revalidation.md

@@ -7,12 +7,13 @@ Configure a Riverbank SDK Next.js App Router site to prerender published routes,
 ## Prerequisites
 
 - A Riverbank SDK site using `createCatchAllPage()` in `src/app/[[...slug]]/page.tsx`.
-- A production content API key in `RIVERBANK_API_KEY`.
-- `RIVERBANK_SITE_ID` set to this site's Riverbank site ID.
-- `NEXT_PUBLIC_DASHBOARD_URL` set to the dashboard origin, for example `https://cms.example.com`.
+- A configured `getRiverbankClient()` helper and `siteId` in `riverbank.config.ts`.
 - `RIVERBANK_WEBHOOK_SECRET` set from the CMS-generated Riverbank webhook secret.
 
-Preview deployments should also set `RIVERBANK_PREVIEW_MODE=true` so draft previews stay dynamic instead of serving stale ISR HTML.
+Sites scaffolded with preview support should set `RIVERBANK_PREVIEW_MODE=true` in
+preview deployments. The SDK preview integration reads the request-bound preview
+session and opts those requests into dynamic rendering; the literal ISR interval
+remains unchanged.
 
 ## Configure the Catch-All Route
 
@@ -21,21 +22,26 @@ In `src/app/[[...slug]]/page.tsx`:
 ```tsx
 import {
   createCatchAllPage,
-  generateAllStaticParams,
-  getISRConfig,
+  createGenerateStaticParams,
 } from '@riverbankcms/sdk/next'
 
 import config from '@/riverbank.config'
 import { blockOverrides } from '@/lib/block-overrides'
 import { getRiverbankClient } from '@/lib/riverbank-client'
 
-export const revalidate = getISRConfig().revalidate
+// Next.js route config values must remain statically analyzable literals.
+export const revalidate = 300
 export const dynamicParams = true
-export { generateAllStaticParams as generateStaticParams }
+export const generateStaticParams = createGenerateStaticParams({
+  getClient: getRiverbankClient,
+  siteId: config.siteId,
+  failureMode: 'throw',
+})
 
 const { Page, generateMetadata } = createCatchAllPage({
   getClient: getRiverbankClient,
   config,
+  searchParamsMode: 'ignore',
   blockOverrides,
 })
 
@@ -43,7 +49,18 @@ export default Page
 export { generateMetadata }
 ```
 
-`generateAllStaticParams()` discovers published pages and routable entries at build time. It reads:
+`searchParamsMode: 'ignore'` is required for this ISR shape because reading the
+Next.js page `searchParams` prop opts the route into dynamic rendering. Use the
+default `dynamic` mode only when server-rendered themes, data loaders, redirects,
+or metadata genuinely depend on URL query parameters.
+
+`createGenerateStaticParams()` uses the site's configured client to discover
+published pages and routable entries at build time. The example uses strict
+failure handling so production CI cannot silently publish an incomplete route
+set.
+
+If a site instead uses the SDK's generic environment variable names,
+`generateAllStaticParams()` is available. It reads:
 
 - `RIVERBANK_API_KEY`
 - `RIVERBANK_SITE_ID`
@@ -59,21 +76,6 @@ export function generateStaticParams() {
 }
 ```
 
-If your site already centralizes the SDK client, use the explicit factory:
-
-```tsx
-import { createGenerateStaticParams } from '@riverbankcms/sdk/next'
-
-import config from '@/riverbank.config'
-import { getRiverbankClient } from '@/lib/riverbank-client'
-
-export const generateStaticParams = createGenerateStaticParams({
-  getClient: getRiverbankClient,
-  siteId: config.siteId,
-  failureMode: 'throw',
-})
-```
-
 ## Add the Revalidation Route
 
 Create `src/app/api/revalidate/route.ts`: