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

⚠️ 当前状态 complete,title 字段已锁定(仅 draft 可改 title,对齐 CLAUDE.md 定位稳定性)

标题(20-200 字符) · 锁定 title 仅 draft 状态可编辑。如需修改,请先回退到 draft。描述(背景/上下文)

**触发**: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

用户故事验收标准(JSON,数组,每项 given/when/then) 支持 JSON 数组格式。空数组表示无 AC。非功能需求(JSON 对象,key/value 字符串)

优先级负责人

截止日期标签(逗号分隔)