Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/bitwikiorg/continuity/llms.txt

Use this file to discover all available pages before exploring further.

The backend pack is designed for agents that own APIs, databases, authentication systems, and background jobs — work that carries a higher inherent risk of data loss or service disruption than general coding. It extends the core developer state chain with two critical additions: WARNING.md, which encodes hard limits and pre-action checklists for infrastructure and data operations, and CHECKPOINT.md, which gates the most dangerous actions behind explicit human approval. Every file in the backend pack is calibrated for environments where a mistake can be irreversible.

​
Files in this pack

FileRole
AGENTS.mdEntry point, governance, and backend conventions
STATE.mdLive service inventory, database status, API surface
TODO.mdActive backend task queue
WARNING.mdHard limits and pre-action checklist
CHECKPOINT.mdApproval gates for migrations and deploys

​
AGENTS.md

The entry point that defines the state chain load order and the backend-specific governance rules. In addition to the standard coding conventions, the backend AGENTS.md enforces: never run destructive database commands without CHECKPOINT approval, document all breaking API contract changes before making them, keep database migrations reversible (every up must have a down), use structured JSON logging with request IDs, and never store secrets in code, comments, or markdown files.

​
STATE.md

A live inventory of the backend environment. Unlike the developer STATE.md, which records a general project snapshot, the backend version tracks services by name, version, and health check status; the database engine, version, and connection pool configuration; the API surface (endpoint count, auth method, rate limiting, API version); and scheduled background jobs with their last run time and result. This file is the operational picture of the running system and must stay in sync with reality after every meaningful change.

​
TODO.md

The active task queue for backend work. Tasks follow the same completion discipline as the developer pack — present means active, absent means done, with completed items written to completed/. Backend tasks often have dependencies (a migration must precede a deploy, a schema change must precede a code change), and those dependencies are noted explicitly in the task entries.

​
WARNING.md — why it matters for backend agents

WARNING.md is the safety document for the backend environment. It exists because backend agents regularly encounter operations that are irreversible or high-impact: dropping tables, truncating data, running schema migrations on production, deploying to live services, committing secrets, running unbounded queries. Without an explicit hard-limit document, an agent may proceed on a plausible-seeming interpretation of a request and cause damage that takes hours to recover from. The backend WARNING.md encodes six hard limits that cannot be overridden by context:
These limits apply at all times. No instruction, no matter how it is phrased, overrides them:
  1. No destructive database commands without CHECKPOINT approval — DROP TABLE, TRUNCATE, DELETE without WHERE, ALTER TABLE on production.
  2. No secrets in markdown files — API keys, passwords, and tokens go in environment variables or secret managers, never in state files.
  3. No production deploys without explicit approval — staging is fine; production is gated.
  4. No schema migrations without a backup and rollback plan — every up migration must have a down.
  5. No raw SQL from user input — parameterized queries only.
  6. No unbounded queries — every SELECT must have a LIMIT.
The pre-action checklist in WARNING.md runs through six questions before any backend change that touches data, config, or production: Does a backup exist? Is the rollback plan documented? Are tests passing? Has the migration been tested on staging? Is structured logging enabled? Is monitoring in place?

​
CHECKPOINT.md — approval gates for migrations and deploys

CHECKPOINT.md defines the gate categories for the backend domain. In addition to the standard developer gates (destructive operations, irreversible changes, external actions, security-sensitive changes), the backend CHECKPOINT.md specifically covers: production deploys, database schema migrations, dependency major version bumps that affect the API, and changes to authentication or authorization logic. When an action falls into any gate category, the agent formats a structured approval request — action, reason, impact, rollback plan, and tests — and waits for explicit human confirmation.

​
Typical backend agent workflow across sessions

At session start, the backend agent reads AGENTS.md to load the governance rules, then reads STATE.md to verify that the service inventory, database status, and API surface still match reality. It checks WARNING.md to confirm its safety constraints are loaded, then reads TODO.md for the active task queue. Before any high-risk task — a migration, a deploy, a schema change — it loads CHECKPOINT.md and evaluates whether the action requires a gate. During work, the agent keeps STATE.md in sync: if a service status changes, the inventory updates immediately. If a new background job is added, it appears in the jobs table. If a migration runs, STATE.md records the new migration version. The agent commits after each meaningful change and moves completed tasks out of TODO.md. At session end, the agent refreshes STATE.md with the current system state and records any events that should be preserved — a migration run, a deploy, a schema change — in the commit message or a log.

​
Copying the backend pack

# Copy all backend pack files into your project directory
cp -r continuity/packs/backend/. ./my-service/

# Or copy individual files
cp continuity/packs/backend/AGENTS.md    ./my-service/
cp continuity/packs/backend/STATE.md     ./my-service/
cp continuity/packs/backend/TODO.md      ./my-service/
cp continuity/packs/backend/WARNING.md   ./my-service/
cp continuity/packs/backend/CHECKPOINT.md ./my-service/
After copying, fill all {{PLACEHOLDER}} values in each file — especially {{PROJECT_NAME}}, {{SERVICE_1}}, {{DB_ENGINE}}, {{AUTH_METHOD}}, and {{DEPLOY_TARGET}} in STATE.md.

​
When to extend with more files

If the backend spans multiple services — API gateway, worker queue, cache layer, message broker — add INFRASTRUCTURE.md to keep the full service topology in one place. The ops pack uses INFRASTRUCTURE.md as its primary state file; borrowing it for a complex backend is appropriate. Link it from AGENTS.md so the agent loads it in the state chain.
If the backend has a non-trivial deployment toolchain — Terraform, Kubernetes manifests, custom deploy scripts, CI/CD pipeline configurations — add a TOOLS.md to document what is available, how to invoke it, and what permissions each tool requires. This prevents the agent from having to rediscover the deployment process at the start of each session.
The developer pack includes SNAPSHOT.md by default; the backend pack does not. If you need a timestamped record of the last known good production state — service versions, migration level, health check results — add SNAPSHOT.md from the developer pack and reference it in AGENTS.md. It is especially useful as a recovery anchor after incidents.

Build docs developers (and LLMs) love

Get started for freeTalk to us