Promote verified tag artifacts to Gitea releases

docs/PROJECT-STRUCTURE.md

@@ -36,7 +36,7 @@ S:\Game Hacking\Eushully\Himegari\           ← workspace root (three siblings)
     │                                         tracked source and generated references use canonical LF
     ├── .gitea/workflows/core-validation.yml  read-only Ubuntu source-only core gate for the private Gitea remote
     ├── .gitea/workflows/linux-release-build.yml
-    │                                       pinned Linux export/package/smoke artifact job; no release publication
+    │                                       pinned Linux export/package/smoke artifact job plus tag-only promotion
     ├── run-godot.ps1 / run-godot.cmd         tracked development launcher + Windows wrapper;
     │                                          resolves Godot/game-root from parameters, environment,
     │                                          PATH, and the conventional sibling install
@@ -48,12 +48,14 @@ S:\Game Hacking\Eushully\Himegari\           ← workspace root (three siblings)
     │   ├── test_validate.py                   pure resolver + validation-plan regressions
     │   ├── build-linux-x64.sh                 one-command pinned Linux export/package/smoke pipeline
     │   ├── dotnet_publish_proxy.py            guarded low-memory Godot export-time publish staging
+    │   ├── publish_gitea_release.py           guarded/retry-safe native Gitea release promotion
     │   ├── bootstrap-godot-linux-x64.sh       repo-local Godot 4.7 Linux editor/template bootstrap
     │   ├── godot-linux-x64.json               immutable Godot editor/template source + SHA-256 manifest
     │   ├── install_godot_templates.py         selective HTTP-range installer for pinned template members
     │   ├── package_linux_x64.py               export verifier + notice/checksum/archive packager
     │   ├── test_install_godot_templates.py, test_package_linux_x64.py,
-    │   │   test_dotnet_publish_proxy.py        source-only bootstrap/package/publish regressions
+    │   │   test_dotnet_publish_proxy.py,
+    │   │   test_publish_gitea_release.py       source-only bootstrap/package/publish regressions
     │   ├── sys4load.py                         loader + disassembler (opcode-decoding)
     │   ├── age_opcodes.py                      GENERATED complete Python ABI view (do not hand-edit)
     │   ├── opcodes_build.py                    generator/linter: vm-map/opcodes.toml -> the 5 artifacts below

docs/platform-portability.md

@@ -66,9 +66,18 @@ servers disabled, lets the real Godot export consume a strictly validated one-as
 the complete external managed payload only after Godot exits. The complete revised path passes locally, including
 payload verification and the packaged opcode/FFmpeg smoke gate. The hosted retry at `400f431` then completed
 successfully on 2026-08-03, accepting the mitigation and the complete build/smoke/artifact-upload path on the
-target runner. The workflow reports both host memory and cgroup limits for future diagnostics. Release
-publication remains a separate tag-only promotion step; it should consume this already-verified artifact rather
-than rebuilding it.
+target runner. The workflow reports both host memory and cgroup limits for future diagnostics.
+
+Tag-only release promotion is now part of the same workflow without changing that build trust boundary. The
+build job always retains read-only contents permission and uploads one flat five-file artifact: the archive, its
+external SHA-256, build metadata, payload checksum ledger, and smoke log. A dependent job
+runs only after a successful `v*` tag build, downloads that exact artifact without rebuilding, and receives
+job-local `releases: write`. It uses the built-in Gitea job token with the native 1.25 release/attachment API;
+branch and manual runs never receive release authority, and no personal secret or third-party release action is
+introduced. Promotion rechecks the clean source commit, archive checksum, and accepted smoke result after
+artifact download. It is retry-safe but fail-closed: a matching partial release can receive missing assets,
+while mismatched release identity or a same-name/different-size asset is never edited, deleted, or overwritten.
+The next acceptance gate is a deliberate first version tag and inspection of its five release attachments.
 
 ## Dependency inventory
 

docs/remake-architecture-and-roadmap.md

@@ -1015,6 +1015,19 @@ do not mix mechanical moves with semantic changes.
    target Gitea runner. The next bounded slice can promote an already-verified tag artifact to a Gitea release
    without rebuilding it.
 
