Lee los Malditos Documentos

¿Qué hace Lee los Malditos Documentos?

No adivines cuando la documentación autorizada pueda responder la pregunta. El movimiento correcto más común es buscar en la web la documentación oficial actual, abrir las páginas relevantes y leerlas antes de programar. Para APIs, versiones, comportamiento de proveedores, configuración, límites, hooks del ciclo de vida o flujos sensibles a la seguridad, fundamenta la respuesta en lo que realmente dicen los documentos.

Disparadores de Lectura de Documentos

Lee los documentos antes de proceder cuando se cumpla alguna de estas condiciones:

• El usuario pregunta por "lo último", "actual", "oficial", "soportado", "mejor práctica", "recomendado", "hoy", "ahora" o "búscalo".
• Los documentos necesarios no están ya en el repositorio ni han sido proporcionados por el usuario. Busca en la web los documentos oficiales en lugar de esperar que la memoria del modelo esté actualizada.
• La tarea añade, actualiza, configura o importa un paquete, SDK, framework, plugin, CLI, modelo, recurso en la nube o integración de proveedor.
• La API es de movimiento rápido o sensible a versiones: AI SDKs, APIs de OpenAI/Anthropic/Google, Next.js, React, Tailwind, Vite, Nitro, Drizzle, Prisma, Stripe, GitHub, Slack, Notion, APIs de navegador, plataformas de despliegue, bibliotecas de autenticación y similares.
• La implementación depende de autenticación, alcances OAuth, permisos, secretos, webhooks, facturación, pagos, PII, cifrado, retención de datos, migraciones, reintentos, límites de tasa, cuotas, caché, despliegues o cumplimiento normativo.
• Un error menciona obsolescencia, opciones desconocidas, exportaciones faltantes, configuración inválida, campos no soportados, valores predeterminados cambiados o desajuste de versiones.
• Un repositorio tiene documentos locales, ADRs, esquemas generados, especificaciones OpenAPI, registros de rutas/acciones, documentos del sistema de diseño o READMEs a nivel de paquete que podrían definir el contrato.
• La elección es costosa de revertir: formatos de cable público, esquema de base de datos, estrategia de migración, IDs persistentes, nombres de eventos, comportamiento visible para el cliente o contratos de automatización externa.
• Te sorprendes a punto de escribir "usualmente", "probablemente", "creo", "de memoria", o código copiado de la memoria del modelo para una API externa.

¿Qué Cuenta Como Documentos?

Usa la fuente más autorizada disponible:

• Documentos locales del repositorio, especificaciones, ADRs, esquemas, tipos generados, READMEs de paquetes y pruebas para comportamiento específico del proyecto.
• Documentos oficiales del producto, referencias de API, guías de migración, registros de cambios, notas de lanzamiento y código fuente/tipos de SDK para comportamiento de terceros. Encuéntralos con búsqueda web si no tienes ya la URL exacta.
• Metadatos del registro de paquetes para versiones. Antes de añadir una dependencia, ejecuta npm view <paquete> version, pnpm view <paquete> version o el equivalente del ecosistema, luego lee los documentos para esa versión principal.
• Código fuente o definiciones de tipos cuando los documentos oficiales están incompletos. Trata esto como evidencia, no como folklor.

Evita Stack Overflow, blogs antiguos, fragmentos aleatorios y la memoria como fuente principal cuando existan documentos oficiales. Usa fuentes comunitarias solo para depurar síntomas después de conocer el contrato autorizado.

Flujo de Trabajo Requerido

1. Identifica la superficie exacta: nombre del paquete, versión instalada, versión objetivo, endpoint del proveedor, comando CLI, archivo de configuración, helper local, esquema o característica del producto.
2. Busca en la web los documentos oficiales actuales a menos que los documentos relevantes ya estén locales o el usuario haya proporcionado una URL. Usa búsquedas dirigidas como <producto> <característica> documentos oficiales, <paquete> guía de migración o <proveedor> referencia de API.
3. Abre y lee los documentos más cercanos a esa superficie. Prefiere primero los documentos locales para código interno, luego los documentos oficiales ascendentes. Para paquetes nuevos, verifica la última versión antes de escribir imports, configuración o comandos de instalación.
4. Extrae los pocos hechos necesarios para la tarea: nombres de opciones, imports, reglas del ciclo de vida, comportamiento predeterminado, cambios importantes, límites, permisos y ejemplos para la versión principal actual.
5. Implementa o responde usando esos hechos. Si los documentos entran en conflicto con el código existente, inspecciona la ruta de código local y señala la discrepancia.
6. Verifica con la verificación útil más pequeña: typecheck, pruebas, compilación, ejecución en seco de CLI, validación de esquema de API o una reproducción local.
7. En la respuesta final, nombra los documentos o archivos locales consultados cuando esa evidencia afecte la recomendación o implementación.

Ejemplos Que Deben Disparar la Lectura de Documentos

• "Añade Tailwind a esta app." Verifica la versión principal actual de Tailwind y sus documentos de instalación desde la web antes de crear archivos de configuración o asumir la configuración anterior de PostCSS.
• "Usa el AI SDK para transmitir respuestas." Verifica la versión principal actual del AI SDK, imports, nombres de paquetes de proveedores, helpers de transmisión y ejemplos de servidor/tiempo de ejecución desde los documentos oficiales.
• "Conecta los webhooks de Stripe." Lee los documentos actuales de Stripe sobre verificación de firmas, reintento de eventos, secreto de endpoint y análisis del cuerpo del framework antes de programar.
• "Arregla este bug de caché de Next.js." Lee los documentos para la versión principal de Next.js instalada y el modo de enrutador antes de asumir la semántica de invalidación de caché.
• "Añade migraciones de Drizzle." Lee los documentos actuales de Drizzle kit y las convenciones de migración existentes del repositorio antes de generar archivos.
• "Crea una Acción de GitHub." Lee los documentos oficiales de sintaxis y permisos de Actions, especialmente para pull_request, workflow_run, OIDC, tokens y artefactos.
• "¿Por qué falla este flujo OAuth?" Lee los documentos del proveedor sobre alcances, URI de redirección, PKCE, renovación de tokens y verificación de aplicaciones antes de cambiar código.
• "Usa el sistema de plan/comentario/acción de este repositorio." Lee los documentos locales, registros de rutas/acciones, esquemas y pruebas antes de inventar endpoints o props.
• "Actualiza Vite/Nitro/React." Lee la guía de migración para la versión principal exacta objetivo antes de editar la configuración o los imports.
• "¿Qué modelo deberíamos usar?" Lee los documentos actuales del modelo del proveedor, las páginas de precios/límites y los ejemplos del SDK antes de recomendar.

Cuando una Lectura Local Rápida es Suficiente

No navegues por la web para cada pequeña edición. Una pasada por los documentos puede ser local y breve cuando la respuesta ya está en el repositorio: uso existente de helpers, pruebas cercanas, interfaces tipificadas, clientes generados, ADRs o READMEs de paquetes. Pero si la tarea depende de una herramienta externa, paquete, proveedor o comportamiento actual del producto, la búsqueda web suele ser el primer paso correcto. Para sintaxis trivial del lenguaje, corrección de errores tipográficos, formato o código autocontenido sin contrato externo, procede normalmente.

Si los Documentos No Están Disponibles

Si el acceso a la red, la autenticación o la falta de archivos locales impiden leer los documentos, dilo claramente antes de confiar en la memoria. Reduce la incertidumbre, inspecciona el código fuente o los tipos si están disponibles, y evita presentar el resultado como confirmado-actual.