# ADR 014: Basic Memory and SilverBullet for an extensible agentic knowledge base

- HTML version: https://robbiepalmer.me/projects/homelab/adrs/014-basic-memory-silverbullet-agentic-knowledge-base
- Project: Home Lab (https://robbiepalmer.me/projects/homelab.md)
- Status: Proposed
- Date: 2026-08-15

# Context

I want a private second brain for personal, free-form, structured, and
semi-structured writing, potentially including diary-like material. It is not
the publication system for this site: useful ideas can graduate into blog posts
or project documentation later, but the working knowledge base should optimize
for thinking rather than publishing.

I previously used Roam Research and Notion. Notion is good when collaborating
with non-technical people, but collaboration is not a requirement here. Roam's
linked blocks were powerful, but its daily-note-first workflow did not fit how I
work, and maintaining its ontology and connections became more work than
creating the content. A new system must not reproduce that failure with a
self-hosted graph.

The main interface is different now. I already run Claude Code, Codex, Grok
Build, and opencode through
[t3-code](/projects/homelab/adrs/006-t3-code) on the Mac mini and can reach
those agents from Android, macOS, and Ubuntu over
[Tailscale](/projects/homelab/adrs/000-tailscale). I want to ask an agent to
capture, find, connect, reorganize, summarize, or critique material in natural
language. The notes application does not need its own AI subscription or chat
surface; it needs to be an **agent-operable knowledge substrate** behind the
interface I already have.

Beads has proved this interaction model for task management at work: a focused
CLI and structured graph give both me and the agents one durable system to
operate, without making me translate every intent into application clicks. I
want the knowledge equivalent—less task-oriented, comfortable with free-form
writing, and able to accumulate durable context across agent sessions.

Requirements, in priority order:

1. **Agent-operable data.** Local agents must be able to search and change the
   complete corpus using ordinary filesystem tools, a CLI, HTTP API, or MCP.
   Agent access cannot be limited to copying text through a GUI.
2. **Durable ownership.** The canonical content must remain readable outside
   the application and straightforward to version, back up, migrate, and
   inspect.
3. **Flexible structure without mandatory gardening.** Plain prose, links,
   tags, and typed metadata should coexist. The system may help produce a
   knowledge graph, but it must not require me to maintain a perfect ontology
   before I can write.
4. **Good access everywhere.** A polished application is preferred, but a good
   PWA is acceptable. Android, macOS, and Ubuntu must all work; offline mobile
   editing is useful but not essential.
5. **Private and single-user.** No collaboration or public publishing is
   required. Agent and administrative access should remain on the tailnet with
   no public ingress. A hosted sync relay is acceptable only with end-to-end
   encryption.
6. **Low incremental cost.** Prefer free and self-hosted. A service costing no
   more than about $5/month is acceptable only after it proves its value.
7. **Extensible without trapping the corpus.** The client should have credible
   paths into future workflows, but extensions must remain optional views and
   tools over durable knowledge rather than make their private formats the
   source of truth. Prefer extension models benefiting from broader agent,
   Markdown, and local-first adoption; bespoke customization must stay small
   enough that owning it is an advantage rather than a new hobby.

# Decision (proposed)

Run a pilot with **Basic Memory as the agent-facing knowledge engine** and
**SilverBullet as the human-facing notes application and programmable view**,
both operating over the same Markdown folder on the always-on Mac mini.

This intentionally separates responsibilities:

* **Markdown is the source of truth.** Every note remains an ordinary file that
  Git, backup tools, text editors, and future applications can understand.
* **Basic Memory is the Beads-like agent interface.** Its local, open-source
  edition is a
  [file-first knowledge engine](https://docs.basicmemory.com/reference/technical-information)
  with a derived search index, a `bm` CLI, a file watcher, and a native MCP
  server. Its
  [MCP tools](https://docs.basicmemory.com/local/mcp-tools-local) include note
  search, read, write, section editing, schema operations, and graph-aware
  context building. Agents without MCP support can use the CLI and its JSON
  output or ordinary file tools.
* **SilverBullet is the human editor and programmable view.** Its
  [Docker installation](https://silverbullet.md/Install/Docker) mounts an
  ordinary folder as its space, while its
  [offline-first PWA](https://v2.silverbullet.md/Sync) provides an app-like
  Android experience and browser access from macOS and Ubuntu. Its primary
  extension mechanism is made from Space Lua scripts, templates, and Markdown
  pages inside the space, so agents can inspect and change the behavior using
  the same file and Git tools as the knowledge itself.

Basic Memory's
[knowledge format](https://docs.basicmemory.com/concepts/knowledge-format) is
normal Markdown plus optional YAML frontmatter, categorized observations, tags,
and typed wiki-link relations. Notes can remain free-form; agents can add those
patterns when they improve retrieval. The resulting graph is derived from the
files, and Basic Memory's schemas are optional, warning-oriented tools that can
be introduced only after repeated structures emerge. Its own documentation
explicitly says the human does not need to write observations and relations by
hand.

SilverBullet independently indexes wiki links, frontmatter, tags, and Markdown
objects for its UI and queries. The two derived indexes may be rebuilt; neither
owns the knowledge. SilverBullet
[reindexes external file changes](https://v2.silverbullet.md/Objects), so a
note written through Basic Memory or directly by an agent becomes visible in
the PWA.

This makes two deliberate rising-tide bets without coupling them. Basic Memory
bets on Markdown, MCP, CLI automation, and reusable agent skills. SilverBullet
bets on open, end-user-programmable software at the same time that capable
agents are making small custom tools dramatically cheaper to create. Either
layer can be replaced without migrating the other. This is the knowledge
analogue of the successful Beads pattern: a purpose-built agent CLI and graph
rather than a GUI integration bolted on later. Unlike Beads, the schema does
not force everything into tasks, statuses, and dependencies; free-form prose
remains a first-class artifact.

## Extension policy

Cheap code is not free ownership. An agent can write a useful command or view
quickly, but upgrades, tests, security, documentation, and interaction design
remain maintenance. The pilot therefore distinguishes **micro-extensions**
from **product development**.

* Use built-in behavior first. For an observed gap, compare a reusable library
  with a small agent-authored Space Lua library on usefulness, trust, and
  maintenance; do not assume either source is automatically better. Compiled
  TypeScript plugs are the last resort.
* Keep custom libraries small, needs-driven, documented, and versioned with the
  space. An agent encountering the repository should be able to explain and
  modify them without reconstructing hidden application state.
* Preserve durable semantics as Markdown, YAML frontmatter, tags, and links.
  An extension may provide commands, templates, queries, widgets, styles, or a
  virtual page, but cannot become the only representation of knowledge.
* Review extension changes through Git and test them against a disposable copy
  of the space before changing the live corpus.
* Do not build a second agent system inside the editor. Basic Memory and
  t3-code remain the stable agent contract; SilverBullet extensions serve
  human workflows or genuinely missing capabilities.

SilverBullet's
[Library Manager](https://v2.silverbullet.md/Library) distributes libraries as
collections of Space Lua, templates, and pages, usually through Git-backed
spaces. Its documented extension surface covers commands, slash and page
templates, widgets, styles, virtual pages, event handlers, and maintenance
pages. Lower-level
[plugs](https://v2.silverbullet.md/Plugs) run in isolated workers and cover
product-sized features such as graph views, PDF support, Mermaid, Draw\.io, and
Excalidraw. If a desired workflow cannot stay in the first, legible category
and repeatedly pushes into the second, that is evidence for buying a more
polished client rather than endlessly rebuilding one.

## Deployment and data layout

* Make the live space a private Git repository on the Mac mini's internal
  storage. Git records reviewable agent changes and makes bad reorganizations
  easy to undo; it is history, not the only backup.
* Install the free local Basic Memory CLI on the Mac mini, register the live
  space as one project, and expose `bm mcp --project <name>` to each compatible
  t3-code agent. Keep its SQLite data as a disposable index outside the Git
  repository; `bm reset` can rebuild it from the files.
* Run a digest-pinned SilverBullet container on the Mac mini, listening only on
  localhost, with the same live space mounted as `/space`. Drop unnecessary
  Linux capabilities and enable the container runtime's no-new-privileges
  control.
* Use the connected external drive for scheduled, versioned backups of the
  space, including attachments and Git metadata. Monitor the job and available
  space through the lab's existing Netdata alerting. Monitor SilverBullet and
  Tailscale Serve availability there too. The live corpus must not depend on
  the removable drive being mounted, and sync is not a backup.
* Put the PWA behind Tailscale Serve, proxying the localhost service over HTTPS
  to the tailnet only. Tailscale documents this exact private reverse-proxy
  pattern in [Tailscale Serve](https://tailscale.com/docs/features/tailscale-serve).
  Do not use Funnel or expose the container port to the LAN or internet.
* Keep SilverBullet authentication enabled as defence in depth. Disable its
  shell backend initially because the t3-code agents already provide the
  automation layer and SilverBullet documents that plugs can otherwise
  [execute shell commands](https://v2.silverbullet.md/Install/Configuration).
  Do not install an in-editor AI system during the pilot; Basic Memory and the
  existing t3-code agents already own that responsibility.
* Grant agents access to the notes space, but not to the rest of the external
  drive. Invoke a cloud-backed agent over diary-like content only deliberately;
  do not add a background process that uploads the corpus. Content may be sent
  to the selected model provider when an agent is asked to work on it;
  self-hosting the files does not make a cloud agent local.

## Agent workflow

The initial workflow should stay deliberately small:

1. I capture a note without having to choose a type, folder, or complete set of
   links.
2. From t3-code, I ask an agent to search, summarize, connect, split, merge, or
   restructure knowledge. The agent uses Basic Memory's MCP tools or `bm` CLI
   for graph-aware work and falls back to normal file operations when that is
   simpler.
3. Before a broad graph-driven mutation, the agent lets file watchers settle
   and reads each target file from disk; an index is for discovery, not
   authority. It then checkpoints the Git worktree, makes small inspectable
   edits, and records the result in Git. Agents must not rewrite existing
   checkpoints or force-push the live corpus. Git is an audit and undo
   mechanism, not a pull-request ceremony for every thought.
4. Agents may add lightweight observations, frontmatter, and wiki-link
   relations when they are useful, but no fixed ontology is required during
   the pilot. Repeated natural structures can graduate into optional Basic
   Memory schemas, SilverBullet queries, or small Space Lua libraries later.
5. Material intended for publication is copied and rewritten into this site's
   existing reviewed Markdown workflow. The private knowledge base is never
   published directly.

Avoid simultaneous human and agent edits to the same note. Sync conflicts and
Git make concurrent changes recoverable, but they do not provide a semantic
merge of two rewrites.

## Pilot acceptance criteria

Keep the ADR Proposed until the pilot demonstrates all of the following:

* Capturing and editing notes on Android is comfortable enough to use without
  reaching for another notes app, including after an offline edit and
  reconnect.
* Each t3-code agent can discover the Basic Memory workflow, answer corpus-wide
  questions, and make a multi-note reorganization with a clear, reversible
  diff through MCP, the CLI, or both.
* Graph-aware retrieval finds useful connected context more reliably than
  plain text search alone.
* Links and metadata improve retrieval without creating a new manual gardening
  habit.
* At least two real, previously unmet needs are tested against SilverBullet's
  extension surface. At least one should be satisfied with built-in behavior or
  a reusable library, and one with a small agent-authored Space Lua library.
* Each adopted extension saves more work than it creates, remains explainable
  to a fresh agent session, survives a SilverBullet upgrade, and can be disabled
  while leaving the underlying notes intelligible and editable.
* A restore from the external-drive backup succeeds into a clean test
  directory.
* The service, sync, backup, and disk-space failures are visible rather than
  silent.

If SilverBullet's editing experience stops me writing, or useful customization
repeatedly becomes product development rather than a small library, keep Basic
Memory and open the same project as an Obsidian vault. Basic Memory officially
supports that
[integration](https://docs.basicmemory.com/integrations/obsidian/), so it is a
client swap rather than a knowledge migration.

# Comparison

The table is directional rather than pretending that subjective workflow
choices have precise scores. `++` is a strong fit, `+` is workable, `~` is a
meaningful compromise, and `-` conflicts with the requirement.

| Option                           | Agent interface                    | Durable/open corpus                        | Cross-device UX                    | Relevant extension leverage                      | Privacy/cost               | Fit          |
| -------------------------------- | ---------------------------------- | ------------------------------------------ | ---------------------------------- | ------------------------------------------------ | -------------------------- | ------------ |
| **Basic Memory + SilverBullet**  | `++` native MCP, CLI, files        | `++` canonical Markdown                    | `+` offline PWA                    | `++` built-ins plus agent-writable Lua/libraries | `++` local, free           | **Pilot**    |
| **Basic Memory + Obsidian Sync** | `++` MCP, CLI, files, Obsidian CLI | `++` canonical Markdown                    | `++` native Mac/Linux/Android      | `+` huge registry; much relevant overlap         | `+` E2EE, $4–5/month       | Fallback     |
| **Basic Memory Cloud**           | `++` hosted MCP and local CLI      | `++` Markdown with local sync              | `++` hosted web/mobile             | `+` young but fast-moving agent/skills surface   | `-` hosted, $15/month      | Rejected     |
| **Obsidian + self-managed sync** | `++` files and CLI                 | `++` canonical Markdown                    | `+` native apps, fragile sync edge | `+` same registry; custom sync burden            | `++` self-hosted, free     | Not selected |
| **TriliumNext**                  | `+` ETAPI and scripts              | `~` canonical database, exports            | `+` desktop/web; mobile PWA online | `+` powerful scripting/widgets; active project   | `++` self-hosted, free     | Rejected     |
| **Joplin + Joplin Server**       | `+` terminal app and REST API      | `+` Markdown bodies, app-managed sync data | `++` native Mac/Linux/Android      | `+` mature API and 300+ plugin registry          | `++` self-hosted, free     | Rejected     |
| **Notion**                       | `++` official MCP and API          | `~` SaaS blocks; Markdown export is a copy | `++` polished web/native clients   | `++` large integration and SaaS platform         | `~` free solo tier, hosted | Rejected     |
| **Roam Research**                | `++` official MCP, CLI, and APIs   | `~` SaaS graph with exports                | `+` web/native clients             | `+` extension API and Roam Depot                 | `-` hosted, $15/month      | Rejected     |

## Ecosystem and rising-tide assessment

Extension count alone is not architecture. The useful question is whether an
option's extension model is active, aligned with likely future needs, and safe
to leave without a data migration.

* **Basic Memory is the protocol bet.** It is a young `v0.x` project, so its
  product and community are less proven. Its active
  [release history](https://github.com/basicmachines-co/basic-memory/releases),
  open Markdown format, MCP/CLI surface, and
  [cross-agent skills](https://github.com/basicmachines-co/basic-memory-skills)
  are nevertheless aligned with a wider move toward agent-operable local data.
  If Basic Memory loses momentum, the files and Git workflow survive.
* **SilverBullet is the agent-buildable platform bet.** It is open source and
  actively released. Most high-level customization is ordinary Space Lua,
  templates, and Markdown pages inside the corpus rather than a separate Node
  project. Agents make that unusually cheap to create, review, and adapt. The
  smaller ecosystem remains a maturity risk, but a rising tide in generated
  software favors a legible, programmable platform when the needed behavior is
  a command, query, template, dashboard, or widget—not a whole application.
* **Obsidian is the packaged-ecosystem bet.** Its official
  [community registry](https://github.com/obsidianmd/obsidian-releases) has more
  than 6,000 plugins and a documented
  [TypeScript API](https://docs.obsidian.md/Plugins/Getting%20started/Build%20a%20plugin).
  Raw breadth is misleading here, though. Dataview-style queries overlap
  SilverBullet's object index;
  templating and quick capture overlap its commands and templates; Git plugins
  overlap the existing agent/Git workflow; and REST/MCP, semantic search, and AI
  plugins overlap Basic Memory and t3-code. Tasks, calendars, daily notes, web
  clipping, collaboration, and publishing are explicitly unimportant or a poor
  workflow fit. Obsidian's ecosystem becomes decisive only when a **specific**
  product-quality plugin solves an observed recurring need better than a small
  SilverBullet library.
* **Joplin and TriliumNext are durable open-source tides**, with mature plugin
  APIs in Joplin and deep scripting plus ETAPI in Trilium. Their extensions are
  more tightly coupled to application-managed storage and conventional notebook
  or hierarchy-first models, so their momentum does not compensate for weaker
  substrate fit.
* **Notion and Roam have credible modern agent surfaces.** Notion's official
  MCP/API and integration marketplace are substantial, and Roam now has
  official MCP and CLI packages alongside its extension API. Those ecosystems
  compound the value of their hosted data models; they do not fix ownership,
  cost, or the known workflow mismatch.

# Alternatives

## Basic Memory Cloud

* **Pros**: The same Markdown knowledge format and MCP contract as the local
  edition, with a hosted web application, cross-device access, sync, and
  snapshots. It removes most of the operations in this ADR.
* **Cons**: The current hosted plan
  [starts at $15/month](https://www.basicmemory.com/pricing), well above the
  $5/month ceiling, and the Mac mini already supplies the persistent host and
  agent access it would replace. Diary-like material would also gain another
  cloud storage boundary.
* **Decision**: Rejected. Use the free AGPL local edition and retain the option
  to reconsider cloud sync without migrating the Markdown format.

## SilverBullet without Basic Memory

* **Pros**: The simplest deployment. Agents can edit Markdown directly or use
  SilverBullet's file-oriented HTTP and runtime APIs, and its own links, object
  index, queries, and programmable libraries cover much of the human browsing
  need.
* **Cons**: Direct file tools provide no consistent, graph-aware contract across
  the four agents. Coupling the agent contract to editor extensions would also
  make replacing the human client harder. Basic Memory more closely matches
  the part of Beads that is working: a dedicated CLI/MCP surface, JSON output,
  consistency checks, and a rebuildable index designed for agents.
* **Decision**: Rejected. Keep the notes UI and agent knowledge engine separate
  while letting them share the same durable files.

## Basic Memory with paid Obsidian Sync

* **Pros**: The strongest polished-client and extension option over the same
  Basic Memory folder. Obsidian has native Android, macOS, and Linux apps while
  keeping each vault as local Markdown. Its new
  [official CLI](https://obsidian.md/help/cli) can search, read, create, and
  manipulate the vault, and the
  [headless Sync client](https://obsidian.md/help/sync/headless) explicitly
  supports agents and automated workflows without the desktop app. Sync is
  end-to-end encrypted and costs
  [$4/month annually or $5 monthly](https://obsidian.md/pricing), exactly at the
  budget ceiling.
* **Cons**: Obsidian's core is proprietary. Sync is hosted synchronization, not
  a self-hostable server, and Headless Sync is still in open beta. Community
  plugins run with broad application permissions and vary in maintenance
  quality. There is no web client, and ecosystem enthusiasm can itself become
  configuration gardening.
* **Decision**: Keep as the polished-client fallback. Move only when an observed
  plugin need or sustained PWA friction makes its native UX and supported sync
  worth the subscription; do not choose it for the abstract registry count.

## Obsidian with self-managed synchronization

* **Pros**: Keeps Obsidian's excellent native clients, graph, plugin ecosystem,
  local Markdown, and the Basic Memory agent layer without a subscription. A
  Mac mini could host Git, WebDAV, Syncthing, or a community LiveSync backend
  over Tailscale.
* **Cons**: Obsidian does not provide a first-party self-hosted Sync server.
  Combining community plugins and different mobile filesystem behaviours makes
  conflict handling and background synchronization the most fragile part of
  the system. That is exactly the kind of infrastructure gardening this
  project should remove.
* **Decision**: Not selected for the pilot. The supported $5/month Sync service
  is a better trade than owning a brittle synchronization stack, but canonical
  local Markdown keeps this option open if the threat or cost model changes.

## TriliumNext

* **Pros**: A capable self-hosted personal knowledge base with hierarchy,
  cloning, attributes, relations, maps, scripting, desktop clients, and a web
  interface. It supports
  [JavaScript automation and custom widgets](https://docs.triliumnotes.org/user-guide/scripts/frontend-basics)
  and an active collection of community extensions. Its documented
  [ETAPI](https://docs.triliumnotes.org/rest-api/etapi/) gives agents proper
  authenticated search and CRUD operations. The mobile interface can be
  [installed as a PWA](https://docs.triliumnotes.org/user-guide/setup/mobile-frontend).
* **Cons**: The canonical representation is Trilium's database rather than a
  directory of Markdown. Agents therefore need to operate through ETAPI or an
  export/import loop, making recovery and ad-hoc filesystem tooling less
  transparent. Its mobile PWA explicitly has no offline capability. The rich
  hierarchy and attribute system also risks encouraging the ontology work I am
  trying to delegate or avoid.
* **Decision**: Rejected for the pilot. It is the strongest alternative if
  typed relations and application-managed structure later matter more than an
  open file substrate.

## Joplin with a self-hosted Joplin Server

* **Pros**: Mature native applications on all three target platforms,
  offline-first sync, end-to-end encryption, Markdown editing, and a powerful
  [terminal application](https://joplinapp.org/help/apps/terminal/). It also has
  a documented, backward-compatibility-conscious
  [plugin API](https://joplinapp.org/help/api/references/plugin_api_index/) and
  an [official registry](https://github.com/joplin/plugins) containing more
  than 300 plugins. Its
  [Data API](https://joplinapp.org/help/api/references/rest_api/) lets external
  tools create, search, update, and delete notes.
* **Cons**: It is primarily a notebook-and-tag notes application, not a
  flexible knowledge graph. Joplin warns that its filesystem sync format is
  [not meant to be edited directly](https://joplinapp.org/help/faq/), and its
  REST API is served by a running local client rather than making the server a
  simple agent-facing source of truth.
* **Decision**: Rejected. It optimizes for conventional cross-device notes and
  sync, while this decision prioritizes agent manipulation and emergent
  structure.

## Notion

* **Pros**: Already familiar, polished everywhere, free for an individual with
  unlimited pages, and strong at mixing prose with databases. The official
  [Notion MCP](https://developers.notion.com/guides/mcp/overview) allows
  compatible agents to read and write the workspace in real time, so it is now
  substantially more agent-friendly than when I last used it.
* **Cons**: Notion remains the source of truth. Markdown export is a migration
  copy, not a live, locally inspectable corpus, and Notion says automatic
  workspace backup is
  [not currently available](https://www.notion.com/help/back-up-your-data).
  Database relations are useful structure but not the same as a file-derived
  knowledge graph. The strongest reason to choose Notion—collaboration—is out
  of scope.
* **Decision**: Rejected. MCP fixes the agent access problem but not ownership,
  backup, or dependency on a SaaS workspace.

## Roam Research

* **Pros**: The most graph-native option considered, with block references,
  backlinks, native clients, Markdown and JSON exports, and an increasingly
  agent-friendly surface. Roam now publishes an official
  [MCP server](https://www.npmjs.com/package/@roam-research/roam-mcp) and
  [CLI](https://www.npmjs.com/package/@roam-research/roam-cli), in addition to
  its API and extension ecosystem.
* **Cons**: The daily-note and block-first workflow already failed this use
  case by turning graph maintenance into work. Agent API access could automate
  some gardening, but it would automate inside the same opinionated data model
  rather than remove the dependency. The
  [Pro plan costs $15/month](https://roamresearch.com/?plan=personal), three
  times the budget ceiling, and the source of truth remains SaaS.
* **Decision**: Rejected based on both prior experience and current fit. Better
  agents do not make the wrong capture workflow right.

# Consequences

### Pros

* **Natural-language operation through the existing agent stack** without
  adding another AI subscription or separate chat interface.
* **A Beads-like contract for knowledge**: every agent gets the same focused
  CLI/MCP tools, graph navigation, and machine-readable results instead of
  inventing its own filesystem conventions.
* **Plain Markdown remains authoritative**, so search, scripts, Git, backup,
  migration, and future tools are independent of Basic Memory and SilverBullet.
* **An agent-buildable extension surface** makes small, personal workflows
  cheaper to create without requiring extensions to own the corpus.
* **Structure can emerge after capture**: agents can perform the connection and
  normalization work that was too expensive to do manually in Roam.
* **Uses the lab that already exists**: the Mac mini supplies the always-on
  host, Tailscale supplies private multi-device access, the external drive
  supplies a backup target, and Netdata supplies observability.
* **Zero mandatory subscription**, with a clear $4–5/month Obsidian fallback if
  a native client or a specific mature plugin proves more valuable than the
  self-hosted programmable PWA.

### Cons

* **SilverBullet is less polished than Obsidian**, especially on mobile. The
  PWA still has to earn its place through actual daily capture.
* **A smaller reusable ecosystem shifts some ownership back here.** Agents make
  extension coding cheaper, but generated code still needs review, upgrade
  testing, documentation, and eventual removal.
* **Libraries and plugs are a supply-chain boundary.** Even sandboxed extension
  code can read or change the space through exposed APIs, so third-party and
  agent-authored code must remain needs-driven and reviewable.
* **The Mac mini is the availability boundary** for online access and sync,
  although offline PWA copies reduce the impact of a temporary outage.
* **Concurrent edits can create conflicts** between an offline client and an
  agent changing the same file; workflow discipline and recoverable copies are
  still needed.
* **Two derived indexes must stay fresh**. Basic Memory and SilverBullet each
  watch the same Markdown folder. Either index can lag or fail independently,
  although both can be rebuilt without changing the source files.
* **Agent access creates a large privacy and deletion boundary**. A model can
  see any note supplied to it, and an over-broad instruction can reorganize or
  delete a large corpus. Scoped filesystem permissions, Git checkpoints, and
  tested backups are mandatory.
* **Git history is sensitive too**: deleting a diary entry from the current
  tree does not remove it from repository history or existing backups. A later
  secure-erasure requirement would need an explicit history-rewrite and backup
  retention policy.
* **Self-hosting adds a service to patch and monitor**, even if the data itself
  stays simple.

---

Markdown index of this site: https://robbiepalmer.me/llms.txt