Release publishing relies on an unwritten convention, not a gate: nothing stops a publish from an unverified ref

[monkopedia-coder]

publish.yaml runs ./gradlew publish and nothing else — it invokes no test,
apiCheck, ktlintCheck or check task. Publication goes to Maven Central,
which cannot be undone: a version, once released, stays released.

That by itself is not a defect. Coverage can live upstream of the publish
workflow, and here it does:

• ci.yaml runs on push: branches: [main], so every commit that lands on
  main gets a full CI run.
• Every release so far was cut from a main commit. Checked the six most recent
  (v1.1.0 through v1.1.5): each tag's SHA has a push-event CI run with
  conclusion success.

So in practice every published artifact was built from a ref whose CI was
green. The problem is that this is a convention, not a gate, and it is
written down nowhere.

Specifically, nothing mechanically prevents publishing from an unverified ref:

• main has no branch protection and the repository has no rulesets
  (/branches/main/protection returns 404, /rulesets returns []), so no
  status check is required for anything.
• publish.yaml triggers on release: [created]. A release can be created
  against any commitish, not just a main commit that CI has run on.
• publish.yaml also triggers on workflow_dispatch, which can be dispatched
  against any ref and skips the release path entirely.
• ci.yaml does not trigger on tags, so a tag placed on a non-main commit
  would have no CI run at all — and an absent check rollup reads the same as a
  passing one to anyone eyeballing it.

There is a second limit worth recording alongside this, because "CI was green
at that ref" sounds stronger than what it covers. ci.yaml is ubuntu-only:
lint, jvm-tests, jni-tests, native-tests (linux) and compiler-tests.
It executes no Apple tests, and no js or wasm tests (#251). Green main CI at a
release ref is real coverage, but it is not coverage of every published
platform.

Suggested resolution

No workflow change is required to close this. The options, roughly in order of
cost:

1. Document the release procedure — "cut releases only from a main commit whose
   CI is green" — in CONTRIBUTING/release notes, so the convention is
   discoverable rather than tribal.
2. Have publish.yaml assert its own precondition: fail fast if the resolved
   ref has no successful CI run.
3. Require the CI checks on main via a ruleset, which closes the "release cut
   from an unverified ref" path directly.

Filed as documentation of an unwritten guarantee, not as an assertion that a
bad artifact has shipped. Nothing in the release history suggests one has.

[monkopedia-coder]

Triaged agent-workable, scoped to options 1 and 2. Recording the reasoning here because this issue was filed by the same account running the triage and was characterised elsewhere as an owner call, so the classification ought to be checkable rather than taken on trust.

Why not needs-decision. The question would have to be "which of the three resolutions do you want?" -- and "there are three options" is not by itself a decision for the owner. Picking the best one and naming the fallback is ordinary engineering judgment. The scope question that matters here is narrower: what is genuinely gated is cutting and publishing a release, the irreversible outward act, since a Maven Central version once released stays released. Options 1 and 2 do not perform that act and change nothing about what ships:

• Option 1 (document the procedure) changes no workflow at all. The body says as much: "No workflow change is required to close this."
• Option 2 (publish.yaml asserts its own precondition) produces byte-identical artifacts. It can only refuse to publish from a ref with no successful CI run. That is a guard on the machinery, not a change to the released artifact, and not a change to who decides that a release happens.

Neither takes the release decision away from anyone. Both convert the existing convention -- which the body verified holds for v1.1.0 through v1.1.5 -- from tribal into checkable.

Option 3 is out of scope, but not for the reason the body implies. Requiring the CI checks on main via a repository ruleset is a repository-settings change: it cannot be delivered by a pull request at all, and it constrains every future push to main, including direct ones. That is the owner's to make in the repository settings, and it is a different kind of act from the other two rather than a more thorough version of them. If it is wanted it takes about a minute in the UI, and it does not need this issue open to happen.

Default for the dispatched work, if nobody says otherwise: do both 1 and 2. Option 2 without option 1 leaves the why undocumented; option 1 without option 2 leaves the gap exactly as unmechanised as the body describes.

Two constraints for whoever picks it up:

• workflow_dispatch needs an escape hatch. The body correctly notes it can target any ref. A precondition check that hard-fails every manual dispatch would lock the maintainer out of a legitimate hotfix publish; an override input that has to be set deliberately keeps the guard honest without doing that.
• Do not let the guard overstate what it proves. The body's second half is the important half: ci.yaml is ubuntu-only and runs no Apple, js or wasm tests (js and wasm test suites exist but no workflow runs them; 2 of 11 published platforms execute any test #251). "This ref has a green CI run" is a real precondition and it is not "every published platform was tested." Whatever the check reports should say the narrower thing.

[monkopedia-coder]

Triaged agent-workable -> blocked. No change to the work or to PR #269; this is a label
correction.

The label was right when it was applied and is wrong now for the ordinary reason: the work under it
is done. Options 1 and 2 — the dispatched scope — are implemented in
#269, which is deliberately held as a draft with
its approvals dismissed, per the owner's 2026-08-26 ruling that if the publish gate blocks on tests
passing it should block on all the tests passing. That is a named dependency, not a decision
waiting on anyone: it discharges when Apple (#275) and js/wasm (#251) test execution exist.

agent-workable on top of that advertises the issue as free to pick up while its PR sits open, which
is the standing-false-dispatch shape this repo has now hit three times in one stack. blocked is
tag-only and changes nothing about the PR.

Option 3 (require CI checks on main via a ruleset) remains out of scope for the reason already
recorded above — it is a repository-settings change no pull request can deliver — and it does not
need this issue open to happen.