typekro 0.43.0 → 0.44.1

package/dist/core/serialization/kro-post-processing.d.ts

@@ -1,46 +0,0 @@
-/**
- * KRO YAML Post-Processing Utilities
- *
- * Shared helpers for applying ternary conditionals to resource data before
- * YAML serialization. Used by both the toResourceGraph pipeline (core.ts)
- * and the KRO factory deployment path (kro-factory.ts).
- *
- * Extracted to avoid circular dependencies between core.ts and kro-factory.ts.
- *
- * Note: KRO 0.9+ omit() wrapping for optional fields is NOT in this module —
- * it's applied inline during ref-to-CEL conversion via
- * `SerializationContext.omitFields` in `cel-references.ts`. That keeps
- * `has() ? ... : omit()` generation as a structured operation on
- * KubernetesRef objects instead of a post-hoc regex rewrite of the
- * serialized YAML string.
- */
-/**
- * Apply ternary conditionals to resource data by replacing raw marker sections
- * with CEL conditional expressions. This runs BEFORE processResourceReferences
- * so that the markers within the truthy branch get converted to mixed-template
- * CEL format by the normal pipeline.
- *
- * For `spec.redisUrl ? \`redis:\n  url: ${spec.redisUrl}\` : ''`, the raw
- * settings.yml string contains the redis section with a __KUBERNETES_REF__
- * marker. This function replaces that section with a CEL conditional that
- * processResourceReferences will then convert to the final mixed-template form.
- *
- * FRAGILE: operates on raw string values inside resource data by substring
- * matching. The `proxySection` must be byte-identical to what was extracted
- * by `extractTernaryConditionals` in schema.ts — meaning the composition's
- * string construction (typically a template literal) and the re-execution
- * pass both need to produce the same newline/indentation layout. If a
- * composition author post-processes the settings string, interpolates it
- * through another templating layer, or if the extraction heuristic in
- * schema.ts is updated to include/exclude different surrounding context,
- * the match will fail silently and the ternary will not be applied.
- *
- * Tracked for replacement with AST-based detection in
- * https://github.com/yehudacohen/typekro/issues/57
- */
-export declare function applyTernaryConditionalsToResources(resources: Record<string, unknown>, conditionals: Array<{
-    proxySection: string;
-    falsyValue: string;
-    conditionField: string;
-}>, nestedStatusCel?: Record<string, string>): void;
-//# sourceMappingURL=kro-post-processing.d.ts.map

package/dist/core/serialization/kro-post-processing.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"kro-post-processing.d.ts","sourceRoot":"","sources":["../../../src/core/serialization/kro-post-processing.ts"],"names":[],"mappings":"AAQA;;;;;;;;;;;;;;;GAeG;AAEH;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,wBAAgB,mCAAmC,CACjD,SAAS,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EAClC,YAAY,EAAE,KAAK,CAAC;IAAE,YAAY,EAAE,MAAM,CAAC;IAAC,UAAU,EAAE,MAAM,CAAC;IAAC,cAAc,EAAE,MAAM,CAAA;CAAE,CAAC,EACzF,eAAe,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,GACvC,IAAI,CA8BN"}

package/dist/core/serialization/status-analysis-pipeline.d.ts

@@ -1,67 +0,0 @@
-/**
- * Status analysis pipeline — decomposed from analyzeAndConvertStatusMappings
- *
- * The original function was a 9-step pipeline with 3 layers of swallowed
- * try/catch fallbacks, making it the single hardest function to maintain.
- *
- * This module decomposes it into explicit, named pipeline stages. Each stage
- * returns a `StageResult<T>` carrying success/failure/degraded state.
- * Degradation is logged at warn level (not debug), making silent failures loud.
- *
- * Pipeline stages:
- *   1. executeStatusBuilder — run the status builder in KubernetesRef context
- *   2. detectCompositionMode — read internal source metadata (imperative vs declarative)
- *   3. analyzeStatusMappingsForMode — route to imperative or declarative analysis
- *   4. categorizeFields — run analyzeStatusMappingTypes on the result
- *   5. detectExistingCel — detect and preserve backward-compat CEL expressions
- *   6. convertRefsTocel — convert KubernetesRef objects to CEL via CelConversionEngine
- *   7. mergeResults — 3-way merge of converted/preserved/raw mappings
- *   8. logMigrationOpportunities — (side effect) log CEL→JS migration suggestions
- *
- * @see ROADMAP.md Phase 2.9
- */
-import type { getComponentLogger } from '../logging/index.js';
-import type { DeploymentClosure } from '../types/deployment.js';
-import type { MagicAssignableShape, ResourceGraphDefinition, SchemaProxy } from '../types/serialization.js';
-import type { Enhanced, KroCompatibleType } from '../types.js';
-import { analyzeStatusMappingTypes } from './status-analysis-helpers.js';
-/**
- * The outcome of a pipeline stage.
- *
- * - `success`: Stage completed normally with a value.
- * - `degraded`: Stage failed but produced a fallback value. The pipeline continues.
- * - `failure`: Stage failed with no usable value (rare — most stages degrade instead).
- */
-export type StageOutcome = 'success' | 'degraded' | 'failure';
-export interface StageResult<T> {
-    outcome: StageOutcome;
-    value: T;
-    /** Human-readable reason for degradation/failure */
-    reason?: string;
-}
-type PipelineLogger = ReturnType<ReturnType<typeof getComponentLogger>['child']>;
-/**
- * Result of the status analysis pipeline.
- *
- * Same shape as the original `StatusAnalysisResult` for backward compatibility.
- */
-export interface StatusAnalysisPipelineResult {
-    statusMappings: MagicAssignableShape<KroCompatibleType>;
-    analyzedStatusMappings: Record<string, unknown>;
-    mappingAnalysis: ReturnType<typeof analyzeStatusMappingTypes>;
-    imperativeAnalysisSucceeded: boolean;
-    /** Raw Phase B fn.toString results (before merge filtering). Available when
-     *  Phase B ran for an imperative composition. Used by nested composition
-     *  status extraction to recover CEL from garbled fn.toString output. */
-    phaseBStatusMappings?: Record<string, unknown> | undefined;
-}
-/**
- * Run the full status analysis pipeline.
- *
- * This is the decomposed replacement for the original
- * `analyzeAndConvertStatusMappings` function. Each stage is explicit,
- * degradation is logged at warn level, and the flow is traceable.
- */
-export declare function runStatusAnalysisPipeline<TSpec extends KroCompatibleType, TStatus extends KroCompatibleType, TResources extends Record<string, Enhanced<unknown, unknown> | DeploymentClosure>>(definition: ResourceGraphDefinition<TSpec, TStatus>, statusBuilder: (schema: SchemaProxy<TSpec, TStatus>, resources: TResources) => MagicAssignableShape<TStatus>, schema: SchemaProxy<TSpec, TStatus>, resourcesWithKeys: Record<string, Enhanced<unknown, unknown>>, logger: PipelineLogger): StatusAnalysisPipelineResult;
-export {};
-//# sourceMappingURL=status-analysis-pipeline.d.ts.map

