`wiki/` is only ever written by the explicit `export wiki` subcommand, yet `AGENTS.md` tells agents to navigate it instead of reading source

[Job28703]

The wiring

to_wiki has exactly one call site:

• graphify/cli.py:2188-2199 — inside the export wiki subcommand.

It is not reached from any other path:

• graphify/watch.py contains no reference to wiki at all.
• graphify update does not touch wiki/.
• The post-commit/rebuild hook path does not touch wiki/.

So once graphify-out/wiki/ exists, it is frozen until someone manually re-runs graphify export wiki.

The instruction

Meanwhile the always-loaded agent instructions state it unconditionally. From the repo's own AGENTS.md:

• If graphify-out/wiki/index.md exists, navigate it instead of reading raw files

The same unconditional sentence appears in graphify/always_on/agents-md.md and graphify/always_on/antigravity-rules.md (the latter carries trigger: always_on).

Why this is inconsistent rather than just unfortunate

graph.json is handled carefully — cli.py:496-512 gates on mtime plus a needs_update sentinel, and 0.9.19 went further by softening the PreToolUse hook to a non-mandatory nudge when the graph is stale for the target file. That is a good design. wiki/ gets none of it, while carrying a stronger instruction ("instead of reading raw files").

Two signals suggest this is an oversight rather than a decision:

1. graphify/always_on/vscode-instructions.md does include an escape hatch — "…or the graph is missing or stale" — but antigravity-rules.md and AGENTS.md do not. Users get different protection depending on which assistant they installed.
2. Everything else in the codebase treats staleness as a first-class concern (_cleanup_stale_ast_entries, the #1939 salt-keyed cache miss, the #1908 excluded-but-alive row drop, the incremental re-extract logic).

Practical impact

An agent following the instruction answers architecture questions from a wiki that may be months out of date, with no staleness signal anywhere in the loop — the failure is silent and looks like a confident correct answer.

Suggested fix (either is fine)

• Wire to_wiki into the update/watch/hook rebuild paths (it is AST-derived, so no API cost), or
• Add the same staleness condition to AGENTS.md and the always_on/ variants that vscode-instructions.md already has, and have the wiki index record the build stamp it was generated from.

How this was found

Static read of cli.py, watch.py, wiki.py, AGENTS.md, and graphify/always_on/*. Call-site enumeration by grep across graphify/. No runtime reproduction.

[Job28703]

Opened #2024 with a docs-only fix: extends the existing PreToolUse staleness check (already used for graph.json vs. source files) to also compare wiki/index.md's mtime against graph.json's, and nudges back to source/graphify query when wiki is the older of the two. Also updated AGENTS.md and the always_on/ prose variants that told agents to trust the wiki unconditionally. Wiring to_wiki into update/watch itself (the other option I named above) is left as a separate, bigger change if that's preferred instead.