@aistastudio/myc 0.3.10 → 0.3.11

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/README.md CHANGED
@@ -26,9 +26,23 @@ the build.
26
26
 
27
27
  ## Requires Bun — this is not fine print
28
28
 
29
- The runtime is bound to `bun:sqlite` (SQLite and `sqlite-vec` ship inside Bun,
30
- with no native bindings on the Node side). **It will not start on plain Node.js
31
- or Deno.** Bun ≥ 1.3.0 is required and pinned in `package.json` → `engines.bun`.
29
+ The runtime is bound to `bun:sqlite` (no native bindings on the Node side).
30
+ **It will not start on plain Node.js or Deno.** Bun ≥ 1.3.0 is required and
31
+ pinned in `package.json` → `engines.bun`.
32
+
33
+ **SQLite ≥ 3.44.0.** Below 3.44.0, FTS5 cannot be written from triggers under
34
+ `trusted_schema = OFF`, so every write fails. On Linux, Bun links its own SQLite
35
+ (3.53.0 in Bun 1.3.14). On macOS, Bun uses the system SQLite — 3.43.2 on
36
+ macOS 14 — so the package ships its own: `vendor/sqlite/libmyc-sqlite3.dylib`,
37
+ SQLite 3.53.4 built from the official amalgamation for arm64 and x86_64
38
+ (`scripts/build-sqlite.ts`), chosen before anything else except an explicit
39
+ `MYC_SQLITE=/path/to/libsqlite3.dylib`. If the SQLite in use is still below
40
+ 3.44.0 — a broken install, or `MYC_SQLITE` pointing at an old library — every
41
+ command, `myc init` included, refuses with `precond.sqlite_unsupported` and says
42
+ what to do, instead of creating a workspace it cannot write to. From 3.44.0 up
43
+ to 3.51.2 myc works but warns (`WARN degraded.sqlite_old`): parallel processes
44
+ may run a background job more than once; on Linux the cure is `bun upgrade`.
45
+ `myc doctor` names the SQLite in use and where it came from.
32
46
 
33
47
  Install Bun: https://bun.sh
34
48
 
@@ -37,8 +51,8 @@ Install Bun: https://bun.sh
37
51
  Installation is one command:
38
52
 
39
53
  ```bash
40
- bun install -g @aistastudio/myc # 3.42 MB compressed, 12.58 MB unpacked, 13 files; no models pulled
41
- myc --version # myc 0.3.10 (schema 1)
54
+ bun install -g @aistastudio/myc # 5.05 MB compressed, 15.59 MB unpacked, 16 files; no models pulled
55
+ myc --version # myc 0.3.11 (schema 1)
42
56
  ```
43
57
 
44
58
  It runs on macOS and Linux. On Windows, use WSL and install Bun and myc inside
@@ -97,6 +111,7 @@ myc wire --status-line # + myc's status line under Claude Code's prompt
97
111
  myc wire --queue-hook # + heavy commands take turns (below)
98
112
  myc wire --agents-md # + the myc block in AGENTS.md
99
113
  myc wire --scope user # the same for agents in git worktrees (Claude Code's user layer)
114
+ myc wire --scope user --agents claude,opencode # + opencode's global config
100
115
  myc unwire # remove what wire put in
101
116
  ```
102
117
 
@@ -118,6 +133,20 @@ workspace the MCP server offers zero tools and no instructions. `--hook-mode
118
133
  replace` is refused here. The journal is `~/.myc/wire-user.json`; `myc unwire
119
134
  --scope user` restores the settings node by node and removes the MCP server.
120
135
 
136
+ opencode in such a worktree is in the same position, and `--agents opencode`
137
+ (or `claude,opencode`; without `--agents` the user layer is Claude Code's only)
138
+ wires its global config, `$XDG_CONFIG_HOME/opencode` or `~/.config/opencode`:
139
+ the `myc` server goes into `mcp` of the `opencode.json[c]` opencode itself treats
140
+ as its own, as one node — the file is JSONC, and other entries, comments and
141
+ trailing commas stay byte for byte — and `plugin/myc.ts` goes next to it. opencode
142
+ starts that server in the directory it was opened in, so `myc mcp` finds the
143
+ workspace from a worktree by itself. The plugin makes the same two checks as the
144
+ helper, once per project and without starting myc: no workspace here, or the
145
+ project wires opencode itself (`opencode.json` with `mcp.myc`, or
146
+ `.opencode/plugin/myc.ts` — opencode loads the plugins of both layers, and a
147
+ project's `mcp.myc` overrides this one) — then it registers no hooks at all.
148
+ `myc unwire --scope user` takes out exactly that node and the plugin.
149
+
121
150
  With `--status-line` the user layer also gets myc's status line, `myc
122
151
  statusline --scope user`: in a myc workspace — a git worktree of one included —
123
152
  it is the full line, outside one it prints nothing of its own. The line that was
@@ -134,7 +163,7 @@ unwire --scope user` puts the previous line back byte for byte. `myc doctor
134
163
  --hooks` checks the whole user layer against the journal: myc's hook entries and
135
164
  rules still in `~/.claude/settings.json`, the helpers exactly what this build
136
165
  writes (a stale one is named with the build that wrote it), the status line, the
137
- MCP server.
166
+ MCP server — and, when opencode is wired, its plugin and `mcp.myc`.
138
167
 
139
168
  ## Heavy commands take turns
140
169
 
@@ -431,8 +460,9 @@ last-writer-wins over whole records.
431
460
 
432
461
  **Guards are proved by mutation.** Every refusal and every invariant is
433
462
  accompanied by a mutation that removes it; a guard whose removal breaks no test
434
- is treated as absent. The full suite: 3672 pass / 0 fail / 16 skip
435
- (`bun test`, 2026-09-11).
463
+ is treated as absent. The full suite: 3790 pass / 1 fail / 16 skip
464
+ (`bun test`, 2026-09-15; the one failure is the queue hook's latency budget —
465
+ p99 46 ms against 30 ms on a loaded laptop, the hook itself unchanged since 0.3.10).
436
466
 
437
467
  ## What myc does
438
468