Imported from derlg-com/DerLg (backend/AGENTS.md). Install upstream with npx skills add derlg-com/DerLg --skill backend. Copyright stays with the author.

DerLg Backend — Agent Context Index

This file lives in the backend root to keep agent context local to this directory. When working on backend code, read the files listed here first. Do not rely on global project memory — these specs are the source of truth.

Quick Start

When starting work on the backend, read these files in this order:

1. context/guides/MISSION.md — Why this backend exists and what success looks like
2. context/guides/CONSTITUTION.md — Rules all backend code must follow
3. context/guides/CODE-STANDARD.md — How we write code (formatting, patterns, NestJS conventions)
4. context/guides/TECH-STACK.md — Exact package versions and configs
5. context/guides/SUPABASE-WORKFLOW.md — Prisma + Supabase commands and workflows
6. context/plans/ROADMAP.md — Current phase and what comes next
7. context/specs/SCHEMA.md — Database schema (Prisma)
8. context/specs/API-CONTRACT.md — All endpoints as TypeScript contracts

Then read the relevant domain specs for the task at hand.

Context Files

All spec files are in backend/context/ organized by category.

context/guides/ — How We Work (read first)

context/specs/ — What We Build (domain specs)

context/plans/ — Planning & Operations

Directory Layout

backend/
  AGENTS.md              <-- you are here
  context/               <-- all spec files live here
    guides/              <-- how we work (read first)
      CONSTITUTION.md
      CODE-STANDARD.md
      TECH-STACK.md
    specs/               <-- what we build (domain specs)
      SCHEMA.md
      API-CONTRACT.md
      ERROR-REGISTRY.md
      EVENT-CATALOG.md
    plans/               <-- planning & operations
      ROADMAP.md
      TEST-PLAN.md
      SEED-SPEC.md
  src/                   <-- implementation code
  prisma/                <-- schema.prisma, migrations, seed.ts
  test/                  <-- E2E tests
  docker-compose.yml     <-- local services
  Dockerfile             <-- production build

How to Use This Index

Starting a new feature

1. Read plans/ROADMAP.md — identify the phase and milestone
2. Read guides/CONSTITUTION.md — verify module structure and dependency rules
3. Read specs/SCHEMA.md — understand the data model
4. Read specs/API-CONTRACT.md — implement the endpoint contracts
5. Read plans/TEST-PLAN.md — write tests to the specified level

Fixing a bug

1. Read specs/ERROR-REGISTRY.md — check if the error code exists
2. Read guides/CODE-STANDARD.md — ensure the fix follows patterns
3. Read relevant section of specs/API-CONTRACT.md — verify expected behavior

Adding a new error code

1. Read specs/ERROR-REGISTRY.md — check for duplicates
2. Add to specs/ERROR-REGISTRY.md first
3. Add to src/common/errors/error-codes.ts
4. Update specs/API-CONTRACT.md if endpoint behavior changes

Modifying the database schema

1. Read specs/SCHEMA.md — understand current state
2. Edit specs/SCHEMA.md to reflect the change
3. Edit prisma/schema.prisma to match
4. Run migration: npx prisma migrate dev
5. Update specs/API-CONTRACT.md if response shapes change
6. Update plans/SEED-SPEC.md if new required fields are added

Change Process

When a spec file changes, update all affected files:

External References

These files live outside backend/ but are relevant:

Agent Reminders

• Do not use global memory for backend decisions — check these files first
• Do not guess error codes — use specs/ERROR-REGISTRY.md
• Do not guess schema fields — use specs/SCHEMA.md
• Do not skip tests — follow plans/TEST-PLAN.md coverage gates
• Do not add cross-module imports — follow guides/CONSTITUTION.md dependency rules
• Run lint and format before finishing — per guides/CODE-STANDARD.md