fix(config): let semantic memory be disabled with enabled: false alone - #1651

…null section

Follow-ups from review of the #1633 fix:

- The runtime config API assigns SemanticMemoryConf fields in place, so an
  enable request on a config with no config_database (now a legal state)
  could persist enabled=True and make the next lazy semantic-service build
  fail. The completeness check is now a public method the API re-runs after
  every semantic update; a request that leaves the config incomplete is
  auto-disabled and says so in the change summary.
- A bare `semantic_memory:` key (YAML null) now reads as a disabled section,
  matching the omitted-section behaviour.
- The config-storage getter refuses an empty config_database the same way
  the validator does, not only None.
- `enabled` field description and the two doc sites that marked
  `config_database` required (configuration.mdx, retrieval_agent README)
  updated to the new contract.
- Round-trip test now pins that a complete-but-disabled section keeps
  `enabled: false` across save and reload.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Signed-off-by: Marvin Yu <[email protected]>

Second review round on the #1633 fix:

- The API re-check covered only the required-fields guard; the sibling
  OpenAI-credential guard (`Configuration._maybe_disable_semantic_memory`)
  was still bypassed, so an enable request against an embedder with an
  empty key and no base_url could persist enabled=True. A new
  `Configuration.auto_disable_semantic_memory()` runs both guards and
  returns the reason; both API entry points call it and report the reason
  in the change summary, naming the missing fields.
- `auto_disable_when_incomplete()` returns the missing field names; a new
  `missing_required_fields()` computes them.
- `semantic_memory: {}` is treated like a null or omitted section
  (disabled, no warning).
- `get_semantic_storage` refuses an empty database id the same way the
  config-storage getter does.
- Docs: the `llm_model`, `embedding_model`, and `database` rows are
  described the same way as `config_database` (required only when
  semantic memory is enabled).
- Tests: the API re-validation tests load the real sample Configuration;
  both disabled-section shapes are pinned through the YAML round trip; the
  null/empty-section test asserts no auto-disable warning.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Signed-off-by: Marvin Yu <[email protected]>

Requests default target_memories to every memory type, so add/search/list
dispatched into semantic memory on the type list alone, without consulting
semantic_memory.enabled. With the section disabled its required fields are
legally unset, so the dispatch reached get_semantic_config_storage and raised
ResourceNotReadyError; no route handles it, so a first POST /memories after
disabling semantic memory returned an unhandled 500.

Route the three dispatch sites through _semantic_memory_targeted, which
conjoins the enabled flag, matching what the startup, shutdown, and
session-deletion paths already do.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Signed-off-by: Marvin Yu <[email protected]>

…sabled

delete_episodes resolved the semantic service before building any of its
work, so with semantic memory disabled the call raised ResourceNotReadyError
and never reached episode_storage.delete_episodes. POST /memories/episodic/
delete, which names no semantic memory, returned a 500 and left the episodes
in place.

Resolve the semantic service only when semantic memory is enabled, and pin
both directions. Also rename the dispatch predicate to
_should_dispatch_to_semantic_memory, since the call sites gave no sign that
it consults configuration as well as its argument, and drop its per-call log
so it stays a pure predicate.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Signed-off-by: Marvin Yu <[email protected]>