`unresolved_links` table is empty after `engraph index` despite known broken wikilinks

[jdubdevs]

Summary

After running engraph index <vault> on a 1,646-file Obsidian vault, the unresolved_links SQLite table is empty (0 rows). External verification (hand-rolled wikilink resolution by walking the filesystem) shows 74 distinct broken wikilink targets across 118 occurrences. Expected: those 118 broken-link instances should appear as rows in unresolved_links.

Environment

• engraph 1.6.1 (installed via brew install devwhodevs/tap/engraph)
• macOS 26 / Apple Silicon
• Vault: 1,646 markdown files
• Index command: engraph index <vault> (default flags)
• Config: stock ~/.engraph/config.toml (intelligence=true, no special flags)
• engraph.db size: ~392 MB after index

Reproduction

# After a successful `engraph index <vault>`:
sqlite3 ~/.engraph/engraph.db "SELECT COUNT(*) FROM unresolved_links;"
# Returns: 0

External verification — extract wikilinks via filesystem walk, resolve against vault file index + basename index. Result in my case: 19,515 wikilinks total across 1,646 files; 74 distinct broken targets, 118 occurrences. None of those 118 broken-link instances are stored in unresolved_links.

Expected behavior

unresolved_links should contain rows for each broken-wikilink occurrence after indexing. The table schema exists and is properly indexed:

CREATE TABLE unresolved_links (
    id          INTEGER PRIMARY KEY,
    source_file TEXT NOT NULL,
    target      TEXT NOT NULL,
    created_at  TEXT NOT NULL DEFAULT (datetime('now')),
    UNIQUE(source_file, target)
);
CREATE INDEX idx_unresolved_source ON unresolved_links(source_file);

— suggesting the table was designed to be populated. The indexer's wikilink-extraction code path doesn't appear to call into it.

Actual behavior

Table remains at 0 rows regardless of vault state or --rebuild flag.

Impact

Any downstream tooling that surfaces broken wikilinks via unresolved_links produces false-confidence ("0 broken links" reported, actually many). Including consumers of engraph context health if it uses this table.

Suggested investigation

When the indexer extracts wikilinks from a source file, does the resolution step (file-index lookup + basename-index fallback) write unresolved targets into unresolved_links? Looks like that write step may have been omitted or sits behind a feature flag.

I'm planning to fork + investigate the source for a fix. Happy to send a PR if the cause looks tractable.