随着项目增长，如何设计 monorepo 结构与工作流以保持 Claude Code 的一致性？

我正在使用 Claude Code 开发一个项目，随着代码库的增长，我开始遇到一些问题。首先，我不得不一次又一次地向 Claude 重复同样的规则和约束。尽管我已经编写了项目指令，并通过 ADR（架构决策记录）记录了架构决策，但它逐渐开始违反这些规则、走捷径，或者做出与预期架构不一致的改动。其次，我的上下文窗口消耗速度远超我的预期。我怀疑这可能与我的仓库结构以及项目文档和指令的组织方式有关。这让我开始质疑，当前的 monorepo 结构和开发工作流从长远来看是否真的可持续。我希望获得系统性解决问题的建议，而不是继续用更多指令来打补丁。以下几个方面我特别感兴趣： 仓库架构：构建可维护的 monorepo 的最佳实践，包括如何组织模块、定义边界以及防止架构漂移。我读过 DDD（领域驱动设计）和六边形架构，但不确定它们是否适合我。 Agent 指令与强制执行：CLAUDE.md、AGENTS.md、ADR、skills、hooks 和自动化检查应该如何协同工作？哪些规则应该写成文档，哪些应该通过机制强制执行？ 上下文管理：如何在不丢失重要架构知识、也不迫使 Claude 重新阅读整个代码库的前提下，减少不必要的上下文消耗？ 工作流与方法论：是否存在经过验证的实践、工具或开发工作流，能让 Claude Code 在项目增长时更加可靠？ 其他盲点：我的问题诊断是否正确？主要问题会不会出在我委派任务的方式、范围变更、架构决策的管理，或者对 agent 工作成果的验证上，而不是仓库结构本身？ 我不一定在寻找某个具体的 skill 或工具推荐（当然也欢迎）。我更希望了解那些有经验的开发者在用 Claude Code 构建大型项目时行之有效的底层原则和实践。如果要从零开始，既要打造一个可长期维护的代码库，又要让 AI 编码 agent 始终如一地遵守架构约束，你会如何着手？