GitHub ya permite leer y cambiar por REST y GraphQL parte de la configuración de Copilot code review desde la empresa hasta el repositorio. La API también identifica explícitamente revisiones y comentarios de Copilot, informa del nivel de esfuerzo cuando está disponible y enumera skills, servidores MCP e instrucciones personalizadas que Copilot declara como fuentes.
La actualización está disponible para Copilot Pro, Pro+, Max, Business y Enterprise. No convierte un comentario en correcto por estar atribuido: añade trazabilidad sobre quién lo produjo y con qué contexto declarado.
Tres niveles con herencia
| Nivel | Qué administra | Límite |
|---|---|---|
| Empresa | Activa, desactiva o delega a organizaciones | La organización no puede contradecir la empresa |
| Organización | Activación, esfuerzo predeterminado y runner | Hereda decisiones superiores |
| Repositorio | Esfuerzo, instrucciones y herramientas MCP | No amplía políticas de empresa u organización |
Las respuestas de ajustes enumeran los niveles de esfuerzo disponibles. Esto evita fijar un valor que el plan o la política no admite, pero sigue siendo necesario leer el retorno después de cada cambio.
La credencial cambia según el endpoint
Los endpoints de empresa y organización —incluido el runner de organización— no admiten GitHub Apps ni personal access tokens de grano fino. Los endpoints de repositorio sí los admiten: requieren Administration: read para leer y Administration: write para modificar. Un PAT clásico necesita acceso de administrador del repositorio.
La consecuencia práctica es que no puedes diseñar una única credencial de menor alcance y asumir que gobernará todos los niveles. Separa automatizaciones, documenta el propietario de cada token y conserva una lectura de retorno con el nivel que realmente cambió.
El resumen de revisión también cambia
- Los archivos omitidos y excluidos comparten una sección con motivo enlazado.
- Se ocultan secciones vacías y las listas largas muestran un recuento restante.
- Una valoración negativa permite indicar si el problema fue exactitud, verbosidad, severidad o utilidad.
- Las sesiones muestran créditos de IA consumidos.
- Las revisiones equilibradas usan tres modelos revisores y otro que combina resultados.
GitHub también reintenta una vez las revisiones fallidas o agotadas y puede cambiar a otro modelo elegible. Por tanto, el modelo preferido no es necesariamente el que termina una revisión tras un fallo; la atribución y el metadato de esfuerzo ayudan a investigar esa diferencia.
Qué comprobar en una automatización
- Lee la política superior antes de proponer un ajuste inferior.
- Usa una credencial admitida por ese nivel y el mínimo permiso necesario.
- Actualiza un único ajuste y vuelve a leerlo.
- Guarda atribución, esfuerzo y fuentes declaradas junto al comentario.
- No trates una skill o un servidor MCP listado como prueba de que su contenido era correcto.
La vista Overview publicada ayer organiza los bloqueos para personas. Esta novedad cubre otra capa: configuración y trazabilidad por API.
Transparencia: noticia elaborada con asistencia de IA a partir del changelog y la documentación de GitHub. Texploto no llamó a los endpoints ni ejecutó una revisión.
