AgentSpec exposes type:oauth setup field but no oauth_providers descriptor field

[Weegy]

Zusammenfassung

Die Plugin-Runtime-Surface PluginContext.oauthTokens (Spec 005) ist im Boilerplate-types.ts vorhanden und laut JSDoc gilt:

Present iff the manifest declares a type:oauth setup field + an oauth_providers descriptor AND the core ships the broker.

Die AgentSpec (Builder-Draft-Schema) erlaubt zwar ein setup_fields[]-Entry mit type: "oauth", kennt aber kein Feld, um den dazugehörigen oauth_providers-Descriptor (provider, authorization_url, token_url, scopes) zu deklarieren. Damit kann der Builder den OAuth-Broker-Flow nicht vollständig verdrahten — ctx.oauthTokens bliebe zur Laufzeit undefined.

Repro-Steps

1. Neuer Agent, Template agent-integration.
2. patch_spec setzt ein OAuth-Setup-Field:

   { "op": "add", "path": "/setup_fields/-", "value": {
     "key": "gmail_oauth", "type": "oauth", "label": "Gmail-Konto verbinden", "required": true } }

   → akzeptiert.
3. Setup-Field mit provider/scopes anreichern:

   { "op": "add", "path": "/setup_fields/-", "value": {
     "key": "gmail_oauth", "type": "oauth", "provider": "google", "scopes": [...] } }

   → Zod-Fail: Unrecognized keys: "provider", "scopes" — allowed keys: key, type, required, description, default, enum_values, label, placeholder, help
4. Descriptor auf Top-Level versuchen:

   { "op": "add", "path": "/oauth_providers", "value": [ { "field_key": "gmail_oauth", "provider": "google", "authorization_url": "...", "token_url": "...", "scopes": [...] } ] }

   → Zod-Fail: Unrecognized key: "oauth_providers" — allowed keys at this path: template, id, name, ..., quality, persona, multi_instance, ...

Erwartung

Entweder ein Top-Level-Spec-Feld oauth_providers[] (field_key → provider/authorization_url/token_url/scopes), oder Provider-/Scope-Subfelder direkt am type:oauth-Setup-Field. Sonst ist type:oauth ein toter Pfad: das Feld lässt sich anlegen, aber der Broker nie scharf schalten.

Impact

Jeder selbst-enthaltene OAuth2-Agent (Gmail, Google Calendar, jede Drittanbieter-API ohne eigene Integration) muss auf den Refresh-Token-als-Secret-Workaround ausweichen — der den refresh-Token in Plugin-Code holt, was Spec 005 gerade vermeiden wollte.

Workaround (in diesem Build verwendet)

Client/Secret/Refresh-Token als drei Secrets (gmail_client_id, gmail_client_secret, gmail_refresh_token); Client refresht den Access-Token selbst gegen oauth2.googleapis.com/token via ctx.http.

Spec-Snapshot (relevant)

{
  "id": "@omadia/agent-gmail-summary",
  "setup_fields": [{ "key": "gmail_oauth", "type": "oauth", "required": true }],
  "network": { "outbound": ["gmail.googleapis.com"] }
}