Skip to main content
← Back to list
01Issue
FeatureOpenSwamp CLI
AssigneesNone

Relationships

#1545 Use whoami entitlement to explain private-extension push refusals

Opened by keeb · 8/6/2026

Follow-up deferred from #1544.

#1544's first stated motivation was that entitlement-gated failures are unexplainable: private extensions are gated on planEntitlesPrivateExtensions(plan) (plan !== "free"), but when a push or pull is refused the CLI has no local notion of plan to say why, or to suggest which collective needs upgrading.

#1544 scoped itself to reporting — it makes swamp auth whoami carry per-collective plan, planName, subscriptionStatus and trial, plus a top-level roll-up — and deliberately did not touch the push path. src/libswamp/extensions/push.ts:391 still resolves only collective slugs via getCollectives() and has no plan awareness, so the refusal message is unchanged.

What to do

Use the entitlement the server now returns to turn a bare refusal into an actionable one: name the collective whose plan blocks the push and what plan it needs. The data is already on the wire after #1544 — this is about routing it into the push error path and wording the message.

Worth checking whether the refusal should re-fetch entitlement or reuse what whoami already resolved, and being careful not to cache plan locally: entitlement is server-authoritative, and a stale cached plan would produce a confidently wrong error message.

Refs #1544.

02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED

Open

8/6/2026, 7:41:29 PM

No activity in this phase yet.

03Sludge Pulse

Sign in to post a ripple.