# IDEAS_BACKLOG.md

**Propósito**: lista corta de items concretos pendientes que no están en
`PHASE_35_PLAN.md`. Cosas que se descubrieron como gaps pero NO bloquean el flujo
principal. Si tenés tiempo, agarrá uno desde acá.

**Convención**:
- 🔴 P1 = afecta funcionalidad core hoy
- 🟡 P2 = mejora cobertura/UX significativa
- 🟢 P3 = nice to have

Cada item: contexto, costo en horas, blockers, criterio "done".

---

## 🟡 1. 26 FL counties que NO usan realauction.com

**Contexto**: probe a `https://www.realauction.com/clients` confirmó que 41 de los 67 condados FL usan realforeclose.com. Los 26 restantes están en otras plataformas (parking pages en realauction = no client). Mayormente counties pequeños/rurales pero también algunos importantes como Monroe (Keys), Collier (Naples), Okaloosa (Destin), St. Johns (St. Augustine).

**Counties pendientes**:
Bradford, Collier, Columbia, DeSoto, Dixie, Franklin, Gadsden, Glades, Hamilton,
Hardee, Hendry, Hernando, Highlands, Holmes, Jefferson, Lafayette, Levy, Liberty,
Madison, Monroe, Okaloosa, St. Johns, Sumter, Taylor, Union, Wakulla.

**Plataformas a investigar**: Govease, ClerkAuction.com, ServiceLink Auction, sistemas in-house del clerk.

**Esfuerzo**: ~30 min por county para identificar plataforma + 2-3h por plataforma nueva para integrar engine.
**Done cuando**: top 5 prioritarios (Monroe, Collier, Okaloosa, St. Johns, Hernando) tienen scraper funcional.

---

## 🟢 2. Property Researcher agent — prompt tuning

**Contexto**: framework `property_researcher.py` + `agent_tools.py` están construidos. El test con Wake County NC mostró que qwen2.5:14b sigue la estrategia inicial bien (lookup_portal → web_search → fetch_url) pero se queda atrapado en loops de fetch sin llamar `extract_with_local_llm` ni `finish()`. 10/10 iteraciones sin terminar limpio en el test.

**Posibles fixes** (probar en orden):
1. Mejor system prompt con flow paso-a-paso explícito + few-shot examples
2. Force `extract_with_local_llm` después de cada `fetch_url` exitoso (regla en prompt)
3. Cambiar al modelo Coordinator (qwen2.5:32b, 19GB) — más reasoning power
4. Implementar "judge" — un segundo LLM evalúa si la iteración avanzó, si no → corrige el plan

**Esfuerzo**: 2-4h iteraciones de prompt + tests.
**Done cuando**: agente completa research de 1 deal NC con `finish()` + ≥2 portales descubiertos guardados en `portal_directory.json`.

---

## 🟢 3. Firecrawl `/extract` como fallback para counties non-FL

**Contexto**: alternativa al PropertyResearcher agent. Firecrawl `/extract` toma una URL + JSON schema y devuelve data extraída via su LLM. 4 credits por deal completo ≈ $0.004. Buena solución para los counties non-FL donde no tenemos scraper.

**Pipeline propuesto**:
```python
def fetch_deal_anywhere(address, county, state):
    # 1 cred: descubrir portal
    portal = firecrawl_search(f"property appraiser {county} county {state}")
    # 1 cred: scrape PA
    pa_data = firecrawl_extract(portal_url, schema=PA_SCHEMA)
    # 1 cred: descubrir court
    court_portal = firecrawl_search(f"court records {county} {state}")
    # 1 cred: scrape court
    court_data = firecrawl_extract(court_portal, schema=COURT_SCHEMA)
    return pa_data | court_data  # ~4 credits
```

**Budget impact**: 4 cred × 250 deals/mes = 1000 cred, justo en límite. Solo activar para counties non-FL.

**Esfuerzo**: ~2h implementación + 1h testing.
**Done cuando**: deal de Virginia (Fairfax) procesado correctamente con verdict + plaintiff + owner extraídos.

---

## 🟢 4. PA fetchers extendidos (Duval, Miami-Dade street photos)

**Contexto**: solo Broward PA tiene foto exterior real funcional vía `bcpa.net`. Miami-Dade y Duval solo exponen aerial map + sketch (verificado). Algunos counties más pequeños podrían tener street photos.

**Counties a probar**:
- Hillsborough: probablemente sí (high-volume)
- Orange: probablemente sí
- Pinellas, Lee, Brevard, Volusia: probable
- Counties más pequeños: usualmente sketch-only

**Esfuerzo**: ~20 min por county para probe + 30 min para integrar al `pa_photo_lookup.py`.
**Done cuando**: al menos 3 counties más con foto exterior funcional + entries en `_FETCHERS` dict.

---

## 🟢 5. HUD PropertyDetails photo extraction

**Contexto**: HUD Homestore search-list page no incluye foto. La página individual `/PropertyDetails?caseNumber=X` SÍ podría tener foto (no investigado a fondo aún). Probe inicial mostró Cloudinary placeholders `NoImage.jpg` para todos.

**Pendiente verificar**:
- ¿Todos los HUD listings son NoImage o solo los que vi?
- ¿Hay listings que SÍ tienen foto del HUD photographer program?
- ¿Vale la pena el per-deal fetch (39 deals × 1 Playwright call ≈ 5 min)?

**Esfuerzo**: ~1h probe + decisión + posible integración.
**Done cuando**: documentado si HUD tiene fotos reales para algún subset, o confirmado que es siempre NoImage.

---

## 🟡 6. Cards UX — feedback loop on Pre-screening result freshness

**Contexto**: pre-screening result se persiste en `st.session_state[f"prescreen_result_{deal_id}"]`. Si re-corrés pre-screening, sobrescribe. Pero si el deal data cambió (re-scrape), la card sigue mostrando el result viejo.

**Pendiente**:
- Mostrar `run_at` timestamp en la pre-screening result box
- Botón "Re-correr pre-screening" cuando hay un result viejo
- Invalidar automáticamente si el deal fue re-scrapeado post-pre-screening

**Esfuerzo**: ~1h.
**Done cuando**: card muestra "Pre-screening generado hace 2h" + botón Re-run visible.

---

## Cómo trabajar este backlog

1. Cuando arranques nueva sesión, leé este archivo + `PHASE_35_PLAN.md`
2. Si Phase 3.5 está en curso, prioridad es esa
3. Si Phase 3.5 está bloqueada o terminada, agarrá item P1/P2 de acá
4. Marcar como ✅ acá cuando se completa + linkear commit hash
5. Mover a tabla "Done" al final del archivo

## Done (historial)

_(vacío — agregar conforme completemos items)_