jackson-concept-implementationlisted

# Jackson 概念实现（模块单体） 输入是已确认的概念模型（`jackson-concept-design` 的输出：concepts、syncs、依赖图）。本技能只做模型到代码结构的映射，不重开概念讨论；概念边界有疑问回上游技能，存量工程审计用 `jackson-concept-audit`。 ## 映射总则 | 模型元素 | 代码落点 | | --- | --- | | 一个 concept | 一个独立编译单元（模块/crate/包），对外只暴露 actions 与状态查询 | | 类型参数 `[U]` | 泛型参数或不透明 ID（值对象），不引入对方类型 | | state | 模块私有，经 port 抽象持久化；不是全局数据模型 | | actions | 模块的公开方法/服务，含正常与错误两类结果 | | OP | 该模块的集成测试场景 | | sync | 组合层代码：唯一允许同时引用多个概念的地方 | | extrinsic 依赖图 | 构建/交付顺序与产品裁剪（feature/构建开关），不产生代码依赖 | 铁律（intrinsic 禁令的代码化）：**概念模块之间零相互引用**；数据与控制流全部经组合层流动。 概念模块内部按整洁架构分层（端口-适配器）：domain 放不变量与纯逻辑（零外部依赖）、actions 即应用服务（依赖 port 抽象）、adapter 实现 port；组合根是唯一命名具体 adapter 的地方。 ## Sync 的两种落地（官方路线） 1. **过程式 mediator**（默认）：每个应用动作（flow 入口）一个编排函数，顺序调用各概念 actions、组装响应。最简单、最贴近常规 web 实践，Jackson 课程即此教法。 2. **声明式规则引擎**：sync 写成 `when / where / then` 规则（when 匹配动作完成，where 查询概念状态并绑定变量，then 派发后续动作），由引擎执行并留下动作溯源。表达力强、行为增量可按条增删，但需引入引擎运行时。 行为规则多、需要审计追踪或按规则粒度演进时才选 2。 ## Syncs 层范式 syncs 层是应用级的用例层（整洁架构的 use-case 层），没有自己的 domain，不套完整分层。三原则： - **薄**：只做编排与数据流；业务不变量必须在概念的 domain 里，出现在 syncs 里就下沉。 - **无自有持久状态**：某组 sync 开始积攒状态 = 升格为概念的信号，回上游技能。 - **按 flow 组织**：每个 flow 一个模块/文件，与 PRD 的 flow 文档一一对应。 ## 接口层 - **对外 API 只暴露应用动作（即 sync），永不直通概念动作**——概念动作绕过组合层可达，所有 sync 约束（认证、级联、通知）即被穿透。 - 端点 = 组合层入口：路由与 DTO 映射写在接口适配器，概念对 HTTP/协议一无所知，签名中不出现传输格式（JSON、状态码）。 - REST/RPC 入站、webhook 出站等协议适配器全部放 app 边缘的接���模块；契约（OpenAPI/proto）是组合层资产，随应用版本演进，与概念版本无关——同一概念可复用于多个应用，各应用契约不同。 - 官方模式（论文）：外部请求本身是动作——Web 引导概念（`request`/`response`），端点触发 sync，响应也由 sync 产生；认证、鉴权因此