egutierrez
ee0d26ce2d
Cada enricher con `lang: python` y `uses_functions` no vacio ahora
puede empaquetar las funciones del registry que necesita en
`<enricher>/_vendored/`. El run.py importa de ahi en lugar de
`<registry_root>/python/functions/`, lo que hace al binario
distribuible sin dependencia de un fn_registry montado.
Cambios:
1. tools/vendor_enricher_python.sh
- Lee `uses_functions` del manifest (filtrando IDs `*_py_*`).
- Resuelve `file_path` desde registry.db.
- Copia recursivamente con expansion transitiva: si un fichero
vendorizado importa siblings del mismo dominio, los siblings
tambien se copian (resuelve el caso `extract_iocs.py` que
importa 7 modulos hermanos).
- Genera `.vendor.lock` con `<id> <sha256> <src_path>` por
funcion declarada para auditoria.
- Idempotente — si todos los hashes coinciden, no rehace nada.
2. Manifests actualizados con `uses_functions`:
- fetch_webpage: normalize_url + html_to_markdown
- extract_links: extract_urls
- extract_text_entities: extract_iocs
3. run.py de los 3 enrichers afectados: importan de `_vendored/`
si existe, fallback a `<registry_root>/python/functions/` en
modo dev (mantiene los tests pytest funcionando).
4. app.md: anade `cryptography` a python_runtime_deps porque el
blob `cybersecurity.cybersecurity` lo importa al top.
5. Tests:
- test_vendor_script.py — 6 tests del script: layout correcto,
transitive siblings, lock con SHA256, idempotencia, modulos
importables en aislamiento.
- 16 tests de enrichers existentes pasan via vendoring (no usan
registry_root porque _vendored/ tiene prioridad).
6. Issue 0033b movido a issues/completed/.
Tests: 32/32 verde (16 enrichers + 6 dispatcher + 4 runtime + 6
vendor).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
49 lines
1.8 KiB
Markdown
49 lines
1.8 KiB
Markdown
---
|
|
id: 0001
|
|
title: Chat con Claude sobre el grafo
|
|
status: completed
|
|
priority: high
|
|
created: 2026-04-30
|
|
---
|
|
|
|
## Objetivo
|
|
|
|
Panel "Chat" dentro de graph_explorer que permita conversar con Claude
|
|
(Anthropic API) usando el grafo activo como contexto. El agente debe poder:
|
|
|
|
- Leer el grafo (entidades, relaciones, metadata) via tool-use sobre operations.db.
|
|
- Responder preguntas tipo: "muestrame los nodos relacionados con X", "que
|
|
patrones ves en estas conexiones", "que falta investigar".
|
|
- Proponer mutaciones (crear nodo, etiquetar relacion) que el usuario aprueba
|
|
con un click antes de aplicarse.
|
|
|
|
## Alcance tecnico
|
|
|
|
- Cliente HTTP minimo (libcurl o WinHTTP) → POST a `https://api.anthropic.com/v1/messages`.
|
|
- Modelo por defecto: `claude-sonnet-4-6` (revisar al implementar).
|
|
- API key desde env var `ANTHROPIC_API_KEY` o `~/.fn_anthropic_key`.
|
|
- Tool-use: definir tools `query_entities`, `query_relations`, `propose_node`,
|
|
`propose_relation`. Las "propose_*" no mutan: insertan en una cola que el
|
|
usuario revisa antes de aplicar.
|
|
- Estado de conversacion en memoria (lista de messages). Persistencia opcional
|
|
en `graph_explorer.db` tabla `chat_sessions`.
|
|
- Streaming SSE para feedback en vivo (puede dejarse para v2 — primer hit
|
|
bloqueante esta bien).
|
|
|
|
## Decisiones a tomar
|
|
|
|
- Renderizado de markdown en ImGui (TextWrapped basico vs lib externa).
|
|
- Threading: bloqueante en hilo aparte → cola de mensajes → main thread lee.
|
|
|
|
## Trabajo previo
|
|
|
|
Ya existe en el registry `python/functions/agents/anthropic_chat_py_agents.py`
|
|
para inspiracion (usa el SDK Python). En C++ usaremos HTTP directo — sin SDK.
|
|
|
|
## Definicion de hecho
|
|
|
|
- Panel "Chat" dockeable.
|
|
- Conversacion con tool-use sobre operations.db funciona.
|
|
- Las mutaciones propuestas por el agente se confirman desde la UI antes de
|
|
llegar a la BD.
|