An executable can start today while leaving tomorrow's maintenance blocked. Source alone makes an operator prepare a development environment first. I deliver the installer, selected public source, startup guidance and hashes together, with a different role for each part.
Provide separate entry points for operation and modification
The installer is an entry for operating the program. The public-source ZIP is an entry for understanding and changing its structure. They refer to a version but are not the same file set. Runtime delivery needs no complete development diary, and source delivery needs no copy of an installed personal environment.
The distribution documents distinguish Windows x64 installation from editable source and compare actual app/MCP source with the canonical version. A recipient can choose to operate first or inspect and modify. A source-available claim should connect to a checkable construction, not merely the presence of files with familiar extensions.
List prerequisites by feature
Current installation guidance separates basic navigation and built-in capture from Python work. External MCP requires Node.js and the recipient's connection file; Python workflows require the specified interpreter and packages. One installer does not mean every feature is ready on every PC.
I also avoid copying historical embedded-CLI instructions into current usage. The installed product removed that internal connection path; an external conversation delegates execution through MCP. Offline regression material remaining in source is not a current runtime capability. Handoff instructions should describe the delivered version's contract rather than repeat every stage of development history.
Resolve paths and authentication in the recipient environment
Recipients log into required sites themselves. The handoff includes no maker account, cookies, projects or connection token. Actual machine paths belong to that computer's data location and host configuration rather than copied constants in public source. An execution example needs a contract, not my authenticated environment.
The source-connection helper changes the selected source location while retaining other runtime-path settings. That differs from a migration wizard moving all existing data. Explain what a recipient prepares and which existing material is read. A changed path should not quietly replace another program's data or turn configuration into an unrequested migration.
Hashes and notices answer different questions
SHA256SUMS supports byte comparison; LICENSE and NOTICE preserve notices for original code and dependencies. Neither replaces the other. Current guidance states the lack of code signing and separate physical-PC verification. Matching a digest creates neither a signature nor universal compatibility.
A historical fresh-user-environment test on the same PC reduced dependence on developer paths. It did not test another Windows account, hardware platform or operating system. Retaining these distinctions helps recipients choose checks for their own environment. Instructions that explain prerequisites and evidence remain more useful than a broad success statement.
Separate local handoff preparation from public upload
Creating and checking a public-source folder and ZIP differs from creating a repository or pushing it. The generator produces local artifacts without automatic upload. Prepared material and an actually public release are separate reportable states.
For this content work I read existing generators and guidance without redistributing the original installer or creating a repository. The separate preservation module compares synthetic snapshots only. The transferable handoff connects installation, modification, environment preparation, file checking and publication as distinct explained stages. Supplying source becomes meaningful when another person can continue without depending on the maker's personal computer.