David Snelling
07754d135a
Per the Cortex team's audit, the BR-CX-INTERFACE-GAP boot crash was a
build/install artifact (stale node_modules, lockfile drift, Docker cache,
bundler quirks), not a plugin-bundles-brainy version-skew issue. Cortex's
MmapFileSystemStorage extends FileSystemStorage and inherits all 6
multi-process helpers via the prototype chain at runtime; the dynamic
ESM import to @soulcraft/brainy is preserved in cortex's dist.
- Rewrote the hasStorageMethod() doc comment to credit the real cause.
- Updated the init-time warning to point operators at the actual fix:
clean install or container rebuild to refresh node_modules.
- New docs/concepts/storage-adapters.md documenting the inheritance
contract: extend FileSystemStorage to inherit the multi-process
helpers, override supportsMultiProcessLocking() -> true to activate.
Includes a minimum checklist for adapter authors.
- New docs/architecture/multiprocess-storage-mixin.md as a future-
direction note: extracting the 7 methods into a
MultiProcessSafeStorage interface/mixin is the architecturally clean
next step, deferred to v8 or until a second multi-process capability
lands.
No behavior changes. Ships with the next release.
|
||
|---|---|---|
| .. | ||
| aggregation.md | ||
| augmentation-system-audit.md | ||
| augmentations-actual.md | ||
| augmentations.md | ||
| CLUSTERING_ALGORITHMS_ANALYSIS.md | ||
| data-storage-architecture.md | ||
| distributed-storage.md | ||
| finite-type-system.md | ||
| index-architecture.md | ||
| initialization-and-rebuild.md | ||
| multiprocess-storage-mixin.md | ||
| noun-verb-taxonomy.md | ||
| overview.md | ||
| PERFORMANCE_ANALYSIS.md | ||
| storage-architecture.md | ||
| triple-intelligence.md | ||
| zero-config.md | ||