Skip to main content
← Back to list
01Issue
FeatureShippedSwamp CLIPublic
AssigneesNone

Relationships

#2198 extension push: allow explicit private visibility in the manifest and at publish time, including public collectives

Opened by swamp_lord · 9/16/2026· Shipped 9/16/2026

Problem

Extension authors need to declare that an individual extension is private when publishing it to Swamp Club, independently of whether its owning collective is public.

A public collective can own both public community extensions and private internal infrastructure extensions. Authors should be able to keep the privacy requirement in the extension specification and enforce it during automated publishing. Changing visibility in the Swamp Club UI after publication is too late: the extension must arrive as private from the start.

On CLI version 20260911.215321.0-sha.d18f2d86, swamp help extension push exposes no visibility option. Publishing reports the resulting visibility, but does not provide an explicit publish-time control. This is a request for Swamp CLI/manifest support, with the corresponding registry API behavior where needed.

Proposed interface

Allow an extension manifest to declare visibility, for example:

manifestVersion: 1
name: "@my-collective/internal-infrastructure"
version: "2026.09.16.1"
visibility: private
models:
  - infrastructure.ts

Also support an explicit publish-time option, for example:

swamp extension push manifest.yaml --visibility private

Suggested precedence: explicit CLI option > manifest visibility > existing default behavior when neither is specified.

The resolved visibility must be sent to Swamp Club as part of the publish operation. An explicitly private extension must be created as private even when the destination collective is public; collective visibility must not override that choice.

Acceptance criteria

  • The manifest schema accepts and validates an explicit private visibility setting.
  • The publish command can explicitly request private visibility in non-interactive/CI use.
  • Publishing into a public collective with private visibility creates a private extension from the outset, with no intermediate public listing or public artifact access.
  • --dry-run and the publish preview show the resolved visibility; successful JSON output confirms the actual visibility applied.
  • Subsequent publishes with explicit private visibility keep the extension private.
  • If permissions, entitlements, or registry capabilities prevent private publication, publishing fails clearly rather than silently falling back to public visibility.
  • Omitting the new field and flag preserves existing behavior.
  • Tests cover manifest-only selection, CLI precedence, and private publication into a public collective.

#1545 concerns explaining private-extension push refusals. This request is specifically about declaring and enforcing extension visibility at publication time.

02Bog Flow
✓OPEN✓TRIAGED✓IN PROGRESS✓SHIPPEDTRIAGE+ 5 MOREREVIEW+ 21 MOREPR_MERGED+ 2 MORESESSION_SUMMARIZED

Shipped

9/16/2026, 11:58:07 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
Editable. Press Enter to edit.

swamp_lord commented 9/16/2026, 6:43:23 PM

Service-side prerequisite filed as #2200: https://swamp-club.com/lab/2200. Implement and deploy the registry API support first, then have this CLI feature consume the documented wire contract.

Compatibility requirement: visibility is strictly opt-in. When omitted, a new extension continues to inherit the existing collective default (including the private-collective entitlement exception), and a subsequent publish preserves the extension’s existing visibility. Existing clients, required fields, upload/confirm flow, and release-channel behavior must remain unchanged.

The service already supports per-extension visibility and post-publication changes, but its current push/confirm handlers do not accept a publish-time visibility field. The server change must apply explicit private visibility at initial persistence, rather than publishing publicly and changing it afterward.

#2200 is a platform issue, visible to its author and admins.

Sign in to post a ripple.