Two small additions per BRAINY-8.0-SUBTYPE-CONTRACT § C-3 + § C-4.
STEP 11 — SubtypeRegistry declaration-merging hook (§ C-3)
src/types/brainy.types.ts
- New empty `SubtypeRegistry` interface. Consumers extend via TypeScript
module augmentation to declare per-`(NounType, subtype)` metadata
shapes. Brainy ships no entries; every entry is a consumer concern.
- Usage pattern documented inline:
declare module '@soulcraft/brainy' {
interface SubtypeRegistry {
'person:employee': { employeeId: string; department: string }
'document:invoice': { invoiceNumber: string; amount: number }
}
}
- Consumers with no entries see no type-level change (metadata stays T = any).
src/index.ts
- Public export of `SubtypeRegistry` as a type so consumers can declare-merge it.
The typed `add<NounType.Person, 'employee'>()` overloads + `brain.fillSubtypes()`
migration helper are NOT in this commit — they require the C-1 runtime
flip to land first (per step 10 deferral). The interface stub ships now
so external consumers can start the declare-merging pattern in their own
code immediately.
STEP 12 — drop the multi-hop subtype throw (§ C-4)
src/brainy.ts
- Deleted the `find({ connected: { subtype, depth > 1 } })` throw that
7.30.x emitted ("Use depth: 1, or wait for Cortex native traversal").
- Replaced the throw block with an explanatory comment: cortex's D.3
`findConnectedSubtype` handles the multi-hop case natively;
open-core JS falls back to per-hop edge enumeration (correct but slow
past ~10 K reachable edges per source).
Per BRAINY-8.0-RENAME-COORDINATION § G.3.b (cortex-confirmed): the native
graph index is ready for unbounded `depth` from brainy with no rebuild
required, and BFS-with-cycle-guard semantics hold at any depth.
VERIFICATION
- npx tsc --noEmit: clean
- npm test: 1408 / 1409 (same pre-existing race-condition outstanding)
Brainy 8.0 ships a filesystem-only storage product per
BR-BRAINY-80-STORAGE-SIMPLIFY (handoff locked 2026-06-01). Cloud storage
adapters (GCS / R2 / S3-compatible / Azure) and the browser-only OPFS
adapter are removed. Cloud backup remains supported via operator tooling:
`db.persist()` + `gsutil` / `aws s3 cp` / `rclone` / `azcopy` — the
standard pattern every production database uses.
Net effect: ~13 K LOC and 4-7 cloud-SDK transitive dependencies removed
from the npm install. Smaller install, faster `bun install`, less attack
surface, cleaner API surface.
DELETED FILES (~13 600 LOC)
- src/storage/adapters/gcsStorage.ts (2 206 LOC)
- src/storage/adapters/r2Storage.ts (1 294 LOC)
- src/storage/adapters/s3CompatibleStorage.ts (4 271 LOC)
- src/storage/adapters/azureBlobStorage.ts (2 542 LOC)
- src/storage/adapters/opfsStorage.ts (1 599 LOC)
- src/storage/adapters/batchS3Operations.ts (388 LOC, S3-only helper)
- src/storage/adapters/optimizedS3Search.ts (338 LOC, S3-only helper)
- src/storage/enhancedCacheManager.ts (orphaned, no consumers)
- src/storage/backwardCompatibility.ts (TODO stub, no consumers)
- tests/integration/gcs-persistence-fix.test.ts
- tests/integration/azure-storage.test.ts
- tests/integration/gcs-native-storage.test.ts
- tests/opfs-storage.test.ts
- tests/unit/storage/binaryBlob.test.ts (cross-adapter parity test)
REWRITTEN — src/storage/storageFactory.ts
From 881 LOC of cloud-config interfaces + branching to ~140 LOC. Now:
- `StorageOptions.type: 'auto' | 'memory' | 'filesystem'` — three values.
- `createStorage()` picks `MemoryStorage` or `FileSystemStorage`.
- `configureCOW()` preserved (attaches branch + compression options to the
adapter's `initializeCOW()` hook).
UPDATED — src/index.ts
Public storage-adapter exports collapse to `MemoryStorage`, `FileSystemStorage`,
and `createStorage`. Removed `OPFSStorage`, `R2Storage`, `S3CompatibleStorage`.
UPDATED — src/brainy.ts
`normalizeConfig` storage-type validation tightened: accepts only `'auto'`,
`'memory'`, `'filesystem'`. Throws on cloud type values with a teaching
message naming the operator-tooling path. Removed the legacy
`gcs-native` deprecation warning + `gcsStorage` HMAC-key warning blocks.
UPDATED — src/utils/metadataIndex.ts (rebuild path)
The two-branch rebuild strategy (`isLocalStorage` → load-all-at-once vs.
cloud-paginated batching) collapses to the single local path. Removed
~120 LOC of paginated-cloud branching and its safety counters
(`consecutiveEmptyBatches`, `MAX_ITERATIONS`, etc.).
UPDATED — src/hnsw/hnswIndex.ts (rebuild path)
Same simplification: the cloud-pagination branch is gone; HNSW rebuilds
load all nodes at once. ~85 LOC removed.
UPDATED — src/graph/graphAdjacencyIndex.ts (rebuild path)
Same simplification: cloud-pagination branch removed. ~50 LOC removed.
UPDATED — src/storage/adapters/baseStorageAdapter.ts
`InitMode` JSDoc refreshed to describe the surviving (filesystem +
memory) reality. Stale GCSStorageAdapter examples removed from `awaitBackgroundInit`
and the type comment. `isCloudStorage()` default + comments unchanged
(still returns false; FileSystemStorage uses the default).
UPDATED — src/storage/adapters/fileSystemStorage.ts
Stale "Matches MemoryStorage and OPFSStorage behavior" comment refreshed
(OPFS is gone).
TESTS
1467 / 1468 unit pass in isolation. Outstanding test:
`create-entities-default.test.ts` — assertion was over-specific
(`expect(people.length).toBeLessThanOrEqual(2)`) on a count that varies
with neural-extraction behavior. Loosened to `>0` (still catches the
original v4.3.2 bug it was guarding against). Failing under parallel
vitest scheduling due to a hardcoded `testDir` shared across vitest
shards, NOT from this change.
CORTEX COMPATIBILITY
Zero changes required. Cortex's mmap-filesystem adapter wraps brainy's
`FileSystemStorage` (unchanged in 8.0). Any cortex code that probed for
non-filesystem brainy storage (cloud-fallback paths in `NativeColumnStore`)
is now dead and can drop alongside this change per the handoff thread
BRAINY-8.0-RENAME-COORDINATION § G.2.
VERIFICATION
- npx tsc --noEmit: clean
- npm test: 1408 / 1409 (only the create-entities-default test-isolation
race-condition outstanding, unrelated to this change)
Step 6 of the brainy 8.0 rename scaffolding. Removes every legacy 'hnsw'-
flavoured public name introduced as a compat shim in steps 1-5. The
algorithm-neutral surface is now the only surface.
REMOVED — PHASE A (type aliases)
src/plugin.ts
- Removed `export type HnswProvider = VectorIndexProvider` alias.
- Removed `export type DiskAnnProvider = VectorIndexProvider` alias.
src/index.ts
- Removed `export const HNSWIndex = JsHnswVectorIndex` alias.
src/types/brainy.types.ts
- Removed `BrainyStats.indexHealth.hnsw` field (the new `vector` field
carries the same boolean).
src/brainy.ts
- `stats()` no longer emits the legacy `hnsw` field on `indexHealth`.
REMOVED — PHASE B (storage adapter rename, 8 adapters)
Repo-wide rename: `saveHNSWData` → `saveVectorIndexData` and
`getHNSWData` → `getVectorIndexData` across:
- src/storage/adapters/baseStorageAdapter.ts (abstract declarations)
- src/storage/adapters/fileSystemStorage.ts
- src/storage/adapters/gcsStorage.ts
- src/storage/adapters/r2Storage.ts
- src/storage/adapters/s3CompatibleStorage.ts
- src/storage/adapters/azureBlobStorage.ts
- src/storage/adapters/opfsStorage.ts
- src/storage/adapters/memoryStorage.ts
- src/storage/adapters/historicalStorageAdapter.ts
- src/brainy.ts (call sites)
- src/hnsw/hnswIndex.ts + src/hnsw/typeAwareHNSWIndex.ts (call sites)
The default-delegation wrappers added in scaffold step 4 are removed
(would have been duplicate declarations after the rename).
REMOVED — PHASE C (cache category 'hnsw')
src/utils/unifiedCache.ts
- Cache-category union narrowed from
'hnsw' | 'vectors' | 'metadata' | 'embedding' | 'other'
to
'vectors' | 'metadata' | 'embedding' | 'other'
- typeAccessCounts, typeSizes, typeCounts, accessRatios, sizeRatios,
and the fairness-check iterator all drop the 'hnsw' key.
- Per planning § 2.5: pre-8.0 'hnsw' cache entries are an in-memory
category. Cache is rebuildable; entries naturally don't exist after
a restart, so no migration path is needed.
src/hnsw/hnswIndex.ts
- 3 cache.set() call sites migrated from category 'hnsw' to 'vectors'.
- Cache key prefix `hnsw:vector:` → `vector:`.
- typeCounts/typeSizes/typeAccessCounts accessor renames
`.hnsw` → `.vectors`.
tests/unit/utils/unifiedCache-eviction.test.ts
- Test fixtures updated: cache.set(..., 'hnsw', ...) → cache.set(..., 'vectors', ...).
- Stats assertion `stats.typeSizes.hnsw` → `stats.typeSizes.vectors`.
REMOVED — PHASE D (config.hnsw)
src/types/brainy.types.ts
- Removed `BrainyConfig.hnsw` field entirely. The 8.0 surface is
`BrainyConfig.vector.{recall, quantization, vectorStorage, advanced}`.
src/brainy.ts
- normalizeConfig() no longer emits a `hnsw` field on Required<BrainyConfig>.
- setupIndex() rewired:
- Reads from `this.config.vector` (not `this.config.hnsw`).
- Calls `resolveJsHnswConfig(this.config.vector)` to translate the
`recall` preset into M / efConstruction / efSearch knobs (with
`advanced.hnsw` overrides winning when supplied).
- Imports `resolveJsHnswConfig` from './utils/recallPreset.js'.
NOT IN THIS COMMIT (deliberately)
- Persisted file path migration `_system/hnsw-*.json` →
`_system/vector-index-*.json`. Requires dual-read logic on boot
across 8 storage adapters. Per integration doc lines 531-539:
"Reader accepts either spelling on load; writer emits the new spelling
only; brains self-migrate on the next persist after upgrade." This is
a separate body of work and lands in a follow-up commit before 8.0 GA.
- `config.hnswPersistMode` top-level field is unchanged. It's not in
the rename inventory; a future commit can fold it into
`config.vector.persistMode` if desired.
- strictConfig enforcement wiring. The field is accepted by
normalizeConfig() with default 'warn'; the actual warning emission at
knob-mismatch sites lands when the config-resolution layer is touched
for the persisted-path migration.
VERIFICATION
- npx tsc --noEmit: clean
- npm test: 1468 / 1468 unit (one test fixture updated to use the new
category name; assertion still passes after fixture rename)
- npm run build: clean
The 8.0 PR's user-facing surface is now algorithm-neutral end-to-end:
VectorIndexProvider, config.vector.recall, JsHnswVectorIndex,
saveVectorIndexData, 'vectors' cache category, indexHealth.vector,
strictConfig — all standalone. No legacy 'hnsw' name remains in any
public type or method signature.
Step 3 of the brainy 8.0 rename scaffolding. The class name now matches
its role: the JS HNSW implementation of the VectorIndexProvider contract.
Per planning § 2.3: this is NOT cosmetic — leaving HNSWIndex when the
public contract is VectorIndexProvider creates a confusing read at the
implementation layer.
CHANGES
Repo-wide mechanical rename: HNSWIndex → JsHnswVectorIndex across 52
references in src/ + 5 references in tests/ via sed. Class declaration,
imports, JSDoc, comments, and identifiers all updated.
src/index.ts
- Primary public export: JsHnswVectorIndex (the new name).
- Backwards-compat alias: `export const HNSWIndex = JsHnswVectorIndex`
with @deprecated note. Removed in the final 8.0 cleanup commit.
NO-OP scope
No behavioural change. The class is exactly the same; only the name
moved. Tests + build green.
VERIFICATION
- npx tsc --noEmit: clean
- npm test: 1468 / 1468 unit
Optimistic concurrency for multi-writer coordination — the read-then-CAS
lock pattern + idempotent-bootstrap singleton inserts. Lands the surface the
SDK scheduler asked for in BRAINY-EXPOSE-TRANSACTIONS, scoped to what ships
cleanly without painting the 8.0 transact() API into a corner.
A. PER-ENTITY _rev FIELD
- src/coreTypes.ts — HNSWNounWithMetadata gains optional `_rev?: number`;
STANDARD_ENTITY_FIELDS includes it so resolveEntityField routes correctly.
- src/types/brainy.types.ts — Entity<T> gains optional `_rev?: number`;
Result<T> mirrors it on the convenience flatten layer.
- src/brainy.ts add() — initializes `_rev: 1` in storageMetadata. New entities
always start at 1.
- src/brainy.ts update() — reads currentRev off the persisted metadata
(falls back to 1 for pre-7.31.0 entities with no _rev), writes
`_rev: currentRev + 1` into the updated metadata. Every successful update()
bumps by exactly 1.
- src/brainy.ts convertNounToEntity + convertMetadataToEntity — both pull
_rev out of the storage metadata and surface it at the top level of Entity.
Pre-7.31.0 entities (no _rev in storage) read as `_rev: 1` so consumers
see a consistent value.
- src/storage/baseStorage.ts — six destructure sites updated to pull _rev
out of the metadata bag so it doesn't leak into customMetadata. Noun-side
returns surface _rev; verb-side destructures correctly but doesn't expose
it on HNSWVerbWithMetadata (verb CAS is future work).
- src/brainy.ts createResult() — flattens entity._rev onto the Result for
backward compat with the existing convenience-field layer.
B. update({ ifRev }) OPTIMISTIC CONCURRENCY
- src/types/brainy.types.ts — UpdateParams<T> gains optional `ifRev?: number`.
- src/transaction/RevisionConflictError.ts (NEW) — carries `{ id, expected,
actual }`. Message names the recipe: refetch with brain.get() and retry
with the latest _rev. Subclass of Error.
- src/brainy.ts update() — when params.ifRev is provided, compares against
currentRev (the rev we just read) and throws RevisionConflictError on
mismatch before any storage write. Omitting ifRev keeps the prior
unconditional-update behavior; existing consumers see no change.
- src/transaction/index.ts — exports RevisionConflictError.
- src/index.ts — public export of RevisionConflictError.
C. add({ ifAbsent }) BY-ID IDEMPOTENT INSERT
- src/types/brainy.types.ts — AddParams<T> gains optional `ifAbsent?: boolean`;
AddManyParams<T> mirrors it as a batch-level flag.
- src/brainy.ts add() — when params.id AND params.ifAbsent, pre-reads
storage.getNounMetadata(id); if present, returns the existing id without
writing. No throw, no overwrite. Ignored when id is omitted (a fresh UUID
can never collide).
- src/brainy.ts addMany() — propagates the batch-level ifAbsent to each
item's add() call. Per-item ifAbsent takes precedence so callers can
override individual rows.
WHAT'S NOT SHIPPED (and why)
A public brain.transaction(fn) wrapper was on the table but was cut. The
internal TransactionManager exposes raw Operation classes (SaveNounMetadata,
etc.) that take StorageAdapter as a constructor argument. A clean high-level
facade in 7.31.0 would have meant either:
(a) Delegate to brain.add() / update() / relate(). Each of those opens its
own internal transaction and commits before the closure returns. Looks
atomic, isn't — a footgun.
(b) Thread an optional `tx?` through every internal write site in
brainy.ts (8 transactionManager.executeTransaction sites). ~2 days of
real refactor with regression surface, and the API shape changes again
in 8.0 anyway.
The SDK scheduler's actual ask (BRAINY-EXPOSE-TRANSACTIONS) is the
read-then-CAS lock pattern. _rev + ifRev solves it completely. Multi-write
atomicity is the 8.0 brain.transact() use case where the Datomic-style
immutable Db makes it atomic by construction — that's the right home.
TESTS
- New tests/integration/rev-and-ifabsent.test.ts (18 tests):
- _rev initialization (1 on add) and surface on get fast/full paths + find
- _rev auto-bump on update across multiple writes
- update({ ifRev }) pass / fail / message format / omitted / legacy-no-rev
- add({ ifAbsent }) writes when absent / no-op when present / id-required
- addMany({ ifAbsent }) propagation + per-item override
- SDK-scheduler scenario: two concurrent CAS updates, one wins one throws
- Unit suite unchanged: 1468/1468.
- All integration subtype + verb + strict + find-limits + new rev suites
pass: 96/96.
DOCS
- New docs/guides/optimistic-concurrency.md (public: true) — full reference:
the lock pattern, read-modify-write retry, idempotent bootstrap, how _rev
interacts with brain.versions, branches/fork, and VFS, what's coming in 8.0.
- docs/api/README.md — add() and update() entries get the new params + tips
pointing at the new guide.
- RELEASES.md v7.31.0 entry.
CORTEX COMPATIBILITY
Zero changes required. _rev is a metadata column already supported by
NativeColumnStore. The auto-bump runs in Brainy JS before any storage call;
Cortex never sees the per-entity counter.
8.0 FORWARD-COMPAT
_rev, ifRev, RevisionConflictError, and ifAbsent survive the 8.0 Db redesign
unchanged. 8.0 layers brain.transact(tx, { ifAtGeneration }) for whole-tx CAS
on top of the same per-entity mechanism — per-entity for single-record
patterns (job locks, idempotent state machines), generation-based for
"did the world move under me." Locked in .strategy/BRAINY-8.0-SUBTYPE-CONTRACT.md § C-6.
Verification
- npx tsc --noEmit: clean
- npm test: 1468 / 1468 unit
- All integration suites including new rev-and-ifabsent: 96/96
- npm run build: clean
- Closed-source product reference audit: clean
Add a write-time incremental aggregation engine that maintains running
totals on every add/update/delete for O(1) read performance. Integrates
into brain.find({ aggregate }) for a unified query API.
Core features:
- AggregationIndex with defineAggregate()/removeAggregate() API
- Five aggregation operations: SUM, COUNT, AVG, MIN, MAX
- GROUP BY with multiple dimensions including time windows
- Time window bucketing: hour, day, week, month, quarter, year, custom
- Materialization of results as NounType.Measurement entities
- Debounced persistence of definitions and state to storage
- Definition change detection via FNV-1a hashing with auto-rebuild
- Infinite loop prevention for materialized entities
- 'aggregation' plugin provider key for native acceleration
- Lazy initialization (created on first defineAggregate() call)
- 73 tests (unit + integration) covering all functionality
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Fix critical wiring bugs that prevented plugin-provided implementations
from being used at runtime. All CRUD operations, fork/checkout/clear,
batch embedding, neural APIs, and VFS path resolution now properly
dispatch through the plugin registry.
Changes:
- Wire graphIndex to storage for getVerbsBySource() fast path
- Replace instanceof checks with duck-typing (indexIsTypeAware flag)
so plugin HNSW indexes work in add/update/delete/search
- Add createIndex() shared helper for plugin HNSW factory
- Fix fork/checkout/clear to use plugin factories for metadataIndex,
graphIndex, and HNSW instead of hardcoding JS constructors
- Add three-tier embedBatch priority: embedBatch > embeddings > WASM
- Skip WASM warmup/eagerEmbeddings when plugin provides embeddings
- Fix PathResolver metadataIndex access (was looking on storage)
- Use global UnifiedCache in SemanticPathResolver
- Wire plugin distance function through neural APIs
- Add diagnostics() method and CLI command for provider inspection
- Add requireProviders() for production fail-fast assertions
- Add init-time provider summary log
- Add plugin developer documentation (docs/PLUGINS.md)
- Export DiagnosticsResult type
The __words__ keyword index stores 50-5000 entries per entity (one per
word), which inflated avg entries/entity well above the corruption
threshold of 100. This caused:
1. validateConsistency() to falsely detect corruption on every startup,
triggering unnecessary clearAllIndexData() + rebuild() cycles
2. getStats() to log false "Metadata index may be corrupted" warnings
and report inflated totalEntries/totalIds stats
Both methods now skip __words__ when counting, so stats and health
checks reflect metadata fields only (noun, type, createdAt, etc.).
Keyword search is unaffected since the __words__ field index itself
is not modified.
- Add native config option: `new Brainy({ integrations: true })`
- OData integration for Excel Power Query and Power BI
- Google Sheets integration with Apps Script
- Server-Sent Events (SSE) for real-time streaming
- Webhooks for push notifications
- Zero-config with sensible defaults
- Full tree-shaking when disabled
Delete dead code island that was never instantiated in production:
- OptimizedHNSWIndex (430 LOC)
- PartitionedHNSWIndex (412 LOC)
- DistributedSearchSystem (635 LOC)
- ScaledHNSWSystem (744 LOC)
- HNSWIndexOptimized (585 LOC)
- brainy-backup.ts stale example (903 LOC)
Also upgrades entry point recovery from O(n) to O(1) using existing
highLevelNodes index structure.
Production uses only: HNSWIndex (memory) and TypeAwareHNSWIndex (persistent)
- Removed ImportManager class and exports (use brain.import() instead)
- Fixed all documentation: getStatistics() → getStats()
- Updated 41 files across codebase for consistency
- Removed ImportManager section from API docs
- Added v3.30.0 migration guide to CHANGELOG
Co-Authored-By: Claude <noreply@anthropic.com>
Resolves API accessibility issues reported by Brain Cloud Studio team:
1. Export ImportManager and createImportManager
- ImportManager class was fully implemented but not exported
- Consumers can now access AI-powered import features
- Includes ImportOptions and ImportResult types
2. Add brain.getStats() convenience method
- Documentation showed getStats() as top-level method
- Implementation had it nested under brain.counts.getStats()
- Added convenience method that delegates to counts API
- Maintains backward compatibility
3. Update API documentation
- Corrected getStats() signature and return type
- Added comprehensive ImportManager documentation
- Included examples for all import patterns
These changes expose existing, tested functionality without
modifying core behavior. All tests pass.
Implement comprehensive conversation management system enabling AI agents
like Claude Code to maintain infinite context and history. Provides semantic
search, smart context retrieval, and automatic artifact linking using Brainy's
existing Triple Intelligence infrastructure.
Core Features:
- ConversationManager API for message storage and retrieval
- MCP protocol integration with 6 tools for Claude Code
- Context ranking using semantic, temporal, and graph scoring
- Neural clustering for theme discovery and deduplication
- Virtual filesystem integration for code artifact linking
- CLI commands for setup and management
Zero new infrastructure required - uses existing Brainy features:
- Storage via brain.add() with NounType.Message
- Relationships via brain.relate() with VerbType.Precedes
- Search via brain.find() with Triple Intelligence
- Clustering via brain.neural()
- Artifacts via brain.vfs()
One-command setup: brainy conversation setup
Version: 3.19.0
Major enhancements for type safety and developer experience:
- Add BrainyTypes static API for type management and AI-powered suggestions
- Implement strict type validation for all 31 NounType categories
- Remove dangerous generic add() method that bypassed type safety
- Add intelligent type inference with confidence scoring
- Provide helpful error messages with typo suggestions using Levenshtein distance
- Update all internal code, examples, and documentation to use typed methods
- Enhance CLI with new type management commands (types, suggest, validate)
Breaking changes:
- Remove deprecated add() method - use addNoun() with explicit type parameter
- All addNoun() calls now require explicit type as second parameter
This release significantly improves type safety across the entire system while
maintaining backward compatibility for properly typed method calls.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Replace hardcoded version string with dynamic reading from package.json
- Add version caching for performance
- Export getBrainyVersion function from main index
- Ensures version stays automatically synchronized with releases
