Add plugin entry: xcode

[vburojevic]

What the plugin does

Tracks every Xcode build and test on the machine with zero per-project
configuration — the tracker learns DerivedData roots from the builds
themselves — and shows live progress, verdicts, errors and failed tests with
file:line, per-project history and trends. The same panel streams any booted
iOS simulator over hardware H.264 with full touch input (tap, drag, flick,
long-press, trackpad pinch, ⌘V paste, keyboard), a device picker ranked by
what your builds actually target, and SwiftUI preview rendering with diffs
against the last run (Stills).

Source

• https://github.com/vburojevic/bb-plugin-xcode.git, range ^0.2.0
• Released tag: v0.2.0 (annotated, on main), MIT licensed, public repo

Plugin checks

• npx tsc --noEmit clean; vitest run — 55 files, 728 passed / 3 skipped
• bb plugin build produces dist/server.js, dist/app.js, dist/app.css

Marketplace checks

• npm run build and npm run check (liveness) both pass — 64 entries
• Icon vendored at icons/xcode-52038a9f.svg (stroke glyph, alpha-mask safe)

Security facts for reviewers

• The simulator capture host (serve-sim, pinned 0.1.45) binds loopback only
  behind a route allowlist; the plugin has no public viewer, exposure
  command, or shared-port declaration.
• Model-facing simulator tools and their CLI equivalents are off by
  default behind an allowAgentCapture setting, re-checked per call.
• Tracked builds execute only /usr/bin/xcodebuild, path-confined to the
  invoking thread's checkout, with an environment allowlist.
• Full model: SECURITY.md

🤖 Generated with Claude Code

[SawyerHood]

Automated note from a Claude Code agent, posted on behalf of the marketplace maintainer.

Thank you for the extensive Xcode integration. We are rejecting this version for now because it cannot activate on the current BB SDK.

• SDK 0.4.16 rejects experimental_statusLabels on xcode_status during startup.
• The exact install finishes, but the plugin enters an error state before normal operation.

Please replace the old label fields with presentation.labels. Then publish a new matching tag and repeat the macOS simulator tests.

[SawyerHood]

Automated note from a Claude Code agent, posted on behalf of the marketplace maintainer.

We are requesting changes for the reasons in the automated review comment above. Please reply after a new matching release is available.

[vburojevic]

Fixed and re-tagged: v0.2.2 (annotated, on main). The entry's existing
^0.2.0 range resolves it, so entries/xcode.json is unchanged.

The fix

All six registered tools (xcode_status, xcode_last_failure, xcode_build,
simulator_capture, simulator_drive, simulator_stills) now declare:

presentation: { label: { pending, completed } }

One note for the guidance text: the accepted key is presentation.label,
singular — parsePluginAgentToolPresentation reads declared.label. The SDK's
own throw message says "folded into presentation (labels)", which is what
sent me to the plural first.

Why it survived to review

bb plugin build rewrites a plugin's vendored types/ to match whichever SDK
the locally installed bb carries. This machine runs bb desktop 0.39.0, which
bundles SDK 0.4.8 — so the vendored declarations kept advertising
experimental_statusLabels, and tsc stayed clean right up to your install
attempt. Type checking could not have caught this.

So the structural fix came along with it: the plugin now depends on the
@get-bb/plugin-sdk npm package pinned at 0.4.17 (via bb plugin migrate)
instead of vendoring declarations. The surface is pinned to an explicit
version rather than to whichever bb happens to be installed.

test/tool-registration.test.ts is new. It runs the real registration objects
through the SDK's own executable validators — rejectStaleAgentToolFields and
parsePluginAgentToolPresentation — rather than restating field names, so the
next rename fails the suite instead of the review. Reintroducing the old field
fails it with your exact error.

engines.bbPluginSdk stays at ^0.4.1

Deliberate, and I'd rather flag it than have it look like an oversight. Since
the current desktop release ships 0.4.8, gating at ^0.4.16 would stop the
plugin loading for every user on it — I confirmed bb refuses the load. SDK
0.4.8 ignores the unknown presentation key rather than rejecting it, so the
plugin runs on both; older hosts just render generic timeline rows. Happy to
raise the floor if you'd rather the declaration be exact.

Re-verified

• npx tsc --noEmit clean against @get-bb/plugin-sdk 0.4.17
• vitest run — 57 files, 747 passed / 3 skipped
• bb plugin build produces dist/server.js, dist/app.js, dist/app.css
• Marketplace npm run build and npm run check (liveness) pass on this
  branch — 64 entries
• macOS simulator: bb xcode sim doctor all green (Apple silicon, Xcode 26.6,
  serve-sim 0.1.45 native capture addon loaded, odiff present); plugin
  reloads clean and xcode_status registers and executes on a live host

One honest limit on that last point: this machine's bb bundles SDK 0.4.8, not
0.4.16, so the startup path was validated by running the registrations through
0.4.17's actual validators rather than by booting a 0.4.16 host. The live
simulator capture tools sit behind allowAgentCapture, which I left off, so
those were exercised through the panel and the suite rather than agent-side.