@ngockhoale/ukit 2.2.5 → 2.2.6

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/CHANGELOG.md CHANGED
@@ -2,6 +2,31 @@
2
2
 
3
3
  All notable changes to UKit are documented here.
4
4
 
5
+ ## 2.2.6 - 2026-08-27
6
+
7
+ Follow-up to a real-world report: a user on a Bun-hosted/self-compiled omp build kept getting
8
+ every Edit/Write blocked with `UKit OMP hook runner failed before producing a valid result
9
+ (killed=true, ..., runtime=/Users/.../bin/omp)`. The diagnostic added in 2.2.4 was already
10
+ honest about the failure, but it did not say *why* — `runtime=` pointed straight at omp's own
11
+ binary (proof that `process.execPath` inside that omp build resolves to omp itself, not a real
12
+ Node.js binary), yet the message never told the user the fix was to set `UKIT_NODE_PATH`.
13
+
14
+ ### Fixed
15
+
16
+ - **The omp bridge's transport-failure message named the wrong-runtime symptom but never the
17
+ fix.** [`ukit-bridge.js`](.omp/hooks/pre/ukit-bridge.js) already resolved
18
+ `process.env.UKIT_NODE_PATH || process.execPath` and reported the resolved `runtime` on failure
19
+ (2.2.4), but a user seeing `runtime=/Users/lenk/.local/bin/omp` had no way to know that string
20
+ meant "wrong binary" or what to do about it. When `UKIT_NODE_PATH` is unset, the failure
21
+ message now appends: the reported runtime may not be a real Node.js binary, and the exact fix —
22
+ `export UKIT_NODE_PATH="$(command -v node)"`. No behavior change when `UKIT_NODE_PATH` is
23
+ already set.
24
+
25
+ ### Added
26
+
27
+ - **2 regression tests** in `tests/hooks/ompHookBridge.test.js` (case 13) — the wrong-runtime
28
+ hint appears when `UKIT_NODE_PATH` is unset, and is omitted when it is already set.
29
+
5
30
  ## 2.2.5 - 2026-08-27
6
31
 
7
32
  Follow-up to the user's report that UKit had become too heavy-handed: too many hook scripts firing per tool call, too much blocking, and a concrete false-positive in the destructive-command gate itself. This wave trims default hook wiring and fixes the false positive, while explicitly preserving `rm`/destructive-command protection as instructed.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@ngockhoale/ukit",
3
- "version": "2.2.5",
3
+ "version": "2.2.6",
4
4
  "description": "Install/update an index-first AI workspace for Claude Code, OpenAI Codex, OpenCode, and omp (Oh My Pi).",
5
5
  "license": "MIT",
6
6
  "type": "module",
@@ -241,10 +241,15 @@ export async function runScriptChain(
241
241
  wrapperError: chainResult?.wrapperError || null,
242
242
  };
243
243
  recordHookErrorDiagnostic(projectRoot, payload.session_id, diagnostic);
244
+ const nodePathHint = process.env.UKIT_NODE_PATH
245
+ ? ''
246
+ : ` "${diagnostic.nodeExecutable}" may not be a real Node.js binary (e.g. a Bun-hosted or `
247
+ + `self-compiled omp reports its own path as process.execPath). If so, set UKIT_NODE_PATH `
248
+ + `to one, e.g.: export UKIT_NODE_PATH="$(command -v node)".`;
244
249
  const reason = `UKit OMP hook runner failed before producing a valid result `
245
250
  + `(killed=${diagnostic.killed}, code=${diagnostic.code}, elapsedMs=${diagnostic.elapsedMs}, `
246
251
  + `runtime=${diagnostic.nodeExecutable}). No safety-gate verdict was available for [${scripts.join(', ')}]. `
247
- + `See .ukit/storage/cache/hook-errors/.`;
252
+ + `See .ukit/storage/cache/hook-errors/.${nodePathHint}`;
248
253
  if (failClosedOnTransportError) {
249
254
  return { block: true, reason, context, invoked };
250
255
  }