bug: per-repo .gortex.yaml changes require a full daemon restart — `daemon reload` drops the workspace-config cache but nothing re-reads it; re-`track` short-circuits

[tiendungdev]

Env: gortex daemon vv0.61.0+58dc39b, Windows 11 Pro (10.0.26200), one tracked repo (~2.6k files, Go+TS+SQL+MD), MCP facade v1.

Repro

1. Repo is tracked and indexed. Edit <repo>/.gortex.yaml: add exclude: entries for two already-indexed directories and a guards.rules block.
2. MCP workspace_admin {operation:"reindex"} → walk still admits the excluded dirs (scoped reindex over them reports file_count: 309), and change {operation:"guards"} still answers no guard rules configured. Expected if the config were live: ~0 files walked, rules evaluated.
3. Run gortex daemon reload, then reindex again → same stale behavior.
4. MCP workspace_admin {operation:"track", path:<repo>} → returns repository already tracked, config still not re-read.
5. Full daemon restart → config finally applies: full walk drops 2613 → 2305 files, guards evaluate (a positive test fires a violation).

Analysis (from reading internal/config/manager.go)

• ConfigManager.Reload() re-reads the global config and drops the workspace cache, with the comment "individual .gortex.yaml files are re-read lazily on demand".
• But the only writer of that cache is LoadWorkspaceConfig, which is invoked at track/boot time. The indexer/EffectiveExclude path never calls it for an already-tracked prefix, so "lazily on demand" never happens — after a reload the repo effectively runs with no workspace config (not even the old one) until restart.
• track on an existing repo short-circuits before reloading the workspace config.

Expected

Either Reload() (or the next reindex after it) re-runs LoadWorkspaceConfig for each tracked repo, or re-track refreshes it. If restart-only is intended, docs should say so — today the reload path silently leaves the repo config-less.

[tiendungdev]

One more occurrence with a different trigger — the config-less state can also arise at boot, not just after reload:

Timeline (same machine/repo as the report):

1. Daemon restart → workspace config loaded correctly (guards from .gortex.yaml verified firing, excludes applied to the walk).
2. Later, another daemon restart happened while a long gortex init was running concurrently in the same repo (init had the store busy for ~20min).
3. On the post-restart daemon, change {operation:"guards"} now answers no guard rules configured again, and since guards/exclude ride the same per-repo Config loaded by LoadWorkspaceConfig, the whole workspace config is effectively absent — while the .gortex.yaml on disk is unchanged.

So whatever path failed here (boot racing init on the global config / store, or a post-boot cache drop triggered by init's track/registration), the daemon ended up running config-less with no log-visible hint at the MCP surface, and — per the original report — nothing short of another restart re-reads the file. A deterministic re-read path (reload → LoadWorkspaceConfig per tracked repo, or lazy re-read on cache miss) would fix both shapes.

[tiendungdev]

Correction/strengthening of my previous comment: the config-less boot reproduces with no concurrent init at all — a plain daemon stop / daemon start --detach with nothing else running came up config-less again (2/2 recent boots; an earlier boot on the same setup loaded the config fine).

New detail that widens the blast radius: on these config-less boots the .gitignore layer is dead too, not just the workspace config. The boot reindex walked ~7.8k files = exactly builtin-only admission (tracked 2.7k + gitignored tmp/ 3.8k + gitignored graphify-out/ 1.3k), where a healthy boot walks 2.3k. That matches ConfigManager structure: workspacePaths (which EffectiveExclude needs to locate the repo's .gitignore) is only populated by LoadWorkspaceConfig — so whatever skips that call on boot kills gitignore-respecting behaviour along with guards/excludes, and the store absorbs every gitignored tree (+115k nodes here, including a full vendored copy of another repo that happened to sit under tmp/).

So the failure isn't only "changes need a restart" — some boots (same disk state, same config files) simply never run the per-repo config/registration step, silently. Happy to run diagnostics if you can point at what to capture from a bad boot.

[tiendungdev]

Sharpest datapoint yet, from a fresh store rebuilt today (untrack → wipe store dir → track via CLI): on the very same daemon runtime,

• the indexer path clearly HAS the workspace config — the walk admitted exactly the configured file set (2,305 files; docs/codemap/ and lib/, which are git-tracked and only excluded by .gortex.yaml, are absent from the fresh index), while
• change {operation:"guards"} still answers no guard rules configured (tried with both bare and repo-prefixed symbol ids, across two subsequent boots with tracked_repos: 1).

So this isn't only "config sometimes fails to load at boot" — the workspace config can be loaded and honoured by the walk yet never become visible to the guards lookup on the same daemon. Looks like two different resolution paths into ConfigManager (per-path vs per-prefix?), which would also explain the intermittent all-or-nothing behaviour reported earlier.