¿Algo no funciona?
Cinco cosas explican casi todo lo que se reporta, y ninguna es un bug. Empieza por ahí y reporta lo que quede.
Ve directo al reporte si ya has pasado por ellas.
Cinco cosas que conviene revisar primero.
Cuatro son configuración, no bugs. La quinta es el único fallo real del que el payload te avisa por su cuenta, así que vale la pena saber qué buscar.
- El editor no aparece nunca
- Tiene que estar montado dentro de <body>, y tu check de desarrollo tiene que ser cierto de verdad. En Next.js, process.env.NODE_ENV vale 'development' solo bajo next dev. Prueba también el atajo del botón flotante, porque el botón se puede arrastrar hasta una esquina que no estás mirando.
- Guardar no hace nada, o devuelve 404
- Los handlers devuelven 404 fuera de desarrollo a propósito, y los dos lados tienen que coincidir en la ruta. Si moviste la route, pásale el mismo valor al componente: <VisualEditor endpoint="/__dev/edits" />.
- Cada edit sale con source: null
- Eso significa que el plugin de Vite no se ejecutó. Tiene que ir antes de react() en el array de plugins, y necesita un TypeScript con parser de JS. TypeScript 7 quitó el parseo en memoria, así que en la 7 le pasas tú un compilador 5.x: visualEditorSource({ typescript }).
- No sale la sección Component en un elemento
- El manifest sale de escanear definiciones de cva() bajo components y src/components. Si tu estructura es otra, cambian las roots: createVisualEditsHandlers({ components: { roots: ['app/ui'] } }). ¿No usas cva? Aporta tú el manifest.
- El edit acaba siempre en el elemento equivocado
- Busca selectorAmbiguous: true en la entrada. El selector es una posición en el DOM, así que una lista que se reordena entre sesiones puede entregarle tu edit al vecino. El source stamping lo arregla cuando el stamp nombra un único elemento, y sourceAmbiguous: true avisa de cuándo no. En lo que edites a menudo, un data-testid es el ancla que no se mueve nunca.
¿Sigue roto?
Entonces merece una issue. Los bugs van a GitHub, donde quedan buscables y donde puedes ver si alguien ya se topó con lo mismo.
¿No tienes cuenta de GitHub? Escribe a hi@marcosguerreros.es con los mismos datos que pide el formulario.
Qué hace que un reporte sea accionable.
El formulario ya viene relleno con esto. Los dos datos que más tiempo ahorran son el framework que usas y la entrada de edits.json que salió mal, porque casi todo bug real está o en la identificación del elemento o en lo que el payload dijo de él.
Si el editor no produjo nada en absoluto, lo siguiente mejor es la consola del navegador. Cada guardado queda registrado ahí como [AI-EDIT-REQUEST].
{
"url": "http://localhost:3000/dashboard",
"selector": "body > div:nth-child(2) > button",
"selectorAmbiguous": true,
"tagName": "BUTTON",
"className": "btn btn-primary",
"source": "src/components/Button.tsx:42:7",
"componentStack": ["Button", "ProjectCard"],
"styles": { "padding": { "before": "8px", "after": "12px" } }
}¿Has encontrado un problema de seguridad?
No abras una issue pública. Escribe directamente a hi@marcosguerreros.es. El editor es solo para desarrollo y su endpoint devuelve 404 fuera de desarrollo, así que el radio de impacto es pequeño por diseño, pero si hay manera de saltarse cualquiera de esas dos barreras merece que me lo cuentes en privado primero.
Aquí no hay casilla. Esto no es un error de configuración.