What
lore serve never reports which investigation tools are unconfigured. lore investigate does:
note: running without metrics (query_metrics), logs (query_logs), knowledge catalog (kb_search, instant recall) — pass --metrics-url/--logs-url or a --config to enable them
That line is emitted in internal/app/investigate_cmd.go (the CLI path only). serve has no equivalent, so an in-cluster install that is missing evidence backends looks identical in the logs to one that has them all.
Why it matters
serve already announces, at Info, everything it turned on — the outcome ledger, the rate limit, the coalescer, the incident debounce, cancel-on-resolve, the gitops watcher, the re-investigate poller. It says nothing about what it did not turn on. The asymmetry is the problem: the startup log reads as a complete picture of the agent's capabilities, and it isn't one.
Concretely, the minimal Helm profile wires no metrics.url and no logs.url, so query_metrics and query_logs are never registered and the loop runs on Kubernetes state plus the GitOps diff. That is a legitimate configuration — but the operator gets no signal, and "the investigations feel shallow" has no breadcrumb leading to "you never wired metrics". The minimal profile comments now say so, which is a documentation fix papering over a runtime silence.
Suggested shape
disabledTools(cfg *config.Config) []string in internal/app/investigate_cmd.go:98 is already a pure function over config, in the same package serve lives in, and it deliberately reuses CatalogConfigured so the notice cannot drift from the real tool-wiring condition. It should be directly reusable.
Something like, near the other startup Info lines in serve.go:
if off := disabledTools(cfg); len(off) > 0 {
log.Info("running without", "tools", off)
}Structured rather than the CLI's prose line, to match the surrounding log.Info("… enabled", …) calls.
Open questions
- Level. Info matches the existing startup pattern. Warn would be louder but fires on every boot of a deliberately-minimal install, which is how warnings get tuned out.
- Should it fire at all when under-configuration is intentional? Argument for yes: the log is exactly where someone looks when investigations seem thin, and an Info line costs nothing. Argument for no: it reports the absence of things the operator chose not to configure, on every restart.
- Scope.
disabledTools currently covers metrics, logs and the catalog. Network flows, cloud and the forge are also silently absent when unset — worth deciding whether this notice is "the evidence backends" or "everything optional".
Not urgent
Nothing is broken; this is a discoverability gap. Filed rather than folded into the profile-docs PRs because the level/scope questions above deserve a decision rather than an implementation smuggled into a docs change.
What
lore servenever reports which investigation tools are unconfigured.lore investigatedoes:That line is emitted in
internal/app/investigate_cmd.go(the CLI path only).servehas no equivalent, so an in-cluster install that is missing evidence backends looks identical in the logs to one that has them all.Why it matters
servealready announces, at Info, everything it turned on — the outcome ledger, the rate limit, the coalescer, the incident debounce, cancel-on-resolve, the gitops watcher, the re-investigate poller. It says nothing about what it did not turn on. The asymmetry is the problem: the startup log reads as a complete picture of the agent's capabilities, and it isn't one.Concretely, the
minimalHelm profile wires nometrics.urland nologs.url, soquery_metricsandquery_logsare never registered and the loop runs on Kubernetes state plus the GitOps diff. That is a legitimate configuration — but the operator gets no signal, and "the investigations feel shallow" has no breadcrumb leading to "you never wired metrics". Theminimalprofile comments now say so, which is a documentation fix papering over a runtime silence.Suggested shape
disabledTools(cfg *config.Config) []stringininternal/app/investigate_cmd.go:98is already a pure function over config, in the same packageservelives in, and it deliberately reusesCatalogConfiguredso the notice cannot drift from the real tool-wiring condition. It should be directly reusable.Something like, near the other startup Info lines in
serve.go:Structured rather than the CLI's prose line, to match the surrounding
log.Info("… enabled", …)calls.Open questions
disabledToolscurrently covers metrics, logs and the catalog. Network flows, cloud and the forge are also silently absent when unset — worth deciding whether this notice is "the evidence backends" or "everything optional".Not urgent
Nothing is broken; this is a discoverability gap. Filed rather than folded into the profile-docs PRs because the level/scope questions above deserve a decision rather than an implementation smuggled into a docs change.