Add createExternalResource agent tool

[ndisidore]

Adds the createExternalResource tool as discussed with respect to Google Drive: rather than granting whole-Drive access so the agent can make one document, the agent creates a new resource of a creatable type through an already-connected account.

This adds the other half of requestConnection: the agent mints a brand-new resource of a type the vendor marks creatable, through an account the user already connected. The binding is live immediately (simliar to what createGadget does), the turn continues, and the gatekeeper simulates the resource until the user approves the creation, which queues first and applies first, so dependent edits are safe to stack behind it.

Auto approval is not supported yet.

First consumer is Google Doc creation, stacked as #428

[github-actions]

Preview: pr427-nathan-create-f79af453

https://pr427-nathan-create-f79af453-router.cloudflare-os-previews.workers.dev

Dashboard · deleted when this PR closes

[ndisidore]

so createExternalResource is the one tool where a "failure" is just a normal string result the model reads and retries on
every other tool gets away with a dumb count label because the error machinery covers their failures separately. we can't just set tc.error on rejections either - the tool call itself succeeded, it returned guidance the model is supposed to act on, and flagging that as an error would paint the designed fix-and-retry flow red like something broke.
so if we did "created 2 external resources" when one was actually rejected, the group header would straight up lie about the thing the user is being asked to approve - hence this one case counts successes

open to other options here

[ask-bonk]

Findings

1. High: Creation-only steps return false because no "changes" message was written, despite committing the tool call. The deferred restart is therefore skipped, leaving the new gatekeeper permanently quarantined whenever a build collaborator is connected. Track barrier success separately from change materialization. packages/workshop-backend/src/overseer.ts:3843

github run

[ask-bonk]

Findings

1. High: Rejected creations remain in build-collaborator verification scope. ACL-based gatekeepers will reject verification for the nonexistent resource, preventing collaborators from reopening the workspace. Persist a terminal state and exclude it from observer requirements. packages/workshop-backend/src/overseer.ts:11611

2. Medium: Chat deletion can remove a newly committed creation before deleting chatMeta. A crash in that window leaves replay restoring a binding to a deleted gatekeeper. Use a durable deletion tombstone or atomic lifecycle transition. packages/workshop-backend/src/overseer.ts:2745

3. Low: Automatic cleanup marks queued actions as user-rejected, so history displays “Denied” despite no user decision, contradicting ActionState semantics. Remove or distinguish system-cancelled actions. packages/workshop-backend/src/overseer.ts:5573

github run

[ask-bonk]

Findings

1. High: The first action queued during initialization is blindly marked as the creation action. Since the record is already accessible, a concurrent session can queue another action first, corrupting approval, rejection, refresh, and recovery behavior. Block sessions until submitCreationAction() establishes the real creation action. packages/workshop-backend/src/overseer.ts:6054

2. High: Rejected creations are excluded from collaborator verification while their gatekeeper remains accessible. A new build collaborator can call getGatekeeperById().openSession() without addObserver() verification; Gatekeeper.rejectAction() does not guarantee future sessions are disabled. Explicitly reject sessions for rejected creations. packages/workshop-backend/src/overseer.ts:9557

3. Low: Missing resolvedBy also applies to legacy user-denied actions, so these are now incorrectly labeled “Cancelled.” Add an explicit system-cancellation discriminator instead. packages/workshop-frontend/src/Activity.tsx:102

github run