@happyvertical/smrt-ingestion 0.57.22 → 0.57.23

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/PROPOSALS.md CHANGED
@@ -180,6 +180,64 @@ The SDK adapter constrains replies with a `json_schema` response format built
180
180
  from the validator's schema and the fixed instructions describe the shape; a
181
181
  custom `ProposalGenerator` receives no schema, so its raw reply meets the
182
182
  validator directly and the same reason is recorded.
183
+ The provider-facing schema is made portable (`portableResponseSchema`, #4260):
184
+ keywords that common OpenAI-compatible structured-output backends reject are
185
+ removed at schema positions, including inside handler argument schemas
186
+ (`uniqueItems`, `contains`, `multipleOf`, `format`, `patternProperties`,
187
+ `propertyNames`, `min`/`maxProperties`, `not`, `if`/`then`/`else`,
188
+ `dependent*`, `unevaluated*`, and the `default`/`examples` annotations; the
189
+ full list and reasons are in `src/proposal-sdk.ts`). With `uniqueItems`, for
190
+ example, vLLM's xgrammar feature check flags the schema, its auto mode routes
191
+ it to llguidance, and llguidance answers
192
+ `400 Grammar error: Unimplemented keys: ["uniqueItems"]`. This only loosens the
193
+ grammar: the validator still enforces the constraints, including unique
194
+ `alternatives` and `missingFields`, and the fixed instructions ask for distinct
195
+ entries. The exception is `format`, which is advisory: the validator runs Ajv
196
+ with `validateFormats: false`, so `format` is enforced nowhere. When
197
+ `patternProperties` is removed, the same object's `additionalProperties` is
198
+ removed too, so the grammar does not shrink to `{}`. The `contentSchema` annotation is omitted as well, so nested unsupported
199
+ constraints cannot leak through an unvisited schema position. A backend may
200
+ recursively inspect typed schema-like objects even inside `enum` or `const`
201
+ data. When such data contains an unsupported keyword, the whole containing
202
+ `enum`/`const` constraint is omitted conservatively; literal data is never
203
+ rewritten. Harmless property names and ordinary enum/const data stay intact.
204
+ The original validator remains authoritative for omitted literal constraints.
205
+ There is no automatic `json_object` fallback.
206
+
207
+ Invariant: the provider copy only ever accepts a superset of what the original
208
+ accepts. Each removed keyword is a conjunct, so removing it only widens. The two
209
+ places where removal would narrow are rewritten:
210
+ - every `oneOf` becomes `anyOf` (or joins an existing `anyOf` through `allOf`),
211
+ because loosened `oneOf` branches could both match and reject a value the
212
+ original accepted;
213
+ - an object that loses `patternProperties` also loses `additionalProperties`.
214
+
215
+ Provider-only `$ref`, `$dynamicRef`, and `$recursiveRef` constraints are also
216
+ removed. Rewriting or deleting a subschema can invalidate pointer or anchor
217
+ targets, including targets inside nested `$id` resources. Dropping references
218
+ conservatively widens the grammar without resolving untrusted schema resources;
219
+ property names and enum/const data named `$ref` remain unchanged. Referenced
220
+ constraints, recursion, and dynamic scope remain enforced by the original
221
+ validator, so provider guidance for reference-based arguments is less precise.
222
+
223
+ The validator still checks the original, including `oneOf` exclusivity. A
224
+ property-style regression checks original-valid ⇒ portable-valid across the
225
+ removed keywords. Handler argument schemas may still carry `allOf` through
226
+ unchanged; its support across backends is unverified, so check such a handler
227
+ against the deployed backend.
228
+
229
+ A generator call that throws ends the attempt as `provider_error` with the
230
+ `unavailable` warning and `provenance.failure` `{category: 'unavailable',
231
+ reason}`. The reason is value-free by construction: a provider's own text can
232
+ quote the prompt or document, so it is never copied. The reason is built only
233
+ from a fixed phrase and, for an SDK `AIError` only, the HTTP status (from a
234
+ structured field, or from the exact `<status> ...` / `TypeSafe request failed
235
+ (<status>): ...` shapes the SDK produces), the SDK error code (from the closed
236
+ list of codes the SDK raises) and, for a schema rejection, quoted tokens that
237
+ are JSON Schema keywords. Any other error contributes at most a structured
238
+ numeric status. For example: `provider rejected the response schema (HTTP 400,
239
+ code API_ERROR); unsupported response-schema keywords: uniqueItems`, or just
240
+ `provider call failed`. It is cut at 500 characters.
183
241
 
184
242
  `createSDKProposalDecisionClient(client)` adapts an existing SDK client’s optional
185
243
  capability without changing its errors or protocol. Optional `decision` uses public core `executeDecision` and the existing SDK
@@ -2,7 +2,7 @@
2
2
  "version": "1.0.0",
3
3
  "timestamp": 0,
4
4
  "packageName": "@happyvertical/smrt-ingestion",
5
- "packageVersion": "0.57.22",
5
+ "packageVersion": "0.57.23",
6
6
  "objects": {
7
7
  "@happyvertical/smrt-ingestion:IntakeItem": {
8
8
  "name": "intakeitem",