aver

To make a Git-based tracker work for teams, Aver uses a Record/Note model. Instead of appending to one file, every update is a unique, separate file. This allows multiple devs to update the same record in different branches and merge cleanly. ## Why this matters: *Digital Stewardship*: As a pastor and a dev, I value the "decades-long view." Aver is designed so your data is readable in 20 years with nothing more than a text editor. *Zero-Dependency*: No servers, no daemons, no background processes. It’s a single-script engine that operates only when you tell it to. *JSON I/O*: It includes a persistent JSON bridge so you can use it as a "storage engine" for automated workflows or custom front-ends without reimplementing the validation logic. ## Adaptability: Aver isn't just a bug tracker. Because the structure is defined in your ``config.toml``, it’s a "chameleon." It’s currently being used for everything from technical logs to editorial workflows and research logs. I'm interested in the community's thoughts on "Subsidiarity of Data"—the idea that the source of truth should reside at the lowest competent level: with the user, in their own repository. Repo: https://github.com/dentm42/aver Manual: https://github.com/dentm42/aver/docs/MANUAL.md