zehuichan/vibe-harness

Revisión de un cambio

Este skill es una guía, no una lista de verificación completa. Verifica y obtén la base en vivo exacta del cambio y su cabeza exacta, luego lista las rutas modificadas con el comando commands.change-scope del perfil antes de leer el diff y suficiente código circundante para entender el diseño. Restablece la base después de un retarget o un merge. Prioriza corrección, ciclo de vida, seguridad y comportamiento requerido roto sobre el estilo; una revisión corta con un bloqueador fundamentado es mejor que una lista de minucias.

Lee los requisitos antes de juzgar el diff. Mapea las rutas modificadas a las fuentes a continuación, abre cada página propietaria y solo entonces lee el diff contra esos requisitos. Juzgar un diff basándose en la memoria de las reglas es cómo una violación pasa la revisión.

Fuentes de verdad

• AGENTS.md en la raíz y en cada subárbol tocado: órdenes permanentes.
• .agents/project-profile.md: comandos, superficies habilitadas, evidencia por superficie y reglas específicas del proyecto.
• docs/defensive-patterns/: reglas aplicadas en la revisión, una página por familia de artefactos; lee cada página que el diff toque.
• docs/AGENTS.md y docs-standard: colocación y disciplina de la documentación.
• prose-standard: cobertura requerida y juicio editorial para comentarios, documentación, prompts y cadenas visibles.
• error-handling: clasificación de fallos, propiedad, contención, garantías e informes.
• lifecycle-review: estado singleton, efectos no revertidos y orden de limpieza en plugins, servicios y componentes.
• test-reliability: aislamiento y prueba de regresión para pruebas que poseen recursos, son asíncronas o inestables.
• .agents/notes/: justificación del diseño. Trata el desacuerdo con una Nota de Agente como una discusión de diseño, no un veto automático.
• Cuando el perfil habilita surfaces.ui, los skills ui-ux-review y responsive-ui.

Requisitos bloqueantes

1. La prosa nueva recibe revisión semántica. Usa prose-standard en cada pasaje de Markdown añadido o modificado, doc de API, comentario, prompt, descripción, diagnóstico y cadena visible. Las verificaciones automatizadas no establecen precisión, colocación ni cobertura.
2. La documentación coincide con el código. La configuración, valores por defecto, errores, campos wire, eventos y comportamiento público actualizan el README propietario y los docs de API en el mismo diff. Señala narración de implementación, tutoriales de prueba, historial de revisión y justificación duplicada.
3. Propiedad y limpieza. Para código de plugin, servicio o componente con un ciclo de vida, aplica lifecycle-review al comportamiento modificado y a los consumidores afectados. Cada nuevo registro prueba su eliminación.
4. Existe evidencia requerida. Verifica que el autor ejecutó las verificaciones relevantes para el diff (ver pre-push-checks) y que CI cubre el resto; revisa las brechas semánticas que ninguno puede detectar.
5. Texto de UI localizado. Cuando el perfil habilita surfaces.localized-ui, rechaza el texto de producto incrustado en marcado, plantillas, valores de retorno de helpers, atributos de accesibilidad o valores por defecto de componentes; requiere el mecanismo de locale y evidencia en cada locale afectado. Los datos de usuario, modelo y wire permanecen textuales.
6. Los cambios disruptivos se registran. Cuando el perfil habilita surfaces.public-api, una rotura perceptible externamente lleva una guía de actualización en el mismo diff (ver upgrade-guide).

Comprobaciones manuales

• Intención y contratos de interfaz: traza ambos lados de cada interfaz modificada. Confirma que la implementación coincide con la descripción y cualquier Nota de Agente, incluyendo errores, cancelación, propiedad y eliminación.
• Manejo de errores: rechaza catch-and-continue a menos que el propietario del estado establezca que se cumplen las precondiciones del trabajo posterior.
• Ciclo de vida y concurrencia: para configuraciones asíncronas, callbacks, procesos o desmontaje, verifica condiciones de carrera antes de la publicación, cancelación durante awaits, reporte independiente de errores, contención de callbacks, propiedad antes de reentrada, limpieza completa de desenganche y eliminación en estado quiescente.
• Capacidad y ajuste al consumidor: traza cada consumidor actual, luego señala el comportamiento específico del consumidor que se filtra en una interfaz compartida. Señala también lo inverso: un nuevo método público en un servicio genérico cuyo único llamante es un consumidor interno; prefiere una capacidad privada entregada a ese consumidor en la construcción.
• Alcance, propiedad y necesidad: mapea cada abstracción, máquina de estados, opción, copia defensiva y ruta de compatibilidad a su contrato actual, consumidor de producción y módulo propietario. Desafía características no relacionadas y generalidad especulativa.
• Configuración y opciones públicas: pregunta qué evidencia de consumidor actual o arte previo respalda cada valor por defecto, conjunto de operaciones públicas, formato o concepto externo importado. Requiere una elección explícita o aplazamiento cuando esa evidencia está ausente.
• Perspectiva del modelo: cuando el proyecto envía prompts, esquemas de herramientas o resultados a un modelo, inspecciona el texto exacto que recibe el modelo. Señala conceptos fuera de la tarea del modelo y verifica el texto estable textual y el comportamiento dinámico mediante pruebas o snapshots.
• Imposición: sigue cada ruta de denegación hasta la operación que la ejecuta; ejercita llamantes directos y alternativos que pueden eludir esquemas, prompts, fachadas, wrappers o el orden de los listeners.
• Estado prestado y derivado: determina si cada valor retenido es prestado o propio, luego traza notificaciones y cada caché, prompt, eco de UI, reproducción y vista de consulta hasta el punto de éxito documentado y la fuente autorizada.
• Los límites cubren la operación final: localiza el propietario del resultado completo emitido o retenido, incluyendo wrappers y metadatos. Sonda límites pequeños y exactos, fragmentos individuales sobredimensionados y texto multibyte en busca de límites de bytes.
• Ruta de entrada real: las pruebas ejercitan el cargador, binario, worker o subproceso enviado cuando sea relevante. Una configuración de prueba ensamblada a mano no detecta exportaciones inválidas.
• Robustez de la prueba: las afirmaciones fallan en la regresión prevista y verifican estado externo, logs, eventos o eliminación en lugar de reafirmar la implementación. La cobertura es necesaria pero no es evidencia de que el escenario sea correcto.
• Controles negativos: verifica que un caso deliberadamente inválido falle a través del runner real para cada regla de aceptación modificada.
• Las Notas de Agente implementadas coinciden con la realidad enviada: cuando un cambio implementa una nota propuesta, muévela y reescríbela como estado enviado en tiempo presente en el mismo diff.
• Traducciones: compara significado y terminología en ambos lados; la estructura coincidente no prueba la calidad de la traducción.

Reporte de hallazgos

Indica el defecto, ubicación, impacto y evidencia. Coloca un defecto localizado en línea sobre el rango de diff relevante más ajustado; usa un comentario de nivel superior para arquitectura transversal, alcance o síntesis. Separa los bloqueadores de las sugerencias y omite problemas ya aplicados por una verificación que pasa. Al recibir revisión, verifica cada afirmación y corrígela o refútala con base técnica.