@globant/coda-linux-arm64 1.4.0 → 1.5.0

package/assets/skills/init-rules/SKILL.md

@@ -17,6 +17,8 @@ This skill assumes the session is running in **auto mode** (unattended/hands-off
 
 If the user is not in auto mode, still proceed — the rules are valid in any mode — but note that in `default`/`read-only` mode many commands already require approval, so `deny`/`ask` rules matter most.
 
+Keeping auto after the rules land: on a fresh install the silent `auto` default applies to the current session only, and only while no `permissions` block exists. Saving a rule never changes the starting mode, so once the first rule is written, later sessions start in `default`. If the user wants to keep starting in auto, ask them, and if they agree propose it explicitly: `propose_policy` with `{ "op": "set-mode", "mode": "auto", "scope": "global" }`. It is a loosen, so the user sees and approves exactly that change. Project scope can only lower the mode, so raising it must be global. Headless, a loosen is auto-refused: report the `set-mode` suggestion instead. If the user already chose a mode, don't propose one.
+
 ## Interactive vs. headless
 
 - **Interactive:** follow every step, using `ask_user` to confirm choices.
@@ -24,7 +26,25 @@ If the user is not in auto mode, still proceed — the rules are valid in any mo
 
 ---
 
-## Step 1 — Explore the project
+## Step 1 — Detect the OS and shell dialect
+
+CODA's command rules are **dialect-scoped**: a `Bash(...)` rule only matches when the session's resolved shell routes to the POSIX extractor, and a `PowerShell(...)` rule only matches when it routes to the PowerShell extractor. A bash rule is **inert on Windows PowerShell**, and a PowerShell rule is inert on macOS/Linux. So you MUST author rules for the dialect the user actually runs, or the rules silently match nothing.
+
+Detect the platform first, then pick the dialect:
+
+- Run a quick probe to learn the OS/shell. Prefer a portable check, e.g. `uname -s` (prints `Darwin`/`Linux` on macOS/Linux; fails or is absent on native Windows), or inspect the environment. On Windows, `$PSVersionTable` / `echo $env:OS` confirm PowerShell.
+- Map the result to a dialect:
+  - **macOS (`Darwin`) or Linux → `bash` dialect.** Author `Bash(...)` rules. (This also covers WSL and any POSIX shell — bash/zsh/sh/dash/ksh/ash.)
+  - **Windows PowerShell / pwsh → `pwsh` dialect.** Author `PowerShell(...)` rules (the tags `PowerShell(...)`, `powershell(...)`, and `pwsh(...)` are all equivalent).
+- If the probe is ambiguous, ask the user with `ask_user` which shell they run (`bash`/`zsh` vs `PowerShell`) before proposing any command rules.
+
+State the detected dialect back to the user, e.g. *"You're on macOS, so I'll propose `Bash(...)` rules"* or *"You're on Windows PowerShell, so I'll propose `PowerShell(...)` rules"*, and use **that dialect for every command rule** in the steps below. Everywhere this skill shows `Bash(...)`, substitute `PowerShell(...)` when the user is on Windows.
+
+> Note: file rules (`Read`/`Edit`/`Write`) and MCP rules (`mcp__server`) are **not** dialect-scoped — they apply on every OS unchanged. Only command rules switch between `Bash(...)` and `PowerShell(...)`.
+
+---
+
+## Step 2 — Explore the project
 
 Understand what commands this project legitimately runs so your rules fit reality. Do NOT skip this.
 
@@ -38,7 +58,9 @@ Search in the ~/.coda/coda.db database for bash commands to get a sense of the c
 
 ---
 
-## Step 2 — Choose how permissive the rules should be
+## Step 3 — Choose how permissive the rules should be
+
+> Use the dialect you detected in Step 1 for every command rule below. The examples show the `Bash(...)` (macOS/Linux) form; on Windows author the `PowerShell(...)` equivalents from the palette further down.
 
 Ask the user which posture they want. Use `ask_user`:
 
@@ -47,32 +69,34 @@ Ask the user which posture they want. Use `ask_user`:
 > - **Restrictive** — allow only a short, explicit allowlist; `ask` before anything not on it; deny a broad set of destructive/network commands.
 > - **Balanced** — allow the confirmed dev commands, `ask` for git-writes and network/publish, deny destructive ones.
 
-Then, using what you found in Step 1, propose the concrete rule set and confirm the risky ones with `ask_user` before writing. Typical shapes (adapt to the actual project):
+Then, using what you found in Step 2, propose the concrete rule set and confirm the risky ones with `ask_user` before writing. Typical shapes (adapt to the actual project):
 
-- **Allow** (permissive/balanced): `Bash(pnpm test:*)`, `Bash(pnpm lint:*)`, `Bash(pnpm type-check)`, `Bash(git status)`, `Bash(git log:*)`, `Bash(git diff:*)`.
+- **Allow** (permissive): `Bash(pnpm:*)`, `Bash(git:*)`, `Bash(bunx)`, `Bash(npx)`, `Bash(git:*)`, `Bash(python3:*)`.
 - **Ask** (guardrails on state-changing / outbound actions): `Bash(git push:*)`, `Bash(git commit:*)`, `Bash(npm publish:*)`, `Bash(curl:*)`.
 - **Deny** (destructive / dangerous): `Bash(rm:*)`, `Bash(git reset --hard:*)`, `Bash(chmod:*)` — deny whatever the user does not want the agent doing unattended.
 
 Rule syntax reminders (this is exactly what `propose_policy` writes):
-- `Bash(npm:*)` = any command starting with `npm`; `Bash(git push origin main)` = exact match; `Bash(*)` = any bash command (**too permissive — don't recommend it**, see below); bare `Bash` = the whole tool.
-- File tools take globs: `Read(//etc/passwd)` (double slash = absolute), `Edit(src/**)`, `Write(package.json)`.
+- **Command rules are dialect-scoped (Step 1):** `Bash(...)` matches POSIX shells (macOS/Linux); `PowerShell(...)` (also written `pwsh(...)` / `powershell(...)`) matches Windows PowerShell. Author the tag for the detected OS — the other tag is inert.
+- `Bash(npm:*)` = any command starting with `npm`; `Bash(git push origin main)` = exact match; `Bash(*)` = any bash command (**too permissive — don't recommend it**, see below); bare `Bash` = the whole tool. On Windows the same shapes are `PowerShell(npm:*)`, `PowerShell(Remove-Item -Recurse ...)`, etc.
+- PowerShell command names are **case-insensitive** and cmdlet aliases are normalized — `PowerShell(Invoke-Expression:*)` also matches `iex`, and `-Force` matches `-force`. Bash names stay case-sensitive.
+- File tools take globs (dialect-independent): `Read(//etc/passwd)` (double slash = absolute), `Edit(src/**)`, `Write(package.json)`.
 - MCP: `mcp__filesystem` (whole server) or `mcp__filesystem__read_file` (one tool).
 - Effects: `allow` (no prompt), `ask` (always prompt, even in auto), `deny` (always block).
 
-Precedence is **deny-first**: `deny` > `ask` > `allow` > mode. Nothing overrides a `deny`, and nothing overrides the catastrophic floor (`rm -rf /`, `sudo`, private-key/credential reads, writes to secret files like `.env` / `.secrets`, etc. — never relaxable, so don't bother proposing rules for those). Note that editing `config.json`, `mcp.json`, or `agents.md` is *not* on that floor: it is allowed as an approval-gated authoring write (see Step 5).
+Precedence is **deny-first**: `deny` > `ask` > `allow` > mode. Nothing overrides a `deny`, and nothing overrides the catastrophic floor (`rm -rf /`, `sudo`, private-key/credential reads, writes to secret files like `.env` / `.secrets`, etc. — never relaxable, so don't bother proposing rules for those). Note that editing `config.json`, `mcp.json`, or `agents.md` is *not* on that floor: it is allowed as an approval-gated authoring write (see Step 6).
 
 ### Command-scoped allow rules
 
-IMPORTANT: Do not recommend `Bash(*)` as it won't allow cases that are related to package managers, etc. 
-Bash(*) doesn't allow every bash command, it isn't the most permissive rule possible. 
-Each command is broken down and evaluated independently. 
+IMPORTANT: Do not recommend `Bash(*)` (or `PowerShell(*)`). A token-less wildcard is deliberately **rejected as a floor-relaxer** by the engine: install-class commands (package managers, package runners, interpreter installs) keep asking even with `Bash(*)` present, so it does not actually give the blanket auto-approval users expect — it just weakens their allowlist without buying the convenience. Each sub-command of a compound command (`a && b`) is also evaluated independently, so a broad allow can never rescue a sub-command a floor or deny rule blocks.
 
-Recommendation: **allow one command family at a time** with `Bash(<tool>:*)`. Each such rule auto-allows only that executable and its arguments, so the agent can run the tool freely while everything else still falls back to `ask`/`deny`/mode.
+Recommendation: **allow one command family at a time** with `Bash(<tool>:*)` (or `PowerShell(<tool>:*)` on Windows). Each such rule auto-allows only that executable and its arguments — and, because it names a binary, it *can* relax that command's install-class floor — while everything else still falls back to `ask`/`deny`/mode.
 
 - If a user needs to run **all `pnpm` commands**, the ideal rule is `Bash(pnpm:*)` — not `Bash(*)`.
 - Same idea per tool: `Bash(bun:*)` for all `bun` commands, `Bash(cargo:*)` for all `cargo` commands, and so on.
 
-Build the allow list from the tools the project actually uses (from Step 1). A palette of common command-scoped rules to draw from:
+Build the allow list from the tools the project actually uses (from Step 2). **Pick the palette for the detected OS** (Step 1) — use the `Bash(...)` palette on macOS/Linux, the `PowerShell(...)` palette on Windows. Do not mix dialects.
+
+**macOS / Linux (`bash` dialect):**
 
 ```jsonc
 // ❌ do NOT recommend this:
@@ -107,14 +131,46 @@ Build the allow list from the tools the project actually uses (from Step 1). A p
 "Bash(sqlite3:*)", "Bash(ffmpeg:*)", "Bash(ffprobe:*)", "Bash(open:*)"
 ```
 
+**Windows PowerShell (`pwsh` dialect):** same idea, one command family per rule, but authored with the `PowerShell(...)` tag. Cross-platform tools (git, node, package managers) keep the same executable names; native cmdlets replace the POSIX coreutils. Names are case-insensitive.
+
+```jsonc
+// ❌ do NOT recommend this:
+"PowerShell(*)",
+
+// ✅ Recommended: scope to one command family each.
+// Package managers / runtimes (same executables as POSIX):
+"PowerShell(bun:*)", "PowerShell(bunx:*)", "PowerShell(pnpm:*)",
+"PowerShell(npm:*)", "PowerShell(npx:*)", "PowerShell(node:*)",
+"PowerShell(python:*)", "PowerShell(py:*)", "PowerShell(uv:*)", "PowerShell(uvx:*)",
+// Lint / format / build / type-check / test:
+"PowerShell(biome:*)", "PowerShell(tsc:*)", "PowerShell(vitest:*)",
+"PowerShell(jest:*)", "PowerShell(eslint:*)", "PowerShell(prettier:*)",
+// Build / task runners:
+"PowerShell(dotnet:*)", "PowerShell(cargo:*)", "PowerShell(go:*)", "PowerShell(msbuild:*)",
+// Version control:
+"PowerShell(git:*)", "PowerShell(gh:*)",
+// Read-only file / text inspection (cmdlets + common aliases):
+"PowerShell(Get-Content:*)", "PowerShell(Get-ChildItem:*)", "PowerShell(Select-String:*)",
+"PowerShell(Get-Item:*)", "PowerShell(Test-Path:*)", "PowerShell(Measure-Object:*)",
+"PowerShell(Write-Output:*)", "PowerShell(Write-Host:*)", "PowerShell(Sort-Object:*)",
+"PowerShell(Where-Object:*)", "PowerShell(ForEach-Object:*)",
+// Environment / navigation:
+"PowerShell(Set-Location:*)", "PowerShell(Get-Location:*)",
+"PowerShell(Set-Item:*)", "PowerShell(Get-Command:*)",
+// Filesystem-mutating — riskier, usually `ask`/`deny`, not blanket `allow`:
+"PowerShell(New-Item:*)", "PowerShell(Copy-Item:*)", "PowerShell(Move-Item:*)",
+"PowerShell(Remove-Item:*)", "PowerShell(Rename-Item:*)"
+```
+
 Caveats to relay when proposing these:
 - These are all **fairly permissive** examples; if the user wants this you should add one rule for each command the user has in their history of commands executed.
-- The filesystem-mutating (`rm`, `mv`, `cp`, `chmod`, …) and network (`curl`, `wget`) families change state or reach outbound — prefer `ask` (or `deny` for the destructive ones) over a blanket `allow`, and confirm each with `ask_user` first.
-- You can scope tighter than a whole tool: `Bash(pnpm test:*)` allows only `pnpm test …`, `Bash(git log:*)` only `git log …`. Prefer the narrowest rule that still lets the project's real commands run.
+- The filesystem-mutating families (`rm`/`mv`/`cp`/`chmod` on POSIX; `Remove-Item`/`Move-Item`/`Copy-Item` on PowerShell) and network families (`curl`, `wget`, `Invoke-WebRequest`, `Invoke-RestMethod`) change state or reach outbound — prefer `ask` (or `deny` for the destructive ones) over a blanket `allow`, and confirm each with `ask_user` first.
+- You can scope tighter than a whole tool: `Bash(pnpm test:*)` / `PowerShell(git log:*)` allow only that sub-command. Prefer the narrowest rule that still lets the project's real commands run.
+- **A command rule keyed on a bare name can be bypassed by an absolute path**: a `deny Bash(rm:*)` does *not* block `/bin/rm`, and a `deny Bash(curl:*)` does not block `/usr/bin/curl` (same for `PowerShell(...)`). What guarantees protection against `rm -rf /` and friends is the **catastrophic floor**, not user deny rules. Treat `deny`/`ask` command rules as convenience guardrails, not airtight blocks.
 
 ---
 
-## Step 3 — Choose the target scope: project or global
+## Step 4 — Choose the target scope: project or global
 
 Ask the user with `ask_user`:
 
@@ -128,11 +184,11 @@ Map their choice to the `scope` argument (`"project"` or `"global"`) you pass to
 
 ---
 
-## Step 4 — Apply the rules with `propose_policy`
+## Step 5 — Apply the rules with `propose_policy`
 
 For each rule the user confirmed, call `propose_policy` once:
 
-- Add a rule: `op: "add-rule"`, `rule: "<rule string>"`, `effect: "allow" | "ask" | "deny"`, `scope: "<from Step 3>"`.
+- Add a rule: `op: "add-rule"`, `rule: "<rule string>"`, `effect: "allow" | "ask" | "deny"`, `scope: "<from Step 4>"`.
 - Change the mode (if needed): `op: "set-mode"`, `mode: "read-only" | "default" | "auto"`, `scope`.
 - Remove a stale rule: `op: "remove-rule"` with the same `rule` + `effect`.
 
@@ -145,13 +201,13 @@ Do them in a sensible order (deny rules first, then ask, then allow, then any mo
 
 ---
 
-## Step 5 — Optionally enable the LLM safety-check layer
+## Step 6 — Optionally enable the LLM safety-check layer
 
 Ask the user with `ask_user`:
 
 > "Do you want an **LLM safety check** on commands the agent would otherwise run? When enabled, a classifier model reviews commands and can flag/deny risky ones as an extra layer on top of your rules."
 
-This layer is configured under `permissions.llmSafetyCheck` in `config.json`. `propose_policy` does not cover this block, so **edit `config.json` directly** — the same config file they chose in Step 3 (`<repo>/.coda/config.json` for project, `~/.coda/config.json` for global) — merging the block into the existing `permissions` object. Read the file first (create it if absent), then apply the change with `edit`/`write`.
+This layer is configured under `permissions.llmSafetyCheck` in `config.json`. `propose_policy` does not cover this block, so **edit `config.json` directly** — the same config file they chose in Step 4 (`<repo>/.coda/config.json` for project, `~/.coda/config.json` for global) — merging the block into the existing `permissions` object. Read the file first (create it if absent), then apply the change with `edit`/`write`.
 
 This is a control-plane authoring write, so CODA will show a **mandatory approval prompt** describing the effect before anything is saved. Tell the user to expect and approve it; if they decline, the block is not written. If you cannot get approval (e.g. headless), fall back to giving them the JSON snippet to paste in by hand.
 
@@ -165,10 +221,7 @@ The block to add:
       // Optional: an explicit model list REPLACES the built-in default.
       // Omit this key to use the shipped default classifier models.
       // If you want to use another model, just modify the list. 
-      "models": ["openai/gpt-5.4", "openai/gpt-5.4", "anthropic/claude-sonnet-4-6", "anthropic/claude-haiku-4-5"],
-      // Optional: after this many auto-approvals in an interactive session,
-      // a one-time nudge suggests adding an explicit allow rule. Default: 10.
-      "nudgeThreshold": 10
+      "models": ["openai/gpt-5.4", "openai/gpt-5.4", "anthropic/claude-sonnet-4-6", "anthropic/claude-haiku-4-5"]
     }
   }
 }
@@ -177,12 +230,11 @@ The block to add:
 Notes to give the user:
 - It is **default-off**; an absent block leaves it inert. Set `enabled: true` to turn it on.
 - If `enabled: true` but `models` is an empty list `[]`, the check is inert (a startup warning fires). Omit `models` to use the built-in default, or list at least one model.
-- `nudgeThreshold` must be an integer ≥ 1.
-- If they picked **project** scope in Step 3, this belongs in the project config; if **global**, in `~/.coda/config.json`. Since it rides the global→project cascade, a project block overrides the global one.
+- If they picked **project** scope in Step 4, this belongs in the project config; if **global**, in `~/.coda/config.json`. Since it rides the global→project cascade, a project block overrides the global one.
 
 ---
 
-## Step 6 — Wrap up: tell the user to restart
+## Step 7 — Wrap up: tell the user to restart
 
 After applying rules and (optionally) writing the safety-check block, finish with a short summary of what was set, then clearly instruct the user:
 

package/coda

@@ -1,4 +1,4 @@
 [diffend] Oversized file quarantined before diffing.
 name: package/coda
-size: 131139904 bytes
-sha256: 8f4618224ede3bece59088a9e83f63bb369362634d71e3854493e087ca49e201
+size: 108710184 bytes
+sha256: cb9742b992c992bee91b9447b54238b8a6858709f10d0467ceb53eaa1afdd3e9

package/lib/opentui/parser.worker.js

@@ -18,22 +18,23 @@ var __toESM = (mod, isNodeMode, target) => {
       return cached;
   }
   target = mod != null ? __create(__getProtoOf(mod)) : {};
-  const to = isNodeMode || !mod || !mod.__esModule ? __defProp(target, "default", { value: mod, enumerable: true }) : target;
-  for (let key of __getOwnPropNames(mod))
-    if (!__hasOwnProp.call(to, key))
-      __defProp(to, key, {
-        get: __accessProp.bind(mod, key),
-        enumerable: true
-      });
+  const to = isNodeMode || !mod || !mod.__esModule || !__hasOwnProp.call(mod, "default") ? __defProp(target, "default", { value: mod, enumerable: true }) : target;
+  if (mod && typeof mod === "object" || typeof mod === "function") {
+    for (let key of __getOwnPropNames(mod))
+      if (!__hasOwnProp.call(to, key))
+        __defProp(to, key, {
+          get: __accessProp.bind(mod, key),
+          enumerable: true
+        });
+  }
   if (canCache)
     cache.set(mod, to);
   return to;
 };
 var __commonJS = (cb, mod) => () => (mod || cb((mod = { exports: {} }).exports, mod), mod.exports);
-var __require = import.meta.require;
 
 // ../../node_modules/.pnpm/web-tree-sitter@0.25.10/node_modules/web-tree-sitter/tree-sitter.wasm
-var require_tree_sitter = __commonJS((exports, module2) => {
+var require_tree_sitter = __commonJS(function(exports, module2) {
   module2.exports = Bun.fileURLToPath(new URL("./tree-sitter-3jzf13jk.wasm", import.meta.url));
 });
 
@@ -1576,7 +1577,7 @@ var Module2 = (() => {
           throw new Error(response.status + " : " + response.url);
         }, "readAsync");
       }
-    } else {}
+    }
     var out = Module["print"] || console.log.bind(console);
     var err = Module["printErr"] || console.error.bind(console);
     Object.assign(Module, moduleOverrides);
@@ -3362,8 +3363,8 @@ class DownloadUtils {
     return "";
   }
 }
