Auwai

Ledger

The ledger is one SQLite database per repository at .auwai/auwai.sqlite (or the [database] path in config.toml). It is the primary metadata store for the coverage architecture.

Shape

segments.chunk_ids is a JSON array rather than a foreign key. The diagram shows the logical relationship, not a database constraint.

Sync flow

The sync is one transaction. It preserves read state and findings for unchanged chunks, and marks a finding stale when its chunk leaves the index.

Tables

Table Purpose
meta Repository name, root, head, generated time, scope counts
files Path, hash, stat, scope, skip reason
chunks Chunk id, path, lines, symbol, kind, language, tokens, scope
partitions Tree id, parent, path, kind, language, tokens
coverage Indexed, mapped, read, finding, stale, last turn
findings Chunk id, text, purpose, tags, time, stale
reads Session, chunk id, turn, time
plans Full-read plan and its counts
segments Segment order, kind, partition, chunk ids, status
events Sync, read, finding, and segment events
chunk_fts FTS5 over path, symbol, label, and purpose

Sync

store.sync_index(repo) reads the JSONL index and the findings file. It replaces the file, chunk, partition, coverage, and FTS rows in one transaction.

It preserves:

It marks a finding stale when its chunk is no longer in the current index. It writes a sync event.

Exports

The JSONL and Markdown files remain exports:

The ledger is the source for the new commands. The planning commands still read the JSONL files. The two views must be kept in sync by index, refresh, and record.

Current limits

There is one database per repository. There is no migration tool yet; the sync rebuilds the ledger from the JSONL files. plan.sqlite remains the planning cache. The DDL is skills/auwai/schema/ledger.sql; the version is stored in meta and PRAGMA user_version.