@wildo-ai/external-connectors-models 1.1.2 → 1.1.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/esm/.native.tsbuildinfo +1 -0
- package/dist/esm/companion-exports.d.ts.map +1 -1
- package/dist/esm/core/commons.external-connectors-models.schemas.d.ts +45 -7
- package/dist/esm/core/commons.external-connectors-models.schemas.d.ts.map +1 -1
- package/dist/esm/core/commons.external-connectors-models.schemas.js +42 -5
- package/dist/esm/core/commons.external-connectors-models.schemas.js.map +1 -1
- package/dist/esm/core/operation-classification.external-connectors-models.schemas.d.ts +13 -0
- package/dist/esm/core/operation-classification.external-connectors-models.schemas.d.ts.map +1 -0
- package/dist/esm/core/operation-classification.external-connectors-models.schemas.js +14 -0
- package/dist/esm/core/operation-classification.external-connectors-models.schemas.js.map +1 -0
- package/dist/esm/core/protocols.external-connectors-models.schemas.d.ts +0 -25
- package/dist/esm/core/protocols.external-connectors-models.schemas.d.ts.map +1 -1
- package/dist/esm/core/protocols.external-connectors-models.schemas.js.map +1 -1
- package/dist/esm/core/security.external-connectors-models.schemas.d.ts +132 -2
- package/dist/esm/core/security.external-connectors-models.schemas.d.ts.map +1 -1
- package/dist/esm/core/security.external-connectors-models.schemas.js +164 -0
- package/dist/esm/core/security.external-connectors-models.schemas.js.map +1 -1
- package/dist/esm/index.d.ts +3 -9
- package/dist/esm/index.d.ts.map +1 -1
- package/dist/esm/index.js +6 -10
- package/dist/esm/index.js.map +1 -1
- package/dist/esm/protocols/agent-client-protocol.external-connectors-models.schemas.d.ts +251 -4
- package/dist/esm/protocols/agent-client-protocol.external-connectors-models.schemas.d.ts.map +1 -1
- package/dist/esm/protocols/agent-client-protocol.external-connectors-models.schemas.js +307 -2
- package/dist/esm/protocols/agent-client-protocol.external-connectors-models.schemas.js.map +1 -1
- package/dist/esm/protocols/billing.standard-interface.schemas.d.ts +154 -0
- package/dist/esm/protocols/billing.standard-interface.schemas.d.ts.map +1 -1
- package/dist/esm/protocols/billing.standard-interface.schemas.js +49 -0
- package/dist/esm/protocols/billing.standard-interface.schemas.js.map +1 -1
- package/dist/esm/protocols/document-extraction.external-connectors-models.schemas.d.ts +72 -0
- package/dist/esm/protocols/document-extraction.external-connectors-models.schemas.d.ts.map +1 -1
- package/dist/esm/protocols/document-extraction.external-connectors-models.schemas.js +77 -2
- package/dist/esm/protocols/document-extraction.external-connectors-models.schemas.js.map +1 -1
- package/dist/esm/protocols/email.external-connectors-models.schemas.d.ts +1 -1
- package/dist/esm/protocols/email.external-connectors-models.schemas.d.ts.map +1 -1
- package/dist/esm/protocols/email.standard-interface.schemas.d.ts.map +1 -1
- package/dist/esm/protocols/embeddings.external-connectors-models.schemas.d.ts.map +1 -1
- package/dist/esm/protocols/frontend.external-connectors-models.schemas.d.ts.map +1 -1
- package/dist/esm/{features/hooks.external-connectors-models.schemas.d.ts → protocols/hooks-capability.external-connectors-models.schemas.d.ts} +1 -1
- package/dist/esm/protocols/hooks-capability.external-connectors-models.schemas.d.ts.map +1 -0
- package/dist/esm/{features/hooks.external-connectors-models.schemas.js → protocols/hooks-capability.external-connectors-models.schemas.js} +1 -1
- package/dist/esm/protocols/hooks-capability.external-connectors-models.schemas.js.map +1 -0
- package/dist/esm/protocols/hooks.external-connectors-models.schemas.d.ts.map +1 -1
- package/dist/esm/protocols/image.external-connectors-models.schemas.d.ts.map +1 -1
- package/dist/esm/protocols/llm.external-connectors-models.schemas.d.ts +36 -19
- package/dist/esm/protocols/llm.external-connectors-models.schemas.d.ts.map +1 -1
- package/dist/esm/protocols/llm.external-connectors-models.schemas.js +90 -28
- package/dist/esm/protocols/llm.external-connectors-models.schemas.js.map +1 -1
- package/dist/esm/protocols/oauth2.external-connectors-models.schemas.d.ts +2 -2
- package/dist/esm/protocols/oauth2.external-connectors-models.schemas.d.ts.map +1 -1
- package/dist/esm/protocols/rest-api.external-connectors-models.schemas.d.ts +1 -89
- package/dist/esm/protocols/rest-api.external-connectors-models.schemas.d.ts.map +1 -1
- package/dist/esm/protocols/rest-api.external-connectors-models.schemas.js +1 -83
- package/dist/esm/protocols/rest-api.external-connectors-models.schemas.js.map +1 -1
- package/dist/esm/protocols/rest-operations.external-connectors-models.schemas.d.ts +370 -0
- package/dist/esm/protocols/rest-operations.external-connectors-models.schemas.d.ts.map +1 -0
- package/dist/esm/protocols/rest-operations.external-connectors-models.schemas.js +89 -0
- package/dist/esm/protocols/rest-operations.external-connectors-models.schemas.js.map +1 -0
- package/dist/esm/protocols/sms.external-connectors-models.schemas.d.ts.map +1 -1
- package/dist/esm/protocols/sms.standard-interface.schemas.d.ts +66 -6
- package/dist/esm/protocols/sms.standard-interface.schemas.d.ts.map +1 -1
- package/dist/esm/protocols/sms.standard-interface.schemas.js +71 -1
- package/dist/esm/protocols/sms.standard-interface.schemas.js.map +1 -1
- package/dist/tsconfig.build.tsbuildinfo +1 -1
- package/package.json +2 -2
- package/dist/esm/features/core.external-connectors-models.schemas.d.ts +0 -63
- package/dist/esm/features/core.external-connectors-models.schemas.d.ts.map +0 -1
- package/dist/esm/features/core.external-connectors-models.schemas.js +0 -101
- package/dist/esm/features/core.external-connectors-models.schemas.js.map +0 -1
- package/dist/esm/features/email.external-connectors-models.schemas.d.ts +0 -181
- package/dist/esm/features/email.external-connectors-models.schemas.d.ts.map +0 -1
- package/dist/esm/features/email.external-connectors-models.schemas.js +0 -34
- package/dist/esm/features/email.external-connectors-models.schemas.js.map +0 -1
- package/dist/esm/features/hooks.external-connectors-models.schemas.d.ts.map +0 -1
- package/dist/esm/features/hooks.external-connectors-models.schemas.js.map +0 -1
- package/dist/esm/features/sms.external-connectors-models.schemas.d.ts +0 -21
- package/dist/esm/features/sms.external-connectors-models.schemas.d.ts.map +0 -1
- package/dist/esm/features/sms.external-connectors-models.schemas.js +0 -8
- package/dist/esm/features/sms.external-connectors-models.schemas.js.map +0 -1
- package/dist/esm/protocols/a2a.external-connectors-models.schemas.d.ts +0 -57
- package/dist/esm/protocols/a2a.external-connectors-models.schemas.d.ts.map +0 -1
- package/dist/esm/protocols/a2a.external-connectors-models.schemas.js +0 -73
- package/dist/esm/protocols/a2a.external-connectors-models.schemas.js.map +0 -1
- package/dist/esm/protocols/git.external-connectors-models.schemas.d.ts +0 -14
- package/dist/esm/protocols/git.external-connectors-models.schemas.d.ts.map +0 -1
- package/dist/esm/protocols/git.external-connectors-models.schemas.js +0 -9
- package/dist/esm/protocols/git.external-connectors-models.schemas.js.map +0 -1
- package/dist/esm/protocols/grpc.external-connectors-models.schemas.d.ts +0 -14
- package/dist/esm/protocols/grpc.external-connectors-models.schemas.d.ts.map +0 -1
- package/dist/esm/protocols/grpc.external-connectors-models.schemas.js +0 -9
- package/dist/esm/protocols/grpc.external-connectors-models.schemas.js.map +0 -1
- package/dist/esm/protocols/mcp.external-connectors-models.schemas.d.ts +0 -60
- package/dist/esm/protocols/mcp.external-connectors-models.schemas.d.ts.map +0 -1
- package/dist/esm/protocols/mcp.external-connectors-models.schemas.js +0 -35
- package/dist/esm/protocols/mcp.external-connectors-models.schemas.js.map +0 -1
- package/dist/esm/protocols/saml.external-connectors-models.schemas.d.ts +0 -135
- package/dist/esm/protocols/saml.external-connectors-models.schemas.d.ts.map +0 -1
- package/dist/esm/protocols/saml.external-connectors-models.schemas.js +0 -9
- package/dist/esm/protocols/saml.external-connectors-models.schemas.js.map +0 -1
|
@@ -99,10 +99,19 @@ export var AgentClientProtocol_WorkingDirectoryPolicy;
|
|
|
99
99
|
* what lets an application say "no session started from this profile may ever
|
|
100
100
|
* skip the permission gate" independently of what any individual run requests.
|
|
101
101
|
*
|
|
102
|
-
* Ordering is meaningful and increasing: PROMPT_ALWAYS <
|
|
102
|
+
* Ordering is meaningful and increasing over all FIVE members: PROMPT_ALWAYS <
|
|
103
|
+
* AUTO_ACCEPT_READS < AUTO_ACCEPT_EDITS < AUTO_ACCEPT_READS_AND_EDITS <
|
|
103
104
|
* UNRESTRICTED. Compare through {@link agentClientProtocolPermissionCeilingRank}
|
|
104
105
|
* rather than by string, so the ordering has one definition.
|
|
106
|
+
*
|
|
107
|
+
* Read that order as a CLAMP — how much is pre-approved without a human — and never
|
|
108
|
+
* as containment. The ceilings are kind-SETS and are deliberately not nested:
|
|
109
|
+
* AUTO_ACCEPT_EDITS outranks AUTO_ACCEPT_READS and still refuses `fetch`, which is
|
|
110
|
+
* exactly why AUTO_ACCEPT_READS_AND_EDITS had to be added rather than being implied
|
|
111
|
+
* by the higher rank. Each member's own docstring states the set it admits, and the
|
|
112
|
+
* rank function carries the full argument for why containment is the wrong reading.
|
|
105
113
|
*/
|
|
114
|
+
/** @wildo_source:part:start acp.permission-ceiling facet:layer:config facet:audience:app-developer */
|
|
106
115
|
export var AgentClientProtocol_PermissionCeiling;
|
|
107
116
|
(function (AgentClientProtocol_PermissionCeiling) {
|
|
108
117
|
/**
|
|
@@ -168,9 +177,36 @@ export var AgentClientProtocol_PermissionCeiling;
|
|
|
168
177
|
* can fetch anything and write only its evidence directory.
|
|
169
178
|
*/
|
|
170
179
|
AgentClientProtocol_PermissionCeiling["AUTO_ACCEPT_READS_AND_EDITS"] = "auto_accept_reads_and_edits";
|
|
171
|
-
/**
|
|
180
|
+
/**
|
|
181
|
+
* No permission gate: every tool kind is pre-approved, `execute` and the unclassified `other`
|
|
182
|
+
* included. Reserve for a disposable or isolated workspace.
|
|
183
|
+
*
|
|
184
|
+
* **This member also removes the task's mutation scope for shell commands, and that is a property
|
|
185
|
+
* of shell commands rather than of this value.** The scope predicate runs AFTER the ceiling and
|
|
186
|
+
* denies any location the task did not authorise even here — so declared file EDITS stay confined.
|
|
187
|
+
* But it decides on the `locations` a permission request carries, and a shell command carries
|
|
188
|
+
* NONE, because what a command writes is not derivable from the command string. Every ceiling
|
|
189
|
+
* below this one refuses `execute` outright, so the empty-location case never reaches the
|
|
190
|
+
* predicate; under this one it does, and `locations.some(...)` over an empty array is vacuously
|
|
191
|
+
* satisfied. A mutating command therefore reaches the workspace inside a complete, well-formed
|
|
192
|
+
* permission record showing it was allowed.
|
|
193
|
+
*
|
|
194
|
+
* Not closable by deriving a scope from the command: any parse is defeated by `sh -c "$CMD"` or a
|
|
195
|
+
* redirect through a substituted path, and an invented scope that can be walked around is worse
|
|
196
|
+
* than a stated absence. So the residual exposure under this member is exactly "shell commands are
|
|
197
|
+
* unbounded", the answer to it is git plus the post-run change set, and the companion WARNS on
|
|
198
|
+
* every run whose mutation followed a permitted act that declared no location — which is how it
|
|
199
|
+
* stops being invisible. Author this member to state that plainly; do not author it expecting the
|
|
200
|
+
* mutation scope to hold for commands.
|
|
201
|
+
*
|
|
202
|
+
* Note this is a DIFFERENT hole from an agent that never asks (see
|
|
203
|
+
* {@link AgentClientProtocol_PermissionEscalationBehaviour}): that one costs you both guards for
|
|
204
|
+
* every act, and dispatch refuses a narrower ceiling against such an agent. This one costs you the
|
|
205
|
+
* scope guard for one act kind, against a fully compliant agent.
|
|
206
|
+
*/
|
|
172
207
|
AgentClientProtocol_PermissionCeiling["UNRESTRICTED"] = "unrestricted";
|
|
173
208
|
})(AgentClientProtocol_PermissionCeiling || (AgentClientProtocol_PermissionCeiling = {}));
|
|
209
|
+
/** @wildo_source:part:end acp.permission-ceiling */
|
|
174
210
|
/**
|
|
175
211
|
* Increasing rank for {@link AgentClientProtocol_PermissionCeiling}; the single ordering definition.
|
|
176
212
|
*
|
|
@@ -204,6 +240,105 @@ export function agentClientProtocolPermissionCeilingRank(ceiling) {
|
|
|
204
240
|
return 4;
|
|
205
241
|
}
|
|
206
242
|
}
|
|
243
|
+
/**
|
|
244
|
+
* Whether THIS agent raises `session/request_permission` before it mutates —
|
|
245
|
+
* the one property that decides whether Wildo's in-flight guards can fire at all.
|
|
246
|
+
*
|
|
247
|
+
* # Why a permission ceiling needs this to mean anything
|
|
248
|
+
*
|
|
249
|
+
* Both of Wildo's in-flight controls are enforced in the CLIENT's ANSWER to a
|
|
250
|
+
* permission request: {@link AgentClientProtocol_PermissionCeiling} decides the
|
|
251
|
+
* tool KIND, and the dispatch's location predicate decides the PATHS. Neither is
|
|
252
|
+
* a sandbox, an interposed filesystem, or a syscall filter — they are answers.
|
|
253
|
+
* So an agent that writes without asking is bound by neither, and the ceiling
|
|
254
|
+
* an application authored is a LABEL rather than a guarantee.
|
|
255
|
+
*
|
|
256
|
+
* That is not hypothetical and it is not a fault in the agents. MEASURED with
|
|
257
|
+
* `wildo acp probe`:
|
|
258
|
+
*
|
|
259
|
+
* - Codex (`@agentclientprotocol/codex-acp`, 2026-09-06) raises nothing before
|
|
260
|
+
* an in-workspace write in ANY of its three modes, including with an explicit
|
|
261
|
+
* `approval_policy = "untrusted"`. Its safety model is a SANDBOX, so an
|
|
262
|
+
* in-workspace write is safe by ITS construction and there is nothing to ask
|
|
263
|
+
* about. A different architecture, not a defect.
|
|
264
|
+
* - OpenCode (1.18.27, 2026-09-04/05) does the same under its DEFAULT
|
|
265
|
+
* configuration, and escalates correctly when pointed at a permission
|
|
266
|
+
* configuration file. So for that agent the answer is conditional on
|
|
267
|
+
* something the HOST supplies.
|
|
268
|
+
* - Claude's adapter (`@agentclientprotocol/claude-agent-acp` 0.73.0) raises,
|
|
269
|
+
* and both guards fire.
|
|
270
|
+
*
|
|
271
|
+
* # Why it is DECLARED rather than inferred, and why it is required
|
|
272
|
+
*
|
|
273
|
+
* It cannot be inferred before a run: an agent that never asks and an agent that
|
|
274
|
+
* had nothing to ask about are indistinguishable from an empty decision list, and
|
|
275
|
+
* by the time the list is empty the workspace has already been mutated. The
|
|
276
|
+
* post-run change set remains the authoritative account of what a run touched —
|
|
277
|
+
* this declaration is what lets the framework say, BEFORE the run, whether that
|
|
278
|
+
* change set is the only account there will be.
|
|
279
|
+
*
|
|
280
|
+
* The provider declares it because the provider is the party that ran the probe.
|
|
281
|
+
* It is REQUIRED on the runtime contract for the same reason `modelDelivery` is:
|
|
282
|
+
* this lane has now shipped three safety-relevant fields that were authored,
|
|
283
|
+
* documented and read by nothing (`hostConfigurationInheritance`, the model
|
|
284
|
+
* channel, the provider's inherited environment). An author who cannot ship the
|
|
285
|
+
* gap is better than one who discovers it on a dispatched run.
|
|
286
|
+
*
|
|
287
|
+
* It is a CLAIM, never an alibi. The companion still judges each completed run
|
|
288
|
+
* from that run's OWN permission decisions and change set, so an agent whose
|
|
289
|
+
* behaviour changes between versions cannot keep a stale, reassuring declaration.
|
|
290
|
+
*/
|
|
291
|
+
/** @wildo_source:part:start acp.permission-escalation facet:layer:config facet:audience:app-developer */
|
|
292
|
+
export var AgentClientProtocol_PermissionEscalationBehaviour;
|
|
293
|
+
(function (AgentClientProtocol_PermissionEscalationBehaviour) {
|
|
294
|
+
/**
|
|
295
|
+
* The agent escalates before mutating, so the ceiling and the mutation scope
|
|
296
|
+
* are both enforceable in flight. The only value under which a ceiling
|
|
297
|
+
* narrower than UNRESTRICTED means what it says.
|
|
298
|
+
*/
|
|
299
|
+
AgentClientProtocol_PermissionEscalationBehaviour["RAISES_BEFORE_MUTATION"] = "raises_before_mutation";
|
|
300
|
+
/**
|
|
301
|
+
* The agent escalates ONLY when the host points it at a permission
|
|
302
|
+
* configuration it does not adopt by default.
|
|
303
|
+
*
|
|
304
|
+
* The configuration is therefore not hardening — it is the condition under
|
|
305
|
+
* which the agent may be dispatched with a gate at all, and the variable that
|
|
306
|
+
* carries the pointer is named on the contract so the dispatch can CHECK that
|
|
307
|
+
* a profile supplies it instead of trusting a docstring that says it must.
|
|
308
|
+
*/
|
|
309
|
+
AgentClientProtocol_PermissionEscalationBehaviour["RAISES_ONLY_UNDER_HOST_CONFIGURATION"] = "raises_only_under_host_configuration";
|
|
310
|
+
/**
|
|
311
|
+
* The agent never escalates before mutating, under any configuration this
|
|
312
|
+
* framework can supply. Its own safety model is elsewhere (a sandbox), and
|
|
313
|
+
* Wildo's in-flight guards are inert for it by construction — the post-run
|
|
314
|
+
* change set is the only account of what it touched.
|
|
315
|
+
*/
|
|
316
|
+
AgentClientProtocol_PermissionEscalationBehaviour["NEVER_RAISES"] = "never_raises";
|
|
317
|
+
})(AgentClientProtocol_PermissionEscalationBehaviour || (AgentClientProtocol_PermissionEscalationBehaviour = {}));
|
|
318
|
+
/** @wildo_source:part:end acp.permission-escalation */
|
|
319
|
+
/**
|
|
320
|
+
* Can Wildo's in-flight permission ceiling and mutation-scope predicate fire for
|
|
321
|
+
* this agent, as it will actually be started?
|
|
322
|
+
*
|
|
323
|
+
* The single definition of that question, so the dispatch's refusal, the run's
|
|
324
|
+
* recorded metadata and any operator-facing report cannot disagree about it.
|
|
325
|
+
*
|
|
326
|
+
* `escalationConfigurationSupplied` answers only the conditional member: it is
|
|
327
|
+
* whether the composed child environment will actually carry the pointer the
|
|
328
|
+
* contract names. Deliberately a parameter rather than something this function
|
|
329
|
+
* reads, because the environment is composed by the dispatch and a predicate
|
|
330
|
+
* that guessed at it would be a second, quieter answer.
|
|
331
|
+
*/
|
|
332
|
+
export function agentClientProtocolInFlightGuardsCanFire(behaviour, escalationConfigurationSupplied) {
|
|
333
|
+
switch (behaviour) {
|
|
334
|
+
case AgentClientProtocol_PermissionEscalationBehaviour.RAISES_BEFORE_MUTATION:
|
|
335
|
+
return true;
|
|
336
|
+
case AgentClientProtocol_PermissionEscalationBehaviour.RAISES_ONLY_UNDER_HOST_CONFIGURATION:
|
|
337
|
+
return escalationConfigurationSupplied;
|
|
338
|
+
case AgentClientProtocol_PermissionEscalationBehaviour.NEVER_RAISES:
|
|
339
|
+
return false;
|
|
340
|
+
}
|
|
341
|
+
}
|
|
207
342
|
/**
|
|
208
343
|
* How much of the HOST MACHINE's agent configuration a session inherits.
|
|
209
344
|
*
|
|
@@ -220,6 +355,7 @@ export function agentClientProtocolPermissionCeilingRank(ceiling) {
|
|
|
220
355
|
* application teaches the agent to use its framework. What it should not
|
|
221
356
|
* silently absorb is whoever happens to be logged in.
|
|
222
357
|
*/
|
|
358
|
+
/** @wildo_source:part:start acp.host-configuration-inheritance facet:layer:config facet:audience:app-developer */
|
|
223
359
|
export var AgentClientProtocol_HostConfigurationInheritance;
|
|
224
360
|
(function (AgentClientProtocol_HostConfigurationInheritance) {
|
|
225
361
|
/** No filesystem-sourced agent configuration. The prompt is the whole instruction. */
|
|
@@ -238,12 +374,79 @@ export var AgentClientProtocol_HostConfigurationInheritance;
|
|
|
238
374
|
*/
|
|
239
375
|
AgentClientProtocol_HostConfigurationInheritance["HOST_INHERITED"] = "host_inherited";
|
|
240
376
|
})(AgentClientProtocol_HostConfigurationInheritance || (AgentClientProtocol_HostConfigurationInheritance = {}));
|
|
377
|
+
/** @wildo_source:part:end acp.host-configuration-inheritance */
|
|
378
|
+
/** @wildo_source:part:start acp.execution-profile facet:layer:config facet:audience:app-developer */
|
|
379
|
+
/**
|
|
380
|
+
* WHERE a coding run's content actually goes, per MODEL (issue #308, join 2).
|
|
381
|
+
*
|
|
382
|
+
* An ACP coding session sends the composed task prompt, retrieved context and — through the agent's
|
|
383
|
+
* own file reads — the application's SOURCE CODE to the selected model vendor. For an application
|
|
384
|
+
* built with Wildo that can include the customer's domain model, schemas, seed data shapes and
|
|
385
|
+
* business rules. So the destination is a processor-register fact, not a runtime detail.
|
|
386
|
+
*
|
|
387
|
+
* ## Why this is per MODEL and not per provider
|
|
388
|
+
*
|
|
389
|
+
* A generalist agent routes to several vendors, so its OWN legal identity is not the identity of the
|
|
390
|
+
* vendor a given run reaches: OpenCode is a binary on the host, and the same profile can send code to
|
|
391
|
+
* Anthropic or to OpenAI depending on one model id. A per-provider declaration structurally cannot
|
|
392
|
+
* express that — it would name the agent's publisher as the recipient of code the publisher never
|
|
393
|
+
* receives, which is false in the direction a reader cannot check.
|
|
394
|
+
*
|
|
395
|
+
* ## Why it lives on the EXECUTION PROFILE
|
|
396
|
+
*
|
|
397
|
+
* The profile is already where an application authors the policy it owns, and the model is selected at
|
|
398
|
+
* dispatch time against that profile. The competing home — `providerComplianceChoices`, where every
|
|
399
|
+
* other compliance answer lives — cannot carry it: that surface is keyed by provider ref and has one
|
|
400
|
+
* entry per provider, which is exactly the shape that cannot say "per model".
|
|
401
|
+
*
|
|
402
|
+
* `ApplicationProviderComplianceChoice` warns against putting a compliance answer somewhere "nothing
|
|
403
|
+
* can read it without knowing the provider", and `providerConfigurations` is genuinely an opaque
|
|
404
|
+
* `Record<string, unknown>` bag. That objection is answered rather than ignored:
|
|
405
|
+
* {@link readCodingModelDestinations} is the named reader, exported beside this schema, and the
|
|
406
|
+
* compliance renderer calls it instead of reaching into the bag and guessing a shape. The hazard the
|
|
407
|
+
* warning names is a fact nobody can FIND; a named reader is what removes it.
|
|
408
|
+
*/
|
|
409
|
+
export const AgentClientProtocol_ModelDestinationSchema = z.object({
|
|
410
|
+
/**
|
|
411
|
+
* The legal entity that receives the code — the model vendor, NOT the agent's publisher.
|
|
412
|
+
*
|
|
413
|
+
* Required, because a destination that cannot be named is not a destination a processor register can
|
|
414
|
+
* state. There is no framework default: the framework does not know which account an operator
|
|
415
|
+
* authorised, and inventing one would publish a recipient nobody declared.
|
|
416
|
+
*/
|
|
417
|
+
vendorLegalEntityName: z.string().trim().min(1),
|
|
418
|
+
/**
|
|
419
|
+
* Where that vendor processes it.
|
|
420
|
+
*
|
|
421
|
+
* Open strings for the same reason `ProviderComplianceProfile.processingRegions` uses them: these
|
|
422
|
+
* are the VENDOR's own labels and a closed enum here would be this repository inventing a
|
|
423
|
+
* vocabulary it does not own.
|
|
424
|
+
*/
|
|
425
|
+
processingRegions: z.array(z.string().trim().min(1)).min(1),
|
|
426
|
+
/**
|
|
427
|
+
* The INTERMEDIARY, when the run reaches the vendor through one (issue #308, join 3).
|
|
428
|
+
*
|
|
429
|
+
* A hosted gateway — OpenCode Zen, an Anthropic-compatible proxy reached through a base-URL
|
|
430
|
+
* override — receives the content before the vendor does. It is therefore its own processor and must
|
|
431
|
+
* appear as a sub-processor DISTINCT from the vendor behind it: naming only the vendor understates
|
|
432
|
+
* the chain by one party, and naming only the gateway understates it by the other.
|
|
433
|
+
*
|
|
434
|
+
* Absent means the run reaches the vendor directly. That is a claim, not a silence — declaring a
|
|
435
|
+
* destination at all is what makes it one.
|
|
436
|
+
*/
|
|
437
|
+
gateway: z.object({
|
|
438
|
+
legalEntityName: z.string().trim().min(1),
|
|
439
|
+
processingRegions: z.array(z.string().trim().min(1)).min(1),
|
|
440
|
+
}).optional(),
|
|
441
|
+
}).strict();
|
|
442
|
+
/** @wildo_source:part:end acp.execution-profile */
|
|
241
443
|
/**
|
|
242
444
|
* One authored way to start an ACP agent.
|
|
243
445
|
*
|
|
244
446
|
* Mirrors the shape a provider's execution profiles have always had: the
|
|
245
447
|
* spawnable command plus the policy that decides whether it may run at all.
|
|
246
448
|
*/
|
|
449
|
+
/** @wildo_source:part:start acp.execution-profile facet:layer:config facet:audience:app-developer */
|
|
247
450
|
export const AgentClientProtocol_ExecutionProfileSchema = z.object({
|
|
248
451
|
runnerHost: z.enum(AgentClientProtocol_RunnerHost).default(AgentClientProtocol_RunnerHost.BACKEND_SUBPROCESS),
|
|
249
452
|
/**
|
|
@@ -329,6 +532,16 @@ export const AgentClientProtocol_ExecutionProfileSchema = z.object({
|
|
|
329
532
|
* reporting loss; losing the run is a work loss.
|
|
330
533
|
*/
|
|
331
534
|
maximumRecordedEventBytes: z.number().int().positive().optional(),
|
|
535
|
+
/**
|
|
536
|
+
* Per-model processing destinations — see {@link AgentClientProtocol_ModelDestinationSchema}.
|
|
537
|
+
*
|
|
538
|
+
* OPTIONAL, and its absence is REPORTED rather than refused. A stale framework region list must not
|
|
539
|
+
* be able to brick an application build, and an operator who has just moved a vendor should be able
|
|
540
|
+
* to say so before the framework catches up — the same warn-do-not-block posture
|
|
541
|
+
* `appAssertedProcessingRegions` already takes for provider regions. The compliance brief names a
|
|
542
|
+
* coding profile that declares none, so the gap is visible without being fatal.
|
|
543
|
+
*/
|
|
544
|
+
modelDestinations: z.record(z.string().trim().min(1), AgentClientProtocol_ModelDestinationSchema).optional(),
|
|
332
545
|
/**
|
|
333
546
|
* Opaque, agent-specific options passed as `_meta` on `session/new`.
|
|
334
547
|
*
|
|
@@ -396,6 +609,7 @@ export const AgentClientProtocol_ExecutionProfileSchema = z.object({
|
|
|
396
609
|
});
|
|
397
610
|
}
|
|
398
611
|
});
|
|
612
|
+
/** @wildo_source:part:end acp.execution-profile */
|
|
399
613
|
/**
|
|
400
614
|
* Transport capability metadata for an ACP-speaking provider.
|
|
401
615
|
*
|
|
@@ -663,6 +877,32 @@ export const AgentClientProtocol_ExecutionTransportMetadataSchema = z.object({
|
|
|
663
877
|
* which of the agent's modes that became.
|
|
664
878
|
*/
|
|
665
879
|
sessionModeId: z.string().optional(),
|
|
880
|
+
/**
|
|
881
|
+
* Whether the agent this run started DECLARES that it escalates before
|
|
882
|
+
* mutating, and whether Wildo's in-flight guards could therefore fire.
|
|
883
|
+
*
|
|
884
|
+
* Recorded on the run because the ceiling alone no longer explains the run:
|
|
885
|
+
* `permissionCeiling: PROMPT_ALWAYS` against an agent that never asks and
|
|
886
|
+
* against one that always asks describe two completely different runs, and
|
|
887
|
+
* nothing else in this metadata tells them apart. A later reader looking at a
|
|
888
|
+
* change set needs to know whether anything stood between the agent and it.
|
|
889
|
+
*
|
|
890
|
+
* Optional because the declaration is a provider fact and a run recorded
|
|
891
|
+
* before this field existed genuinely has no answer — absence must not read as
|
|
892
|
+
* `false`, which would assert an unbound run that may have been fully bound.
|
|
893
|
+
*/
|
|
894
|
+
permissionEscalation: z.enum(AgentClientProtocol_PermissionEscalationBehaviour).optional(),
|
|
895
|
+
/**
|
|
896
|
+
* The resolved answer for THIS run, from
|
|
897
|
+
* {@link agentClientProtocolInFlightGuardsCanFire} — the declared behaviour
|
|
898
|
+
* combined with whether the composed environment actually supplied the
|
|
899
|
+
* configuration a conditionally-escalating agent needs.
|
|
900
|
+
*
|
|
901
|
+
* Kept beside the behaviour rather than derived by each reader, because the
|
|
902
|
+
* conditional member cannot be resolved from the behaviour alone and a reader
|
|
903
|
+
* that tried would answer `true` for an agent that was dispatched unconfigured.
|
|
904
|
+
*/
|
|
905
|
+
inFlightPermissionGuardsCanFire: z.boolean().optional(),
|
|
666
906
|
/** The ACP session, retained so a later turn can resume or fork it. */
|
|
667
907
|
sessionId: z.string().optional(),
|
|
668
908
|
});
|
|
@@ -789,4 +1029,69 @@ export const CodingAgent_RunTaskOutputSchema = z.object({
|
|
|
789
1029
|
*/
|
|
790
1030
|
suspension: CodingAgent_SessionSuspensionSchema.optional(),
|
|
791
1031
|
});
|
|
1032
|
+
/**
|
|
1033
|
+
* Read per-model coding destinations out of an application's provider configurations.
|
|
1034
|
+
*
|
|
1035
|
+
* ## Why this function exists at all
|
|
1036
|
+
*
|
|
1037
|
+
* `providerConfigurations` is `Record<string, Record<string, unknown>>` — genuinely opaque, and
|
|
1038
|
+
* `ApplicationProviderComplianceChoice` warns for that reason that "a compliance answer must not live
|
|
1039
|
+
* somewhere nothing can read it without knowing the provider". The destination has to live there
|
|
1040
|
+
* anyway (it is per MODEL, and no per-provider surface can hold it), so the objection is answered by
|
|
1041
|
+
* making the reader NAMED and exported beside the schema instead of leaving each consumer to reach in
|
|
1042
|
+
* and guess a shape. A compliance renderer calls this; it never parses the bag.
|
|
1043
|
+
*
|
|
1044
|
+
* ## What it does with malformed input
|
|
1045
|
+
*
|
|
1046
|
+
* SKIPS it, silently, and this is deliberate rather than lax. The function's job is to report what an
|
|
1047
|
+
* application declared, and it is called from a compliance BRIEF — a lane that must not fail because
|
|
1048
|
+
* one provider's opaque configuration has an unexpected shape. A profile whose destinations do not
|
|
1049
|
+
* parse contributes nothing and therefore surfaces in `profilesWithoutDestinations`, which is the
|
|
1050
|
+
* honest reading: nothing usable was declared.
|
|
1051
|
+
*
|
|
1052
|
+
* Nothing is lost by that leniency, because a malformed profile is ALREADY refused where it matters:
|
|
1053
|
+
* `getAgentClientProtocolExecutionProfile` parses every profile through
|
|
1054
|
+
* {@link AgentClientProtocol_ExecutionProfileSchema} when a run resolves one, and throws
|
|
1055
|
+
* `ErrorType.CONFIGURATION` naming the provider and profile. So a bad destination fails the CODING RUN
|
|
1056
|
+
* loudly, with an author present, while the compliance brief still reports the other twenty providers.
|
|
1057
|
+
* Two surfaces, two correct answers — and note that the profile schema is `.strict()`, so before
|
|
1058
|
+
* `modelDestinations` existed as a declared field an application COULD NOT have authored it at all.
|
|
1059
|
+
*/
|
|
1060
|
+
export function readCodingModelDestinations(
|
|
1061
|
+
/*
|
|
1062
|
+
* `unknown` per value, not `Record<string, unknown>`, because that is what the bag genuinely is at
|
|
1063
|
+
* every consumer — `ProviderConfigurations` types each entry as optional and the companion's own
|
|
1064
|
+
* local view types it as `unknown`. Declaring a narrower parameter would push a cast onto every
|
|
1065
|
+
* caller, which is how a reader written to STOP callers guessing a shape starts making them assert
|
|
1066
|
+
* one.
|
|
1067
|
+
*/
|
|
1068
|
+
providerConfigurations) {
|
|
1069
|
+
const destinations = [];
|
|
1070
|
+
const profilesWithoutDestinations = [];
|
|
1071
|
+
for (const providerRef of Object.keys(providerConfigurations).sort()) {
|
|
1072
|
+
const providerConfiguration = providerConfigurations[providerRef];
|
|
1073
|
+
if (providerConfiguration === null || typeof providerConfiguration !== 'object')
|
|
1074
|
+
continue;
|
|
1075
|
+
const acpConfiguration = providerConfiguration[ExternalProvider_ExchangeProtocol_Kind.AGENT_CLIENT_PROTOCOL];
|
|
1076
|
+
if (acpConfiguration === null || typeof acpConfiguration !== 'object')
|
|
1077
|
+
continue;
|
|
1078
|
+
const profiles = acpConfiguration.executionProfiles;
|
|
1079
|
+
if (profiles === null || typeof profiles !== 'object')
|
|
1080
|
+
continue;
|
|
1081
|
+
for (const executionProfileRef of Object.keys(profiles).sort()) {
|
|
1082
|
+
const profile = profiles[executionProfileRef];
|
|
1083
|
+
const declared = profile?.modelDestinations;
|
|
1084
|
+
const parsed = z.record(z.string().trim().min(1), AgentClientProtocol_ModelDestinationSchema)
|
|
1085
|
+
.safeParse(declared);
|
|
1086
|
+
if (!parsed.success || Object.keys(parsed.data).length === 0) {
|
|
1087
|
+
profilesWithoutDestinations.push({ providerRef, executionProfileRef });
|
|
1088
|
+
continue;
|
|
1089
|
+
}
|
|
1090
|
+
for (const model of Object.keys(parsed.data).sort()) {
|
|
1091
|
+
destinations.push({ providerRef, executionProfileRef, model, destination: parsed.data[model] });
|
|
1092
|
+
}
|
|
1093
|
+
}
|
|
1094
|
+
}
|
|
1095
|
+
return { destinations, profilesWithoutDestinations };
|
|
1096
|
+
}
|
|
792
1097
|
//# sourceMappingURL=agent-client-protocol.external-connectors-models.schemas.js.map
|