用途：当需要在 architecture/ 目录中创建、审查或更新架构文档时使用，包括重构、功能变更之后。文档目标是让已了解项目用途的读者能自信地阅读源码，回答“如何运作、为何这样设计”，提供项目及生态的总体视角，而非替代读代码或逐行复述实现。
主要能力：解释组件及其职责、关键术语（如 slot、envelope）、系统边界、关键设计决策与原因，并指明深入源码的位置。文档按编号建议阅读顺序，00-overview.md 负责导览，后续文档逐层建立在前面概念之上；结构可随系统演进拆分、合并或重组，编号只表示阅读顺序而非固定分类。
使用原则：做桥梁而非摘要，聚焦概念与边界；引用包/目录而非具体文件行，避免路径失效；只记录理解系统形态所需的重要包，通用工具包不必提及；记录边界（IPC 消息、HTTP API 契约、镜像标签、环境变量）而非内部实现；解释“为什么”，每个主要结构选择附一两句理由。
更新判断：边界或接口变化需更新，包括增删 IPC 消息类型、HTTP 端点、CLI 命令、构建流水线步骤、Dockerfile 结构、pkg/ 或 crates/ 下新顶层包、组件通信方式变化、新设计决策或理由变化。组件内缺陷修复、不改变接口的内部重构、性能改进、测试变更无需更新。
准确性审查：逐条指出文档中的组件名、包位置、协议消息、环境变量、构建步骤、CLI 命令等声明，与源码核对是否存在且描述正确；优先修复结构性问题（描述不存在或根本不同）和误导性问题（技术上正确但给出错误心智模型），缺失的边界或接口内容可补充，过时引用择机修复。
写作规范：先读现有架构文档，匹配其语气与细节程度；保持清晰精确，避免空洞修饰语。图表可用 Mermaid 或 ASCII，每张图聚焦一个概念。
当前事实基线需在所有文档中保持一致：Coglet（Rust/Axum + PyO3）是唯一运行时；Pydantic 不是核心，静态 schema 由 Go 侧基于 tree-sitter 生成并直接输出 OpenAPI，解析失败会阻止构建；SDK 与 coglet wheels 在 Docker 构建时从 PyPI、环境变量或本地 dist/ 解析，不嵌入 Go 二进制；三个代码库为 cmd/cog/ 与 pkg/（Go CLI 与构建工具）、python/cog/（Python SDK）、crates/coglet/ 与 crates/coglet-python/（Rust 预测服务器及 PyO3 绑定）。