feat: AR-House initial commit
This commit is contained in:
@@ -0,0 +1,125 @@
|
||||
# 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)_
|
||||
Reference in New Issue
Block a user