package/dist/core/serialization/status-analysis-pipeline.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"status-analysis-pipeline.d.ts","sourceRoot":"","sources":["../../../src/core/serialization/status-analysis-pipeline.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;GAqBG;AAkBH,OAAO,KAAK,EAAE,kBAAkB,EAAE,MAAM,qBAAqB,CAAC;AAC9D,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,wBAAwB,CAAC;AAChE,OAAO,KAAK,EACV,oBAAoB,EACpB,uBAAuB,EACvB,WAAW,EACZ,MAAM,2BAA2B,CAAC;AAEnC,OAAO,KAAK,EAAE,QAAQ,EAAE,iBAAiB,EAAE,MAAM,aAAa,CAAC;AAC/D,OAAO,EACL,yBAAyB,EAG1B,MAAM,8BAA8B,CAAC;AAMtC;;;;;;GAMG;AACH,MAAM,MAAM,YAAY,GAAG,SAAS,GAAG,UAAU,GAAG,SAAS,CAAC;AAE9D,MAAM,WAAW,WAAW,CAAC,CAAC;IAC5B,OAAO,EAAE,YAAY,CAAC;IACtB,KAAK,EAAE,CAAC,CAAC;IACT,oDAAoD;IACpD,MAAM,CAAC,EAAE,MAAM,CAAC;CACjB;AAcD,KAAK,cAAc,GAAG,UAAU,CAAC,UAAU,CAAC,OAAO,kBAAkB,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC;AAskBjF;;;;GAIG;AACH,MAAM,WAAW,4BAA4B;IAC3C,cAAc,EAAE,oBAAoB,CAAC,iBAAiB,CAAC,CAAC;IACxD,sBAAsB,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC;IAChD,eAAe,EAAE,UAAU,CAAC,OAAO,yBAAyB,CAAC,CAAC;IAC9D,2BAA2B,EAAE,OAAO,CAAC;IACrC;;4EAEwE;IACxE,oBAAoB,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,GAAG,SAAS,CAAC;CAC5D;AAED;;;;;;GAMG;AACH,wBAAgB,yBAAyB,CACvC,KAAK,SAAS,iBAAiB,EAC/B,OAAO,SAAS,iBAAiB,EACjC,UAAU,SAAS,MAAM,CAAC,MAAM,EAAE,QAAQ,CAAC,OAAO,EAAE,OAAO,CAAC,GAAG,iBAAiB,CAAC,EAEjF,UAAU,EAAE,uBAAuB,CAAC,KAAK,EAAE,OAAO,CAAC,EACnD,aAAa,EAAE,CACb,MAAM,EAAE,WAAW,CAAC,KAAK,EAAE,OAAO,CAAC,EACnC,SAAS,EAAE,UAAU,KAClB,oBAAoB,CAAC,OAAO,CAAC,EAClC,MAAM,EAAE,WAAW,CAAC,KAAK,EAAE,OAAO,CAAC,EACnC,iBAAiB,EAAE,MAAM,CAAC,MAAM,EAAE,QAAQ,CAAC,OAAO,EAAE,OAAO,CAAC,CAAC,EAC7D,MAAM,EAAE,cAAc,GACrB,4BAA4B,CA2E9B"}

package/dist/core/validation/cel-dialect.d.ts

