Live State Over Seed Data

Rule

For anything that changes after install — current epics, backlog items, users, capabilities, agent state, build status — query the database. Treat packages/db/src/seed.ts as bootstrap defaults only; never edit it to represent runtime change, and never read it instead of querying live state.

Why

Seed data captures the platform’s initial state at install time; it does not track what happened after install. An agent that quotes seed values when asked “what’s the current backlog?” gives a wrong answer the moment any item is added, moved, or completed — which is approximately immediately. The discipline keeps every agent grounded in the actual operational state, not a synthetic snapshot. The cost is one extra DB query per question, which is negligible compared to the cost of acting on stale data.

Applies To

In-platform coworkers, external coding agents, and humans operating the platform. Symmetric. Applies to backlog state, user lists, agent state, configuration values, build status, and any data that mutates after install. Does NOT apply to compile-time constants (enum values, schema shape) — those legitimately live in code or seed.

How To Apply

When the agent needs current state, query the DPF MCP tool surface (list_backlog_items, list_epics, get_backlog_item, etc.) or the Postgres database directly. Say which source was used. Do not read from packages/db/src/seed.ts to answer a runtime question. When the MCP server is unavailable, say so and fall back to Postgres explicitly — see the related contextual principle “DB fallback must be explicit” for the exact disclosure pattern.

Decision Dimensions

Examples

Sources

(Rendered from the sources: frontmatter by WikiSourceCitations.)