No vuelvas a explicar el mismo fallo.

Clic derecho en lo que está roto. El informe se escribe solo: componente, captura, registros. Nadie te pregunta dónde era.

Right-click the Subscribe button, write the note, save. The pin appears on the page and the note lands on the team board, anchored to SubscribeButton in PricingCard.

Cinco cosas viajan con cada nota.

El componente, sus registros, quién la escribió y cuándo, y en qué parte de la página estaba. Por eso nadie tiene que preguntar.

El bloque de componente de una nota real: elemento Button Subscribe, componente SubscribeButton en una compilación de desarrollo de React, origen /src/PricingCard.tsx línea 94, y dos selectores verificados.

El componente, no una suposición

Un selector verificado, el componente del framework que pintó el elemento y, en compilaciones de desarrollo, el fichero y la línea.

El panel lateral de FrontBug: tres notas de la misma página, cada una con su componente, tipo, estado y hace cuánto se escribió.

Quién, cuándo y dónde

Autor y hora en cada nota. También la página, el scroll y el viewport, porque un fallo de maquetación depende de los tres.

Tres formas de señalar algo.

Una página de precios con el botón Subscribe recuadrado y un pin numerado al lado.

Un elemento

Clic derecho encima. La nota queda anclada a ese componente y sobrevive a una recarga.

Un rectángulo dibujado sobre una tarjeta de precios, con los componentes de dentro listados en la nota.

Una zona

Arrastra un rectángulo. FrontBug lista todos los componentes de dentro, ordenados por cuánto los cubre.

Una página entera con tres pines numerados: uno en un botón, otro en una tarjeta y otro para la página.

La página entera

Todo el alto en una imagen, con las cabeceras fijas resueltas y los pines dibujados encima.

La pestaña de registros: el clic en Subscribe, después un POST al endpoint de pago y un error Checkout failed, los dos marcados como altos, y debajo el ruido de resize y scroll.

El error que importa, no todos los errores.

Un reporter sin configurar y un favicon que falta no son tu fallo. FrontBug los guarda, los agrupa por patrón, y pone arriba el error propio que vino justo después de tu clic.

No se descarta nada. El registro completo va en el paquete.

Funciona con la red apagada

Captura, anota y exporta en un avión o en la red cerrada de un cliente.

Local mientras no digas lo contrario

Todo se queda en tu navegador hasta que exportas un paquete o conectas un proyecto.

Dos personas, un mismo artefacto

Quien lo encuentra trabaja al lado de la página. Quien lo arregla abre una carpeta que ya dice qué componente falló.

Lo que recibe quien lo arregla.

Una carpeta. Se lee sola, y está hecha para que un agente de código trabaje directamente desde ella.

frontbug-app.example.com-2026-09-16/
  • report.mdevery note, with its component and logs
  • report.htmlthe same report, ready to print or send
  • AGENT.mdhow to work through it, for a coding agent
  • notes.jsonthe notes as data, fingerprint included
  • screenshots/elements, regions and full pages, pinned
  • dom/the markup around each note
  • logs/console, network, actions and navigation
  • audio/voice notes, when there are any

Léelo primero

report.md
Cada nota con su componente, su ubicación en el código y su ventana de registros.
AGENT.md
Cómo recorrer el informe, para Claude Code o Cursor.

Las pruebas

screenshots/
Recortes del elemento, zonas y páginas enteras con los pines dibujados.
notes.json
Las mismas notas como datos, con la huella completa del componente.
logs/
Consola, red, acciones del usuario y navegación, como JSON por líneas.

Una nota, cuatro manos, nada perdido.

Una sesión de revisión son diez notas en diez minutos. Aquí cada nota ya es un ticket, y cada mano que la toca queda registrada.

  1. 1

    Ana revisa

    Tres notas en dos minutos, cada una anclada al componente que la pintó. La sesión va al proyecto y el equipo se entera.

  2. 2

    Dani coge una

    Cogerla se la asigna, así que nadie más empieza el mismo trabajo. El tablero enseña quién la tiene y cuándo la tocó por última vez.

  3. 3

    La arregla, pero no la cierra

    Cae en To verify, no en Done. Quien arregla algo es la peor persona para decidir que funciona.

  4. 4

    Marta lo comprueba en la página

    Un clic abre el sitio, salta al componente y pone la captura antigua encima de la de ahora. Lo ve, y entonces lo cierra.

El tablero del equipo en el hub: notas como tarjetas en Open, In progress, To verify y Done, cada una con su captura, componente y responsable.

La comprobación pasa en la página, no sobre una descripción. Eso es lo que un gestor de tickets no te puede dar.