Backlog Lives in PostgreSQL

Rule

Backlog state (Epic, BacklogItem) lives in PostgreSQL. Always query live state before planning or changing backlog work. Use the DPF MCP backlog tools when available; fall back to direct Postgres queries when the MCP server is offline; never substitute packages/db/src/seed.ts, generated Prisma files, or stale docs for current backlog state.

Why

The backlog is the platform’s authoritative record of what needs doing and what’s been done. Agents that reason about backlog from anywhere other than the live database are wrong as often as the data has changed — which is constantly. Even the seed file’s view is correct only at install time. The MCP tool surface exists to make the live-query path cheap and routine; the principle is to use it instead of cached or inferred state.

Applies To

In-platform coworkers managing backlog (Build Studio, recommendation agents), external coding agents working from the backlog (Claude, Codex picking up items), and humans operating the platform. Symmetric. Applies to epic state, item state, ownership, priority, status, and any related field.

How To Apply

Use the DPF MCP backlog tools first when available: list_backlog_items, get_backlog_item, create_backlog_item, update_backlog_item_status, list_epics, link_backlog_item_to_epic, search_specs_and_plans, record_execution_evidence. The MCP endpoint is /api/mcp/v1 and the connector is configured via the untracked .mcp.json generated from Admin > Platform Development. When the MCP server is unavailable, query Postgres directly AND say “DB fallback in use” so downstream consumers know which path produced the answer.

Decision Dimensions

Examples

Sources

(Rendered from the sources: frontmatter by WikiSourceCitations.)