用途
Architecture Model Bootstrap 用于把 Impact 面板生成的确定性候选模型，精炼为读者可以确认的模型。服务器已经从工作区推导出一个有边界、有依据的骨架：一个 SoftwareSystem、每个工作区清单对应一个 Container、源代码目录对应 Component。该技能承担静态分析器无法完成的语义工作：命名、分组、归类、描述，并提出代码仅暗示的外部系统，同时不虚构证据不支持的结构。
默认使用仓库的回复语言。保持编辑有依据且可逆：输出是一份供人保存的提案，而不是你断言的事实。
何时使用
- 项目未声明任何模型，Impact 面板回退到生成的模型。
- 读者希望在把生成的骨架保存为已声明模型之前对其进行精炼。
- 已有的已声明模型需要根据当前代码对元素进行重命名、合并、拆分、重新归类或补充描述。
不要用它来虚构没有证据支持的业务能力、运行时流量或外部系统。按照父规范的非目标，L1 系统上下文和外部系统保持为提案状态并由人工确认。
输入（证据包）
在提出任何内容之前，先收集以下材料：
- 生成的候选模型。在任意提交上打开 Impact 面板，或读取服务器将生成的模型——一个 SoftwareSystem、每个工作区清单对应一个 Container、每个源代码目录对应一个 Component，每个元素都标记为 generated，外加把路径 glob 映射到元素 id 的绑定。
- 工作区清单。package.json（根目录和嵌套目录），以及任何 Cargo.toml、go.mod、pyproject.toml 或类似的边界标记。
- 目录证据。已跟踪的路径列表和顶层源代码布局，使提出的边界指向真实路径。
- 文字证据。README.md、AGENTS.md、docs/、ADR——仅用于名称、归属和已声明的外部依赖，绝不用于与代码相矛盾的结构。
工作流程
- 读取候选模型和清单。在改动任何边界之前，先确认生成器找到的真实边界。
- 命名和描述。用项目自己的词汇替换通用 id/名称（packages-api、src）。为每个保留的元素给出基于其文件实际作用的一行描述。
- 在证据支持时重新归类。可部署/独立拥有的单元是 Container；其中一个内部的构建块是 Component。没有边界标记（清单、入口点、部署目标）时，不要把目录提升为 Container。
- 合并和拆分。把属于同一组件的兄弟目录合并；把明显承载两个组件的目录拆分。每个结果元素至少保留一个真实路径 glob。
- 提出能基于导入、HTTP 客户端或已声明依赖建立依据的关系。为每个关系标注其类型（Contains、Imports、ResolvedCall、DeclaredHttp、DeclaredRelationship）。无法解析的边宁可省略，也不要猜测目标。
- 仅作为明确标注的候选提出外部系统和人员，并在描述中指明证据（客户端、环境变量、README 声明）。这些是父规范保持人工确认的 L1 层级。
- 依据 Model Schema 验证形态，然后把模型和绑定交回，供读者通过 Impact 面板的 Save as declared model 操作保存。除非读者要求，否则不要自己写文件。
依据规则（硬性约束）
- 你保留的每个元素必须至少有一个绑定，其路径 glob 匹配真实已跟踪路径。没有证据就没有元素。
- 绝不要为工作区中不存在的路径虚构绑定。
- 严格保持 arch-core 形态：elements（snake_case 的 parent_id）+ relationships（source_id/target_id）。这是 Impact 宿主消费、发现流程验证的形态。
- 目录不是组件，仓库不是容器。边界需要标记，而不仅仅是一个文件夹。
- 提出的外部系统、人员和 L1 上下文是供人工确认的候选，并在描述中如此标注。
输出
返回两个产物，可直接用于 Save as declared model：
- model.json——精炼后的 { elements, relationships }，采用 arch-core 的形态。
- bindings.json——[{ "path_glob": "...", "element_id": "..." }]，每个 glob 都可在工作区中解析。
简要说明你重命名、合并、拆分、重新归类和建议了哪些内容，以及哪些元素仍是低置信度候选，读者应优先检查。