Personal Website as Operating System
A working idea for turning this site into the front door for projects, memory, learning, photography, finance, and the Digital Wei assistant.
Treat the personal website as a small operating system: public pages are the shell, Markdown notes are files, private dashboards are tools, backlinks become durable memory, and Codex-produced products feed lessons back into the garden.
## Thesis
A personal website can be more than a portfolio. It can become a small operating system for public identity, private tools, long-term notes, and personal data products.
That does not mean the website should become complicated. The strongest version is boring in the right places: stable URLs, readable notes, private tools where privacy matters, and simple public pages that can survive deployment changes. This is why the Digital Garden should stay close to plain Markdown while still supporting backlinks, status, and long-form reading.
The current site already contains several subsystems:
- A home/about page.
- Digital Wei as a conversational interface.
- Photography publishing through cloud albums.
- A private ETF dashboard.
- Experiments with Cloudflare, PicX, R2, and deployment routing.
- A Codex-supported product loop for turning repeated implementation work into notes, checks, and recovery playbooks.
> The garden is not a blog feed. It is a durable map of reusable concepts that can keep improving as the rest of the site evolves.
The closest public inspiration is the evergreen-note tradition described by [Andy Matuschak](https://notes.andymatuschak.org/Evergreen_notes) and the long-form page craft seen on [Gwern.net](https://gwern.net/).[^inspiration]
## Why a Website Can Behave Like an Operating System
An operating system coordinates small programs, files, permissions, memory, and user interaction. A personal website can do the same at a smaller human scale:
| Layer | Website version | Current example |
| --- | --- | --- |
| Shell | Public navigation and homepage | Home, Photography, Garden |
| Files | Long-lived content | Markdown notes in `content/garden/` |
| Services | Private tools and APIs | Digital Wei, finance import, photo APIs |
| Memory | Durable references | Soul notes and backlinks |
| Permissions | Public/private boundary | Login and admin-only areas |
This framing is useful because it prevents every feature from becoming a separate island. [[cloudflare-r2-d1-pages|Cloudflare R2 and Pages]] should serve the same system as [[photography-archive-system]], and [[etf-portfolio-dashboard]] should remain a private tool inside the broader personal-site structure.
## Design Principle: Keep the Core Plain
The first rule is to keep core knowledge portable. Markdown files are easy to read outside the app, easy to version, and easy to transform later. The site can add rendering behavior around them, but the notes should remain understandable as text.
A note should answer one reusable question. If it becomes too large, split it and connect the pieces:
```markdown
[[photography-archive-system]]
[[cloudflare-r2-d1-pages|Cloudflare deployment notes]]
```
That small convention is enough to create backlinks and related concepts without needing a database.
## Public, Private, and Personal
The system needs three zones.
### Public
Public pages should help visitors understand the work and ideas without logging in. The Digital Garden belongs here, along with the photography page and selected project notes.
### Private
Private areas should hold account-specific, sensitive, or experimental tools. Finance data belongs here because it is personal and can easily be mistaken for advice if presented too openly.
### Personal
Some information should exist only as private local context for the assistant or for admin workflows. The website can still coordinate it, but it does not need to publish it.
## How This Changes Writing
A blog post usually asks, "What happened recently?" An evergreen note asks, "What idea should still be useful later?"
That shifts the writing style:
- Prefer stable claims over daily updates.
- Keep examples concrete.
- Link concepts instead of repeating context.
- Use `seed`, `growing`, and `evergreen` honestly.
- Revisit older notes when the project changes.
For example, this note is marked evergreen because the framing is meant to remain useful even as the implementation changes. A note like [[future-edge-cache-playbook|future edge cache playbook]] can start as a missing seed until there is enough real experience to write it.
## Implementation Shape
The current implementation is intentionally small:
1. Vite imports Markdown files from `content/garden/`.
2. Frontmatter becomes note metadata.
3. Wiki-links become internal `/garden/:slug` links.
4. Backlinks are computed by scanning all note bodies.
5. The reader view adds table of contents, heading anchors, footnotes, and a metadata panel.
This keeps the system understandable. If the garden later moves to Cloudflare D1, R2, or a build-time indexer, the note format can remain mostly the same.
## Recent Update - 2026-W26
The operating-system frame now has a weekly maintenance layer through [[weekly-review-2026-w26]]. That makes the site more than a set of public pages: it becomes a place where product work, automation evidence, and infrastructure decisions can be reviewed without exposing private inbox material.
## What Should Not Happen Yet
The site should not start with a full graph database, live editor, or complex knowledge-management backend. Those may become useful later, but they would currently add more maintenance than insight.
The right first version is:
- Local notes.
- Stable slugs.
- Human-readable Markdown.
- Good reading layout.
- Clear note maturity.
- Search and filters.
- Backlinks that are computed simply.
## Durable Question
What should live as public knowledge, what should stay private, and what should become context for Digital Wei?
The answer will probably change. That is why the garden exists: not to freeze the project, but to make the changes legible.
[^inspiration]: This site is not trying to clone either source. The useful lesson is the writing discipline: stable addresses, dense links, patient revision, and pages that are worth returning to.
:::details Implementation checklist
Use this section as a compact test of collapsible garden content.
- Keep Markdown readable without the React app.
- Use wiki-links for internal concepts.
- Keep external links explicit.
- Prefer `related` frontmatter for intentional concept relationships.
- Let backlinks reveal accidental relationships.
:::
Open this garden note