docs: add Ecosystem diagram to README + update harness-extension conventions post-split

Two small doc updates consolidating the session's architectural arc:

1. README.md gets a new 'Ecosystem' section (after the contents list,
   before 'Why this exists') showing the five-repo composition:
     myconfigs -> opencode-toolkit + pi-toolkit -> mempalace-toolkit
   Plus an ownership table clarifying which scope lives where. The
   diagram makes the opt-out pattern visible \u2014 opencode-devbox's slim
   container path skips mempalace-toolkit and still gets a functional
   stack.

2. AGENTS.md 'Adding a new harness extension' section was still written
   for the pre-split extensions/pi/ which had keybindings.json +
   settings.example.json + pi-env.zsh. Rewrote to reflect:
   - Bridge-only scope (harness-generic config goes in <harness>-toolkit).
   - 'Probe for the sibling toolkit' step replaces the old symlink-keybindings
     and template-settings steps.
   - Worked example now points at install_pi_extension + check_pi_toolkit
     rather than the four functions that moved out.
   - Explicitly names the pattern: opencode-toolkit + pi-toolkit as
     the two existing examples of the sibling-toolkit convention.
This commit is contained in:
2026-05-05 17:50:13 +02:00
parent 16915f0e55
commit 90e70fff61
2 changed files with 77 additions and 27 deletions
+41
View File
@@ -15,6 +15,47 @@ Producer-side tooling for [MemPalace](https://github.com/MemPalace/mempalace)
---
## Ecosystem
This repo is the memory-layer hub in a family of composable toolkits.
Each `install.sh` is independent and idempotent; install only what you
need. MemPalace can be opted out entirely (the `opencode-devbox` slim
container path exercises this).
```
┌──────────────────┐
│ myconfigs │ dotfiles: ~/.config/pi/.env, ~/.config/opencode/.env,
└────────┬─────────┘ tmux CSI-u, zsh loaders, … (git-crypt encrypted)
│ provision
┌──────────────┼──────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────────┐
│opencode- │ │pi-toolkit│ │ (pi/opencode │
│ toolkit │ │ │ │ installed │
│ │ │ │ │ upstream) │
└─────┬────┘ └─────┬────┘ └──────────────┘
│ │
│ (optional) │ (optional)
└──────┬───────┘
┌─────────────────┐
│mempalace-toolkit│ ← this repo
└─────────────────┘ detects pi / opencode and installs bridges
for whichever are present
```
Who owns what:
| Repo | Scope |
|---|---|
| [`myconfigs`](https://gitea.jordbo.se/joakimp/myconfigs) | Dotfiles (git-crypt encrypted). Ships `.env` files each toolkit below sources. |
| [`opencode-toolkit`](https://gitea.jordbo.se/joakimp/opencode-toolkit) | Opencode's own shell glue (env loader for `~/.config/opencode/.env`). No mempalace dep. |
| [`pi-toolkit`](https://gitea.jordbo.se/joakimp/pi-toolkit) | Pi's own base config (keybindings, env loader, `settings.example.json`). No mempalace dep. |
| **`mempalace-toolkit` (this)** | Memory layer. Mining wrappers in `bin/`, `opencode-mempalace-bridge` skill, pi↔mempalace MCP extension. Probes for the other toolkits' artifacts; installs bridges where relevant. |
| [`opencode-devbox`](https://gitea.jordbo.se/joakimp/opencode-devbox) | Docker containers that compose any subset via independent `install.sh` invocations. |
---
## Why this exists
MemPalace is the agent memory layer. Its stock CLI has two gaps that bite on a machine running opencode with a docs-first palace policy: