重新思考架构层级抽象分层(基于 16872a2f / 290f0450 实施经验)

📝 描述

**触发**:16872a2f 实施时发现 sdlc-workflow 是 L2 但要编排其他 L2 skill(sdlc-requirement/design/code/operate/feedback),按 CLAUDE.md "L_n 只能引用 L_{n-1}" 严格分层原则不合规,需要为「编排型 skill」开分层口子(已临时决定允许)。但这只是「现象处理」,没回答「根因 — 现有分层是否合理」。 **待研究问题**: 1. L0 基础设施 / L1 平台工具 / L2 能力 / L3 应用 这 4 层对 skill + 组件是否都适用? 2. "编排型 skill"(sdlc-workflow)应该独立一层(如 L3_orchestration),还是允许 L2 内编排放行? 3. sdlc 总入口(L3)只做编排,sdlc-workflow(L2)做 SDLC 8 阶段编排 — 编排逻辑分散在哪一层最合理? 4. 现有 14 个 skill 的层次归类是否要调整?(如 sdlc-feedback-watchdog 当前算 L2 派生,是否要独立?) 5. 是否需要新增 "L_meta" 层承载 cross-cutting 关注点(如 audit / consolidate-claude / doubt-driven-development)? **关联**:290f0450 的 status syncer 可能也要按新分层归位(候选 L0_infrastructure,因它跨阶段调用 arch-platform-cli 不依赖任何业务 skill)。 **How to apply**:本需求是「再设计」类,实施时建议先建立新分层的 ADR 草案 → 评审 → 然后再批量调整现有 skill 归层。Phase 0-2 用 doubt-driven-development skill 做对抗式审查。 --- ## 🎯 新增子需求: arch ComponentBase 加 runtime_dependency 字段(2026-06-22 用户指示记录) **触发**: REQ-16872a2f Phase 3 实施时 FB-76dd519a 认知修订 — 14 个 skill 全 atomic=true(独立单元,代码层不 import 其他 skill),LayeringCheck 0 finding 是正确结果,不是 bug。 **真正问题**:arch 平台缺 `runtime_dependency` 字段,追踪 skill 间运行时/编排依赖关系(CLI 调 / manifest 引用 / scheduling / API 调),与 composed_of(代码层 import 依赖)正交。 **已有线索**: - CLAUDE.md 分层原则只定义了 composed_of(代码逻辑组合 L_n → L_{n-1})和 runtime_dependency(L3→L1/L0) - 但 ComponentBase schema 只有 composed_of,缺 runtime_dependency - "L3 可直接引用 L1/L0(物理依赖不可避免)"这一规则当前没有 schema 字段承载,纯靠人工约束 **期望行为**(2026-06-22 用户指示记录): 1. **新字段**: `runtime_dependency: Optional[List[ComposedOfEntry]] = None`(复用 ComposedOfEntry 结构 = {component_id, version_constraint}) 2. **位置**: ComponentBase,与 composed_of 并列 3. **同步更新**: ComponentCreate / ComponentUpdate / ComponentOut 都加该字段 4. **业务规则**: - 允许 L_n → L_n 引用(任何层可运行时依赖同层,如 audit 运行时调 arch-platform-cli 查询 dependency 图,二者都是 L1) - 允许 L_n → L_{n-k}(任意下层,如 L3 → L0) - **禁止** L_n → L_{n+k}(向上引用,如 L1 不能依赖 L3) - cross-cutting 关注点(audit / consolidate-claude / doubt-driven-development)允许跨任意层 5. **LayeringCheck 新规则**: - 检查 runtime_dependency 是否违反"禁止向上引用" - 检查 composed_of 仍是 L_n → L_{n-1}(仅编排型 skill 白名单允许 L2→L2 例外) 6. **migration**: - 已有的 14 个 skill + 13 个 L1_platform 组件按设计文档 §3 候选矩阵批量补 runtime_dependency - 16872a2f 撤回后状态机推进: scheduled → in_progress(等本需求设计定稿) **依赖关系**: 本子需求是 16872a2f 的真正解决方案(替代原本错误的"补 composed_of"方向),也是 290f0450 status syncer 的归位依据(L1_platform 还是 L0_infrastructure?) **Priority**: P1(原 16872a2f 是 P2,但认知修订后,本需求实际承担 16872a2f 全部价值 + 衍生 LayeringCheck 完整化,升 P1) **触发 phase**: - 本子需求独立推进,Phase 1 完成(本 description 即描述) - Phase 2 设计: 由本会话 reviewer 拍板后,启动 ADR 草案 - Phase 3 实施: 修后端 ComponentBase + ComponentUpdate schema + LayeringCheck 新规则,批量补 runtime_dependency - 16872a2f 完成后 wontfix 关闭,标记 fixed by 1f45f486

👤 用户故事

作为架构师,我在跑 16872a2f(13 个 skill 补 composed_of)和 290f0450(SDLC status 自动推进)时,发现现有的 L0/L1/L2/L3 四层划分可能不够清晰或不够合理。需要重新审视:1) 应该设置多少个层级?2) 每个层级的定位是什么?3) 各层之间的依赖关系应该怎么约束?4) 现有 13 个 skill 是否需要重新归层?

🏷️ 标签

layering redesign architecture follow-up-of-16872a2f follow-up-of-290f0450 key-priority deployed-v0.2.0 pr9-merged verified-bulk-fill-done audit-passed 40-components-patched

🔄 推进状态