@intentius/chant 0.124.13 → 0.124.14

package/dist/lint/output-docs.js

@@ -0,0 +1,163 @@
+/**
+ * Parsed-output view for post-synth checks (chant #975).
+ *
+ * `PostSynthContext.outputs` carries raw serialized strings — a `chant build`
+ * consumer has to parse YAML/JSON itself before it can reason about
+ * structure. Every lexicon that needs this today rolls its own splitter
+ * (`parseK8sManifests` in k8s, hand-rolled `JSON.parse` in aws's
+ * `cf-refs.ts`), and each of the ~30 k8s post-synth checks reparses the same
+ * output independently. This module is the shared, parse-once primitive:
+ * `parseOutputDocs` turns `ctx.outputs` into a flat list of `OutputDoc`s,
+ * and `PostSynthContext.docs` (see `./post-synth.ts`) memoizes one call to it
+ * per build so every check — lexicon-shipped or project-authored policy —
+ * shares the same parse.
+ *
+ * `pick`/`get` are the "look at only the fields you care about" ergonomic
+ * from the issue's `,remain`-style framing — a partial, unvalidated view of
+ * an already-parsed tree, not a query DSL. Selector languages over the
+ * *source* AST stay in `./declarative.ts`; this module is output-side only.
+ */
+import { parseYAML } from "../yaml.js";
+/**
+ * Parse every output in `outputs` into a flat list of `OutputDoc`s: one call,
+ * shared by every post-synth check via `PostSynthContext.docs`.
+ *
+ * Format detection is whole-source, not per-document: if the entire source
+ * parses as JSON, it is one `"json"` document (CloudFormation, most non-k8s
+ * serializers). Otherwise the source is treated as a YAML stream — split on
+ * `---` document separators — and each resulting document is parsed as YAML
+ * (`format: "yaml"`), even one that happens to also be valid JSON, since
+ * JSON is a YAML subset. `SerializerResult.files` entries (nested templates,
+ * sidecar manifests) are parsed the same way, tagged with `file`.
+ *
+ * A document that fails to parse into a non-null object/array — malformed
+ * input, or a bare scalar where a manifest was expected — is not thrown:
+ * it is included with `error` set and `value: undefined`. See `OutputDoc`.
+ */
+export function parseOutputDocs(outputs) {
+    const docs = [];
+    for (const [lexicon, output] of outputs) {
+        const primary = typeof output === "string" ? output : output.primary;
+        docs.push(...parseSource(primary, lexicon));
+        const files = typeof output === "string" ? undefined : output.files;
+        for (const [file, content] of Object.entries(files ?? {})) {
+            docs.push(...parseSource(content, lexicon, file));
+        }
+    }
+    return docs;
+}
+/** Split a YAML stream on `---` document-separator lines (own line, optional
+ *  trailing whitespace) — including a leading separator before any content,
+ *  which `"\n---\n"`-style splitting misses. Empty documents (two separators
+ *  back to back, or a leading/trailing one) are dropped. */
+function splitYamlDocuments(source) {
+    return source
+        .split(/^---[ \t]*$/m)
+        .map((doc) => doc.trim())
+        .filter((doc) => doc.length > 0);
+}
+/** True for a value a document is usable as — a non-null object or array.
+ *  A bare scalar ("just a string") parses without error but is not a
+ *  document a check can walk, so it is treated as malformed. */
+function isUsableDoc(value) {
+    return typeof value === "object" && value !== null;
+}
+/**
+ * Parse one source string (a primary output, or one `files` entry) into its
+ * `OutputDoc`s, trying whole-content JSON first and falling back to a
+ * (possibly multi-document) YAML stream. Never throws — a parse failure or
+ * an unusable result becomes a marker document with `error` set.
+ */
+function parseSource(source, lexicon, file) {
+    const trimmed = source.trim();
+    if (trimmed === "")
+        return [];
+    try {
+        const value = JSON.parse(trimmed);
+        if (isUsableDoc(value)) {
+            return [{ lexicon, index: 0, format: "json", value, ...(file && { file }) }];
+        }
+        return [
+            {
+                lexicon,
+                index: 0,
+                format: "json",
+                value: undefined,
+                error: "parsed JSON is not an object or array",
+                ...(file && { file }),
+            },
+        ];
+    }
+    catch {
+        // Not whole-content JSON — fall through to the YAML stream path.
+    }
+    return splitYamlDocuments(trimmed).map((segment, index) => {
+        try {
+            const value = parseYAML(segment);
+            if (isUsableDoc(value)) {
+                return { lexicon, index, format: "yaml", value, ...(file && { file }) };
+            }
+            return {
+                lexicon,
+                index,
+                format: "yaml",
+                value: undefined,
+                error: "parsed YAML document is not an object or array",
+                ...(file && { file }),
+            };
+        }
+        catch (err) {
+            return {
+                lexicon,
+                index,
+                format: "yaml",
+                value: undefined,
+                error: err instanceof Error ? err.message : String(err),
+                ...(file && { file }),
+            };
+        }
+    });
+}
+/**
+ * Partial typed decode — the `,remain`-style ergonomic from `ma91n/tfpolicy`:
+ * decode the fields you care about, leave everything else in place,
+ * unvalidated. Returns a shallow, top-level view of `value` narrowed to the
+ * keys named in `shape`. A key absent from `value` (or `value` not being a
+ * plain object) is simply absent from the result — no default is invented.
+ *
+ * This is NOT runtime validation: a key that IS present is copied as-is,
+ * whatever its actual shape, and cast to `T`'s declared type for that key.
+ * Use `get` for a deeper walk into one of the picked values.
+ */
+export function pick(value, shape) {
+    const result = {};
+    if (typeof value !== "object" || value === null)
+        return result;
+    const source = value;
+    for (const key of shape) {
+        const propertyName = key;
+        if (propertyName in source) {
+            result[propertyName] = source[propertyName];
+        }
+    }
+    return result;
+}
+/**
+ * Dotted-path getter for the common walk over a parsed doc, e.g.
+ * `get(doc.value, "spec.template.spec")`. Not a query DSL — no wildcards,
+ * no predicates, no array-flattening. An array index is just a numeric path
+ * segment (`get(value, "items.0.name")`), since JS indexes arrays by string
+ * key underneath. Returns `undefined` as soon as any segment is missing or
+ * the value at that point isn't indexable — it never throws on a bad path.
+ */
+export function get(value, path) {
+    if (path === "")
+        return value;
+    let current = value;
+    for (const segment of path.split(".")) {
+        if (typeof current !== "object" || current === null)
+            return undefined;
+        current = current[segment];
+    }
+    return current;
+}

package/dist/lint/parser.js

@@ -0,0 +1,33 @@
+import * as ts from "typescript";
+import { readFileSync } from "fs";
+/**
+ * Parse a TypeScript file into an AST
+ * @param path - Absolute or relative path to the TypeScript file
+ * @returns Parsed TypeScript SourceFile
+ * @throws Error if the file cannot be read or parsed
+ */
+export function parseFile(path) {
+    let content;
+    try {
+        content = readFileSync(path, "utf-8");
+    }
+    catch (err) {
+        throw new Error(`Failed to read file ${path}: ${err instanceof Error ? err.message : String(err)}`);
+    }
+    const sourceFile = ts.createSourceFile(path, content, ts.ScriptTarget.Latest, true // setParentNodes
+    );
+    // Check for syntax errors (parseDiagnostics is internal but accessible)
+    const diagnostics = [
+        ...sourceFile.parseDiagnostics,
+    ];
+    if (diagnostics.length > 0) {
+        const errors = diagnostics
+            .map((d) => {
+            const { line, character } = sourceFile.getLineAndCharacterOfPosition(d.start ?? 0);
+            return `${path}:${line + 1}:${character + 1} - ${ts.flattenDiagnosticMessageText(d.messageText, "\n")}`;
+        })
+            .join("\n");
+        throw new Error(`TypeScript parsing failed:\n${errors}`);
+    }
+    return sourceFile;
+}

package/dist/lint/pipeline-change-gate.js

