Update v0.3.0 public release documentation

RELEASE_WORKFLOW.md

@@ -2,30 +2,118 @@
 
 ## Repositories
 
-- Private development repository:
-  `~/Projects/vexta`
+### Private development repository
 
-  Contains the full development history.
-  Push is disabled for all remotes.
+```text
+~/Projects/vexta
+```
 
-- Public release repository:
-  `~/vexta-public`
+This repository contains the full Vexta development history.
 
-  Contains only clean public snapshots.
-  This is the only repository allowed to push to GitHub.
+It is used for development, testing, consensus work, and release builds.
 
-## Future release process
+**Never push from this repository.**
 
-1. Finish and test changes in `~/Projects/vexta`.
-2. Create release binaries and checksums.
-3. Copy the current tracked source snapshot into `~/vexta-public`.
-4. Review the public diff carefully.
-5. Commit the public snapshot with a release-focused commit message.
-6. Create a version tag such as `v0.1.1`.
-7. Push only from `~/vexta-public`.
-8. Create the GitHub Release and attach binaries and checksum files.
+### Public release repository
 
-## Important
+```text
+~/vexta-public
+```
 
-Never push directly from `~/Projects/vexta`.
-Never push private phase tags or development branches to the public repository.
+This repository contains the public Vexta source tree and is the **only repository allowed to push to GitHub**.
+
+Official GitHub repository:
+
+https://github.com/VextaProject/Vexta
+
+## Release Process
+
+1. Complete development and testing in `~/Projects/vexta`.
+
+2. Verify that all intended tracked changes are committed.
+
+3. Build and validate the release binaries.
+
+4. Generate SHA-256 checksums for all release packages.
+
+5. Synchronize the public repository from the finalized development commit.
+
+   Example:
+
+```bash
+cd ~/vexta-public
+git fetch ~/Projects/vexta <release-branch>
+git checkout -B <public-release-branch> FETCH_HEAD
+```
+
+6. Review the complete public diff and repository status.
+
+7. Update public documentation, including:
+
+   - `README.md`
+   - `RELEASE_WORKFLOW.md`
+   - release notes
+   - other release documentation when required
+
+8. Commit the final public release state.
+
+9. Create the Vexta release tag.
+
+   Vexta release tags use the format:
+
+```text
+vexta-vX.Y.Z
+```
+
+   Example:
+
+```text
+vexta-v0.3.0
+```
+
+10. Verify that the release tag points to the intended release commit.
+
+11. Push the release branch and Vexta release tag to GitHub **only from `~/vexta-public`**.
+
+12. Create the GitHub Release.
+
+13. Attach the official release archives and publish their SHA-256 checksums.
+
+14. Verify the published source, tag, release files, and checksums before announcing the release.
+
+## Release Validation
+
+Before publishing a release, verify:
+
+- the public tracked tree contains only intended changes
+- the release commit is correct
+- the Vexta release tag points to the correct commit
+- Linux binaries report the intended Vexta Core version
+- Windows binaries report the intended Vexta Core version
+- required consensus and proof-of-work tests pass
+- release archives contain the expected binaries
+- SHA-256 checksums match the final release archives
+
+## Important Rules
+
+Never push directly from:
+
+```text
+~/Projects/vexta
+```
+
+Never expose private development branches, private tags, temporary build files, or unrelated untracked files through the public repository.
+
+Never use destructive cleanup commands such as `git clean` in the private development repository unless the contents have been reviewed explicitly.
+
+Only push Vexta public releases from:
+
+```text
+~/vexta-public
+```
+
+Release tags should use the Vexta-specific naming convention:
+
+```text
+vexta-vX.Y.Z
+```