用途
本技能是“五阶段结构改造协议”（pentaphase structural-overhaul protocol）的第 3 阶段，主题为“系统选择与环境配置”。其核心任务是把第 2 阶段的概念性分类模型（taxonomy model）转化为一个具体可运行的环境：选择承载该模型的机制，把模式（schema）构建进该机制，并设置校验规则，使不合规条目在入口处即被拒绝。
前置条件
开始前必须完整读取以下三个文件：
<working-dir>/substrate-context.md<working-dir>/phase-1-landscape-report.md（用于规模与摩擦背景）<working-dir>/phase-2-taxonomy-model.md（且已通过第 2 阶段门槛）
四条工作流
工作流 1 — 翻译需求
把分类模型转化为客观、可度量的技术标准。每条标准包含：名称、来源（来自第 1 或第 2 阶段的哪一部分）、类型（容量/性能/集成/治理/成本/运营）、阈值（最低可接受值，必须量化）、权重（must-have / should-have / nice-to-have）。可考虑的标准族包括：规模、查询模式、并发、模式灵活性、访问控制粒度、审计要求、集成面、运营适配、合规姿态。目标为 8–20 条标准。
工作流 2 — 评估机制
针对标准对候选引擎或框架进行基准评估。每个候选（通常 2–4 个）需记录：名称与版本、类别（关系型数据库/文档存储/图/对象存储/CMS/仓库/电子表格/专用 SaaS/自定义）、逐条标准的评分（meets / partial / fails 并附简要理由）、总成本（许可、基础设施、运营时间、集成成本）、锁定风险、与现有基底的兼容性。最终选出胜出者，说明决策理由，并明确指出胜出者在哪些标准上失败或仅部分满足，以及各自的缓解措施。
工作流 3 — 实例化架构
把设计好的分类模型直接构建进所选环境，记录步骤：模式声明（DDL、模式文件、配置清单等，覆盖第 2 阶段的每个实体类和通用模式属性）、关系实现（外键、链接表、嵌入文档、图边等，每个第 2 阶段关系一个）、访问控制实现（角色/权限/策略声明）、索引策略（针对哪些查询模式建立哪些索引）、初始状态（空/种子参考数据/迁移子集）。需提供实际代码或配置，使新操作者仅凭本节即可复现环境。
工作流 4 — 执行校验规则
编写自动化检查，在入口处拒绝不合规条目。每条规则包含：层级（模式级/应用级/管道级）、触发时机（插入/更新/读取/定时）、行为（拒绝/强制转换/警告/隔离）、失败处理（死信队列、错误日志、退回发送方）。至少覆盖：通用模式属性校验（id 格式、所有权存在性、状态枚举）、类特定必填属性校验、关系完整性（孤儿检测、基数强制）、访问层级一致性（写入者不能写入其无权访问的层级）。
输出文件
将四条工作流合并为 <working-dir>/phase-3-environment-spec.md，结构为：标题与元信息（基底、日期、前置条件、后置条件）、1. 选择标准、2. 机制评估、3. 实例化（3.1 模式声明、3.2 关系、3.3 访问控制、3.4 索引、3.5 初始状态）、4. 校验规则、5. 留给第 4 阶段的开放问题。
门槛条件（审计员将检查）
- 至少定义 8 条带阈值和权重的选择标准。
- 至少评估 2 个候选机制，并针对标准给出明确评分。
- 声明胜出者并给出明确理由；胜出者失败或仅部分满足的标准需点名并给出缓解措施。
- 第 2 阶段的每个实体类都有模式声明，不得在实例化中静默丢弃任何类。
- 校验规则至少覆盖通用模式、类特定必填项、关系完整性和访问层级一致性。
- 存在“留给第 4 阶段的开放问题”一节。
反模式
- 不要先选机制再定标准；若机制确已预先决定，需记录原因并用一段理由短路工作流 2。
- 不要静默丢弃实体类；若某类无法干净地适配所选机制，应暴露摩擦，重新设计分类模型或改选机制。
- 不要把校验推迟到“以后再加”；校验规则就是入口门槛，实例化时缺失会导致后续摄入污染新环境。
- 不要跳过索引；第 1 阶段的价值指标（尤其是速度）隐含特定查询模式，应现在就为其建索引。
参考文件
references/selection-criteria.md— 常见标准族及示例阈值references/validation-rules.md— 按机制类别划分的校验模式
限制
本技能的具体实现细节、依赖工具、运行环境、收费方式与价格、平台支持等信息，资料中暂未提供。