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:
@@ -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:
|
||||
|
||||
Reference in New Issue
Block a user