docs: record immutable release policy

README.md

@@ -247,7 +247,7 @@ Code version: **v0.1.1**
 
 Latest GitHub release: **[v0.1.1](https://github.com/mohsinht/zaati-os/releases/tag/v0.1.1)**, published August 25, 2026.
 
-This foundation release establishes the portable data contract, atomic bundle ingestion, adaptive renderer, guided onboarding, provider-neutral prompts, optional encrypted storage, theme studio, privacy boundaries, Cloudflare recipe, and CI quality gates. Hosted LLM workflows remain contract-compatible rather than provider-certified until their recorded end-to-end gates pass. Private validators should pin the reviewed v0.1.1 release commit `0ef31dc8e973e5f1f557b1df9c7f79a012dd7d2a`; future signed and protected release tags may be used as immutable references. See [CHANGELOG.md](CHANGELOG.md).
+This foundation release establishes the portable data contract, atomic bundle ingestion, adaptive renderer, guided onboarding, provider-neutral prompts, optional encrypted storage, theme studio, privacy boundaries, Cloudflare recipe, and CI quality gates. Hosted LLM workflows remain contract-compatible rather than provider-certified until their recorded end-to-end gates pass. Private validators should pin the reviewed v0.1.1 release commit `0ef31dc8e973e5f1f557b1df9c7f79a012dd7d2a`; future signed, protected, and immutable releases may be used as stable references. See [CHANGELOG.md](CHANGELOG.md).
 
 Before storing real data, read [Data lifecycle and key recovery](docs/data-lifecycle.md). Fork maintainers can follow [Upgrade and fork sync](docs/upgrading.md).
 

docs/maintainer-setup.md

@@ -11,6 +11,7 @@ In repository Settings, Security and analysis:
 3. Enable secret scanning and push protection when available.
 4. Enable private vulnerability reporting.
 5. Add repository variable `DEPENDENCY_REVIEW_ENABLED=true`.
+6. Enable release immutability. GitHub applies it only to releases published after the setting is enabled.
 
 The dependency review workflow remains safely skipped until that variable is set. This avoids a false failing check on new repositories where the dependency graph API is not yet active.
 
@@ -26,7 +27,7 @@ After the first successful runs, protect `main`:
 - block force pushes and branch deletion
 - apply the rules to administrators unless an emergency procedure says otherwise
 
-Create a second active ruleset targeting `refs/tags/v*`. Block tag updates and deletion, and create each release tag as a signed tag. A published release tag is an immutable validator reference only when both controls are in place.
+Create a second active ruleset targeting `refs/tags/v*`. Block tag updates and deletion, and create each release tag as a signed tag. Together with repository release immutability, these controls protect the tag, release metadata, and assets from later changes.
 
 For every private data repository, add a second ruleset for `.github/**` and `zaati.data.json`. Require trusted-owner review and block the producer identity from bypassing it. The producer needs Contents and Pull requests write access only. It must have no Actions, Workflows, Administration, secrets, variables, environments, or repository-settings write access.
 

docs/release-process.md

@@ -7,6 +7,6 @@
 5. Confirm GitHub Actions remain pinned to reviewed full commit SHAs.
 6. Merge through the protected `Quality gate` and CodeQL checks.
 7. Create and push a signed tag matching `vX.Y.Z`; the protected `v*` tag ruleset prevents later updates or deletion. Do not publish the GitHub release manually. The tag workflow reruns all checks before creating it.
-8. Verify the release notes, tag, assets, demo, and fork-upgrade instructions.
+8. Verify the release notes, signed and protected tag, immutable-release status, assets, demo, and fork-upgrade instructions.
 
 Do not create a release when the complete-source, privacy, or independent-publication gates are failing. A shiny tag is not a security control, although it does look fetching.