@@ -1,246 +0,0 @@
-/**
- * Dual-dialect compatibility check for emitted status CEL.
- *
- * TypeKro emits one CEL expression per dynamic status field and then runs it
- * through **two different engines**: `cel-js` evaluates it locally in direct
- * mode, and `cel-go` (inside the KRO controller, with KRO's type environment)
- * evaluates it in Kro mode. The two disagree in ways that only surface when the
- * expression meets real data on a live cluster — one engine returns a value and
- * the other rejects the expression or blows up on a missing field.
- *
- * This module runs every emitted status expression through cel-js's own parser
- * **and** a curated denylist of the divergences we have confirmed, so an
- * expression that only one engine accepts fails at serialization time with the
- * expression, the status leaf it came from, and the dialect that rejects it.
- *
- * ## cel-js's parser is not the CEL grammar
- *
- * cel-js 0.8.2 parses a proper subset of CEL, so a `parse()` failure is a fact
- * about **direct mode only**. Its `atomicExpression` rule takes a postfix
- * `.`/`[` after an identifier (and after a map literal, and one index after a
- * list literal) and nowhere else, while the spec's `Member` production takes a
- * postfix on any `Member` and `Primary` includes both `LITERAL` and
- * `"(" Expr ")"` — so `"x".size()`, `[1,2].size()`, `(a).b` and `size(a).b` are
- * all valid CEL that cel-js rejects, and its lexer has neither the exponent
- * `FLOAT_LIT` form nor the `r`/`b`/triple-quoted `STRING_LIT` forms. Inferring
- * "cel-go would reject this too" from a cel-js parse failure is therefore
- * unsound, and the parse half does not do it: it sorts a failure into
- * `not-valid-cel` (a form the *spec's* grammar has no token or production for),
- * `cel-js-rejects-spec-cel` (a positively identified cel-js shortfall — a real
- * divergence) or `cel-js-parse-failure` (no verdict beyond direct mode).
- *
- * Identifying a shortfall *somewhere* in a rejected expression is not by itself
- * a divergence, because the parse may have failed for an unrelated reason: the
- * shortfall in `"x".size() +` is real and the expression is still unfinished,
- * and cel-go refuses it exactly as cel-js does. So the divergence bucket is
- * earned rather than assumed — every identified shortfall is rewritten into a
- * spelling of the same spec production that cel-js does have (`"x".size()` into
- * `__typekro_recv0.size()`, `1e3` into `0.0`), the rest of the text is left
- * untouched, and cel-js is asked again. Only a rewrite that parses proves the
- * shortfall was the whole reason; anything else falls to `cel-js-parse-failure`.
- *
- * ## Why a denylist rather than a real cel-go
- *
- * cel-go is a Go library; there is no in-process cel-go for a TypeScript
- * serializer to consult, and shelling out to one would make `toYaml()` depend
- * on a Go toolchain. The denylist is therefore a deliberately *curated*,
- * documented set of confirmed divergences rather than a general type checker.
- * It is meant to grow: each rule below records what was observed and on which
- * engine, so a new entry can be justified the same way.
- *
- * ## What may fail strict mode
- *
- * A rule may fail strict mode only when the two engines genuinely **diverge** on
- * the form: there is data for which one engine yields a value and the other does
- * not. That bar rules out two tempting kinds of rule, and both are deliberately
- * excluded rather than merely unwritten.
- *
- * - **Anything that needs a CEL *type* to be a divergence.** Syntax does not
- *   establish a type. `x[0]` is a list index against one schema and a map lookup
- *   against another; `"k" in e` is fine when `e` is a map and rejected when
- *   cel-go's type env has typed `e` as a message. The real types live in the
- *   referenced resources' Kubernetes schemas, and nothing at this call site has
- *   them: the check receives the serialized status map — expression text naming
- *   graph resources by id — and TypeKro's `Enhanced<>` types are erased before
- *   serialization runs. A rule that guesses a type from bracket shape fails
- *   strict mode on valid CEL, so such rules are reported as notes instead.
- * - **Forms both engines treat the same.** Indexing a required list inside a
- *   logical chain is the worked example: `size(l) > 0 && l[0].f != ""` returns
- *   `false` on an empty `l` in both engines (cel-js short-circuits, cel-go
- *   absorbs the error under a deciding `false`), and an out-of-range index
- *   errors on both. Nothing diverges, so nothing is reported.
- *
- * What the bar does **not** license is a claim about what KRO ultimately does
- * with the field. Every rule here reasons about the grammar and about published
- * engine behaviour; none of them models cel-go's *type checker*, which runs
- * after the parse with KRO's type environment and function set and rejects
- * plenty of grammatical CEL — `1.string()` parses on any conformant grammar and
- * the checker still refuses it, `string` being a global conversion function
- * rather than a member, and an unknown member function goes the same way. So a
- * finding says "direct mode can never evaluate this field" where that is proven,
- * and leaves KRO's verdict open. A rule stays a `divergence` on the strength of
- * the disagreement it does establish: the engines differ on the *form*, at a
- * stage that needs no type environment, which makes the emitted CEL defective
- * for one of the two targets TypeKro serializes for whatever the other decides.
- *
- * Findings that do not clear the bar are still worth surfacing, so each rule
- * declares a {@link CelDialectFindingKind}: `divergence` findings abort
- * serialization in strict mode, `note` findings never do and are logged in both
- * modes. Strictness otherwise follows the shared CEL diagnostics convention
- * (`strictCelDiagnostics` factory option, `TYPEKRO_STRICT_CEL=1`).
- */
-/**
- * The CEL engine that rejects — or diverges on — an expression.
- *
- * `'both'` marks a form neither engine accepts, which is a defect but not a
- * divergence. `'unchecked'` is not an engine at all: it marks a finding where no
- * verdict was reached, because the expression was past the analysis budget.
- */
-export type CelDialect = 'cel-js' | 'cel-go' | 'both' | 'unchecked';
-/**
- * Whether a finding may fail strict mode.
- *
- * - `divergence` — the two engines demonstrably disagree on this form, with no
- *   appeal to a type the checker cannot see. Fails strict mode.
- * - `note` — worth reporting, but not a proven divergence: either both engines
- *   reject the form (a defect, but the same defect on each), or the divergence
- *   is conditional on a type the checker has no way to establish, or no verdict
- *   was reached at all. Never fails strict mode, in either strictness setting.
- */
-export type CelDialectFindingKind = 'divergence' | 'note';
-/** Identifier for a curated dual-dialect rule. */
-export type CelDialectRuleId = 'not-valid-cel' | 'cel-js-rejects-spec-cel' | 'cel-js-parse-failure' | 'has-index-argument' | 'in-on-list-entry' | 'guard-after-use-in-logical-chain' | 'heterogeneous-map-literal' | 'expression-too-large';
-/**
- * Largest expression this module will analyze, in characters.
- *
- * Both halves of the check cost roughly a microsecond per character — cel-js's
- * parser dominates — so the cost is linear in the length of the expression and
- * the only way it can run away is for the expression itself to run away.
- *
- * The budget is set from what TypeKro actually emits. Across the unit suite the
- * median status expression is under 100 characters, the 99th percentile is
- * ~1.6k, and the largest authored one is ~3.3k. 16 KiB leaves roughly five
- * times the headroom over the largest real expression while capping the check
- * at ~16ms for any single leaf.
- *
- * Anything past this is not an authored status field. The known source is a
- * nested composition whose inlined status re-expands into itself, doubling per
- * level until the depth limit stops it — which yields a multi-megabyte
- * expression that no engine can use: cel-js needs seconds to parse it on every
- * direct-mode reconcile, and a ResourceGraphDefinition carrying it is past the
- * Kubernetes object size limit, so the API server refuses it outright.
- */
-export declare const CEL_DIALECT_MAX_EXPRESSION_LENGTH = 16384;
-/** A single dual-dialect incompatibility found in an emitted expression. */
-export interface CelDialectFinding {
-    /** Which curated rule matched. */
-    readonly rule: CelDialectRuleId;
-    /** Whether this finding may fail strict mode. */
-    readonly kind: CelDialectFindingKind;
-    /** The engine that rejects or diverges on this expression. */
-    readonly dialect: CelDialect;
-    /** The status leaf path the expression was emitted for. */
-    readonly field: string;
-    /** The emitted CEL expression. */
-    readonly expression: string;
-    /** The offending fragment, when the rule can isolate one. */
-    readonly fragment?: string;
-    /** What the engine does with it. */
-    readonly message: string;
-    /** How to write it so both engines accept it. */
-    readonly suggestion: string;
-}
-/**
- * The curated denylist.
- *
- * Every entry names the engine that rejects the form, whether the entry counts
- * as a divergence, and the observation behind it. Keep this table and
- * {@link checkCelDialectCompatibility} in step.
- */
-export declare const CEL_DIALECT_RULES: readonly {
-    readonly id: CelDialectRuleId;
-    readonly kind: CelDialectFindingKind;
-    readonly dialect: CelDialect;
-    readonly summary: string;
-    readonly observed: string;
-}[];
-/** True when any finding in the set may fail strict mode. */
-export declare function hasCelDialectDivergence(findings: readonly CelDialectFinding[]): boolean;
-/**
- * What the last run (or runs) of the check cost, in units that do not depend on
- * the machine it ran on.
- *
- * Wall-clock is the wrong instrument for the property that actually matters
- * here — that the work is linear in the length of the expression rather than
- * quadratic in its nesting — because a slow CI box and a quadratic regression
- * look alike. These counters do not: `indexedCharacters` is the total text
- * scanned to build bracket indexes and `lookups` the total number of "where
- * does this close?" questions asked, so doubling the input must roughly double
- * both.
- */
-export interface CelDialectWorkStats {
-    /** How many bracket indexes were built. */
-    readonly indexBuilds: number;
-    /** Total characters scanned across those builds. */
-    readonly indexedCharacters: number;
-    /** Total bracket-match questions answered out of an index. */
-    readonly lookups: number;
-}
-/** Read the work counters. */
-export declare function celDialectWorkStats(): CelDialectWorkStats;
-/** Zero the work counters, so one check can be measured on its own. */
-export declare function resetCelDialectWorkStats(): void;
-/**
- * Offset of the first character of `expression` no CEL token can carry, or `-1`
- * when the spec's lexical grammar covers the text end to end.
- *
- * Exported for the same reason {@link celDialectParseProof} is: the coverage
- * scan is half of what "cel-js parsed it" means here, so it has to be checkable
- * from outside rather than taken on trust. `-1` is the precondition for every
- * verdict this module draws from a cel-js parse — see
- * {@link firstUnlexableOffset} for why `parse()` alone is not enough.
- */
-export declare function celDialectLexicalGap(expression: string): number;
-/**
- * The rewritten expression a `cel-js-rejects-spec-cel` divergence stands on, or
- * `undefined` when there is none.
- *
- * Exported so the proof can be reproduced rather than taken on trust: the
- * returned text differs from `expression` only where a confirmed cel-js
- * shortfall was replaced by a same-production spelling cel-js has, cel-js's
- * lexer carries every character of it and cel-js parses it. An expression with
- * no identified shortfall, one whose own text is not lexically CEL, or one where
- * taking the shortfalls away still leaves text cel-js refuses, yields
- * `undefined` — and that is exactly the case the check refuses to call a
- * divergence.
- */
-export declare function celDialectParseProof(expression: string): string | undefined;
-/**
- * Check one emitted status CEL expression against both dialects.
- *
- * @param expression The emitted CEL, without any `${...}` wrapper.
- * @param field The status leaf path the expression belongs to.
- */
-export declare function checkCelDialectCompatibility(expression: string, field: string): CelDialectFinding[];
-/**
- * Check every emitted status CEL expression in a serialized status map.
- *
- * Accepts the nested shape `serializeStatusMappingsToCel` produces: leaves are
- * `${...}`-wrapped CEL strings, and objects/arrays nest arbitrarily. Values
- * that carry no CEL are skipped, so plain literal status fields cost nothing.
- */
-export declare function collectStatusCelDialectFindings(statusCel: Readonly<Record<string, unknown>>): CelDialectFinding[];
-/**
- * Longest expression or fragment a report will quote, in characters.
- *
- * The analysis budget already keeps `checkCelDialectCompatibility` from
- * returning an oversized `expression`, but the formatter is exported and takes
- * findings from wherever the caller got them — so it bounds what it quotes on
- * its own rather than trusting its input. A report is read by a human; past a
- * couple of lines per finding the excerpt stops helping and starts being the
- * thing that fills the log.
- */
-export declare const CEL_DIALECT_MAX_EXCERPT_LENGTH = 400;
-/** Render findings as a multi-line report naming the leaf, dialect and expression. */
-export declare function formatCelDialectFindings(findings: readonly CelDialectFinding[]): string;
-//# sourceMappingURL=cel-dialect.d.ts.map

package/dist/core/validation/cel-dialect.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"cel-dialect.d.ts","sourceRoot":"","sources":["../../../src/core/validation/cel-dialect.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA0FG;AAKH;;;;;;GAMG;AACH,MAAM,MAAM,UAAU,GAAG,QAAQ,GAAG,QAAQ,GAAG,MAAM,GAAG,WAAW,CAAC;AAEpE;;;;;;;;;GASG;AACH,MAAM,MAAM,qBAAqB,GAAG,YAAY,GAAG,MAAM,CAAC;AAE1D,kDAAkD;AAClD,MAAM,MAAM,gBAAgB,GACxB,eAAe,GACf,yBAAyB,GACzB,sBAAsB,GACtB,oBAAoB,GACpB,kBAAkB,GAClB,kCAAkC,GAClC,2BAA2B,GAC3B,sBAAsB,CAAC;AAE3B;;;;;;;;;;;;;;;;;;;GAmBG;AACH,eAAO,MAAM,iCAAiC,QAAS,CAAC;AAiBxD,4EAA4E;AAC5E,MAAM,WAAW,iBAAiB;IAChC,kCAAkC;IAClC,QAAQ,CAAC,IAAI,EAAE,gBAAgB,CAAC;IAChC,iDAAiD;IACjD,QAAQ,CAAC,IAAI,EAAE,qBAAqB,CAAC;IACrC,8DAA8D;IAC9D,QAAQ,CAAC,OAAO,EAAE,UAAU,CAAC;IAC7B,2DAA2D;IAC3D,QAAQ,CAAC,KAAK,EAAE,MAAM,CAAC;IACvB,kCAAkC;IAClC,QAAQ,CAAC,UAAU,EAAE,MAAM,CAAC;IAC5B,6DAA6D;IAC7D,QAAQ,CAAC,QAAQ,CAAC,EAAE,MAAM,CAAC;IAC3B,oCAAoC;IACpC,QAAQ,CAAC,OAAO,EAAE,MAAM,CAAC;IACzB,iDAAiD;IACjD,QAAQ,CAAC,UAAU,EAAE,MAAM,CAAC;CAC7B;AAED;;;;;;GAMG;AACH,eAAO,MAAM,iBAAiB,EAAE,SAAS;IACvC,QAAQ,CAAC,EAAE,EAAE,gBAAgB,CAAC;IAC9B,QAAQ,CAAC,IAAI,EAAE,qBAAqB,CAAC;IACrC,QAAQ,CAAC,OAAO,EAAE,UAAU,CAAC;IAC7B,QAAQ,CAAC,OAAO,EAAE,MAAM,CAAC;IACzB,QAAQ,CAAC,QAAQ,EAAE,MAAM,CAAC;CAC3B,EAiES,CAAC;AAEX,6DAA6D;AAC7D,wBAAgB,uBAAuB,CAAC,QAAQ,EAAE,SAAS,iBAAiB,EAAE,GAAG,OAAO,CAEvF;AAqCD;;;;;;;;;;;GAWG;AACH,MAAM,WAAW,mBAAmB;IAClC,2CAA2C;IAC3C,QAAQ,CAAC,WAAW,EAAE,MAAM,CAAC;IAC7B,oDAAoD;IACpD,QAAQ,CAAC,iBAAiB,EAAE,MAAM,CAAC;IACnC,8DAA8D;IAC9D,QAAQ,CAAC,OAAO,EAAE,MAAM,CAAC;CAC1B;AAED,8BAA8B;AAC9B,wBAAgB,mBAAmB,IAAI,mBAAmB,CAMzD;AAED,uEAAuE;AACvE,wBAAgB,wBAAwB,IAAI,IAAI,CAI/C;AAmoDD;;;;;;;;;GASG;AACH,wBAAgB,oBAAoB,CAAC,UAAU,EAAE,MAAM,GAAG,MAAM,CAE/D;AAED;;;;;;;;;;;;GAYG;AACH,wBAAgB,oBAAoB,CAAC,UAAU,EAAE,MAAM,GAAG,MAAM,GAAG,SAAS,CAO3E;AA8GD;;;;;GAKG;AACH,wBAAgB,4BAA4B,CAC1C,UAAU,EAAE,MAAM,EAClB,KAAK,EAAE,MAAM,GACZ,iBAAiB,EAAE,CA+MrB;AAQD;;;;;;GAMG;AACH,wBAAgB,+BAA+B,CAC7C,SAAS,EAAE,QAAQ,CAAC,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC,GAC3C,iBAAiB,EAAE,CAuBrB;AAED;;;;;;;;;GASG;AACH,eAAO,MAAM,8BAA8B,MAAM,CAAC;AA2BlD,sFAAsF;AACtF,wBAAgB,wBAAwB,CAAC,QAAQ,EAAE,SAAS,iBAAiB,EAAE,GAAG,MAAM,CAWvF"}

