Choose the correct input
Point staging at the directory that would actually be published as public static files. A source repository, an entire framework server build, a signed native app or a deployment archive is not interchangeable with that directory. Establish this boundary with the owner of the build and hosting configuration.
The distinction matters because generic cleanup inside a native package can invalidate signatures, and copying server artifacts to a static host can expose files that were never meant for visitors. Keep private diagnostic storage and release receipts outside the public output.
Preview and review the plan
Use a new output path and run the dry-run form first. Inspect the listed omissions and any rejected surfaces. Known .map files, environment or key files, private debug companions and version-control metadata are candidates for exclusion, but legitimate public files still need an intentional policy.
python3 /tools/cloneguard/cloneguard stage ./dist --out ../public-release --dry-run
python3 /tools/cloneguard/cloneguard stage ./dist --out ../public-releaseResolve refusals at the right step
Staging refuses unsupported or unsafe inputs such as symlinks, native executables, signed bundles, incomplete inventories and unresolved high findings. Treat a refusal as a reason to inspect the input or fix the build. Do not bypass it by renaming a file or copying only the scanner-visible subset.
Inline maps and embedded secrets need changes in the source or bundler followed by a rebuild. Staging does not parse and rewrite arbitrary JavaScript, remove a sourceMappingURL directive, implement code obfuscation or validate runtime authorization. Preserved bytes are useful evidence, but they do not establish every browser interaction still works.
Validate what will be served
Run the project’s existing tests against the staged deployment path. Check lazy-loaded chunks, workers, styles, public data files and asset URLs. Create a receipt outside the staged tree after all intended files have been finalized, then verify the published inventory where deployment access permits.
Keep the original release for rollback and private diagnostic retrieval according to your retention policy. The result is a narrower public artifact and a reviewable change. Public code and application behavior remain inspectable, so this workflow should not be advertised as a complete anti-cloning compiler.
Check a referenced companion intentionally
Imagine a public app.js that still ends with a reference to app.js.map. Staging can exclude the map file while preserving app.js exactly, so the reference remains. That is expected from a byte-preserving copy tool. Decide whether the reference is allowed by your policy; if not, generate the desired bundle through the supported bundler setting. Also test that removing a file did not remove a deliberately public resource with an unusual extension. The dry-run is a review artifact, not a substitute for understanding the assets the application needs. Preserve its findings with the final file inventory.
Practical checklist
- Identify the exact public hosting directory.
- Review dry-run omissions and refused inputs.
- Keep source, private maps and receipts outside output.
- Smoke-test the staged site and record its final inventory.
Sources and further reading
Primary references support the technical details. Procedures here are guidance; only explicitly recorded project results describe tests we ran.
Prepared with AI assistance. How this library is produced. Suggest a correction; keep private code and credentials out of public issues.