The LQ.AI Atlas LQ.AI's documentation, bound to the code it describes
234 documents

First hour with LQ.AI

The orientation path: what LQ.AI is and why, how to run it, how decisions are routed, the system shape, and how to tell what's real.

Decision routing

When you face a decision while implementing, the canonical reference is — in priority order:

  1. The PRD (docs/PRD.md) — for product, capability, and architectural decisions.
  2. The OpenAPI sketches (docs/api/backend-openapi.yaml, docs/api/gateway-openapi.yaml) — for endpoint shapes, request/response schemas, status codes.
  3. The database schema (docs/db-schema.md) — for tables, columns, indexes, constraints.
  4. The gateway configuration example (gateway.yaml.example) — for the gateway's configuration shape.
  5. The implementation order (docs/M1-IMPLEMENTATION-ORDER.md) — for which task is next and what its acceptance criteria are.
  6. The skill-authoring guide (docs/skill-authoring-guide.md) — for skill conventions.
  7. CONTRIBUTING.md (CONTRIBUTING.md) — for code style, testing, PR process.

If a decision is not anchored in any of these, stop and ask rather than guess. The right move is usually:

  1. Document the decision in the appropriate place (PRD §9 if it's forward-looking; an ADR in docs/adr/ if it's structural; CLAUDE.md if it's a workflow convention).
  2. Resume implementation.

This is more friction than letting an agent decide independently, and that friction is worth it. The cost of an undocumented decision compounds across every subsequent task that relates to it.