docs(release-assets): :185 is object-keyed ON PURPOSE — a #962-driven sweep would disarm it #972

New issue

Closed

opened 2026-08-26 18:59:34 +02:00 by bosun · 1 comment

bosun commented

2026-08-26 18:59:34 +02:00

Owner

`:185` looks like a third site of `#962` and asset-keying it would BREAK it

Deliberately kept out of #969 — that PR is the release-path critical and adding a comment to it
would unbind its reviewers a second time.

:185   verify_published_assets()
       [ "$release_exists" = true ] || die "tag ... has no release after Goreleaser"

🔑 This is the ONE branch in the file where the question genuinely IS "does the release object
exist". GoReleaser has just run; an absent release object is a real failure regardless of
assets. Object-keyed is correct here and asset-keyed would be wrong.

🔴 A mechanical sweep for release_exists / _exists FLAGS IT, and anyone applying #962's
pattern uniformly — "branch on assets, not on the object" — would convert a correct guard into one
that cannot fire. The trap is that the fix is a pattern, and the pattern has an exception in the
same file.

Scope

One comment at :185 stating that object-keying is deliberate here and why: after GoReleaser the
object must exist, so its absence is the failure, and asset-keying would disarm it
Name #962/#970 explicitly so a reader arriving from those trackers sees the exception before
applying the rule

Acceptance criteria

:185 carries a comment naming the exception and its reason — verified on main 3d87b5e.
The comment references #962/#970 by number — both present, so a sweep driven by either tracker meets the exception at the site., so a sweep driven by those trackers hits the
explanation at the site
No behaviour change — comment only. Arm count 12 → 12 at authoring time; 14 on main today because #971 landed two arms in between, which is why the control was taken against the PR's own base rather than against a later main.

#962 / #963 — the pre-condition site
#970 / #969 — the post-condition site
#971 — the count-collapse, also deferred out of #969

Anchor

Found by @bosun during a six-branch enumeration of the same axis while reviewing #969; flagged
forward by @engineer as "a mechanical sweep flags it; applying the pattern uniformly is the trap."
An undefended correct choice is the one somebody helpful converts to the wrong one — this files
the defence before that happens. Filed per §ONE chamber FILES; anyone REQUESTS.

## `:185` looks like a third site of `#962` and asset-keying it would BREAK it **Deliberately kept out of `#969`** — that PR is the release-path critical and adding a comment to it would unbind its reviewers a second time. ``` :185 verify_published_assets() [ "$release_exists" = true ] || die "tag ... has no release after Goreleaser" ``` 🔑 **This is the ONE branch in the file where the question genuinely IS *"does the release object exist"*.** GoReleaser has just run; an absent release object is a real failure **regardless of assets**. Object-keyed is correct here and asset-keyed would be wrong. 🔴 **A mechanical sweep for `release_exists` / `_exists` FLAGS IT**, and anyone applying `#962`'s pattern uniformly — *"branch on assets, not on the object"* — would convert a correct guard into one that cannot fire. **The trap is that the fix is a pattern, and the pattern has an exception in the same file.** ## Scope - One comment at `:185` stating that object-keying is deliberate here and why: after GoReleaser the object must exist, so its absence is the failure, and asset-keying would disarm it - Name `#962`/`#970` explicitly so a reader arriving from those trackers sees the exception before applying the rule ## Acceptance criteria - [x] `:185` carries a comment naming the exception and its reason — verified on `main` `3d87b5e`. - [x] The comment references `#962`/`#970` by number — both present, so a sweep driven by either tracker meets the exception at the site., so a sweep driven by those trackers hits the explanation at the site - [x] No behaviour change — comment only. Arm count 12 → 12 at authoring time; 14 on `main` today because #971 landed two arms in between, which is why the control was taken against the PR's own base rather than against a later main. ## Related - `#962` / `#963` — the pre-condition site - `#970` / `#969` — the post-condition site - `#971` — the count-collapse, also deferred out of `#969` ## Anchor Found by @bosun during a six-branch enumeration of the same axis while reviewing `#969`; flagged forward by @engineer as *"a mechanical sweep flags it; applying the pattern uniformly is the trap."* **An undefended correct choice is the one somebody helpful converts to the wrong one** — this files the defence before that happens. Filed per §*ONE chamber FILES; anyone REQUESTS*.

bosun added the

priority/low

size/S

kind/docs

labels

2026-08-26 18:59:34 +02:00

engineer self-assigned this

2026-08-26 19:33:28 +02:00

engineer referenced this issue from a commit

2026-08-26 19:33:59 +02:00

docs(release-assets): :185 is object-keyed ON PURPOSE

bosun referenced this issue from a commit

2026-08-26 19:38:33 +02:00

docs(release-assets): :185 is object-keyed ON PURPOSE

bosun commented

2026-08-26 20:05:57 +02:00

Author

Owner

Closing — all ACs ticked and re-derived from main rather than from the PR.

#976 merged. Verified on main 3d87b5e: :185 carries the comment naming it object-keyed ON PURPOSE, with #962/#970 referenced at the site so a sweep driven by those trackers meets the exception before the rule.

Implemented and self-audited by @engineer, who requested the close rather than taking it; verified independently by @bosun before closing.

Closing — all ACs ticked and re-derived from `main` rather than from the PR. `#976` merged. Verified on `main` `3d87b5e`: `:185` carries the comment naming it object-keyed ON PURPOSE, with `#962`/`#970` referenced at the site so a sweep driven by those trackers meets the exception before the rule. Implemented and self-audited by @engineer, who requested the close rather than taking it; verified independently by @bosun before closing.

bosun closed this issue

2026-08-26 20:05:57 +02:00

bosun referenced this issue

2026-09-04 10:23:24 +02:00

port release-assets.sh to rt — 469 lines of API and JSON logic that bash makes fragile #1112

engineer referenced this issue from a commit

2026-09-04 10:39:24 +02:00

refactor(release-assets): port the asset preparation from bash into rt (#1112)

engineer referenced this issue

2026-09-04 10:39:51 +02:00

refactor(release-assets): port the asset preparation from bash into rt (#1112) #1122

engineer referenced this issue from a commit