Data integrity comes first. Avoid forced legacy rebuilds; upgrades must be atomic, repeatable, and recoverable after crashes or power loss. Read data safety before changing storage or migration code. Implementation is not complete until tests establish database safety for the affected behavior. Unresolved safety risks or missing safety coverage block completion.
Read development and workflow before changing code. Read the relevant topic below when working in that area; there is no need to load every rule file.
| Work area | Guidance |
|---|---|
| Reproductions, tests, fuzzing, CI evidence | Validation |
| PR safety section, removing/skipping tests, fault hooks, CI changes | Safety evidence |
| File formats, upgrades, persisted indexes | Compatibility |
| Transactions, cursors, WAL, disposal, buffers | Storage and ownership |
| LINQ/SQL translation, expression and statement caches | Query expressions |
| Index planning, INCLUDE, sorting, LIKE, vectors | Query execution |
| BSON, mapper contracts, public API behavior | Mapping and serialization |
| Benchmarks and memory measurements | Performance |
| Source generators, trimming, AOT | Code generation |
The library is in LiteDB/; tests are in LiteDB.Tests/. Use gh for GitHub.
Issues and PRs normally belong to litedb-org/LiteDB; verify the actual PR head
repository before pushing. New work normally targets dev.
Keep this file as an entry point. Add durable lessons to the relevant rule file, prefer links to existing design docs and tests, and remove superseded guidance. Do not add task logs, individual bug histories, or benchmark results here. The session review records the sources and limits of the initial cleanup.