Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/davidbuenov/dbv-specs-ops/llms.txt

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

No code is written during /plan. Its entire purpose is to validate the specification through structured debate, classify how the work should be executed, and produce an approved, unambiguous task breakdown. Skipping this phase is the most reliable way to build the wrong thing correctly.

​
Step 1 — Work Mode Classification

The assistant implicitly determines the optimal execution mode based on the scope of the task. This is not a user-facing prompt; it is an internal routing decision.
ModeTriggerBehaviour
Conductor Mode (fast edit)Touches ≤ 2 files and fewer than 50 linesProceeds with rapid, interactive iterations in the IDE
Orchestrator Mode (async delegation)New feature, migration, or changes affecting > 2 filesPlans in detail; suggests autonomous execution commands (e.g. /goal) if the environment supports them
Orchestrator Mode is not just about file count — any task touching authentication, payments, or sensitive data triggers it regardless of size.

​
Step 2 — Adversarial Architect Review (MANDATORY)

Before decomposing tasks, the assistant must print an internal XML debate. This forces explicit analysis of edge cases and security failures before any implementation decision is locked in. The block is not optional and is not skipped for small tasks. The <adversary> block must cite at least one concrete noun present in docs/SPECIFICATIONS.md — generic references like “the user” or “the input” without project-specific context do not satisfy the requirement. 
<architect_review>
  <builder>
    Propongo este plan para cumplir la especificación: implementar el endpoint
    POST /sessions con validación de JWT y registro en la tabla `user_sessions`.
  </builder>
  <adversary>
    Riesgo específico al dominio: ¿Qué ocurre si el campo `refresh_token` llega
    expirado o con firma inválida durante el flujo de renovación de sesión?
    ¿Hay inconsistencia de estado si el cliente reintenta la solicitud antes de
    que la BD confirme la escritura anterior?
  </adversary>
  <builder>
    Resolución: Ajustaremos el plan añadiendo una verificación de firma
    antes del upsert en `user_sessions` y envolviendo la operación en una
    transacción atómica con rollback explícito en caso de colisión.
  </builder>
</architect_review>
If the Adversarial Review surfaces a risk that the team consciously decides to accept, it must be recorded in memory.md under ## 🏗️ Log de Decisiones Técnicas before the plan continues. Accepted risks that are not logged become invisible technical debt.

​
Step 3 — Phase Gate: Task Decomposition

If the specification survives the debate, the assistant breaks the work into steps in task.md. Each step must be narrow enough to be completed in a single, reviewable increment — a maximum of 50 lines per step is the guideline.

​
When is a plan “complex”?

A plan is classified as complex and requires an implementation_plan.md file if it meets any of the following criteria:
  • Affects more than 3 files
  • Touches authentication, payments, or other sensitive data
  • Estimates more than 150 new lines of code

​
implementation_plan.md requirements

When an implementation_plan.md is required, it must begin with a YAML frontmatter block containing exactly these three keys: 
---
dependencies:
  - "JWT library (e.g. jose)"
  - "PostgreSQL adapter (e.g. pg)"
risks:
  - "Token replay if session table write fails silently"
rollback_strategy: "Revert migration file and restore previous JWT middleware"
---
The assistant requests explicit approval from the developer before executing any plan classified as complex. Silence is not consent.

​
Key outputs

ArtifactWhen created
Internal <architect_review> block (printed to chat)Every task, without exception
Updated task.md with step breakdownEvery task
implementation_plan.md with YAML frontmatterComplex tasks only
New memory.md entry under Log de Decisiones TécnicasWhen a risk is consciously accepted

Build docs developers (and LLMs) love

Get started for freeTalk to us