superbee 0.3.0-pre.3 → 0.3.0-pre.5

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.3.0-pre.3",
3
+ "version": "0.3.0-pre.5",
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": [
@@ -4,6 +4,54 @@ Read this when you work in a folder made by `superbee checkout`, or when `superb
4
4
  conflict there. The hosted bundle is the authority. The folder is a working copy. `superbee sync`
5
5
  applies changes directly under the signed-in person's own access, and nobody has to approve them.
6
6
 
7
+ ## Finding a bundle to check out
8
+
9
+ `superbee catalog list --hosted` lists the hosted bundles the signed-in person can reach on the
10
+ host of their last sign-in (or `--host <url>`), across all their workspaces. Each row has the
11
+ `bundle_id` that `superbee checkout <bundle-id>` takes, its `name` and `lifecycle`, the `folder` of
12
+ an existing checkout here (null when there is none), and `ambiguous: true` when two of their
13
+ workspaces hold the same id, which checkout refuses. If a bundle already has a `folder`, work there
14
+ with `--dir` instead of checking it out again. The list is read live and never cached.
15
+
16
+ ## The folder marker, and adopting a moved or copied checkout
17
+
18
+ A checkout folder carries a read-only `.superbee/checkout.json` naming its host and bundle. It is a
19
+ note for you and the person, never an authority: nothing reads it to decide where a command goes.
20
+ The checkout is bound by private state, keyed by the folder's path.
21
+
22
+ When `status`, `home`, `bundle locate` or `session-start` report `copy_of_checkout` (and `home:
23
+ local`), the folder was moved, copied or restored, and it is not bound here. It behaves as a plain
24
+ local bundle, and `sync` refuses it (`unbound_copy`). Tell the person, then:
25
+
26
+ - `superbee checkout --adopt <folder>` binds a folder moved on the same disk back to its own
27
+ checkout, with no network. Unsent edits and conflicts carry over.
28
+ - For a copy or a restore, the same command only previews. Adopting it needs `--host <url>`, and
29
+ the person should confirm the host: never take the marker's host on its own. Adopt adds the
30
+ documents the folder lacks and never overwrites a file. A file that differs from the host's
31
+ version becomes a conflict (below), and a document only in the folder is sent as new by the next
32
+ sync, so check its `local_only` list with the person first.
33
+
34
+ ## Moving a local bundle or Git board to hosted
35
+
36
+ `superbee publish --to hosted` moves a bundle to hosted Superbee in the person's own workspace.
37
+ Only run it when the person asks for the move.
38
+
39
+ 1. Run it without `--yes` first. It makes no request. It lists what travels (documents, reserved
40
+ files, other files), what stays (dot-files, links), anything that blocks the move, and the
41
+ bundle id and host it will use. Show the person the preview. A document that does not satisfy
42
+ its Kind, or a Kind convention with a problem, blocks the move, because the host would refuse
43
+ writes to it. Fix them before publishing.
44
+ 2. When they agree, run the `--yes` command the preview names. It signs in if needed (relay the
45
+ link, as below), creates the bundle, and converts the folder in place into a hosted checkout.
46
+ No file is rewritten.
47
+ 3. A Git board is unbound from its `board` branch, but the branch stays, locally and on origin.
48
+ Tell the person their teammates keep using the Git board until they check out the hosted bundle
49
+ instead. A board that is behind its upstream is refused until `superbee sync` brings it current.
50
+ 4. `--with-history` imports a Git board's earlier versions as labeled, unverified history. Use it
51
+ only when the person asks for history.
52
+ 5. `TRANSIENT` with `write_outcome_unknown` means the creation may be partial: re-run the same
53
+ command, which finishes or confirms the same creation.
54
+
7
55
  ## Sign-in: relay the link, then retry
8
56
 
9
57
  Hosted commands start sign-in by themselves. When a command returns `AUTH_REQUIRED` (exit 4):
@@ -108,9 +156,11 @@ Superbee app, by the person.
108
156
  ## Refusals that belong to the person
109
157
 
110
158
  Some commands are refused in a hosted checkout with "do this in the Superbee app". Examples:
111
- editing Kinds or recipes, artifacts, and `doc verify`. Tell the person what to do in the app. Do
112
- not work around a refusal by editing files, using another command, or copying the bundle
113
- somewhere else.
159
+ artifacts and `doc verify`. Tell the person what to do in the app. Editing Kinds or recipes is
160
+ refused too, and the app cannot do it either: a hosted bundle's Kinds cannot be changed from a
161
+ checkout. Kinds are designed in a local or Git bundle before it is published. Do not work around a
162
+ refusal by editing files, using another command, or copying the bundle somewhere else. Taking a
163
+ bundle out of hosted is `superbee export` (below), and only when the person asks for it.
114
164
 
115
165
  `checkout` adds the folder to the workspace catalog, where `catalog list` shows it with
116
166
  `home: hosted`. The local MCP app (`superbee mcp`) can read it by that label, but refuses every
@@ -124,12 +174,45 @@ confirm that no superbee command is still running, then remove the lock named in
124
174
  ## Session hooks (opt-in)
125
175
 
126
176
  - `superbee hook install` installs the SessionStart hook. In a hosted checkout, it pulls from the
127
- host at the start of each session.
177
+ host at the start of each session. Its `workspaces` block lists the other catalog bundles with
178
+ their `home` (local, git or hosted) and `freshness` (when each was last pulled or fetched). It
179
+ pulls none of them: to work in one, get its path with `superbee catalog resolve <label> --field
180
+ path` and pass `--dir`, and sync a stale one only when the work needs it.
128
181
  - `superbee hook install --turn-end-sync` also installs a Stop hook for Claude Code and Codex. It
129
182
  syncs the checkout when each turn ends, and skips the network when nothing changed and the last
130
183
  pull is recent. If that sync finds a conflict, a held file or a sign-in link, the hook hands it
131
184
  back to you before the turn ends: handle it as above. It reports each condition once; the same
132
185
  unresolved condition is not reported on later turns, so check `superbee sync` yourself.
186
+ - A Git board is never synced by the Stop hook unless the person also asks for it:
187
+ `superbee hook install --turn-end-sync --git-boards`. Then the shared board the session is in
188
+ syncs at turn end under the same rules, and a conflict comes back once, in Git's form: the
189
+ teammate's version is kept and yours is saved to the export file the reason names.
133
190
  - Offer the Stop hook, but install it only when the person agrees.
134
191
  `superbee hook uninstall --turn-end-sync` removes it, and `SUPERBEE_NO_TURN_SYNC=<any value>`
135
192
  turns it off for a shell.
193
+ - Each write names the agent the sync runs under, and the host records it with the write as
194
+ unverified attribution, never authority: `claude-code` under Claude Code (`CLAUDECODE=1`), or
195
+ `SUPERBEE_VIA=<token>` (1 to 32 of `a-z 0-9 . _ -`, not starting with `superbee`).
196
+ `SUPERBEE_NO_VIA=<any value>` names none. Another agent started from a Claude Code shell (a
197
+ Codex in a tmux pane, for example) inherits `CLAUDECODE=1` and is named `claude-code` unless
198
+ `SUPERBEE_VIA` is set. A token the host would refuse is not sent, and the receipt says so
199
+ (`via_ignored`).
200
+
201
+ ## Export: taking a bundle out of hosted
202
+
203
+ Run `superbee export` only when the person asks for a copy outside hosted, or to stop using a
204
+ checkout. It never changes the hosted bundle, and it carries the current revision only, never
205
+ history.
206
+
207
+ - `superbee export <bundle-id> --to <folder>` (or `--dir <checkout> --to <folder>`) writes every
208
+ document, reserved file and blob into a new or empty folder, which becomes an ordinary local
209
+ bundle. The archive is verified against the host's digests first, and the folder appears
210
+ complete or not at all. `export_incomplete` (TRANSIENT) means the host stopped the export:
211
+ retry the same command.
212
+ - `superbee export --dir <checkout> --in-place` turns the checkout into a local bundle: it adds
213
+ the files the checkout lacks, never overwrites one (`kept_local` lists files that differ from
214
+ the host's), and forgets the binding. It refuses `unsent_changes`: run `superbee sync` first. Pass
215
+ `--keep-unsent` only when the person agrees that those changes stay in this folder and never
216
+ reach the host. If it stops part way, re-run the same command: it finishes without the network.
217
+ - `--git` makes the result a Git board on branch `board`. To share it, the person adds a remote
218
+ (`git remote add origin <url>`), then `superbee sync --establish`.