Repair release archives and document current Sized distribution

SHIPMENT.md

@@ -6,8 +6,9 @@ This document defines the process for versioning and distributing the `sized` pr
 
 Use a named branch from `main` and keep a pull request focused on one outcome.
 The `sizequeen-scan-hardening` branch corrects accounting/error handling and
-adds the scan controls needed by SizeQueen; shared-crate extraction follows
-in a separate PR so reviewers can distinguish behaviour changes from packaging.
+adds the scan controls needed by SizeQueen; the scanner has also been
+extracted into private `sized-core` for SizeQueen. Sized retains its own copy
+until adoption preserves public source access.
 
 1. Run local locked tests and strict Clippy as an unprivileged user. Run
    `./scripts/check-linux.sh linux/arm64` and
@@ -20,8 +21,8 @@ in a separate PR so reviewers can distinguish behaviour changes from packaging.
 3. Review and merge independently of distribution. A branch push or PR merge
    does not publish a package, change repository visibility or create a tag.
 4. Choose the release version after reviewing library/API compatibility, then
-   use the release steps below when explicitly authorized. Reconcile legacy
-   GitLab download/package links before announcing a Gitea release.
+   use the release steps below when explicitly authorized. Verify the exact archive
+   contents, target and installation instructions before announcing a release.
 
 ### Gitea Linux CI
 
@@ -68,40 +69,54 @@ The project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html
     git tag -a v1.0.0 -m "Release v1.0.0"
     ```
 
-## 2. Asset Generation
-
-The `scripts/release.sh` script is the authoritative way to generate release assets locally or in any CI environment. 
+## 2. Asset generation and verification
 
 ```bash
+./scripts/check-release.sh
 ./scripts/release.sh
 ```
 
-This script generates:
--   **Optimized Binary**: The production-ready `sized` executable.
--   **Documentation**: The `sized.1` man page.
--   **Shell Completions**: Scripts for Bash, Zsh, and Fish.
--   **System Installers**: A `.deb` package for Debian-based Linux distributions.
+`release.sh` uses the locked dependencies and the Rust toolchain's host target.
+It packages the executable **before** creating the archive, together with the
+man page, Bash/Zsh/Fish completions, licence, README, manual and build metadata.
+Outputs are `dist/sized-v<VERSION>-<RUST-TARGET>-<REVISION>/`, a sibling `.tar.gz`
+and `.tar.gz.sha256`. Existing outputs are never replaced. Use
+`--output-dir /absolute/new/path` for an explicitly named local candidate.
+`CARGO_TARGET_DIR` is respected. The script does not sign, upload, tag or publish.
 
-All assets are gathered in the `dist/v<VERSION>/` directory.
+`check-release.sh` creates temporary outputs, extracts the archive, checks all
+required files and the checksum, then runs the packaged executable against an
+owned fixture. It also checks the refusal to overwrite. Gitea's Linux check
+runs this same test; a successful compile alone is insufficient.
 
-## 3. Distribution Channels
+Only build from a clean, reviewed commit for distribution. `BUILD-INFO.txt`
+records the commit, target, toolchain and whether tracked inputs were modified.
+Exported source can provide `SIZED_SOURCE_REVISION`; verify that provenance
+against the original checkout. Retain matching source and complete dependency
+licences with any public binary distribution. A host build is unsigned; do not
+advertise it as notarized or as a Mac App Store application.
 
-### crates.io
-To update the project on the central Rust registry:
-```bash
-cargo publish
-```
+## 3. Distribution channels
 
-### System Package Managers
-For Homebrew, GitLab, or Gitea-based distribution:
-1.  Push the git tag to your SCM.
-2.  Run the release script to generate assets.
-3.  Attach the contents of the `dist/` folder to your SCM's "Release" or "Tag" entry.
-4.  Update downstream formulas (like `homebrew-tap`) with the new source URL and SHA256 of the generated tarball.
+The existing public Gitea v1.0.0 release contains a macOS arm64 executable,
+man page and completions, plus generated source archives. It predates the
+scanner hardening branch. No architecture-labelled binary archive, `.deb` or
+verified Homebrew tap is currently offered.
 
-## 4. Automation & Hooks
+Future public releases need their own reviewed version, source, target-specific
+archives, checksums and installation acceptance. Do not replace historical
+v1.0.0 assets with newly built bytes. Add a new version only after review.
 
-To automate asset generation locally, you can use a git `post-checkout` or a wrapper script. Since gitea and gitlab use different CI formats, it is recommended to simply call `./scripts/release.sh` within your preferred CI runner (e.g., `gitlab-ci.yml` or `gitea-actions`).
+Debian/Alpine packaging is separate from the portable host archive. Do not
+implicitly invoke `cargo deb` or `abuild` just because they are installed: a Mac
+binary is not a Debian package. Validate each installer on its target OS before
+publishing it. Registry and Homebrew publication are separate decisions too.
+
+## 4. Automation
+
+CI tests and packages temporary candidates without publishing credentials.
+Do not run release generation automatically from Git hooks. Publication remains
+an intentional operation after the checks above.
 
 ## 5. Manual Installation
 For system-wide installation from source, use the `Makefile`: