@telorun/kernel 0.72.0 → 0.74.0

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.
Files changed (39) hide show
  1. package/dist/application-env.js +2 -2
  2. package/dist/application-env.js.map +1 -1
  3. package/dist/controllers/module/import-controller.d.ts.map +1 -1
  4. package/dist/controllers/module/import-controller.js +1 -0
  5. package/dist/controllers/module/import-controller.js.map +1 -1
  6. package/dist/invocation-contract-binding.d.ts +37 -1
  7. package/dist/invocation-contract-binding.d.ts.map +1 -1
  8. package/dist/invocation-contract-binding.js +109 -8
  9. package/dist/invocation-contract-binding.js.map +1 -1
  10. package/dist/kernel.d.ts.map +1 -1
  11. package/dist/kernel.js +14 -3
  12. package/dist/kernel.js.map +1 -1
  13. package/dist/manifest-schemas.js +2 -2
  14. package/dist/manifest-schemas.js.map +1 -1
  15. package/dist/observed-state.js +2 -2
  16. package/dist/observed-state.js.map +1 -1
  17. package/dist/resource-context.d.ts.map +1 -1
  18. package/dist/resource-context.js +2 -5
  19. package/dist/resource-context.js.map +1 -1
  20. package/dist/runtime-seam.d.ts.map +1 -1
  21. package/dist/runtime-seam.js +24 -4
  22. package/dist/runtime-seam.js.map +1 -1
  23. package/dist/schema-compiled-values.d.ts.map +1 -1
  24. package/dist/schema-compiled-values.js +25 -1
  25. package/dist/schema-compiled-values.js.map +1 -1
  26. package/dist/schema-validator.d.ts.map +1 -1
  27. package/dist/schema-validator.js +20 -35
  28. package/dist/schema-validator.js.map +1 -1
  29. package/package.json +4 -4
  30. package/src/application-env.ts +2 -2
  31. package/src/controllers/module/import-controller.ts +1 -0
  32. package/src/invocation-contract-binding.ts +120 -8
  33. package/src/kernel.ts +17 -3
  34. package/src/manifest-schemas.ts +2 -2
  35. package/src/observed-state.ts +2 -2
  36. package/src/resource-context.ts +2 -5
  37. package/src/runtime-seam.ts +29 -3
  38. package/src/schema-compiled-values.ts +28 -1
  39. package/src/schema-validator.ts +19 -35
@@ -7,7 +7,8 @@ import { createHash } from "node:crypto";
7
7
  import * as fs from "node:fs";
8
8
  import { createRequire } from "node:module";
9
9
  import * as path from "node:path";
10
- import { binaryKeyword, X_TELO_BINARY } from "@telorun/analyzer";
10
+ import { registerTeloKeywords } from "@telorun/analyzer";
11
+ import { X_TELO_TYPE } from "@telorun/sdk";
11
12
  import { mergeFilledDefaults, withBigIntsAsNumbers } from "./bigint-schema-view.js";
12
13
  import { formatAjvErrors } from "./manifest-schemas.js";
13
14
 
@@ -25,7 +26,6 @@ import {
25
26
  EXACT_TEMPLATE_REGEX,
26
27
  isTaggedSentinel,
27
28
  ManifestRootSchema,
28
- normalizeRefSlots,
29
29
  } from "@telorun/templating";
30
30
 
31
31
  const Ajv = AjvModule.default ?? AjvModule;
