Follow-up from #794, deliberately scoped out of that PR.
#794 added system_settings.origin, which records whether a row was set deliberately (admin API, SettingsService.Set, tmi-dbtool --import-config) or merely seeded with a registry default at first boot. That distinction is now load-bearing: it decides whether a database row outranks an explicitly-configured env var.
The field is not exposed through the admin settings API. modelToAPISystemSetting (api/config_handlers.go) builds the API type field by field and does not copy it, so GET /admin/settings gives an admin no way to see why a setting is or is not taking effect.
Why it was left out
Exposing it means changing api-schema/tmi-openapi.json and running make generate-api, which regenerates api/api.go. Every concurrent PR then conflicts on that file (this is a known, recurring cost — see the rebase note in the 2026-08-22 handoff). #794 was already a schema change plus a precedence change plus a startup check; adding a spec change on top was not worth the merge friction, and the startup divergence warning added in the same PR covers the immediate diagnostic need.
What to do
Add origin to the SystemSetting schema in the OpenAPI spec as a read-only, admin-only enum (seeded | explicit), copy it in modelToAPISystemSetting, regenerate, and surface it in whatever admin UI lists settings.
Worth considering at the same time: the existing computed source field ("database", "config", "environment", "vault") answers a related but different question — where the effective value comes from. With origin present, the pair fully explains any precedence outcome, so they should probably be documented together rather than as two unrelated fields.
Related
Follow-up from #794, deliberately scoped out of that PR.
#794 added
system_settings.origin, which records whether a row was set deliberately (admin API,SettingsService.Set,tmi-dbtool --import-config) or merely seeded with a registry default at first boot. That distinction is now load-bearing: it decides whether a database row outranks an explicitly-configured env var.The field is not exposed through the admin settings API.
modelToAPISystemSetting(api/config_handlers.go) builds the API type field by field and does not copy it, soGET /admin/settingsgives an admin no way to see why a setting is or is not taking effect.Why it was left out
Exposing it means changing
api-schema/tmi-openapi.jsonand runningmake generate-api, which regeneratesapi/api.go. Every concurrent PR then conflicts on that file (this is a known, recurring cost — see the rebase note in the 2026-08-22 handoff). #794 was already a schema change plus a precedence change plus a startup check; adding a spec change on top was not worth the merge friction, and the startup divergence warning added in the same PR covers the immediate diagnostic need.What to do
Add
originto theSystemSettingschema in the OpenAPI spec as a read-only, admin-only enum (seeded|explicit), copy it inmodelToAPISystemSetting, regenerate, and surface it in whatever admin UI lists settings.Worth considering at the same time: the existing computed
sourcefield ("database", "config", "environment", "vault") answers a related but different question — where the effective value comes from. Withoriginpresent, the pair fully explains any precedence outcome, so they should probably be documented together rather than as two unrelated fields.Related