port fork-pr-approval-notice.sh to rt — same API-plus-JSON shape, smaller #1113
Labels
No labels
bump
major
bump
minor
bump
patch
kind/bug
kind/chore
kind/docs
kind/feature
priority/critical
priority/high
priority/low
priority/medium
size/L
size/M
size/S
size/XL
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/release-toolkit#1113
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
scripts/fork-pr-approval-notice.shis the same class asrelease-assets.shat a quarter the size: it talks to the API and parses JSON in bash.Referenced by one workflow. Nothing about it needs to run before
rtexists, so there is no bootstrap argument for keeping it in shell.AC
rt, the script is deleted, and the workflow calls the verb📌 Lower priority than
release-assets.shand independent of it. Take it second; the two share a shape but no code.Closing — every AC verified against
origin/mainat10ccb54c.rt, the script is deleted, and the workflow calls the verbVerification
Notice text — byte-compared, not read. The shell's own
printfformat was replayed from0d79de63^and compared against a live call toforknotice.Body:(A first pass showed a 6-byte delta. That was my extraction leaving the shell source's six escaped backticks literal — three pairs,
pull_request/ head / base — not a difference in the port.)⚠️ Scope note on AC 2, since a tick reads as coverage.
tests/fork-pr-approval-notice.batsis preserved, but it now guards the workflow's security shape — target-only, checkout pinned tobase.sha,rtproduced exactly once bygo build ./cmd/rt, norefs/pull/head.shareachable. It does not assert the notice text. So the arms are preserved and valuable, and they are not what verifies AC 3; the byte-comparison above is.AC sweep, re-derived from
origin/mainrather than from the close. Per §Acceptance-criteria tick discipline, a state-asserting AC is only ticked when the state is true and checkable at tick time.✅ So "the script is deleted, not left as a wrapper" and "no workflow keeps a bash path to the same behaviour" are TRUE and checkable. The zero is from a grep across both workflow trees and
scripts/, not from the workflow tree alone.⚠️ NOT verified by me, and deliberately left unticked rather than assumed: the arms-as-acceptance-oracle criteria, and — on #1112 — "every one of the six prior defects has a Go test that reddens without the fix". That is a mutation claim, and reading a test is not running one. Ticking it off a file listing would be exactly the "presence is not integrity" failure.
📌 Whoever completes this sweep needs only the mutation half; the deletion and call-site halves are measured above and need not be redone.
AC sweep — all three were true and un-ticked. Ticked now, against
forgejo/main@fb1bd9c2.The third AC — "the notice text is unchanged" — was the one worth actually measuring rather than eyeballing. The notice body was extracted from the deleted script (at
0d79de63^) and frominternal/forknotice, normalised forprintf%svs Go concatenation, and byte-compared:The prose is character-for-character identical. Stated with the control because a byte-comparator that returns IDENTICAL is exactly the result an inert one also returns.
Swept by @bosun, 2026-09-05.