+   **Tag-only Gitea release promotion (2026-08-03):** the third CI/CD slice adds a dependent promotion job to
+   that accepted workflow. The Linux build/smoke job remains read-only and uploads one flat five-file artifact:
+   archive, external archive checksum, build metadata, payload checksum ledger, and smoke evidence.
+   Only a successful `v*` tag run creates the second job and its job-local `releases: write` token; develop and
+   manual runs never receive release authority. The promotion downloads the artifact from the completed build
+   rather than rebuilding, then uses Gitea 1.25's native release and attachment API with the built-in job token.
+   The project-owned helper verifies the tag/clean-build commit/release identity, archive checksum, accepted
+   smoke result, and fixed archive/evidence set after download. Retries may
+   complete missing attachments on a matching partial release, but mismatches and same-name/different-size
+   collisions fail without edit, deletion, or overwrite. Pure creation/resume/refusal regressions and workflow
+   lint pass locally. The immediate acceptance gate is a deliberately chosen first `v*` tag and inspection of
+   the resulting release/archive/evidence; no tag is created by this slice.
+
 **Not cleanup targets:** generated `build/` output, the two intentional solution files, historical
 `docs/superpowers/` plans/specifications, and fidelity-specific complexity that is directly covered by the
 native ABI. Reorganization is successful when ownership and reproduction become clearer, not when the raw

docs/tools-reference.md

@@ -48,14 +48,27 @@ its tree-equivalent rewritten commit is `524ea74`. The hosted gate also succeede
 `d673652` on 2026-08-03.
 
 The artifact wrapper is `.gitea/workflows/linux-release-build.yml`. It runs independently from the fast core
-gate on `develop` pushes, manual dispatch, and `v*` tag pushes. The job uses the same Python 3.11 and
+gate on `develop` pushes, manual dispatch, and `v*` tag pushes. The build job uses the same Python 3.11 and
 `global.json` .NET setup actions, then calls `./tools/build-linux-x64.sh` unchanged. `actions/cache@v4` retains
 only the two hash-verified dependency archives and the independently hash-verified Linux release template; its
 key is the combined Godot/FFmpeg manifest hash and deliberately has no prefix fallback. Successful runs upload
-the `.tar.gz`, unpacked `BUILD-INFO.json`/`SHA256SUMS`, and packaged-runtime smoke log for 30 days. Failed runs
-retain any smoke/validation evidence for seven days. The workflow has read-only repository permission, no
-secrets or private game corpus, and no release/package publication authority; a tag currently changes only the
-build trigger, not the artifact's destination.
+one flat artifact containing the `.tar.gz`, its external SHA-256 file, `BUILD-INFO.json`, `SHA256SUMS`, and packaged-runtime smoke log for
+30 days. Failed runs retain any smoke/validation evidence for seven days. The build job has read-only repository
+permission, no secrets or private game corpus, and no release/package publication authority.
+
+Only a successful `v*` tag run enables the dependent promotion job. It downloads that same workflow artifact
+rather than rebuilding, checks out only the release tool, and receives job-local `releases: write` plus
+`contents: read`; branch and manual runs skip the job and never receive release authority. The built-in
+`secrets.GITEA_TOKEN` calls the native Gitea API, so no personal token or third-party release action is required.
+`publish_gitea_release.py` validates the version-like tag, exact clean-build commit metadata, archive checksum,
+accepted package-smoke result, fixed five-file asset set, and any
+existing release/asset metadata. A retry resumes a matching partial release and uploads only missing files; it
+refuses mismatched releases or same-name/different-size assets instead of editing, deleting, or overwriting them.
+
+| Tool | Purpose | Run | Reads → Writes |
+|---|---|---|---|
+| `publish_gitea_release.py` | Tag-only, retry-safe promotion of one verified Linux workflow artifact through Gitea's native release API. Requires `GITEA_TOKEN`; the token is passed to upload `curl` through standard input rather than its argument list. | `publish_gitea_release.py --server <url> --repository <owner/name> --tag <v...> --target <sha> --asset <path>` (exactly the five expected `--asset` names) | verified downloaded workflow artifact + tag context → matching Gitea release and five attachments |
+| `test_publish_gitea_release.py` | Pure synthetic creation, retry/resume, collision, and mismatch regressions. | `test_publish_gitea_release.py` | temporary files only |
 
 ## Optional local binary tools