Paso 6 — Code review: el dev primero, después un partner

En qué consiste en detalle

Dos revisiones distintas:

El dev revisa su propia implementación — la que produjo la IA, minucioso y con criterio (correctitud, casos borde, seguridad, calidad). Es responsable del código, no la IA (anti vibe-coding). Solo con eso en orden, y todo commiteado, crea la PR.
Un partner revisa la PR y firma aprobación/rechazo. Se apoya en la skill dai-review para un primer pase consciente de la metodología: corre dai check (¿la US quedó atrasada?), valida el DoD, revisa el código (severidad low/medium/high) y deja un review inline — un resumen + un comentario anclado a cada archivo:línea. La skill valida cada posición contra el diff (descarta lo que el modelo inventó), te muestra el preview y espera tu OK antes de postear (ADR-0016).

Skill dai-review — GitHub y GitLab. Postea el review inline por el MCP del forge o por dai forge review <ref> --from <review.json> (token); dai forge comment queda como fallback simple sin anclar.
dai check (ADR-0003).
Gate de cierre: definition-of-done.md.

El partner aprueba o rechaza (Art. 5). La IA comenta y sugiere; nunca firma la aprobación.

Rubber-stamp ("LGTM" sin leer) → el review deja de valer.
Que la IA "apruebe" → prohibido; aprueba una persona.
Hallazgos abstractos ("mejorar la calidad") → sin archivo:línea, no es accionable.
Aprobar con dai check en ⚠️ atrasado → se implementó una versión vieja del QUÉ.