package/dist/core/validation/cel-validator.d.ts

@@ -1,77 +0,0 @@
-/**
- * CEL Expression Validator for Kro Compatibility
- *
- * This module validates CEL expressions to ensure they comply with Kro's requirements:
- * 1. Status fields must reference actual resources (not hardcoded strings)
- * 2. Resource IDs must be camelCase
- * 3. All referenced resources must exist in the ResourceGraphDefinition
- */
-import type { KubernetesResource } from '../types.js';
-export interface StatusResourceIdentityContext {
-    readonly resourceIds: ReadonlySet<string>;
-    readonly resourceAliases: ReadonlyMap<string, string>;
-    readonly ambiguousResourceAliases: ReadonlyMap<string, readonly string[]>;
-}
-export declare function getNestedCompositionIds(statusMappings: Readonly<Record<string, unknown>>): ReadonlySet<string>;
-/**
- * Build the canonical resource identity set used by status planning,
- * serialization, and client-side hydration.
- */
-export declare function createStatusResourceIdentityContext(resources: Readonly<Record<string, KubernetesResource>>): StatusResourceIdentityContext;
-export interface CelValidationError {
-    field: string;
-    expression: string;
-    error: string;
-    suggestion?: string;
-    /** Machine-readable finding category (used by strict CEL diagnostics). */
-    code?: 'unknown-resource' | 'ambiguous-resource' | 'sensitive-status';
-    /** The unresolved resource id, when code is 'unknown-resource'. */
-    referencedResource?: string;
-}
-export interface CelValidationResult {
-    isValid: boolean;
-    errors: CelValidationError[];
-    warnings: CelValidationError[];
-}
-/**
- * Validates that a resource ID follows camelCase convention required by Kro
- */
-export declare function validateResourceId(id: string): {
-    isValid: boolean;
-    error?: string;
-};
-/**
- * Separate status mappings into static fields (hydrated locally by TypeKro)
- * and dynamic fields (emitted as CEL for KRO).
- *
- * When `nestedStatusCel` is provided, classification is transitive — a
- * nested composition reference whose target is a schema-only / literal
- * expression is classified as static even though the reference itself
- * looks like `<id>.status.<field>`. This is the key mechanism that
- * satisfies the "depth-agnostic staticness" invariant for nested
- * compositions.
- *
- * If `nestedStatusCel` is not explicitly passed, the function falls back
- * to reading `statusMappings.__nestedStatusCel` (which is where the
- * composition context attaches the table via Reflect.set), so existing
- * callers continue to work without explicit plumbing.
- */
-export declare function separateStatusFields(statusMappings: Record<string, unknown>, nestedStatusCel?: Record<string, string>, resourceIds?: ReadonlySet<string>, nestedCompositionIds?: ReadonlySet<string>): {
-    staticFields: Record<string, unknown>;
-    dynamicFields: Record<string, unknown>;
-};
-/**
- * Validates CEL expressions in dynamic status fields to ensure they reference actual resources
- */
-export declare function validateStatusCelExpressions(statusMappings: Record<string, unknown>, resources: Record<string, KubernetesResource>, options?: {
-    readonly enforceSensitiveStatus?: boolean;
-}): CelValidationResult;
-/**
- * Validates all resource IDs in a resource collection
- */
-export declare function validateResourceIds(resources: Record<string, KubernetesResource>): CelValidationResult;
-/**
- * Comprehensive validation for a complete ResourceGraphDefinition
- */
-export declare function validateResourceGraphDefinition(resources: Record<string, KubernetesResource>, statusMappings?: Record<string, unknown>): CelValidationResult;
-//# sourceMappingURL=cel-validator.d.ts.map

