dentm42

The question presumes that most of us are "thinking" in the first place, when in actuality, most of us are just acting according to the patterns that have emerged from our encounters with the thoughts of others. We generally adopt them and/or try to hallucinate coherence when they conflict. Very few people actually "think". It's hard work and takes time. We neither have (take) the time nor are we particularly motivated to put in the work because the patterns we have learned from others are useful enough to achieve the low goals we set for ourselves.

IOW - modern AI is simply an extension of the lack of thinking that characterizes the modern life... It just does it faster and uses a hulluva lot more energy.

aver record new --title "TODO: fix manual link" --status new --priority 1 --description "Proofread better! Fix the link in the HN comment" --use-id HN-001

aver note add HN-001 --message "HN comment uneditable (edit window expired). User should proofread and check links more carefully!"

aver record update HN-001 --status closed

git add . && git commit -m "proofreading issue -apologies!" && git push origin master

#and that's how you handle issues with aver and communicate them to fellow devs.

I’ve been building tracking systems since the mid-80s -- from church giving records on early micros to C-based ticket systems in the 90s ISP "Wild West." Over those decades, I’ve watched countless "platforms" vanish, taking their data with them.

I built Aver (pronounced "AH-ver") because I believe important knowledge should be an indestructible artifact. It shouldn't live in a SaaS silo or a complex SQL schema; it should live in your Git repo, alongside your code, as plain text.

## The "Markdown-as-Truth" Architecture:

*The Authority is the File*: Records are stored as {id}.md files with YAML frontmatter. Aver treats your filesystem as the database.

*Disposable Indexing*: We use SQLite strictly as a performance layer (a "Lens"). If the DB is lost, aver admin reindex rebuilds it from the source files in seconds.

*Solving Merge Conflicts*: 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