semantic_memory cannot be disabled with enabled: false alone: the section and config_database are required even when semantic memory is off #1633

What happened

Turning semantic memory off in the config file takes more than enabled: false. The configuration fails to load unless you also name a config_database, and it fails if the semantic_memory section is left out entirely.

Line numbers as of 98f3cde (speedkick), packages/server/src/memmachine_server/common/configuration/__init__.py:

• SemanticMemoryConf.config_database is declared Field(...) (line 144), so it is required whatever enabled is.
• Configuration.semantic_memory has no default (line 373), so the section itself is required.

Checked against the model directly:

SemanticMemoryConf(enabled=False)
  -> 1 validation error for SemanticMemoryConf
     config_database  Field required [type=missing]

SemanticMemoryConf(enabled=False, config_database="pg")        -> OK
Configuration(... semantic_memory section omitted ...)
  -> 1 validation error for Configuration
     semantic_memory  Field required [type=missing]

This contradicts #1580 ("default to no short-term or semantic memory"). Semantic memory is off by default, but the operator still has to write a semantic section and point it at a database that will never be used. Every other semantic field is optional, and _auto_disable_when_incomplete (line 180) already treats a missing storage field as grounds to disable rather than to fail.

Expected

With semantic memory disabled, semantic_memory: should be optional and so should config_database. Either of these should load:

semantic_memory:
  enabled: false

or no semantic_memory section at all.

Concretely: make config_database optional (str | None = None), give Configuration.semantic_memory a default, and fold a missing config_database into _auto_disable_when_incomplete for configs that do set enabled: true. SemanticManager.get_semantic_config_storage (common/resource_manager/semantic_manager.py:175) would then need to raise ResourceNotReadyError when it is unset, as the storage getter already does for database.

Related

• semantic_memory.enabled is honored only at startup: search, add and list still build and query the semantic stack whenever a request names the semantic type #1600 / Honor semantic_memory.enabled on every request path, not only at startup (speedkick) #1601: the runtime side of the same flag (request paths ignore enabled). This issue is only about the config schema.
• Project deletion never completes when semantic memory is disabled: the deletion worker requests the semantic service unconditionally and gives up #1575: project deletion with semantic memory disabled. Its reproduction config shows the workaround this issue asks to remove (enabled: false plus a config_database).

Investigated and written by Claude (Claude Code), filed from the account of the user who commissioned the investigation.