Skip to content

sys_secret.namespace / .key still describe themselves as settings-only, on a table with three producers #12550

Description

@claude

Observation-class finding, surfaced while re-measuring reachability for #8103. ⛔ Not assigned, not queued — recording drift, not asking for a sprint.

What is declared vs what is true

packages/platform-objects/src/system/sys-secret.object.ts documents the table correctly in its managedBy note — three privileged producers (#4270): SettingsService, the engine's own secret-field encryption (encryptSecretFields), and the datasource credential binder.

Its two most load-bearing field descriptions still say the table is settings-only:

  • namespace'Settings namespace this secret belongs to.'
  • key'Specifier key within the namespace.'
  • id'Opaque handle referenced by \sys_setting.value_enc`.'`

Measured on origin/main@3a3a0993, none of the three is true in general:

Producer writes namespace writes key reference lives at
SettingsService settings namespace specifier key sys_setting.value_enc
engine encryptSecretFields object name field name a business row's own column
datasource binder caller-supplied (default datasource) datasource name the datasource artefact's credential ref

Why it is worth a card rather than a shrug

These strings are not internal comments — they are the field help an operator reads in the sys_secret grid, and they are compiled into the shipped translation bundles (packages/platform-objects/src/apps/translations/*.objects.generated.ts). A reader of the grid is told, by the platform, that namespace means "settings namespace".

That is the precise misreading that makes a sys_secret row look attributable to settings when it is not. #8103's re-measurement found that attribution by (namespace, key) is unsound exactly because those two columns mean something different per producer; the field help currently asserts the unsound reading. It is a declared ≠ enforced drift with a safety-relevant direction, which is why it is being written down rather than left.

Shape of the fix

Descriptions that name the tri-producer reality and stop implying a single owner — e.g. namespace/key as "producer-scoped pair; meaning depends on which producer wrote the row (see managedBy)", and id as the handle referenced by whichever producer's holder column. Regenerating the translation bundles is part of it.

⛔ Explicitly not proposing a producer/owner column here — that is a persist-path change with its own consequences and belongs to whoever takes that decision.

Found while working #8103 (reachability re-measurement); filed unassigned for triage.


Generated by Claude Code

Metadata

Metadata

Assignees

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions