777genius 95e0f34d31 docs(product-docs): add zh, es, ja, fr, de doc translations

Localize the VitePress docs into Simplified Chinese, Spanish, Japanese,
French and German (18 pages each), mirroring the existing en/ru structure.

- generate the 5 new locales in config.ts from a single strings table
  (nav, sidebar, search, footer, docFooter, outline, editLink) with
  locale-prefixed links
- rework DocsCardGrid from the binary isRu check to a per-locale map so
  the home cards render translated copy and prefixed links for every locale

2026-05-31 17:50:54 +03:00

6.4 KiB

Raw Blame History

title	description	lang
Revisión de código – Documentación de Agent Teams	Inspecciona los diffs delimitados por tarea, acepta o rechaza hunks, deja comentarios en línea y gestiona los estados de revisión desde none hasta approved.	es-ES

Revisión de código

La revisión de código en Agent Teams está centrada en las tareas. Inspeccionas lo que cambió para una tarea específica en lugar de rastrear a través de un diff grande y sin estructura.

Superficie de revisión

Para cada tarea completada que tocó archivos, la interfaz de revisión te permite:

Inspeccionar los archivos modificados con contexto de antes/después
Aceptar o rechazar hunks individuales
Dejar comentarios en línea
Conectar el diff con la descripción de la tarea y los registros del agente

Decisiones a nivel de hunk

Acepta los cambios pequeños y correctos y rechaza los errores aislados sin descartar toda la tarea. Esto es útil cuando un agente resolvió la mayor parte de la tarea pero se extralimitó en un archivo.

::: tip Acepta de forma incremental Si un diff es mayormente correcto, acepta primero los hunks buenos y solicita cambios únicamente para las partes que necesitan corrección. Esto mantiene el tablero en movimiento. :::

Usa las decisiones a nivel de hunk para:

Situación	Acción
Cambio correcto y delimitado	Acepta el hunk
Idea correcta, archivo equivocado o refactor demasiado amplio	Rechaza el hunk y solicita una corrección más acotada
Cambio de comportamiento poco claro	Comenta y pide verificación
Ruido de formato generado	Rechaza, a menos que el formato formara parte de la tarea

Iniciar la revisión

Abre una tarea completada
Mira la pestaña Changes
Si el diff parece razonable, haz clic en Request Review para mover la tarea a la columna review

Durante la revisión la tarea aún no se considera done, por lo que otros compañeros de equipo o el lead todavía pueden comentar sobre ella.

Ciclo de revisión

Un ciclo de revisión saludable se ve así:

El propietario publica un comentario de resultado con el alcance modificado y la verificación
El revisor abre el diff de la tarea y comprueba los hunks frente a la descripción de la tarea
El revisor acepta los hunks buenos, rechaza los hunks malos o solicita cambios
El propietario corrige únicamente el alcance solicitado y publica un comentario de seguimiento
El revisor aprueba cuando el resultado de la tarea y el diff coinciden

Ejemplo de comentario de solicitud de cambios:

Please keep the copy improvements, but revert the unrelated runtime wording in the provider table. Add the `pnpm --dir landing docs:build` result before resubmitting.

Estados de revisión

Estado	Significado
`none`	La tarea es nueva, está in progress o completada pero aún no está en revisión
`review`	La tarea está activamente bajo revisión
`needsFix`	Se solicitaron cambios; el propietario debe actualizar antes de la nueva aprobación
`approved`	La revisión fue aceptada y la tarea está finalizada

Flujo de trabajo de revisión por agentes

Los equipos pueden revisar el trabajo de los demás antes de que tomes la decisión final. Esto detecta regresiones evidentes y mantiene el tablero honesto, pero aun así deberías revisar tú mismo las áreas de riesgo.

La revisión por agentes es más útil cuando el revisor tiene una rúbrica clara. Por ejemplo, indícale a un revisor que compruebe solo la claridad de la documentación, solo la seguridad de IPC o solo la cobertura de pruebas. Las solicitudes amplias de "revisar todo" tienden a producir comentarios más débiles.

Estado de revisión gestionado por MCP

Los cambios de estado de revisión (solicitar revisión, solicitar cambios, aprobar) están gestionados por herramientas. Dejar un comentario de "solicitar cambios" en una tarea no mueve la columna del kanban a needsFix: un lead o un agente debe llamar a la herramienta MCP apropiada:

review_request_changes — mueve la tarea a needsFix y notifica al propietario
review_approve — mueve la tarea a approved y finaliza la revisión

Los comentarios por sí solos son insuficientes para las transiciones de estado. Para ver la lista completa de herramientas MCP de revisión y sus parámetros, consulta Integración de MCP.

Participantes de la revisión

El lead del equipo es el revisor predeterminado. Puedes configurar revisores adicionales en la configuración del Kanban si quieres que los compañeros revisen el trabajo de los demás.

Qué comprobar manualmente

Prioriza estas áreas al revisar:

Autenticación de proveedores y detección del runtime — ¿el agente cambió la configuración del runtime de una forma que rompería otras rutas?
Límites de IPC, preload y sistema de archivos — mantén separadas las responsabilidades de Electron
Comportamiento de Git y worktree - verifica el nombrado de ramas, los commits y los pushes; consulta Estrategia de Git y worktree para conocer los patrones de aislamiento.
Lógica de parseo y ciclo de vida de las tareas — los cambios en las referencias de tareas, el chunking o el filtrado pueden romper la entrega de mensajes
Flujos de persistencia y revisión de código — los cambios en el almacenamiento de tareas o en el estado de revisión deben mantenerse consistentes entre las capas de IPC

Para conocer el diseño canónico de las funciones y los enlaces a los guardrails estrictos, usa Arquitectura para colaboradores.

Verificación

Prefiere comandos de verificación enfocados. No deberían usarse comandos amplios de formato o lint-fix a menos que la tarea pretenda explícitamente un cambio amplio de formato.

Los buenos comentarios de verificación incluyen el comando y el resultado:

Verified with `pnpm --dir landing docs:build`. Build passed.

Cuando se omite la verificación, el comentario de la tarea debería indicar por qué:

Docs-only wording change. Build not run because the existing dev server was busy; checked Markdown links manually.

::: warning No apliques formato automático en todo el proyecto A menos que la tarea trate específicamente sobre formato, evita ejecutar pnpm lint:fix en archivos no relacionados. Crea ruido en la superficie de revisión. :::

6.4 KiB Raw Blame History Unescape Escape