--- title: "ChatGPT Dots + GitHub: Del reporte de error al PR revisado" canonical: https://wavect.io/es/blog/chatgpt-dots-github-bug-triage/ language: es description: "Usa ChatGPT Dots con GitHub y Codex para investigar errores: encargo reutilizable, evidencias del PR, pruebas, permisos y parada de tareas sin dejar trabajo activo." image: "https://wavect.io/img/blog/headers/header_chatgpt-dots-github-bug-triage.png" --- [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 11 min de lectura · 1 oct 2026 Última revisión 1 de octubre de 2026 [**Siguiente**](/es/blog/agentic-testing-vs-test-automation-2026/) # ChatGPT Dots + GitHub: Del reporte de error al PR revisado Resumen ChatGPT Dots permite delegar trabajo continuado. Para un piloto de software, asígnale una responsabilidad acotada: investigar reportes asignados y entregar correcciones revisables. Comprueba por separado el acceso a GitHub y el entorno de programación, conserva el reporte original y el commit probado, y exige evidencias de cada comprobación declarada. Conectar Slack no establece una monitorización y completar una tarea no equivale a aceptar una corrección. Separa publicación, merge y despliegue. Mide esfuerzo de revisión y resultados aceptados, no cantidad de PR generados. Llega un reporte de error mientras el equipo trabaja en otra cosa. Lo costoso suele ser todo lo que ocurre antes de revisar una solución útil: localizar el código, reproducir el comportamiento, conservar el contexto y comprobar qué cambió realmente. **Ese es el flujo que merece evaluarse con ChatGPT Dots: entra un reporte y sale un conjunto de evidencias revisable.** No un botón de merge desatendido. Esta guía propone un flujo acotado de clasificación e investigación de errores en GitHub, con un encargo reutilizable, requisitos para las pruebas y un procedimiento de parada. Documentación comprobada el 1 de octubre de 2026. Las capacidades del producto proceden de la documentación de OpenAI. El piloto, los criterios de aceptación y los ejemplos son nuestra propuesta de ingeniería, no resultados de un benchmark ejecutado con Dots. ## ¿Qué son ChatGPT Dots? OpenAI presentó Dots el **29 de septiembre de 2026**: agentes persistentes basados en GPT-6 Astra, con ordenador en la nube y trabajo continuado. Su [anuncio de lanzamiento](https://openai.com/index/introducing-dots/) ilustra flujos que convierten comentarios en correcciones. Los dots especializados con identidad organizativa propia siguen en pilotos empresariales específicos. Para un equipo de desarrollo, la pregunta importante no es si un agente puede generar otro parche. Es si delegar reduce el trabajo necesario para tomar una decisión de revisión fundamentada. Proponemos que un dot coordine la entrada de reportes, la recopilación de fuentes y las correcciones acotadas, sin dejar la aceptación a su propio criterio. Mantén tres responsabilidades diferenciadas: la coordinación decide qué investigar dentro del encargo; el entorno de programación produce el cambio propuesto; el revisor decide si las evidencias justifican aceptarlo. Una persona puede dirigir el piloto, pero esas decisiones no deben convertirse en un único mensaje de «terminado». ## ¿Quién puede utilizar Dots en el lanzamiento? La [guía oficial de acceso](https://learn.chatgpt.com/docs/dots) describe el siguiente despliegue en la fecha de revisión. Tener un plan compatible no implica disponibilidad inmediata en la cuenta. | Plan | Acceso documentado | | --- | --- | | Pro 100 / 200 / 500 | Mayores de 18 años fuera del EEE, Reino Unido y Suiza. | | Business Premium | Despliegue mundial. | | Enterprise | Despliegue mundial; desactivado hasta que lo habilite la administración del espacio de trabajo. | Para un equipo de España, Austria o Alemania, conviene comprobar el plan del espacio de trabajo en lugar de asumir que todas las cuentas europeas tienen el mismo acceso. No comprometas una fecha de implantación basándote en una función que todavía no aparece en tu cuenta. Crea el dot desde el ordenador. La [documentación de configuración](https://learn.chatgpt.com/docs/dots/getting-started) distingue conexiones a aplicaciones, canales de mensajería y acceso al equipo local. Nuestro piloto propuesto empieza con un repositorio y sin conectar el ordenador local. Añade únicamente los accesos cuya necesidad demuestre una prueba concreta. ## Configura GitHub y el entorno de programación por separado La [guía de ordenadores y aplicaciones](https://learn.chatgpt.com/docs/dots/computers-and-apps) describe la investigación de issues de GitHub y la preparación de PR mediante un plugin autorizado. Las tareas de código en la nube pueden utilizar un entorno Codex preconfigurado. El trabajo local requiere un ordenador conectado, en línea y con ChatGPT abierto. **Conectar una cuenta de GitHub no demuestra que estén disponibles el repositorio, la rama, las dependencias y los datos de prueba correctos.** Antes de asignar una responsabilidad recurrente, realiza una pequeña comprobación de acceso. Pide el repositorio seleccionado, un issue conocido, la revisión actual y el comando de pruebas definido en ese repositorio. Exige distinguir lo leído de lo inferido. Después verifica la escritura permitida en una rama desechable o un repositorio de pruebas. ¿Puede la cuenta crear el PR en borrador previsto sin tener también una vía para fusionarlo o desplegarlo? Revisa los permisos del sistema de origen y las credenciales de los flujos, no solo el texto del encargo. Si la integración no permite imponer ese límite, mantenla en modo de lectura y deja que una persona incorpore el parche. Adjunta un breve documento de traspaso a cada tarea de programación: identificador del reporte, comportamiento esperado, revisión afectada, archivos permitidos, pasos de reproducción y pruebas de aceptación. No hagas depender la aceptación de que la tarea recuerde una conversación anterior. Para trabajar en sitios autenticados, consulta nuestra [guía de inicio de sesión en el navegador cloud de ChatGPT](/es/blog/chatgpt-cloud-browser-secure-login/): conectar una aplicación no equivale a iniciar sesión en una web. ## Un encargo reutilizable para investigar errores con Dots Conectar Slack no inicia por sí solo una monitorización. La [guía de tareas y memoria](https://learn.chatgpt.com/docs/dots/tasks-and-memory) exige un evento compatible configurado expresamente o una programación guardada. También advierte que completar una ejecución no demuestra haber conseguido el resultado. Verifica tanto la entrada como la salida. El texto siguiente es una propuesta de encargo conversacional, no una API de Dots ni un archivo de configuración. Sustituye las entradas indicadas antes de utilizarlo. Empieza con un reporte asignado por el responsable; automatiza la entrada solo después de confirmar que tu espacio de trabajo lo admite. ``` Responsabilidad: preparar correcciones revisables, no publicaciones. Responsable: el revisor de ingeniería designado. Alcance: repositorio, fuente de reportes y entorno de pruebas acordados. Entrada: investigar solo los reportes que asigne el responsable. Antes de modificar código: identificar el reporte y la revisión actual; reproducir el problema o explicar exactamente qué impide reproducirlo. Usar el entorno Codex cloud acordado, nunca un ordenador local. Proponer una corrección acotada por reporte. No cambiar los criterios de aceptación, eliminar pruebas fallidas, acceder a datos de producción ni modificar la configuración de CI. Crear un PR en borrador solo después de que el responsable autorice su publicación y si la acción está permitida. En caso contrario, entregar un parche para revisión humana. No fusionar, desplegar, cerrar el issue de origen ni contactar con clientes. Entregar: enlace al reporte, revisiones base y final, reproducción, archivos modificados, comprobaciones exactas y resultados, pruebas no ejecutadas, riesgos pendientes y decisión solicitada al revisor. Una prueba fallida o no disponible no es una prueba superada. Preguntar antes de ampliar el alcance o iniciar otro trabajo de pago. Informar de los bloqueos sin sustituir el entorno acordado por otro. ``` Para un piloto posterior con horario fijo, especifica zona horaria, fecha final y destino de los resultados, y comprueba la programación guardada. Para una entrada por eventos, envía un reporte sintético y verifica que se inicia exactamente una investigación. Envíalo de nuevo y comprueba la política de duplicados. «Vigila este canal» no constituye una evidencia de aceptación suficiente. Conserva el identificador original del reporte durante todo el proceso. Un duplicado debería enlazar a la investigación existente, no iniciar otra corrección competidora. Si un reporte corresponde a una revisión diferente, hay que validarlo de nuevo y no vincularlo silenciosamente a una reproducción antigua. ## Define las evidencias del PR antes de la primera corrección **Nuestra regla de aceptación propuesta: un parche solo está listo para revisión cuando otro ingeniero puede relacionar el resultado declarado con la revisión exacta que se probó.** Un vídeo ayuda a explicar un cambio de interfaz. No demuestra qué commit estaba ejecutándose, si se cumplieron las aserciones ni si se introdujo una regresión cercana. | Evidencia | Pregunta de aceptación | | --- | --- | | Origen y alcance | ¿Qué reporte, recorrido de usuario y comportamiento esperado autorizan el cambio? | | Revisión y entorno | ¿Qué commits base y final, entorno de ejecución y datos no productivos se utilizaron? | | Reproducción anterior al cambio | ¿Qué falló, con qué entradas y cómo se estableció el resultado esperado? | | Pruebas posteriores al cambio | ¿Qué comandos o pasos de navegador se ejecutaron sobre la revisión propuesta y qué devolvieron? | | Casos negativos y adyacentes | ¿Se preservan el acceso denegado, los estados vacíos y los recorridos relacionados que ya funcionaban? | | Lagunas y decisión | ¿Qué falló, no se ejecutó o sigue siendo incierto, y qué debe decidir el revisor? | Imagina un reporte ficticio: «No aparece el botón de exportar en el móvil». Una solución débil lo muestra a todo el mundo. Una investigación útil determina primero el tamaño de pantalla, el rol y el estado de la cuenta afectados. Después comprueba al usuario móvil autorizado, al no autorizado y el comportamiento existente en escritorio. Si la exportación es asíncrona, incluye los estados pendiente y fallido. Pide el fallo de partida y el resultado corregido con las mismas entradas relevantes. Mantén la expectativa independiente del parche. De lo contrario, el agente puede hacer que su propia prueba pase debilitando la aserción, en vez de corregir la aplicación. Utiliza estados explícitos como `not-reproduced`, `blocked`, `patch-unverified` y `ready-for-review`. Son etiquetas propuestas para el equipo, no estados integrados de Dots. Reserva la aceptación para una decisión humana respaldada por las pruebas requeridas. Sin acceso al navegador, el resultado es «pruebas de navegador no ejecutadas», no «verificado mediante inspección del código». Aplica la misma distinción después de cada commit adicional. Las evidencias de una revisión anterior no aprueban automáticamente un parche posterior. Nuestra guía de [testing agéntico frente a automatización determinista de pruebas](/es/blog/agentic-testing-vs-test-automation-2026/) explica la arquitectura general. ## Separa autorización y corrección del software La [guía de administración Enterprise](https://learn.chatgpt.com/docs/enterprise/o-admin-guide) indica que solo el propietario dirige a su dot personal mediante mensajes compatibles de Slack. También aclara que los valores predeterminados de modelos de Enterprise no gobiernan Dots. Revisa el acceso específico de Dots, sin dar por suficiente una política de modelos existente. Esa distinción de propietario afecta al diseño de entrada. El reporte de un compañero es información de trabajo, no autoridad para ampliar permisos. Una petición dentro de un issue para exportar secretos, omitir pruebas o publicar una versión no debe convertirse en una instrucción solo por estar en un repositorio autorizado. La [explicación de seguridad de Dots](https://openai.com/index/how-we-build-safety-security-and-privacy-into-dots/) describe defensas frente a instrucciones maliciosas e investigación proactiva de solo lectura. Esa investigación no equivale al trabajo asignado y autorizado. Nuestra distinción de ingeniería es igualmente importante: tener permiso para una acción no demuestra que su resultado sea correcto. En este piloto, permite leer los reportes acordados y preparar cambios aislados; exige revisión antes de publicar un PR; excluye merge, despliegue, cambios de credenciales y comunicaciones con clientes. Aplica las restricciones disponibles en la aplicación, el repositorio y el entorno de ejecución. No proporciones una sesión de navegador más privilegiada para eludir un plugin restringido. Antes de ampliar el acceso, prueba tres fallos deliberados: un repositorio fuera de alcance, un reporte con instrucciones hostiles y una dependencia ausente. Los resultados deseados son una solicitud denegada, instrucciones ignoradas y un bloqueo comunicado con precisión. No son tres oportunidades para buscar una vía con más privilegios. ## Cómo detener Dots sin dejar tareas en ejecución La [guía de controles](https://learn.chatgpt.com/docs/dots/controls) distingue tres operaciones: Pause afecta a la tarea principal; el trabajo delegado se detiene en Activity; las tareas recurrentes se desactivan o eliminan en Scheduled. Las reglas personalizadas son instrucciones falibles, no permisos de acceso. Detener no revierte las acciones completadas. Incluye la parada en la aceptación del piloto. Inicia una tarea delegada inofensiva y una comprobación recurrente futura. Pausa la coordinación, inspecciona ambas por separado, detén la tarea y elimina la programación. Registra qué se detuvo realmente. Comprueba por separado los permisos de aplicaciones y las sesiones web autenticadas antes de considerar cerrado el piloto. La [guía de Dots del Help Center](https://help.openai.com/en/articles/20001530-getting-started-with-your-dot) también distingue desconectar una aplicación de borrar información ya obtenida. Revisa la confirmación actual de restablecimiento o eliminación y conserva las evidencias aprobadas antes de eliminar el dot. Revocar permisos, tratar el contexto retenido y gestionar los artefactos publicados requieren decisiones distintas. En el flujo GitHub propuesto, revisa los PR en borrador abiertos, las ramas, el trabajo en cola y la entrada programada. Quitar el acceso no decide qué hacer con los parches que ya se produjeron. ## Mide correcciones aceptadas, no actividad del agente Ejecuta un piloto pequeño y expresamente acotado sobre incidencias no críticas. Incluye todos los reportes asignados en el denominador: duplicados, intentos bloqueados y reportes que no eran errores. De lo contrario, el panel premia los casos fáciles mientras oculta el coste de coordinación. Proponemos registrar correcciones aceptadas, minutos de revisión por reporte asignado, falsos positivos, resultados no verificados y regresiones detectadas después de aceptar. Compara trabajo similar con el proceso habitual del equipo. Incluye el tiempo dedicado a corregir el encargo, reparar el entorno y rechazar conclusiones plausibles pero sin respaldo. Para el coste, cuenta configuración, revisión humana y toda la ejecución de tareas, incluidos los intentos descartados. Las [notas de versión de ChatGPT](https://help.openai.com/en/articles/6825453-chatgpt-release-notes) describen condiciones temporales de lanzamiento, no un compromiso de trabajo ilimitado permanente. Confirma el cupo actual en el producto y el consumo aplicable de Work o Codex antes de fijar un presupuesto recurrente. Un resultado útil no significa necesariamente más PR. Puede ser identificar antes los reportes imposibles de reproducir, reducir traspasos de contexto o aportar mejores evidencias para el mismo número de correcciones. Fija los criterios para continuar o parar antes de revisar resultados, no después de ver una demostración atractiva. ## Cuándo utilizar Dots y cuándo desarrollar un flujo Proponemos Dots para coordinar prioridades cambiantes de un responsable concreto: investigar este reporte, mantener actualizada una cola acotada y entregar evidencias para revisión. Elige otra vía cuando los criterios exijan identidad de servicio compartida, disparadores deterministas, reintentos explícitos o un compromiso de servicio productivo que el piloto con Dots no haya demostrado. No se trata de desarrollar todo desde cero. Se trata de distinguir la utilidad de un asistente del contrato de un sistema de producción. Nuestro [análisis de ingeniería de OpenAI Agents API](/es/blog/openai-agents-api-managed-harness-review/) aborda la vía de producto a medida sin presentar Dots como una API pública para aplicaciones. Como siguiente paso concreto, trae una cola recurrente de errores y un repositorio representativo a una [sesión de definición del flujo y la QA](/es/contact/). Empieza por los criterios de evidencia y los límites de permisos. Automatiza los traspasos cuando ambos estén claros. ## Preguntas frecuentes sobre ChatGPT Dots y GitHub ### ¿En qué se diferencian Dots y Codex en este flujo? Dots coordina la responsabilidad; un entorno Codex cloud preparado puede ejecutar la tarea de programación. La propuesta separa reporte original, evidencias de ejecución y aceptación humana. Consulta la [configuración del entorno](#github-setup). ### ¿Puede ChatGPT Dots investigar issues de GitHub? OpenAI documenta la investigación de issues y la preparación de PR mediante un plugin GitHub autorizado. Comprueba cuenta, acceso al repositorio y acciones disponibles antes de asignar trabajo. Una integración funcional no demuestra que la corrección sea válida. ### ¿Conectar Slack inicia automáticamente la vigilancia de errores? No. Configura y verifica expresamente un evento compatible o una programación guardada. En el piloto propuesto, prueba un reporte sintético y un duplicado antes de depender de la entrada automática. Consulta el [encargo reutilizable](#triage-brief). ### ¿Puede Dots trabajar con el portátil apagado? El trabajo cloud no necesita que el portátil permanezca encendido. El trabajo local requiere un equipo conectado, en línea y con ChatGPT abierto. Confirma el entorno: no presupongas que toda tarea delegada se ejecuta en la nube. ### ¿Una tarea completada significa que la corrección pasó las pruebas? No. Exige commit probado, reproducción, comandos o pasos reales de navegador, resultados y pruebas no ejecutadas. El [contrato de evidencias del PR](#evidence-contract) propuesto reserva la aceptación al revisor. ### ¿Pausar un dot detiene todo su trabajo? No. Pause, tareas delegadas en Activity y tareas recurrentes en Scheduled requieren atención por separado. Sigue el [procedimiento de parada](#stop-work) y después revisa accesos y artefactos ya creados. ## Reflexiones finales La promesa útil de Dots es reducir la coordinación entre un reporte y una corrección revisable. Empieza con una cola acotada, vincula cada resultado a una revisión probada y mantén la aceptación independiente del agente. Amplía el alcance cuando las evidencias demuestren que el flujo ayuda al equipo. QA y preparación para producción ## Continúa por este clúster Pruebas, auditorías, mantenimiento y hardening para software fiable. [Empieza por el artículo fundamental**QA para Código Generado por IA**](/es/blog/qa-for-ai-generated-code/) - [Testing agéntico vs. automatización: guía piloto 2026](/es/blog/agentic-testing-vs-test-automation-2026/) - [Benchmark de QA externa: qué encontramos en los primeros 30 días](/es/blog/external-qa-benchmark-first-30-days/) - [Cuánto Cuesta Mantener Software Después del Launch: Benchmark SaaS DACH](/es/blog/software-maintenance-cost-benchmark-dach-saas/) - [Desingeniería ágil](/es/blog/agile-de-engineering/) - [Due diligence de apps Lovable, Bolt y Replit](/es/blog/lovable-bolt-replit-app-due-diligence/) [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 11 min de lectura · 1 oct 2026 Última revisión 1 de octubre de 2026 [**Siguiente**](/es/blog/agentic-testing-vs-test-automation-2026/) ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/es/blog/chatgpt-dots-github-bug-triage/#webpage", "@type": "WebPage", "dateModified": "2026-10-01", "inLanguage": "es", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-10-01", "url": "https://wavect.io/es/blog/chatgpt-dots-github-bug-triage/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "ChatGPT Dots permite delegar trabajo continuado. Para un piloto de software, asígnale una responsabilidad acotada: investigar reportes asignados y entregar correcciones revisables. Comprueba por separado el acceso a GitHub y el entorno de programación, conserva el reporte original y el commit probado, y exige evidencias de cada comprobación declarada. Conectar Slack no establece una monitorización y completar una tarea no equivale a aceptar una corrección. Separa publicación, merge y despliegue. Mide esfuerzo de revisión y resultados aceptados, no cantidad de PR generados.", "articleBody": " Resumen del blog/Entrega y QA/QA y preparación para producción ChatGPT Dots + GitHub: Del reporte de error al PR revisado Resumen ChatGPT Dots permite delegar trabajo continuado. Para un piloto de software, asígnale una responsabilidad acotada: investigar reportes asignados y entregar correcciones revisables. Comprueba por separado el acceso a GitHub y el entorno de programación, conserva el reporte original y el commit probado, y exige evidencias de cada comprobación declarada. Conectar Slack no establece una monitorización y completar una tarea no equivale a aceptar una corrección. Separa publicación, merge y despliegue. Mide esfuerzo de revisión y resultados aceptados, no cantidad de PR generados. Llega un reporte de error mientras el equipo trabaja en otra cosa. Lo costoso suele ser todo lo que ocurre antes de revisar una solución útil: localizar el código, reproducir el comportamiento, conservar el contexto y comprobar qué cambió realmente. Ese es el flujo que merece evaluarse con ChatGPT Dots: entra un reporte y sale un conjunto de evidencias revisable. No un botón de merge desatendido. Esta guía propone un flujo acotado de clasificación e investigación de errores en GitHub, con un encargo reutilizable, requisitos para las pruebas y un procedimiento de parada. Documentación comprobada el 1 de octubre de 2026. Las capacidades del producto proceden de la documentación de OpenAI. El piloto, los criterios de aceptación y los ejemplos son nuestra propuesta de ingeniería, no resultados de un benchmark ejecutado con Dots. ¿Qué son ChatGPT Dots? OpenAI presentó Dots el 29 de septiembre de 2026: agentes persistentes basados en GPT-6 Astra, con ordenador en la nube y trabajo continuado. Su anuncio de lanzamiento ilustra flujos que convierten comentarios en correcciones. Los dots especializados con identidad organizativa propia siguen en pilotos empresariales específicos. Para un equipo de desarrollo, la pregunta importante no es si un agente puede generar otro parche. Es si delegar reduce el trabajo necesario para tomar una decisión de revisión fundamentada. Proponemos que un dot coordine la entrada de reportes, la recopilación de fuentes y las correcciones acotadas, sin dejar la aceptación a su propio criterio. Mantén tres responsabilidades diferenciadas: la coordinación decide qué investigar dentro del encargo; el entorno de programación produce el cambio propuesto; el revisor decide si las evidencias justifican aceptarlo. Una persona puede dirigir el piloto, pero esas decisiones no deben convertirse en un único mensaje de «terminado». ¿Quién puede utilizar Dots en el lanzamiento? La guía oficial de acceso describe el siguiente despliegue en la fecha de revisión. Tener un plan compatible no implica disponibilidad inmediata en la cuenta. Despliegue de ChatGPT Dots, comprobado el 1 de octubre de 2026 PlanAcceso documentado Pro 100 / 200 / 500Mayores de 18 años fuera del EEE, Reino Unido y Suiza. Business PremiumDespliegue mundial. EnterpriseDespliegue mundial; desactivado hasta que lo habilite la administración del espacio de trabajo. Para un equipo de España, Austria o Alemania, conviene comprobar el plan del espacio de trabajo en lugar de asumir que todas las cuentas europeas tienen el mismo acceso. No comprometas una fecha de implantación basándote en una función que todavía no aparece en tu cuenta. Crea el dot desde el ordenador. La documentación de configuración distingue conexiones a aplicaciones, canales de mensajería y acceso al equipo local. Nuestro piloto propuesto empieza con un repositorio y sin conectar el ordenador local. Añade únicamente los accesos cuya necesidad demuestre una prueba concreta. Configura GitHub y el entorno de programación por separado La guía de ordenadores y aplicaciones describe la investigación de issues de GitHub y la preparación de PR mediante un plugin autorizado. Las tareas de código en la nube pueden utilizar un entorno Codex preconfigurado. El trabajo local requiere un ordenador conectado, en línea y con ChatGPT abierto. Conectar una cuenta de GitHub no demuestra que estén disponibles el repositorio, la rama, las dependencias y los datos de prueba correctos. Antes de asignar una responsabilidad recurrente, realiza una pequeña comprobación de acceso. Pide el repositorio seleccionado, un issue conocido, la revisión actual y el comando de pruebas definido en ese repositorio. Exige distinguir lo leído de lo inferido. Después verifica la escritura permitida en una rama desechable o un repositorio de pruebas. ¿Puede la cuenta crear el PR en borrador previsto sin tener también una vía para fusionarlo o desplegarlo? Revisa los permisos del sistema de origen y las credenciales de los flujos, no solo el texto del encargo. Si la integración no permite imponer ese límite, mantenla en modo de lectura y deja que una persona incorpore el parche. Adjunta un breve documento de traspaso a cada tarea de programación: identificador del reporte, comportamiento esperado, revisión afectada,", "articleSection": "Ingeniería", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "anuncio de lanzamiento", "url": "https://openai.com/index/introducing-dots/" }, { "@type": "WebPage", "name": "guía oficial de acceso", "url": "https://learn.chatgpt.com/docs/dots" }, { "@type": "WebPage", "name": "documentación de configuración", "url": "https://learn.chatgpt.com/docs/dots/getting-started" }, { "@type": "WebPage", "name": "guía de ordenadores y aplicaciones", "url": "https://learn.chatgpt.com/docs/dots/computers-and-apps" }, { "@type": "WebPage", "name": "guía de tareas y memoria", "url": "https://learn.chatgpt.com/docs/dots/tasks-and-memory" }, { "@type": "WebPage", "name": "guía de administración Enterprise", "url": "https://learn.chatgpt.com/docs/enterprise/o-admin-guide" }, { "@type": "WebPage", "name": "explicación de seguridad de Dots", "url": "https://openai.com/index/how-we-build-safety-security-and-privacy-into-dots/" }, { "@type": "WebPage", "name": "guía de controles", "url": "https://learn.chatgpt.com/docs/dots/controls" }, { "@type": "WebPage", "name": "guía de Dots del Help Center", "url": "https://help.openai.com/en/articles/20001530-getting-started-with-your-dot" }, { "@type": "WebPage", "name": "notas de versión de ChatGPT", "url": "https://help.openai.com/en/articles/6825453-chatgpt-release-notes" } ], "dateModified": "2026-10-01", "datePublished": "2026-10-01", "description": "ChatGPT Dots permite delegar trabajo continuado. Para un piloto de software, asígnale una responsabilidad acotada: investigar reportes asignados y entregar correcciones revisables. Comprueba por separado el acceso a GitHub y el entorno de programación, conserva el reporte original y el commit probado, y exige evidencias de cada comprobación declarada. Conectar Slack no establece una monitorización y completar una tarea no equivale a aceptar una corrección. Separa publicación, merge y despliegue. Mide esfuerzo de revisión y resultados aceptados, no cantidad de PR generados.", "headline": "ChatGPT Dots + GitHub: Del reporte de error al PR revisado", "image": "https://wavect.io/img/blog/headers/header_chatgpt-dots-github-bug-triage.svg", "inLanguage": "es", "keywords": "ChatGPT Dots, GitHub, Agentes de IA", "mainEntityOfPage": { "@id": "https://wavect.io/es/blog/chatgpt-dots-github-bug-triage/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/es/blog/chatgpt-dots-github-bug-triage/", "wordCount": 2885 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/es/", "name": "Inicio", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/overview/", "name": "Resumen del blog", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/topics/delivery-qa/", "name": "Entrega y QA", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/clusters/qa-production/", "name": "QA y preparación para producción", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/chatgpt-dots-github-bug-triage/", "name": "ChatGPT Dots + GitHub: Del reporte de error al PR revisado", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Dots coordina la responsabilidad; un entorno Codex cloud preparado puede ejecutar la tarea de programación. La propuesta separa reporte original, evidencias de ejecución y aceptación humana. Consulta la configuración del entorno." }, "name": "¿En qué se diferencian Dots y Codex en este flujo?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "OpenAI documenta la investigación de issues y la preparación de PR mediante un plugin GitHub autorizado. Comprueba cuenta, acceso al repositorio y acciones disponibles antes de asignar trabajo. Una integración funcional no demuestra que la corrección sea válida." }, "name": "¿Puede ChatGPT Dots investigar issues de GitHub?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No. Configura y verifica expresamente un evento compatible o una programación guardada. En el piloto propuesto, prueba un reporte sintético y un duplicado antes de depender de la entrada automática. Consulta el encargo reutilizable." }, "name": "¿Conectar Slack inicia automáticamente la vigilancia de errores?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "El trabajo cloud no necesita que el portátil permanezca encendido. El trabajo local requiere un equipo conectado, en línea y con ChatGPT abierto. Confirma el entorno: no presupongas que toda tarea delegada se ejecuta en la nube." }, "name": "¿Puede Dots trabajar con el portátil apagado?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No. Exige commit probado, reproducción, comandos o pasos reales de navegador, resultados y pruebas no ejecutadas. El contrato de evidencias del PR propuesto reserva la aceptación al revisor." }, "name": "¿Una tarea completada significa que la corrección pasó las pruebas?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No. Pause, tareas delegadas en Activity y tareas recurrentes en Scheduled requieren atención por separado. Sigue el procedimiento de parada y después revisa accesos y artefactos ya creados." }, "name": "¿Pausar un dot detiene todo su trabajo?" } ] } ```