|
| 1 | +# Manual Pages |
| 2 | + |
| 3 | +Basic Memory's manual is written in the style of Unix man pages — and |
| 4 | +implemented as Basic Memory notes ([#952](https://github.com/basicmachines-co/basic-memory/issues/952)). |
| 5 | +Every page is a markdown note conforming to the `Manpage` schema, `SEE ALSO` |
| 6 | +entries are real knowledge-graph relations, and every example on every page |
| 7 | +was executed against a live project before the page shipped. The manual |
| 8 | +documents the tools; the tools verify the manual. |
| 9 | + |
| 10 | +## Where it lives |
| 11 | + |
| 12 | +The canonical manual is the **`manual` project in the Basic Memory team |
| 13 | +workspace** (cloud, shared). Anyone can build their own: the schema ships as |
| 14 | +an opt-in seed at `plugins/claude-code/schemas/manpage.md` — copy it into any |
| 15 | +project's folder and start writing pages against it. |
| 16 | + |
| 17 | +Layout: |
| 18 | + |
| 19 | +``` |
| 20 | +manual/ |
| 21 | +├── schemas/Manpage.md # the manpage schema (type: schema) |
| 22 | +├── man1/ # CLI commands bm(1), bm-status(1), ... |
| 23 | +├── man3/ # MCP tools write-note(3), search-notes(3), ... |
| 24 | +├── man5/ # file formats bm-note(5), bm-observation(5), ... |
| 25 | +├── man7/ # concepts basic-memory(7), semantic-memory(7), ... |
| 26 | +├── playground/ # scratch notes for destructive examples |
| 27 | +└── diagrams/ # canvas visualizations of the manual graph |
| 28 | +``` |
| 29 | + |
| 30 | +### Why "man1", "man3", "man5"? |
| 31 | + |
| 32 | +The folder names are Unix's, unchanged since 1971. The manual is divided |
| 33 | +into numbered **sections**, pages physically live in directories named |
| 34 | +after them (`/usr/share/man/man1`, `man5`, ...), and the number tells you |
| 35 | +what *kind* of thing is documented — not importance, not reading order: |
| 36 | + |
| 37 | +- **1** — user commands (`ls`, `grep`) |
| 38 | +- **2** — system calls |
| 39 | +- **3** — library functions / APIs (`printf(3)`) |
| 40 | +- **4** — devices |
| 41 | +- **5** — file formats and config files (`crontab(5)`, `passwd(5)`) |
| 42 | +- **6** — games (really) |
| 43 | +- **7** — miscellanea: concepts, conventions, overviews (`regex(7)`, `signal(7)`) |
| 44 | +- **8** — system administration |
| 45 | + |
| 46 | +That's also why man page names carry the parenthesized number — |
| 47 | +`crontab(1)` is the command, `crontab(5)` is the file format, same name in |
| 48 | +two sections. `man 5 crontab` picks the section explicitly. |
| 49 | + |
| 50 | +This manual copies that layout with the sections that have a Basic Memory |
| 51 | +analog: |
| 52 | + |
| 53 | +- **man1/** — `bm` CLI commands → `bm-status(1)` |
| 54 | +- **man3/** — MCP tools, our equivalent of the "library API" section → `write-note(3)` |
| 55 | +- **man5/** — file formats: note syntax, observations, relations, schemas → `bm-note(5)` |
| 56 | +- **man7/** — concepts → `basic-memory(7)`, `semantic-memory(7)` |
| 57 | +- **8** is reserved for admin/cloud operations but has no pages yet; 2, 4, |
| 58 | + and 6 have no analog (no system calls, no devices, and no games — yet) |
| 59 | + |
| 60 | +When a page says `see_also [[bm-note(5)]]`, the `(5)` reads "the |
| 61 | +file-format page," exactly the way a Unix manual cross-references — except |
| 62 | +here it's a traversable relation in the graph instead of a typographic |
| 63 | +convention. The manual explains its own conventions in `man-pages(7)` — |
| 64 | +fittingly, the same page name Linux uses for this, and that almost nobody |
| 65 | +ever reads. |
| 66 | + |
| 67 | +## Page anatomy |
| 68 | + |
| 69 | +Pages use the classic headers where applicable: `NAME`, `SYNOPSIS`, |
| 70 | +`DESCRIPTION`, `PARAMETERS`, `MCP USAGE`, `CLI EQUIVALENT`, `EXAMPLES`, |
| 71 | +`GOTCHAS`, `SEE ALSO`. Frontmatter (validated by the schema): |
| 72 | + |
| 73 | +```yaml |
| 74 | +type: manpage |
| 75 | +section: 3 # 1 | 3 | 5 | 7 | 8 |
| 76 | +name: write-note # page name without section suffix |
| 77 | +summary: create or overwrite a markdown note in the knowledge base |
| 78 | +generated: hand # hand | registry | typer (regeneration ownership) |
| 79 | +tool: write_note # section-3 pages: the MCP tool documented |
| 80 | +command: basic-memory status # section-1 pages: the CLI command documented |
| 81 | +verified: 0.21.6 mcp+cli # version + path(s) that proved the page |
| 82 | +``` |
| 83 | +
|
| 84 | +Field knowledge accumulates as observations — `[gotcha]`, `[bug]` (with issue |
| 85 | +links), `[pattern]` — and `SEE ALSO` entries are `see_also` relations, so the |
| 86 | +manual is a navigable graph, not a folder of files. |
| 87 | + |
| 88 | +## How to use it |
| 89 | + |
| 90 | +Man-style reads (any MCP client or the CLI): |
| 91 | + |
| 92 | +```bash |
| 93 | +# read a page |
| 94 | +bm tool read-note "man3/write-note-3" --project manual |
| 95 | +
|
| 96 | +# apropos — find pages by section, tool, or text |
| 97 | +bm tool search-notes --project manual # then filter, or via MCP: |
| 98 | +# search_notes(project="manual", metadata_filters={"type": "manpage", "section": 3}) |
| 99 | +# search_notes(project="manual", metadata_filters={"type": "manpage", "tool": "write_note"}) |
| 100 | +
|
| 101 | +# traverse SEE ALSO from any page |
| 102 | +# build_context(url="man3/write-note-3", project="manual") |
| 103 | +``` |
| 104 | + |
| 105 | +A future `bm man <topic>` command is thin sugar over exactly these calls. |
| 106 | + |
| 107 | +And for the real thing — `man bm` in an actual terminal: |
| 108 | + |
| 109 | +```bash |
| 110 | +bm man install # copies bundled groff pages to ~/.local/share/man |
| 111 | +man bm # the overview page, rendered by man(1) |
| 112 | +man basic-memory # same page via its alias |
| 113 | +``` |
| 114 | + |
| 115 | +`bm man install` warns with a one-line `MANPATH` fix if the install root |
| 116 | +isn't searched by your `man`. Agents with shell access can use `man bm` as |
| 117 | +an offline quick reference; the full per-tool detail stays in the manual |
| 118 | +project's section-3 pages. |
| 119 | + |
| 120 | +## The verification discipline |
| 121 | + |
| 122 | +Two rules make the manual trustworthy: |
| 123 | + |
| 124 | +1. **Examples must have run.** An `EXAMPLES` (or `MCP USAGE` / `CLI |
| 125 | + EQUIVALENT`) block contains only commands that actually executed against |
| 126 | + the manual project. Destructive operations (`delete_note`, `move_note`, |
| 127 | + destructive `edit_note`) run only against `playground/` notes — never |
| 128 | + against pages. The `verified:` field records the version and which path |
| 129 | + proved the page: `mcp` (live service), `cli` (dev checkout), or both. |
| 130 | + |
| 131 | +2. **The schema is the linter.** Validate the whole manual any time: |
| 132 | + |
| 133 | + ```bash |
| 134 | + bm tool schema-validate manpage --project manual |
| 135 | + # → {"total_notes": 38, "valid_count": 38, "warning_count": 0, ...} |
| 136 | + ``` |
| 137 | + |
| 138 | + `bm orphans --project manual` confirms every page is connected to the |
| 139 | + graph, and `schema_diff`/`schema_infer` report drift between the schema |
| 140 | + and how pages are actually written. |
| 141 | + |
| 142 | +Because verification exercises real tool calls against the live service, |
| 143 | +building the manual doubles as an end-to-end smoke test. The initial build |
| 144 | +found six bugs in one pass (#954–#959) — including the verification rule |
| 145 | +catching a test that asserted a bug as expected output (#958). |
| 146 | + |
| 147 | +## Adding or updating a page |
| 148 | + |
| 149 | +1. Run the commands you intend to document; keep the actual output. |
| 150 | +2. Write the page with `write_note`, passing frontmatter through the |
| 151 | + `metadata` parameter (nested YAML in content frontmatter is unreliable on |
| 152 | + some clients): |
| 153 | + |
| 154 | + ``` |
| 155 | + write_note(title="my-tool(3)", directory="man3", project="manual", |
| 156 | + note_type="manpage", |
| 157 | + metadata={"section": 3, "name": "my-tool", |
| 158 | + "summary": "...", "generated": "hand", |
| 159 | + "tool": "my_tool", "verified": "<version> mcp"}) |
| 160 | + ``` |
| 161 | +
|
| 162 | +3. Link related pages in `SEE ALSO` with `see_also [[other-page(3)]]`. |
| 163 | + Forward references to pages that don't exist yet are fine — they resolve |
| 164 | + automatically when the target is written. |
| 165 | +4. Validate: `bm tool schema-validate manpage --project manual`. |
| 166 | +
|
| 167 | +For mechanical updates to generated sections, prefer `edit_note` with |
| 168 | +`replace_section` / `insert_after_section` so curated content (EXAMPLES, |
| 169 | +GOTCHAS, SEE ALSO, observations) survives — that ownership split is what the |
| 170 | +`generated:` field declares. |
| 171 | +
|
| 172 | +## Roadmap |
| 173 | +
|
| 174 | +- **Registry generator** — section-3 SYNOPSIS/PARAMETERS generated from the |
| 175 | + MCP tool registry (docstrings + pydantic schemas), section-1 from Typer |
| 176 | + help; the hand-written corpus is the template spec. Regenerate-and-diff in |
| 177 | + CI becomes the drift gate. |
| 178 | +- **`bm man <topic>`** — CLI sugar over `read_note` + metadata search. |
| 179 | + (`bm man install` + a hand-written `bm.1` already ship — the first slice |
| 180 | + of [#610](https://github.com/basicmachines-co/basic-memory/issues/610); |
| 181 | + the generator will produce per-command pages from the same extraction.) |
| 182 | +- **Docs site** — the notes remain canonical for sections 5 and 7, code is |
| 183 | + canonical for 1 and 3; both render to the hosted docs site. |
0 commit comments