CodeNib v0.2.3

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.