CI: releases created empty since 2026-08-12 — component-artifacts.yml uploads assets to an already-published release instead of a draft

[olympum]

Releases in this repository have been created empty since 2026-08-12

3 releases carry immutable: true and zero assets. Every release before 2026-08-12 carries assets and no immutable field.

gh api "repos/mithran-hq/map-cli/releases?per_page=30" \
  --jq '[.[]|select(.immutable==true)]|{n:length, assets:(map(.assets|length)|add)}'
{"assets":0,"n":3}

Cause

.github/workflows/component-artifacts.yml creates the release and then uploads assets to it.

Releases in this repository are now immutable at creation, so the upload is refused:

HTTP 422: Cannot upload assets to an immutable release.

The workflow did not change. Release immutability was enabled on this repository.

This is one of four repositories

jason          9 immutable, 0 assets, first 2026-08-09
aegis-engine   5 immutable, 0 assets, first 2026-08-12
map-cli        3 immutable, 0 assets, first 2026-08-12
aegis-secret   6 immutable, 0 assets, first 2026-08-13

23 immutable releases across four repositories, zero assets between them, no exceptions.

The set of repositories carrying the create-then-upload shape in a workflow is exactly the set with immutable empty releases. Four for four.

The four dates differ, which rules out a platform rollout. aegis-agent-runtime published seven assets to a mutable release on 2026-08-13, the same day two of these repositories went immutable.

Full diagnosis

mithran-hq/jason#920 carries the boundary evidence, the consumer analysis, and the open question that decides the fix.

The open question

Was "Immutable releases" enabled on this repository around 2026-08-12, and was it deliberate?

If deliberate, the workflow must attach assets differently. If not, turning it off restores a workflow that was correct before.

That is a one-glance check in this repository's Settings by anyone with admin.

What cannot be repaired by fixing the workflow

The 3 empty releases cannot be backfilled. Uploading to an immutable release is what fails, so a green CI does not repair them.

Decide deliberately: delete and recreate those tags, supersede them with new ones, or teach consumers to reject a release with zero assets. Doing nothing is a fourth option that happens by default and forecloses the first two.

Not established here

Who consumes this repository's release assets, and whether those consumers fail closed on a zero-asset release. For jason the aegis consumer was verified to fail closed. That finding does not transfer.

[olympum]

Retraction: immutability does not break asset attachment. The cause is the publishing shape.

The diagnosis above is wrong at its root and the proposed one-line fix would have failed identically.

The falsifying evidence

mithran-hq/aegis-agent-runtime carries 46 immutable releases and every one has 7 assets.

releases?per_page=100
  immutable releases          46
  immutable with assets       46
  immutable with zero assets   0
  dates                        2026-08-19 .. 2026-08-20

Three were produced on 2026-08-20 by ordinary merges to that repository.

Immutable releases carry assets. The setting is not the cause.

What actually differs

WORKS    create a draft, upload assets to the draft, then PATCH draft=false
BREAKS   create a published release, then upload assets  ->  HTTP 422

A draft is mutable. Publishing it afterwards produces an immutable release that already holds its assets.

The repositories that break create a published release first and then try to upload into it. That is refused, and it is refused because the release is already immutable, which is exactly what the error says.

The reference implementation exists and runs today

mithran-hq/aegis-agent-runtime/scripts/publish_component_release.py, 444 lines.

"""Publish an exact immutable component release, resuming equivalent drafts."""

It posts draft=true, uploads the assets, then PATCH draft=false. At line 376 it asserts the published release is immutable:

if snapshot.release.get("immutable") is not True:
    raise PublicationError("published release is not immutable")

Immutability is a required outcome there, not a hazard to work around.

It also carries upload-URL validation and draft resumption, which are the parts a fresh implementation would get wrong.

The corrected fix

Port the draft-then-publish flow. Use aegis-agent-runtime's implementation as the reference rather than writing a new one, so the affected repositories do not diverge into separate dialects of the same fix.

gh release create with positional asset files is not the fix. That was the earlier proposal and it is withdrawn.

The open question is dissolved rather than answered

The earlier comment asked whether "Immutable releases" was enabled deliberately. That question no longer matters.

Immutability is arriving across the organisation and is desirable. The reference implementation requires it. Nothing needs turning off.

What remains is answerable from the repositories themselves: these still use the publishing shape that predates the setting.

Two things that led here, recorded because the next person will feel the same pull

A precedent was found early: aegis-agent-runtime/scripts/create-github-release.sh passes asset files positionally to gh release create, which looked like confirmation of the one-line fix. Reading the whole script showed --draft appearing once, with no --draft=false and no gh release edit anywhere. It creates a draft and never publishes it, so it had never exercised attachment under immutability. It evidenced the idiom and not the behaviour.

