Use cases / Engineering decisions

Engineering decision records

Working across repositories, decisions scatter — why this architecture, why that dependency, what the migration plan was. It ends up in Slack threads, PR comments, and memory. In Intabula, each repository gets a collection of decision records, and the agent can read the actual code and history while writing them.

The setup

Create a collection per repository — decisions/backend, decisions/ios — and attach each repo as a read-only linked folder. The agent gets git_log, git_show, and git_diff on that path plus file reading and search, and nothing else: the fence is resolved to real paths, sensitive files like .env are blocklisted (including in Git history), and the working tree is never touched.

Notes about the code, verifiably

"Write up why we switched the queue implementation — check the actual diff" produces a decision record grounded in the commit rather than in anyone's memory. Ticket notes carry the file references they discuss; architecture notes cite the code they describe.

Structure emerges as fields recur

You don't design a decision-record template upfront. Write notes as work happens; when status, ticket, and decided_on keep recurring, Intabula offers to promote them to typed columns. From then on the collection sorts and filters like a database — open decisions grouped by status on a board, sorted by date in a table.

Why not just keep notes in the repo

Repo-adjacent Markdown works until you need to see decisions across repositories, filter by status, or search them from your phone. Intabula gives each repo's collection its own context and schema while keeping everything in one vault — as plain files, greppable and portable like the rest of your notes.