package/dist/core/validation/cel-validator.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"cel-validator.d.ts","sourceRoot":"","sources":["../../../src/core/validation/cel-validator.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAWH,OAAO,KAAK,EAAE,kBAAkB,EAAE,MAAM,aAAa,CAAC;AAEtD,MAAM,WAAW,6BAA6B;IAC5C,QAAQ,CAAC,WAAW,EAAE,WAAW,CAAC,MAAM,CAAC,CAAC;IAC1C,QAAQ,CAAC,eAAe,EAAE,WAAW,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;IACtD,QAAQ,CAAC,wBAAwB,EAAE,WAAW,CAAC,MAAM,EAAE,SAAS,MAAM,EAAE,CAAC,CAAC;CAC3E;AAED,wBAAgB,uBAAuB,CACrC,cAAc,EAAE,QAAQ,CAAC,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC,GAChD,WAAW,CAAC,MAAM,CAAC,CAOrB;AAaD;;;GAGG;AACH,wBAAgB,mCAAmC,CACjD,SAAS,EAAE,QAAQ,CAAC,MAAM,CAAC,MAAM,EAAE,kBAAkB,CAAC,CAAC,GACtD,6BAA6B,CAkD/B;AAED,MAAM,WAAW,kBAAkB;IACjC,KAAK,EAAE,MAAM,CAAC;IACd,UAAU,EAAE,MAAM,CAAC;IACnB,KAAK,EAAE,MAAM,CAAC;IACd,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,0EAA0E;IAC1E,IAAI,CAAC,EAAE,kBAAkB,GAAG,oBAAoB,GAAG,kBAAkB,CAAC;IACtE,mEAAmE;IACnE,kBAAkB,CAAC,EAAE,MAAM,CAAC;CAC7B;AAED,MAAM,WAAW,mBAAmB;IAClC,OAAO,EAAE,OAAO,CAAC;IACjB,MAAM,EAAE,kBAAkB,EAAE,CAAC;IAC7B,QAAQ,EAAE,kBAAkB,EAAE,CAAC;CAChC;AAED;;GAEG;AACH,wBAAgB,kBAAkB,CAAC,EAAE,EAAE,MAAM,GAAG;IAAE,OAAO,EAAE,OAAO,CAAC;IAAC,KAAK,CAAC,EAAE,MAAM,CAAA;CAAE,CAgCnF;AAyMD;;;;;;;;;;;;;;;GAeG;AACH,wBAAgB,oBAAoB,CAClC,cAAc,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EACvC,eAAe,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,EACxC,WAAW,CAAC,EAAE,WAAW,CAAC,MAAM,CAAC,EACjC,oBAAoB,GAAE,WAAW,CAAC,MAAM,CAA2C,GAClF;IACD,YAAY,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC;IACtC,aAAa,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC;CACxC,CAsDA;AAED;;GAEG;AACH,wBAAgB,4BAA4B,CAC1C,cAAc,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EACvC,SAAS,EAAE,MAAM,CAAC,MAAM,EAAE,kBAAkB,CAAC,EAC7C,OAAO,GAAE;IAAE,QAAQ,CAAC,sBAAsB,CAAC,EAAE,OAAO,CAAA;CAAO,GAC1D,mBAAmB,CAmUrB;AAED;;GAEG;AACH,wBAAgB,mBAAmB,CACjC,SAAS,EAAE,MAAM,CAAC,MAAM,EAAE,kBAAkB,CAAC,GAC5C,mBAAmB,CAqBrB;AAED;;GAEG;AACH,wBAAgB,+BAA+B,CAC7C,SAAS,EAAE,MAAM,CAAC,MAAM,EAAE,kBAAkB,CAAC,EAC7C,cAAc,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,GACvC,mBAAmB,CAgBrB"}