@@ -0,0 +1,70 @@
+import { STARTER_VERB_FAMILIES } from "../components/starter-plugin.js";
+import { walkComponent } from "./rules/comp/support.js";
+/**
+ * Fallback registry when no project registry is supplied: core's own starter
+ * verbs, the same fallback COMP005 uses for a direct unit test
+ * (`./rules/comp/comp005-capability-kind-is-noun.ts`). A real `chant lint` /
+ * gate run passes the project's resolved `knownKinds` (core's starter set
+ * plus the active lexicons' leaves) so a real project's cloud verbs are never
+ * mistaken for an out-of-registry escape hatch.
+ */
+const CORE_STARTER_KINDS = new Set(Object.values(STARTER_VERB_FAMILIES).flat());
+/** Every non-gate step kind a component's composition invokes, across `deploy` and `rollback` (nested fan-out phases included, via `walkComponent`). `gate` steps are excluded — they are not a capability verb. */
+export function componentVerbSet(component) {
+    const { steps } = walkComponent(component);
+    return new Set(steps.map((s) => s.step.kind));
+}
+/**
+ * Classify a single component's composition (the "cheap first cut", no
+ * before/after needed): a `shell` step trips the class unconditionally — it
+ * is the escape hatch by construction (COMP006) — and any step whose `kind`
+ * is outside `knownKinds` trips it too, since an unregistered verb is,
+ * structurally, the same kind of hole a `shell` step is: something the
+ * bounded registry does not account for.
+ */
+export function classifyComponentPipelineChange(component, opts) {
+    const knownKinds = opts?.knownKinds ?? CORE_STARTER_KINDS;
+    const { steps } = walkComponent(component);
+    const reasons = [];
+    for (const { step, phaseName } of steps) {
+        if (step.kind === "shell") {
+            reasons.push({ kind: "shell-step", phaseName });
+        }
+        else if (!knownKinds.has(step.kind)) {
+            reasons.push({ kind: "unregistered-verb", stepKind: step.kind, phaseName });
+        }
+    }
+    return { pipelineChange: reasons.length > 0, reasons };
+}
+/**
+ * Classify a *change* to a component's composition between two revisions
+ * (#1569's "add or modify a shell step ... or the composition graph
+ * itself"): on top of `classifyComponentPipelineChange`'s single-composition
+ * check on `after`, a change also trips the class when the verb set itself
+ * changed — a verb added or removed changes what the composition can invoke,
+ * which is the routing signal even when every individual verb, before and
+ * after, is registry-clean. `before: undefined` (a brand-new component) never
+ * reports a verb-set change — there is nothing to diff against, and the
+ * single-composition check already covers a new component's own shell/
+ * unregistered-verb findings.
+ */
+export function classifyPipelineChange(before, after, opts) {
+    const base = classifyComponentPipelineChange(after, opts);
+    if (!before)
+        return base;
+    const beforeVerbs = componentVerbSet(before);
+    const afterVerbs = componentVerbSet(after);
+    const added = [...afterVerbs].filter((v) => !beforeVerbs.has(v)).sort();
+    const removed = [...beforeVerbs].filter((v) => !afterVerbs.has(v)).sort();
+    if (added.length === 0 && removed.length === 0)
+        return base;
+    return {
+        pipelineChange: true,
+        reasons: [...base.reasons, { kind: "verb-set-changed", added, removed }],
+    };
+}
+/** Evaluate a component composition change against a routing policy. Pure — no I/O. */
+export function evaluatePipelineChangeGate(before, after, policy = "human-always", opts) {
+    const classification = classifyPipelineChange(before, after, opts);
+    return { ...classification, route: classification.pipelineChange ? policy : "none" };
+}

package/dist/lint/policy-import.d.ts

@@ -17,7 +17,7 @@
  * the *decision* and documents the reasoning, and re-exports these three
  * functions as its public surface) for one structural reason: `./policy.ts`
  * needs to consult it, `./policy-sandbox.ts` needs to call `./policy.ts`, and a
- * flag on a leaf module with no imports of its own breaks what would otherwise
+ * flag on a leaf module (its one import, `../ts-loader`, is a leaf too) breaks what would otherwise
  * be an import cycle. It also puts the check on the narrowest possible thing —
  * the function that actually executes project code — rather than on a caller
  * that might forget to ask.

