llm/docs/1c-sql-protocol/operations/configurator-cache.md

Configurator refresh behaviour

Observed session model

ConfigCASSave is an SQL overlay, but writing it outside Configurator does not set Configurator’s in-memory changed/dirty state.

Observed consequences:

State before adapter write	Minimal human action after write
Object already existed in saved-state	Close and reopen that object
Adapter created the first pending object for an extension	Close and reopen the extension
Adapter created the first pending object for base configuration	Close and reopen the configuration

If the user manually edits and saves any object in an extension, Configurator marks the extension changed; reopening another object can then load its ConfigCASSave overlay.

Required adapter response

Write results should return machine-readable guidance:

{
  "configurator_refresh": {
    "required": true,
    "scope": "object|extension|configuration",
    "action": "close_reopen_object|close_reopen_extension|close_reopen_configuration"
  }
}

This guidance does not claim that the adapter controls Configurator; it merely reports the minimum observed reload boundary.