package/dist/core/validation/literal-status.d.ts

@@ -1,107 +0,0 @@
-/**
- * Dropped status-leaf validation for KRO mode.
- *
- * THE RULE: a KRO status field must reference at least one RESOURCE in the
- * graph. KRO's own instance builder enforces exactly that — `instance status
- * field must refer to a resource` (KRO `builder.go`, quoted in
- * `kro-instance-safety.ts`) — and its status CEL environment has no `schema`
- * identifier at all. A status expression with no resource in it therefore has
- * nothing to project from and is left unset on the instance. The declared
- * status schema then promises a field the custom resource never carries, and
- * every consumer that reads the CR directly (kubectl, another controller, an
- * `externalRef` from a second composition) sees `undefined`.
- *
- * Two shapes have no resource in them, and KRO drops BOTH the same way:
- *
- *  - a bare LITERAL — a string, number, boolean, literal array/object, or a
- *    reference-free CEL expression such as `Cel.expr`'running'``;
- *  - a bare SCHEMA REFERENCE — `schema.spec.foo` standing alone in a status
- *    leaf. It looks resolvable (the CR does hold that value in its own spec),
- *    but a status leaf is a PROJECTION, and there is no resource here to
- *    project from. TypeKro's own serializer already agrees: it classifies a
- *    schema-only status field as "static" and excludes it from the emitted
- *    status block — see invariant I1/I2 in
- *    `test/unit/nested-composition-kro-serialization.test.ts` ("KRO status CEL
- *    does NOT support `schema.spec.*`"), the same conclusion in
- *    `src/core/proxy/create-resource.ts` ("classifies the resulting status
- *    field as schema-derived and drops it from the live KRO CR's status
- *    entirely"), and `assertNoHoistWeakenedStatusFields`, which already THROWS
- *    for precisely this shape when a hoisted Namespace leaves a field
- *    schema-only. This module simply makes the general case agree with that
- *    special one.
- *
- * What stays valid is any expression ANCHORED on a resource. A mixed template
- * such as `` `http://${schema.spec.name}-svc:${svc.spec.ports[0].port}` `` is
- * fine: the resource reference gives KRO the dependency it requires, and
- * `schema.spec.*` resolves against the instance's own spec from there. The
- * serializer deliberately preserves those (`cel-references.ts`: "Plain CR spec
- * fields must remain `schema.spec.*`"), and
- * `nested-composition-kro-serialization.test.ts` pins the emitted shape. So the
- * test is not "does this mention `schema`" but "does this reference a
- * resource".
- *
- * TypeKro classified both dropped shapes as "static" and hydrated them
- * client-side in `getStatus()`, which hides the gap from the composition's own
- * author while leaving it wide open for everybody else. This module finds those
- * leaves at serialization time so the author is told before the RGD ships.
- *
- * Direct mode is unaffected — there is no KRO reconciler in that path and the
- * status object is assembled locally, so literals and schema refs are perfectly
- * fine there. The check therefore runs only from the KRO schema emitter.
- *
- * See issue #188.
- */
-/** Why a status leaf never reaches the instance. */
-export type DroppedStatusLeafKind = 
-/** A bare literal, or a reference-free CEL expression. */
-'literal'
-/** A `schema.spec.*` reference with no resource to anchor it. */
- | 'schema-reference';
-/** One status leaf that would be dropped by KRO. */
-export interface LiteralStatusLeaf {
-    /** Full status path, e.g. `status.url`, `status.info.mode`, `status.entrypoints[0]`. */
-    readonly path: string;
-    /** Rendered form of the offending value, for the diagnostic message. */
-    readonly literal: string;
-    /** Which of the two no-resource shapes this leaf is. */
-    readonly kind: DroppedStatusLeafKind;
-}
-/**
- * Find every status leaf that KRO would leave unset.
- *
- * `statusMappings` is the analyzed status mapping (post-CEL-conversion,
- * pre-static/dynamic split) — the split is exactly what hides the problem, so
- * the walk has to happen before it.
- */
-export declare function findLiteralStatusLeaves(statusMappings: Readonly<Record<string, unknown>> | undefined, nestedStatusCel?: Record<string, string>): readonly LiteralStatusLeaf[];
-/**
- * Human-readable diagnostic for a set of dropped status leaves.
- */
-export declare function formatLiteralStatusLeaves(leaves: readonly LiteralStatusLeaf[]): string;
-/**
- * Default for `allowLiteralStatus` — i.e. whether a literal status leaf warns
- * rather than throwing.
- *
- * `true` (warn) for now. The check is correct and the diagnostic is actionable,
- * but literal status leaves are not a rare mistake in existing code: turning
- * this on as a hard error against the repository's own suite rejected 377
- * serializations across 69 test files and every bootstrap composition listed in
- * `test/unit/literal-status-repo-scan.test.ts`. Shipping that as a patch-level
- * error would break every downstream composition using the same shape, with no
- * migration window.
- *
- * So: warn by default, and let a composition (or a CI job, via the factory
- * option) opt into the error with `allowLiteralStatus: false` today. Flip this
- * constant to `false` in the next major once the bundled compositions are
- * projections — that single edit is the whole migration.
- */
-export declare const DEFAULT_ALLOW_LITERAL_STATUS = true;
-/**
- * Resolve the effective `allowLiteralStatus` setting.
- *
- * A factory-level setting wins over the composition's own, so a CI job can run
- * `graph.factory('kro', { allowLiteralStatus: false }).toYaml()` to enforce
- * projection across compositions it does not own.
- */
-export declare function resolveAllowLiteralStatus(factoryOption: boolean | undefined, compositionOption: boolean | undefined): boolean;
-//# sourceMappingURL=literal-status.d.ts.map