package/dist/lint/policy-import.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"policy-import.d.ts","sourceRoot":"","sources":["../../src/lint/policy-import.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AAKH;;;;GAIG;AACH,wBAAgB,yBAAyB,IAAI,IAAI,CAEhD;AAED,iEAAiE;AACjE,wBAAgB,6BAA6B,IAAI,OAAO,CAEvD;AAED,4IAA4I;AAC5I,wBAAgB,mCAAmC,IAAI,IAAI,CAE1D;AAED,2HAA2H;AAC3H,MAAM,MAAM,qBAAqB,GAAG,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC;AAE5D;;;;;;;;;;;GAWG;AACH,wBAAsB,kBAAkB,CAAC,UAAU,EAAE,MAAM,GAAG,OAAO,CAAC,qBAAqB,CAAC,CAO3F"}
+{"version":3,"file":"policy-import.d.ts","sourceRoot":"","sources":["../../src/lint/policy-import.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AAOH;;;;GAIG;AACH,wBAAgB,yBAAyB,IAAI,IAAI,CAEhD;AAED,iEAAiE;AACjE,wBAAgB,6BAA6B,IAAI,OAAO,CAEvD;AAED,4IAA4I;AAC5I,wBAAgB,mCAAmC,IAAI,IAAI,CAE1D;AAED,2HAA2H;AAC3H,MAAM,MAAM,qBAAqB,GAAG,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC;AAE5D;;;;;;;;;;;GAWG;AACH,wBAAsB,kBAAkB,CAAC,UAAU,EAAE,MAAM,GAAG,OAAO,CAAC,qBAAqB,CAAC,CAQ3F"}

package/dist/lint/policy-import.js

@@ -0,0 +1,62 @@
+/**
+ * The single place chant imports a project's `lint.policies` module **in the
+ * CLI's own process** — and the flag that says it may not.
+ *
+ * The third member of the same family as `../discovery/import.ts`'s
+ * `importModule` (project source) and `../config-import.ts`'s
+ * `importConfigModule` (`chant.config.ts`): one narrow module whose only job is
+ * "execute project-authored code here", so that "did any project code run in
+ * this process?" has one place to look and one place to instrument — see
+ * `examples/sandbox-execution-boundary.e2e.test.ts`, which spies on all three.
+ *
+ * Before chant #1131 `./policy.ts` called `await import(resolved)` inline,
+ * which is why the corpus boundary gate could not see it even after #1113 put
+ * the config behind the boundary: there was nothing named to wrap.
+ *
+ * The armed flag lives here rather than in `./policy-sandbox.ts` (which owns
+ * the *decision* and documents the reasoning, and re-exports these three
+ * functions as its public surface) for one structural reason: `./policy.ts`
+ * needs to consult it, `./policy-sandbox.ts` needs to call `./policy.ts`, and a
+ * flag on a leaf module (its one import, `../ts-loader`, is a leaf too) breaks what would otherwise
+ * be an import cycle. It also puts the check on the narrowest possible thing —
+ * the function that actually executes project code — rather than on a caller
+ * that might forget to ask.
+ */
+import { ensureTypeScriptLoader } from "../ts-loader.js";
+/** Whether this process must run project policy modules inside the sandbox boundary instead of here. */
+let armed = false;
+/**
+ * Arm sandboxed policy execution for the rest of this process. See
+ * `./policy-sandbox.ts` for what arms it and why it is a process mode rather
+ * than a threaded option. Idempotent; there is deliberately no disarm.
+ */
+export function armSandboxPolicyExecution() {
+    armed = true;
+}
+/** Whether {@link armSandboxPolicyExecution} has been called. */
+export function isSandboxPolicyExecutionArmed() {
+    return armed;
+}
+/** Test-only reset — vitest gives each test file its own module registry, so this exists for suites that arm and disarm within one file. */
+export function resetSandboxPolicyExecutionForTests() {
+    armed = false;
+}
+/**
+ * Import a policy module into THIS process and return its module namespace.
+ * Node's ESM registry caches it, so repeated loads within one CLI invocation
+ * evaluate the file once.
+ *
+ * Refuses while armed. Under `--sandbox` the policy modules are imported inside
+ * a child process (`../discovery/sandbox/policy-run.ts`); arriving here anyway
+ * means something is about to execute project-authored code in the CLI's own
+ * process, which is exactly what the flag promises does not happen. Falling
+ * through would make `--sandbox` mean less than it says with nothing visible to
+ * notice, so this throws instead.
+ */
+export async function importPolicyModule(policyPath) {
+    if (armed) {
+        throw new Error(`Refusing to import the policy module ${policyPath} into the chant process under --sandbox: it is project-authored code and must be imported inside the sandbox boundary (packages/core/src/lint/policy-sandbox.ts's runProjectPolicies).`);
+    }
+    ensureTypeScriptLoader();
+    return (await import(policyPath));
+}

package/dist/lint/policy-sandbox.js

@@ -0,0 +1,86 @@
+import { resolve } from "node:path";
+import { runPostSynthChecks, } from "./post-synth.js";
+import { loadPolicyChecks } from "./policy.js";
+import { armSandboxPolicyExecution, isSandboxPolicyExecutionArmed, resetSandboxPolicyExecutionForTests, } from "./policy-import.js";
+/**
+ * chant #1131 — decides WHERE a project's `lint.policies` checks run.
+ *
+ * A policy is project-authored code. Every other piece of project code moved
+ * behind the `--sandbox` boundary in chant #1045 (run-fallback source), #1093
+ * (composite factories, constructors, intrinsic tags) and #1113
+ * (`chant.config.ts`), and all three had to leave this one out: the config
+ * declares its policies as *paths*, so putting the config behind the boundary
+ * did not put them there with it. `chant build` imported each policy module and
+ * called its `check` function in the CLI's own process, after discovery was
+ * over, with the CLI's filesystem, network, environment and process-spawn
+ * access. This module closes it.
+ *
+ * ## Why an armed process mode rather than a threaded option
+ *
+ * The same reason `../config-sandbox.ts` gives. `./policy.ts`'s
+ * `loadPolicyChecks` is exported from chant-core's public surface and called
+ * from more than one place (`../cli/commands/build.ts` for a build, and
+ * `evaluateProjectPolicies` for the `policyGate` Op step). Threading a
+ * `sandbox` flag to each is fail-OPEN: miss one and project code executes in
+ * the CLI process with nothing to notice. Arming the process once, before any
+ * policy is loaded, is fail-CLOSED — `loadPolicyChecks` REFUSES while armed, so
+ * a call site nobody remembered gets a loud error rather than a silent
+ * execution.
+ *
+ * ## What arms it
+ *
+ * Both ways of turning sandboxing on, unlike `../config-sandbox.ts`. That
+ * asymmetry is not an oversight: the config has a bootstrap limit (reading
+ * `build.sandbox` out of `chant.config.ts` means running it, so only the CLI
+ * flag, known before any config is touched, can cover the config's own
+ * evaluation). Policies have no such limit — they are loaded long after the
+ * config is known — so `build.sandbox: true` in a project's config sandboxes
+ * them just as `--sandbox` does, and `../cli/commands/build.ts` arms this from
+ * the RESOLVED value.
+ *
+ * There is deliberately no disarm: a security mode that can be turned off
+ * partway through a process is not one.
+ */
+/**
+ * The mode itself lives on `./policy-import.ts` — the leaf module that actually
+ * performs an in-process policy import, so the refusal sits on the narrowest
+ * possible thing and `./policy.ts` can consult it without importing this file
+ * (which imports `./policy.ts`). Re-exported here because this is where the
+ * decision is documented and where callers look.
+ *
+ * `armSandboxPolicyExecution` is called from `../cli/commands/build.ts` once
+ * `build.sandbox`/`--sandbox` has resolved, and from `../cli/main.ts` off the
+ * parsed flag.
+ */
+export { armSandboxPolicyExecution, isSandboxPolicyExecutionArmed, resetSandboxPolicyExecutionForTests };
+/**
+ * Run a project's organizational policy checks over a finished build and return
+ * their diagnostics. Sandboxed in a post-merge child when armed, in-process
+ * otherwise.
+ *
+ * The unarmed path is byte-for-byte what `chant build` has always done: load
+ * the modules, hand every check one `PostSynthContext`, concatenate what they
+ * return. The armed path does the same thing on the other side of a process
+ * boundary — see `../discovery/sandbox/policy-run.ts`.
+ */
+export async function runProjectPolicies(run) {
+    if (run.policies.length === 0)
+        return [];
+    if (!isSandboxPolicyExecutionArmed()) {
+        const checks = run.preloaded ?? (await loadPolicyChecks([...run.policies], run.configDir));
+        if (checks.length === 0)
+            return [];
+        return runPostSynthChecks(checks, run.buildResult, run.env);
+    }
+    // Dynamic, not static, for the same reason `../config-sandbox.ts` imports
+    // `../discovery/sandbox/config-run` dynamically: this pulls in `esbuild`, a
+    // large CJS package no unsandboxed build should pay to load.
+    const { runPoliciesSandboxed } = await import("../discovery/sandbox/policy-run.js");
+    const { diagnostics } = await runPoliciesSandboxed({
+        policyPaths: run.policies.map((p) => resolve(run.configDir, p)),
+        buildResult: run.buildResult,
+        env: run.env,
+        projectRoot: run.configDir,
+    });
+    return diagnostics;
+}

package/dist/lint/policy.js

@@ -0,0 +1,122 @@
+/**
+ * Project-authored organizational policy: loading the policy pack and evaluating
+ * it against a freshly built project. `chant build` runs policies inline; the
+ * `policyGate` Op step runs this to gate an apply on the same checks.
+ */
+import { resolve, dirname } from "node:path";
+import { loadChantConfigUpward, resolveOwnershipEnv, resolveOwnershipMarker } from "../config.js";
+import { resolveBuildParams } from "../build-params.js";
+import { resolveProjectLexicons, loadPlugins } from "../cli/plugins.js";
+import { resolveBuildModes, resolveProjectBuildOptions } from "../cli/build-options.js";
+import { formatWarning } from "../cli/format.js";
+import { build } from "../build.js";
+import { runPostSynthChecks, isPostSynthCheck } from "./post-synth.js";
+import { applyConfiguredSeverity } from "./config.js";
+import { importPolicyModule, isSandboxPolicyExecutionArmed } from "./policy-import.js";
+/**
+ * Load project policy checks (one or more `PostSynthCheck` exports) from files,
+ * **into this process**.
+ *
+ * chant #1131 — refuses while `./policy-sandbox.ts` is armed. Under `--sandbox`
+ * the policy modules are imported and their checks run inside a child process
+ * (`runProjectPolicies`); reaching this function anyway means a call site is
+ * about to execute project-authored code in the CLI's own process, which is
+ * precisely the thing the flag promises does not happen. Failing loudly is the
+ * only honest option — falling through would make `--sandbox` mean less than it
+ * says without anything visible to notice.
+ */
+export async function loadPolicyChecks(paths, configDir) {
+    if (isSandboxPolicyExecutionArmed()) {
+        throw new Error(`Cannot load lint.policies (${paths.join(", ")}) in the chant process under --sandbox: a policy module is project-authored code, and it must be imported inside the sandbox boundary. This is a chant bug — the caller should route through runProjectPolicies() (packages/core/src/lint/policy-sandbox.ts).`);
+    }
+    const checks = [];
+    for (const p of paths) {
+        const resolved = resolve(configDir, p);
+        let mod;
+        try {
+            mod = await importPolicyModule(resolved);
+        }
+        catch (err) {
+            throw new Error(`Failed to load policy "${p}": ${err instanceof Error ? err.message : String(err)}`);
+        }
+        for (const value of Object.values(mod)) {
+            if (isPostSynthCheck(value))
+                checks.push(value);
+        }
+    }
+    return checks;
+}
+/**
+ * Build a project and run its `lint.policies` over the resolved resources,
+ * standalone — used by the `policyGate` Op step to gate an apply on the same
+ * organizational policy `chant build` enforces. Loads the project's lexicons,
+ * builds, then runs the policy pack with `env` (explicit, else `ownership.env`).
+ *
+ * chant #2002 — "the same organizational policy `chant build` enforces" only
+ * holds if it is the same build. The build options are assembled by
+ * `../cli/build-options.ts`'s `resolveProjectBuildOptions`, the single function
+ * `chant build` also calls, rather than by a second list here; a build option
+ * added for one caller and not the other is what let a gate pass a build
+ * `chant build` fails.
+ */
+export async function evaluateProjectPolicies(opts) {
+    const buildPath = resolve(opts.path);
+    const lexiconNames = await resolveProjectLexicons(buildPath);
+    const plugins = await loadPlugins(lexiconNames);
+    const serializers = plugins.map((p) => p.serializer);
+    // chant #1117 — walks up from the build dir to the project root, same as
+    // `chant build` (`../cli/commands/build.ts`'s `loadChantConfigUpward`), not
+    // just the build dir's immediate parent.
+    const loaded = await loadChantConfigUpward(buildPath);
+    const config = loaded.config;
+    const configDir = loaded.configPath ? dirname(loaded.configPath) : buildPath;
+    // #1396 — `ownership.env` may reference a build parameter, so the declared
+    // parameters are resolved first (from their env mappings and defaults, the
+    // same inputs an Op step has) and the build sees them too.
+    const params = resolveBuildParams(config.buildParams, { env: process.env });
+    if (params.errors.length > 0) {
+        throw new Error(`Build parameters did not resolve — cannot evaluate policy:\n  ${params.errors.join("\n  ")}`);
+    }
+    const env = opts.env ?? resolveOwnershipEnv(config, params.provenance);
+    // chant #2002 — the build options come from the shared assembler
+    // (`../cli/build-options.ts`), the same one `chant build` uses, so the gate
+    // decides on the project `chant build` produces: folded by default (#1134),
+    // with the project's config reaching the serializers, and with
+    // config-declared build roots contributing their entities. Assembling a
+    // second, shorter list here is what let the two drift apart.
+    const modes = resolveBuildModes(config);
+    const warnings = [];
+    if (modes.sandbox) {
+        // Resolved, reported, and not yet honoured. Building inside the boundary
+        // needs per-execution arming (#1157) — until that lands, saying so is the
+        // difference between a known gap and a silent one.
+        warnings.push(`build.sandbox is enabled for this project, but the policy gate builds it in this process — the project's source files and its lint.policies modules execute here, unsandboxed (chant #1157). Run \`chant build --sandbox\` for a sandboxed build of the same project.`);
+    }
+    for (const warning of warnings)
+        console.error(formatWarning({ message: warning }));
+    const result = await build(buildPath, serializers, undefined, resolveProjectBuildOptions({
+        config,
+        configDir,
+        plugins,
+        modes: { fold: modes.fold, sandbox: false },
+        ownership: resolveOwnershipMarker(config, params.provenance),
+        buildParams: params.provenance,
+    }));
+    if (result.errors.length > 0) {
+        throw new Error("Build failed — cannot evaluate policy on a broken build");
+    }
+    const checks = config.lint?.policies?.length
+        ? await loadPolicyChecks(config.lint.policies, configDir)
+        : [];
+    if (checks.length === 0) {
+        return { diagnostics: [], violations: [], env, suppressed: [], warnings };
+    }
+    const raw = runPostSynthChecks(checks, result, env);
+    // chant #1138 — same `lint.rules` resolution `chant build` applies
+    // (`../cli/commands/build.ts`), so a check `lint.rules` turned "off"/
+    // "warning" doesn't gate an apply here even though `chant build` no longer
+    // fails on it either, and vice versa for a check turned UP to "error".
+    const { diagnostics, suppressed } = applyConfiguredSeverity(raw, config.lint?.rules);
+    const violations = diagnostics.filter((d) => d.severity === "error");
+    return { diagnostics, violations, env, suppressed, warnings };
+}

package/dist/lint/post-synth.js

@@ -0,0 +1,87 @@
+import { parseOutputDocs } from "./output-docs.js";
+export { parseOutputDocs, pick, get } from "./output-docs.js";
+/**
+ * Build the lazy, memoized `docs` accessor shared by `runPostSynthChecks`
+ * (below) and `@intentius/chant-test-utils`'s `createPostSynthContext` — the
+ * two places a `PostSynthContext` gets constructed. Returns a zero-arg
+ * function suitable for a `get docs()` object-literal accessor; the first
+ * call parses, every later call returns the same cached array.
+ */
+export function createDocsAccessor(outputs) {
+    let cached;
+    return () => {
+        if (cached === undefined) {
+            cached = parseOutputDocs(outputs);
+        }
+        return cached;
+    };
+}
+/**
+ * Extract the primary content string from a serializer output.
+ */
+export function getPrimaryOutput(output) {
+    return typeof output === "string" ? output : output.primary;
+}
+/**
+ * Extract the ADDITIONAL files from a serializer output — everything
+ * {@link getPrimaryOutput} discards.
+ *
+ * Every post-synth check shipped before this one reads the primary output
+ * only, which means a sidecar file (a nested stack template, committed SOPS
+ * ciphertext) is invisible to all of them. That is the right default — the
+ * primary output is what appliers read — but a rule ABOUT a sidecar has to
+ * be able to see it, and `PostSynthContext.outputs` has carried the data all
+ * along. WK8504 (k8s) is the first caller.
+ */
+export function getAdditionalFiles(output) {
+    return typeof output === "string" ? {} : (output.files ?? {});
+}
+/** Structural type guard — used to collect project-authored policy checks. */
+export function isPostSynthCheck(value) {
+    return (typeof value === "object" &&
+        value !== null &&
+        typeof value.id === "string" &&
+        typeof value.description === "string" &&
+        typeof value.check === "function");
+}
+/**
+ * Run a set of post-synthesis checks against a build result. `env` is threaded
+ * into the context so a check can branch on the current environment/stack, and
+ * `opts.activityContracts` (chant #2101) carries the build's cross-lexicon
+ * activity-contract map to the checks that validate Op steps against it.
+ * `opts.telemetry` is the build's resolved telemetry attribution, and
+ * `opts.projectDir` and `opts.projectConfig` the config the build loaded and
+ * its directory.
+ */
+export function runPostSynthChecks(checks, buildResult, env, opts) {
+    const getDocs = createDocsAccessor(buildResult.outputs);
+    const ctx = {
+        outputs: buildResult.outputs,
+        entities: buildResult.entities,
+        env,
+        buildResult,
+        ...(opts?.activityContracts ? { activityContracts: opts.activityContracts } : {}),
+        ...(opts?.telemetry ? { telemetry: opts.telemetry } : {}),
+        ...(opts?.projectDir ? { projectDir: opts.projectDir } : {}),
+        ...(opts?.projectConfig ? { projectConfig: opts.projectConfig } : {}),
+        get docs() {
+            return getDocs();
+        },
+    };
+    const diagnostics = [];
+    for (const check of checks) {
+        diagnostics.push(...check.check(ctx));
+    }
+    return diagnostics;
+}
+// chant #1138 — `applyConfiguredSeverity` (the `lint.rules` severity-override
+// pass over a set of `PostSynthDiagnostic`s) lives in `./config.ts`, not here,
+// even though it operates on this module's own type. This file is a leaf:
+// every lexicon's post-synth checks import it as a real runtime module (not
+// just for types — `getPrimaryOutput` above is a plain function several
+// checks call directly), so it has to stay cheap to load. `./config.ts` is
+// not cheap — it resolves built-in preset paths via the runtime adapter at
+// module scope — and pulling that into every lexicon's check barrel merely to
+// share one filter function is the wrong trade. `applyConfiguredSeverity`
+// only needs this module's TYPE (`PostSynthDiagnostic`), which costs nothing
+// at runtime, so the dependency runs the other way instead.

package/dist/lint/presets/relaxed.json

@@ -0,0 +1,26 @@
+{
+  "rules": {
+    "COR001": "warning",
+    "COR002": "off",
+    "COR003": "off",
+    "COR004": "off",
+    "COR005": "off",
+    "COR006": "off",
+    "COR007": "off",
+    "COR008": "warning",
+    "COR009": "off",
+    "COR010": "warning",
+    "COR011": "warning",
+    "COR012": "off",
+    "COR013": "off",
+    "COR014": "off",
+    "COR015": "off",
+    "COMP001": "warning",
+    "COMP002": "warning",
+    "COMP003": "off",
+    "COMP004": "warning",
+    "COMP005": "off",
+    "COMP006": "off",
+    "COMP007": "off"
+  }
+}