Driftless empieza con topics: memoria de ingeniería que perdura, anclada a los archivos y flujos de trabajo donde importa.
# Primer topic = algo REAL que ya sabes, anclado al módulo que gobierna:driftless context add api-auth --title "Auth" \ --what "Cada request de la API está acotado al workspace por un guard global." \ --pattern "src/auth/**"
¿Todavía no tienes nada concreto que registrar? Sáltalo. Primero trabaja y persiste lo que aprendes. Un topic genérico de relleno no documenta nada y se pudre el primer día.Enriquece con contexto estructurado:
driftless context update api-auth \ --gotcha "WorkspaceGuard es global; usa @Public() solo para rutas públicas explícitas" \ --decision "Llaves RS256 para que los servicios verifiquen sin un secreto compartido" \ --invariant "Todas las rutas requieren auth salvo que estén marcadas explícitamente con @Public()" \ --check "Verifica que el decorador de rol coincida con la metadata que espera el guard"
Conecta topics con relaciones tipadas:
driftless context update api-auth --rel relates_to:api-architecturedriftless context get api-auth --json
Ancla a rutas de archivos para el seguimiento de drift:
La CLI valida cada pattern contra tu checkout local en el momento de escribir. Un pattern que coincide con cero archivos se bloquea; uno que coincide con más de 100 archivos recibe una advertencia de anclaje demasiado amplio.
Define DRIFTLESS_API_KEY para entornos no interactivos. Define DRIFTLESS_API_URL solo cuando apuntes a staging o a una API local.
