@aistastudio/myc 0.3.14 → 0.4.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/README.md +101 -24
- package/dist/myc.js +2089 -995
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -30,19 +30,25 @@ The runtime is bound to `bun:sqlite` (no native bindings on the Node side).
|
|
|
30
30
|
**It will not start on plain Node.js or Deno.** Bun ≥ 1.3.0 is required and
|
|
31
31
|
pinned in `package.json` → `engines.bun`.
|
|
32
32
|
|
|
33
|
-
**SQLite ≥ 3.
|
|
34
|
-
`trusted_schema = OFF`, so every write fails.
|
|
35
|
-
|
|
36
|
-
|
|
33
|
+
**SQLite ≥ 3.50.4.** The floor has two reasons. Below 3.44.0, FTS5 cannot be
|
|
34
|
+
written from triggers under `trusted_schema = OFF`, so every write fails. And on
|
|
35
|
+
3.43.2 and 3.46.0, parallel myc processes were measured running one background
|
|
36
|
+
job two or three times, with a failing job reporting "database disk image is
|
|
37
|
+
malformed"; the cause is not known, so myc refuses every library below what a
|
|
38
|
+
supported setup gives it. Nothing supported loses anything: on Linux, Bun links
|
|
39
|
+
its own SQLite (3.50.4 in Bun 1.3.0, the minimum in `engines.bun`; 3.53.0 in
|
|
40
|
+
Bun 1.3.14), and on macOS, where Bun would use the system SQLite — 3.43.2 on
|
|
41
|
+
macOS 14 — the package ships its own: `vendor/sqlite/libmyc-sqlite3.dylib`,
|
|
37
42
|
SQLite 3.53.4 built from the official amalgamation for arm64 and x86_64
|
|
38
43
|
(`scripts/build-sqlite.ts`), chosen before anything else except an explicit
|
|
39
44
|
`MYC_SQLITE=/path/to/libsqlite3.dylib`. If the SQLite in use is still below
|
|
40
|
-
3.
|
|
41
|
-
command, `myc init` included, refuses with
|
|
42
|
-
what to do, instead of creating a
|
|
43
|
-
to 3.51.2 myc works but warns
|
|
44
|
-
|
|
45
|
-
`myc doctor` names the SQLite in use and where
|
|
45
|
+
3.50.4 — a broken install, an unsupported Bun, or `MYC_SQLITE` pointing at an
|
|
46
|
+
old library — every command, `myc init` included, refuses with
|
|
47
|
+
`precond.sqlite_unsupported` and says what to do, instead of creating a
|
|
48
|
+
workspace it cannot write to. From 3.50.4 up to 3.51.2 myc works but warns
|
|
49
|
+
(`WARN degraded.sqlite_old`): that band is not proven safe for the queue, and on
|
|
50
|
+
Linux the cure is `bun upgrade`. `myc doctor` names the SQLite in use and where
|
|
51
|
+
it came from.
|
|
46
52
|
|
|
47
53
|
Install Bun: https://bun.sh
|
|
48
54
|
|
|
@@ -51,8 +57,8 @@ Install Bun: https://bun.sh
|
|
|
51
57
|
Installation is one command:
|
|
52
58
|
|
|
53
59
|
```bash
|
|
54
|
-
bun install -g @aistastudio/myc # 5.
|
|
55
|
-
myc --version # myc 0.
|
|
60
|
+
bun install -g @aistastudio/myc # 5.11 MB compressed, 15.79 MB unpacked, 16 files; no models pulled
|
|
61
|
+
myc --version # myc 0.4.1 (schema 1)
|
|
56
62
|
```
|
|
57
63
|
|
|
58
64
|
It runs on macOS and Linux. On Windows, use WSL and install Bun and myc inside
|
|
@@ -460,8 +466,8 @@ last-writer-wins over whole records.
|
|
|
460
466
|
|
|
461
467
|
**Guards are proved by mutation.** Every refusal and every invariant is
|
|
462
468
|
accompanied by a mutation that removes it; a guard whose removal breaks no test
|
|
463
|
-
is treated as absent. The full suite:
|
|
464
|
-
(`bun test`, 2026-09-
|
|
469
|
+
is treated as absent. The full suite: 4184 pass / 0 fail / 16 skip
|
|
470
|
+
(`bun test`, 2026-09-30).
|
|
465
471
|
|
|
466
472
|
## What myc does
|
|
467
473
|
|
|
@@ -471,8 +477,9 @@ ranked hybrid search; the code index above; hooks and MCP for four agents;
|
|
|
471
477
|
the machine-wide queue for heavy commands; the status line; import from beads;
|
|
472
478
|
a local web interface (`myc viz`: graph, queue, board, cards, search, health —
|
|
473
479
|
edits go through the same write path as the CLI); git worktrees and nested
|
|
474
|
-
repositories;
|
|
475
|
-
|
|
480
|
+
repositories; a team server over Postgres with tokens, roles and ACL
|
|
481
|
+
(`myc serve`, see below); sync through git or through that server; and a
|
|
482
|
+
`doctor` that compares claims with a recount.
|
|
476
483
|
|
|
477
484
|
The full list — each capability with the release it arrived in and a command
|
|
478
485
|
that shows it on your machine, every command checked against this build's
|
|
@@ -492,14 +499,84 @@ In short: the core, memory, semantics and the human interface (M0–M2, M7) are
|
|
|
492
499
|
done or nearly done, and so is English output for every CLI and MCP line; code
|
|
493
500
|
intelligence (M3, including the built-in replacement for graft) and the
|
|
494
501
|
heavy-command queue have shipped, with tasks still open; the team milestone
|
|
495
|
-
(M4: `myc serve`, ACL, network sync, Postgres) is
|
|
496
|
-
|
|
497
|
-
|
|
498
|
-
|
|
499
|
-
|
|
500
|
-
|
|
501
|
-
|
|
502
|
-
|
|
502
|
+
(M4: `myc serve`, ACL, network sync, Postgres) is built and running — 10 of its
|
|
503
|
+
15 tasks are closed, and what is left is its own acceptance (a week of two
|
|
504
|
+
people and four agents on one server), hybrid search on Postgres, SSE deltas,
|
|
505
|
+
the `leader` and `full` MCP profiles, and a bulk SQLite→Postgres migration;
|
|
506
|
+
swarm self-learning (M5: routing by cost and outcome, with a shared pool of
|
|
507
|
+
agent statistics) and distillation (M6) have not started.
|
|
508
|
+
|
|
509
|
+
What that means in practice: **myc is a local tool first, and a team server
|
|
510
|
+
second — and the two are not the same thing.** Everything works locally over
|
|
511
|
+
files in git. The server exists, is tested against a live Postgres and is
|
|
512
|
+
described below, but only part of the CLI speaks to it; the rest refuses out
|
|
513
|
+
loud rather than quietly writing somewhere else.
|
|
514
|
+
|
|
515
|
+
## The team server
|
|
516
|
+
|
|
517
|
+
One command gives a server you can actually use — no manual steps:
|
|
518
|
+
|
|
519
|
+
```bash
|
|
520
|
+
docker compose -f deploy/compose.yml up -d
|
|
521
|
+
docker compose -f deploy/compose.yml logs server | grep 'bootstrap token'
|
|
522
|
+
```
|
|
523
|
+
|
|
524
|
+
Postgres runs the schema itself on an empty volume, and the server registers
|
|
525
|
+
the first tenant and mints the first token from `MYC_BOOTSTRAP_*`. That sample
|
|
526
|
+
deployment is not production: the password is in the open, there is no TLS,
|
|
527
|
+
and the database sits in a volume next to it. TLS is the deployment's job —
|
|
528
|
+
put a reverse proxy in front and let it set `X-Forwarded-Proto`.
|
|
529
|
+
|
|
530
|
+
Without containers it is the same binary:
|
|
531
|
+
|
|
532
|
+
```bash
|
|
533
|
+
myc serve --pg postgres://myc_app:…@host/myc --apply-schema # empty db only
|
|
534
|
+
myc serve --pg … --add-tenant acme
|
|
535
|
+
myc serve --pg … --add-token acme:anna --role owner # secret printed once
|
|
536
|
+
myc serve --pg … --port 8080
|
|
537
|
+
```
|
|
538
|
+
|
|
539
|
+
Everything but the liveness probe `/v1/health` needs a token. A token stores
|
|
540
|
+
only its sha256, so a copy of the database gives no access and nobody can read
|
|
541
|
+
a secret back. Roles are `owner`, `maintainer`, `member`, `agent`, `viewer`;
|
|
542
|
+
rights are `read`, `write`, `claim`, `sync`, `admin`, and `--scopes` narrows
|
|
543
|
+
what a role means. `sync` is deliberately not part of `read`: a replica is not
|
|
544
|
+
filtered by the visibility predicate, so the right to pull one is the right to
|
|
545
|
+
see everything in the workspace. The admin page at `/v1/admin` asks a browser
|
|
546
|
+
for a token in a form and keeps it in an HttpOnly, SameSite=Strict cookie.
|
|
547
|
+
|
|
548
|
+
A client points at the server through the environment, never the command line
|
|
549
|
+
(arguments are visible in `ps`, in shell history and in hook logs):
|
|
550
|
+
|
|
551
|
+
```bash
|
|
552
|
+
export MYC_SERVER=https://myc.example/acme # workspace in the path
|
|
553
|
+
export MYC_TOKEN=myc_…
|
|
554
|
+
myc ready
|
|
555
|
+
```
|
|
556
|
+
|
|
557
|
+
**Only part of the CLI speaks to a server, and this is the important part.**
|
|
558
|
+
Working remotely today: `create`/`task`/`bug`/`epic`/`msg`, `update`, `claim`,
|
|
559
|
+
`list`, `ready`, `show`, `prime` and `sync`. Everything else — `close`,
|
|
560
|
+
`remember`, `recall`, `comment`, `link`, `dep`, `attempt`, `search`, `code` —
|
|
561
|
+
refuses with `precond.no_remote` instead of silently using the local database,
|
|
562
|
+
because seeing someone else's tasks and taking them for the team's is worse
|
|
563
|
+
than an error. So the server is a place where replicas **meet**, not yet a
|
|
564
|
+
place where the whole working loop lives.
|
|
565
|
+
|
|
566
|
+
That is why the normal shape today is: every machine keeps its own local
|
|
567
|
+
workspace and exchanges through the server.
|
|
568
|
+
|
|
569
|
+
```bash
|
|
570
|
+
myc sync # both ways; --push-only, --pull-only, --dry-run
|
|
571
|
+
```
|
|
572
|
+
|
|
573
|
+
The exchange carries operations, not rows: deduplicated by `op_id`, replayed
|
|
574
|
+
through the same CRDT path as a git merge (per-field LWW, add-wins edges,
|
|
575
|
+
G-counters), with a cursor per site, so repeating it changes nothing and an
|
|
576
|
+
interrupted exchange resumes.
|
|
577
|
+
|
|
578
|
+
Step by step, for a real host with TLS, tokens per person, backups and what
|
|
579
|
+
to do when something refuses: [`docs/deploy.md`](docs/deploy.md).
|
|
503
580
|
|
|
504
581
|
## Syncing between machines
|
|
505
582
|
|