/**
 * Phase 9a — workspace.json schema (WARN-MODE).
 *
 * Registry-driven validator that flags secret-shaped material anywhere in a
 * workspace.json blob. In 9a the validator runs but only *logs* violations;
 * the write proceeds. Phase 9b will route writers through the validator, and
 * 9c will flip rejections on.
 *
 * The detector reuses `findSecretLeaks()` from `bundle.ts` — the goal is
 * that import-time, export-time, and save-time agree on what "looks like a
 * secret" so leaks can't slip through one path while another rejects them.
 *
 * Output format is the structured single-line shape from the plan §5:
 *   [schema-warn] workspace_config: field '<path>' has secret-shaped value
 *     (registry: <key.name>, classification: <classification>)
 *
 * One line per violation. No multi-line stack traces. Cheap to grep, cheap
 * for downstream log routing to redact further once Phase 11's sanitize()
 * is wired.
 */
import { z } from 'zod';
/**
 * Phase 9c — strict-mode error.
 *
 * Thrown when `STUDIOGRAPH_SCHEMA_STRICT` is on (default) and the
 * workspace or connector validator finds at least one violation.
 *
 * **The error message MUST NOT contain the offending value.** Only the
 * field path, registry classification, and a remediation hint are
 * exposed — exactly what a route handler can log and surface to the
 * user without re-leaking the secret.
 *
 * Routes that catch this translate it to:
 *   - HTTP 400 with error code `schema_violation` (config-api, etc.)
 *   - CLI exit 1 with a red message (sync, clone, join, ...)
 *
 * Callers can read `violations` and `scope` to build their own message.
 */
export declare class SchemaViolationError extends Error {
    static readonly code: "schema_violation";
    readonly code: "schema_violation";
    readonly scope: 'workspace_config' | 'connector_config';
    readonly violations: ReadonlyArray<SchemaViolation>;
    constructor(scope: 'workspace_config' | 'connector_config', violations: SchemaViolation[]);
}
/**
 * Phase 9c — runtime check for strict mode.
 *
 * Read at validation time (not cached at boot) so operators can flip the
 * env in a hotfix without restarting the process. Default behaviour
 * (env unset) is strict — `'0'` and `'false'` are the only opt-outs.
 */
export declare function isSchemaStrict(): boolean;
/**
 * A structured violation. Returned by `validateWorkspaceConfig()` so callers
 * can choose to log, reject, or aggregate. The default warn-mode wiring
 * passes these straight to `console.warn` via `formatViolation()` below.
 */
export interface SchemaViolation {
    /** Dotted path within the validated object. */
    path: string;
    /** Canonical registry key this path resolves to, if any. */
    registryKey?: string;
    /** Registry classification (`bootstrap`, `workspace-secret`, …). */
    classification?: string;
    /** Why the detector flagged the value. */
    reason: 'registry' | 'value-shape' | 'connector';
}
/**
 * Top-level shape. Loose by design in 9a — we keep unknown fields so
 * upstream callers (workspace.ts writeConfig, dual-write mirrors) don't
 * regress on perfectly valid existing data. Phase 9b/c can tighten this to
 * `.strict()` once the warn-mode telemetry shows what real data looks like.
 */
export declare const WorkspaceConfigSchema: z.ZodObject<{
    version: z.ZodOptional<z.ZodString>;
    team_name: z.ZodOptional<z.ZodString>;
    name: z.ZodOptional<z.ZodString>;
    slug: z.ZodOptional<z.ZodString>;
    created_at: z.ZodOptional<z.ZodString>;
    repos: z.ZodOptional<z.ZodArray<z.ZodUnknown>>;
}, z.core.$loose>;
/**
 * Run the secret-leak walker over a workspace.json blob and return a list of
 * structured violations. The walker uses `findSecretLeaks()` from bundle.ts,
 * which understands:
 *   - registry-named paths (`r2_config.secret_access_key` → bootstrap)
 *   - bootstrap field names (`jwtSecret`, `apiKey`)
 *   - value-shape patterns (`sk-*`, `Bearer *`, `https://user:pass@…`, etc.)
 *
 * The validator does NOT mutate, throw, or reject — it just produces the
 * violation list. Callers that want strict behaviour wrap it in their own
 * `if (violations.length) throw` check (Phase 9c).
 */
export declare function validateWorkspaceConfig(input: unknown): SchemaViolation[];
/**
 * Format a single violation as the warn-mode log line. Stable, greppable,
 * one line per violation. Phase 11's `sanitize()` is responsible for any
 * further redaction once the centralized logger lands.
 */
export declare function formatViolation(scope: 'workspace_config' | 'connector_config', v: SchemaViolation): string;
/**
 * Warn-mode entry point: validate + log each violation via `console.warn`.
 * Returns the violation list so callers (tests, telemetry) can also
 * inspect what was found.
 *
 * The logger seam is `console.warn` for 9a; Phase 11 will swap this for the
 * centralized `log.warn` once that lands. Using `console.warn` here keeps
 * the import graph small and avoids a Phase-11 dependency.
 */
export declare function warnOnWorkspaceConfigViolations(input: unknown): SchemaViolation[];
/**
 * Phase 9c — strict-or-warn entry point used by save sites.
 *
 * When `STUDIOGRAPH_SCHEMA_STRICT` is on (default), throws
 * `SchemaViolationError` on the first non-empty violation list. Otherwise
 * delegates to `warnOnWorkspaceConfigViolations` for log-only behaviour.
 *
 * This is the canonical helper that `Workspace.writeConfig` should call.
 * Tests can flip the env to exercise both modes.
 */
export declare function enforceWorkspaceConfig(input: unknown): SchemaViolation[];
