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):

Mejor system prompt con flow paso-a-paso explícito + few-shot examples
Force extract_with_local_llm después de cada fetch_url exitoso (regla en prompt)
Cambiar al modelo Coordinator (qwen2.5:32b, 19GB) — más reasoning power
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:

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

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

Done (historial)

(vacío — agregar conforme completemos items)

5.8 KiB Raw Blame History Unescape Escape