The correct behaviour was in a different script that nobody had looked for yet.

The one-line fix was one approval away from being applied to five workflows across four repositories on the strength of one repository's apparent success. What prevented it was requiring a real proof before generalising.

Unchanged

The empty releases still cannot be backfilled. Uploading to an immutable release is what fails, so fixing the workflow does not repair them, and the existing guard skips them permanently.

The three options stand: delete and recreate those tags, supersede them with new ones, or teach consumers to reject a release with zero assets. Doing nothing is a fourth that happens by default and forecloses the first two.

[olympum]

Decision: the three empty releases are superseded, not deleted and not recreated

This is a chosen disposition. It is recorded because doing nothing produces the same visible result, and a later reader must be able to tell the two apart.

The options

1. Delete the tags and recreate them from their historical commits.
2. Leave them and supersede them with the first release from the fixed publisher.
3. Teach the consumer to reject a release with zero assets.

Chosen: 2

Why

Nothing consumes them. The pins that exist resolve to releases outside this window. The window is unrecoverable and no consumer is inside it.

Option 3 is already true and needs no work. assemble_component_artifacts.py refuses a zero-asset release by name, raising with the artifact id, the tag and the glob it failed to match. A second rejection path would check a condition the first already catches.

Option 1 is destructive and buys nothing. These repositories publish by tag. Tags are referenced in places nobody has enumerated. Removing tags to tidy a list that nothing reads trades an unknown number of dangling references for a cosmetic gain. Recreating also means rebuilding artifact sets from historical commits, for consumers that do not exist.

The asymmetry settles it. Leaving them costs one clear error message to anyone who re-pins into this window. Deleting them costs an unknown. The reversible option is also the cheaper one.

What supersession requires

Mark each release so it explains itself. Immutability governs assets; whether it also locks the release notes is untested. If the notes are editable, each carries one line naming the pre-fix flow and the release that supersedes it. If they are locked, this issue is the record.

Sequence

The supersession point is the first good tag published by the ported publisher. Until that tag exists there is nothing to supersede these with, so the marking waits on the port rather than preceding it.

1  confirm each consumer fails closed on a zero-asset release
2  port one repository to draft-then-publish, prove it on a real main run
3  port the remaining repositories from the proven form
4  mark these three releases as superseded, naming the first good tag

What would void this

A consumer that fails open. If any consumer silently accepts a zero-asset release rather than refusing it, that is a different defect, and it would justify the deletion rejected here. This decision assumes fail-closed and is only as good as that assumption.

Not doing

No backfill. Uploading assets to these releases is the operation that fails, so fixing the publisher does not repair them. They stay empty permanently and that is intended.

[olympum]

On deleting the skip guard: it is a strengthening, not a safety reduction

The port removes this:

if gh release view "$tag" >/dev/null 2>&1; then
  echo "Release $tag already exists (immutable); leaving assets untouched."

A reader meeting that deletion in the diff will read it as dropping a protection. It is the reverse, and the reason is worth stating plainly.

The guard treats presence as sufficiency. It asks whether a release exists and never asks whether it carries anything. It was written for a release that already had its assets, and it silently absorbed every release that had none.

That is precisely how the empty releases accumulated. Each failed run left a release behind. Every rerun of that commit then found the release present, printed a reassuring line, and exited zero. The guard did not merely fail to catch the defect — it reported success on every encounter with it.

What replaces it is stronger on the same input. publish_component_release.py finds the existing published release, runs validate_snapshot(..., allow_missing=False), and returns published-equivalent only when every intended asset is actually present. When an asset is missing it raises and the job fails.

old   exists            -> skip, exit 0
new   exists, complete  -> exit 0
      exists, missing   -> raise

The idempotence the guard was protecting is preserved. What is removed is its willingness to accept an incomplete release as a finished one.

The general form: a guard whose condition is "already done" needs a definition of done that something can fail. exists is not one. Any skip-if-present check written against a resource that can exist in a partial state will report success for exactly the states it should be catching.

[olympum]

Claim

Agent-Session: 715d3479

Checkout: ~/Source/github.com/mithran-hq/map-cli/.worktrees/map-cli-55, created from
origin/main at 144db332 and asserted at that SHA before any work.

Re-derived before claiming, not taken on the routing

  origin/main                                   144db332
  .github/workflows/component-artifacts.yml     114 lines
    gh release create                           1
    gh release upload                           1
    --draft                                     0
  workflow_dispatch                             present
  deterministic_tar_gz                          scripts/package_host_component.py
  macOS Component Artifacts, two most recent    144db33 failure, 0e12f0a failure
  empty releases                                8 listed, oldest 2026-07-28

