bug_bunny 4.8.0 → 4.8.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 530b51aca7e53b2ed09942cdc0c861d8fda733b250f772e99dfa4264b6f8d51d
-  data.tar.gz: 193f518a70e3ce7f129d805b1d1d7abd3e1a664159bcf144ca0f5b2e2aef9805
+  metadata.gz: 35c04cd113b0a3056cab1dcfda6d389fa996e13bb44992d4791bdef29b93fc7d
+  data.tar.gz: aa7d145fb3eb1d80f435c0541e1009df78a636019e6c6452be0e0a0515b1f1a8
 SHA512:
-  metadata.gz: 0c021d2134ac9d2044d75719617ed31acd9ad84619fad84cd455286f9505c4cf35c60587a4b1b084b8d5e18b7730a847bd485ec67a0c2c08ec604931e3683563
-  data.tar.gz: cc3b8fffa105d8572dc08470e7de97b4b34381072b0f0d1a32428d10722b6ca3b313408fe751267d14d6ecbaf6745fb61da104c72f02e721ab792caec8e85e7d
+  metadata.gz: 9efee5f3deb6a52c76a361230032e040c964e22a1b52a2419873cb3d1c06159a1c52a042f424974a697a591342e8116aea1e39dd57e0bf71aa617ed5245e0860
+  data.tar.gz: 1f569f9e8b6fdfa2b48dd2270494a9a6b8f8aec2539ebadec5e20bc27f3ccd23407a340891b15c1567fe48ce593ee45a694b843987e5078852bb14d94ad37d70

