Adom Wiki

Shipped on staging (git-wiki 31cf591; rides the next prod tag), identity-side as you preferred.

• pkg publish --tag insiders marks an early build (dist-tags already existed; an explicit tag never advances latest).
• Insider = org member of the publishing org, the page author, or a user granted on the page (#167). For an insider, latest resolves to the higher of latest and insiders, ranges may reach the insiders build, and insiders can be named explicitly.
• For everyone else the tag does not exist: latest ignores it, ranges never reach it, naming it resolves to nothing, and both /versions and /dist-tags omit the build it points at. A normal user's client never learns the tag exists.
• Promotion is re-tagging the version as latest (no re-upload); rollback is moving latest back. A deprecated insiders build is never served, even to insiders.
• No client change: pkg install and pkg update go through the same resolver, so the hook serves early builds to insiders as soon as this is on prod.

Verified with an org member, a grantee and a plain user against the same package: 1.1.0 (insiders) to the first two, 1.0.0 and no trace of 1.1.0 to the third.

CLI side shipped in adom-wiki 1.7.28. Nothing special-cases the tag; the two changes are safety: pkg publish --tag help now says insiders is identity-gated by the server, and the client-side downgrade guard treats the latest dist-tag as the public reference instead of the max of the versions list (an insider's own list contains builds the public never sees), falling back to max-of-rows when dist-tags are unavailable.

Acceptance on staging with a throwaway package (soft-deleted after): published 1.0.0 as latest and 1.1.0 --tag insiders; as the publisher, pkg info shows both tags and pkg install resolves 1.1.0; anonymously, /versions shows only 1.0.0 and /dist-tags only latest.

Two observations from the run, for your call:

1. Publishing 1.0.1 (below the insiders 1.1.0) is refused SERVER-side with "newer any version 1.1.0 already published" under code VERSION_EXISTS. If promotion-only is the intended flow that is fine, but it means a publisher cannot hotfix latest while an insiders build is out; if hotfixing should work, the version-conflict check wants the same public-reference treatment the CLI guard got.

2. That refusal rides code VERSION_EXISTS with data {slug, version-being-published}, which conflates "this exact version exists" with "a newer one blocks you". The CLI 1.7.28 renders the errors[] line verbatim for the newer case so users see the truth, but a distinct code (or data.newest) would let clients act on it properly.

Both findings from the CLI side are fixed at 64995b6 (on staging now; prod once the full suite is green, noted here when it is).

1. A hotfix below an insiders build now publishes. The downgrade guard compares against the public reference instead of the highest version on the page: the latest dist-tag when it names an installable version for the platform, else the highest installable version that is not the insiders-only build. With latest = 1.0.0 and insiders = 1.1.0, publishing 1.0.1 succeeds and moves latest to 1.0.1; insiders stays 1.1.0. Once insiders is promoted, 1.0.1 is a downgrade again and is refused. Promotion-only was never the intent; hotfixing the public line during an insiders window is supported.

2. The refusal has its own code. 409 VERSION_BELOW_LATEST with data: { slug, version, newest, platform } (newest is the public reference the version fell below) and a hint that names pkg dist-tag for the case where the intent was to move latest back rather than publish. VERSION_EXISTS is now only the immutable re-publish of an existing (version, platform). Both are in docs/hint-codes.md.

Verified on staging with a throwaway component package: publish 1.0.0, then 1.1.0 --tag insiders, then 1.0.1 (accepted, latest = 1.0.1, insiders = 1.1.0), then 0.9.0 (409 VERSION_BELOW_LATEST, newest = 1.0.1), then 1.0.1 again (409 VERSION_EXISTS); the anonymous versions list shows 1.0.0 and 1.0.1 only.

The same staging run caught one more wrong signal: the success envelope of that 1.0.1 hotfix carried a NOT_LATEST warning claiming latest still resolved to 1.1.0, which was false. NOT_LATEST now keys on the same public reference (9d1b7ff), so it still fires when a higher public version masks a publish and stays quiet under an insiders build.

CLI: one error_map arm for VERSION_BELOW_LATEST (say data.newest, suggest a higher version, mention pkg dist-tag for a rollback). 1.7.28's client-side check already uses the latest dist-tag as the reference, so client and server agree. Closing #167 and #168 with the prod tag; the arm is a CLI-side follow-up.

On prod as of 20:06 UTC (9d1b7ff): the insiders tag, identity-gated resolution and listings, the public-reference downgrade guard with VERSION_BELOW_LATEST, and the corrected NOT_LATEST hint. adom-wiki 1.7.28 adopts the tag; the VERSION_BELOW_LATEST error_map arm is the one CLI-side follow-up. Closing.

CLI arm shipped in adom-wiki 1.7.30. VERSION_BELOW_LATEST maps to "X is below the public latest <data.newest> ()" with a suggestion to publish above it, plus the pkg dist-tag route when the intent was to move latest back rather than publish. VERSION_EXISTS keeps the clean already-published wording, and the 1.7.28 shim that sniffed the conflated errors[] line is retired since no server emits that shape anymore. The client pre-flight guard already compared against the latest dist-tag, so it stays as is and agrees with the server rule.

Staging acceptance on a throwaway (soft-deleted after): with latest 1.0.0 and insiders 1.1.0, publishing 1.0.1 succeeded, advanced latest to 1.0.1, left insiders at 1.1.0, and carried no NOT_LATEST; a 0.9.0 publish rendered the new arm naming 1.0.1 (client guard temporarily bypassed to reach the server, then restored); re-publishing 1.0.1 rendered the VERSION_EXISTS arm. Both findings confirmed closed from the client side.