git blame tells you who wrote a line. Your project's memory knows why it's there. Publish it next to your code, and anyone can ask.
Free for public projects · no credit card
#[derive(Debug, Clone, Serialize, Deserialize)] pub struct Config { /// Schema version for migration support. Missing = v0. #[serde(default)] pub version: u32,Serkan · 8 months ago /// Repository setup mode pub repo_mode: RepoMode,
Why does every saved struct carry its own version field?
Stele · read 2 notes
Inline schema versioning with a v0 fallback
Each saved struct has a version: u32 field. Migration code lives in the struct's own module, so there's no separate migration layer to keep in sync.
There's an old rule: don't tear down a fence until you know why someone put it up. Code is full of them. A check that looks redundant. A dependency pinned to an old version. A pattern that seems clumsy until you hit the bug it prevents.
The reason is almost never in the code. So people take the fence down, in good faith, in a pull request.
Refactor: move all config migrations into one migrations module
“The migration code is scattered across every struct. This puts it in one place.”
You, again: “It's spread out on purpose. Each struct carries its own version and migration, so there's no separate layer to keep in sync…”
Would a central migrations module be cleaner?
Stele: DotState decided against that. Each saved struct carries its own version and migration, so there's no separate migration layer to keep in sync.
decisionKNOW-14Add a migration for the new profile field, next to its struct
Same contributor, same good intentions. The only difference is whether the reason could be found before the work started.
Anyone can ask your project a question, without an account. They learn what was tried and why it was dropped before they spend a weekend on it.
Right now the reasons live in your head. When you're busy, burned out or moving on, they go with you. Published, they stay with the project and outlast any one maintainer.
Before adopting a library, ask it what its maintainers worry about. Known risks and past incidents are there, with sources. That tells you more than a star count does.
DotState is a dotfile manager written in Rust. Its memory was written by the agents that built it. Read the graph, or ask Stele.
github.com/serkanyersen/dotstate
Ask Stele about DotState
Answers from the project's memory, with sources.
No account needed for your first questions.
Cargo.lock is committed to the repo, because DotState is a binary crate
A Vercel “Configuration error” on the website deploy was a vercel.json schema rejection
The CLI surface: 15 top-level commands, plus profile and package subcommands
Stele works alongside the coding agents you already use. Decisions, lessons and risks get written down while the context is fresh.
Claude Code, Cursor, Codex or any MCP client. Your agent reads the memory before it starts, and adds to it as it works.
Every note links to what caused it and what it replaced, so a reader can follow the story from the first attempt to the code in the repo.
Your project gets a public page with the graph, and anyone can ask it questions. Claim an address that matches your repo.
app.stele-ai.dev/your-name/your-repoOne badge takes readers from your repo to the reasons behind it.
memory bysteleProjects are private until you make one public, one at a time, and you can switch it back. Everything else you work on stays private.
How public projects workYour agents write the reasons down as they work. Make them public, and the next person finds them before they start.