Cli versioned resource plugins

[scott-cotton]

Depends on:

• https://github.com/signadot/signadot/pull/7007 (server-side symmetric-name shape)
• include versioned resource plugins go-sdk#80 (regenerated client from the above)

This PR addresses signadot/community#116

What changes for users

Plugin references take the form name[@<semver>] everywhere a user types or sees a plugin reference:

signadot rp apply -f my-plugin.yaml       # version comes from the YAML name: field
signadot rp list                          # NAME column renders foo@1.2.0 (or bare foo at default)
signadot rp versions my-plugin            # new: every published version
signadot rp get my-plugin                 # latest
signadot rp get my-plugin@1.2.0           # specific version
signadot rp delete my-plugin@1.2.0

In YAML, the version travels with name: as an @<semver> suffix — there is no separate version: field. A bare name publishes the plugin at the default version (0.0.0):

name: my-plugin@1.2.0
spec: { ... }

A stray top-level version: field is silently ignored, like any other unknown top-level field.

What get / list look like

For plugins published at the default version, get -o yaml returns the bare name: my-plugin (no @0.0.0 suffix), matching the pre-versioning CLI surface byte-for-byte. For any concretely-versioned plugin, the response carries the version in the name field as a single token. get -o yaml round-trips back into apply -f without renaming.

Server contract

• Identity on the wire is a single name field; the version is the optional @semver suffix.
• Versions are immutable: re-applying an existing (name, version) — including the implicit default 0.0.0 — returns 409. The CLI maps that to resource plugin %q version %q already exists; versions are immutable — bump the version field to publish a new revision, and uses default version (0.0.0) when the user never set one.
• get and delete accept ?version=<v> or omit/?version=latest for the highest semver.
• ListResourcePlugins returns latest-only; per-plugin version listing is the new versions subcommand.

Test plan

• go test ./... passes locally.
• Loader unit tests cover bare name, @version suffix, and the now-ignored top-level version: field.
• --help for resourceplugin, get, versions renders the new NAME[@VERSION] usage.
• e2e: apply a plugin with bare name, GET it back, see name: my-plugin.
• e2e: apply a plugin with name: foo@1.2.0, list, get by version, list versions, delete by version.
• e2e: apply same plugin twice with same version → see the 409 message.

Before merging

• Re-pin go-sdk to the merged tag from go-sdk#80 (currently on the versioned-resource-plugins branch tip).

[scott-cotton]

The latest push (3 commits, 23bc855..7577984) adapts this PR to the symmetric-name wire shape introduced in signadot/signadot#7007. Summary of what changed from the previous state of the branch:

• name@version is the wire form, end to end. The previous shape carried name and version as two body fields on PUT and as two response fields on GET. Now the body and the response both use a single name field of the form bareName[@semver]. get -o yaml pastes straight back into apply -f.
• Top-level YAML version: is dropped. The earlier review feedback had us accept either name: foo@1.2.0 or name: foo + version: 1.2.0. Once the wire identity collapsed to a single token, supporting two YAML forms for the same thing only widened the input space beyond what get -o yaml produces. The loader now reads name: as the wire form directly; a stray version: key is silently ignored, like any other unknown top-level field. Users who hand-wrote the two-field form should fold the version into the name suffix.
• Default-version plugins display bare. A plugin published at 0.0.0 (no @semver in apply) is shown as name: my-plugin everywhere — the CLI's apply success message, get/list/versions output, and the JSON body the server returns. Concrete versions still render name: my-plugin@1.2.0. This preserves byte-for-byte compatibility with the pre-versioning CLI surface for the typical "I don't care about versioning" user.

The CLI commits in this push correspond 1:1 to the three layers of change:

