v2026.6.5
fortemi-react v2026.6.5 release notes.
fortemi-react v2026.6.5
fortemi-react v2026.6.5 makes the source of a knowledge base a runtime choice. A pre-indexed PGlite snapshot, a static `.shard` read in place, and the live PGlite database now present one operation interface, and an app asks for the capabilities it needs rather than wiring to a specific store. Everything here is additive and opt-in; existing PGlite read and write paths are unchanged.
Highlights
- Uniform tool-intent backend seam + capability negotiation (#191): the new `DataBackend` interface lifts the storage seam above SQL. `listNotes` / `getNote` / `search` are the shared core; `getNoteFull`, `semantic`, and `manageNote` appear only on backends that advertise them. `createPGliteBackend(db)` wraps the repositories and the `manageNote` tool (read+write+merge; `ann-full` semantic when embeddings exist); `createShardBackend(reader)` wraps `openShard` (instant, read-only; semantic tier set by the attached vector provider). `selectBackend(request, available)` negotiates — it returns the lightest backend that fully satisfies the request, or the fewest-missing candidate so callers degrade deliberately via `selection.missing`. Runtime upgrade/downgrade (static-file → PGlite when a visitor opts into semantic) is the same call with a stronger request. A remote-server backend is a future adapter against this same interface, deferred under epic #190. Design is captured in `.aiwg/architecture/adr-backend-seam.md`.
- Static-file backend — in-place clusterable shard reader (#189): `openShard(source)` reads a `.shard` archive without importing it into PGlite — browse, full-text + facet search with PGlite-parity AND semantics over multiple words, links/tags/concepts resolution, and lazy full content. `source` is a packed `Uint8Array`/`Blob`, or `{ baseUrl }` for lazy per-file fetch. Shards can be exported with a clustered note layout (`exportShard(db, { clusterNotesSize })` → `notes/NNNNNN.jsonl` + a manifest `layout`) so a reader fetches only the clusters a query needs; `importShard` and `openShard` both consume the layout transparently and monolithic shards stay valid. Semantic over a shard is a pluggable provider with three tradeoff points — none (text/facets), brute-force cosine over a small static vector set (`createCosineSemanticProvider`), or a prebuilt ANN snapshot. React adds `useShard(source, options?)`, mirroring `useAiwgIndex()`.
- Physical data-dir snapshot restore (#187): `dumpDbSnapshot(db, options?)` captures a pre-indexed PGlite data-directory image (gzip by default) with a version stamp (schema id, migration head, PGlite version, pgvector availability); `restoreDbSnapshot(source, options?)` verifies that stamp against the running environment and loads the image, so a consumer boots a fully-indexed database without replaying migrations or rebuilding HNSW. Hard version gates (schema, exact migration head, PGlite major.minor) throw `DbSnapshotVersionError` on mismatch; pgvector availability is advisory. Source forms: inline `{ data, meta }`, a string URL (with a `<url>.meta.json` sidecar), or `{ dataUrl, metaUrl? }`. `ArchiveManager.adopt(...)` swaps in an externally-built backend with no migration run, and `FortemiProvider` gains `snapshotUrl` / `snapshotExpectations` props for main-thread restore on mount.
- aiwg-index chunked-mode fixes (#177, #178, #179): path-safe base64url detail-id encoding, `exportReviewDecisions` in chunked mode, and a query match-set cache that stops re-scanning every part when re-paging a query.
Published Packages
- `@fortemi/[email protected]`
- `@fortemi/[email protected]`
- `@fortemi/[email protected]`
Compatibility
Existing `2026.6.4` consumers upgrade without source changes. Every addition is additive and opt-in:
- The backend seam, the shard reader, and the snapshot API are new exports; no existing PGlite, shard import/export, or capability path changed.
- The snapshot version stamp is strict by design — a snapshot built against a different schema, migration head, or PGlite major.minor is rejected rather than silently loaded.
Server-free by design
Snapshots and shards are static, build-time-generated assets. None of this adds a server requirement: the snapshot is a data-directory image, the shard reader fetches static files, and semantic-over-shard runs in the browser. The backend seam simply lets one app choose among these — and the live database — at runtime.