superbee 0.4.3 → 0.4.4-pre.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "superbee",
3
- "version": "0.4.3",
3
+ "version": "0.4.4-pre.2",
4
4
  "type": "module",
5
5
  "description": "Agent-facing Superbee CLI for reading and writing local OKF knowledge bundles: context notes, docs, cross-links, and live bundle Views.",
6
6
  "keywords": [
@@ -66,7 +66,6 @@
66
66
  "prepublishOnly": "node -e \"console.error('superbee is released by .github/workflows/release.yml (npm stage publish); do not run npm publish here'); process.exit(1)\""
67
67
  },
68
68
  "devDependencies": {
69
- "@modelcontextprotocol/sdk": "^1.32.1",
70
69
  "@superbee/board-git": "*",
71
70
  "@superbee/bundle-descriptor": "*",
72
71
  "@superbee/core": "*",
@@ -90,6 +89,6 @@
90
89
  "darwin",
91
90
  "linux"
92
91
  ],
93
- "readme": "# superbee\n\nShared, versioned, conflict-safe knowledge for AI coding agents, stored as plain markdown in\nyour repo.\n\nSuperbee is pre-1.0. Commands and formats may change between releases.\n\n## What is Superbee?\n\nAgents forget everything between sessions, overwrite each other's work, and keep what they know\ninvisible to the humans they work for. Superbee fixes all three with a **knowledge bundle**: a\nfolder of markdown documents, by convention `.superbee/` at your project root, that agents read\nand write through a small command-line tool.\n\n- **Context that persists.** Agents write context notes, decisions, plans, and research into the\n bundle. The next session, or a different agent, picks up where the last one left off. An\n optional `SessionStart` hook for Claude Code, Codex, and OpenCode orients every new session\n automatically.\n- **Safe for many writers.** Each write can carry the actor that made it. A writer can name the\n version it last read; if anyone changed the document since, the write fails with a typed\n conflict error instead of silently overwriting their work.\n- **Visible to humans.** The bundle is plain markdown. Open it in any editor, render it on\n GitHub, diff it in git. `superbee ui` serves it locally as cross-linked pages with backlinks and\n a live activity feed. No bundle content leaves your machine until you run `superbee sync`, which\n shares the bundle with teammates through the board: a copy of the bundle kept on its own git\n branch, separate from your code.\n- **Views on demand.** Ask your agent for a dashboard, a timeline, a filtered task queue, or a\n reading view of one dense document. It builds a self-contained HTML page, stores it in the bundle\n as a View, and `superbee ui` hosts it in a sandboxed frame. A View reads the bundle live and can\n change it only through a write you confirm. Views are bundle content, so they travel with `sync`.\n- **Built for agents.** Output is structured and token-lean, and errors carry a small, stable set\n of exit codes. Agents act on responses without parsing prose or flooding their context window.\n- **Yours, and portable.** Bundles follow the Open Knowledge Format (OKF), a convention of\n markdown with frontmatter, so they outlive the tool: hand the folder to someone else, or read it\n with anything that speaks markdown. New bundles are written as OKF v0.2, and existing v0.1\n bundles keep working as they are. Reading and writing the bundle works offline; only sharing\n needs a network. The document schemas, called kinds, live inside the bundle, so it describes\n its own structure.\n\nBees build comb one cell at a time. The comb holds what the colony gathers, and its shape shows\nthe next bee where to build and what belongs where. Superbee works the same way: people and\nagents record what they learn in a structure that fits their domain, and that structure guides\nwhoever works next. Each session builds on the last instead of starting over.\n\nThe npm package is one self-contained executable with zero runtime dependencies, plus an Agent\nSkill, an instruction file your agent loads, that teaches it how to use the tool.\n\n## Install\n\nRequires a supported Node.js 22, 24, or 26 release (22.14.0 minimum) on macOS or Linux. Native Windows is not supported by this package.\n\n```sh\nnpm install -g superbee\n```\n\nStable releases publish on npm's `latest` tag and prereleases on `next`.\n\nWindows adapters and the `superbee-windows` executable live in a separate repository and are\nnot included in `superbee`. Most Windows users should run Superbee in WSL2, where npm sees a\nLinux platform and the normal installation applies. An experimental, unsupported native Windows\nbuild is available as open source, with build-from-source instructions: https://github.com/Holaxis-ai/superbee-windows-cli\n\n### Upgrading an existing Windows installation\n\nThe first release containing the Windows extraction removes native Windows support from this\npackage. Its npm `os` metadata permits only `darwin` and `linux`, so a Windows upgrade to an affected\nversion is rejected with `EBADPLATFORM`. This applies to existing prerelease users too. Forcing the\ninstallation does not restore support: the executable refuses commands on unsupported hosts\nbefore running them (the bare `--version` flag can still identify the installed build).\n\nThere is no supported Windows replacement on npm. The alternatives are WSL2 or the experimental\nbuild from source at https://github.com/Holaxis-ai/superbee-windows-cli; neither carries a\nfirst-party support promise for native Windows. An older installed version is not converted or\nremoved by this source change, and existing bundle files are not migrated by it. Review the affected release's notes before changing an existing\nWindows installation. macOS/Linux users can continue using the normal installation and setup flow.\n\nRun `superbee version --check` to compare your install with the current stable release.\n\n## First run: let your agent finish setup\n\n`npm install` gives you the CLI. The integrations (the Agent Skill, the `SessionStart` hook, and\nMCP server registration, where MCP is the Model Context Protocol) are installed by your agent,\nnot by hand. Ask it:\n\n> Run `superbee setup` and follow its instructions.\n\nSetup itself changes nothing. It inspects your configuration and returns one safe next command at\na time, and the agent runs each with your approval. Setup knows Claude Code, Codex, and OpenCode,\nplus Claude Desktop for the MCP registration only.\n\nFor a fresh cloud container, provision Superbee in the environment setup step before agent tool\nuse. Generated hooks bind absolute Node and CLI paths from their installation, so a project hook\ncopied from a laptop does not install Superbee or provide a working container launcher. Configure\nhooks inside the environment and verify startup in a fresh session. Startup pulls are best-effort;\ninspect an explicit `superbee sync` receipt to verify publication of edits.\n\n## Everyday use\n\nYou rarely type Superbee commands yourself. You ask your agent, and the Agent Skill translates the\nrequest into CLI calls:\n\n- \"Set up a Superbee bundle for this project and track our tasks in it.\"\n- \"Write up what we decided about the auth design as a doc, and link it to the task.\"\n- \"What did the last session leave off on? Check the context notes.\"\n- \"Sync the board so my teammate's agent sees this.\"\n- \"Give me a view of the open tasks grouped by owner.\"\n\nBehind those requests the agent uses a small set of commands: `init --dir .superbee` creates the\nbundle, `new` creates a document of a declared kind, `doc write` writes a free-form one,\n`doc update` changes a document, `link add` connects two, `list` and `doc read` query them, and\n`sync` shares the board. `superbee --help` lists the commands, and `superbee <command> --help`\ngives each one's full reference.\n\nThe two commands meant for you are the ones that show you the knowledge:\n\n```sh\nsuperbee ui --open # the whole bundle, rendered in your browser\nsuperbee doc open <id> # one document, by an id from `superbee list`\n```\n\n## Upgrading from aslite\n\nIf you installed the earlier `@holaxis/aslite` package or its marketplace plugin: install\n`superbee` alongside it, have your agent run `superbee setup` to migrate the integrations, then\nrun `npm uninstall -g @holaxis/aslite`. Existing `.agentstate-lite/` bundles and\n`.agentstate.json` bindings keep working with no migration.\n\n## Learn more\n\nThe [repository](https://github.com/Holaxis-ai/superbee) holds the source, the\n[CLI contract](https://github.com/Holaxis-ai/superbee/blob/main/packages/superbee/AXI-CONTRACT.md),\nand the [wire protocol](https://github.com/Holaxis-ai/superbee/blob/main/docs/WIRE-PROTOCOL.md).\n\n## License\n\nApache-2.0 © 2026 Holaxis\n",
92
+ "readme": "# superbee\n\nShared, versioned, conflict-safe knowledge for AI coding agents, stored as plain markdown in\nyour repo.\n\nSuperbee is pre-1.0. Commands and formats may change between releases.\n\n## What is Superbee?\n\nAgents forget everything between sessions, overwrite each other's work, and keep what they know\ninvisible to the humans they work for. Superbee fixes all three with a **knowledge bundle**: a\nfolder of markdown documents, by convention `.superbee/` at your project root, that agents read\nand write through a small command-line tool.\n\n- **Context that persists.** Agents write context notes, decisions, plans, and research into the\n bundle. The next session, or a different agent, picks up where the last one left off. An\n optional `SessionStart` hook for Claude Code, Codex, and OpenCode orients every new session\n automatically.\n- **Safe for many writers.** Each write can carry the actor that made it. A writer can name the\n version it last read; if anyone changed the document since, the write fails with a typed\n conflict error instead of silently overwriting their work.\n- **Visible to humans.** The bundle is plain markdown. Open it in any editor, render it on\n GitHub, diff it in git. `superbee ui` serves it locally as cross-linked pages with backlinks and\n a live activity feed. No bundle content leaves your machine until you run `superbee sync`, which\n shares the bundle with teammates through the board: a copy of the bundle kept on its own git\n branch, separate from your code.\n- **Views on demand.** Ask your agent for a dashboard, a timeline, a filtered task queue, or a\n reading view of one dense document. It builds a self-contained HTML page, stores it in the bundle\n as a View, and `superbee ui` hosts it in a sandboxed frame. A View reads the bundle live and can\n change it only through a write you confirm. Views are bundle content, so they travel with `sync`.\n- **Built for agents.** Output is structured and token-lean, and errors carry a small, stable set\n of exit codes. Agents act on responses without parsing prose or flooding their context window.\n- **Yours, and portable.** Bundles follow the Open Knowledge Format (OKF), a convention of\n markdown with frontmatter, so they outlive the tool: hand the folder to someone else, or read it\n with anything that speaks markdown. New bundles are written as OKF v0.2, and existing v0.1\n bundles keep working as they are. Reading and writing the bundle works offline; only sharing\n needs a network. The document schemas, called kinds, live inside the bundle, so it describes\n its own structure.\n\nBees build comb one cell at a time. The comb holds what the colony gathers, and its shape shows\nthe next bee where to build and what belongs where. Superbee works the same way: people and\nagents record what they learn in a structure that fits their domain, and that structure guides\nwhoever works next. Each session builds on the last instead of starting over.\n\nThe npm package is one self-contained executable with zero runtime dependencies, plus an Agent\nSkill, an instruction file your agent loads, that teaches it how to use the tool.\n\n## Install\n\nRequires a supported Node.js 22, 24, or 26 release (22.14.0 minimum) on macOS or Linux. Native Windows is not supported by this package.\n\n```sh\nnpm install -g superbee\n```\n\nStable releases publish on npm's `latest` tag and prereleases on `next`. To try the prerelease:\n\n```sh\nnpm install -g superbee@next\n```\n\nWindows adapters and the `superbee-windows` executable live in a separate repository and are\nnot included in `superbee`. Most Windows users should run Superbee in WSL2, where npm sees a\nLinux platform and the normal installation applies. An experimental, unsupported native Windows\nbuild is available as open source, with build-from-source instructions: https://github.com/Holaxis-ai/superbee-windows-cli\n\n### Upgrading an existing Windows installation\n\nThe first release containing the Windows extraction removes native Windows support from this\npackage. Its npm `os` metadata permits only `darwin` and `linux`, so a Windows upgrade to an affected\nversion is rejected with `EBADPLATFORM`. This applies to existing prerelease users too. Forcing the\ninstallation does not restore support: the executable refuses commands on unsupported hosts\nbefore running them (the bare `--version` flag can still identify the installed build).\n\nThere is no supported Windows replacement on npm. The alternatives are WSL2 or the experimental\nbuild from source at https://github.com/Holaxis-ai/superbee-windows-cli; neither carries a\nfirst-party support promise for native Windows. An older installed version is not converted or\nremoved by this source change, and existing bundle files are not migrated by it. Review the affected release's notes before changing an existing\nWindows installation. macOS/Linux users can continue using the normal installation and setup flow.\n\nRun `superbee version --check` to compare your install with the current stable release.\n\n## First run: let your agent finish setup\n\n`npm install` gives you the CLI. The integrations (the Agent Skill, the `SessionStart` hook, and\nMCP server registration, where MCP is the Model Context Protocol) are installed by your agent,\nnot by hand. Ask it:\n\n> Run `superbee setup` and follow its instructions.\n\nSetup itself changes nothing. It inspects your configuration and returns one safe next command at\na time, and the agent runs each with your approval. Setup knows Claude Code, Codex, and OpenCode,\nplus Claude Desktop for the MCP registration only.\n\nFor a fresh cloud container, provision Superbee in the environment setup step before agent tool\nuse. Generated hooks bind absolute Node and CLI paths from their installation, so a project hook\ncopied from a laptop does not install Superbee or provide a working container launcher. Configure\nhooks inside the environment and verify startup in a fresh session. Startup pulls are best-effort;\ninspect an explicit `superbee sync` receipt to verify publication of edits.\n\n## Everyday use\n\nYou rarely type Superbee commands yourself. You ask your agent, and the Agent Skill translates the\nrequest into CLI calls:\n\n- \"Set up a Superbee bundle for this project and track our tasks in it.\"\n- \"Write up what we decided about the auth design as a doc, and link it to the task.\"\n- \"What did the last session leave off on? Check the context notes.\"\n- \"Sync the board so my teammate's agent sees this.\"\n- \"Give me a view of the open tasks grouped by owner.\"\n\nBehind those requests the agent uses a small set of commands: `init --dir .superbee` creates the\nbundle, `new` creates a document of a declared kind, `doc write` writes a free-form one,\n`doc update` changes a document, `link add` connects two, `list` and `doc read` query them, and\n`sync` shares the board. `superbee --help` lists the commands, and `superbee <command> --help`\ngives each one's full reference.\n\nThe two commands meant for you are the ones that show you the knowledge:\n\n```sh\nsuperbee ui --open # the whole bundle, rendered in your browser\nsuperbee doc open <id> # one document, by an id from `superbee list`\n```\n\n## Upgrading from aslite\n\nIf you installed the earlier `@holaxis/aslite` package or its marketplace plugin: install\n`superbee` alongside it, have your agent run `superbee setup` to migrate the integrations, then\nrun `npm uninstall -g @holaxis/aslite`. Existing `.agentstate-lite/` bundles and\n`.agentstate.json` bindings keep working with no migration.\n\n## Learn more\n\nThe [repository](https://github.com/Holaxis-ai/superbee) holds the source, the\n[CLI contract](https://github.com/Holaxis-ai/superbee/blob/main/packages/superbee/AXI-CONTRACT.md),\nand the [wire protocol](https://github.com/Holaxis-ai/superbee/blob/main/docs/WIRE-PROTOCOL.md).\n\n## License\n\nApache-2.0 © 2026 Holaxis\n",
94
93
  "readmeFilename": "README.md"
