@equationalapplications/core-llm-wiki 7.8.0 → 7.9.0

package/README.md

@@ -1254,6 +1254,15 @@ const { nodesWritten, edgesWritten, superseded } = await wikiMemory.upsertGraph(
 
 `upsertGraph` is "the tail of `ingestDocument` with the middle (LLM extraction) step removed" — it accepts caller-supplied nodes (`{ id, type, title, body? }`) and edges (`{ type, sourceId, targetId, id? }`) and writes them under the same `(sourceRef, sourceHash)` semantics. If a *different* live `sourceRef` already holds the same `sourceHash`, it throws `WikiSourceRefHashCollision`; re-writing the identical `(sourceRef, sourceHash)` is a no-op returning zero counts. The adapter parameter is required so writes participate in the caller's transaction.
 
+Core never sees your transaction commit, so it can't index the new nodes itself. Until you tell it, they won't show up in keyword or hybrid `read()` results on the same instance. Call `syncSearchIndex` **after** the commit, not inside the transaction:
+
+```typescript
+await db.withTransactionAsync((tx) => wikiMemory.upsertGraph('entity-123', params, tx));
+await wikiMemory.syncSearchIndex('entity-123'); // or syncSearchIndex() for every entity written
+```
+
+It is cheap on an entity that is already current, runs in order with core's own index syncs, and never rejects for a valid `entityId` (an empty or non-string id throws `TypeError`). It does not compute embeddings; those still come from the maintenance sweep.
+
 Entry IDs occupy one globally shared namespace within a database. An ID belongs
 to its existing entity while its row exists, including after soft deletion.
 Same-entity updates and resurrection retain their existing behavior; physically

package/dist/{chunk-M76CF2Q6.mjs → chunk-J2TWKOEE.mjs}

@@ -578,6 +578,16 @@ var _SearchService = class _SearchService {
     this.staleEntities.add(entityId);
     this.staleEpochs.set(entityId, (this.staleEpochs.get(entityId) ?? 0) + 1);
   }
+  /**
+   * Runs syncEntries(id, []) for each entity marked stale when this is called,
+   * so only those entities are rebuilt. Each rebuild still takes its own turn
+   * on the sync chain, and like syncEntries this never rejects. With nothing
+   * stale it resolves at once, without waiting on work already on the chain.
+   */
+  async syncStale() {
+    const ids = [...this.staleEntities];
+    await Promise.all(ids.map((id) => this.syncEntries(id, [])));
+  }
   /**
    * Clears the parsed vector cache. Useful for mid-loop flush guarantees
    * or memory pressure evictions.
@@ -6786,5 +6796,5 @@ var WriteService = class {
 };
 
 export { BaseRepository, DEFAULT_CHUNK_OVERLAP, DEFAULT_MAX_CHUNK_LENGTH, DEFAULT_MAX_EMBED_CHARS, DiagnosticBuffer, EMBED_CHARS_CEILING, EmbeddingService, HEAL_ANCHORS_PER_CANDIDATE, HEAL_BATCH_SIZE, HEAL_MAX_FACT_BODY_CHARS_L3, HEAL_MAX_TASKS, HEAL_RECHECK_MS, HOOK_TIMEOUT_MARKER, ImportExportService, IngestionService, JobManager, MAX_EMBED_ATTEMPTS, MaintenanceService, MetadataRepository, ONTOLOGY_BACKFILL_BATCH_SIZE, ONTOLOGY_BACKFILL_MAX_PROMPT_CHARS, ONTOLOGY_BACKFILL_RECHECK_MS, ONTOLOGY_BACKFILL_SYSTEM_PROMPT, PromptService, PrunePartialFailureError, RetrievalService, SearchService, TemporalService, UsageMeter, WikiBusyError, WikiDraftNotFound, WikiDuplicateHashError, WikiGraphNodeOwnershipConflict, WikiIngestEmptyError, WikiInvalidReadOptions, WikiParseError, WikiSourceRefHashCollision, WikiStrictOntologyViolation, WikiSupersedeError, WikiTransactionError, WriteService, __privateAdd, __privateGet, __privateSet, chunkText, configureRandomSource, edgeTripleAllowed, emptyManifest, entitySummaryMetaKey, extractSqliteCode, factTokenCost, generateId, isLiveAt, liveAtSql, normalizeSourceHash, normalizeSourceRef, normalizeTitleKey, packFactsByBudget, parseEmbedding, resolveEdgeDefinitions, resolveGrounding, resolveNodeType, safeSlice, typeSatisfies, validateInlineEdges, validateManifest };
-//# sourceMappingURL=chunk-M76CF2Q6.mjs.map
-//# sourceMappingURL=chunk-M76CF2Q6.mjs.map
+//# sourceMappingURL=chunk-J2TWKOEE.mjs.map
+//# sourceMappingURL=chunk-J2TWKOEE.mjs.map