Skip to content

CodeNib 0.2.3

CodeNib 0.2.3 narrows the product database boundary to the Wiki domain. The public codenib.storage name is now a single-file, lazily loaded facade for WikiStore, its SQLiteWikiStore implementation, and their Wiki-specific types and errors. It no longer provides a generic repository catalog, content addressed store, job system, or backend registry.

python -m pip install --upgrade "codenib[graph,mcp]==0.2.3"
codenib --version

Wiki-only storage

Applications that need to inject or open the supported Wiki store can import the complete public boundary from one module:

from codenib.storage import SQLiteWikiStore, WikiStore

WikiStore owns complete Wiki cache envelopes and only the operations used by the Wiki consumer: reading, atomic publication, maintenance scans, and generation serialization. SQLiteWikiStore stores those envelopes in wiki_cache/wiki.sqlite3 with a versioned one-table schema, SQLite WAL, bounded canonical JSON, record digests, short transactions, and cross-process generation guards.

AgentWiki, the Web service, cache audit, prewarming, and Wiki benchmarks now share that database boundary. Eligible entries from the earlier JSON cache remain available through read-through compatibility; CodeNib does not rewrite or delete those source files during a read.

Repository indexes remain artifacts

RepoManifest, BM25, FAISS, igraph, and portable context payloads remain manifest-bound file artifacts. Existing compiler caches can be packaged with codenib artifact pack; portable artifacts remain supported by codenib artifact verify and codenib mcp --artifact.

No catalog data is migrated into WikiStore. Wiki cache entries and repository artifacts have separate ownership and lifecycle contracts, and sharing SQLite does not make them one storage abstraction.

Removed generic storage surface

The v0.2.2 generic codenib.storage package, including SQLiteCatalog, LocalCAS, storage protocols, schema state, and backend discovery, is removed. The artifact import-cache, artifact materialize, storage audit, and retained index-publication commands are also absent from 0.2.3. Unreleased Web index jobs, retained BM25 activation, durable storage workers, catalog-backed clangd FactBatch reuse, and their configuration surfaces are removed without changing the normal index, Wiki, publish, portable-artifact, or MCP routes.

Upgrade from 0.2.2

  • A v0.2.2 SQLite catalog cannot be opened by 0.2.3. Before upgrading, use a pinned CodeNib 0.2.2 environment and its artifact materialize command to produce a portable context artifact. Upgrade only after codenib artifact verify succeeds for that artifact.
  • Do not migrate catalog rows into WikiStore; it accepts Wiki cache envelopes, not repository refs, snapshots, CAS objects, jobs, or leases.
  • Existing compiler cache directories do not need a catalog migration. Use codenib artifact pack when a portable copy is required.
  • The 0.2.2 source-selection and manifest compatibility rules remain in force; normal repositories can be re-indexed or reused through their existing manifest-bound routes.