[pgvector] is missing from config.toml.example — document it and add a drift test

[jason-shen]

Problem

config.toml.example is the de facto configuration reference — it's what CONTRIBUTING-less newcomers copy and what the README points at. Nothing keeps it in sync with the Config struct, so a key added in Go can quietly go undocumented.

It has already drifted. [rag] provider = "pgvector" is offered as a valid choice, and PgvectorConfig exists in internal/config/config.go with a toml:"pgvector" tag, but there is no [pgvector] section anywhere in config.toml.example. A user who follows the file's own suggestion and switches the RAG provider to pgvector has nothing telling them what to configure next.

Every other section in the struct is represented. This is the only gap today — which is exactly why it's worth adding a guard now, while the fix is one section rather than fifteen.

Proposed change

Part 1 — fix the drift. Add a documented [pgvector] section to config.toml.example, matching the field set in PgvectorConfig and following the commenting style of the neighbouring [supabase] block. internal/rag/pgvector.go shows how each field is actually consumed.

Part 2 — prevent recurrence. Add a test in internal/config/config_test.go that walks the Config struct by reflection, collects every toml: tag, parses config.toml.example, and fails naming any key that is absent.

Two details that make this test practical rather than annoying:

• Commented-out keys count as documented. Many optional settings in the file are deliberately shown as # key = "value", and the test must accept that form — otherwise it forces every optional key to be uncommented, which would break the example as a copy-paste starting point.
• Nested structs need their section prefix, so compare on the full dotted path (pgvector.connection_string), not the bare leaf name.

A small allowlist for keys that are intentionally undocumented is fine, as long as each entry carries a comment saying why.

Acceptance criteria

• [pgvector] is documented in config.toml.example with a comment per field.
• The new test fails if a field is added to any *Config struct without a matching entry in the example.
• The test passes on main once part 1 lands.
• Commented-out (# key =) entries are accepted as documented.

Pointers

• internal/config/config.go — Config and the *Config structs; PgvectorConfig is the one currently missing
• internal/rag/pgvector.go — how those fields are used
• config.toml.example — [supabase] is the style to match
• internal/config/config_test.go — existing test file to extend

[adity982]

I found that current main already documents the commented [pgvector] section and both fields (the lines trace to commit 9c533b4), so Part 1 of the proposed change is already present. I’m going to keep the contribution focused on the still-missing drift regression test: it will derive full dotted TOML paths from Config, accept active and commented example keys, and report any undocumented fields. I won’t duplicate or rewrite the existing pgvector example block.

[jason-shen]

I found that current main already documents the commented [pgvector] section and both fields (the lines trace to commit 9c533b4), so Part 1 of the proposed change is already present. I’m going to keep the contribution focused on the still-missing drift regression test: it will derive full dotted TOML paths from Config, accept active and commented example keys, and report any undocumented fields. I won’t duplicate or rewrite the existing pgvector example block.

sounds good to me, thank you @adity982