/**
 * `.d.ts` assembly for `weft codegen`'s active-workflow projection.
 *
 * Consumes the active workflow projection of a registry snapshot
 * (`Record<name, CodegenWorkflowEntry>`, projected from its v2 manifest
 * array by `codegen-validate.ts`'s `resolveActiveWorkflowEntries`) and
 * produces a single `.d.ts` string that augments the public
 * `'@lostgradient/weft'` module with typed `WorkflowRegistry` entries. The
 * output is byte-stable across runs with the same input: keys are sorted
 * with explicit codepoint comparators, property names and string-literal
 * values are uniformly double-quoted via `emitStringLiteral`, and there are
 * no timestamps or environment-dependent paths.
 *
 * The augmented `WorkflowRegistry` interface is the single source of truth
 * for per-workflow input/output typing across the whole public surface:
 * `engine.start`, `WorkflowHandle.result()`, AND the client
 * (`WeftClient.start`/`schedule` and `ClientHandle.result()`). The client
 * overloads key off this interface, so emitting one declaration narrows
 * both engine and client call sites — there is no separate client-specific
 * emission, and skipping codegen leaves both usable with plain string
 * names. Every entry also carries `revision`/`workflowVersion` as
 * string-literal fields for compile-time introspection; neither is
 * required by `engine.start`/`WeftClient.start`/`.schedule()`, which read
 * only `input`/`output` structurally (`WorkflowInput`/`WorkflowOutput` in
 * `core/types/workflow-registries.ts`) — an ordinary start needs no
 * caller-supplied revision.
 *
 * Activity names are no longer emitted as a global `ActivityTypes` module
 * augmentation — that interface was removed when the chained workflow
 * builder made activity names a per-workflow concern (typed at the
 * builder's `.activities({...})` step). The snapshot still carries
 * activity schemas because the same registry feeds discovery and MCP
 * tooling, but the emitter intentionally drops them from the generated
 * `.d.ts`.
 *
 * When two or more workflow entries' `inputSchema`/`outputSchema` render to
 * the same non-trivial TypeScript text (see `codegen-emit-dedup.ts` — grouped
 * by the emitted text itself, not by a JSON-level normalization of the
 * source schema, so schemas differing only in an order-insensitive JSON
 * construct like `required` array order still dedupe correctly), that text
 * is hoisted into a single, unexported, file-top-level
 * `type __WeftSchema_<hash> = <TS type>;` alias declared BEFORE
 * `declare module '@lostgradient/weft' { ... }` — never inside it.
 * Placing an alias inside the augmentation block would make it a
 * pseudo-public exported type name of `@lostgradient/weft` (autocomplete
 * pollution for every consumer), and because TypeScript `type` aliases
 * don't structurally merge the way `interface` does, two independently
 * generated `.d.ts` files declaring the same content-derived alias name
 * inside the same augmented interface would collide with a real
 * "Duplicate identifier" compile error the moment both landed in one
 * TypeScript program. File-scoped placement avoids both problems.
 *
 * @module cli/codegen-emit-registry
 */
export { CodegenEmitError } from './codegen-emit-keywords.ts';
/**
 * One active workflow's codegen-relevant metadata: its input/output
 * schemas plus the `revision`/`workflowVersion` identity fields every
 * generated entry now carries. Deliberately narrower than, and separate
 * from, `core/registry-workflow-manifest.ts`'s `RegistryWorkflowEntry` —
 * that type also describes the full registration-time shape fed into
 * `buildWorkflowRevisionManifest` itself (which doesn't yet have a
 * `revision` to attach — a manifest can't carry the revision of the
 * manifest used to build it), so widening it here would be circular.
 * `description`/`tags` are carried through for parity with the source
 * manifest and future codegen features, but this batch does not emit them
 * into the `.d.ts` (see the module's `openQuestions` in its planning
 * record — emitting free-text description as a JSDoc comment reopens the
 * same injection-safety surface WFT-5 closed for the contract module, and
 * is out of scope here).
 */
export type CodegenWorkflowEntry = {
    inputSchema?: Record<string, unknown>;
    outputSchema?: Record<string, unknown>;
    description?: string;
    tags?: ReadonlyArray<string>;
    revision: string;
    workflowVersion: string;
};
/**
 * Emit the full `.d.ts` declaration string for a registry's active workflow
 * projection.
 *
 * The output is deterministic: keys are sorted by codepoint, property
 * names and string-literal values go through {@link emitPropertyKey}/
 * {@link emitStringLiteral}, unions/intersections are always parenthesized
 * so they compose correctly when nested, and hoisted schema aliases are
 * sorted by alias name.
 */
export declare function emitRegistryDeclaration(activeWorkflows: Record<string, CodegenWorkflowEntry>): string;