Saltar al contenido principal
Solo GitHub.com. GitHub Enterprise Server, GitLab y Bitbucket no son compatibles, y tampoco SSO ni un registro de auditoría.
Revisa cualquier archivo de código fuente de texto que no esté en la lista de omitidos. Está probado y medido en Elixir, Ruby y Rails, TypeScript y React, Python y Go: se plantan defectos conocidos en código de esos lenguajes y comprobamos cuántos encuentra CodeWarden. Los demás lenguajes los revisa el mismo modelo, sin esa medición detrás.Los comentarios pueden escribirse en el idioma que definas con language.
No. Lee el diff, los archivos modificados y algunos archivos relacionados a través de la API de GitHub. No se clona nada, y nada de tu repositorio se ejecuta jamás: ni build, ni pruebas, ni linters.
No. Un grafo de dependencias necesita el repositorio completo, lo que implica un clon. En cambio, CodeWarden encuentra los archivos que usan el código que cambió un pull request con la búsqueda de código de GitHub, dentro de tu repositorio, y le muestra al modelo hasta tres de ellos, leídos desde la base branch. Las reglas que ningún grafo podría encontrar pertenecen a .codewarden.yml.
No. Cada revisión se publica como una revisión de comentarios. Nunca aprueba y nunca pide cambios, así que no puede bloquear una fusión.
Normalmente porque el push no agregó nada nuevo que revisar, o porque la revisión de seguimiento no encontró nada: una revisión posterior sin nada que decir no publica nada. Otros motivos: el pull request es un borrador (se omite por defecto y no aparece en la consola), el repositorio está desactivado, .codewarden.yml lo omite, el cupo se agotó, o no hay un plan vigente. Los dos últimos se avisan en un comentario, una vez por pull request. El check CodeWarden de cada commit muestra qué pasó con ese commit, y la página del repositorio en la consola muestra cada revisión con su estado.
La primera vez que CodeWarden revisa un pull request, publica un comentario corto diciendo que empezó. No repite ese comentario en pushes posteriores. En cada commit, el check CodeWarden muestra “Reviewing…” mientras corre la revisión, y después su resultado.
Es a propósito. Una revisión publica solo hallazgos con una confianza de al menos 0,7, como máximo 8 comentarios por defecto, y nunca observaciones de estilo. La consola lista cada hallazgo que descartó y por qué.
No. Qué modelo revisa un pull request es responsabilidad de CodeWarden, y un modelo que no hemos medido daría una revisión de la que no podemos responder.
No. Un push que no toca nada nuevo no llama a ningún modelo y no usa ningún turno de IA.
Las revisiones se pausan hasta el siguiente periodo de facturación, y no se publica nada en tus pull requests. Un propietario puede cambiar de plan, o agregar 100 turnos de IA para el resto del periodo: $20 en Starter, $15 en Pro, $12 en Business. Consulta Turnos de IA extra.
Por defecto no. Un borrador se revisa cuando se marca como listo para revisión. Para revisar también los borradores, define skip.drafts: false en .codewarden.yml en la base branch.
No. Las reglas de revisión viven en .codewarden.yml en tu repositorio, leído desde la base branch. La consola decide qué repositorios están activos, quién puede verlos y qué se paga.
No. Solo las personas con acceso de escritura al repositorio, y el autor del pull request, pueden obtener respuesta a una mención. Cualquier otra persona se ignora sin costo.
No. .codewarden.yml se lee desde la base branch, así que editarlo en un pull request no afecta la revisión de ese pull request. El texto en el pull request que le dice al revisor que apruebe o que se calle se trata como datos, no como instrucciones.
La política de privacidad responde esto en su sección “Quién más lo ve”: cada solicitud a OpenRouter le pide usar solo proveedores con una política de retención cero de datos que no almacenen ni entrenen con lo que reciben.