【框架设计】任务系统骨架：接取、进度、交付的状态流转

实战应用：用在哪里

主线、支线、日常任务共享同一套流转逻辑：接取 → 打怪/收集推进进度 → 达标交付领奖。任务系统骨架把这套流转做成数据驱动：任务表定义目标，进度表记录玩家状态，交付脚本只查表发货。新任务接入 = 加一行任务定义。

任务定义与进度存储

local QUEST_DEFS = {
    q1001 = { type = "kill", target = "黑野猪", goal = 20, reward = { gold = 5000 } },
    q1002 = { type = "collect", item = 1001, goal = 5, reward = { gold = 3000 } },
}

-- 玩家进度表：q1001 = { state = "doing", count = 12 }

打怪触发（QF 的杀怪触发）里调用统一入口：QuestOnKill(player, monsterName)——遍历玩家 doing 状态的任务，类型匹配且目标匹配则进度加一，达标自动把状态切到 deliverable（可交付）。状态机四态：不可接取 → 可接取 → 进行中 → 可交付，非法跳转被入口函数拒绝。

交付与防重

交付接口的四道校验：任务存在、状态为可交付、进度达目标、奖励未领。全部通过后发放奖励、状态置完成、写流水。防重由状态位保证（完成态不再响应交付请求），配合唯一流水号兜底。

日常任务的差异化

日常任务在骨架之上叠加"按日刷新"：进度表按日期分键（当日 key），跨日自动重置。任务池随机分配（从任务池按权重抽 N 个）让每天的日常组合有变化。骨架与差异的边界清晰：骨架管流转，差异只在任务定义与刷新规则——这个划分让任务系统的长期维护成本保持在低位。TXT 引擎的触发对接（杀怪、捡取触发改写进度）沿用触发器瘦身篇的原则：高频触发里只做进度加一与达标判断，其余逻辑全部移出。

任务进度达标时发一条进度达标事件，事件总线的订阅方各取所需：成就系统累计进度、红点系统点亮交付提示、引导系统推进步骤。任务骨架不直接调用其他系统，一切通过事件解耦。任务链（前置任务）的实现也在骨架上：接取校验里检查前置任务状态，前置完成才允许接取，任务链的顺序由配置的前置字段表达。