Saltar al contenido principal
Driftless publica exactamente un tipo de comentario de PR, el del Auditor, y solo lo publica cuando tiene un hallazgo. Cuando un pull request toca áreas documentadas, el Auditor revisa el cambio contra el contexto que el equipo dejó registrado. Si el cambio puede contradecir algo que el equipo escribió, publica un comentario: el hallazgo, con los gotchas, las decisiones y los invariantes de los topics afectados viajando junto. El reviewer ve la señal y la memoria que hay detrás, juntas. Un PR limpio no recibe ningún comentario. No hay un comentario de “esto es todo lo que sabemos” en cada PR que toca un archivo anclado. Ese tipo se disparaba con un simple match de archivo, se leía como spam, y entrenaba a los reviewers a ignorar al bot.

​
Cómo funciona

Cuando se abre o se actualiza un PR:
  1. Driftless trae los archivos cambiados y los matchea contra los anchors (globs) de cada topic.
  2. Cada match PR↔topic queda registrado (alimenta la actividad de PR del dashboard), haya comentario o no.
  3. Si el workspace tiene el Auditor configurado (una key de modelo en Settings → Agents), el Auditor entra a la cola: lee el diff real contra lo que los topics matcheados dejaron registrado.
  4. Solo si encuentra algo publica un único comentario sticky, que se actualiza en su lugar en los commits siguientes, nunca se re-publica.

​
Qué entrega el comentario

## 🔎 Driftless Auditor

Este cambio puede afectar 2 cosas que el equipo dejó registradas. En cola para revisión,
son Ediciones sugeridas; un owner/admin las fusiona.

- `billing-flow` (Edición sugerida): la ventana de reembolso cambió de 7d→30d
- `auth-boundaries` (necesita un humano): la nueva ruta se salta el guard del workspace

### Lo que el equipo ya sabe

#### `billing-flow`: cobros de Stripe y manejo de reembolsos
**Gotchas**
- Stripe entrega los webhooks al menos una vez, así que los consumidores deben ser idempotentes
**Invariants**
- Los handlers de webhooks deben leer event.id y cortar en corto si hay duplicado
Los topics stale se marcan dentro del comentario (“confía en el código por encima de la nota, y después actualízala”). Los topics que todavía no tienen nada registrado aportan solo la línea del hallazgo.

​
Solo señal, por diseño

  • Sin hallazgo → sin comentario. El silencio es lo que pasa por defecto, y también es información.
  • Sin key de modelo → sin comentario. El Auditor es BYOM; sin una key el PR igual se observa y se registra, solo que no se comenta.
  • Informa; nunca bloquea. Los hallazgos aterrizan como Ediciones sugeridas en la cola de revisión, y un owner/admin las fusiona. Sin puntaje de cobertura, sin tarea.
  • Encontrar los huecos vive en el mapa de cobertura, no en los comentarios de PR: driftless_context_coverage por el MCP, o el dashboard.
Si tu cambio alteró cómo funciona un área, actualiza el topic para que la nota siga siendo cierta: 
driftless context update auth-boundaries --gotcha "..." --decision "..."
# o abre una Edición sugerida si ya es Knowledge:
driftless context pr auth-boundaries --open --summary "..." --content @new.md
El comentario respeta la gobernanza: los hallazgos son Ediciones sugeridas, nunca se aplican solas, y el contexto que muestra distingue Knowledge de Notas. Mira Gobernanza y Agentes.