9042110ea2
Cinco issues que componen el plan: - 0026: sistema de jobs (infra, contrato wire) - 0027: tipo Webpage + cache de documentos - 0028: enricher fetch_webpage (MVP end-to-end) - 0028b: enrichers extract_domain / extract_links / extract_text_entities - 0029: variantes CDP (Chrome headless, screenshot) - 0030: macro "Deep enrich" + expand_domain Tambien anade los issues previos 0012-0025 que estaban untracked. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1.5 KiB
1.5 KiB
id, title, status, priority, created, depends_on
| id | title | status | priority | created | depends_on | |
|---|---|---|---|---|---|---|
| 0025 | Sync bidireccional con vault Obsidian / markdown | pending | low | 2026-05-01 |
|
Objetivo
Espejar el grafo activo a un vault de markdown (estilo Obsidian) en
projects/osint_graph/vaults/<name>/. Cada entidad = una nota; cada
relacion = un wikilink. El usuario puede navegar el grafo desde Obsidian
y editar campos alli; los cambios vuelven al grafo.
Encaja con vaults/ ya conceptualizados en el registry.
Alcance
- Watcher de filesystem + serializer/parser de notas con frontmatter YAML para los campos del entity_type.
- Plantilla por entity_type configurable (apoyandose en el exporter Markdown de 0024).
- Resolucion de conflictos: timestamp + merge campo a campo; preferencia configurable (vault wins / db wins / prompt).
- Modo unidireccional inicial (graph -> vault) si la ida y vuelta es mucho trabajo. v2 anade sync de vuelta.
Decisiones
- Sync continuo o on-demand (boton "Sync now")? Empezar on-demand. El watcher se anade en una segunda fase.
- Detectar cambios externos via
mtime+ checksum. - Wikilinks usan ids del registry, no nombres (estables ante renames).
Definicion de hecho
- Boton "Sync to vault" genera N notas con frontmatter correcto y wikilinks navegables en Obsidian.
- Editar un campo en la nota y "Sync from vault" actualiza la entidad en operations.db.
- No se pierden datos cuando hay edicion concurrente en ambos lados (resolucion de conflicto explicita).