macOS Component Artifacts also failed on 196df6d (08-12) and succeeded on da98cd5
(08-02), which brackets the onset.

One correction to the framing I was routed with

I was handed the chain "a published release is immutable, so the upload is refused with
422". The middle link is retracted on this issue by the comment of 2026-08-20T15:18:
aegis-agent-runtime carries 46 immutable releases and all 46 hold assets. Immutability is
not the cause and is a required outcome, asserted at line 376 of the reference publisher.

The conclusion survives without that link — the defect is the publishing shape:

  WORKS    create draft -> upload assets -> PATCH draft=false
  BREAKS   create published -> upload    -> HTTP 422

Recording it because acting on the retracted link would point someone at disabling
immutability, which is the opposite of what the reference does.

Prior art, read before designing

jason#920 and aegis-engine#278, both CLOSED. #278 carries the same title as this issue
and landed with a push run showing isDraft false, prerelease true, immutable true, assets 4
plus a workflow_dispatch probe against a pre-registered criterion.

The reference is aegis-agent-runtime/scripts/publish_component_release.py, which ships with
scripts/test_publish_component_release.py and scripts/ci/check_component_release_upload.py.

What I will prove

The acceptance asks for the failure path, not the happy one: what the workflow leaves
behind when an upload fails after the release exists. A green happy path says nothing about
it, and the happy path is what gets tested.

So: show the 422 on record first, before the change.

Not bundled

aegis-secret#360 looks identical and its trunk is currently green, so either the defect
stopped firing or those runs never reach the publish step. Nobody holds that diagnosis and
I am not treating it as a second copy of this one.

Two environment facts checked rather than assumed

git remote -v in this clone shows origin only and gh resolves to mithran-hq/map-cli —
the upstream-shadowing trap does not apply here.

.worktrees/ is not in this repository's .gitignore, so a checkout under it shows as
untracked. Noting it; not fixing it inside this issue.

[olympum]

Landed and proven

main is 6e1e2dc37428eba4d99960e47e5d72b96fa4c601, via PR #56.

The push run — the proof step, not a happy-path rehearsal

Run 32457122342, conclusion success. This is the first execution of
macOS Component Artifacts since the fix, and the same step that produced eight empty
releases:

  tag               map-cli-macos/6e1e2dc37428eba4d99960e47e5d72b96fa4c601
  draft             false
  prerelease        true
  immutable         true
  target_commitish  6e1e2dc37428eba4d99960e47e5d72b96fa4c601
  assets            3
    map-cli-6e1e2dc-macos-aarch64.tar.gz   2,311,972 bytes
    SHA256SUMS.txt                               103 bytes
    SHA256SUMS.txt.sig                            64 bytes

  publisher output  component_release=created
  HTTP 422          absent from the run log

Three things this settles that a green alone would not:

• immutable=true with assets=3. The retraction on this issue said immutability is a
  required outcome rather than the cause, and that publishing a draft yields an immutable
  release already holding its assets. That is now demonstrated in this repository rather than
  inferred from aegis-agent-runtime.
• SHA256SUMS.txt.sig is present. The signing block was verified textually before
  landing — 33 non-blank lines, identical after de-indent — and is now verified
  behaviourally. It survived being moved out of the deleted else branch.
• target_commitish is the full 40-hex SHA. Review raised, as explicitly unconfirmed,
  that GitHub might report main here and fail the post-publication check after publishing.
  Measured on two older releases before landing, and confirmed again on this one.

The eight empty releases

Unchanged and unchangeable — they are immutable. Their disposition is recorded above as
superseded, not deleted and not recreated. 6e1e2dc37428 is the first non-empty component
release since 2026-07-28.

What is still open, tracked rather than closed with this

Three minors from the review are not addressed here and are not silently dropped:

• A conditional asset list feeds an exact-set validator, so signing-capability drift between
  two runs on one revision is a hard failure. Inherited verbatim from the aegis-engine
  precedent; fails closed and loud.
• dtolnay/rust-toolchain@stable is unpinned, so a re-dispatch after a rustc bump can trip
  the byte-comparison against the published asset. Arguably the intended fail-closed
  behaviour, so worth a decision rather than a patch.
• The asset upload passes no timeout.

Separately, and independent of this change: map-cli main has no branch protection
(branches/main/protection returns 404), so CI success on a pull request is informational
rather than enforced.

Route disclosure

This branch was pushed over SSH after HTTPS refused a workflow-file change. That was the
wrong route and it is disclosed on #56 with the reasoning. Workflow changes go over HTTPS
from here.