Define portable plugin display names and icons

[jonathanhefner]

Motivation

The portable name field is deliberately constrained, so it cannot preserve capitalization, spacing, punctuation, or other branding used in human-facing interfaces.

The specification also provides no portable way for clients to discover a plugin icon.

Proposal

This PR adds an optional displayName field to plugin.json and a fixed assets/icon.<format> convention for optional plugin icons. It also reserves assets/ for future specification-defined portable assets.

{
  "$schema": "https://agent-plugins.org/schemas/1.1.0/plugin.schema.json",
  "name": "example-plugin",
  "displayName": "Example Plugin"
}

my-plugin/
├── plugin.json
└── assets/
    └── icon.png

Clients presenting a human-readable name prefer displayName and fall back to name. Clients that display icons must support PNG and may support additional formats, including safely rendered SVG. Missing or unusable icons do not affect plugin or component loading.

The change applies only to the 1.1.0 working draft; the published 1.0.0 specification remains unchanged.

Rationale

Fixed icon filenames avoid manifest indirection and precedence rules.

Reserving assets/ prevents collisions with future portable asset conventions.

[Patrick-Erichsen]

LGTM! Small feedback from my agent that seems worthwhile:

One small edge case: displayName currently accepts blank and unbounded strings, while clients are instructed to prefer it over name. Could we require 1–128 characters and at least one non-whitespace character? That prevents blank labels and gives clients a predictable UI bound.

[jonathanhefner]

One small edge case: displayName currently accepts blank and unbounded strings, while clients are instructed to prefer it over name. Could we require 1–128 characters and at least one non-whitespace character? That prevents blank labels and gives clients a predictable UI bound.

That was something I had considered, but ultimately omitted because:

• It's difficult to define appropriate constraints for all cases and all UI surfaces -- e.g., are emoji-only display names allowed?
• Other optional metadata fields (such as homepage and license) have no constraints other than their type.

However, I've added a commit that clarifies clients "MAY use name instead when displayName is unsuitable for the presentation context, such as when it is empty or contains only whitespace".

Would that sufficiently address your concern?

[Patrick-Erichsen]

Yeah I think so! We strip out emojis on ClawHub for example even though they're allowed in the name, but it makes sense to leave that up to the client imo.

+1 if homepage and license also omit any constraints like this.