trackfw 9.2.0 → 9.3.1

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.
Files changed (2) hide show
  1. package/README.md +84 -34
  2. package/package.json +7 -7
package/README.md CHANGED
@@ -19,12 +19,12 @@ ADR → REQ → ROADMAP → backlog / wip / blocked / done / abandoned
19
19
  Every piece of work traces back to a decision. Every decision links to a requirement. Every requirement lands in a roadmap. No orphan work, no undocumented choices.
20
20
 
21
21
  > 🚧 **Platform support: Linux and macOS are supported. Windows support is partial.**
22
- > The CLIs install on Windows and core governance commands run — but the generated
23
- > guard hooks are POSIX shell scripts, and **on several agent CLIs they do not execute
24
- > on Windows.** They are written to disk and reported as installed while never running.
25
- > Native Windows hooks are planned, not yet in progress (tracked in
26
- > [REQ-2026-09-05](docs/req/REQ-2026-09-05-os-hooks-de-guard-nao-executam-no-windows-na-maioria-dos-clis-de-agente-e-o-validate-reporta-instalado.md)).
27
- > **Read [Windows support (partial)](#windows-support-partial) before adopting on Windows.**
22
+ > The CLIs install on Windows and core governance commands run. Since v9.3.0, guard
23
+ > hooks call `trackfw guard <name>` (the Go binary) instead of a POSIX shell script —
24
+ > measured blocking and allowing correctly in PowerShell 5, cmd.exe, and Git Bash on
25
+ > Windows; Claude Code and Codex CLI proven end-to-end. Windows CI still reports known
26
+ > test failures. There are limits worth knowing; **read
27
+ > [Windows support (partial)](#windows-support-partial) before adopting on Windows.**
28
28
 
29
29
  ---
30
30
 
@@ -112,14 +112,17 @@ declaration.
112
112
 
113
113
  Shared behavior follows the [command contract](docs/cli-parity.md).
114
114
 
115
- > **The CLI installs on Node ≥ 18 alone — the generated guard hooks do not run on
116
- > Node alone.** They are POSIX shell scripts and need a POSIX shell to execute. On
117
- > Windows, see [Windows support](#windows-support-partial) before relying on them.
115
+ > **The npm package delivers the same Go binary, and the guard hooks run it from `PATH`.**
116
+ > Since v9.3.0, hooks call `trackfw guard <name>` directly; no POSIX shell is needed. On
117
+ > Windows, the npm shim is a `.ps1` that PowerShell's `ExecutionPolicy Restricted` blocks —
118
+ > see [Windows support](#windows-support-partial) before relying on the hooks.
118
119
 
119
120
  ### Windows support (partial)
120
121
 
121
- 🚧 **Windows support is partial. Native Windows hooks are planned but not yet being
122
- worked on. Read this before adopting `trackfw` on Windows.**
122
+ 🚧 **Windows support is partial. Read this before adopting `trackfw` on Windows.**
123
+
124
+ Since v9.3.0, guard hooks call `trackfw guard <name>` (the Go binary) and run on
125
+ Windows. Windows CI still reports known test failures mapped by root cause.
123
126
 
124
127
  We publish a Windows binary and the npm/pip packages install on Windows. That is not
125
128
  the same as the tool working end to end, and we would rather tell you where the edges
@@ -138,32 +141,79 @@ are than let you find them after adoption.
138
141
 
139
142
  - Our Windows CI still reports **known test failures**. They are mapped by root cause,
140
143
  not unknown — but they are not zero.
141
- **Guard hooks on Windows — measured, per agent CLI**
144
+ **Guard hooks on Windows — measured state (since v9.3.0)**
145
+
146
+ Since v9.3.0, guard hooks call `trackfw guard <name>` (the Go binary) instead of a
147
+ `.sh` script. The same binary runs in every shell; for a given agent CLI, the hook
148
+ line in the committed config is the same string across PowerShell, cmd.exe, and Git
149
+ Bash — a team with mixed OS can commit one config and have it work on all machines.
142
150
 
143
- The guard hooks are `.sh` scripts, executed by *your* AI agent CLI. Which shell that CLI
144
- uses on Windows decides whether they run at all. We measured it:
151
+ The hook line emitted depends on the shell the agent CLI uses on Windows — a fact of
152
+ the vendor, not of the OS:
145
153
 
146
- | Agent CLI | Shell on Windows | Do the hooks run? | Basis |
154
+ | Agent CLI | Shell on Windows | Hook line emitted | Basis |
147
155
  |---|---|---|---|
148
- | Gemini CLI | PowerShell, always | ❌ **No** | measured in vendor source |
149
- | Codex CLI | PowerShell on the normal path | ❌ **No** | measured in vendor source |
150
- | GitHub Copilot CLI | — | ❌ **No** — we populate the wrong config field | vendor docs + our code |
151
- | Claude Code | Git Bash if installed, else PowerShell | ⚠️ **Only with Git Bash** | vendor documentation |
152
- | Cursor · Kiro | unknown | ❓ **Unknown** | closed, undocumented |
153
-
154
- 🔴 **This is the failure mode we care most about, because it is silent.** A guard that
155
- never executes still reports health over something it never inspected. On the CLIs marked
156
- ❌, `trackfw validate` will tell you the hook is installed — and it will never fire.
157
-
158
- **Until native Windows hooks ship, do not rely on `credential_guard` or
159
- `git_branch_guard` as an enforced control on Windows.** Treat them as documentation of
160
- intent, not as enforcement.
161
-
162
- We are **not** going to answer this by requiring Git Bash: it would fix one CLI out of
163
- six and push the cost onto you. Windows hooks should run on Windows. Native hook
164
- generation is the direction — see
165
- [`docs/portabilidade/2026-09-05-contrato-de-execucao-de-hook-por-cli-de-agente-no-windows.md`](docs/portabilidade/2026-09-05-contrato-de-execucao-de-hook-por-cli-de-agente-no-windows.md)
166
- for the full measurement, per CLI, with the level of certainty of each row.
156
+ | Claude Code | Git Bash (if installed), else PowerShell | `trackfw guard <name>; exit $LASTEXITCODE` | vendor docs (2026-10-04) |
157
+ | Codex CLI | PowerShell | `trackfw guard <name>; exit $LASTEXITCODE` | vendor source (2026-10-04) |
158
+ | Gemini CLI | PowerShell | `trackfw guard <name>; exit $LASTEXITCODE` | vendor source (2026-10-04) |
159
+ | Cursor | PowerShell | `trackfw guard <name>; exit $LASTEXITCODE` | vendor bundle (2026-09-06) |
160
+ | Windsurf | PowerShell | `trackfw guard <name>; exit $LASTEXITCODE` | vendor docs (2026-10-04) |
161
+ | GitHub Copilot | PowerShell / cross-platform `command` field | `trackfw guard <name>; exit $LASTEXITCODE` | vendor docs (2026-10-04) |
162
+ | Kiro | cmd.exe | `trackfw guard <name>` | vendor docs (2026-10-04) |
163
+ | Amazon Q | cmd.exe | `trackfw guard <name>` | vendor source (2026-10-04) |
164
+
165
+ The `; exit $LASTEXITCODE` suffix is required for PowerShell 5: without it, PowerShell
166
+ converts exit 2 (deny) from the child process into exit 1, and 6 of 8 CLIs treat exit 1
167
+ as a non-blocking error. cmd.exe and bash propagate the exit code directly; they do not
168
+ need the suffix.
169
+
170
+ **What was measured in the VM (Windows 11 ARM64, 2026-10-06):** PowerShell 5, cmd.exe,
171
+ and Git Bash (non-login, explicit PATH to the branch binary) all block
172
+ `git push origin main` (exit 2) and allow `ls` (exit 0) correctly. `pwsh` (PowerShell 7)
173
+ was not installed on the VM — not measured. Subsequent testing with real agent CLIs on the
174
+ same VM proved end-to-end blocking and allowing for two CLIs; the remaining CLIs have the
175
+ hook line verified in each shell but were not run agent-to-end:
176
+
177
+ | Agent CLI | End-to-end proven on Windows | Evidence |
178
+ |---|---|---|
179
+ | Claude Code | ✅ real agent — `git push` blocked by guard, `git status` allowed | Claude Code 2.1.292, 2026-10-07 (ML-5B) |
180
+ | Codex CLI | ✅ real agent — `git push` blocked ("Blocked by hook" + guard REASON), `git status` allowed | Codex CLI 0.160.1, KG interactive session, 2026-10-07 (ML-5C) |
181
+ | Cursor | Hook line measured in shell; agent not run end-to-end | — |
182
+ | Windsurf | Hook line measured in shell; agent not run end-to-end | — |
183
+ | Gemini CLI | Hook line measured in shell; agent not run end-to-end | — |
184
+ | Kiro | Hook line measured in `cmd.exe`; agent not measured (no Windows ARM64 CLI; the IDE needs an AWS Builder ID account) | — |
185
+ | GitHub Copilot | Not verified (no account) | — |
186
+ | Amazon Q | Not verified (no account) | — |
187
+
188
+ **Claude Code on Windows uses the PowerShell shell tool**, not Bash. The hook emitted by
189
+ trackfw carries `matcher: "Bash|PowerShell"` so it fires on both macOS/Linux (where Claude
190
+ Code names the tool `Bash`) and Windows (where it names it `PowerShell`). Run
191
+ `trackfw update` to migrate existing configs that carry only `"Bash"` — it also handles the
192
+ `.sh`-to-binary-hook migration.
193
+
194
+ **Caveat — old trackfw binary in Git Bash's PATH:** Claude Code runs the hook command
195
+ through Git Bash (login shell), whose login profile puts `~/bin` at the front of `PATH`.
196
+ If an older trackfw binary (without the `guard` subcommand) lives in `~/bin`, the hook
197
+ exits 1 ("unknown command") and fails open on most CLIs — remove or update that binary.
198
+ Since v9.3.0, `trackfw validate` reports this condition.
199
+
200
+ **The guard requires a `trackfw` binary with the `guard` subcommand in the PATH of the
201
+ agent CLI's process.** `trackfw validate` now reports three new conditions:
202
+
203
+ - **Old binary in PATH** (no `guard` subcommand — exits 1 with "unknown command"):
204
+ fail-open on 6 of 8 CLIs. Claude Code, Codex, Gemini, Cursor, Windsurf, and Amazon Q
205
+ treat exit 2 as the only blocking exit — exit 1 passes through. Kiro and Copilot
206
+ block any non-zero exit, so they block for the wrong reason (deny-all until updated).
207
+ `trackfw validate` reports a violation when the binary in PATH does not support
208
+ `guard`. **Caveat:** if Git Bash resolves a different binary (e.g. one installed in
209
+ `~/bin` that is absent from the Windows PATH), the probe does not see it — that
210
+ binary's version is not checked.
211
+ - **npm channel under `ExecutionPolicy Restricted`**: the `.ps1` shim is blocked by
212
+ PowerShell; validate reports a violation and recommends
213
+ `Set-ExecutionPolicy -Scope CurrentUser RemoteSigned`.
214
+ - **`trackfw.exe`, `trackfw.cmd`, or `trackfw.bat` in the project root**: cmd.exe (used
215
+ by Kiro and Amazon Q) searches the current directory before PATH — validate reports a
216
+ violation for each file found.
167
217
 
168
218
  **If you are on Windows**, we want your report. The Windows defects fixed so far came
169
219
  from a user running the tool on real Windows 11 and measuring before reporting — open
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "trackfw",
3
- "version": "9.2.0",
3
+ "version": "9.3.1",
4
4
  "description": "Governance CLI for AI-native software delivery and AI coding agents. Enforces traceability: ADR → REQ → ROADMAP → kanban. Native support for Codex, Claude Code, Gemini CLI, Cursor, Copilot, Windsurf, Amazon Q, OpenCode, and Kiro.",
5
5
  "keywords": [
6
6
  "cli",
@@ -63,11 +63,11 @@
63
63
  "node": ">=18"
64
64
  },
65
65
  "optionalDependencies": {
66
- "@trackfw-bin/darwin-arm64": "9.2.0",
67
- "@trackfw-bin/darwin-x64": "9.2.0",
68
- "@trackfw-bin/linux-arm64": "9.2.0",
69
- "@trackfw-bin/linux-x64": "9.2.0",
70
- "@trackfw-bin/win32-arm64": "9.2.0",
71
- "@trackfw-bin/win32-x64": "9.2.0"
66
+ "@trackfw-bin/darwin-arm64": "9.3.1",
67
+ "@trackfw-bin/darwin-x64": "9.3.1",
68
+ "@trackfw-bin/linux-arm64": "9.3.1",
69
+ "@trackfw-bin/linux-x64": "9.3.1",
70
+ "@trackfw-bin/win32-arm64": "9.3.1",
71
+ "@trackfw-bin/win32-x64": "9.3.1"
72
72
  }
73
73
  }