1. 23bc855 resourceplugin: adapt to combined name wire field — go-sdk bump; split req.Name for the URL-path arg in apply/delete; use rp.Name directly in printers (it's already joined on the wire).
2. 2577541 resourceplugin: drop top-level YAML version field — remove optionalStringField and the XOR check from subst.go; trim related test cases; drop the version key from utils.extractName's keep-list for delete -f.
3. 7577984 resourceplugin: render default-version plugins as bare name — go-sdk re-bump for the bare-default server change; drop effectiveNameRef in favor of formatNameRef (which already produces bare when version is empty).

Net: this PR no longer adds any local string-splitting "cleverness" to paper over a server asymmetry — the server now exposes the same shape the CLI always wanted.

[davixcky]

NAME        CREATED                       STATUS
foo@2.0.0   2026-05-19T14:50:09.656114Z   0 resources
foo@1.5.0   2026-05-19T14:53:39.50125Z    0 resources
foo@1.1.0   2026-05-19T14:50:09.055472Z   0 resources
foo@1.0.0   2026-05-19T14:50:07.937688Z   0 resources

IMO this is verbose, we are repeating the same word over an over (foo)

Also the CREATED time doesn't seem to be aligned with others, for example sb list

[scott-cotton]

NAME        CREATED                       STATUS
foo@2.0.0   2026-05-19T14:50:09.656114Z   0 resources
foo@1.5.0   2026-05-19T14:53:39.50125Z    0 resources
foo@1.1.0   2026-05-19T14:50:09.055472Z   0 resources
foo@1.0.0   2026-05-19T14:50:07.937688Z   0 resources

IMO this is verbose, we are repeating the same word over an over (foo)

Yes but IMO it should be verbose because this is tabular output and hence both expected and easier to automate, which in my mind outweighs the repetition. wdyt in light of this?

Also the CREATED time doesn't seem to be aligned with others, for example sb list

This PR did not change the time, it was pre-existing problem. But, I agree it would be better to be aligned, so I've added that in 5577eba.

[davixcky]

Yes but IMO it should be verbose because this is tabular output and hence both expected and easier to automate, which in my mind outweighs the repetition. wdyt in light of this?

I guess if you want to automate, why not use output json instead?

The reason of saying this, is because also aligned with our current web and how others vendors also do it

I will suggest something like this

> signadot rp versions foo
Name: foo

TABLE

[foxish]

Maybe we can do a regular version of the command that just lists the plugin name and latest version, and an --all-versions flag that can list the full expanded table (for using with CLI automation)?

[davixcky]

Can be a flag, but not --all-version cause we are already showing all the versions. I think is more --full-version

[foxish]

Can be a flag, but not --all-version cause we are already showing all the versions. I think is more --full-version

I was saying by default when listed, show just the latest version (1 entry per plugin), and then --all-versions would be the one showing all versions.

[scott-cotton]

I guess if you want to automate, why not use output json instead?

To me, it is not a question of whether there exists an alternative which is more expensive and takes more care to craft.

There is a long long history of tools outputting tables and using things like awk, cut, paste, sed, etc. IMO by far the gold standard for CLI tools outputting to stdout is for piping. And the example you give is a photo of a UI, not tabular text output for piping, it doesn't really address the issue IMO.

It is worth noting that one could separate the version in a different column. The reason it's not like that now is to make the presentation of name[@Version] uniform everywhere. But, in any output which is a table/matrix, repetition in some columns at least is expected IMO.

I am ok with @foxish's suggestion to only show the latest version unless a flag is provided, which would be another way to reduce the repetition across columns. I guess it might make it less ergonomic to navigate the version history, requiring a separate call to the versions subcommand, but the tradeoff seems reasonable to me.

[foxish]

It is worth noting that one could separate the version in a different column.

I think this is a good idea also, to have the xyz@vN identifier being shorthand but allowing the long form split representation for outputs. I don't feel strongly about this, but if it is not too brittle to split, it could be nicer.

[scott-cotton]

@davixcky @foxish

Please see last commit regarding the listing /versions.

Upon doing that, I realised I (or we) had conflated the rp list with the rp versions list through the discussion. In fact rp list was already latest only, and the repeated text example was from the versions command.

Last commit

• splits version into its own column in both rp list and rp versions
• removes the name from the output of rp versions

wdyt?

[scott-cotton]

Pushed 7343d25 covering the four hot-path CLI findings from the UX pass:

#4 apply immutable-version error wording. The previous errors.As(err, *ApplyResourcePluginConflict) was dead code: the go-sdk's transport middleware FixAPIErrors intercepts every 4xx/5xx response before the per-endpoint typed reader runs, so that type is never in the error chain. Users saw the raw 409 Conflict: plugin version already exists. Switched to matching *transport.APIError + Code == 409 (same pattern as internal/command/planexec/logs.go:164).

Folded in finding #11 while we're here: bare-name authors got the dead-end advice "bump the version field" they didn't have. The branch now emits a concrete add an @<semver> suffix to publish a new revision (e.g. my-plugin@0.0.1) for that case.

#5 apply success silent on version for bare-name authors. Was emitting Created resource plugin my-plugin for bare publishes vs Created resource plugin my-plugin@0.0.1 for explicit-version publishes. The asymmetry hid the versioning rule from exactly the population that most needs to see it. Now always echoes @version on the success line (@0.0.0 for bare publishes), as a teaching moment. The list/table/get-yaml display still bares the default version for backward compatibility — this single line is explicit on purpose.

#3 bare-form delete silently removes only the latest. Now resolves the latest version up-front (one List call), deletes it explicitly, then reports both what was removed and how many versions remain:

Deleted resource plugin my-plugin@0.0.1.
1 other version(s) remain (use 'signadot resourceplugin versions my-plugin' to list).

Small race remains (someone publishes a newer version between the List and the Delete); we still delete the version we resolved, which matches the user's mental model of "delete whatever was latest when I asked".

#6 delete-in-use doesn't name holding sandboxes. Server's generic 400 Bad Request: plugin is currently in use is now enriched client-side: on that specific 400 we GET the plugin and surface the sandbox names from Status.Resources:

resource plugin foo@1.2.0 is still referenced by sandbox(es): customer-sb, orders-sb

Falls back to the original error if the enrichment GET fails.

go test ./... green. SKILL.md updated to reflect the new error wording and delete warnings.

[scott-cotton]

Pushed 559ca79 picking up the go-sdk regen of versioned-resource-plugins (with the new ?version=all schema from signadot/signadot#7025).

signadot rp list --all-versions (or -A). Calls the list endpoint with ?version=all and renders one row per (name, version), sorted by name then semver-descending. The existing NAME / VERSION column split makes the expanded view naturally scannable.

Multi-version hint on the default list. Addresses finding #7. When the user runs the plain rp list (no flag), the CLI issues a cheap second list-with-?version=all and counts how many bare names show up more than once. If any do, a footer hint appears under the table:

NAME         VERSION   CREATED      STATUS
echo-test    0.0.2     5m ago       0 resources
mariadb      1.4.1     2h ago       1 resource
…
(3 plugins have multiple versions — pass --all-versions to expand, or 'resourceplugin versions NAME')

The hint is supplementary — errors fetching it are silently dropped, so the exit status reflects only the primary list call. The hint is skipped under JSON/YAML output (those callers can compute it from the all-versions payload if they need to).

go test ./... green.

[daniel-de-vera]

LGTM

[daniel-de-vera]

@foxish, @davixcky I will go ahead and merge this one (further changes can be addressed in a separate PR).