@corenel/cli 0.5.0 → 0.7.0

package/README.md

@@ -1,68 +1,68 @@
-# @corenel/cli
-
-The Corenel CLI — runs the host-agnostic agent harness in Node, in-process (no
-transport). Early/beta: the headless proof the kernel runs outside the browser.
-
-```bash
-npx @corenel/cli
-```
-
-Requires Node 18+. Bring your provider key via the environment.
-
-Running `corenel` with no command opens an interactive agent in the current
-directory. On a terminal it opens the full terminal face; when output is piped,
-under `TERM=dumb`, in CI, or with `--no-tui`, it falls back to a plain
-line-by-line loop. `--tui` demands the full face and fails rather than falling
-back. `--resume` reopens the last conversation.
-
-Assistant replies render as markdown. More verbs (`run` / `ask` / `chat` /
-`login`, and `start --sidecar`) are in progress.
-
-## Releasing
-
-`@corenel/term` (the terminal face) is a real runtime dependency, not bundled
-into `dist/main.js` -- see the note at the top of `build.mjs`. (`dist/cli.js`,
-the bin, is only a Node >=18 check that then imports `main.js`.) `@corenel/term`'s
-own dist is bundled but keeps `@corenel/harness` and `@corenel/protocol`
-EXTERNAL (see `packages/term/build.mjs`) -- both the CLI and term import the
-harness directly, and they must resolve to the SAME installed copy, or the
-`llm-execution` feature guard and `--debug` logging silently apply to the
-wrong module instance. That makes all four packages real runtime dependencies
-of each other, and publish order matters:
-
-    pnpm --filter @corenel/protocol build && pnpm --filter @corenel/protocol publish
-    pnpm --filter @corenel/harness  build && pnpm --filter @corenel/harness  publish
-    pnpm --filter @corenel/term     build && pnpm --filter @corenel/term     publish
-    pnpm --filter @corenel/cli      build && pnpm --filter @corenel/cli      publish
-
-Publishing any package against an unpublished dependency yields one that
-cannot install at all, so `npx @corenel/cli` fails before any verb runs.
-
-Publish with **pnpm, never npm**: this CLI depends on `@corenel/term` as
-`workspace:*`, and pnpm rewrites the `workspace:` protocol to a real version at
-pack/publish time while npm ships it verbatim -- an `npm publish` from this
-workspace produces a manifest whose install fails with
-`EUNSUPPORTEDPROTOCOL / Unsupported URL Type "workspace:"`, which is the very
-breakage this section exists to prevent.
-
-**All four versions must be bumped and published together, in the order
-above, every release -- even one that only touches a single package.** pnpm
-rewrites every `workspace:*` dependency to the EXACT current version of that
-dependency at pack time. All four packages are pinned to the same harness
-version today, so a normal `npm install` of `@corenel/cli` resolves to one
-harness copy. Bump `@corenel/harness` and publish a new `@corenel/term`
-without also republishing `@corenel/cli`, and the tree that installs
-`@corenel/cli` gets the OLD harness version nested under it (frozen into the
-manifest `@corenel/cli` published against) plus the NEW harness version
-hoisted at the top level for `@corenel/term` -- two separate harness module
-instances again, silently. That is exactly the bug this section's ordering
-exists to prevent (see `harnessSingleInstance.test.ts` in this package's
-`test/`): `registerGuard()`/`setAgentLogging()` calls made through one
-instance configure a module the other never reads, so the `llm-execution`
-feature gate silently stops running and `--debug` logging can't be turned
-off. Every test in this repo stays green when that happens, because the
-in-repo workspace is symlinked (one instance by construction) and the
-build-output regression test only exercises that same symlinked layout --
-neither one can see a real, version-skewed `npm install`.
-
-Licensed under Elastic-2.0.
+# @corenel/cli
+
+The Corenel CLI — runs the host-agnostic agent harness in Node, in-process (no
+transport). Early/beta: the headless proof the kernel runs outside the browser.
+
+```bash
+npx @corenel/cli
+```
+
+Requires Node 22+. Bring your provider key via the environment.
+
+Running `corenel` with no command opens an interactive agent in the current
+directory. On a terminal it opens the full terminal face; when output is piped,
+under `TERM=dumb`, in CI, or with `--no-tui`, it falls back to a plain
+line-by-line loop. `--tui` demands the full face and fails rather than falling
+back. `--resume` reopens the last conversation.
+
+Assistant replies render as markdown. More verbs (`run` / `ask` / `chat` /
+`login`, and `start --sidecar`) are in progress.
+
+## Releasing
+
+`@corenel/term` (the terminal face) is a real runtime dependency, not bundled
+into `dist/main.js` -- see the note at the top of `build.mjs`. (`dist/cli.js`,
+the bin, is only a Node >=22 check that then imports `main.js`.) `@corenel/term`'s
+own dist is bundled but keeps `@corenel/harness` and `@corenel/protocol`
+EXTERNAL (see `packages/term/build.mjs`) -- both the CLI and term import the
+harness directly, and they must resolve to the SAME installed copy, or the
+`llm-execution` feature guard and `--debug` logging silently apply to the
+wrong module instance. That makes all four packages real runtime dependencies
+of each other, and publish order matters:
+
+    pnpm --filter @corenel/protocol build && pnpm --filter @corenel/protocol publish
+    pnpm --filter @corenel/harness  build && pnpm --filter @corenel/harness  publish
+    pnpm --filter @corenel/term     build && pnpm --filter @corenel/term     publish
+    pnpm --filter @corenel/cli      build && pnpm --filter @corenel/cli      publish
+
+Publishing any package against an unpublished dependency yields one that
+cannot install at all, so `npx @corenel/cli` fails before any verb runs.
+
+Publish with **pnpm, never npm**: this CLI depends on `@corenel/term` as
+`workspace:*`, and pnpm rewrites the `workspace:` protocol to a real version at
+pack/publish time while npm ships it verbatim -- an `npm publish` from this
+workspace produces a manifest whose install fails with
+`EUNSUPPORTEDPROTOCOL / Unsupported URL Type "workspace:"`, which is the very
+breakage this section exists to prevent.
+
+**All four versions must be bumped and published together, in the order
+above, every release -- even one that only touches a single package.** pnpm
+rewrites every `workspace:*` dependency to the EXACT current version of that
+dependency at pack time. All four packages are pinned to the same harness
+version today, so a normal `npm install` of `@corenel/cli` resolves to one
+harness copy. Bump `@corenel/harness` and publish a new `@corenel/term`
+without also republishing `@corenel/cli`, and the tree that installs
+`@corenel/cli` gets the OLD harness version nested under it (frozen into the
+manifest `@corenel/cli` published against) plus the NEW harness version
+hoisted at the top level for `@corenel/term` -- two separate harness module
+instances again, silently. That is exactly the bug this section's ordering
+exists to prevent (see `harnessSingleInstance.test.ts` in this package's
+`test/`): `registerGuard()`/`setAgentLogging()` calls made through one
+instance configure a module the other never reads, so the `llm-execution`
+feature gate silently stops running and `--debug` logging can't be turned
+off. Every test in this repo stays green when that happens, because the
+in-repo workspace is symlinked (one instance by construction) and the
+build-output regression test only exercises that same symlinked layout --
+neither one can see a real, version-skewed `npm install`.
+
+Licensed under Elastic-2.0.

package/dist/cli.js

@@ -1,7 +1,7 @@
 #!/usr/bin/env node
 var major = Number(process.versions.node.split('.')[0]);
-if (!(major >= 18)) {
-  process.stderr.write('corenel needs Node.js 18 or newer. This is ' + process.version + ' at ' + process.execPath + '.\n');
+if (!(major >= 22)) {
+  process.stderr.write('corenel needs Node.js 22 or newer. This is ' + process.version + ' at ' + process.execPath + '.\n');
   process.exit(1);
 }
 import('./main.js');