python-vibe-guard 0.12.1__tar.gz → 0.12.2__tar.gz

{python_vibe_guard-0.12.1 → python_vibe_guard-0.12.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: python-vibe-guard
-Version: 0.12.1
+Version: 0.12.2
 Summary: Runtime anti-pattern scanner for async Python — detects what AI-generated code gets wrong
 License: MIT
 Keywords: async,linter,fastapi,asyncio,static-analysis
@@ -79,7 +79,7 @@ Patterns that introduce data races, swallowed errors, or runaway loops under con
 | PYVIBE-020 | `put_nowait()` without `asyncio.QueueFull` handler | any | `QueueFull` propagates unhandled; item is silently lost on bounded queues |
 
 **Severity notes:**
-- PYVIBE-005: `CRITICAL` — checks per-task decorator arguments only. **If your project sets a global `task_time_limit` via `app.conf.task_time_limit`, `app.conf.update(...)`, or in `celeryconfig.py` / `settings.py`, tasks already covered by that global limit will still be flagged.** Add per-task limits (self-documenting, immune to config drift) or suppress with `# noqa: PYVIBE-005`.
+- PYVIBE-005: `CRITICAL` — checks per-task decorator arguments only. **If your project sets a global `task_time_limit` via `app.conf.task_time_limit`, `app.conf.update(...)`, or in `celeryconfig.py` / `settings.py`, tasks already covered by that global limit will still be flagged.** Add per-task limits (self-documenting, immune to config drift) or suppress with `# pyvibe: ignore PYVIBE-005` on the task's `def` line.
 - PYVIBE-009: `CRITICAL` in production files; automatically downgraded to `WARNING` in test files (`test_*.py`, `*_test.py`, `tests/`). **Context matters:** `open()` in a hot-path request handler blocks all concurrent coroutines (CRITICAL); `open()` in a startup/lifespan function runs before requests are served and has zero practical impact. The rule cannot distinguish these contexts via AST — if you use `open()` in an `async def` lifespan or one-time initializer, the idiomatic fix is to use plain `def` instead (FastAPI's own docs do this), which avoids the flag entirely.
 - PYVIBE-017: bare `except` → `CRITICAL` (catches `KeyboardInterrupt`/`SystemExit`); `except Exception` with empty body → `WARNING`. Specific exceptions (`except ValueError: pass`) are not flagged.
 - PYVIBE-013 in test files: automatically downgraded to `WARNING` in files matching `test_*.py`, `*_test.py`, or paths under `tests/` — exceptions should propagate for assertions in test code.
@@ -451,7 +451,7 @@ Add to your `.pre-commit-config.yaml`:
 ```yaml
 repos:
   - repo: https://github.com/Joaquinriosheredia/python-vibe-guard
-    rev: v0.7.0
+    rev: v0.12.2
     hooks:
       - id: python-vibe-guard
 ```
@@ -498,6 +498,12 @@ python tests/test_rules.py
 
 ---
 
+## Documentation
+
+- [research/public-findings.md](research/public-findings.md) — real findings reported to public open source projects, including confirmed cases and cases where context changed the outcome.
+
+---
+
 ## Ecosystem
 
 This project is part of the **vibe-guard** family of runtime anti-pattern scanners:

{python_vibe_guard-0.12.1 → python_vibe_guard-0.12.2}/README.md

@@ -63,7 +63,7 @@ Patterns that introduce data races, swallowed errors, or runaway loops under con
 | PYVIBE-020 | `put_nowait()` without `asyncio.QueueFull` handler | any | `QueueFull` propagates unhandled; item is silently lost on bounded queues |
 
 **Severity notes:**
-- PYVIBE-005: `CRITICAL` — checks per-task decorator arguments only. **If your project sets a global `task_time_limit` via `app.conf.task_time_limit`, `app.conf.update(...)`, or in `celeryconfig.py` / `settings.py`, tasks already covered by that global limit will still be flagged.** Add per-task limits (self-documenting, immune to config drift) or suppress with `# noqa: PYVIBE-005`.
+- PYVIBE-005: `CRITICAL` — checks per-task decorator arguments only. **If your project sets a global `task_time_limit` via `app.conf.task_time_limit`, `app.conf.update(...)`, or in `celeryconfig.py` / `settings.py`, tasks already covered by that global limit will still be flagged.** Add per-task limits (self-documenting, immune to config drift) or suppress with `# pyvibe: ignore PYVIBE-005` on the task's `def` line.
 - PYVIBE-009: `CRITICAL` in production files; automatically downgraded to `WARNING` in test files (`test_*.py`, `*_test.py`, `tests/`). **Context matters:** `open()` in a hot-path request handler blocks all concurrent coroutines (CRITICAL); `open()` in a startup/lifespan function runs before requests are served and has zero practical impact. The rule cannot distinguish these contexts via AST — if you use `open()` in an `async def` lifespan or one-time initializer, the idiomatic fix is to use plain `def` instead (FastAPI's own docs do this), which avoids the flag entirely.
 - PYVIBE-017: bare `except` → `CRITICAL` (catches `KeyboardInterrupt`/`SystemExit`); `except Exception` with empty body → `WARNING`. Specific exceptions (`except ValueError: pass`) are not flagged.
 - PYVIBE-013 in test files: automatically downgraded to `WARNING` in files matching `test_*.py`, `*_test.py`, or paths under `tests/` — exceptions should propagate for assertions in test code.
@@ -435,7 +435,7 @@ Add to your `.pre-commit-config.yaml`:
 ```yaml
 repos:
   - repo: https://github.com/Joaquinriosheredia/python-vibe-guard
-    rev: v0.7.0
+    rev: v0.12.2
     hooks:
       - id: python-vibe-guard
 ```
@@ -482,6 +482,12 @@ python tests/test_rules.py
 
 ---
 
+## Documentation
+
+- [research/public-findings.md](research/public-findings.md) — real findings reported to public open source projects, including confirmed cases and cases where context changed the outcome.
+
+---
+
 ## Ecosystem
 
 This project is part of the **vibe-guard** family of runtime anti-pattern scanners:

{python_vibe_guard-0.12.1 → python_vibe_guard-0.12.2}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "python-vibe-guard"
-version = "0.12.1"
+version = "0.12.2"
 description = "Runtime anti-pattern scanner for async Python — detects what AI-generated code gets wrong"
 readme = "README.md"
 requires-python = ">=3.10"
@@ -28,3 +28,6 @@ pyvibe = "pyvibe.cli:main"
 [tool.setuptools.packages.find]
 where = ["."]
 include = ["pyvibe*"]
+
+[tool.setuptools.package-data]
+pyvibe = ["_evidence/*.md", "_evidence/accepted/*.md"]

{python_vibe_guard-0.12.1 → python_vibe_guard-0.12.2}/python_vibe_guard.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: python-vibe-guard
-Version: 0.12.1
+Version: 0.12.2
 Summary: Runtime anti-pattern scanner for async Python — detects what AI-generated code gets wrong
 License: MIT
 Keywords: async,linter,fastapi,asyncio,static-analysis
@@ -79,7 +79,7 @@ Patterns that introduce data races, swallowed errors, or runaway loops under con
 | PYVIBE-020 | `put_nowait()` without `asyncio.QueueFull` handler | any | `QueueFull` propagates unhandled; item is silently lost on bounded queues |
 
 **Severity notes:**
-- PYVIBE-005: `CRITICAL` — checks per-task decorator arguments only. **If your project sets a global `task_time_limit` via `app.conf.task_time_limit`, `app.conf.update(...)`, or in `celeryconfig.py` / `settings.py`, tasks already covered by that global limit will still be flagged.** Add per-task limits (self-documenting, immune to config drift) or suppress with `# noqa: PYVIBE-005`.
+- PYVIBE-005: `CRITICAL` — checks per-task decorator arguments only. **If your project sets a global `task_time_limit` via `app.conf.task_time_limit`, `app.conf.update(...)`, or in `celeryconfig.py` / `settings.py`, tasks already covered by that global limit will still be flagged.** Add per-task limits (self-documenting, immune to config drift) or suppress with `# pyvibe: ignore PYVIBE-005` on the task's `def` line.
 - PYVIBE-009: `CRITICAL` in production files; automatically downgraded to `WARNING` in test files (`test_*.py`, `*_test.py`, `tests/`). **Context matters:** `open()` in a hot-path request handler blocks all concurrent coroutines (CRITICAL); `open()` in a startup/lifespan function runs before requests are served and has zero practical impact. The rule cannot distinguish these contexts via AST — if you use `open()` in an `async def` lifespan or one-time initializer, the idiomatic fix is to use plain `def` instead (FastAPI's own docs do this), which avoids the flag entirely.
 - PYVIBE-017: bare `except` → `CRITICAL` (catches `KeyboardInterrupt`/`SystemExit`); `except Exception` with empty body → `WARNING`. Specific exceptions (`except ValueError: pass`) are not flagged.
 - PYVIBE-013 in test files: automatically downgraded to `WARNING` in files matching `test_*.py`, `*_test.py`, or paths under `tests/` — exceptions should propagate for assertions in test code.
@@ -451,7 +451,7 @@ Add to your `.pre-commit-config.yaml`:
 ```yaml
 repos:
   - repo: https://github.com/Joaquinriosheredia/python-vibe-guard
-    rev: v0.7.0
+    rev: v0.12.2
     hooks:
       - id: python-vibe-guard
 ```
@@ -498,6 +498,12 @@ python tests/test_rules.py
 
 ---
 
+## Documentation
+
+- [research/public-findings.md](research/public-findings.md) — real findings reported to public open source projects, including confirmed cases and cases where context changed the outcome.
+
+---
+
 ## Ecosystem
 
 This project is part of the **vibe-guard** family of runtime anti-pattern scanners:

{python_vibe_guard-0.12.1 → python_vibe_guard-0.12.2}/python_vibe_guard.egg-info/SOURCES.txt

@@ -19,6 +19,27 @@ pyvibe/explain.py
 pyvibe/rule_docs.py
 pyvibe/sarif.py
 pyvibe/suppressions.py
+pyvibe/_evidence/precision-audit.md
+pyvibe/_evidence/accepted/PYVIBE-001.md
+pyvibe/_evidence/accepted/PYVIBE-002.md
+pyvibe/_evidence/accepted/PYVIBE-003.md
+pyvibe/_evidence/accepted/PYVIBE-004.md
+pyvibe/_evidence/accepted/PYVIBE-005.md
+pyvibe/_evidence/accepted/PYVIBE-006.md
+pyvibe/_evidence/accepted/PYVIBE-007.md
+pyvibe/_evidence/accepted/PYVIBE-008.md
+pyvibe/_evidence/accepted/PYVIBE-009.md
+pyvibe/_evidence/accepted/PYVIBE-010.md
+pyvibe/_evidence/accepted/PYVIBE-011.md
+pyvibe/_evidence/accepted/PYVIBE-012.md
+pyvibe/_evidence/accepted/PYVIBE-013.md
+pyvibe/_evidence/accepted/PYVIBE-014.md
+pyvibe/_evidence/accepted/PYVIBE-015.md
+pyvibe/_evidence/accepted/PYVIBE-016.md
+pyvibe/_evidence/accepted/PYVIBE-017.md
+pyvibe/_evidence/accepted/PYVIBE-018.md
+pyvibe/_evidence/accepted/PYVIBE-019.md
+pyvibe/_evidence/accepted/PYVIBE-020.md
 pyvibe/rules/__init__.py
 pyvibe/rules/async_requests.py
 pyvibe/rules/async_sleep.py
@@ -45,6 +66,7 @@ tests/test_audit.py
 tests/test_baseline.py
 tests/test_config.py
 tests/test_diff.py
+tests/test_evidence_sync.py
 tests/test_exclude.py
 tests/test_explain.py
 tests/test_rules.py

python_vibe_guard-0.12.2/pyvibe/__init__.py

@@ -0,0 +1 @@
+__version__ = "0.12.2"

python_vibe_guard-0.12.2/pyvibe/_evidence/accepted/PYVIBE-001.md

@@ -0,0 +1,172 @@
+# PYVIBE-001 — time.sleep() en async def
+
+**Severidad:** CRITICAL  
+**Archivo:** `pyvibe/rules/async_sleep.py`  
+**Patrón:** `time.sleep(N)` llamado directamente dentro de `async def`
+
+---
+
+## Datos objetivos
+
+| Métrica | 100 repos | 250 repos |
+|---------|-----------|-----------|
+| Repos afectados | 16/100 (16.0%) | 31/250 (12.4%) |
+| Total hits | 55 | 87 |
+| Estabilidad 100→250 | Alta (−3.6 pp) | |
+| Falsos positivos documentados | 0 | |
+
+## Repos representativos (sweep 250)
+
+- `home-assistant/core` — 17 hits
+- `pmh1314520/WebRPA` — 9 hits
+- `MODSetter/SurfSense` — 7 hits
+- `IBM/mcp-context-forge` — 6 hits
+- `learning-at-home/hivemind` — 5 hits
+
+---
+
+## Evidence Review Protocol v1
+
+### Paso 1 — Documentación oficial
+
+**Resultado: CONFIRMADO — mención explícita en docs.python.org**
+
+`docs.python.org/3/library/asyncio-task.html` (sección `asyncio.to_thread()`) usa `time.sleep()` como el ejemplo canónico de llamada bloqueante, con la nota explícita:
+
+> *"Note that time.sleep() can be replaced with any blocking IO-bound operation, such as file operations."*
+
+y el efecto documentado:
+
+> *"Directly calling blocking_io() in any coroutine would block the event loop for its duration, resulting in an additional 1 second of run time."*
+
+El ejemplo de código en la doc muestra `time.sleep(1)` dentro de una función sync (correctamente) y la llamada bloqueante desde una coroutine como el antipatrón a evitar, mostrando `asyncio.to_thread(blocking_io)` como la solución.
+
+`docs.python.org/3/library/asyncio-dev.html` (Developing with asyncio) añade:
+
+> *"Blocking (CPU-bound) code should not be called directly. For example, if a function performs a CPU-intensive calculation for 1 second, all concurrent asyncio Tasks and IO operations would be delayed by 1 second."*
+
+Este texto no nombra `time.sleep()` explícitamente, pero lo describe de forma genérica.
+
+**Tornado FAQ** (framework de referencia para async Python predecesor de asyncio):
+
+> *"time.sleep is a blocking function: it doesn't allow control to return to the IOLoop so that other handlers can be run."*
+
+**Veredicto paso 1:** documentación oficial Python nombra `time.sleep()` explícitamente como el ejemplo estándar de llamada bloqueante que no debe usarse directamente en coroutines.
+
+---
+
+### Paso 2 — Incidentes reales
+
+**Resultado: CONFIRMADO — issue real en producción**
+
+**[home-assistant/core#119628](https://github.com/home-assistant/core/issues/119628)** (cerrado):  
+`time.sleep(0.3)` en la librería `pyserial-asyncio` (línea 104 de `serial/urlhandler/protocol_socket.py`) era llamado desde dentro del event loop de Home Assistant. Home Assistant 2024.6.2 introdujo detección activa de llamadas bloqueantes y produjo el warning:
+
+> *"Detected blocking call to sleep inside the event loop by integration 'config'..."*
+
+La issue fue reportada en core-2024.6.2 y no ocurría en core-2024.4.4. Issue cerrada — el impacto fue degradación de responsividad durante reloads de integration.
+
+**[MagicStack/uvloop#29](https://github.com/MagicStack/uvloop/issues/29)** (aparece en búsqueda, no verificado con fetch):  
+Mencionado en el contexto de que "el tiempo del loop no avanza cuando el loop está bloqueado por time.sleep()" — consistente con el comportamiento documentado.
+
+**DEV.to "3-Hour Debugging: How time.sleep in Async Functions Killed Our asyncio Concurrency":**  
+Post con formato de caso de debugging. El síntoma: un servicio de recolección de datos que no mejoró al convertirse a async, tomando los mismos 30 minutos por ejecución. Causa raíz: `time.sleep(0.5)` enterrado en una función anidada. **No es un postmortem con nombre de empresa verificable** — es contenido educativo presentado como caso de estudio. No cuenta como incidente público confirmado.
+
+**Veredicto paso 2:** un incidente real confirmado en GitHub (home-assistant/core#119628, cerrado). El impacto fue observable en producción.
+
+---
+
+### Paso 3 — Comunidad
+
+**Resultado: CONSENSO UNIVERSAL — sin casos de desacuerdo**
+
+La búsqueda no encontró ninguna discusión en Stack Overflow, DEV.to, Medium o foros que sugiera que `time.sleep()` dentro de `async def` sea aceptable. El consenso es unánime:
+
+- La causa síntomática más reportada: *"convertí mi código a async pero no mejora la velocidad"*
+- Solución universal documentada: reemplazar `time.sleep(n)` por `await asyncio.sleep(n)`, o por `await asyncio.to_thread(time.sleep, n)` si la intención es bloquear en un thread aparte
+- El Mergify blog documenta la detección de event loop blocking mediante medición de latencia; usa `time.sleep()` como ejemplo paradigmático del problema a detectar
+
+**Veredicto paso 3:** la comunidad no tiene posiciones encontradas sobre este patrón. Es tratado como bug obvio.
+
+---
+
+### Paso 4 — Evidencia empírica propia
+
+**Resultado: FUERTE**
+
+- 31/250 repos afectados (12.4%) — estabilidad Alta (−3.6 pp entre 100 y 250 repos)
+- 87 hits totales en proyectos de alta estrella con asyncio
+- Presente en repos de referencia: `home-assistant/core`, `MODSetter/SurfSense`, `IBM/mcp-context-forge`
+- 0 falsos positivos documentados en 250 repos escaneados
+
+---
+
+### Paso 5 — Intento de refutación
+
+**Búsqueda activa de excepciones legítimas.**
+
+**¿Existe algún caso donde `time.sleep()` dentro de `async def` sea intencional y correcto?**
+
+La búsqueda encontró tres escenarios candidatos:
+
+**Candidato A — Testing de comportamiento bloqueante**  
+Usar `time.sleep()` en un test `async def` para simular una llamada bloqueante y verificar que el detector de blocking funciona. *Técnicamente funciona, pero:*
+- `asynctest` y `sleepfake` (librerías de testing para asyncio) proveen `advance()` y mocking de clock precisamente para evitar `time.sleep()` real en tests
+- Ningún framework de testing Python recomienda `time.sleep()` real en async tests; se recomienda mockear o usar `asyncio.sleep()` con un loop de testing
+- **Veredicto: no es una excepción legítima que invalide la regla**
+
+**Candidato B — Delay deliberado en un sistema sin concurrencia**  
+Código que usa `async def` pero en la práctica solo ejecuta una tarea a la vez y quiere añadir un delay. `time.sleep()` funciona en este caso porque no hay otra coroutine esperando.  
+- Esto es una antipatrón de diseño: si no se necesita concurrencia, no debería usarse asyncio
+- Si se necesita asyncio pero se quiere bloquear un momento, `await asyncio.sleep(n)` es siempre equivalente y correcto
+- **Veredicto: funciona técnicamente pero nunca es la opción correcta**
+
+**Candidato C — Wrapper para `asyncio.to_thread()`**  
+`await asyncio.to_thread(time.sleep, n)` — llamar `time.sleep` desde `async def` *como argumento de `to_thread`*, no como llamada directa. Esto ES correcto.  
+- PYVIBE-001 **no flagea este patrón**: la regla detecta `time.sleep(...)` como expresión directa en el cuerpo de `async def`, no como argumento de otra función
+- **Veredicto: caso correcto, y la regla ya lo maneja bien**
+
+**Excepción conocida documentada:**  
+No se encontró ningún caso donde `time.sleep(n)` directamente en el cuerpo de `async def` sea la opción técnicamente correcta sobre `await asyncio.sleep(n)`. Tornado FAQ, Python docs y comunidad son unánimes.
+
+**Límite honesto:** los 31 repos con hits no han sido auditados manualmente para verificar si algún hit está en un test que específicamente testea comportamiento bloqueante. Este caso extremo existe en teoría pero no se ha verificado en el scan actual.
+
+---
+
+## Clasificación final
+
+**Evidence Level: A+**
+
+| Criterio | Estado |
+|----------|--------|
+| Validada en repos reales (31/250, 12.4%) | ✅ |
+| Documentación oficial Python nombra `time.sleep()` explícitamente | ✅ |
+| Incidente público confirmado (HA core#119628, cerrado) | ✅ |
+| Falsos positivos documentados en campo | ✅ 0 |
+| Excepción legítima conocida | ✅ ninguna para llamada directa |
+
+---
+
+## Confidence
+
+```
+Confidence:
+  Detection:         High — AST directo sobre name="sleep" en module time;
+                            0 FP documentados en 250 repos; el Candidato C
+                            (to_thread) no es flagueado correctamente
+  Runtime impact:    High — bloquea el event loop completo para toda la
+                            duración del sleep; efecto demostrado en HA prod
+  External evidence: High — docs.python.org nombra time.sleep() explícitamente
+                            + HA issue real cerrado + consenso comunitario unánime
+```
+
+---
+
+## Fuentes verificadas
+
+- [asyncio-task.html — asyncio.to_thread() example](https://docs.python.org/3/library/asyncio-task.html)
+- [asyncio-dev.html — Developing with asyncio](https://docs.python.org/3/library/asyncio-dev.html)
+- [Tornado FAQ — time.sleep is a blocking function](https://www.tornadoweb.org/en/stable/faq.html)
+- [home-assistant/core#119628 — Blocking call to sleep inside event loop](https://github.com/home-assistant/core/issues/119628)
+- [Mergify — Detecting Blocking Tasks in Asyncio](https://mergify.com/blog/detecting-blocking-tasks-in-asyncio-by-measuring-event-loop-latency/)
+- [DEV.to — 3-Hour Debugging case study (educativo, sin empresa verificable)](https://dev.to/_eb7f2a654e97a60ae9f96e/3-hour-debugging-how-timesleep-in-async-functions-killed-our-asyncio-concurrency-43c3)

python_vibe_guard-0.12.2/pyvibe/_evidence/accepted/PYVIBE-002.md

@@ -0,0 +1,86 @@
+# PYVIBE-002 — requests.get/post en async def
+
+**Severidad:** CRITICAL  
+**Archivo:** `pyvibe/rules/async_requests.py`  
+**Patrón:** `requests.get(...)` / `requests.post(...)` / etc. dentro de `async def`
+
+## Datos objetivos
+
+| Métrica | 100 repos | 250 repos |
+|---------|-----------|-----------|
+| Repos afectados | 3/100 (3.0%) | 10/250 (4.0%) |
+| Total hits | 5 | 14 |
+| Estabilidad 100→250 | Alta (+1.0 pp) | |
+| Falsos positivos documentados | 0 | |
+
+## Repos representativos (sweep 250)
+
+- `paulpierre/RasaGPT` — 3 hits
+- `home-assistant/core` — 2 hits
+- `learning-at-home/hivemind` — 2 hits
+- `bmoscon/cryptofeed` — 1 hit
+- `pydantic/logfire` — 1 hit
+
+## Evidence Level: B
+
+- ✅ Validada en repos reales: 10 repos afectados en muestra de 250
+- ⏳ Documentación oficial o incidentes públicos confirmando `requests` sync en async como bug: **PENDIENTE — requiere investigación manual**
+- ✅ Falsos positivos documentados en campo: 0
+
+---
+
+## Auditoría de Precisión (Sweep 250)
+
+**Muestra analizada:** 14 hits de 14 totales (10 repos)
+**Metodología:** 100% audit (14 hits)
+
+### Clasificación hit-by-hit
+
+| # | Repo | File:Line | Function | Clasificación | Razón |
+|---|------|-----------|----------|---------------|-------|
+| 1 | BetaStreetOmnis__xhs_ai_publisher | src/core/pages/tools.py:63 | async_process | FP | `requests.post()` dentro de `loop.run_in_executor(None, lambda: requests.post(...))` — la llamada síncrona está correctamente delegada al executor de threads; el comentario en código incluso menciona que se podría usar aiohttp |
+| 2 | Kav-K__GPTDiscord | models/openai_model.py:1312 | save_image_urls_and_return | FP | `requests.get()` dentro de `asyncio.get_running_loop().run_in_executor(None, lambda: [...])` — correctamente envuelto en executor |
+| 3 | bmoscon__cryptofeed | cryptofeed/exchanges/binance.py:158 | _refresh_token | TP | `requests.put()` directo en `async def _refresh_token`, sin executor. Bug real — bloquea el event loop durante token refresh en un bucle while True |
+| 4 | home-assistant__core | homeassistant/components/downloader/services.py:64 | download_file | FP | `requests.get()` dentro de `def do_download()` (función síncrona), que se llama luego con `await service.hass.async_add_executor_job(do_download)` — el detector flagueó la línea del requests.get pero está en una función def interna que se ejecuta en executor |
+| 5 | home-assistant__core | homeassistant/components/xmpp/notify.py:274 | upload_file_from_url | FP | `requests.get()` en `def get_url(url)` síncrona interna, llamada con `await hass.async_add_executor_job(get_url, url)` — mismo patrón que hit 4 |
+| 6 | learning-at-home__hivemind | hivemind/p2p/p2p_daemon.py:440 | _read_stream | FP | La variable `requests` en este contexto es `asyncio.Queue(max_prefetch)` — no es el módulo `requests`. El detector tiene un FP por colisión de nombre de variable: `requests = asyncio.Queue(...)`, luego `request = await requests.get()` |
+| 7 | learning-at-home__hivemind | hivemind/p2p/p2p_daemon.py:477 | _handle_stream | FP | Mismo contexto que hit 6 — `requests` es una `asyncio.Queue`, no el módulo HTTP |
+| 8 | paulpierre__RasaGPT | app/rasa-credentials/main.py:65 | get_active_tunnels | TP | `requests.get()` directo en `async def get_active_tunnels()`, sin executor. Bug real. |
+| 9 | paulpierre__RasaGPT | app/rasa-credentials/main.py:78 | stop_tunnel | TP | `requests.delete()` directo en `async def stop_tunnel()`. Bug real. |
+| 10 | paulpierre__RasaGPT | app/rasa-credentials/main.py:118 | create_tunnel | TP | `requests.post()` directo en `async def create_tunnel()`. Bug real. |
+| 11 | pydantic__logfire | tests/otel_integrations/test_requests.py:41 | test_requests_instrumentation | FP | Test async que verifica instrumentación del módulo `requests` — `requests.get()` es el objeto bajo prueba (test de observabilidad). Uso legítimo en test. |
+| 12 | python-kasa__python-kasa | kasa/protocols/smartprotocol.py:299 | _execute_multiple_query | FP | La variable `requests` es un `dict` local (mapa de requests al protocolo KASA), no el módulo `requests`. `requests.get(method)` es `dict.get()` en un dict llamado `requests`. Colisión de nombre. |
+| 13 | raullenchai__Rapid-MLX | tests/evals/gsm8k/gsm8k_eval.py:136 | evaluate_with_server | EDGE | `requests.post()` en bucle de evaluación async — es un test/benchmark que llama a un servidor local; técnicamente bloquea el loop pero es un script de evaluación no de producción. Contexto borderline. |
+| 14 | wyeeeee__hajimi | app/utils/version.py:23 | check_version | TP | `requests.get()` directo en `async def check_version()`, sin executor. Bug real — bloquea el loop en cada check de versión. |
+
+### Resultado
+
+| Métrica | Valor |
+|---------|-------|
+| TP | 5 |
+| FP | 8 |
+| EDGE | 1 |
+| Precisión (TP/total sin EDGE) | 5/13 = 38% |
+| Precisión (TP/total con EDGE) | 5/14 = 36% |
+
+### Patrones de FP identificados
+
+1. **EXECUTOR_WRAPPER** — `requests.*()` dentro de `run_in_executor(None, lambda: ...)` o `async_add_executor_job()`. La llamada síncrona está correctamente delegada al pool de threads.
+   - Ejemplo: `await loop.run_in_executor(None, lambda: requests.post(...))`
+   - Repos afectados: 2 (xhs_ai_publisher, GPTDiscord) + 2 en Home Assistant (como inner def)
+
+2. **INNER_SYNC_FUNCTION_EXECUTOR** — `requests.*()` en una función `def` interna que luego se pasa a `executor_job`. El detector flagueó la llamada en el scope síncrono pero no detectó que se ejecutará en executor.
+   - Ejemplo: `def do_download(): requests.get(...)` → `await hass.async_add_executor_job(do_download)`
+   - Repos afectados: 1 (home-assistant/core, 2 instancias)
+
+3. **VARIABLE_NAME_COLLISION** — variable local llamada `requests` que no es el módulo HTTP (puede ser un dict, una Queue, etc.).
+   - Ejemplo: `requests = asyncio.Queue(max_prefetch)` → detector flagueó `requests.get()` como llamada HTTP
+   - Ejemplo: `requests = {}` (dict) → `requests.get(method)` es un dict lookup
+   - Repos afectados: 2 (hivemind, python-kasa)
+
+4. **TEST_SUBJECT** — test async que verifica el módulo `requests` como objeto bajo prueba para instrumentación.
+   - Repos afectados: 1 (pydantic/logfire)
+
+### Recomendación de Evidence Level
+
+**Mantener B. Precisión preocupante: 36-38%.** El problema principal es triple: (a) colisiones de nombre de variable (`requests` como nombre de dict/Queue), (b) `requests.*()` en funciones `def` síncronas internas que se pasan a executor, (c) test subjects. El detector necesita mejorar: verificar que `requests` sea realmente el módulo importado (no una variable local), y detectar el patrón `run_in_executor` en el contexto inmediato. Los 5 TP reales son genuinamente problemáticos. **FP rate alto (62%) requiere acción antes de considerar elevación a Evidence A.**

python_vibe_guard-0.12.2/pyvibe/_evidence/accepted/PYVIBE-003.md

@@ -0,0 +1,64 @@
+# PYVIBE-003 — asyncio.run() dentro de async def
+
+**Severidad:** CRITICAL  
+**Archivo:** `pyvibe/rules/asyncio_run.py`  
+**Patrón:** `asyncio.run(coro())` llamado dentro de `async def`
+
+## Datos objetivos
+
+| Métrica | 100 repos | 250 repos |
+|---------|-----------|-----------|
+| Repos afectados | 1/100 (1.0%) | 1/250 (0.4%) |
+| Total hits | 1 | 1 |
+| Estabilidad 100→250 | Alta (−0.6 pp) | |
+| Falsos positivos documentados | 0 | |
+
+## Repos representativos (sweep 250)
+
+- `piccolo-orm/piccolo` — 1 hit (único repo afectado en ambos sweeps)
+
+## Evidence Level: B
+
+- ✅ Validada en repos reales: 1 repo afectado confirmado en ambas muestras
+- ⏳ Documentación oficial o incidentes públicos: **PENDIENTE — requiere investigación manual**
+- ✅ Falsos positivos documentados en campo: 0
+
+## Nota
+
+Baja prevalencia (0.4% en 250 repos) pero el patrón es siempre incorrecto:
+`asyncio.run()` crea un nuevo event loop y falla si ya hay uno activo,
+lo que dentro de `async def` genera `RuntimeError: This event loop is already running`.
+
+---
+
+## Auditoría de Precisión (Sweep 250)
+
+**Muestra analizada:** 1 hit de 1 total (1 repo)
+**Metodología:** 100% audit (1 hit)
+
+### Clasificación hit-by-hit
+
+| # | Repo | File:Line | Function | Clasificación | Razón |
+|---|------|-----------|----------|---------------|-------|
+| 1 | piccolo-orm__piccolo | tests/table/test_batch.py:129 | test_batch | FP | Llamada dentro de un método de `unittest.TestCase` (`def test_batch`, no `async def`); el hit es en la línea donde el patrón AST lo detecta pero la función contenedora es síncrona — se usa `asyncio.run()` para ejecutar la corrutina desde un test síncrono, que es el uso correcto |
+
+**Nota:** La función `test_batch` es un método de `TestCase` (síncrono, no `async def`). El uso de `asyncio.run()` para ejecutar una corrutina desde código síncrono de test es el patrón idiomático correcto. El linter parece haber flagueado este caso porque la línea con `asyncio.run()` está dentro de un método de clase que hereda de `TestCase`, sin verificar si la función es `async def` o `def` regular.
+
+### Resultado
+
+| Métrica | Valor |
+|---------|-------|
+| TP | 0 |
+| FP | 1 |
+| EDGE | 0 |
+| Precisión (TP/total) | 0% |
+
+### Patrones de FP identificados
+
+1. **TEST_SYNC_METHOD** — `asyncio.run()` llamado desde método síncrono de `TestCase` para ejecutar una corrutina. Uso idiomático correcto.
+   - Ejemplo: `asyncio.run(self.run_batch(batch_size=batch_size), debug=True)`
+   - Repos afectados: 1 (piccolo-orm/piccolo)
+
+### Recomendación de Evidence Level
+
+**Revisar detección.** Con 1/1 FP la muestra es mínima, pero el FP indica una posible debilidad en la regla: si el detector no verifica que la función inmediata contenedora sea `async def`, va a flagear `asyncio.run()` en métodos síncronos que legítimamente lanzan corrutinas. Confirmar que `pyvibe/rules/asyncio_run.py` comprueba que el nodo padre directo es un `AsyncFunctionDef`, no solo cualquier `FunctionDef`. Si la regla ya lo verifica, este FP es un bug del detector a corregir. Mantener Evidence B hasta ampliar muestra.

python_vibe_guard-0.12.2/pyvibe/_evidence/accepted/PYVIBE-004.md

@@ -0,0 +1,93 @@
+# PYVIBE-004 — threading.Lock() en async def
+
+**Severidad:** CRITICAL  
+**Archivo:** `pyvibe/rules/threading_lock.py`  
+**Patrón:** `threading.Lock()` / `threading.RLock()` instanciado o usado dentro de `async def`
+
+## Datos objetivos
+
+| Métrica | 100 repos | 250 repos |
+|---------|-----------|-----------|
+| Repos afectados | 5/100 (5.0%) | 5/250 (2.0%) |
+| Total hits | 60 | 60 |
+| Estabilidad 100→250 | Alta (−3.0 pp) | |
+| Falsos positivos documentados | 0 | |
+
+## Repos representativos (sweep 250)
+
+- `agronholm/anyio` — 36 hits
+- `BeanieODM/beanie` — 11 hits
+- `home-assistant/core` — 8 hits
+- `IBM/mcp-context-forge` — 3 hits
+- `polarsource/polar` — 2 hits
+
+## Evidence Level: B
+
+- ✅ Validada en repos reales: 5 repos afectados; el total de hits (60) se mantiene igual en ambos sweeps, concentrado en los mismos repos
+- ⏳ Documentación oficial o incidentes públicos: **PENDIENTE — requiere investigación manual**
+- ✅ Falsos positivos documentados en campo: 0
+
+## Nota
+
+El total de hits es idéntico entre 100 y 250 repos (60), lo que indica que los 5 repos afectados ya estaban en el sweep de 100. Los 150 repos nuevos no añaden ningún hit.
+
+---
+
+## Auditoría de Precisión (Sweep 250)
+
+**Muestra analizada:** 14 hits de 60 totales (5 repos) — todos los repos tienen < 3 hits salvo anyio (36 hits, toma 3)
+**Metodología:** Muestra estratificada (max 3 por repo) — total 14 de 60 hits; anyio concentra 36/60
+
+### Clasificación hit-by-hit
+
+| # | Repo | File:Line | Function | Clasificación | Razón |
+|---|------|-----------|----------|---------------|-------|
+| 1 | BeanieODM__beanie | test_validation_on_save.py:70 | test_validate_on_save_dbref | FP | `lock = Lock(k=1)` — `Lock` aquí es un modelo de Beanie/MongoDB (clase ORM de la aplicación, no `threading.Lock`). Colisión de nombre de clase: el detector flagueó la instanciación de un documento ORM llamado `Lock`. |
+| 2 | BeanieODM__beanie | test_find.py:435 | test_fetch_links_with_chained_delete | FP | Mismo repo — `Lock` es un documento ORM de Beanie en los tests. Colisión de nombre. |
+| 3 | BeanieODM__beanie | test_find.py:511 | test_distinct_with_fetch_links | FP | Mismo repo — mismo patrón, `Lock` es modelo ORM. |
+| 4 | IBM__mcp-context-forge | test_cache_invalidation_subscriber.py:125 | test_process_tool_lookup_name_invalidation | FP | `mock_tool_lookup._lock = threading.Lock()` — se asigna un `threading.Lock` a un objeto mock en un test. En el test no hay `async def` que lo use como mutex — se está configurando un atributo del mock para que el SUT pueda acceder a él. El `threading.Lock()` aquí es un setup de datos de test, no un mutex que bloquee el event loop. FP contextual. |
+| 5 | IBM__mcp-context-forge | test_cache_invalidation_subscriber.py:143 | test_process_tool_lookup_gateway_invalidation | FP | Mismo repo y mismo patrón — `threading.Lock()` en atributo de mock. |
+| 6 | IBM__mcp-context-forge | test_cache_invalidation_subscriber.py:161 | test_process_admin_invalidation | FP | Mismo repo — `threading.Lock()` en atributo de mock de admin cache. |
+| 7 | agronholm__anyio | src/anyio/functools.py:173 | __call__ | EDGE | `Lock(fast_acquire=not self._always_checkpoint)` — este es `anyio.Lock`, no `threading.Lock`. Si el detector flagueó esto por el nombre `Lock`, es una colisión de nombre. anyio.Lock es el mutex async correcto. |
+| 8 | agronholm__anyio | src/anyio/functools.py:183 | __call__ | EDGE | Mismo contexto — `Lock(fast_acquire=...)` es `anyio.Lock` en el memoize cache de anyio. Uso correcto de Lock async. |
+| 9 | agronholm__anyio | tests/test_synchronization.py:38 | test_contextmanager | FP | Test de anyio — verificación de comportamiento del Lock async de anyio. En test de la librería de sync. |
+| 10 | home-assistant__core | homeassistant/util/async_.py:105 | gather_with_limited_concurrency | FP | `semaphore = Semaphore(limit)` — `Semaphore` es `asyncio.Semaphore`, no `threading.Semaphore`. Incluso si fuera `threading.Lock`, la función no usa la primitiva directamente como mutex bloqueante sino para limitar concurrencia a través de `async with semaphore:`. FP si el detector flagueó el Semaphore como Lock threading. |
+| 11 | home-assistant__core | tests/components/backblaze_b2/test_backup.py:911 | test_metadata_downloads_are_sequential | FP | Test de HA — probablemente `threading.Lock()` en mock o fixture de test. |
+| 12 | home-assistant__core | tests/components/homekit/test_type_locks.py:44 | test_lock_unlock | FP | El nombre del archivo ya indica que se testea la integración "locks" de HomeKit — `Lock` en este contexto es un dispositivo HomeKit, no `threading.Lock`. Colisión de dominio. |
+| 13 | polarsource__polar | server/polar/locker.py:63 | lock | FP | `Lock(self.redis, self._get_key(name), ...)` — este `Lock` es `redis.asyncio.lock.Lock` (importado en la línea 7 del archivo). Es un distributed lock async sobre Redis, no `threading.Lock`. |
+| 14 | polarsource__polar | server/polar/locker.py:122 | is_locked | FP | Mismo repo — `Lock(self.redis, ...)` es `redis.asyncio.lock.Lock`. Correcto. |
+
+### Resultado
+
+| Métrica | Valor |
+|---------|-------|
+| TP | 0 |
+| FP | 12 |
+| EDGE | 2 |
+| Precisión (TP/total sin EDGE) | 0/12 = 0% |
+| Precisión (TP+EDGE/total) | 2/14 = 14% |
+
+### Patrones de FP identificados
+
+1. **DOMAIN_CLASS_NAME_COLLISION** — clase de dominio llamada `Lock` (ORM model, HomeKit device) que el detector confundió con `threading.Lock`.
+   - Ejemplo: `lock = Lock(k=1)` donde `Lock` es un documento de Beanie MongoDB
+   - Repos afectados: 1 (BeanieODM/beanie, 3 instancias)
+
+2. **ASYNC_LOCK_SAME_NAME** — `anyio.Lock`, `redis.asyncio.lock.Lock` importados y usados correctamente dentro de `async def` — son primitivas async válidas, no `threading.Lock`.
+   - Ejemplo: `from redis.asyncio.lock import Lock; ... Lock(self.redis, ...)`
+   - Repos afectados: 2 (polarsource/polar, agronholm/anyio)
+
+3. **MOCK_ATTRIBUTE_SETUP** — `threading.Lock()` asignado como atributo de un objeto mock en test (`mock._lock = threading.Lock()`). El lock no se adquiere en la función async bajo prueba — se pasa como dato al SUT que lo usa internamente.
+   - Repos afectados: 1 (IBM/mcp-context-forge, 3 instancias)
+
+4. **TEST_INTEGRATION_DOMAIN** — tests de integraciones HomeKit donde `Lock` es un tipo de dispositivo de automatización del hogar.
+   - Repos afectados: 1 (home-assistant/core)
+
+### Recomendación de Evidence Level
+
+**ALERTA: Precisión 0-14% — regla requiere revisión profunda del detector.** Todos los hits en la muestra son falsos positivos. El problema es sistemático:
+- El detector no verifica que `Lock` sea específicamente `threading.Lock` (verificando el módulo de origen del símbolo)
+- Flagueó `anyio.Lock`, `redis.asyncio.Lock`, clases ORM llamadas `Lock`, y mocks
+- Para reparar: el detector debe verificar que el import de `Lock` sea `from threading import Lock` o `import threading; threading.Lock()`, no cualquier clase con nombre `Lock`
+- Los 36 hits de anyio probablemente son todos FPs del mismo tipo (anyio.Lock siendo confundido con threading.Lock)
+- **Recomendación: degradar a 🔵 Limited Scope hasta que el detector se corrija.** Con 0% de precisión en la muestra, la regla genera más ruido que valor.