app.loadApiJson (lo que usa comfyui_load_workflow_ui) reconstruye el grafo pero
no llama a app.clean(), por lo que no resetea el store app.nodeOutputs ni los
previews de los nodos. Cuando un workflow nuevo reusa un node_id existente en el
store, el preview cacheado del workflow anterior se re-pinta sobre el nodo nuevo
(visto: imagen 3D pegada bajo un CheckpointLoaderSimple/SaveGLB).
- Nueva funcion comfyui_clear_node_outputs_ui: limpieza no destructiva del store
app.nodeOutputs + node.imgs/images, sin tocar la topologia del grafo.
- comfyui_load_workflow_ui v1.1.0: anade clear_outputs=True (default) que invoca
la limpieza antes de loadApiJson, replicando la garantia de loadGraphData.
Reproducido y verificado en la UI real (CDP 9222) con evidencia antes/despues.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El monitor de captación scrapeaba Workana sobre el navegador personal del
usuario (chromium-personal, CDP 9222), interfiriendo con su navegación. El
scraping CDP debe correr siempre en un perfil headless dedicado.
- Nuevo pipeline monitor_freelance_projects_headless: levanta un Chromium
headless aislado con perfil dedicado (~/.config/fn_scrape_chrome, CDP 9334)
vía systemd-run, ejecuta monitor_freelance_projects contra ese puerto y
cierra la instancia al terminar (finally). Reutiliza el patrón de lifecycle
de ingest_market_trends_headless. Reutiliza un CDP vivo si el puerto ya
responde (no cierra lo ajeno).
- scrape_workana_projects y monitor_freelance_projects: default de `port`
cambiado de 9222 (chromium-personal) a 9334 (perfil dedicado). Default seguro:
correr a pelo sin Chrome en 9334 falla limpio, no contamina el 9222 personal.
Verificado: el wrapper arranca headless en 9334, scrapea 8 proyectos reales de
Workana, cierra la instancia (9334 muerto, sin proceso colgado) y deja el 9222
personal intacto.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Añade fetch_http_fingerprint_cdp_py_browser (domain browser): recoge el HTML
renderizado tras ejecutar JavaScript usando un Chrome remoto via CDP, componiendo
cdp_open_url_and_wait + cdp_eval. Devuelve la misma estructura que el fetch
estático para que detect_web_tech lo consuma sin cambios.
Integra use_cdp en el pipeline fingerprint_web_stack (v1.1.0): combina los headers
reales del fetch estático con el HTML post-JS del CDP. Detecta frameworks de SPA
(React/Vue/Angular/Next) que el fetch estático no ve porque montan el DOM en
runtime. Si no hay Chrome en cdp_port, degrada al fetch estático con un warning
(no rompe). cdp_port=9333 (Chrome aislado) recomendado para terceros, 9222 diario.
Verificado en vivo (Chrome 9333): sobre una SPA cuyo marcador de framework solo
aparece tras ejecutar JS, el estático detecta solo nginx; con use_cdp=True detecta
además Next.js, React y Node.js.
Tests: 48 verdes (error path sin Chrome + happy path mockeado + degradación).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
egutierrez