import { EventEmitter, TemplateRef } from '@angular/core';
import { ComponentState } from '../../types';
import { RequestReviewDecision, RequestReviewItem, RequestReviewPanelMetadata } from './types';
import * as i0 from "@angular/core";
/**
 * val-request-review-panel — cola de revisión del factory (ADR-062).
 *
 * Es **presentacional**: no carga datos, no conoce el backend ni el dominio. El
 * consumer le pasa la cola ya normalizada y escucha `(decision)`.
 *
 * ## Por qué el cuerpo va proyectado y no configurado
 *
 * El ADR original proponía describir el cuerpo con arrays de nombres de campo
 * (`fields.display: ['taxId', 'tagsRequested']`). Al implementarlo con los dos
 * consumidores reales delante quedó claro que eso reinventa un motor de
 * templating peor que Angular: Chesed necesita una lista de documentos con
 * iconos y `target="_blank"`, Okhelia un enlace a la receta y un input de
 * comentario. Ninguna lista de strings expresa eso sin agregarle un flag al
 * componente por cada caso nuevo.
 *
 * Entonces el panel es dueño de lo que **de verdad** se repite — la cáscara, el
 * chrome de la card, y la mecánica de decisión — y el cuerpo de cada ítem lo
 * escribe cada vertical en un `ng-template` con su propio HTML.
 *
 * ```html
 * <val-request-review-panel [props]="panelProps()" [itemBody]="body"
 *                           (decision)="onDecision($event)" />
 *
 * <ng-template #body let-item>
 *   <a [routerLink]="['/app/recetas', recipeIdOf(item)]">Ver receta</a>
 * </ng-template>
 * ```
 *
 * ## Rechazo con motivo
 *
 * El flujo de dos pasos (Rechazar → escribir motivo → Confirmar) es del panel,
 * no del consumer, y está activo por defecto. Rechazar de un click deja al
 * solicitante sin saber qué corregir; era el único de los dos paneles que lo
 * tenía bien resuelto y ahora lo heredan los dos.
 */
export declare class RequestReviewPanelComponent {
    private i18n;
    readonly props: import("@angular/core").InputSignal<RequestReviewPanelMetadata>;
    /**
     * Cuerpo de cada card. El contexto trae el ítem como `$implicit` y también
     * como `item`, para que el consumer pueda usar `let-item` o `let-x="item"`.
     */
    itemBody?: TemplateRef<{
        $implicit: RequestReviewItem;
        item: RequestReviewItem;
    }>;
    decision: EventEmitter<RequestReviewDecision>;
    /** ID del ítem cuyo formulario de rechazo está abierto. */
    private readonly _rejectingId;
    readonly rejectingId: import("@angular/core").Signal<string>;
    private readonly _reason;
    readonly reason: import("@angular/core").Signal<string>;
    readonly cfg: import("@angular/core").Signal<RequestReviewPanelMetadata>;
    readonly skeletonRows: import("@angular/core").Signal<number[]>;
    /** Hay una decisión en vuelo: toda la cola se congela. */
    readonly isBusy: import("@angular/core").Signal<boolean>;
    constructor();
    protected t(key: string): string;
    /** El ítem en vuelo muestra WORKING; los demás quedan deshabilitados. */
    private stateFor;
    protected approveState(item: RequestReviewItem): ComponentState;
    /**
     * Confirmar el rechazo exige motivo cuando `requireRejectReason` está activo
     * (el default). Es el freno que evita la notificación de rechazo vacía.
     */
    protected confirmRejectState(item: RequestReviewItem): ComponentState;
    protected onReasonInput(event: Event): void;
    protected startReject(item: RequestReviewItem): void;
    protected cancelReject(): void;
    protected confirmReject(item: RequestReviewItem): void;
    protected approve(item: RequestReviewItem): void;
    static ɵfac: i0.ɵɵFactoryDeclaration<RequestReviewPanelComponent, never>;
    static ɵcmp: i0.ɵɵComponentDeclaration<RequestReviewPanelComponent, "val-request-review-panel", never, { "props": { "alias": "props"; "required": true; "isSignal": true; }; "itemBody": { "alias": "itemBody"; "required": false; }; }, { "decision": "decision"; }, never, never, true, never>;
}