A source-only archive is not automatically suitable for public release. Development instructions and historical records can contain real accounts or machine paths. Northstar has separate development-archive and public-source builders. I treat retaining useful code and excluding the personal environment as two connected design tasks.
A source ZIP name does not define its inclusion policy
Source_archive excludes runtime data and dependencies but retains root instructions and broad docs/scripts/tests. That can support resuming development without being the same as public selection. A filename containing source is not an approval procedure for publication.
Public_release uses a separate allowlist and rejects personal instructions, authentication, path settings and connection files. Profiles, databases, logs, captures and operational material stay outside the public construction. Development completeness and the minimum useful public set are different questions. A retained selection list is easier to review than the statement that a few files were removed from a general ZIP.
Preserve runtime bytes and handle test examples separately
The public builder compares runtime app/package/SDK/MCP source bytes with canonical files. Publication preparation must not quietly create different product code. Tests and retained regression material instead have substitutions for specifically known personal examples using synthetic values.
The two operations serve different purposes and receive separate counts. Runtime-identical file count need not equal total public files. A replacement list handles known examples; it is not an anonymizer that detects every personal detail. New material requires renewed selection and content review. Byte identity and privacy review cannot substitute for one another.
Explain why retained historical code is still needed
The current public set includes selected archived embedded-CLI TypeScript for offline regression and type dependencies. Its presence does not establish an active embedded CLI in the installed product. Runtime entry points and explicit installer inclusion remain separate evidence.
Removing everything merely because its folder says archive can instead break public-source checks. Document why it is retained and its lack of runtime connection, then test the extracted set. Minimizing public files is not a competition for the smallest count. The goal is a modifiable construction separated from the personal environment, without resurrecting retired features.
Zero pattern findings do not end content review
The builder checks selected credential-like patterns and forbidden files, stopping on a finding. It also checks ZIP integrity. Credential-pattern zero means no match to those regular expressions, not proof that every company name, manuscript or unstructured secret is absent.
Current release guidance therefore calls for separate file-list review. Documents, comments and fixtures still need reading for disclosure meaning and scope. This article reviews selection rules rather than opening and deleting personal files. A separate public candidate preserves the original development environment and makes comparison and review easier to repeat.
The public construction should support its own checks
Extract a new ZIP elsewhere and run type, architecture and regression checks with dependencies matching the lockfile. Files available only in the development checkout must not accidentally hide omissions. This does not imply a new network dependency installation or complete other-PC compatibility; retain the conditions and limits of the actual record.
I did not run the original public generator or upload it for this article. Current rules and historical results provide the narrative material, while this site supplies independently checked synthetic modules. Useful public source retains what another maintainer needs without carrying the maker's logins and actual work along with it. That separation is the distribution knowledge I want to share.