import type { ValidationIssue } from '@opentask/taskin-task-manager';
/**
 * Nome do arquivo de registro de usuários.
 *
 * O nome repete o do diretório (`.taskin/.taskin-users.json`) por herança: o
 * arquivo nasceu na raiz do projeto e migrou para dentro de `.taskin/` sem ser
 * renomeado. Ver {@link resolveUsersFilePaths}.
 */
export declare const USERS_FILE_NAME = ".taskin-users.json";
/** Diretório de configuração local do Taskin. */
export declare const TASKIN_DIR_NAME = ".taskin";
/**
 * Nome dado ao arquivo legado quando o canônico já existe: nada é apagado, mas
 * o arquivo sai da raiz para não voltar a ser confundido com a fonte de verdade.
 */
export declare const PARKED_USERS_FILE_NAME = ".taskin-users.legacy.json";
/**
 * Os caminhos que o registro de usuários pode ocupar num projeto.
 *
 * @public
 */
export interface UsersFilePaths {
    /** `<root>/.taskin/.taskin-users.json` — o único caminho que o `UserRegistry` lê */
    canonical: string;
    /** `<root>/.taskin-users.json` — onde versões antigas do `initialize()` escreviam */
    legacy: string;
    /** `<root>/.taskin/.taskin-users.legacy.json` — destino de um legado redundante */
    parked: string;
}
/**
 * Resolve os caminhos do registro de usuários a partir da raiz do projeto.
 *
 * @public
 */
export declare function resolveUsersFilePaths(projectRoot: string): UsersFilePaths;
/**
 * Onde o registro de usuários está, de fato.
 *
 * - `missing`: projeto sem registro (estado de um projeto novo)
 * - `canonical`: correto — dentro de `.taskin/`
 * - `legacy`: só na raiz — o `UserRegistry` não lê, todo assignee fica sem resolver
 * - `both`: os dois existem — o da raiz é resto e nunca foi lido
 *
 * @public
 */
export type UsersFileLocation = 'missing' | 'canonical' | 'legacy' | 'both';
/**
 * Descobre em que caminho o registro de usuários do projeto está.
 *
 * @public
 */
export declare function inspectUsersFileLocation(projectRoot: string): Promise<UsersFileLocation>;
/**
 * O que a correção fez.
 *
 * @public
 */
export type UsersFileFixAction = 'none' | 'moved' | 'parked';
/**
 * Resultado da correção do caminho do registro de usuários.
 *
 * @public
 */
export interface UsersFileFixResult {
    /** `moved`: legado promovido a canônico. `parked`: legado redundante tirado da raiz. */
    action: UsersFileFixAction;
    /**
     * `true` quando a mudança foi para o índice do Git. Em `moved`, via `git mv`;
     * em `parked`, a remoção do legado e a adição do canônico, juntas.
     */
    viaGit: boolean;
    /** Caminho de origem, quando houve movimentação */
    from?: string;
    /** Caminho de destino, quando houve movimentação */
    to?: string;
}
/**
 * Aponta o registro de usuários fora de lugar.
 *
 * É o lado analisador: não escreve nada, só descreve o problema — o par de
 * {@link fixUsersFileLocation}, no mesmo desenho de `validateTaskFile` /
 * `fixTaskFile`.
 *
 * @param projectRoot - Raiz do projeto (o diretório que contém `.taskin/`)
 * @public
 */
export declare function validateUsersFileLocation(projectRoot: string): Promise<ValidationIssue[]>;
/**
 * Normaliza o caminho do registro de usuários.
 *
 * Regras, deliberadamente conservadoras — o conteúdo é dado do usuário, nada
 * é apagado nem mesclado automaticamente:
 *
 * - só o legado existe: promovido a canônico (o `UserRegistry` volta a ler)
 * - os dois existem: o canônico é a fonte de verdade e fica intocado; o legado
 *   sai da raiz como `.taskin-users.legacy.json` para o usuário comparar à mão.
 *   Quando o legado era versionado, a remoção dele e a adição do canônico vão
 *   juntas para o índice — ver `parkLegacy`.
 *   Mesclar seria arriscado: o legado costuma conter só o usuário sintético que
 *   o `initialize()` antigo semeava (`$USER` / `<user>@example.com`).
 * - qualquer outro estado: nada a fazer
 *
 * @param projectRoot - Raiz do projeto (o diretório que contém `.taskin/`)
 * @public
 */
export declare function fixUsersFileLocation(projectRoot: string): Promise<UsersFileFixResult>;
//# sourceMappingURL=users-file-location.d.ts.map