Import Linter 架构导入边界

问题：当 Python 项目的分层被悄悄打破

随着代码库膨胀，模块之间的导入关系会逐渐失控：views 层直接 import 了数据访问模块，工具包反向依赖了应用代码，或者两个本该独立的子系统开始互相引用。这类架构漂移通常不会导致测试失败，却会让依赖方向变得难以推理，后续的重构和测试成本随之上升。等到问题暴露时，往往已经扩散到大量文件。

核心能力与工作方式

这个技能把 Import Linter 引入工作流，用「契约」的方式声明并校验模块之间被允许的导入关系：

• 分层契约（layered contracts）：声明各层（如 presentation、application、domain、infrastructure）之间的合法导入方向，禁止反向或跨层导入。
• 禁止契约（forbidden contracts）：直接列出不允许出现的导入，例如核心模块不得被外部代码依赖。
• 独立契约（independence contracts）：约束两个包或子系统之间不能存在任何导入关系。

技能的工作方式是：先在项目配置中声明契约，再运行 lint-imports 对全库导入做静态检查。任何违反契约的 import 语句都会在构建或 CI 环节被拦截，让架构破坏在第一时间暴露，而不是逐渐扩散。

适用边界与注意点

• 该工具只做静态导入分析，不追踪运行时通过 importlib 等方式动态加载的依赖。
• 契约需要与真实架构保持同步：架构调整后契约要随之更新，否则检查会持续报错。
• 适合有明确分层或模块边界诉求的 Python 项目，尤其是多人协作、依赖方向容易被无意破坏的代码库。
• 运行环境需要 Python 项目与 pip 或 Poetry 环境。