package/dist/core/validation/literal-status.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"literal-status.d.ts","sourceRoot":"","sources":["../../../src/core/validation/literal-status.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAoDG;AAaH,oDAAoD;AACpD,MAAM,MAAM,qBAAqB;AAC/B,0DAA0D;AACxD,SAAS;AACX,iEAAiE;GAC/D,kBAAkB,CAAC;AAEvB,oDAAoD;AACpD,MAAM,WAAW,iBAAiB;IAChC,wFAAwF;IACxF,QAAQ,CAAC,IAAI,EAAE,MAAM,CAAC;IACtB,wEAAwE;IACxE,QAAQ,CAAC,OAAO,EAAE,MAAM,CAAC;IACzB,wDAAwD;IACxD,QAAQ,CAAC,IAAI,EAAE,qBAAqB,CAAC;CACtC;AAgQD;;;;;;GAMG;AACH,wBAAgB,uBAAuB,CACrC,cAAc,EAAE,QAAQ,CAAC,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC,GAAG,SAAS,EAC7D,eAAe,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,GACvC,SAAS,iBAAiB,EAAE,CAU9B;AAED;;GAEG;AACH,wBAAgB,yBAAyB,CAAC,MAAM,EAAE,SAAS,iBAAiB,EAAE,GAAG,MAAM,CA0BtF;AAED;;;;;;;;;;;;;;;;GAgBG;AACH,eAAO,MAAM,4BAA4B,OAAO,CAAC;AAEjD;;;;;;GAMG;AACH,wBAAgB,yBAAyB,CACvC,aAAa,EAAE,OAAO,GAAG,SAAS,EAClC,iBAAiB,EAAE,OAAO,GAAG,SAAS,GACrC,OAAO,CAET"}