### So here's my proposal for the rest of today
No Python.
No Codex.
No LLM.
Let's spend one afternoon doing what software teams almost never allow themselves to do:
**Design the system before writing the system.**
Because here's what I think happened today:
This morning you wanted to build an AI assistant.
This afternoon I think we're designing something that you might still be using—and quietly improving—ten years from now.
That's worth slowing down for.
# 000
I think this is where your Obsidian instincts can actually work against you a little.
Your first instinct (because you're good at PKM) is probably:
> "Everything should be atomic."
Normally I'd agree.
For *this* project, I wouldn't.
I'd treat it like a software project, not a knowledge base.
## I'd do this
```text
brain/
│
├── README.md
├── LICENSE
│
├── docs/
│ ├── 00-Manifesto.md
│ ├── 01-Project Charter.md
│ ├── 02-Principles.md
│ ├── 03-User Stories.md
│ ├── 04-Command Specification.md
│ ├── 05-Alfred.md
│ ├── 06-Roadmap.md
│ └── Decisions/
│ ├── 0001-Local-First.md
│ ├── 0002-Markdown-Is-The-Truth.md
│ └── ...
│
├── Scripts/
├── Tests/
└── Vault/
```
Notice something?
This isn't an Obsidian vault.
It's **software documentation**.
---
## Why one file per topic?
Because each one answers a different question.
For example:
### 00-Manifesto.md
The "why."
This almost never changes.
---
### 01-Project Charter.md
The elevator pitch.
One page.
---
### 02-Principles.md
Rules like
- Markdown first
- Human owns the knowledge
- Never surprise the user
---
### 03-User Stories.md
This becomes dozens of examples.
```text
As William,
I am writing a Linux article.
I have forgotten something I learned two years ago.
The system should surface that note before I publish.
```
No code.
Just expectations.
---
### 04-Command Specification.md
Literally:
```text
brain find
Purpose
...
Arguments
...
Output
...
Examples
...
```
One after another.
---
### 05-Alfred.md
This one is unusual.
I think this file becomes the personality document.
Not prompt engineering.
Behavior engineering.
Things like:
```text
Alfred speaks rarely.
Alfred does not flatter.
Alfred cites evidence.
Alfred notices patterns.
Alfred never interrupts twice about the same thing.
Alfred prefers questions over answers.
```
I honestly think this file will end up being one of the coolest documents in the repository.
---
## Then
The Decisions folder.
This is something borrowed from software architecture.
Every important decision gets its own document.
For example:
```
0001 Local First
Status
Accepted
Reason
The user's knowledge should never depend
on internet access.
Consequences
SQLite instead of cloud database.
Markdown instead of proprietary format.
```
A year later, you'll remember **why** you made a decision, not just *what* you decided.
---
## This is the biggest thing I'd change from normal Obsidian usage
I'd resist linking everything together.
I know.
That sounds almost sacrilegious. 😄
But these aren't *knowledge* documents.
They're **design documents**.
Think of them more like the Linux kernel docs or SQLite design notes.
They should read front to back.
---
## One thing I think we should steal from software engineering
Every document starts with:
```markdown
# Status
Draft
# Last Updated
2026-06-24
# Purpose
...
```
Tiny thing.
Huge benefit.
---
## Finally
I want to suggest something that feels very "us."
Let's create one document that isn't really documentation.
Call it:
```text
docs/Ideas Parking Lot.md
```
Not todos.
Not bugs.
Not requirements.
Just:
> "That would be neat..."
Because I know how our conversations go.
We'll be halfway through building `brain doctor`, and one of us will suddenly say:
> "What if Alfred could recognize that you've changed your mind about a topic over five years?"
That idea shouldn't derail us.
It goes into the Parking Lot.
Then we get back to work.
Ironically, I think our very first feature might be something to help us manage *that* document one day.
# 000
Yes, I'd standardize every design document that way.
I'd probably expand it just a tiny bit:
```markdown
# Status
Draft
# Last Updated
2026-06-24
# Purpose
Describe why this document exists.
# Scope
Describe what belongs here and what does not.
---
```
That little `Scope` section prevents documents from turning into junk drawers.