95
94
  }
@@ -307,6 +307,15 @@ with a `held` row, reason `unsafe_id`, and the rest of the bundle syncs. A host
307
307
  differs only in letter case from another is held as `case_collision`. Both are renamed in the
308
308
  Superbee app, by the person.
309
309
 
310
+ An edit that removes an outbound link the document had is held as `dropped_links`, and the row
311
+ names the links it removes. Usually the removal is a mistake (a rewrite from a partial read):
312
+ restore the links. When removing them is intended, `superbee sync --replace-links <id>` sends that
313
+ one document's edit as the file stands in that run, against the version it was checked against;
314
+ once admitted it is sent like any other change, retried by a later sync if the host was busy. It
315
+ covers no other document and no later edit, and it never admits a body carrying a
316
+ truncated-preview notice.
317
+ `superbee status` shows the same hold before you sync.
318
+
310
319
  ## The bundle's front page (the root `index.md`)
311
320
 
312
321
  The root `index.md` syncs as one file of its own when the host lets you change the bundle's front
@@ -406,7 +415,11 @@ somewhere else. Taking a bundle out of hosted is `superbee export` (below), and
406
415
  person asks for it.
407
416
 
408
417
  `checkout` adds the folder to the workspace catalog, where `catalog list` shows it with
409
- `home: hosted`. The local MCP app (`superbee mcp`) serves it through the folder, by that label or
418
+ `home: hosted`. `checkout --release` forgets the label checkout gave it; a label you chose is
419
+ kept. `superbee catalog remove <label>` forgets any other entry, such as one `catalog list`
420
+ reports `available: false` (its folder is gone); it never touches the folder or the checkout. It
421
+ refuses (`unsent_changes`, exit 5) a checkout whose folder holds changes sync has not sent: run
422
+ `superbee sync --dir <folder>` first. The local MCP app (`superbee mcp`) serves it through the folder, by that label or
410
423
  with the session opened in it: a document written through a View lands in the folder and reaches
