fix(memory): initialize candidates and enforce lifecycle rollout

2026-07-21 22:55:19 +08:00
parent 0dd9331e5b
commit bfb1f6fea9
8 changed files with 207 additions and 14 deletions
@@ -79,7 +79,16 @@ The additive user-scoped management API is:
 Lifecycle workers are disabled by default. When explicitly enabled they run
 expiration, conservative compaction observation, candidate promotion, and
 reflection observation according to the rollout mode; none of these operations
-blocks the chat path.
+blocks the chat path. `off` creates no worker scope and performs no lifecycle
+mutation, `canary` is always user-scoped to the configured rollout IDs, and only
+`active` permits an unscoped global worker run.
+
+When candidate persistence is enabled, the Portal runtime idempotently creates
+`h5_memory_v2_candidates` before enabling the MySQL candidate store. DDL failure
+is fail-open for Portal chat and falls back to bounded in-memory candidates;
+`memind_adm` uses the same schema helper during bootstrap and fails startup rather
+than serving a permanently broken candidate API. The table is additive and must
+not be dropped as part of an application rollback.

 The pgvector adapter does not create tables or generate embeddings. It only defines the adapter contract for a future semantic memory backend and requires explicit `enabled: true`, an injected PostgreSQL pool, and either an input embedding or an injected `embedQuery(...)` function.