v0.5.8 — config.json / secrets.json moved out of the package

0.5.8 — machine settings moved out of the package

The problem. config.json and secrets.json were read from the package root (join(ROOT, 'config.json') in bin/guard.mjs and in the DSH adapter), and neither is in the published files allowlist. npm i / dsh plugin update replaces the whole package directory — so the documented setup ("create secrets.json in the package root") had to be redone after every update. The audit log, allow-list tokens and degraded state were already outside the package; the two files holding what a human typed were the ones left behind.

What changed. Resolution lives in one module, lib/paths.js, and both the CLI and the adapter call it, so a relative apiKeyFile can never be written through one path and read through another.

Precedence: explicit JEV_GUARD_CONFIG / JEV_GUARD_SECRETS → the file in JEV_GUARD_HOME (default ~/.jev-guard/config.json / secrets.json) → the old package-root location. The last step is deliberate: checkouts, link: installs and not-yet-migrated machines keep working unchanged. apiKeyFile keeps its documented meaning (a relative path resolves against the package root, independently of cwd).

Verified. guard selftest 12/12; the seven offline suites 30 / 113 / 54 / 17 / 83 / 20 / 34 assertions, all passing; DSH adapter smoke test 24/24; doc-pair check exit 0. Precedence exercised against a temporary JEV_GUARD_HOME in four cases: package-root file when no user file exists, user file wins once present, JEV_GUARD_CONFIG overrides both, relative apiKeyFile still resolves to <package root>/mine/secrets.json.

The pipeline smoke test was not run — it imports @deepseek-ai/cordis, which this deliberately zero-dependency checkout does not have (unchanged limitation, also recorded in the 0.2.1-rc.2 round).

Docs (START-HERE, DEPLOY, README, SECURITY, docs/DSH-INTEGRATION, cordis.patch.yml, config.example.json and both no-key hint strings, zh-CN pairs included) now say where the files belong and why they are outside the package.

v0.5.6 - PowerShell's destructive surface in L0

PowerShell's destructive surface is in the L0 rules now — on the day this profile's executor flipped from bash to pwsh.

L0 is the floor that survives a degraded or timed-out semantic layer. With the live model given 1800 ms before it fails open, forms like Remove-Item -Recurse C:\, bcdedit /delete, iex, powershell -EncodedCommand, reg delete, net user … /delete and takeown /f C:\ were relying on the online verdict alone. They are offline rules now: DENY 21 → 26, ASK 16 → 24. The reasoning is D19 in docs/DECISIONS.md.

Why now

On 2026-10-17 this profile's executor moved from bash to pwsh (Git Bash's MSYS2 runtime cannot start under the sandbox's WRITE_RESTRICTED token). The plugin's tool list already carried both (DEFAULT_TOOLS = ['bash', 'pwsh']), so nothing was left unguarded — but the L0 rules were written in bash syntax, and the semantic layer fails open after 1800 ms. Measured on this host: 8 of the day's judgments were source: error, every one a timeout — commands that ran with no model decision behind them. After the restart the audit log also carries the first "tool": "pwsh" records.

What changed

• New DENY rules (5): recursive delete aimed at a drive root (Remove-Item -Recurse C:\, plus ri / rm / del / rd aliases with -Recurse / /s), at C:\Windows ($env:SystemRoot, %SystemRoot%), or at a profile root ($env:USERPROFILE, $HOME, C:\Users\<name>, ~); format C:; bcdedit /set|/delete|/create|/import; Disable-ComputerRestore.
• The old drive-root rule was rewritten, because it was wrong in the other direction. Remove-Item -Recurse C:\Users\me\build was denied: the pattern tested "any drive-letter path" rather than a root. It now tests the target for a root with a token boundary, and finds -Recurse / /s by lookahead, so -Path C:\ -Recurse is covered too.
• New ASK rules (8): iex / Invoke-Expression; powershell -EncodedCommand; Clear-Content; reg delete; Remove-Item against HKLM: / HKCU: / HKCR:; net user|localgroup … /delete; takeown /f <drive> and icacls <drive> /reset; Clear-RecycleBin.
• Shell-wrapper recognition covers the PowerShell forms. SHELL_C now matches pwsh -NoProfile -Command "…" and cmd's /c, so a destructive command inside either is still seen at its own command position. where: 'anywhere' remains exactly two rules, and the suite asserts that structural invariant.
• Tests: selftest-rules grew from 48 to 83 cases (24 new real-string cases, 10 cases that must not fire); selftest-i18n now covers all 50 L0 rules; docs and the decision record are updated, including D19.

Acceptance

Windows, Node 24.12.0, DSH 0.2.1-rc.2 desktop host: guard selftest 12/12; seven offline suites 30 / 34 / 113 / 54 / 17 / 83 / 20 assertions, all passing; DSH adapter smoke 23/23 without a key. The real tool-pipeline integration test is not run here: it resolves @deepseek-ai/cordis from its own location and this checkout is deliberately zero-dependency.

Install

npm install -g dsh-jev-guard@0.5.6