架构边界与分层治理

问题从哪来

Agent 在仓库里持续产出代码时，人工 Code Review 拦不住架构漂移：循环依赖、上层直接摸底层实现、外部 JSON 当 any 在层间乱传——往往不是模型「变坏」，而是它在复刻仓库里已有的坏模式。若依赖方向、数据边界和跨层调用路径没有可机械执行的规则，约束会在几轮生成内被冲垮。

技能怎么落地

本技能面向「边界内自由、边界上严格」的分层设计，核心模式是：固定依赖方向 + 限定合法边 + 横切关注点单一入口。

• 从项目自身推导分层：列出主域/模块，沿数据流从底层类型到 UI 定单向依赖；横切（鉴权、日志、配置）只从约定入口进入，并写入 docs/ARCHITECTURE.md。
• 数据边界：外部进入系统的数据应 Parse, Don't Validate——解析成强类型再向内传递；边界层禁止未解析的 any/字典式访问，用 lint 或脚本可检。
• boundary-auditor 只审不改：读架构文档后，用 grep/rg/find 等做层间 import、循环依赖与数据边界检查；每条发现按 ### [Severity] 给出文件、行号、违反规则、影响与可执行的修复建议（含 Before/After 时更佳）。
• 严重级别与门禁：CRITICAL（循环依赖、跨层越界）与 HIGH（数据边界、横切散落）视为必须修复；风格类交给 harness-golden-principles，并与 harness-verification-loop 衔接。

适用边界

不要照搬固定六层模型——小项目可从 Types → Services → UI 三层起步再演进。纯命名/风格偏好、用户明确不要架构约束、或模块间本无分层需求时，不应触发本技能；微服务场景应在各服务内部定义相同模式，服务间仅通过 API 与共享类型通信。