@@ -165,13 +165,19 @@ const NAME_KEYED_SCHEMA_KEYWORDS = new Set([
165
165
  const DATA_VALUE_KEYWORDS = new Set(["const", "default", "enum", "examples"]);
166
166
 
167
167
  /** Annotations that DO emit validation code, and so must survive the strip and stay
168
- * in the cache key. `x-telo-binary` is the first: bytes have no JSON Schema type,
168
+ * in the cache key. `x-telo-type` is the only one: bytes have no JSON Schema type,
169
169
  * so the keyword is the only thing standing between a byte slot and "accepts any
170
170
  * object". Stripping it would silently reduce the slot to an empty schema — the
171
171
  * precise regression the annotation was introduced to close — and, because the key
172
172
  * is meant to describe the compiled validator, a keyword that changes the validator
173
- * belongs in it. */
174
- const VALIDATING_ANNOTATIONS = new Set([X_TELO_BINARY]);
173
+ * belongs in it.
174
+ *
175
+ * Its names need no canonicalization to be safe in a key, unlike `x-telo-ref`'s:
176
+ * the vocabulary is closed and `Telo.`-qualified, so an author writes the
177
+ * canonical name or none, and a named SHAPE reaches the annotation as a `$ref`
178
+ * the loader already resolved. There is nothing here that the analyzer's baked
179
+ * view and the runtime could spell differently. */
180
+ const VALIDATING_ANNOTATIONS = new Set([X_TELO_TYPE]);
175
181
 
176
182
  /** Deep-clone `schema` without its `x-telo-*` annotations — applied, like
177
183
  * {@link collapseSentinelsToSource}, before both AJV compilation and cache
@@ -193,9 +199,7 @@ const VALIDATING_ANNOTATIONS = new Set([X_TELO_BINARY]);
193
199
  *
194
200
  * Stripping is what makes the key describe the compiled validator and nothing
195
201
  * else, so the two views converge without either side having to agree on an
196
- * annotation's spelling. `normalizeRefSlots` runs FIRST and is unaffected: it
197
- * reads `x-telo-ref` to drop a legacy scalar `type` at a ref slot, which does
198
- * change validation, and it has already done so by the time this runs. */
202
+ * annotation's spelling. */
199
203
  function stripTeloAnnotations(value: unknown, nameKeyed = false): unknown {
200
204
  // An array's items are schema nodes (`allOf`, tuple `items`), never names.
201
205
  if (Array.isArray(value)) return value.map((item) => stripTeloAnnotations(item));
@@ -258,27 +262,12 @@ export class SchemaValidator {
258
262
  code: { source: true },
259
263
  });
260
264
  addFormats.default(this.ajv);
261
- for (const kw of [
262
- "x-telo-ref",
263
- "x-telo-eval",
264
- "x-telo-scope",
265
- "x-telo-context",
266
- "x-telo-context-from",
267
- "x-telo-context-ref-from",
268
- "x-telo-schema-from",
269
- "x-telo-topology-role",
270
- "x-telo-step-context",
271
- "x-telo-widget",
272
- "x-telo-type",
273
- "x-telo-inline",
274
- ]) {
275
- this.ajv.addKeyword(kw);
276
- }
277
- // Not a no-op like the rest: bytes have no JSON Schema type, so this keyword IS
278
- // the check. Defined as codegen in the analyzer so it inlines into the
279
- // standalone validators compiled and cached below, rather than needing the
280
- // implementation present at load.
281
- this.ajv.addKeyword(binaryKeyword());
265
+ // One registration site for every Telo keyword: the annotations as no-ops
266
+ // and `x-telo-type` as the one that actually checks. `x-telo-type` is defined
267
+ // as codegen in the analyzer so it inlines into the standalone validators
268
+ // compiled and cached below, rather than needing the implementation present
269
+ // at load.
270
+ registerTeloKeywords(this.ajv);
282
271
  // Register the shared manifest root so module schemas can
283
272
  // `$ref: "telo://manifest#/$defs/ResourceRef"` without each manifest
284
273
  // bundling its own copy. Mirrors the analyzer's createAjv().
@@ -361,12 +350,7 @@ export class SchemaValidator {
361
350
  }
362
351
  : normalized;
363
352
 
364
- // Drop the legacy scalar `type` an older published module may still pin on
365
- // its `x-telo-ref` slots. Schema validation runs in create() before Phase 5
366
- // injection, so a ref slot holds the resolved `{kind, name, alias?}` object
367
- // (or an unresolved sentinel) — both objects the stale `type: "string"`
368
- // would otherwise reject.
369
- const injected = normalizeRefSlots(withImplicit) as typeof withImplicit;
353
+ const injected = withImplicit;
370
354
 
371
355
  // Canonicalize CEL/template carriers (an inline `${{ }}` left in a
372
356
  // `description`, a `!cel` tag, …) to their bare source text so AJV can