Vector index resolves against working directory instead of install location

The dashboard reported a skill count that disagreed with the authoritative total. The number changed depending on which directory the process was started from.

What the index actually is

The skill count is not a directory scan. It comes from a prebuilt index file, and that file's directory resolves against the process working directory. The same installed build reports different totals depending on where it was started.

The index is already architected as installation-global. Per-project enable and disable state is applied at read time and never enters the index. The writer takes no project parameter. Only the location is per-project, and that mismatch is the defect.

Why the wrong number was not extra files

The stale index reported 141 skills. The canonical count is 130. Anyone would assume eleven extra skill files exist somewhere.

The stale index was missing 18 canonical skills and carried 29 duplicate records. Minus 18 plus 29 equals plus 11. That is arithmetic coincidence, not a set of stray files. Hunting for eleven extra skill files would have found nothing.

Both failure modes

A stale index shows a wrong number, which invites investigation. An absent index shows zero skills and reads as a broken installation. The absent case is quieter and harder to diagnose.

Eleven such index directories exist across the machine, in three distinct generations, several inside backup folders. The artifact is being copied around as though it were project data.

The fix

Change the resolution so the index lives in a single per-user location instead of resolving against the process working directory. Add an explicit directory creation call in the index writer rather than relying on a side effect of the other indexing backend.

Existing index directories will be orphaned rather than migrated or deleted. Migrating one would promote whatever staleness it carries to canonical status. Deleting files inside backup folders is not acceptable for a path fix.

The index writer and every reader obtain the directory from a single resolved path property, so changing that property moves them together with no divergence window.

Verification technique that worked

Commit history settled a question code reading could not. A Settings field that looked like an unfinished stub turned out to be a deliberate mirror of a backend constant. It was written six hours after that constant was set, matched it exactly, and was orphaned eight days later when the constant changed and the display did not. Reading the code alone supported the wrong conclusion.