Separate application language from tool runtime

Your application may use TypeScript, Vite, Next.js or a Node API while a release step uses Python. This is the same boundary as a compiler, signing utility or image optimizer: the build tool’s implementation language does not dictate the application’s language.

CloneGuard v0.1 is a repository CLI, agent skill and optional read-only MCP server. It is not a published native TypeScript protection engine. Do not install an unrelated similarly named registry package or assume an npm wrapper would automatically remove the Python requirement.

Pin the tool and prepare the runner

Check out a reviewed CloneGuard revision in a dedicated tools path, and provision a supported Python interpreter in the runner. Use the project’s existing Node and package-manager setup for its own build. Keep CloneGuard updates separate enough that maintainers can review a change in audit behavior.

A CI example should name the actual tool path rather than depend on an unverified global command. In a Node-only container, either add Python to the controlled build image or run the artifact audit in a separate job with access to the immutable build output.

Audit the artifact rather than node_modules

Build the application normally, identify the public deployment directory and audit that exact tree. Do not substitute the source checkout or development dependency tree. A Next.js server build needs adapter-specific boundaries; CloneGuard loose-web staging is not meant for the whole .next tree.

{
  "scripts": {
    "release:audit": "python3 /tools/cloneguard/cloneguard audit ./dist --scope release"
  }
}

Keep integration claims narrow

Run a synthetic failure case to confirm the CI job fails for an exposed map or known fake credential, then remove the fixture before publishing. Verify that errors and incomplete scans also fail. Store generated reports in CI evidence storage outside the public artifact.

An npm package could improve installation and programmatic integration for Node teams. A wrapper would still need Python unless it embedded or replaced the engine. The current integration offers artifact checks and receipts; it does not add bundler rewriting, automatic API middleware or demonstrated REA resistance to the application.

Make the job boundary reproducible

In a split pipeline, upload the build output as an immutable CI artifact and audit that downloaded artifact in the Python-enabled job. Confirm the deploy step consumes the same bytes or a documented staged derivative, rather than rebuilding from source with different environment variables. Retain checksums or the CloneGuard receipt to connect the jobs. Provisioning Python in one audited build image is often simpler than maintaining a second implementation merely to avoid a tool runtime. If your organization prohibits that runtime, document the current integration constraint honestly instead of claiming native Node execution.

Practical checklist

  • Pin a reviewed tool revision and Python runtime.
  • Use the real deployment output path.
  • Test a synthetic failure and an incomplete scan.
  • Document the lack of a native npm engine today.

Sources and further reading

Primary references support the technical details. Procedures here are guidance; only explicitly recorded project results describe tests we ran.

  1. CloneGuard CLI and documented scope

Prepared with AI assistance. How this library is produced. Suggest a correction; keep private code and credentials out of public issues.