Add plugin entry: ultragoal

[braedonsaunders]

Summary

• Lists UltraGoal (ultragoal) on BB Community.
• Source is https://github.com/braedonsaunders/bb-plugin-ultragoal.git with range ^0.2.6 (current tag v0.2.6).
• Vendors the plugin icon at icons/ultragoal-9a4e92b2.svg.

What it does

Codex-style durable UltraGoals for Cursor, OpenCode, Claude Code, and Pi. The root thread orchestrates named workers and keeps working until the objective is done, blocked, paused, or limited.

Source

• Git: https://github.com/braedonsaunders/bb-plugin-ultragoal.git
• Range: ^0.2.6
• Release: https://github.com/braedonsaunders/bb-plugin-ultragoal/releases/tag/v0.2.6

Plugin checks

• Plugin id derived from bb-plugin-ultragoal is ultragoal.
• Public v0.2.6 tag is present and immutable.

Marketplace checks

• npm run build and npm run check succeed on this branch.
• Icon is vendored in icons/; the entry does not use a remote icon URL.

[SawyerHood]

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

Thank you for the detailed goal system. We are rejecting this version for now because it bypasses an important approval boundary.

• The background service approves command, file, permission, and plan requests (server.ts:947-1003, server.ts:1903-1908).
• Worker and verifier threads use full permissions (lib/collab.ts:515-544, lib/collab.ts:633-652).
• SDK 0.4.16 also rejects the old experimental_statusLabels field during activation.

Please remove automatic approval. A clear setting can enable it, but the setting must stay off by default. Please restrict verifier permissions and publish a compatible tag.

[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.

[braedonsaunders]

Thanks. Auto-approve by default was the miss. Next pass will keep that off unless you turn it on, restrict verifier permissions, and publish a tag the current SDK will take.

[braedonsaunders]

Fixed and released as v0.18.0. All three points, plus one you didn't hit yet.

Automatic approval is now off by default. You were right, and I've removed the behaviour rather than defended it. The background service no longer resolves anything unless autoApproveAgentRequests is explicitly turned on; with it off the approval pulse short-circuits and does no work at all, so every command, file-change, permission and plan request reaches the owner exactly as it would without this plugin installed. The setting's description says plainly that it crosses an approval boundary on the user's behalf and should stay off unless they are deliberately running unattended. User questions were never answered automatically and still are not.

Spawned threads no longer default to full permissions. New workerPermissionMode setting, default auto, so a worker's risky actions still go through the normal approval gate. An unrecognised value falls back to auto rather than to whatever was intended — a typo must not be a way to hand an agent full access — and there's a unit test pinning that.

Verifiers are restricted and, deliberately, not configurable. They are hardcoded to auto with no setting to raise them. A verifier inspects a worktree and reports; it never needs to write, and a verifier that can edit the work it is judging can make its own verdict come true. That felt like the wrong thing to leave as an operator's choice.

experimental_statusLabels is gone — 17 occurrences across server.ts and lib/collab.ts. Activation works on SDK 0.4.16.

One more thing I found while preparing this, which is why the entry file changed too: the entry pinned "range": "^0.4.2", and a caret range on a 0.x version is pinned to that minor, so it could never resolve 0.18.0. Merging as it stood would have installed an old tag that still carries every defect you named. It now reads ^0.18.0.

Ready for another look whenever you have time.

[braedonsaunders]

Bumped the entry to ^0.20.3. The review fixes are unchanged and still in place — this is later work found while running the plugin hard, and two of them matter for anyone else adopting it:

• v0.20.1 — root transfer required the target thread to be codex/gpt-5.6-sol xhigh fast/full. One vendor and one model name hardcoded into a plugin whose whole premise is provider neutrality, and it made the transfer useless in the exact situation it exists for: when a root dies because ITS provider is unavailable, the only permitted rescue thread was one on that same provider. What must hold is that the target can be a root — same project, not a child, not archived, idle — all of which was already checked. A provider change is now logged, not refused.
• v0.20.3 — the transfer waited for the source root to reach idle, and an errored thread never does, so it froze and re-running froze again. A root whose provider ran out of quota is already released. A source still running is still waited out.
• v0.20.2 — a worker's own managed worktree no longer blocks a transfer. One agent per slice means each worker has its own environment by design, so that check refused every transfer once a single worker had been staffed.
• v0.19.x — the plugin now reclaims a slice's worktree once its work is merged, instead of leaving them to accumulate, and shares node_modules by reference where the filesystem supports it.

Each of the three transfer fixes was necessary and none was sufficient alone; the goal stayed stuck until all three landed. Found the hard way, on a live goal whose orchestrator had died.

[braedonsaunders]

Entry now resolves ^0.20.4.

One fix in that release is worth calling out for anyone else running a long goal, because it fails silently and I only found it by measuring token spend rather than by anything going visibly wrong.

Root transfer was dropping goal-scoped state. It moves items, findings, decisions, agents, reservations and worker caps — every table that existed when it was written — and silently left behind three added since: the standing worker brief, the per-item completion floors, and the staffing holds. Those stayed keyed to the source root. On a live goal that root was then deleted, so a 3,485-character brief, 28 requires floors and 6 holds went with it. The goal kept running, workers kept being staffed, and nothing reported a thing.

The visible symptom was cost, not failure: without their standing rules, workers re-derived the repository from scratch every slice — bb status, git log, ls, cat package.json, printenv, docker ps, docker info — and one was setting up its own PostgreSQL, which is the first rule of the brief it never received.

Each of the three moves is guarded rather than assumed, because these tables are created at their use sites and a database predating one must still transfer.

Also in this range, all found while running the plugin against a real goal: 0.20.1 removed a hardcoded codex/gpt-5.6-sol requirement on the transfer target, 0.20.2 stopped a worker's own managed worktree from blocking a transfer, 0.20.3 allows transferring off a root that has errored, and 0.20.0 exposes the worker/verifier execution pin on the CLI — that pin was previously only visible in the right-pane settings, and a goal ran 99 workers on an unintended provider before an exhausted quota made it obvious.