-function isBunfsPath(path22) {
-  return path22.includes("$bunfs") || /^B:[\\/]~BUN/i.test(path22);
+function isBunfsPath(path2) {
+  return path2.includes("$bunfs") || /^B:[\\/]~BUN/i.test(path2);
 }
 function getBunfsRootPath() {
   return process.platform === "win32" ? "B:\\~BUN\\root" : "/$bunfs/root";
@@ -3463,8 +3464,8 @@ var stripANSI = bun?.stripANSI ?? stripAnsi;
 var writeFile2 = bun?.write ?? writeFilePortable;
 async function resolveBundledFilePath(loadBundledFile, fallbackPath, metaUrl) {
   if (!bun) {
-    const path22 = typeof fallbackPath === "function" ? fallbackPath() : fallbackPath;
-    return fileURLToPath(path22 instanceof URL ? path22 : new URL(path22, metaUrl));
+    const path2 = typeof fallbackPath === "function" ? fallbackPath() : fallbackPath;
+    return fileURLToPath(path2 instanceof URL ? path2 : new URL(path2, metaUrl));
   }
   const loadedPath = (await loadBundledFile()).default;
   if (loadedPath.startsWith("file:")) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@globant/coda-linux-arm64",
-  "version": "1.4.0",
+  "version": "1.5.0",
   "description": "Coda CLI native binary (linux-arm64)",
   "os": [
     "linux"