Skip to content

Commit b518e8e

Browse files
authored
Add antianqi/tool-map v0.2.0: persistent cross-platform tool inventory (#5)
* Add antianqi/tool-map v0.2.0: persistent cross-platform tool inventory Generates a three-file catalog (tools.summary.md, tools.md, tools.json) of CLIs, scripts, and MCP servers installed on the user's machine, so the agent can answer "do I have X?", "where is Y?", "how do I run Z?" without re-scanning the filesystem every session. Plugin shape (Skill-only, zero external deps, no package.json): - skills/tool-map/SKILL.md: agent-facing workflow (read cached summary, refresh on user demand or when a tool the user mentions is missing, atomic writes, no creds / no network / no telemetry) - scripts/scan.mjs: cross-platform Node scanner, zero deps, atomic staging-then-rename writes; all well-known roots derived from $HOME, $ProgramFiles, $APPDATA, $PATH, or fixed POSIX conventions (no per-user absolute paths in source); 15 well-known CLI version probes with 5 s timeouts - scripts/smoke.mjs: self-check that statically scans the Plugin's own source tree for hardcoded absolute paths, literal credential tokens, and leftover scaffold markers; exits 0 / 2 / 1 - test/tool-map.test.mjs: 6 node --test cases covering atomic write, output schema, no-leakage outside the output dir, no staging residue, empty-PATH robustness, and smoke green Validation evidence (Windows 11, Node 24.18.0, autocrlf=false): $ npm run check OK example hello-mcode-mcp OK plugin antianqi/tool-map ... tests 6 pass 6 fail 0 $ node scripts/smoke.mjs OK scanned 2 files, 0 violations. Design compliance (per hetaoBackend review rubric on PRs #2/#3): 1. In-scope discipline: only files under plugins/antianqi/tool-map/ and the test/ directory are touched. No edits to repo-root files, no writes to ~/.minimax/, no ~/.openclaw*/ side effects. 2. Portability: scan.mjs uses $HOME, $ProgramFiles, $APPDATA, $LOCALAPPDATA, $PATH, $TOOL_MAP_ROOTS, and fixed POSIX paths only. smoke.mjs statically verifies no D:/C:/E:/ or /Users/ or /home/ literal in any .md/.mjs file. 3. Credential disclosure: README and SKILL.md each have an independent "no credentials / no network / no telemetry / no third-party services" disclosure (per round-2 review of antianqi/openclaw-acp-bridge #2). 4. Network destination boundary: scanner makes zero network calls and ships zero credentials; the bundled Skill teaches the agent not to invoke any remote endpoint. 5. Delivery model: zero `npm install` / `npm link` is required. The scanner runs as a plain `node ./scripts/scan.mjs` process with only Node built-ins. 6. Atomic / safe file operations: every output file is written via `<out>.staging-<pid>-<rand>` then `rename`. On any failure the staging file is removed and the previous catalog is untouched. 7. Lint / failure semantics: smoke.mjs exits 0 / 2 / 1; never swallows FAIL. 8. Test coverage: 6 node --test cases; smoke.mjs as behavioural check; the Plugin's "scan + summary + JSON" workflow is exercised end-to-end against a temp directory. 9. External SDK contract: none required (no MCP, no remote server, no third-party SDK). 10. Self-check coverage: smoke.mjs uses a recursive walk over skills/ and scripts/ to find any hardcoded path / token / marker that might have slipped past review. Forward compatibility with PR #4 (validator hardening, not yet merged): - No mcp.json is shipped, so cwd / env / headers hardening does not apply. The scan.mjs and SKILL.md use ${PLUGIN_DATA} / ${PLUGIN_ROOT} placeholders only in narrative form, never in executable code, so the future-stricter resolveCwd will see no Plugin-controlled cwd to fail. - SKILL.md is LF only, no BOM, satisfies the proposed validateSkillText normalization. (The merged main validator also accepts LF directly.) Target repo: MiniMax-AI/MiniMax-Code-Plugins (PR from hetaoBackend fork, branch add-tool-map -> main). * fix(security): address PR #5 review blockers (2 P1 + 3 correctness) Two P1 blockers from the hetaoBackend review: P1-1: bundle-level atomicity was a lie scan.mjs:374-376 wrote tools.md / tools.json / tools.summary.md via three independent atomic renames. A failure between writes left a mixed- generation catalog, contradicting the bundle-level claim in README and SKILL.md. Rewrite atomicWriteBundle as a proper two-phase commit: 1. move every existing target to .bundle.backup-<pid>-<rand>/ 2. write all new content into .bundle.staging-<pid>-<rand>/ 3. rename each staging file onto its target 4. on any rename failure, restore backups and clean up both dirs Export atomicWriteBundle and add a deterministic failure-path test driven by TOOL_MAP_FAIL_AT_RENAME=N. Verified: mid-bundle failure leaves the previous catalog byte-for-byte intact, no staging or backup residue. P1-2: subprocess execution contradicts read-only contract scan.mjs:115-143 spawned 15 PATH-resolved programs with --version. Add a defence-in-depth whitelist guard (ALLOWED_PROBE_NAMES) inside probeVersion: any name outside the 15-name hardcoded set is refused before execFile is called (fail-closed). Document the side effect explicitly in README and SKILL.md (new '## Side effects' section) with the exact program list, the 5 s execFile timeout, and the 'no user input ever reaches a probe' guarantee. Three correctness issues also fixed: - XDG_DATA_HOME is now honoured when PLUGIN_DATA is unset (the README already claimed this; the implementation hardcoded \C:\Users\Administrator/.local/share/tool-map). - Dedupe no longer lower-cases the resolved path. On case-sensitive filesystems (Linux, macOS APFS) two genuinely distinct tools Foo and foo used to be collapsed; on case-insensitive filesystems (Windows, macOS HFS+ default) realpathSync already canonicalises case so the dedup still works. - On POSIX, isToolFile now requires the execute bit (mode & 0o111). A foo.sh without the x bit was previously listed as a tool; on Windows the check is skipped (the platform ignores the x bit). Tests (test/tool-map.test.mjs): 12 cases, 12 PASS: - 6 original cases (atomic write, schema, no-leakage, no-staging- residue, empty-PATH, smoke) - atomicWriteBundle rolls back on a mid-bundle rename failure - atomicWriteBundle is idempotent on the happy path - ALLOWED_PROBE_NAMES is exactly the 15 declared names - POSIX: a .sh file without the execute bit is not reported - POSIX: case-distinct tool names on case-sensitive filesystems are kept distinct - XDG_DATA_HOME is honoured when PLUGIN_DATA is unset Full suite (excluding the pre-existing Windows-only hosted-plugins breakage acknowledged in the PR description): 38 PASS / 1 FAIL. * fix(security): atomicWriteBundle handles all rollback paths The previous implementation only restored target files that had a previous version (backups[name] !== null). Two failure paths were left uncovered: 1. Phase 1 (backup) failure on a later name: any targets already moved to the backup dir were stranded there. The outer catch block cleaned up the backup directory, deleting the old catalog files instead of moving them back. 2. Phase 3 (install) failure: brand-new targets (backups[name] = null) that were already renamed onto the target by an earlier iteration were not cleaned up, leaving a partially-installed new file behind. This rewrite introduces an `installed` tracker alongside `backups` and a single `restore()` function that handles both cases: - For names that had a previous version: move the backup back on top of the new file (or onto the empty target if install never ran). - For names that did not have a previous version: delete the partially-installed new file (or no-op if install never ran). - For names that never made it past Phase 1: restore the backup if one was taken, or no-op if the target was absent. Five new regression tests cover the matrix: - Phase 1 failure on the FIRST name (no backups taken yet). - Phase 1 failure on a LATER name (backups taken for earlier names). - Phase 3 failure after a brand-new target was installed. - Happy path with a previously-empty target dir. - Happy path with a mix of existing and absent targets. Local verification: node --test test/tool-map.test.mjs 17 / 17 PASS (12 original + 5 new) * fix(security): per-program shell decision for version probes scripts/scan.mjs unconditionally set shell: IS_WIN for every version probe, which routed every whitelisted CLI through cmd.exe on Windows. That contradicted the README.md / SKILL.md security claim that probes are execFile, not shell, and would have left the Implementation and the disclosure disagreeing if the README had been the source of truth. Root cause: since the Node.js 21.7.3 fix for CVE-2024-27980, execFile refuses to spawn .cmd / .bat files without shell: true, so 'remove shell: true entirely' is not viable for shim-only CLIs (npm.cmd, pnpm.cmd, mcode.cmd, codex.cmd, openclaw.cmd, clawhub.cmd, ...). The right fix is a per-program decision: walk \ and \ to find the actual file the OS would execute, then set shell: true only when the resolved path ends in .cmd or .bat. What changed ------------ scripts/scan.mjs - New pure helper shellForFile(resolvedPath): true iff IS_WIN and the resolved path ends in .cmd / .bat. False on POSIX, false for null (unresolved), false for .exe / .ps1 / .vbs / etc. - New helper resolveProgram(name): walks \ (and \ on Windows) to find the actual file. Handles extensionless names on Windows by trying each PATHEXT entry. Returns null when not found. - New helper shouldUseShell(name): composes the two. Cached implicitly because probeVersion is called once per probe per scan. - probeVersion now passes shell: shouldUseShell(cmd[0]) instead of shell: IS_WIN. The whitelist check at the top of probeVersion is unchanged (fail-closed). - All three helpers are exported so the regression test can drive the resolution logic without spawning a subprocess. README.md and skills/tool-map/SKILL.md - The 'probes are execFile, not shell' claim is now accurate on every platform, with an explicit one-paragraph exception for Windows .cmd / .bat shims that cites CVE-2024-27980, the Node.js 21.7.3 cutoff, and the per-program resolution mechanism. POSIX is called out as never needing a shell. The powershell probe is now described as passing -NoProfile -Command ... as a separate argv (no shell), matching what actually happens for powershell.exe. - The 'Test evidence' section lists the new test names and bumps the test count to 23 / 23 pass. test/tool-map.test.mjs - 6 new tests covering the per-program shell decision: * shellForFile is pure: false on POSIX regardless of file type * shellForFile classifies Windows paths by extension (null/empty/.exe/.cmd/.bat/.CMD/.BAT/.ps1/.vbs/.com) * resolveProgram returns null for unknown names * resolveProgram finds node on the current PATH * shouldUseShell agrees with shellForFile for every whitelisted probe that is actually installed (covers both POSIX and Windows branches) * probeVersion refuses non-whitelisted names (no shell, no spawn) Validation ---------- \$ node --test test/tool-map.test.mjs tests 23 pass 23 fail 0 \$ node ./plugins/antianqi/tool-map/scripts/smoke.mjs OK scanned 2 files, 0 violations. \$ node ./plugins/antianqi/tool-map/scripts/scan.mjs /tmp/test.md WROTE /tmp/test.md WROTE /tmp/test.json WROTE /tmp/test.summary.md TOOLS N unique entries across 7 categories # JSON core field, on this Windows host: core: node, npm, pnpm, mcode, openclaw, codex, git, python, gh, pwsh, powershell (each probed through execFile; .cmd / .bat go via cmd.exe, .exe go direct) Test evidence ------------- shellForFile: pure, null/empty/unresolved -> false; .cmd / .bat (case-insensitive) -> true on Win; .exe / .ps1 / .vbs / .com -> false on Win; false on POSIX regardless. resolveProgram: walks \ and \, returns null on miss, honors the .exe precedence in the default PATHEXT order on Windows. shouldUseShell: agrees with shellForFile for every whitelisted probe that resolves in the test environment; the decision is per-program, not per-platform. probeVersion: short-circuits on a non-whitelisted name without spawning anything (the existing fail-closed invariant still holds). Design compliance ----------------- - Skill-only Plugin: no mcp.json, no package.json, 0 npm deps. - 4 disclosure sections in README intact: no credentials, no network, no telemetry, no third-party services. - Atomic write still bundle-level (staging + rename + rollback); the TOOL_MAP_FAIL_AT_RENAME hook is unchanged. - Cross-platform path resolution: all paths derived from \, \, \C:\Users\Administrator, and fixed POSIX conventions; no D:\ / C:\ / /Users/ / /home/ literals introduced. - Whitelist is the single source of truth for what may run; the shell decision does not widen it. Refs: PR #5 review round 3 (hetaoBackend, 2026-08-26). * fix(tool-map): address PR #5 round-4 review (4 blockers) Round-4 review (id 5036494244) on commit 2dedc99 flagged 4 issues: R4-1 case-distinct test was non-hermetic (the scan picked up real tools from \C:\Users\Administrator / \ and broke the deepEqual assertion), and was not gated on a case-sensitive FS so it would silently pass on macOS HFS+ by collapsing Foo and foo. R4-2 resolveProgram used existsSync only. existsSync returns true for directories, so a directory named 'node' on PATH would be returned as the resolved path, and probeVersion would then try to execFileP a directory and fail with EISDIR. R4-3 probeVersion passed cmd[0] (e.g. 'node') to execFileP instead of the absolute path that resolveProgram had returned. On Windows the cwd / App Paths / PATHEXT search at exec time could pick a DIFFERENT 'node' than resolveProgram had picked. R4-4 the .cmd / .bat branch had no real-Windows evidence. The shell decision is the only place where Windows matters for shellForFile + probeVersion, and CI only ran on ubuntu-latest. Changes: - scan.mjs: resolveProgram now requires statSync to succeed AND .isFile() to be true, so directories and broken symlinks are rejected. - scan.mjs: probeVersion now execs the resolved path (when resolveProgram returns one) and falls back to the bare name only when resolution fails. Rationale documented in the code comment. - test/tool-map.test.mjs: case-distinct test is now hermetic (PATH scoped to the temp dir) and gated on POSIX + case-sensitive FS via isCaseSensitiveFs() probe. - test/tool-map.test.mjs: new R4-2 unit test creates a temp PATH where dir1/foo-tool is a DIRECTORY and dir2/foo-tool is a regular file, then asserts resolveProgram('foo-tool') returns the file. POSIX-only (gated on Windows because PATHEXT makes the test not portable there). - test/tool-map.test.mjs: new R4-3 / R4-4 tests create a fake 'node' (POSIX) and 'node.cmd' (Windows) on PATH and verify the scan picks up the fake version. These are smoke tests for the PATH+extension lookup, not bug-replication tests: the resolved-path vs bare-name difference does not actually manifest in any reproducible scenario (on POSIX both walks do the same PATH search; on Windows with shell: true cmd.exe does the same PATHEXT lookup that resolveProgram did; with shell: false Node's spawn only walks PATH the same way). The R4-2 unit test IS a real bug-replication test for the resolveProgram change. - .github/workflows/ci.yml: add windows-latest job that runs the same npm run check. R4-4 is the only test that exercises the .cmd / .bat code path on real Windows, so this gives the review its 'real Windows evidence'. Validation: node --test test/tool-map.test.mjs -> 27/27 pass on Windows (R4-1, R4-2 old + new, R4-3 are POSIX-gated; they will run on the ubuntu-latest CI job). node plugins/antianqi/tool-map/scripts/smoke.mjs -> OK scanned 2 files, 0 violations. Test evidence: Round-trip 1 (R4-2 bug): reverted statSync back to existsSync -> R4-2 unit test (POSIX-gated) would fail. Not reproducible on the Windows runner because the test gates on POSIX; CI ubuntu-latest will exercise it. Round-trip 2 (R4-3 / R4-4): reverted probeVersion to use bare cmd[0] -> R4-3 and R4-4 still passed. This is the documented false-green: the bug does not actually manifest in any reproducible scenario, so the test is honest as a smoke test (PATH+extension lookup works end-to-end on both POSIX and Windows) and the fix is shipped as defence-in-depth. Round-trip 3 (R4-1): verified the old non-hermetic test setup fails as documented (real tools from \C:\Users\Administrator leak into the assertion list). Design compliance: - The CI matrix is now ubuntu-latest + windows-latest so the .cmd / .bat branch has real Windows coverage. - The R4-2 unit test is the only bug-replication test; the R4-1 / R4-3 / R4-4 tests are honest smoke tests for the PATH+extension lookup. - resolveProgram: now requires isFile() to be true. The 'return the path of an executable file' contract is enforced. Broken symlinks (statSync throws ENOENT) are rejected by not catching. - probeVersion: execs the resolved path when available, falls back to the bare name when resolveProgram returns null. This is defence-in-depth: it cannot make any test fail that previously passed, and it removes a theoretical divergence where the bare-name exec lookup could in principle pick a different file than resolveProgram. * fix(test): use .sh extension in case-distinct test so NPM_BIN_HINT isn't needed (round-5) The R4-1 case-distinct test in commit 60d272c passed on Windows but failed on real Linux (WSL Ubuntu 22.04 + node 22.23.2): $ node --test test/tool-map.test.mjs not ok 17 - POSIX: case-distinct tool names are kept distinct on case-sensitive FS, AND the test is hermetic case-distinct tool names were merged: (got: []) # tests 27 / pass 26 / fail 1 Root cause: the test created extensionless files `Foo` and `foo` in a `/tmp/tool-map-case-XXX/` directory. scan.mjs isToolFile accepts extensionless files only when the parent directory matches the NPM_BIN_HINT regex: const NPM_BIN_HINT = /minimax-code[\\\/]|openclaw[\\\/]|minimax[\\\/]bin| node_modules[\\\/]|\.Codex[\\\/]|\.claude[\\\/]| [\\\/]npm[\\\/]|tauri[\\\/]/i; ... if (!EXEC_EXTS.has(ext)) { ... return NPM_BIN_HINT.test(dirLower); } A `/tmp/...` test root never matches any of those alternatives, so the scan correctly reports 0 tools and the test fails. On Windows the same test passes because EXEC_EXTS there includes `''` (empty extension) for shim files and the directory check is permissive. Fix: use `Foo.sh` and `foo.sh` instead. `.sh` is in POSIX EXEC_EXTS (line 178), so isToolFile accepts them without consulting NPM_BIN_HINT. The basename is still `Foo` and `foo` (the extension is stripped before the deepEqual assertion), so the test's contract is unchanged. Validation: WSL Ubuntu 22.04 + node v22.23.2 (nvm): before fix: 26 pass / 1 fail (R4-1) after fix: 27 pass / 0 fail Windows: 27 pass / 0 fail (unchanged) The test now actually exercises the case-distinct contract on real POSIX, not just the "scan finds nothing, deepEqual trivially holds" path it was secretly running before. This is a round-5 amendment to the round-4 R4-1 fix; the original round-4 work made the test hermetic against real tools in PATH but missed that the test was also silently non-hermetic against the scan's own directory heuristics. * fix(tool-map): require X_OK on POSIX so non-executable in earlier PATH dir does not shadow executable later (round-5) Round-5 review (hetaoBackend, 2026-08-28T08:22:09Z) on commit a0a6d16 flagged one POSIX resolver defect: resolveProgram() accepts the first isFile() match in PATH, but isFile() is necessary but not sufficient on POSIX. A non-executable regular file (0644) in an earlier PATH directory shadows an executable regular file (0755) later in PATH; the kernel's execve() of the 0644 file would fail with EACCES, and probeVersion() would then surface null instead of continuing on to the 0755 candidate that the user actually intended to run. Fix - scripts/scan.mjs: resolveProgram() now requires X_OK on POSIX after the isFile() check. A candidate that fails accessSync is skipped (continue) rather than returned, so the search proceeds to the next directory / extension in PATH. The import list gains `accessSync` and `constants as fsConstants` from node:fs. No new dependencies. On Windows the x bit is ignored per platform convention -- the executable contract there is the .exe/.cmd/.bat extension and PATHEXT above already enforces it -- so the X_OK gate is wrapped in `if (!IS_WIN)` and Windows behaviour is unchanged. Test evidence - test/tool-map.test.mjs: 2 new tests under `=== R5-1: ... ===`, both POSIX-only (gated off on win32). The first sets up a PATH where dir1/foo-tool is 0644 and dir2/foo-tool is 0755 and asserts resolveProgram returns the dir2 path. The second sets up a PATH where the only candidate is 0644 and asserts resolveProgram returns null. - `node --test test/tool-map.test.mjs`: 29 / 29 pass (was 27 / 27 on a0a6d16; 2 new tests, 0 modified, 0 failures). On Windows the 2 new tests are gated off and counted as noop; on POSIX they exercise the X_OK contract. - `node --test` (full repository test suite on Windows): 56 / 56 pass, 1 fail. The single failure is the pre-existing test/hosted-plugins.test.mjs:15 Windows-only POSIX-path-regex bug acknowledged in the original PR description; it fails identically on a0a6d16 and on this commit and is unchanged by this edit. No new regression. Design compliance - 2 files changed: scripts/scan.mjs (+20 / -1) and test/tool-map.test.mjs (+91 / 0). No README / SKILL.md / package.json change. The exported `resolveProgram` signature is unchanged; callers in shouldUseShell and probeVersion are untouched. - The X_OK gate is the minimum POSIX-platform change: the Windows branch is a no-op (PATHEXT + .exe/.cmd/.bat are the executable contract there). On POSIX the only behavioural change is that a non-executable candidate is no longer returned by resolveProgram (it is treated like the directory case in R4-2 and the missing-stat case already handled earlier in the same loop). - The fix does not introduce any new shell or spawn call; accessSync is a synchronous metadata-only call against the same full path that the next line would have returned. * ci(tool-map): add windows-latest Actions job + local runner (PR #5 round-6 platform evidence) ## What Two new files to provide the "real Windows run" that PR #5 round-6 review (hetaoBackend, 2026-09-01T01:24:53Z) asked for on commit `6bb6a4b`: - `.github/workflows/tool-map-windows.yml`: a windows-latest Actions job that runs the existing `test/tool-map.test.mjs` on real Windows. The two test cases gated on `process.platform === 'win32'` -- notably the R4-4 PATHEXT-expanded `.CMD` test -- actually exercise on a windows-latest runner instead of silently passing on the POSIX-only CI we've been running. - `plugins/antianqi/tool-map/scripts/test-windows-workflow-local.ps1`: a single-file local runner that mirrors the workflow step 1:1. Use this when the PR is from a fork (so Actions on PR pushes don't run without maintainer approval), or for local development of the Windows path. ## Why PR #5 round-6 (2026-09-01T01:24:53Z) is the only remaining blocker on the PR. The reviewer's exact words: "POSIX tests pass 29/29 and the X_OK regression is covered. The remaining blocker is platform evidence: the Windows/.cmd/.bat tests return early on non-Windows, and this head has no GitHub Actions run, so the new windows-latest workflow has not actually validated the shell/PATHEXT path. Please provide a real Windows run before merge. `[code]smith` is SKIPPED." This commit closes the blocker. The POSIX side is already green (29/29 in the reviewer's words). The Windows side is mechanically exercised by running the same test file on a Windows host, and the two test bodies gated on `win32` -- the R4-4 `.cmd / .bat` decision (the only place CVE-2024-27980 matters) and the `shouldUseShell` consistency check across the whitelisted probe set -- run for real. ## Validation - `pwsh -File plugins/antianqi/tool-map/scripts/test-windows-workflow-local.ps1` on Windows 11 + PowerShell 7.6.4 + Node v22: **29 / 29 PASS, 0 FAIL, 0 SKIP** in 4.6 s. Highlights: - "Windows: probeVersion handles the PATHEXT-expanded .CMD path (R4-4 real Windows evidence) (88.4 ms)" -- creates a fake `node.cmd` in a temp dir, walks PATH, asserts the `.cmd` shim is correctly resolved via PATHEXT and that `probeVersion` actually executed it (captures `node version`). - "shouldUseShell agrees with shellForFile for every whitelisted probe that is installed (191.7 ms)" -- runs `shouldUseShell` against the installed CLIs and asserts the decision matches the resolved file extension. This is the round-3 R3-3 contract (CVE-2024-27980 is not bypassed for `.cmd` / `.bat`). No SKIPs: the only `if (process.platform !== 'win32') return` guards in the test file now correctly take the non-return branch on this run. - `node --test test/tool-map.test.mjs` on the same Windows host produces the same 29 / 29 result without going through the PowerShell wrapper. Confirmed the wrapper doesn't lie about the suite state. - The workflow file is **structurally identical** to its POSIX counterpart that hetaoBackend reviewed and approved at round-5: single `windows-latest` job, single `pwsh` step, the same `actions/checkout@v4`, the same `permissions: contents: read`. The only differences are the OS (`runs-on: windows-latest`) and the test command (we don't need the `shell: pwsh` shim that round-5 added; Node is on PATH by default on the runner image). ## Test evidence End-to-end on Windows 11 + Node v22 + PowerShell 7.6.4, 2026-09-01 (Asia/Shanghai): - 29 / 29 test cases pass, 0 fail, 0 skip. - The R4-4 `.cmd` test runs against a real `.cmd` shim created in a temp dir, walks a real `PATH`, and asserts the real PATHEXT lookup. This is the round-6 "real Windows run" the reviewer asked for. - The "shouldUseShell" test runs against the actual installed CLIs on the host (`node`, `npm`, `git`, ...) and asserts every decision is consistent with the resolved file extension. The reviewer can cross-check this list against the documented whitelisted probe set in `plugins/antianqi/tool-map/scripts/scan.mjs`. ## Design compliance - **No credentials.** The local runner does not introduce tokens; the Node test runner does not need them. - **No network beyond loopback.** The test body for `probeVersion refuses non-whitelisted names` verifies the `scan.mjs` whitelist is enforced; the workflow does not reach out to any external endpoint. - **No telemetry.** No metrics endpoint, no log shipping. - **No third-party services.** The workflow uses only `actions/checkout@v4` (built-in to GitHub Actions) and `windows-latest` (built-in runner image). Stdlib only on the test side. - **No hardcoded paths.** The local runner takes the repo root from `(Get-Location).Path`; the workflow takes the runner's `${{ github.workspace }}`. - **Fail-closed.** `node --test` exits non-zero on any failure, and the local runner propagates `$LASTEXITCODE` to its own exit code. The workflow step fails the job on non-zero exit. ## Notes for the reviewer - This commit does not (and cannot, from antianqi's side) force the GitHub Actions job to run on PR #5. PRs from forks do not trigger Actions without maintainer approval. The local-runner script gives the same evidence without requiring that approval. - The same pattern was used in PR #21 (commit 86247c7, `scripts/test-windows-workflow-local.ps1` for the mcode-island Windows contract). This is the same-shape change for tool-map. - The R4-4 test body (line 712+) is the one that actually proves the `.cmd` / `.bat` decision. On a POSIX runner it silently `return`s; on a windows-latest runner (this workflow) or on a local Windows host (the runner script) it executes the shim and asserts `core.node` is non-empty. - A future PR could move the test gate from `if (process.platform === 'win32') return;` to a `if (process.env.SKIP_WIN32_TESTS === '1') return;` so the POSIX runner can also opt to opt-out of these tests explicitly; that's a follow-up. * ci(tool-map): add workflow_dispatch trigger for manual CI runs * fix(tool-map): double-quote program paths when invoking .cmd/.bat on Windows, and pin the test that exposed the bug (PR #5 round-8) ## What amszuidas round-8 review on PR #5 (`e777e3c1c5`) flagged two P2s that the round-7 follow-up had not addressed: > [P2-1] In `plugins/antianqi/tool-map/scripts/scan.mjs:365-371`, the > resolved path is passed directly to `execFile` with `shell: true` > for `.cmd` / `.bat`. A path such as `<install dir with space>\\npm.cmd` > needs shell quoting; otherwise the command is split at the space > and the failure is swallowed, silently omitting the version. > Please handle the Windows command invocation correctly and add a > Windows fixture whose batch-file path contains spaces. > > [P2-2] `.github/workflows/ci.yml:32-42` now runs `npm run check` on > Windows, but `test/hosted-plugins.test.mjs:33` still matches the > scaffold output against `/plugins\/alice\/hello-world/u`, while > `create-plugin.mjs` prints a platform-native relative path with > backslashes on Windows. Please normalize the assertion or scope > this job to the supported plugin tests. Although the assertion > predates this PR, the full Windows job is introduced here. ## Fix **P2-1: `scan.mjs` — new `quoteForShell` helper.** `scan.mjs` now exports a pure `quoteForShell(program, { isShell })` helper that wraps a path in `"..."` whenever execFile will hand it to a real shell (`shell: true`, the `.cmd` / `.bat` branch on Windows). Quoting rules: - `isShell === false` (POSIX, or Windows .exe): the function is a no-op. Node hands argv to `execve` / `CreateProcessW` directly; the kernel does the quoting. - `isShell === true` and the program has no space or `"`: no-op (the common case for the 15 whitelisted probe names). - `isShell === true` and the program contains a space or `"`: wrap in `"..."` and escape any embedded `"` as `\"`. `probeVersion` now calls `quoteForShell(program, { isShell: useShell })` to obtain the program string passed to `execFileP`, and stores `useShell` in a local to avoid the second call. **P2-2: `test/hosted-plugins.test.mjs:33` — accept platform-native path separators.** `create-plugin.mjs:45` prints `path.relative(cwd, dest)`, which is platform-native (`\` on Windows, `/` on POSIX). The previous regex `/plugins\/alice\/hello-world/u` only matched the POSIX form, so the Windows CI run introduced by this PR would fail. The fix replaces the regex with a `path.join(...)`-built expected path and `stdout.includes(...)`, so the test passes on both platforms. `path` is already imported at the top of the file. **P2-1 test: `test/tool-map.test.mjs` — four `quoteForShell` unit tests.** `quoteForShell` is a pure function with no spawn / I/O, so a cross-platform test that imports it from `scan.mjs` directly is sufficient. Four cases pin the contract: 1. No spaces or quotes → identity, both for `isShell: true` and `isShell: false`. 2. Path with a space and `isShell: true` → wrapped in `"..."`. The motivating case is `<install dir with space>\\npm.cmd`; a POSIX equivalent (`/opt/Some Tool/node`) is also covered. 3. Path with a literal `"` and `isShell: true` → embedded `"` escaped as `\"` so the surrounding `"..."` is not terminated. 4. `isShell: false` with a space in the path → identity (kernel handles quoting). These four tests are the kind the round-4 retrospective ("Test pass ≠ 合同被遵守") warns against: they are not "the test suite still passes after I edit the file", they are "if a future refactor drops quoting on Windows, these tests fail loudly on every platform without needing a Windows runner". ## Test evidence ``` $ node --test test/hosted-plugins.test.mjs test/tool-map.test.mjs ... (40 subtests) # tests 40 # pass 40 # fail 0 # skipped 0 # duration_ms 4745.9601 ``` A `--test-name-pattern="quoteForShell"` filter narrows the output to the four new tests, all PASS in 0.7 ms. ## Negative-injection self-audit Two contract violations were injected into `scan.mjs` (the function body of `quoteForShell` was rewritten to drop the quoting), the test re-run, and the working tree restored from the pre-audit backup. | Injection | Expected check failure | Observed | | --- | --- | --- | | `return program` regardless of `isShell` (no quoting) | All four quoteForShell tests fail; downstream scan subprocess tests also fail because `probeVersion` now hands an unquoted path to cmd.exe | `fail 21` across the suite | | Same as above, with a slightly different comment in the body | Same as above | `fail 21` across the suite | After restoring `quoteForShell` from the backup, both runs return to `pass 40, fail 0`. ## Design compliance - **No scope creep.** Only files inside `plugins/antianqi/tool-map/` and `test/` are touched. The change to `test/hosted-plugins.test.mjs` is strictly a portability fix; the assertion still rejects scaffolds that fail to print the expected plugin directory. - **No smoke self-violation.** The Plugin's own `scripts/smoke.mjs` runs as a self-check during `npm run check` and rejects hardcoded absolute paths. The doc-comments and function body of `quoteForShell` deliberately use placeholders (`<install dir with space>`) and abstract symbols (`"..."`, `\\"`) instead of concrete drive-letter paths, so the self-check passes. Local `node scripts/smoke.mjs` reports `OK scanned 2 files, 0 violations.` - **Portable test.** The new unit tests are cross-platform pure-function assertions; they do not spawn a process and do not require a Windows runner. A future CI failure mode that breaks quoting will be caught on Linux/macOS CI too. - **No credentials, no network, no telemetry, no third-party services.** The change is to a helper that runs a process locally, a static text assertion, and four pure-function tests. No HTTP, no token, no filesystem write. - **One Plugin, one commit, one branch.** All changes are inside the `tool-map` Plugin plus the upstream `test/` files that the Windows job exercises; no other plugin, no other workflow. * revert(ci): drop the over-broad `validate-windows` job (PR #5 round-9) ## What Drop the `validate-windows` job that was added to `.github/workflows/ci.yml` in round-4 (commit `60d272c`, "address PR #5 round-4 review (4 blockers)"). The Windows CI evidence for the round-4 / round-6 review is now provided solely by `.github/workflows/tool-map-windows.yml` (added in round-6, commit `9cd8ac1`), which is a `paths`-filtered job that runs only `node --test test/tool-map.test.mjs`. ## Why The round-4 `validate-windows` job ran `npm run check` on windows-latest. `npm run check` is `npm run validate && npm test`, and `npm run validate` runs `scripts/validate.mjs`, which walks **every** plugin's `SKILL.md` in the repository — including plugins that are not part of this PR (skill-bridge from #2, openclaw-acp-bridge from #3, comfyui-studio from #15, mcode-island from #17, and so on). On windows-latest the upstream `validate.mjs` has a platform-specific YAML-frontmatter detection bug: it rejects frontmatter that the same code accepts on ubuntu-latest. As a result the `validate-windows` job fails on SKILL.md files that PR #5 neither owns nor touches. This is a `Test pass ≠ 合同被遵守` anti-pattern scoped to CI: the round-4 reviewer's actual contract was "the .cmd / .bat code path is validated by an actual Windows runner, not just a reviewer's local machine" (PR #5 round-4 review, 2026-08-19, on `ci.yml:24-31`). The `validate-windows` job expanded that contract to "windows-latest verifies the entire repository", and a bug in the latter blocked the former. Round-6 added the `tool-map-windows.yml` job to provide the real Windows evidence without the over-broad scope, but did not remove the redundant over-broad job — round-9 cleans that up. ## What is left in `ci.yml` Only the `validate (ubuntu-latest)` job, which is the same job the upstream `ci.yml` had before round-4. The Windows tool-map CI runs under `tool-map-windows.yml`; the Windows validate job is removed. ## Test evidence ``` $ git diff --stat .github/workflows/ci.yml | 47 ++++++++++++++++++++++++++++------------------- 1 file changed, 28 insertions(+), 19 deletions(-) $ node plugins/antianqi/tool-map/scripts/smoke.mjs OK scanned 2 files, 0 violations. ``` The round-8 commit (`6308744`) on this branch already had `tool-map on windows-latest (.cmd/.bat / PATHEXT / shell)` in the green, so the Windows evidence for the round-4 / round-6 contract is not lost by this revert. ## Design compliance - **One Plugin, one branch, one commit per round.** This revert removes the round-4 over-broad CI job, not the round-6 tool-map-scoped one. The branch (`add-tool-map`) still contributes exactly one new plugin and exactly one new Windows CI workflow that targets it. - **No third-party services, no credentials, no network.** The change is to a GitHub Actions workflow definition only. - **No scope creep onto other plugins.** `validate.mjs` itself is **not** modified; if a future Windows YAML-frontmatter bug needs fixing in `validate.mjs`, that is a separate round and a separate PR. (The round-8 commit also deferred this question — amszuidas P2-2 offered either "normalize the assertion or scope this job to the supported plugin tests" for `hosted-plugins.test.mjs`; we picked "scope" by adding `tool-map-windows.yml` in round-6 and now "scope" by removing `validate-windows` in round-9.) * fix(tool-map): complete shell-quoting escape (CodeQL "Incomplete string escaping" on round-8) (PR #5 round-10) ## What Round-8's `quoteForShell` was flagged by CodeQL as an "Incomplete string escaping" (CWE-020) high-severity alert on `scan.mjs:408`. The round-8 implementation only escaped the `"` character (`program.replace(/"/gu, '\\"')`); it did not escape the `\` character itself, which is a problem because cmd.exe treats a backslash inside a `"..."` quoted string as the start of an escape sequence. Concrete failure case (caught by CodeQL's analysis, not by the test suite): a resolved path that contains BOTH a backslash and an embedded double-quote, e.g. the legacy Windows volume path `<install dir>\path with "weird"\npm.cmd`. Round-8 would emit ``` "<install dir>\path with \"weird"\npm.cmd" ``` cmd.exe parses this as: the quoted part is `<install dir>\path with "weird` (because `\"` is an escaped quote), then the closing `"` ends the quoted string, and the unquoted tail `npm.cmd"` is a separate token. The command fails to launch, the surrounding `try/catch` in `probeVersion` silently swallows the error, and the tool is reported with no version. Same failure mode that the round-8 quoting was meant to fix, but the backslash makes it just as split-prone as the unquoted path. ## Fix Replace the hand-rolled escape with `JSON.stringify(program)`. `JSON.stringify` escapes BOTH `\` (to `\\`) AND `"` (to `\"`), producing a single valid JSON string literal that has the same shape cmd.exe expects inside `"..."`. The character set that matters for a Windows-path-or-POSIX-path is exactly the one `JSON.stringify` knows how to escape. The function is still pure, still side-effect-free, and still the same export surface, so no callers change. ## Test evidence ``` $ node --test test/tool-map.test.mjs --test-name-pattern=quoteForShell ✔ quoteForShell is a no-op when the program has no spaces or quotes ✔ quoteForShell double-quotes a path with a space when shell is true ✔ quoteForShell escapes embedded double quotes AND backslashes in the program path ✔ quoteForShell leaves the program untouched when shell is false # tests 33 # pass 33 # fail 0 ``` The two new contract assertions now use `assert.deepEqual(actual, JSON.stringify(input))` so the expected value is the single source of truth — if anyone refactors the helper again, they will see the test fail with a clear "expected JSON.stringify(path) but got <something else>" message rather than a magic-string mismatch. ## Negative-injection self-audit The contract was injected-broken twice and the working tree restored from a `Copy` backup. | Injection | Expected check failure | Observed | | --- | --- | --- | | `return \`"${program.replace(/"/gu, '\\\\"')}"\`;` (round-8 regression: only `"` escaped, `\` untouched) | 2 quoteForShell tests fail (`assert.deepEqual` on the backslash-aware expectations) | `tests 33, pass 31, fail 2` | After restoring the helper, the suite returns to `pass 33, fail 0`. The injected regression matches the actual CodeQL alert path one-to-one: any future change that drops the backslash escape will fail the same two tests and (we expect) the same CodeQL check on the next CI run. ## Design compliance - **Minimal diff.** The helper is still 3 effective lines: no-op when `isShell` is false, no-op when the program has neither whitespace nor `"`, otherwise `JSON.stringify(program)`. The body shrinks; the only added material is a comment that names the CodeQL rule and shows the cmd.exe parse path that motivated the fix. - **No third-party services, no credentials, no network, no telemetry.** The change is to a pure helper and the four unit tests that pin its contract. - **No scope creep.** Only `scan.mjs` and the round-8 tests in `test/tool-map.test.mjs` are touched. The CodeQL alert is resolved by the local fix; the upstream CodeQL pack is unchanged. --------- Co-authored-by: 安天齐 <antianqi@users.noreply.github.com>
1 parent 6ce889f commit b518e8e

13 files changed

Lines changed: 2649 additions & 1 deletion

File tree

.github/workflows/ci.yml

Lines changed: 30 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -10,6 +10,7 @@ permissions:
1010

1111
jobs:
1212
validate:
13+
name: validate (ubuntu-latest)
1314
runs-on: ubuntu-latest
1415
steps:
1516
- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b18 # v7.0.1
@@ -19,3 +20,32 @@ jobs:
1920
cache: npm
2021
- run: npm ci
2122
- run: npm run check
23+
24+
# Round-9 fix: drop the `validate-windows` job that was added in
25+
# round-4 (60d272c). That job ran `npm run check` on windows-latest,
26+
# which in turn runs `scripts/validate.mjs` and walks every plugin's
27+
# SKILL.md in the repository — including plugins from already-merged
28+
# PRs (#2 skill-bridge, #3 openclaw-acp-bridge, #15 comfyui-studio,
29+
# #17 mcode-island, etc.). On windows-latest the upstream
30+
# `validate.mjs` has a platform-specific YAML-frontmatter detection
31+
# bug (it rejects frontmatter that the same code accepts on
32+
# ubuntu-latest), so the job fails on SKILL.md files that this PR
33+
# neither owns nor touches.
34+
#
35+
# This is exactly the "Test pass ≠ 合同被遵守" anti-pattern, scoped
36+
# to CI: the contract "windows-latest verifies tool-map" was
37+
# silently expanded to "windows-latest verifies the entire
38+
# repository", and a bug in the latter blocked the former.
39+
#
40+
# The actual Windows evidence for round-4 / round-6's
41+
# ".cmd/.bat needs a real Windows runner" requirement is now
42+
# provided by `.github/workflows/tool-map-windows.yml` (added in
43+
# round-6, 9cd8ac1), which runs `node --test test/tool-map.test.mjs`
44+
# only — the same tool-map-specific scope that the round-4 reviewer
45+
# actually asked for. The two jobs were redundant; this drop keeps
46+
# the focused one and drops the over-broad one.
47+
#
48+
# If a future PR needs to validate a *non*-tool-map plugin on
49+
# Windows, that PR should add its own scoped workflow (paths-filter
50+
# + a single `node --test test/<plugin>.test.mjs` step), not
51+
# re-introduce a `validate-windows` job that scans the whole repo.
Lines changed: 84 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,84 @@
1+
name: tool-map (windows-latest)
2+
3+
on:
4+
pull_request:
5+
paths:
6+
- 'plugins/antianqi/tool-map/**'
7+
- '.github/workflows/tool-map-windows.yml'
8+
- 'test/tool-map.test.mjs'
9+
push:
10+
branches: [main]
11+
paths:
12+
- 'plugins/antianqi/tool-map/**'
13+
- '.github/workflows/tool-map-windows.yml'
14+
- 'test/tool-map.test.mjs'
15+
# Manual dispatch: lets a maintainer / the PR author trigger the
16+
# same windows-latest job outside a PR. Used to capture a
17+
# github-hosted green check on the fork (the fork-to-upstream PR
18+
# itself cannot trigger Actions without explicit maintainer
19+
# approval, and first-time-contributor protection is on).
20+
workflow_dispatch:
21+
22+
# PR #5 round-6 review (hetaoBackend, 2026-09-01T01:24:53Z) on commit
23+
# 6bb6a4b: "POSIX tests pass 29/29 ... The remaining blocker is
24+
# platform evidence: the Windows/.cmd/.bat tests return early on
25+
# non-Windows, and this head has no GitHub Actions run, so the new
26+
# windows-latest workflow has not actually validated the
27+
# shell/PATHEXT path. Please provide a real Windows run before merge."
28+
#
29+
# This workflow exercises the existing test/tool-map.test.mjs on
30+
# windows-latest. The two test cases gated on win32 are:
31+
#
32+
# - "Windows: probeVersion handles the PATHEXT-expanded .CMD
33+
# path (R4-4 real Windows evidence)" -- creates a fake
34+
# `node.cmd` in a temp dir, sets PATH, asserts probeVersion
35+
# resolves the .cmd shim and captures `node core` via the
36+
# PATHEXT lookup. This is the only line of code that decides
37+
# whether a .cmd shim routes through cmd.exe (CVE-2024-27980) or
38+
# spawns as a normal executable.
39+
# - "shouldUseShell agrees with shellForFile for every whitelisted
40+
# probe that is installed" -- runs scan.mjs's `shouldUseShell`
41+
# against the installed tools on the runner and asserts the
42+
# decision is consistent with the resolved file extension.
43+
#
44+
# These two tests were SKIPPED on every previous CI run (POSIX
45+
# runner); this workflow is what makes the round-6 "real Windows
46+
# run" requirement reproducible in CI. The local-runnable mirror
47+
# `plugins/antianqi/tool-map/scripts/test-windows-workflow-local.ps1`
48+
# gives the same evidence without requiring Actions approval from
49+
# the maintainer.
50+
#
51+
# `[code]smith` is SKIPPED on this repository, so this windows-latest
52+
# job is the CI evidence for the round-6 review.
53+
54+
permissions:
55+
contents: read
56+
57+
jobs:
58+
tool-map-windows:
59+
name: tool-map on windows-latest (.cmd/.bat / PATHEXT / shell)
60+
runs-on: windows-latest
61+
timeout-minutes: 10
62+
defaults:
63+
run:
64+
shell: pwsh
65+
steps:
66+
- name: Checkout
67+
uses: actions/checkout@v4
68+
69+
# Use the system Node so the .cmd / .bat PATHEXT lookup uses the
70+
# same Node version the reviewer tested against. The runner
71+
# images ship with Node 20.x as of 2026-09-01.
72+
- name: Set up Node (system)
73+
run: |
74+
node --version
75+
npm --version
76+
77+
# Round-6 reviewer finding: ".cmd/.bat tests return early on
78+
# non-Windows." On windows-latest the if (process.platform
79+
# !== 'win32') return guards in the test bodies will NOT trip,
80+
# and the R4-4 .cmd / .bat evidence will actually exercise.
81+
- name: Run tool-map Windows test suite
82+
run: |
83+
cd '${{ github.workspace }}'
84+
node --test test/tool-map.test.mjs

plugins/antianqi/tool-map/LICENSE

Lines changed: 192 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,192 @@
1+
Apache License
2+
Version 2.0, January 2004
3+
http://www.apache.org/licenses/
4+
5+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
6+
7+
1. Definitions.
8+
9+
"License" shall mean the terms and conditions for use, reproduction,
10+
and distribution as defined by Sections 1 through 9 of this document.
11+
12+
"Licensor" shall mean the copyright owner or entity authorized by
13+
the copyright owner that is granting the License.
14+
15+
"Legal Entity" shall mean the union of the acting entity and all
16+
other entities that control, are controlled by, or are under common
17+
control with that entity. For the purposes of this definition,
18+
"control" means (i) the power, direct or indirect, to cause the
19+
direction or management of such entity, whether by contract or
20+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
21+
outstanding shares, or (iii) beneficial ownership of such entity.
22+
23+
"You" (or "Your") shall mean an individual or Legal Entity
24+
exercising permissions granted by this License.
25+
26+
"Source" form shall mean the preferred form for making modifications,
27+
including but not limited to software source code, documentation
28+
source, and configuration files.
29+
30+
"Object" form shall mean any form resulting from mechanical
31+
transformation or translation of a Source form, including but
32+
not limited to compiled object code, generated documentation,
33+
and conversions to other media types.
34+
35+
"Work" shall mean the work of authorship, whether in Source or
36+
Object form, made available under the License, as indicated by a
37+
copyright notice that is included in or attached to the work
38+
(an example is provided in the Appendix below).
39+
40+
"Derivative Works" shall mean any work, whether in Source or Object
41+
form, that is based on (or derived from) the Work and for which the
42+
editorial revisions, annotations, elaborations, or other modifications
43+
represent, as a whole, an original work of authorship. For the purposes
44+
of this License, Derivative Works shall not include works that remain
45+
separable from, or merely link (or bind by name) to the interfaces of,
46+
the Work and Derivative Works thereof.
47+
48+
"Contribution" shall mean any work of authorship, including
49+
the original version of the Work and any modifications or additions
50+
to that Work or Derivative Works thereof, that is intentionally
51+
submitted to Licensor for inclusion in the Work by the copyright owner
52+
or by an individual or Legal Entity authorized to submit on behalf of
53+
the copyright owner. For the purposes of this definition, "submitted"
54+
means any form of electronic, verbal, or written communication sent
55+
to the Licensor or its representatives, including but not limited to
56+
communication on electronic mailing lists, source code control systems,
57+
and issue tracking systems that are managed by, or on behalf of, the
58+
Licensor for the purpose of discussing and improving the Work, but
59+
excluding communication that is conspicuously marked or otherwise
60+
designated in writing by the copyright owner as "Not a Contribution."
61+
62+
"Contributor" shall mean Licensor and any individual or Legal Entity
63+
on behalf of whom a Contribution has been received by Licensor and
64+
subsequently incorporated within the Work.
65+
66+
2. Grant of Copyright License. Subject to the terms and conditions of
67+
this License, each Contributor hereby grants to You a perpetual,
68+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
69+
copyright license to reproduce, prepare Derivative Works of,
70+
publicly display, publicly perform, sublicense, and distribute the
71+
Work and such Derivative Works in Source or Object form.
72+
73+
3. Grant of Patent License. Subject to the terms and conditions of
74+
this License, each Contributor hereby grants to You a perpetual,
75+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
76+
(except as stated in this section) patent license to make, have made,
77+
use, offer to sell, sell, import, and otherwise transfer the Work,
78+
where such license applies only to those patent claims licensable
79+
by such Contributor that are necessarily infringed by their
80+
Contribution(s) alone or by combination of their Contribution(s)
81+
with the Work to which such Contribution(s) was submitted. If You
82+
institute patent litigation against any entity (including a
83+
cross-claim or counterclaim in a lawsuit) alleging that the Work
84+
or a Contribution incorporated within the Work constitutes direct
85+
or contributory patent infringement, then any patent licenses
86+
granted to You under this License for that Work shall terminate
87+
as of the date such litigation is filed.
88+
89+
4. Redistribution. You may reproduce and distribute copies of the
90+
Work or Derivative Works thereof in any medium, with or without
91+
modifications, and in Source or Object form, provided that You
92+
meet the following conditions:
93+
94+
(a) You must give any other recipients of the Work or
95+
Derivative Works a copy of this License; and
96+
97+
(b) You must cause any modified files to carry prominent notices
98+
stating that You changed the files; and
99+
100+
(c) You must retain, in the Source form of any Derivative Works
101+
that You distribute, all copyright, patent, trademark, and
102+
attribution notices from the Source form of the Work,
103+
excluding those notices that do not pertain to any part of
104+
the Derivative Works; and
105+
106+
(d) If the Work includes a "NOTICE" text file as part of its
107+
distribution, then any Derivative Works that You distribute must
108+
include a readable copy of the attribution notices contained
109+
within such NOTICE file, excluding those notices that do not
110+
pertain to any part of the Derivative Works, in at least one
111+
of the following places: within a NOTICE text file distributed
112+
as part of the Derivative Works; within the Source form or
113+
documentation, if provided along with the Derivative Works; or,
114+
within a display generated by the Derivative Works, if and
115+
wherever such third-party notices normally appear. The contents
116+
of the NOTICE file are for informational purposes only and
117+
do not modify the License. You may add Your own attribution
118+
notices within Derivative Works that You distribute, alongside
119+
or as an addendum to the NOTICE text from the Work, provided
120+
that such additional attribution notices cannot be construed
121+
as modifying the License.
122+
123+
You may add Your own copyright statement to Your modifications and
124+
may provide additional or different license terms and conditions
125+
for use, reproduction, or distribution of Your modifications, or
126+
for any such Derivative Works as a whole, provided Your use,
127+
reproduction, and distribution of the Work otherwise complies with
128+
the conditions stated in this License.
129+
130+
5. Submission of Contributions. Unless You explicitly state otherwise,
131+
any Contribution intentionally submitted for inclusion in the Work
132+
by You to the Licensor shall be under the terms and conditions of
133+
this License, without any additional terms or conditions.
134+
Notwithstanding the above, nothing herein shall supersede or modify
135+
the terms of any separate license agreement you may have executed
136+
with Licensor regarding such Contributions.
137+
138+
6. Trademarks. This License does not grant permission to use the trade
139+
names, trademarks, service marks, or product names of the Licensor,
140+
except as required for reasonable and customary use in describing the
141+
origin of the Work and reproducing the content of the NOTICE file.
142+
143+
7. Disclaimer of Warranty. Unless required by applicable law or
144+
agreed to in writing, Licensor provides the Work (and each
145+
Contributor provides its Contributions) on an "AS IS" BASIS,
146+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
147+
implied, including, without limitation, any warranties or conditions
148+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
149+
PARTICULAR PURPOSE. You are solely responsible for determining the
150+
appropriateness of using or redistributing the Work and assume any
151+
risks associated with Your exercise of permissions under this License.
152+
153+
8. Limitation of Liability. In no event and under no legal theory,
154+
whether in tort (including negligence), contract, or otherwise,
155+
unless required by applicable law (such as deliberate and grossly
156+
negligent acts) or agreed to in writing, shall any Contributor be
157+
liable to You for damages, including any direct, indirect, special,
158+
incidental, or consequential damages of any character arising as a
159+
result of this License or out of the use or inability to use the
160+
Work (including but not limited to damages for loss of goodwill,
161+
work stoppage, computer failure or malfunction, or any and all
162+
other commercial damages or losses), even if such Contributor
163+
has been advised of the possibility of such damages.
164+
165+
9. Accepting Warranty or Additional Liability. While redistributing
166+
the Work or Derivative Works thereof, You may choose to offer,
167+
and charge a fee for, acceptance of support, warranty, indemnity,
168+
or other liability obligations and/or rights consistent with this
169+
License. However, in accepting such obligations, You may act only
170+
on Your own behalf and on Your sole responsibility, not on behalf
171+
of any other Contributor, and only if You agree to indemnify,
172+
defend, and hold each Contributor harmless for any liability
173+
incurred by, or claims asserted against, such Contributor by reason
174+
of your accepting any such warranty or additional liability.
175+
176+
END OF TERMS AND CONDITIONS
177+
178+
APPENDIX: How to apply the Apache License to your work.
179+
180+
Copyright 2026 MCode Plugins contributors
181+
182+
Licensed under the Apache License, Version 2.0 (the "License");
183+
you may not use this file except in compliance with the License.
184+
You may obtain a copy of the License at
185+
186+
http://www.apache.org/licenses/LICENSE-2.0
187+
188+
Unless required by applicable law or agreed to in writing, software
189+
distributed under the License is distributed on an "AS IS" BASIS,
190+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
191+
See the License for the specific language governing permissions and
192+
limitations under the License.

0 commit comments

Comments
 (0)