[gradyzhuo]

Account gains workspace, and pin(id:to:) sets it. The host's own pin — which account a workspace uses — moves to the plugin that owns the accounts it names.

public struct Account {
    public let id: AccountID
    public let name: String
    public let email: String?
    public let plan: String?
    public let workspace: String?   // new
}

// on Account, not on the tool:
func pin(to workspace: String) async throws                 // new

Why pinning is not part of setCurrent

They answer different questions:

current	which account is designated right now
a pin	where this account belongs

A pin survives the current one changing, and a test says so. Scoping current by workspace instead — current(in:) — would leave "which account is current" with no answer until the caller also said where, and that plain question is exactly what a host asks. Keeping them apart costs one method and leaves both answerable.

Why the account carries it, not a table

It is one workspace per account, so the account is where the relation belongs. A host that wants the accounts of one workspace filters a listing it already has:

try await tool.list().filter { $0.workspace == "origin" }

So the reverse lookup needs no second method — this lands at six methods rather than seven.

nil means not pinned, and there is no default

"origin", "main", "default" are all host vocabulary. A framework that shipped one would be taking a side in a naming decision that is not its own.

workspace crosses as an opaque string: the plugin records it without knowing what a workspace is, the same way it already accepts a directory path without knowing what the host keeps in it.

On the wire

An explicit null when absent, like email and plan. A missing key cannot be told apart from a reply that lost one, and "pinned nowhere" is a state a host renders differently from "unknown".

Account is now a protocol

It shipped as a struct in dev.10 and should not have. The rule for this package is that a foundation type is a protocol, for the reason AITool is one: holding only properties today does not mean nothing will ever need behaviour, and a struct forces a breaking change the first time one does. Putting workspace on it is what surfaced the miss.

The pattern is the one AITool and ToolDescription already set:

public protocol Account: Sendable {
    var id: AccountID { get }
    var name: String { get }
    var email: String? { get }      // defaulted
    var plan: String? { get }       // defaulted
    var workspace: String? { get }  // defaulted
}

public struct AccountRecord: Account, Codable, Equatable { … }

The smallest conformer supplies id and name. A test pins that, because a defaults extension nobody exercises stops being real and the protocol then buys nothing over a struct. AccountRecord is the concrete Codable type the protocol deliberately is not — a protocol cannot be Decodable, because decoding has to know what to build.

Codable and Equatable live on the record, so any Account has neither. That is the cost, and it is the right side of the trade: a forwarding proxy can conform without carrying values it does not have.

Operations live on Account

pin(to:) came first, and the rest follow it: setCurrent(id:) becomes makeCurrent(), deleteAccount(id:) becomes delete().

The rule is legible in the shape now — anything done to an account is on the account, because a caller doing one of those is already holding it, and a verb(id:) on the tool asked it to name the thing in its hand.

public protocol Account: Sendable {
    var id: AccountID { get }
    var name: String { get }
    var email: String? { get }      // defaulted
    var plan: String? { get }       // defaulted
    var workspace: String? { get }  // defaulted

    func pin(to workspace: String) async throws
    func makeCurrent() async throws
    func delete() async throws
}

public protocol AIToolAccounts: AITool {
    func list() async throws -> [any Account]
    func current() async throws -> (any Account)?
    func addAccount(id: AccountID, name: String) async throws -> any Account
}

What stays on the tool is what only the tool can answer. list() and current() are questions about the tool, and current() can legitimately have no answer, which an account-side method could not express. addAccount stays because there is nothing to call a method on until it has been made.

"No such account" stops being an operation error. You cannot act on an account you are not holding, so failing to find one is a lookup that failed, earlier and somewhere else — in PluginServer, resolving the wire's id. That is now the single place it arises, and the wire tests still cover it for all three operations.

This is the protocol earning its keep. An Account that only carried properties could have been a struct; behaviour arriving on it is exactly the case a struct would have turned into a breaking change.

AccountRecord therefore stops conforming to Account, matching ToolDescription, which has never conformed to AITool. A decoded value has nothing to pin with — no store, no connection — so a record that conformed would answer pin(to:) by failing, which is a conformance that lies. The types that conform are the ones that can act: a plugin's own account, and a host-side proxy holding the connection back to it. The in-suite pool now models that, holding a view onto its store rather than a detached copy.

pin(to:) gets no default. One that did nothing would tell a host the pin was recorded; one that threw would hide the decision from whoever wrote the conformer. Identity fields still default, so the smallest conformer is two properties and this method.

The wire keeps tool/pin, since a request has to name an account. The server resolves the id against list() and asks that account to pin itself.

Verification

126 tests pass, and swift build -Xswiftc -strict-concurrency=complete -Xswiftc -warnings-as-errors is clean. Both wire tests were checked for discrimination — dropping workspace from the encoder fails them immediately, which is the mistake worth guarding against since the field is optional and its absence looks legitimate.

Note for the sibling PR

PR #1 adds a test that pins the advertised capability set exactly. When it lands, tool/pin goes in that list.

🤖 Generated with Claude Code