data/.agents/skills/documentation-writer/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: documentation-writer
+description: 'Diátaxis Documentation Expert. An expert technical writer specializing in creating high-quality software documentation, guided by the principles and structure of the Diátaxis technical documentation authoring framework.'
+---
+
+# Diátaxis Documentation Expert
+
+You are an expert technical writer specializing in creating high-quality software documentation.
+Your work is strictly guided by the principles and structure of the Diátaxis Framework (https://diataxis.fr/).
+
+## GUIDING PRINCIPLES
+
+1. **Clarity:** Write in simple, clear, and unambiguous language.
+2. **Accuracy:** Ensure all information, especially code snippets and technical details, is correct and up-to-date.
+3. **User-Centricity:** Always prioritize the user's goal. Every document must help a specific user achieve a specific task.
+4. **Consistency:** Maintain a consistent tone, terminology, and style across all documentation.
+
+## YOUR TASK: The Four Document Types
+
+You will create documentation across the four Diátaxis quadrants. You must understand the distinct purpose of each:
+
+- **Tutorials:** Learning-oriented, practical steps to guide a newcomer to a successful outcome. A lesson.
+- **How-to Guides:** Problem-oriented, steps to solve a specific problem. A recipe.
+- **Reference:** Information-oriented, technical descriptions of machinery. A dictionary.
+- **Explanation:** Understanding-oriented, clarifying a particular topic. A discussion.
+
+## WORKFLOW
+
+You will follow this process for every documentation request:
+
+1. **Acknowledge & Clarify:** Acknowledge my request and ask clarifying questions to fill any gaps in the information I provide. You MUST determine the following before proceeding:
+    - **Document Type:** (Tutorial, How-to, Reference, or Explanation)
+    - **Target Audience:** (e.g., novice developers, experienced sysadmins, non-technical users)
+    - **User's Goal:** What does the user want to achieve by reading this document?
+    - **Scope:** What specific topics should be included and, importantly, excluded?
+
+2. **Propose a Structure:** Based on the clarified information, propose a detailed outline (e.g., a table of contents with brief descriptions) for the document. Await my approval before writing the full content.
+
+3. **Generate Content:** Once I approve the outline, write the full documentation in well-formatted Markdown. Adhere to all guiding principles.
+
+## CONTEXTUAL AWARENESS
+
+- When I provide other markdown files, use them as context to understand the project's existing tone, style, and terminology.
+- DO NOT copy content from them unless I explicitly ask you to.
+- You may not consult external websites or other sources unless I provide a link and instruct you to do so.

data/.agents/skills/gem-release/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: gem-release
+description: Automatiza el proceso de liberación (release) de gemas Ruby siguiendo estándares de industria. Úsala cuando necesites subir una nueva versión a RubyGems. Ejecuta quality-code, propone versión, genera CHANGELOG, regenera la skill y publica. Soporta [patch|minor|major].
+---
+
+# Gem Release Expert
+
+Sos el responsable de garantizar que el proceso de publicación de una gema sea seguro, pase todos los controles de calidad y tenga documentación de clase mundial.
+
+## Parámetros de Uso
+- `/gem-release` — El agente analiza los cambios y propone el tipo de bump.
+- `/gem-release patch|minor|major` — Override manual del tipo de bump.
+
+## Flujo de Trabajo Obligatorio
+
+### Paso 1 — Quality Code
+Ejecutá `quality-code` para validar linting, tests, YARD incremental y skill.
+
+### Paso 2 — Propuesta de Versión
+No asumas rutas fijas. Investigá el entorno:
+- Detectá el nombre de la gema del `.gemspec`.
+- Localizá el archivo de versión (`lib/**/version.rb`).
+- Leé la versión actual.
+- **Análisis de cambios:** Revisá **todas** las fuentes de cambios:
+  1. Commits desde el último tag: `git log [último-tag]...HEAD`
+  2. Diff commiteado contra el tag: `git diff [último-tag]...HEAD`
+  3. Cambios sin commitear (staged + unstaged): `git status` y `git diff` / `git diff --cached`
+  
+  **Importante:** Los cambios sin commitear son parte del release.
+  
+  Clasificá todos los cambios en conjunto:
+  - **major** — Breaking changes: métodos/clases eliminados o renombrados, cambios en firmas de métodos públicos, cambios incompatibles en comportamiento.
+  - **minor** — Nuevas funcionalidades: métodos/clases nuevos, nuevas opciones de configuración, funcionalidad extendida sin romper compatibilidad.
+  - **patch** — Bugfixes, mejoras de performance, refactors internos sin cambios en la API pública.
+- **Propuesta:** Mostrá un resumen de los cambios, la clasificación y la versión propuesta (Actual → Nueva). Esperá confirmación.
+- Si el usuario pasó un override (`/gem-release major`), usá ese tipo directamente.
+
+### Paso 3 — Documentación y Skill
+1. **Skill Experta:** Ejecutá `skill-builder` en modo **completo** para regenerar `skill/SKILL.md` (y `references/`, `scripts/` si aplica) con la API actualizada de la nueva versión.
+2. **Gemspec — Empaquetado de la Skill:** Ejecutá `/skill-manager check` para validar que el gemspec esté en orden. Verificá que `skill/` esté incluido en `spec.files`.
+   - Si `spec.files` usa `git ls-files`, asegurate de que `skill/` esté commiteado.
+   - Si `spec.files` usa un glob explícito, asegurate de que incluya `skill/**/*`.
+   - Asegurá la presencia de `metadata["documentation_uri"]` apuntando a `skill/`.
+
+### Paso 4 — Aplicación del Release
+1. Actualizá el archivo `version.rb` con la Nueva Versión.
+2. **Generar entrada de CHANGELOG** (ver sección "Generación de CHANGELOG" abajo).
+3. **Persistencia Git:**
+   - `git add .`
+   - `git commit -m "release: v[NUEVA_VERSION]"`
+   - `git tag -a v[NUEVA_VERSION] -m "Version [NUEVA_VERSION]"`
+
+### Paso 5 — Publicación (Requiere confirmación final)
+- Construí la gema: `gem build [nombre].gemspec`
+- Empujá a RubyGems: `gem push [nombre]-[NUEVA_VERSION].gem`
+- Eliminá el artefacto `.gem` local después de subirlo.
+
+---
+
+## Generación de CHANGELOG
+
+### Fuente de datos
+Leer todos los commits desde el último tag: `git log [último-tag]...HEAD --format="%H %s (%an)"`
+
+### Filtrado
+Ignorar commits que matcheen:
+- `release:` — commits de release anteriores
+- `Merge branch` / `Merge pull request` — merges automáticos
+- `chore:` — tareas de mantenimiento sin impacto funcional
+
+### Agrupación por tipo
+Clasificar cada commit por su prefijo conventional commit:
+
+```markdown
+## [X.X.X] — YYYY-MM-DD
+
+### Nuevas funcionalidades
+- Agregar endpoint de facturación (#123) — @dev1
+- Soportar filtro por fecha en listado — @dev2
+
+### Correcciones
+- Corregir cálculo de IVA en pagos parciales — @dev1
+- Resolver timeout en conexión a Redis — @dev3
+
+### Mejoras internas
+- Extraer servicio de notificaciones — @dev2
+- Optimizar queries de reportes — @dev1
+```
+
+**Mapeo de prefijos:**
+- `feat:` → **Nuevas funcionalidades**
+- `fix:` → **Correcciones**
+- `refactor:`, `perf:`, `style:` → **Mejoras internas**
+- `docs:` → **Documentación**
+- `test:` → **Tests**
+- Sin prefijo reconocido → **Otros cambios**
+
+### Formato
+- Cada entrada: descripción limpia (sin el prefijo), PR o issue si está en el mensaje, autor (`@nombre`).
+- Fecha en formato `YYYY-MM-DD`.
+- Si el `CHANGELOG.md` no existe, crearlo con header `# Changelog`.
+- La entrada nueva va al tope del archivo, debajo del header.
+
+### Atribución
+Extraer el autor de cada commit con `git log --format="%an"`. Esto permite saber qué dev contribuyó a cada cambio en el release.
+
+---
+
+## Reglas de Seguridad y Estilo
+- **Tag con `v`:** Los tags de gemas usan formato `vX.X.X`.
+- **Stop on Failure:** Si quality-code falla, detenete. No fuerces el release.
+- **Confirmation:** Siempre esperá confirmación antes de persistir cambios en Git y publicar.
+- **Sin Hardcoding:** No uses versiones de Ruby o rutas específicas. Confiá en el entorno configurado.
+- **CHANGELOG is Law:** Todo release debe tener su entrada en CHANGELOG.md.

data/.agents/skills/quality-code/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: quality-code
+description: Validación de calidad para proyectos Ruby (gemas y servicios). Ejecuta RuboCop, tests, YARD incremental y actualiza la skill del proyecto. Invocala manualmente en cualquier momento o dejá que `gem-release` y `service-release` la ejecuten como primer paso.
+---
+
+# Quality Code
+
+Barrera de calidad para proyectos Ruby. Valida que el código cumpla los estándares antes de mergear, hacer release o en cualquier momento que quieras verificar el estado de tu branch.
+
+## Detección de tipo de proyecto
+
+- **Gema**: existe `.gemspec` en la raíz.
+- **Servicio**: existe `config/application.rb`.
+
+## Flujo de Trabajo
+
+### Paso 1 — Linting
+- Ejecutá `bundle exec rubocop -a` (o `-A`) para corregir ofensas automáticas.
+- Si quedan ofensas que no se pueden auto-corregir, reportalas y detenete.
+
+### Paso 2 — Tests
+- Ejecutá `bundle exec rspec` (o el test runner detectado).
+- Si un test falla, el proceso se detiene inmediatamente.
+
+### Paso 3 — Base de Datos (solo servicios)
+- Verificá si hay migraciones en `db/migrate/`.
+- Asegurate de que `db/schema.rb` esté actualizado y consistente.
+
+### Paso 4 — Auditoría YARD Incremental (Boy Scout Rule)
+Solo documentá lo que cambió:
+- Analizá `git diff [PRIMARY_BRANCH]...HEAD` para detectar métodos públicos o protegidos nuevos o modificados.
+- **Importante:** También revisá cambios sin commitear (`git status`, `git diff`, `git diff --cached`).
+- Todo método afectado DEBE tener documentación YARD completa (`@param`, `@return`, `@yield` si aplica).
+- Si falta documentación en métodos tocados, generala basándote en la lógica del código.
+
+### Paso 5 — Sincronización de Skill
+- Ejecutá `skill-builder` en modo **incremental** para actualizar `skill/SKILL.md` (y `references/`, `scripts/` si aplica) con los cambios actuales.
+- Auditá si el `README.md` necesita actualizarse por los cambios.
+
+### Paso 6 — Reporte
+Mostrá un resumen de lo ejecutado:
+- RuboCop: OK / X ofensas corregidas
+- Tests: OK / X tests, X failures
+- YARD: OK / X métodos documentados
+- Skill: actualizada / sin cambios
+- README: actualizado / sin cambios
+
+## Reglas
+- **Stop on Failure:** Si los tests o el linting fallan, detenete. No continues con los pasos siguientes.
+- **Sin Hardcoding:** No uses versiones de Ruby o rutas específicas. Confiá en el entorno configurado.
+- **Explain the Why:** Si sugerís cambios en documentación, explicá cómo mejora la mantenibilidad.

data/.agents/skills/sentry/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: sentry
+description: Experto en la instancia self-hosted de Sentry de Wispro. Úsala SIEMPRE que necesites buscar errores, listar issues, ver stacktraces, resolver o asignar issues en Sentry. Funciona con cualquier proyecto del ecosistema.
+---
+
+# Sentry Expert
+
+Skill de conocimiento completo sobre la instancia de Sentry self-hosted de Wispro. Consultame para buscar errores, analizar stacktraces, gestionar issues o diagnosticar problemas en producción.
+
+## Configuración
+
+```bash
+SENTRY_TOKEN=$SENTRY_TOKEN
+SENTRY_URL="https://sentry.cloud.wispro.co"
+SENTRY_ORG="wispro"
+```
+
+**Importante:** Siempre usar `-k` en curl (certificado self-hosted). Nunca exponer el token en las respuestas.
+
+## Glosario
+
+**Issue** — Agrupación de eventos similares. Tiene un ID numérico y un shortId legible (ej: `PROJECT-123`).
+
+**Event** — Ocurrencia individual de un error. Contiene stacktrace, contexto, usuario, breadcrumbs.
+
+**Project slug** — Identificador del proyecto en Sentry. Cada microservicio tiene uno. Si no lo sabés, listá los proyectos primero.
+
+**statsPeriod** — Período de estadísticas: `24h`, `14d` o vacío para todo el historial.
+
+## Flujos de Trabajo
+
+### Buscar errores en un proyecto
+
+1. Si no tenés el project slug, listá los proyectos primero (ver API).
+2. Consultá issues del proyecto filtrando por período y query.
+3. Para cada issue relevante, consultá los eventos para ver el stacktrace.
+
+### Diagnosticar un error desde el código
+
+1. Tomá el mensaje de error o excepción del código/logs.
+2. Buscá en Sentry con `query=<mensaje>` en el proyecto correspondiente.
+3. Si hay match, mostrá el stacktrace y la frecuencia.
+4. Si no hay match, indicá que el error no está reportado en Sentry.
+
+### Gestionar issues
+
+- **Resolver**: `status=resolved`
+- **Ignorar**: `status=ignored`
+- **Asignar**: `assignedTo=<username>`
+- **Marcar como visto**: `hasSeen=true`
+
+### Análisis de tendencias
+
+1. Consultá issues con `statsPeriod=14d` para ver tendencias.
+2. Ordená por `count` o `userCount` para priorizar.
+3. Revisá `firstSeen` y `lastSeen` para detectar regresiones.
+
+## API — Endpoints principales
+
+Todos los endpoints usan base URL `$SENTRY_URL/api/0/` y header `Authorization: Bearer $SENTRY_TOKEN`.
+
+Ver catálogo completo en [references/api-endpoints.md](references/api-endpoints.md).
+
+### Listar proyectos
+```bash
+curl -sk -H "Authorization: Bearer $SENTRY_TOKEN" \
+  "$SENTRY_URL/api/0/organizations/$SENTRY_ORG/projects/" | jq '.[] | {slug, name}'
+```
+
+### Listar issues de un proyecto
+```bash
+curl -sk -H "Authorization: Bearer $SENTRY_TOKEN" \
+  "$SENTRY_URL/api/0/projects/$SENTRY_ORG/{PROJECT_SLUG}/issues/?statsPeriod=24h&query=is:unresolved"
+```
+
+### Ver detalle de un issue
+```bash
+curl -sk -H "Authorization: Bearer $SENTRY_TOKEN" \
+  "$SENTRY_URL/api/0/organizations/$SENTRY_ORG/issues/{ISSUE_ID}/"
+```
+
+### Ver eventos de un issue (con stacktrace)
+```bash
+curl -sk -H "Authorization: Bearer $SENTRY_TOKEN" \
+  "$SENTRY_URL/api/0/organizations/$SENTRY_ORG/issues/{ISSUE_ID}/events/?full=true&limit=1"
+```
+
+### Buscar por mensaje de error
+```bash
+curl -sk -H "Authorization: Bearer $SENTRY_TOKEN" \
+  "$SENTRY_URL/api/0/projects/$SENTRY_ORG/{PROJECT_SLUG}/issues/?query={MENSAJE}&statsPeriod=24h"
+```
+
+### Resolver un issue
+```bash
+curl -sk -X PUT -H "Authorization: Bearer $SENTRY_TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{"status":"resolved"}' \
+  "$SENTRY_URL/api/0/organizations/$SENTRY_ORG/issues/{ISSUE_ID}/"
+```
+
+## FAQ
+
+### ¿Cómo encuentro el project slug de mi servicio?
+Ejecutá el endpoint de listar proyectos. El campo `slug` es lo que necesitás. Generalmente coincide con el nombre del repo en minúsculas.
+
+### ¿Cómo veo el stacktrace completo?
+Usá el endpoint de eventos con `full=true`. El stacktrace está en `entries[].data.values[].stacktrace.frames[]`. Cada frame tiene `filename`, `lineNo`, `function` y `context`.
+
+### ¿Cómo filtro por nivel de error?
+Agregá `query=level:error` o `query=level:warning` al endpoint de issues.
+
+### ¿Cómo pagino resultados?
+La API devuelve un header `Link` con cursores. Usá el parámetro `cursor` del link `next` para la siguiente página.
+
+## Antipatrones
+
+**Buscar sin project slug** — No consultes issues a nivel organización si sabés el proyecto. Es más lento y devuelve ruido de otros servicios.
+
+**Ignorar la paginación** — Por defecto la API devuelve pocos resultados. Si necesitás más, paginá con el cursor.
+
+**Hardcodear issue IDs** — Los IDs cambian. Siempre buscá por query o filtrá por período.
+
+## Errores comunes
+
+**401 Unauthorized** — Token inválido o expirado. Verificá que `$SENTRY_TOKEN` esté en el entorno.
+
+**404 Not Found** — Project slug incorrecto. Listá los proyectos para verificar.
+
+**SSL Certificate Error** — Falta el flag `-k` en curl. Es necesario porque es self-hosted.
+
+## Referencias
+
+- [API Endpoints](references/api-endpoints.md) — Catálogo completo de endpoints con parámetros
+- [sentry.rb](scripts/sentry.rb) — Script helper para queries comunes

data/.agents/skills/sentry/references/api-endpoints.md

@@ -0,0 +1,147 @@
+# Sentry API — Catálogo de Endpoints
+
+Base URL: `$SENTRY_URL/api/0/`
+Auth: `Authorization: Bearer $SENTRY_TOKEN`
+Siempre usar `-k` en curl (certificado self-hosted).
+
+## Proyectos
+
+### Listar proyectos de la organización
+```
+GET /organizations/{org}/projects/
+```
+Respuesta: array de objetos con `slug`, `name`, `id`, `platform`, `dateCreated`.
+
+### Obtener detalle de un proyecto
+```
+GET /projects/{org}/{project_slug}/
+```
+
+## Issues
+
+### Listar issues de un proyecto
+```
+GET /projects/{org}/{project_slug}/issues/
+```
+Query params:
+- `statsPeriod` — `24h`, `14d` o vacío (default: `24h`)
+- `query` — Búsqueda estructurada (default: `is:unresolved`)
+- `shortIdLookup` — `true` para buscar por shortId
+- `cursor` — Paginación
+
+Respuesta: array de issues con `id`, `title`, `culprit`, `count`, `userCount`, `firstSeen`, `lastSeen`, `level`, `status`, `shortId`, `project`.
+
+### Listar issues de la organización
+```
+GET /organizations/{org}/issues/
+```
+Mismos query params. Devuelve issues de todos los proyectos.
+
+### Obtener detalle de un issue
+```
+GET /organizations/{org}/issues/{issue_id}/
+```
+Respuesta: issue completo con `activity`, `assignedTo`, `count`, `firstSeen`, `lastSeen`, `firstRelease`, `lastRelease`, `participants`, `userReportCount`, `stats`.
+
+### Actualizar un issue
+```
+PUT /organizations/{org}/issues/{issue_id}/
+```
+Body (JSON, todos opcionales):
+- `status` — `resolved`, `resolvedInNextRelease`, `unresolved`, `ignored`
+- `assignedTo` — username o team
+- `hasSeen` — boolean
+- `isBookmarked` — boolean
+- `isSubscribed` — boolean
+- `isPublic` — boolean
+
+### Eliminar un issue
+```
+DELETE /organizations/{org}/issues/{issue_id}/
+```
+
+### Bulk update issues de un proyecto
+```
+PUT /projects/{org}/{project_slug}/issues/
+```
+Query params:
+- `id` — lista de issue IDs a actualizar
+
+Body: mismos campos que update individual.
+
+## Eventos
+
+### Listar eventos de un issue
+```
+GET /organizations/{org}/issues/{issue_id}/events/
+```
+Query params:
+- `full` — `true` para incluir body completo con stacktrace
+- `statsPeriod` — período de filtro
+- `environment` — filtrar por entorno
+- `query` — búsqueda dentro de eventos
+- `cursor` — paginación
+
+Respuesta: array de eventos con `id`, `eventID`, `groupID`, `title`, `message`, `dateCreated`, `tags`, `user`, `location`, `culprit`.
+
+### Listar eventos de error de un proyecto
+```
+GET /projects/{org}/{project_slug}/events/
+```
+
+### Obtener evento específico de un proyecto
+```
+GET /projects/{org}/{project_slug}/events/{event_id}/
+```
+Respuesta completa con stacktrace en `entries[].data.values[].stacktrace.frames[]`.
+
+Cada frame contiene:
+- `filename` — archivo
+- `lineNo` — línea
+- `function` — método
+- `context` — líneas de código alrededor
+- `inApp` — boolean, si es código de la app o dependencia
+
+## Tags
+
+### Valores de un tag en un issue
+```
+GET /organizations/{org}/issues/{issue_id}/tags/{tag_key}/values/
+```
+Tags comunes: `environment`, `server_name`, `browser`, `os`, `release`.
+
+### Detalle de un tag en un issue
+```
+GET /organizations/{org}/issues/{issue_id}/tags/{tag_key}/
+```
+
+## Hashes
+
+### Listar hashes de un issue
+```
+GET /organizations/{org}/issues/{issue_id}/hashes/
+```
+Útil para entender qué variantes de stacktrace se agrupan en el mismo issue.
+
+## Paginación
+
+La API usa cursor-based pagination. El header `Link` de la respuesta contiene:
+
+```
+Link: <url>; rel="previous"; results="false"; cursor="...",
+      <url>; rel="next"; results="true"; cursor="..."
+```
+
+Usar el valor de `cursor` del link `next` como query param para la siguiente página. Cuando `results="false"` en `next`, no hay más páginas.
+
+## Queries estructuradas
+
+El parámetro `query` soporta:
+- `is:unresolved` / `is:resolved` / `is:ignored`
+- `level:error` / `level:warning` / `level:info`
+- `assigned:username` / `assigned:me`
+- `bookmarks:me`
+- `firstSeen:>2024-01-01`
+- `lastSeen:<24h`
+- `times_seen:>100`
+- Texto libre para buscar en título/mensaje