/**
 * Compile-time state shared by the part emitters.
 *
 * The context owns the part registry (part name → content type + optional
 * document-level relationship), the relationship-id allocator, and the
 * ordered file map handed to the zip assembler. All allocation is
 * deterministic: ids are sequential counters, never random, and no part of
 * the compiler reads the clock.
 */
export type RegisteredPart = {
    /** Zip path, e.g. 'word/header1.xml'. */
    name: string;
    /** Content type registered as an Override in [Content_Types].xml. */
    contentType: string;
    /** Relationship from word/document.xml, when the part is document-attached. */
    documentRel?: {
        type: string;
        rId: string;
    };
};
export declare class CompileContext {
    private readonly partsByName;
    private readonly fileContents;
    private nextRid;
    private nextHeaderIndex;
    private nextFooterIndex;
    /** Register a part that needs a content-type Override (content set separately). */
    registerPart(name: string, contentType: string, documentRelType?: string): RegisteredPart;
    allocateRid(): string;
    allocateHeaderPartName(): string;
    allocateFooterPartName(): string;
    setFileContent(name: string, content: string): void;
    registeredParts(): RegisteredPart[];
    documentRelParts(): RegisteredPart[];
    /**
     * Assemble the final zip-file record. [Content_Types].xml is placed first —
     * createZipBuffer preserves insertion order but does not enforce ordering
     * itself, so the contract lives here.
     */
    toFileRecord(): Record<string, string>;
}
//# sourceMappingURL=context.d.ts.map