package jnpf.audit;

import java.util.Arrays;
import java.util.Collections;
import java.util.HashSet;
import java.util.Set;

/**
 * 审计事件常量：event_type 受控枚举 + action_code SDK 内置常量。
 */
public final class AuditConsts {
    /** event_type 受控枚举（spec v2.2 枚举分层治理：新增须经 audit 模块评审） */
    public static final String TYPE_DATA_CHANGE = "DATA_CHANGE";
    public static final String TYPE_BIZ_ACTION  = "BIZ_ACTION";
    public static final String TYPE_E_SIGNATURE = "E_SIGNATURE";
    // JDK 8 兼容写法（仓库有效 maven.compiler.source=1.8，禁用 Set.of 等 Java 9+ API）
    public static final Set<String> VALID_TYPES = Collections.unmodifiableSet(
            new HashSet<>(Arrays.asList(TYPE_DATA_CHANGE, TYPE_BIZ_ACTION, TYPE_E_SIGNATURE)));
    /**
     * action_code SDK 内置常量：**只内置最基础的三种数据动作**（开放命名空间，业务仍可自定义大写蛇形）。
     *
     * <p>业务动作变体（禁用/启用/审批/驳回/归档/发布…）一律<b>不再新增常量</b>——它们本质都是
     * 这三种之一，按业务语义枚举下去永远加不完。正确做法是用最接近的基础动作打底，
     * 把"具体是哪一种"交给细化字段承载：
     * <pre>
     *   禁用用户 → actionCode = UPDATE
     *              actionLabel = "禁用用户"                （人读语义）
     *              fieldDiffs  = enabled_mark: 1 → 0       （字段级 before-after，机器可判）
     *              reason / extra                          （需要原因或额外结构化信息时）
     * </pre>
     * 这样既能按 UPDATE 统一筛选统计，又比多一个枚举值携带更多信息。
     */
    public static final String ACT_CREATE = "CREATE";
    public static final String ACT_READ   = "READ";
    public static final String ACT_UPDATE = "UPDATE";
    public static final String ACT_DELETE = "DELETE";
    /** 复核（在线表单「复核」按钮，由 lims_sign.meta_data.is_review_button 判定）。 */
    public static final String ACT_REVIEW = "REVIEW";
    /**
     * 例外：CORRECTION 不是业务动作，而是审计域自身的元操作——更正一条已写错的审计记录
     * （append-only 下靠追加新事件实现，契约 {@code extra.correctsEventId} = 被更正事件 id，spec §4.3）。
     * 它必须能与"业务数据被修改"区分开，降级成 UPDATE 会丢掉这个区分，故保留。
     */
    public static final String ACT_CORRECTION = "CORRECTION";
    private AuditConsts() {}
}