Modules
Tenant behaviour — grid settings, form surfaces and application configuration. Core.
settings is the tenant's behaviour: one key-value table, one row per scope, the configuration in a JSON column. The configuration page carries the model; this page is the module's surface.
settings, and beside it settings_secrets, the sealed, server-only row that holds the tenant's storage keys and nothing else.
Application-wide rows hold what the app as a whole needs: currency and gateway, the shop, the marketing site, the chat, the theme, storage. A module row holds that module's form surface and, per grid, its setting flags, column definitions and filter definitions. A defaults row is the fallback.
/settings: the application-wide settings, and per module its form surface and grids. /settings/memory is the owner's view of what the assistant has remembered across conversations, with the option to retract any of it.
get_module_settings, manage_grid_settings, manage_form_settings. Each replaces one node of a module row, so an edit to one grid leaves its siblings alone, and a role restriction on a setting stays an admin-panel decision the assistant cannot make. Every change is audited and reversible from the entry that recorded it.
settings.manage. Module rows resolve against the reader's role, so a grid looks richer to an admin and leaner to a standard user from one configuration.
Never. Every project links it at provisioning.