Goal
Your team picked a database. Six months from now someone will ask why. You want the answer, and the option you turned down, written where Guild Stack and your team will find it.
The result
One description and one approval later, .guild/wiki/decisions/ holds a
page that names the choice (SQLite) and the rejected option (Redis), where
your team and later Guild Stack runs can read it. Here is the flow.
Commands
In Claude Code, in the project folder, after /guild:init, describe the
decision in plain words:
Capture this decision with Guild's decision-capture workflow (significance: high; asker and owner: operator):
Question: which local state store should fixture-store use?
Decision: SQLite in WAL mode, because there is a single writer and we need crash-safe restore. Rejected: Redis (adds a server and a failure domain).
Then promote the staged candidate into the wiki through Guild's harvest promotion.
Guild Stack first stages the decision for review. Approve the promotion when it asks.
What Guild Stack produced
- A staged copy of the decision under
.guild/knowledge/(incandidates/decisions/) before you approve it. - After approval, a page in
.guild/wiki/decisions/that names SQLite and the rejected Redis option. The page starts with a metadata header.
.guild/wiki/index.md.
Open it directly from .guild/wiki/decisions/. A fix is tracked
on that issue and lands through the beta (next) channel first.
Finding it later
Ask the wiki, as in Onboard an existing repo:
/guild:wiki query "state store"
Time and cost
The test suite allows up to 20 minutes for init, capture, and promotion on a tiny project. Token cost is not measured by this scenario.
New to Guild Stack? Install it first.