411
424
  the host at the next `superbee sync`. A write sync could not send (a View save, a convention, a
412
425
  retype, a document over the size limit, a change to `verified`) is refused before the file
@@ -54,6 +54,9 @@ Use `--body-file` for multiline Markdown. Use `superbee new "<Kind>" --help` for
54
54
  of an installed Kind. Prefer semantic no-ops, actor attribution, and version-aware updates when the
55
55
  CLI exposes them.
56
56
 
57
+ Put write-time guidance in a Kind's field or value descriptions, never its body: a write that
58
+ sets a described value returns that description as `guidance`.
59
+
57
60
  ## Evolve from use
58
61
 
59
62
  Refine fields or relationships only after actual instances expose a recurring need. Package a
@@ -2,7 +2,7 @@
2
2
  type: Reference
3
3
  title: Open Knowledge Format v0.1 (Draft)
4
4
  description: A version-scoped OKF v0.1 interop reference, not Superbee's cross-edition authority.
5
- resource: https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md
5
+ resource: https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/ee67a5ca27044ebe7c38385f5b6cffc2305a9c1a/okf/SPEC.md
6
6
  tags: [okf, spec, reference]
7
7
  timestamp: 2026-08-23T17:47:52Z
8
8
  ---
@@ -17,6 +17,11 @@ file is a Concept whose ID is its path minus `.md`. The only required
17
17
  frontmatter field is `type`. This document mirrors the external spec as a
18
18
  first-class concept (§8) so citations resolve inside the graph.
19
19
 
20
+ OKF has since moved to its own repository,
21
+ `GoogleCloudPlatform/open-knowledge-format`, which publishes v0.2. The
22
+ `knowledge-catalog` copy is a frozen snapshot, so the v0.1 citation below is a
23
+ permalink to the commit that published v0.1.
24
+
20
25
  # Key sections
21
26
 
22
27
  * §3 bundle structure and reserved filenames (`index.md`, `log.md`).
@@ -26,4 +31,5 @@ first-class concept (§8) so citations resolve inside the graph.
26
31
 
27
32
  # Citations
28
33
 
29
- 1. [OKF SPEC.md](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md)
34
+ 1. [OKF v0.1 SPEC.md](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/ee67a5ca27044ebe7c38385f5b6cffc2305a9c1a/okf/SPEC.md)
35
+ 2. [Open Knowledge Format repository](https://github.com/GoogleCloudPlatform/open-knowledge-format)