package com.ruoyi.common.core.service;

/**
 * 出入院随访模块<b>下沉给宣教模块</b>的最小接口：生成一条"宣教类"随访子任务。
 *
 * <h3>为什么需要它（以及为什么放 ruoyi-common）</h3>
 * 宣教（{@link PublicityApi}）与出入院随访是<b>互相调用</b>的：
 * <ul>
 *   <li>{@code ruoyi-inhospvisit} 的 {@code dealOutHospInfo} 要调 {@link PublicityApi} 决定"要不要宣教"；</li>
 *   <li>{@code ruoyi-publicity} 判定"要发"之后，又要把建子任务交回 inhospvisit
 *       （这样 {@code boxedServiceSubtask} 的宣教分支 type=0/4/5 全仓只有一份实现）。</li>
 * </ul>
 * 若 publicity 直接依赖 inhospvisit，就形成 {@code inhospvisit <-> publicity} 双向依赖 → Maven 构建失败。
 * 所以把"宣教模块唯一需要的那一个能力"下沉成本接口放在 ruoyi-common，
 * 两边都只依赖 ruoyi-common，运行时按类型查找实现（取不到就降级）。
 *
 * <h3>和 ruoyi-inhospvisit 里那个同名能力的关系</h3>
 * 本接口只有 1 个方法，是给宣教模块用的<b>最小面</b>；
 * {@code com.ruoyi.inhospvisit.api.InhospVisitApi} 是完整契约（含出院随访主扫描、任务组轮次滚动等），
 * 供直接依赖该模块的 smartor / ruoyi-quartz 使用。
 * 两者由同一个常驻门面 {@code InhospVisitFacade} 一并实现，因此按任一种类型查找都能拿到同一个 Bean。
 * <p>
 * <b>刻意不做继承</b>：若让完整契约继承本接口，本接口就会"声称"自己也有那些方法，
 * 而按本接口编译的代码运行期却拿到完整实现 —— 这正是满意度模块"门面把自己当实现"
 * 那类假象的翻版，会掩盖配置错误。
 *
 * @see PublicityApi 调用方
 */
public interface PublicitySubtaskApi {

    /**
     * 为某个患者生成一条"宣教类"随访子任务（type=0 药品宣教 / type=4 入院科室 / type=5 入院病区）。
     * <p>
     * 这是给 {@code ruoyi-publicity} 用的：宣教模块判定"该发"之后，
     * 把建子任务这件（含 {@code boxedServiceSubtask} 的宣教分支、回写 check_flag）交回 inhospvisit。
     *
     * @param taskid   命中的长期宣教任务ID
     * @param patid    患者档案ID
     * @param inhospid 出入院记录ID
     * @param type     0=药品宣教（出院维度）/ 4=入院科室 / 5=入院病区
     * @param config   {@code sys_config: visit.early.day} 的值，可能为 null
     * @return true = 已生成（或按原逻辑被标记为不执行）
     */
    boolean generatePublicitySubtask(Long taskid, Long patid, Long inhospid, int type, String config);
}