A client handover should let a recipient answer four questions without asking the sender: what is included, which version is current, how can I open it, and what remains open? ZGMob’s Zip & Go tool packages selected files in a browser-created ZIP with an index, a README, and a manifest.json. The manifest records the package title, creation time, note, and each file’s display name, original name, and byte count. It does not scan, convert, encrypt, host, or send the files for you.
Build a manifest that names the boundary
Before packaging, separate approved final deliverables from drafts, source material, and internal notes. Put a human-readable version label and issue date in the README or package note, such as “Client site handover v1.2 — 20 October 2026.” State the intended recipient, primary contact, opening instructions, and the next review date. Do not include passwords, API keys, recovery codes, or access links that grant permanent control; send credentials through the agreed access-management process and record only who owns that process.
The manifest’s byte sizes help a recipient notice an obviously incomplete transfer, but they are not a content-authentication system. ZIP entries use integrity information such as CRC checks as part of the archive format; that can detect accidental corruption when an archive tool reads the entry, but it does not prove who produced a file or that a recipient has the intended release. When a contract needs a stronger boundary, agree an out-of-band SHA-256 value from a trusted hashing tool and the channel through which the recipient compares it. NIST’s Secure Hash Standard defines the SHA family; Zip & Go does not claim to generate or verify that value.
Run a receiving test
Download the ZIP as the recipient would, open it on a separate device or account, and read the index before opening a sample from each file class. Check that names match the manifest, the version label is visible, and links in the README lead to the correct final location. If a browser blocks a download, a corporate security control quarantines a file, or the recipient lacks an application, record that as an open handover dependency rather than silently changing the package.
- Package only files approved for the recipient and remove stale drafts.
- Include a purpose, version, date, owner, contents list, and explicit open items.
- Keep credentials outside the archive and state the separate provisioning path.
- Use a separately agreed cryptographic hash only where an integrity requirement calls for it.
- Ask the recipient to complete one real opening task and acknowledge any missing dependency.
If the recipient reports a mismatch, preserve the received archive and the original sent archive while the owner compares version labels and file lists. Avoid “fixing” the package in place: issue a new version and state what changed. The downloadable checklist is a starting record. ZGMob’s practical handover planning can scope the manifest, recipient test, and follow-up without representing the local tool as a managed delivery platform. Agree who retains the final package and for how long, because a download link or browser download alone is not a retention policy.