workflow 5.0.0-beta.8 → 5.0.0

package/docs/api-reference/workflow-api/world/observability.mdx

@@ -1,164 +0,0 @@
----
-title: Observability Utilities
-description: Hydrate step I/O, parse display names, and decrypt workflow data using workflow/observability.
-type: reference
-summary: "Functions: hydrateResourceIO(), parseStepName(), parseWorkflowName(), parseClassName(), getEncryptionKeyForRun(), hydrateResourceIOWithKey()."
-prerequisites:
-  - /docs/api-reference/workflow-api/get-world
-related:
-  - /docs/api-reference/workflow-api/world/storage
-keywords:
-  - workflow/observability
-  - hydrateResourceIO
-  - observabilityRevivers
-  - parseStepName
-  - parseWorkflowName
-  - parseClassName
-  - getEncryptionKeyForRun
-  - hydrateResourceIOWithKey
-  - data hydration
-  - devalue deserialization
-  - encryption decryption
-  - display name parsing
----
-
-The `workflow/observability` module provides utilities for working with workflow data in observability and debugging tools. It includes functions to hydrate serialized step I/O, parse machine-readable names into display-friendly formats, and decrypt encrypted workflow data.
-
-## Import
-
-```typescript lineNumbers
-import { // [!code highlight]
-  hydrateResourceIO, // [!code highlight]
-  observabilityRevivers, // [!code highlight]
-  parseStepName, // [!code highlight]
-  parseWorkflowName, // [!code highlight]
-  parseClassName, // [!code highlight]
-} from "workflow/observability"; // [!code highlight]
-```
-
-## Data Hydration
-
-### hydrateResourceIO()
-
-Deserialize step or run data that was serialized using the [devalue](https://github.com/Rich-Harris/devalue) format. Required to display step input/output in your UI.
-
-```typescript lineNumbers
-import { hydrateResourceIO, observabilityRevivers } from "workflow/observability"; // [!code highlight]
-
-const step = await world.steps.get(runId, stepId);
-const hydrated = hydrateResourceIO(step, observabilityRevivers); // [!code highlight]
-console.log(hydrated.input, hydrated.output);
-```
-
-**Parameters:**
-
-| Parameter | Type | Description |
-|-----------|------|-------------|
-| `resource` | `Step \| WorkflowRun` | The step or run with serialized data |
-| `revivers` | `Revivers` | Reviver functions for deserialization. Use `observabilityRevivers` for standard use. |
-
-**Returns:** The resource with hydrated `input` and `output` fields.
-
-### observabilityRevivers
-
-A set of reviver functions that handle standard workflow serialization types (Date, Map, Set, Error, etc.).
-
-## Name Parsing
-
-Workflow and step names are stored as machine-readable identifiers. These utilities extract display-friendly names. All return `{ shortName: string, moduleSpecifier: string } | null`.
-
-### parseStepName()
-
-```typescript lineNumbers
-import { parseStepName } from "workflow/observability"; // [!code highlight]
-
-const parsed = parseStepName("step//./src/workflows/order//processPayment"); // [!code highlight]
-// parsed?.shortName → "processPayment"
-// parsed?.moduleSpecifier → "./src/workflows/order"
-```
-
-### parseWorkflowName()
-
-```typescript lineNumbers
-import { parseWorkflowName } from "workflow/observability"; // [!code highlight]
-
-const parsed = parseWorkflowName("workflow//./src/workflows/order//processOrder"); // [!code highlight]
-// parsed?.shortName → "processOrder"
-```
-
-### parseClassName()
-
-```typescript lineNumbers
-import { parseClassName } from "workflow/observability"; // [!code highlight]
-
-const parsed = parseClassName("class//./src/models//User"); // [!code highlight]
-// parsed?.shortName → "User"
-```
-
-## Encryption
-
-For workflows with encrypted step data, decrypt before hydrating.
-
-### getEncryptionKeyForRun()
-
-Retrieve the encryption key used for a specific workflow run.
-
-{/* @expect-error:2305 */}
-```typescript lineNumbers
-import { getEncryptionKeyForRun } from "workflow/observability"; // [!code highlight]
-
-const key = await getEncryptionKeyForRun(runId); // [!code highlight]
-```
-
-**Parameters:**
-
-| Parameter | Type | Description |
-|-----------|------|-------------|
-| `runId` | `string` | The workflow run ID |
-
-**Returns:** Encryption key for the run
-
-### hydrateResourceIOWithKey()
-
-Hydrate step or run data using a decryption key. Use this instead of `hydrateResourceIO()` when data is encrypted.
-
-{/* @expect-error:2305,2724 */}
-```typescript lineNumbers
-import { getEncryptionKeyForRun, hydrateResourceIOWithKey } from "workflow/observability"; // [!code highlight]
-
-const key = await getEncryptionKeyForRun(runId); // [!code highlight]
-const hydrated = hydrateResourceIOWithKey(step, key); // [!code highlight]
-```
-
-**Parameters:**
-
-| Parameter | Type | Description |
-|-----------|------|-------------|
-| `resource` | `Step \| WorkflowRun` | The step or run with encrypted serialized data |
-| `key` | `EncryptionKey` | The encryption key from `getEncryptionKeyForRun()` |
-
-**Returns:** The resource with decrypted and hydrated `input` and `output` fields.
-
-## Examples
-
-### Parse Display Names for a Run's Steps
-
-```typescript lineNumbers
-import { getWorld } from "workflow/runtime";
-import { parseStepName, parseWorkflowName } from "workflow/observability"; // [!code highlight]
-
-const world = await getWorld();
-const run = await world.runs.get(runId, { resolveData: "none" });
-console.log("Workflow:", parseWorkflowName(run.workflowName)?.shortName); // [!code highlight]
-
-const steps = await world.steps.list({ runId, resolveData: "none" });
-for (const step of steps.data) {
-  const parsed = parseStepName(step.stepName); // [!code highlight]
-  console.log(`  ${parsed?.shortName}: ${step.status}`); // [!code highlight]
-}
-```
-
-## Related
-
-- [Storage](/docs/api-reference/workflow-api/world/storage) — Query runs, steps, hooks, and events
-- [Serialization](/docs/foundations/serialization) — How workflow data is serialized

package/docs/api-reference/workflow-api/world/queue.mdx

@@ -1,86 +0,0 @@
----
-title: Queue
-description: Low-level queue interface for dispatching workflow and step invocations.
-type: reference
-summary: "Methods: getDeploymentId(), queue(), createQueueHandler(). Internal queue dispatch — normally handled by the SDK."
-prerequisites:
-  - /docs/api-reference/workflow-api/get-world
-related:
-  - /docs/api-reference/workflow-api/start
-  - /docs/foundations/starting-workflows
-keywords:
-  - world.queue
-  - getDeploymentId
-  - queue
-  - createQueueHandler
-  - ValidQueueName
-  - queue dispatch
----
-
-Queue methods live directly on the `world` object (not nested). They dispatch internal workflow and step invocations to the queue backend.
-
-<Callout type="warn">
-  These methods are used internally by the Workflow SDK to dispatch execution. You do not need to call them in normal operations — use [`start()`](/docs/api-reference/workflow-api/start) to trigger workflows instead. Direct queue access is only needed if you programmatically create a run via `world.events.create()` with a `run_created` event and need to kick off its initial execution, or for debugging resumption of a flow or step route.
-</Callout>
-
-## Import
-
-```typescript lineNumbers
-import { getWorld } from "workflow/runtime";
-
-const world = await getWorld(); // [!code highlight]
-// Queue methods are called directly on world — e.g. world.queue()
-```
-
-## Methods
-
-### getDeploymentId()
-
-Get the current deployment ID. Used internally for routing queue messages to the correct deployment.
-
-```typescript lineNumbers
-const deploymentId = await world.getDeploymentId(); // [!code highlight]
-```
-
-**Returns:** `string` — The current deployment ID
-
-### queue()
-
-Dispatch a message to a named queue. The message payload is an internal SDK type (`WorkflowInvokePayload`, `StepInvokePayload`, or `HealthCheckPayload`).
-
-```typescript lineNumbers
-const { messageId } = await world.queue(queueName, payload, opts); // [!code highlight]
-```
-
-**Parameters:**
-
-| Parameter | Type | Description |
-|-----------|------|-------------|
-| `queueName` | `ValidQueueName` | The queue name (branded string) |
-| `message` | `QueuePayload` | Internal SDK payload |
-| `opts` | `QueueOptions` | Optional — `deploymentId`, `idempotencyKey`, `delaySeconds`, `headers` |
-
-**Returns:** `{ messageId: MessageId | null }`
-
-### createQueueHandler()
-
-Create an HTTP handler that processes messages from a queue. Used to set up the queue consumer endpoint.
-
-```typescript lineNumbers
-const handler = world.createQueueHandler(prefix, callback); // [!code highlight]
-```
-
-**Parameters:**
-
-| Parameter | Type | Description |
-|-----------|------|-------------|
-| `prefix` | `QueuePrefix` | Queue name prefix to match |
-| `callback` | `(message, meta) => Promise<void \| { timeoutSeconds: number }>` | Handler called for each message. `meta` contains `attempt`, `queueName`, `messageId`, `requestId`. |
-
-**Returns:** `(req: Request) => Promise<Response>`
-
-## Related
-
-- [start()](/docs/api-reference/workflow-api/start) — The standard way to start workflow runs
-- [Starting Workflows](/docs/foundations/starting-workflows) — Core concepts for workflow invocation
-- [Storage](/docs/api-reference/workflow-api/world/storage) — Create events that trigger queue dispatch

package/docs/deploying/building-a-world.mdx

@@ -1,251 +0,0 @@
----
-title: Building a World
-description: Implement the World interface to run workflows on any custom infrastructure.
-type: guide
-summary: Build a custom World adapter to run workflows on your own infrastructure.
-prerequisites:
-  - /docs/deploying
-  - /docs/foundations/workflows-and-steps
-related:
-  - /docs/deploying/world/local-world
-  - /docs/deploying/world/postgres-world
-  - /docs/deploying/world/vercel-world
----
-
-A **World** is the abstraction that allows workflows to run on any infrastructure. It handles workflow storage, step execution queuing, and data streaming. This guide explains the World interface and how to implement your own.
-
-<Callout>
-  Before building a custom World, check the [Worlds Ecosystem](/worlds) page — there may already be a community implementation for your infrastructure.
-</Callout>
-
-<Callout type="info">
-  **Reference Implementation:** The [Postgres World source code](https://github.com/vercel/workflow/tree/main/packages/world-postgres) is a production-ready example of how to implement the World interface with a database backend and graphile-worker for queuing.
-</Callout>
-
-## What is a World?
-
-A World connects workflows to the infrastructure that powers them. The World interface abstracts three core responsibilities:
-
-1. **Storage** — Persisting workflow runs, steps, hooks, and the event log
-2. **Queue** — Enqueuing and processing workflow and step invocations
-3. **Streamer** — Managing real-time data streams between workflows and clients
-
-{/* @skip-typecheck - interface definition, not runnable code */}
-```typescript
-interface World extends Storage, Queue, Streamer {
-  start?(): Promise<void>;
-  close?(): Promise<void>;
-  getEncryptionKeyForRun?(run: WorkflowRun): Promise<Uint8Array | undefined>;
-  getEncryptionKeyForRun?(runId: string, context?: Record<string, unknown>): Promise<Uint8Array | undefined>;
-}
-```
-
-The optional `start()` method initializes background tasks (for example, queue polling). The optional `close()` method releases resources like connection pools and listeners. The optional `getEncryptionKeyForRun()` method returns the AES-256 key used to encrypt data for a run; if it is not implemented, encryption is disabled.
-
-## The Event Log Model
-
-Workflow storage is built on an **append-only event log**. All state changes happen through events — you never modify runs, steps, or hooks directly. Instead, you create events that update the materialized state.
-
-Events fall into three categories: run lifecycle events, step lifecycle events, and hook lifecycle events. See the [Event Sourcing](/docs/how-it-works/event-sourcing) documentation for a complete list of event types and their semantics.
-
-## Storage Interface
-
-The Storage interface provides read access to materialized entities and write access through events:
-
-{/* @skip-typecheck - interface definition, not runnable code */}
-```typescript
-interface Storage {
-  runs: {
-    get(id: string, params?: GetWorkflowRunParams): Promise<WorkflowRun>;
-    list(params?: ListWorkflowRunsParams): Promise<PaginatedResponse<WorkflowRun>>;
-  };
-
-  steps: {
-    get(runId: string | undefined, stepId: string, params?: GetStepParams): Promise<Step>;
-    list(params: ListWorkflowRunStepsParams): Promise<PaginatedResponse<Step>>;
-  };
-
-  events: {
-    // Create a new workflow run (runId may be client-provided or null for server generation)
-    create(runId: string | null, data: RunCreatedEventRequest, params?: CreateEventParams): Promise<EventResult>;
-    
-    // Create an event for an existing run
-    create(runId: string, data: CreateEventRequest, params?: CreateEventParams): Promise<EventResult>;
-    
-    list(params: ListEventsParams): Promise<PaginatedResponse<Event>>;
-    listByCorrelationId(params: ListEventsByCorrelationIdParams): Promise<PaginatedResponse<Event>>;
-  };
-
-  hooks: {
-    get(hookId: string, params?: GetHookParams): Promise<Hook>;
-    getByToken(token: string, params?: GetHookParams): Promise<Hook>;
-    list(params: ListHooksParams): Promise<PaginatedResponse<Hook>>;
-  };
-}
-```
-
-### Key Implementation Details
-
-**Event Creation:** When `events.create()` is called, your implementation must:
-1. Persist the event to the event log
-2. Atomically update the affected entity (run, step, or hook)
-3. Return both the created event and the updated entity
-
-**Run Creation:** For `run_created` events, the `runId` parameter may be a client-provided string or `null`. When `null`, your World generates and returns a new `runId`.
-
-**Hook Tokens:** Hook tokens must be unique. If a `hook_created` event conflicts with an existing token, return a `hook_conflict` event instead and include the active hook owner's run ID as `eventData.conflictingRunId`.
-
-**Automatic Hook Disposal:** When a workflow reaches a terminal state (`completed`, `failed`, or `cancelled`), automatically dispose of all associated hooks to release tokens for reuse.
-
-## Queue Interface
-
-The Queue interface handles asynchronous execution of workflows and steps:
-
-{/* @skip-typecheck - interface definition, not runnable code */}
-```typescript
-interface Queue {
-  getDeploymentId(): Promise<string>;
-
-  queue(
-    queueName: ValidQueueName,
-    message: QueuePayload,
-    opts?: QueueOptions
-  ): Promise<{ messageId: MessageId }>;
-
-  createQueueHandler(
-    queueNamePrefix: QueuePrefix,
-    handler: (message: unknown, meta: { attempt: number; queueName: ValidQueueName; messageId: MessageId }) => Promise<void | { timeoutSeconds: number }>
-  ): (req: Request) => Promise<Response>;
-}
-```
-
-### Queue Names
-
-Queue names follow a specific pattern:
-- `__wkf_workflow_<name>` — For workflow invocations
-- `__wkf_step_<name>` — For step invocations
-
-### Message Payloads
-
-Two types of messages flow through queues:
-
-**Workflow Invocations:**
-{/* @skip-typecheck - interface definition, not runnable code */}
-```typescript
-interface WorkflowInvokePayload {
-  runId: string;
-  traceCarrier?: Record<string, string>;  // OpenTelemetry context
-  requestedAt?: Date;
-}
-```
-
-**Step Invocations:**
-{/* @skip-typecheck - interface definition, not runnable code */}
-```typescript
-interface StepInvokePayload {
-  workflowName: string;
-  workflowRunId: string;
-  workflowStartedAt: number;
-  stepId: string;
-  traceCarrier?: Record<string, string>;
-  requestedAt?: Date;
-}
-```
-
-### Implementation Considerations
-
-- Messages must be delivered at-least-once
-- Support configurable retry policies
-- Track attempt counts for observability
-- Implement idempotency using the `idempotencyKey` option when provided
-
-## Streamer Interface
-
-The Streamer interface enables real-time data streaming:
-
-{/* @skip-typecheck - interface definition, not runnable code */}
-```typescript
-interface Streamer {
-  streamFlushIntervalMs?: number;
-
-  streams: {
-    write(
-      runId: string,
-      name: string,
-      chunk: string | Uint8Array
-    ): Promise<void>;
-
-    writeMulti?(
-      runId: string,
-      name: string,
-      chunks: (string | Uint8Array)[]
-    ): Promise<void>;
-
-    close(runId: string, name: string): Promise<void>;
-
-    get(
-      runId: string,
-      name: string,
-      startIndex?: number
-    ): Promise<ReadableStream<Uint8Array>>;
-
-    list(runId: string): Promise<string[]>;
-
-    /** Paginated snapshot of stream chunks. */
-    getChunks(
-      runId: string,
-      name: string,
-      options?: { limit?: number; cursor?: string }
-    ): Promise<{
-      data: { index: number; data: Uint8Array }[];
-      cursor: string | null;
-      hasMore: boolean;
-      done: boolean;
-    }>;
-
-    /** Lightweight metadata: tail index and completion flag. */
-    getInfo(
-      runId: string,
-      name: string
-    ): Promise<{ tailIndex: number; done: boolean }>;
-  };
-}
-```
-
-Streams are identified by a combination of `runId` and `name`. Each workflow run can have multiple named streams.
-`writeMulti()` is an optional optimization for batching multiple writes.
-
-`getChunks` returns a paginated snapshot of currently available chunks (unlike `get` which returns a live `ReadableStream` that waits for new chunks). `getInfo` returns the tail index (last chunk index, 0-based, or `-1` when empty) and whether the stream is complete — useful for resolving negative `startIndex` values into absolute positions.
-
-## Reference Implementations
-
-Study these implementations for guidance:
-
-- **[Local World](https://github.com/vercel/workflow/tree/main/packages/world-local)** — Filesystem-based, great for understanding the basics
-- **[Postgres World](https://github.com/vercel/workflow/tree/main/packages/world-postgres)** — Database-backed with graphile-worker for queuing
-
-## Testing Your World
-
-Workflow SDK includes an E2E test suite that validates World implementations. Once your World is published to npm:
-
-1. Add your world to [`worlds-manifest.json`](https://github.com/vercel/workflow/blob/main/worlds-manifest.json)
-2. Open a PR to the Workflow repository
-3. CI will automatically run the E2E test suite against your implementation
-
-Your world will then appear on the [Worlds Ecosystem](/worlds) page with its compatibility status and performance benchmarks.
-
-## Publishing Your World
-
-1. **Package your World** — Export a default World instance from your package
-2. **Publish to npm** — Publish your package to npm
-3. **Add to the manifest** — Submit a PR adding your world to [`worlds-manifest.json`](https://github.com/vercel/workflow/blob/main/worlds-manifest.json)
-4. **Document configuration** — Clearly document any required environment variables
-
-```json
-// worlds-manifest.json entry
-{
-  "package": "your-world-package",
-  "repository": "https://github.com/you/your-world",
-  "docs": "https://github.com/you/your-world#readme"
-}
-```

package/docs/deploying/index.mdx

@@ -1,95 +0,0 @@
----
-title: Deploying
-icon: Rocket
-description: Deploy workflows locally, on Vercel, or anywhere using pluggable World adapters.
-type: overview
-summary: Learn how to deploy workflows to different environments using World adapters.
-related:
-  - /docs/deploying/world/local-world
-  - /docs/deploying/world/postgres-world
-  - /docs/deploying/world/vercel-world
-  - /docs/deploying/building-a-world
----
-
-Workflows are designed to be highly portable. The same workflow code can run locally during development, on Vercel with zero configuration, or on any infrastructure using **Worlds** — pluggable adapters that handle storage, queuing, and communication.
-
-## Local Development
-
-During local development, workflows automatically use the **Local World** — no configuration required. The Local World stores workflow data in a `.workflow-data/` directory and processes steps synchronously, making it perfect for development and testing.
-
-```bash
-# Just run your dev server - workflows work out of the box
-npm run dev
-```
-
-You can inspect local workflow data using the CLI:
-
-```bash
-npx workflow inspect runs
-```
-
-<Callout>
-  Learn more about the [Local World](/worlds/local) configuration and internals.
-</Callout>
-
-## Deploying to Vercel
-
-The easiest way to deploy workflows to production is on Vercel. When you deploy to Vercel, workflows automatically use the **Vercel World** — again, with zero configuration.
-
-The Vercel World provides:
-
-- **Durable storage** - Workflow state persists across function invocations
-- **Managed queuing** - Steps are processed reliably with automatic retries
-- **Automatic scaling** - Workflows scale with your application
-- **Built-in observability** - View workflow runs in the Vercel dashboard
-
-Simply deploy your application:
-
-```bash
-vercel deploy
-```
-
-<FluidComputeCallout />
-
-<Callout>
-  Learn more about the [Vercel World](/worlds/vercel) and its capabilities.
-</Callout>
-
-## Self-Hosting & Other Providers
-
-For self-hosting or deploying to other cloud providers, you can use community-maintained Worlds or build your own.
-
-<Cards>
-  <Card title="Explore Worlds" href="/worlds">
-    Browse official and community World implementations with compatibility status and performance benchmarks.
-  </Card>
-  <Card title="Build Your Own" href="/docs/deploying/building-a-world">
-    Learn how to implement a custom World for your infrastructure.
-  </Card>
-</Cards>
-
-### Using a Third-Party World
-
-To use a different World implementation, set the `WORKFLOW_TARGET_WORLD` environment variable:
-
-```bash
-export WORKFLOW_TARGET_WORLD=@workflow/world-postgres
-# Plus any world-specific configuration
-export DATABASE_URL=postgres://...
-```
-
-Each World may have its own configuration requirements — refer to the specific World's documentation for details.
-
-## Observability
-
-The [Observability tools](/docs/observability) work with any World backend. By default they connect to your local environment, but can be configured to inspect remote deployments:
-
-```bash
-# Inspect local workflows
-npx workflow inspect runs
-
-# Inspect remote workflows
-npx workflow inspect runs --backend @workflow/world-postgres
-```
-
-Learn more about [Observability](/docs/observability) tools.

package/docs/deploying/meta.json

@@ -1,4 +0,0 @@
-{
-  "title": "Deploying",
-  "pages": ["...deploying", "building-a-world"]
-}

package/docs/deploying/world/local-world.mdx

@@ -1,84 +0,0 @@
----
-title: Local World
-description: Zero-config world bundled with Workflow for local development. No external services required.
-type: integration
-summary: Set up the Local World for zero-config workflow development on your machine.
-prerequisites:
-  - /docs/deploying
-related:
-  - /docs/deploying/world/postgres-world
-  - /docs/deploying/world/vercel-world
----
-
-The Local World is bundled with `workflow` and used automatically during local development. No installation or configuration required.
-
-To explicitly use the local world in any environment, set the environment variable:
-
-```bash
-WORKFLOW_TARGET_WORLD=local
-```
-
-## Observability
-
-The `workflow` CLI uses the local world by default. Running these commands inside your workflow project will show your local development workflows:
-
-```bash
-# List recent workflow runs
-npx workflow inspect runs
-
-# Launch the web UI
-npx workflow web
-```
-
-Learn more in the [Observability](/docs/observability) documentation.
-
-## Testing & Compatibility
-
-<WorldTestingPerformance />
-
-## Configuration
-
-The local world works with zero configuration, but you can customize behavior through environment variables or programmatically via `createLocalWorld()`.
-
-### `WORKFLOW_LOCAL_DATA_DIR`
-
-Directory for storing workflow data as JSON files. Default: `.workflow-data/`
-
-### `PORT`
-
-The application dev server port. Used to enqueue steps and workflows. Default: auto-detected
-
-### `WORKFLOW_LOCAL_BASE_URL`
-
-Full base URL override for HTTPS or custom hostnames. Default: `http://localhost:{port}`
-
-Port resolution priority: `baseUrl` > `port` > `PORT` > auto-detected
-
-### `WORKFLOW_LOCAL_QUEUE_CONCURRENCY`
-
-Maximum number of concurrent queue workers. Default: `100`
-
-### Programmatic configuration
-
-{/* @skip-typecheck: incomplete code sample */}
-```typescript title="workflow.config.ts" lineNumbers
-import { createLocalWorld } from "@workflow/world-local";
-
-const world = createLocalWorld({
-  dataDir: "./custom-workflow-data",
-  port: 5173,
-  // baseUrl overrides port if set
-  baseUrl: "https://local.example.com:3000",
-});
-```
-
-## Limitations
-
-The local world is designed for development, not production:
-
-- **In-memory queue** - Steps are queued in memory and do not persist across server restarts
-- **Filesystem storage** - Data is stored in local JSON files
-- **Single instance** - Cannot handle distributed deployments
-- **No authentication** - Suitable only for local development
-
-For production deployments, use the [Vercel World](/worlds/vercel) or [Postgres World](/worlds/postgres).

package/docs/deploying/world/meta.json

@@ -1,4 +0,0 @@
-{
-  "title": "World",
-  "pages": ["local-world", "vercel-world", "postgres-world"]
-}