Align safety guard and docs with the real Sprites MCP API

[aezell]

Reviewed the plugin against the Claude Code plugin docs and the authoritative tool reference in superfly/sprites-mcp. The structure was already correct — claude plugin validate passed, the hook matcher used the right mcp__plugin_sprites_sprites__… scoped form, and the 18 tools in the skill matched the server exactly. The problems were in the content: the guard fired on parameters that don't exist, and several doc statements didn't match the real API.

Guard and API alignment (64f8dee)

The exposure confirmation never fired. It looked for public_url, is_public, make_public, and expose_*. The real service_create schema is service_name, cmd, args, needs, http_port, duration — none of those keys exist, so the branch was unreachable. Worse, the unit test asserted against an invented public_url: true, so the suite was green on a fiction.

The actual exposure signal is http_port: per the services docs, without it "the proxy routes to port 8080, not to your service." The guard now keys on that.

Also in this commit:

• Dropped guard patterns for tools that have never existed (delete_sprite, restore_sprite, delete_checkpoint, privilege/resource policy), anchored the three real ones, and gave each its own confirmation reason instead of one generic string.
• checkpoint_create takes comment, not reason — the skill had the wrong parameter name, which is exactly the kind of thing that produces an invalid tool call.
• Documented that policy_network_update replaces the entire rule set. Nothing told the model to read the current policy back first, so a "block one domain" request could silently drop every existing rule.
• Corrected the blanket "treat every Sprite URL as potentially internet-accessible" claim. Per concepts/networking.mdx, URL auth defaults to sprite, and no MCP tool in this plugin can flip it — that is a separate --url-auth public change. The accurate framing keeps the real constraint (anything on http_port is reachable there) without a warning the model learns to discount.
• Noted that Sprite-level tools are generated from the Sprite environment API and can change between versions, so the live tool list wins over the map in the skill.
• Reworked the guard tests to use real parameters, and added coverage for checkpoint_restore, policy_network_update, service_create without a port, and a read-only service_get.

Manifest, CI, and asset tidy-up (0b8151f)

• CI now runs claude plugin validate --strict for both the plugin and the marketplace, pinned to CLI 2.1.224. The README already told contributors to run it; now a stale or misspelled manifest field fails the build. Verified locally that --strict passes on this tree and that validate runs clean against an empty CLAUDE_CONFIG_DIR, so it won't hang the runner.
• Marketplace manifest: metadata.description → top-level description (the former is only accepted for backward compatibility), plus $schema and owner.url.
• The logo asset was unreferenced — there is no icon field in the plugin or marketplace schema — so it shipped in every install for nothing. It is now shown in the plugin README, and the repository checker resolves src paths in HTML tags so that reference is covered by the same broken-link check as Markdown links.
• Removed the empty argument-hint from the status skill.

Verification

13 tests, check_repository.py, compileall, and claude plugin validate --strict on both manifests all pass.

Worth a second opinion

• No fallback for renamed destructive tools. Fly's docs say the Sprite-level tool list can change between environment versions, so a future rename like checkpoint_rollback would slip past the guard silently. The skill instructs Claude to confirm anyway. A loose restore|destroy|delete catch-all would trade some false prompts for that coverage.
• CLI pinned rather than floating. This matches the repo's SHA-pinning discipline and keeps CI deterministic, but a schema change won't surface until someone bumps the pin.