@corenel/cli 0.3.1 → 0.4.0
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 +56 -2
- package/dist/cli.js +5118 -2672
- package/package.json +20 -15
package/README.md
CHANGED
|
@@ -7,7 +7,61 @@ transport). Early/beta: the headless proof the kernel runs outside the browser.
|
|
|
7
7
|
npx @corenel/cli
|
|
8
8
|
```
|
|
9
9
|
|
|
10
|
-
Requires Node 18+. Bring your provider key via the environment.
|
|
11
|
-
|
|
10
|
+
Requires Node 18+. Bring your provider key via the environment.
|
|
11
|
+
|
|
12
|
+
Running `corenel` with no command opens an interactive agent in the current
|
|
13
|
+
directory. On a terminal it opens the full terminal face; when output is piped,
|
|
14
|
+
under `TERM=dumb`, in CI, or with `--no-tui`, it falls back to a plain
|
|
15
|
+
line-by-line loop. `--tui` demands the full face and fails rather than falling
|
|
16
|
+
back. `--resume` reopens the last conversation.
|
|
17
|
+
|
|
18
|
+
Assistant replies render as markdown. More verbs (`run` / `ask` / `chat` /
|
|
19
|
+
`login`, and `start --sidecar`) are in progress.
|
|
20
|
+
|
|
21
|
+
## Releasing
|
|
22
|
+
|
|
23
|
+
`@corenel/term` (the terminal face) is a real runtime dependency, not bundled
|
|
24
|
+
into `dist/cli.js` -- see the note at the top of `build.mjs`. `@corenel/term`'s
|
|
25
|
+
own dist is bundled but keeps `@corenel/harness` and `@corenel/protocol`
|
|
26
|
+
EXTERNAL (see `packages/term/build.mjs`) -- both the CLI and term import the
|
|
27
|
+
harness directly, and they must resolve to the SAME installed copy, or the
|
|
28
|
+
`llm-execution` feature guard and `--debug` logging silently apply to the
|
|
29
|
+
wrong module instance. That makes all four packages real runtime dependencies
|
|
30
|
+
of each other, and publish order matters:
|
|
31
|
+
|
|
32
|
+
pnpm --filter @corenel/protocol build && pnpm --filter @corenel/protocol publish
|
|
33
|
+
pnpm --filter @corenel/harness build && pnpm --filter @corenel/harness publish
|
|
34
|
+
pnpm --filter @corenel/term build && pnpm --filter @corenel/term publish
|
|
35
|
+
pnpm --filter @corenel/cli build && pnpm --filter @corenel/cli publish
|
|
36
|
+
|
|
37
|
+
Publishing any package against an unpublished dependency yields one that
|
|
38
|
+
cannot install at all, so `npx @corenel/cli` fails before any verb runs.
|
|
39
|
+
|
|
40
|
+
Publish with **pnpm, never npm**: this CLI depends on `@corenel/term` as
|
|
41
|
+
`workspace:*`, and pnpm rewrites the `workspace:` protocol to a real version at
|
|
42
|
+
pack/publish time while npm ships it verbatim -- an `npm publish` from this
|
|
43
|
+
workspace produces a manifest whose install fails with
|
|
44
|
+
`EUNSUPPORTEDPROTOCOL / Unsupported URL Type "workspace:"`, which is the very
|
|
45
|
+
breakage this section exists to prevent.
|
|
46
|
+
|
|
47
|
+
**All four versions must be bumped and published together, in the order
|
|
48
|
+
above, every release -- even one that only touches a single package.** pnpm
|
|
49
|
+
rewrites every `workspace:*` dependency to the EXACT current version of that
|
|
50
|
+
dependency at pack time. All four packages are pinned to the same harness
|
|
51
|
+
version today, so a normal `npm install` of `@corenel/cli` resolves to one
|
|
52
|
+
harness copy. Bump `@corenel/harness` and publish a new `@corenel/term`
|
|
53
|
+
without also republishing `@corenel/cli`, and the tree that installs
|
|
54
|
+
`@corenel/cli` gets the OLD harness version nested under it (frozen into the
|
|
55
|
+
manifest `@corenel/cli` published against) plus the NEW harness version
|
|
56
|
+
hoisted at the top level for `@corenel/term` -- two separate harness module
|
|
57
|
+
instances again, silently. That is exactly the bug this section's ordering
|
|
58
|
+
exists to prevent (see `harnessSingleInstance.test.ts` in this package's
|
|
59
|
+
`test/`): `registerGuard()`/`setAgentLogging()` calls made through one
|
|
60
|
+
instance configure a module the other never reads, so the `llm-execution`
|
|
61
|
+
feature gate silently stops running and `--debug` logging can't be turned
|
|
62
|
+
off. Every test in this repo stays green when that happens, because the
|
|
63
|
+
in-repo workspace is symlinked (one instance by construction) and the
|
|
64
|
+
build-output regression test only exercises that same symlinked layout --
|
|
65
|
+
neither one can see a real, version-skewed `npm install`.
|
|
12
66
|
|
|
13
67
|
Licensed under Elastic-2.0.
|