注：本技能主锚行业已切换为 ai-video（视频内容创作）；文中酒店示例为历史参考案例。
行业一线作业与know-how深度调研方法论
一、技能定位
1.1 这个技能解决什么问题
当HyperReality进入一个新行业时，仅知道"竞品在做什么"（技能一的产出）是不够的。还必须深度理解：这个行业里的人，每天到底在做什么？他们的工作流程是什么？哪些环节是机械重复的？哪些环节需要判断？哪些环节必须人来做？
这个技能就是回答这些问题的"元方法论"。它从人类视角（而非系统视角）深度还原一线从业者的日常工作全貌，挖掘可被AI替代或增强的环节，为HyperReality行业Bundle的SOP设计和Skills开发提供"行业know-how"输入。
核心理念：HyperReality要"重构经营"，必须先"懂经营"。而"懂经营"的本质，是懂经营者在每个环节做什么、想什么、痛什么。
1.2 何时调用
- HyperReality进入新行业，行业Bundle开发前（与技能一并行）
- 已有行业Bundle需要深化某个业务域时（如酒店版的"在住域"需要深化）
- 需要验证"AI替代可行性"假设时（某个环节真的能被AI替代吗？）
- 需要沉淀行业know-how为Skill时（优秀从业者的经验如何固化？）
1.3 调用者
- 行业交付工程师（负责行业Bundle的SOP设计）
- 产品团队（负责Skills的功能设计）
- 行业合作伙伴（提供行业know-how输入）
1.4 与其他技能的关系
本技能与技能一是并行独立的两个调研技能，两者的产出共同作为技能三的输入：
技能一（竞品调研）──┐
├──→ 技能三（落地完整方案设计）──→ 可交付研发团队的方案
技能二（一线调研）──┘ ↑
│
HyperReality底座（代码+PRD兜底）
- 输出 → 技能三（落地方案设计）：AI替代可行性矩阵、工作流程拆解，直接指导SOP设计和Skills开发
- 输出 → HyperReality底座：行业know-how沉淀为一店一档默认值、围栏基线规则、Skill方法论
- 与技能一无先后依赖：两者可在同一行业并行执行；若技能一已完成，其产出可作为本技能的参考输入之一（非必需，如提示"竞品未覆盖环节"作为调研关注点）
- 将一线环节映射到HyperReality能力前，必须执行附录A的"动态读取前置环节"
二、适用场景
2.1 典型场景
场景一：新行业一线作业全景调研 HyperReality进入餐饮行业，需要深度还原餐厅店长、前厅服务员、后厨厨师、外卖打包员的日常工作全貌，挖掘可被AI替代或增强的环节。
场景二：特定业务域深化 酒店行业的"在住域"需要深化——客人在住期间的每个触点、每个服务环节、每个可能的AI增强机会，需要更细粒度的调研。
场景三：无人业态特殊场景调研 无人酒店、无人餐厅、无人零售等新业态，需要分析其"全流程自动化中的断点"和"兜底方案"。
场景四：行业know-how结构化 资深行业合作伙伴有一二十年的行业经验，需要把这些"隐性经验"结构化为"显性Skill"——本技能提供结构化的框架。
2.2 不适用场景
- 集团连锁企业的一线调研（HyperReality目标客群是中小单体，集团流程不适用）
- 纯技术系统的调研（本技能聚焦"人的工作"，不是系统功能）
- 宏观行业分析（本技能是微观的一线作业，不是宏观市场）
三、方法论：四层深度还原
3.1 核心原则
原则一：人类视角，不是系统视角。 调研的起点是"人每天在做什么"，不是"系统有什么功能"。先还原人的工作，再看系统如何支撑（或阻碍）人的工作。
原则二：全流程覆盖，不留盲区。 从早到晚、从预订到离店后、从前台到后厨，每个环节都要覆盖。任何一个环节的遗漏，都可能导致SOP设计的盲区。
原则三：know-how显性化。 优秀从业者的"隐性经验"（如"怎么排房""怎么调价""怎么处理客诉"）必须被结构化为"显性Skill"。经验不能随人走。
原则四：AI替代可行性分级。 每个环节都要评估AI替代可行性——完全替代/人机协作/保留人工。这是HyperReality围栏设计的依据。
3.2 四层还原框架
第一层：角色全景还原
还原目标：理解每个一线角色"是谁"和"怎么工作"。
还原步骤：
- 角色画像：年龄、学历、从业经验、流动性、技术能力、核心职责。
- 工作特征提炼：用几个关键词概括其工作特征（如店长的"三高一低"：高碎片化、高决策密度、高情绪负荷、低系统化）。
- 一天的时间线还原：从早到晚，每个时段做什么？以Mermaid flowchart绘制24小时时间线。
- 核心工作模块识别：把一天的工作归纳为若干核心模块（通常6-8个），每个模块是一个可独立分析的工作单元。
输出要求：
- 角色画像表
- 工作特征关键词
- 24小时时间线图（Mermaid flowchart）
- 核心工作模块清单（6-8个）
第二层：核心工作模块深度拆解
还原目标：理解每个工作模块"怎么做"和"痛在哪里"。
还原步骤： 对每个核心工作模块：
- 标准流程还原：这个模块的标准流程是什么？以Mermaid flowchart绘制（输入→处理→输出）。
- 痛点识别：这个模块的痛点是什么？（通常从"耗时""易错""不及时""不沉淀"等维度识别）
- 时间黑洞分析：这个模块中，哪些环节是"低价值高耗时"的时间黑洞？（以Mermaid quadrantChart绘制时间价值矩阵）
- AI增强机会识别：这个模块中，哪些环节可以被AI替代或增强？增强方向是什么？
输出要求：
- 每个模块的标准流程图（Mermaid flowchart）
- 每个模块的痛点清单
- 时间价值矩阵（Mermaid quadrantChart）
- AI增强机会表（模块|AI替代可行性|增强方向|对应HyperReality能力）
第三层：行业痛点与AI替代可行性矩阵
还原目标：系统评估"哪些工作AI能替代、哪些需要人机协作、哪些必须保留人工"。
还原步骤：
- 行业特有效率瓶颈识别：这个行业有哪些特有的效率瓶颈？（根源分析：规模小/资源少/系统弱等结构性问题）
- 收益流失点分析：这个行业的收益流失点在哪里？（通常6-8个，每个估算流失量级）
- AI替代可行性矩阵构建：把所有工作环节分为三级：
- 完全替代（Full）：规则明确、重复执行、不涉及判断
- 人机协作（Collab）：需要判断但判断有规则可循
- 保留人工（Human）：需要情感、创意、复杂判断或物理操作
- 围栏分级模型设计：基于AI替代可行性，设计auto/review/block三级围栏：
- auto级：完全替代环节，直接执行
- review级：人机协作环节，生成方案待审
- block级：高危动作，拒绝执行并告警
- 经济性测算：AI替代的降本价值（节省人力）和增收价值（挽回流失）测算。测算必须满足（v1.1强化）：
- 给出区间估计而非单点估计（保守/中性/乐观三档）
- 列明关键假设清单（如"时薪按25元计""挽回比例70%"），每个假设标注依据或"经验估计"
- 对最敏感的1-2个假设做敏感性说明（如"挽回比例从70%降至50%时，年化价值从X降至Y"）
输出要求：
- 效率瓶颈根源图（Mermaid graph）
- 收益流失点分析图（Mermaid graph，含量级估算）
- AI替代可行性三级图（Mermaid graph，分完全替代/人机协作/保留人工）
- 围栏分级模型图（Mermaid flowchart）
- 经济性测算表（降本+增收）
第四层：特殊场景与AI增强流程对比
还原目标：针对特殊业态（如无人业态），分析其特殊场景和AI增强方案。
还原步骤：
-
特殊业态识别：这个行业有哪些特殊业态？（如酒店的无人酒店、餐饮的无人餐厅）
-
全流程自动化与断点分析：特殊业态的全流程自动化中，有哪些"断点"——自动化无法覆盖、需要人工介入的环节？以Mermaid flowchart绘制全流程并标注断点。每个断点必须使用标准化模板描述（v1.1新增）：
字段 说明 断点编号/名称 如"断点2：身份验证失败" 触发条件 什么情况下发生 发生频率 高频/中频/低频（依据或经验估计） 影响等级 服务中断/体验受损/资金风险/安全合规风险 当前人工处置方式 现状如何处理 AI兜底可行性 AI能否自动处理、边界在哪 -
兜底方案设计：针对每个断点，设计"AI优先+远程人工+现场应急"三级兜底方案，并明确断点处理后的记录归档与优化闭环（为什么发生→AI为什么没处理→如何减少未来断点）。
-
人工作业流程 vs AI增强流程对比：选取2-3个核心场景，对比传统人工作业流程与AI增强流程的差异（以Mermaid对比图呈现）。
-
特殊业态的AI增强流程设计：针对特殊业态，设计完整的AI增强流程（如无人酒店的夜班班组+远程管理）。
输出要求：
- 特殊业态全流程图（Mermaid flowchart，标注断点）
- 兜底方案三级响应图（Mermaid flowchart）
- 人工作业 vs AI增强流程对比图（Mermaid，至少2个场景）
- 特殊业态AI增强流程设计图（Mermaid）
- 价值测算（特殊业态的降本+增收）
3.3 调研方法
方法一：公开信息调研
- 行业从业者公开分享（知乎/小红书/行业论坛）
- 行业媒体报道中的从业者故事
- 行业SOP标准文档
方法二：行业合作伙伴深度访谈
- 与资深行业合作伙伴深度协作（他们有一二十年的行业经验）
- 结构化访谈：每个角色、每个模块、每个痛点
- 实地观察：到门店现场观察一线从业者的工作（如可能）
方法三：合理推演
- 基于公开信息和行业通用SOP，合理推演未公开的细节
- 推演部分明确标注"合理推演"
四、输入契约
4.1 必需输入
| 输入项 | 说明 | 来源 |
|---|---|---|
| 目标行业 | 要调研的行业名称 | 调用者指定 |
| 目标客群 | 要调研的客群类型（如低星单体酒店/民宿/无人酒店） | 调用者指定 |
| 一线角色清单 | 要调研的一线角色（如店长/前台/客房服务员） | 调用者指定或本技能识别 |
4.2 推荐输入
| 输入项 | 说明 | 来源 |
|---|---|---|
| 行业合作伙伴 | 资深行业合作伙伴的know-how输入 | 行业合作伙伴提供 |
| 行业SOP标准 | 行业通用的SOP标准文档 | web-search |
| 从业者公开分享 | 知乎/小红书/行业论坛的从业者分享 | web-search + web-reader |
| 实地观察机会 | 到门店现场观察一线工作 | 行业合作伙伴安排 |
4.3 输入校验
- 必须有至少一个一线角色的全景还原
- 必须有行业合作伙伴的know-how输入（或明确标注"基于公开信息推演"）
- 目标客群必须与HyperReality的目标客群一致（中小单体，非集团连锁）
五、输出契约
5.1 输出物
一份完整的一线作业调研文档，Markdown格式，包含：
- 调研说明（调研方法、信息来源、推演标注）
- 第一章：[角色一]日常工作全景分析（如店长）
- 第二章：[角色二]与[角色三]工作流程分析（如前台与客房）
- 第三章：行业痛点与AI替代可行性矩阵
- 第四章：特殊场景与AI增强流程对比（如无人业态）
5.2 输出规格
| 规格 | 要求 |
|---|---|
| 格式 | Markdown，使用Mermaid语法绘制所有图表 |
| 字数 | 不少于30000字（分4章输出） |
| Mermaid图表 | 至少8张（流程图、泳道图、状态机图、痛点矩阵等） |
| 对比分析 | 必须包含"人工作业流程 vs AI增强流程"的对比 |
| 抽象适配 | 每个模块结尾说明"如何抽象适配到其他行业" |
5.3 输出校验
- 是否覆盖所有一线角色？
- 每个角色是否有24小时时间线？
- 每个核心模块是否有流程图？
- 所有Mermaid图表在最终交付物中是否已实际渲染为图形（渲染率100%）？
- 是否有AI替代可行性矩阵（三级）？
- 是否有围栏分级模型？
- 是否有经济性测算？是否为区间估计+关键假设清单+敏感性说明？
- 是否有特殊业态（如无人业态）分析？断点是否使用标准化模板？
- 是否有"人工作业 vs AI增强"对比？
- 文档头部是否标注信息截止日期？
- 字数是否达标（≥30000字，融合模式下以"旧+新增补"合计信息量计）？
- 迭代融合模式下：是否包含新旧对比表、冲突裁决记录、融合结论？
六、质量标准
6.1 深度标准
- 人类视角：必须从"人每天在做什么"出发，不是"系统有什么功能"
- know-how显性化：优秀从业者的隐性经验必须被结构化为显性Skill
- 痛点量化：痛点不能只说"很痛"，必须量化（耗时多少、流失多少、出错率多少）
- AI替代分级有依据：每个环节的AI替代分级必须有理由（为什么完全替代/人机协作/保留人工）
6.2 可执行性标准
- AI替代可行性矩阵必须能转化为围栏规则
- 工作流程拆解必须能转化为SOP设计
- know-how必须能转化为Skill方法论
- 经济性测算必须能支撑定价决策
6.3 格式标准
- Mermaid图表必须可复制到支持Mermaid的编辑器直接渲染
- 流程图必须清晰（输入→处理→输出，异常分支）
- 矩阵必须规范（象限标注、数据点准确）
七、抽象适配说明
7.1 本技能的复用性
本技能是行业无关的元方法论。四层还原框架（角色全景+模块拆解+痛点矩阵+特殊场景）适用于任何行业的一线作业调研。
7.2 适配到其他行业的步骤
- 识别一线角色：找到该行业的一线从业者角色（餐饮是店长/前厅/后厨，美业是店长/前台/技师）
- 替换行业词汇：把"酒店"替换为目标行业词汇
- 保持四层框架不变：四层还原框架完全复用
- 行业特定调整：根据行业特点，调整某些层级的还原重点（如餐饮的"角色全景"要包含后厨厨师，酒店的"角色全景"包含客房服务员）
7.3 已验证的行业
- ✅ 酒店行业（店长/前台/客房服务员调研，已验证框架可行性）
- 🔜 餐饮行业（店长/前厅/后厨调研，待执行）
- 🔜 美业行业（店长/前台/技师调研，待执行）
- 🔜 教培行业（校区负责人/前台/教师调研，待执行）
7.4 跨行业角色映射参考
| 抽象角色 | 酒店 | 餐饮 | 美业 | 教培 |
|---|---|---|---|---|
| 经营负责人 | 店长 | 餐厅店长 | 门店店长 | 校区负责人 |
| 客户接触一线 | 前台 | 前厅服务员 | 前台接待 | 前台/课程顾问 |
| 服务交付一线 | 客房服务员 | 后厨厨师 | 技师 | 教师 |
| 双一线协作 | 前台+客房 | 前厅+后厨 | 前台+技师 | 前台+教师 |
八、调用示例
8.1 调用模板
调用技能：industry-frontline-research
输入：
- 目标行业：餐饮
- 目标客群：中小单体餐厅
- 一线角色：店长、前厅服务员、后厨厨师
- 推荐输入：餐饮行业合作伙伴know-how、行业SOP、从业者分享
输出：
- 餐饮行业一线作业调研文档（≥30000字，≥8张Mermaid图表）
8.2 与HyperReality底座的集成
本技能作为"行业know-how获取"技能，建议：
- 归类为official套件（随HyperReality底座分发）
- 安装后由行业交付工程师Agent调用
- 输出的know-how沉淀到一店一档默认值和围栏基线规则
- AI替代可行性矩阵转化为围栏规则（auto/review/block）
- 工作流程拆解转化为SOP设计和Skills开发
九、交付质量门禁与迭代融合规则（v1.1 新增）
9.1 交付质量门禁（Pre-Delivery Gate）
交付前必须逐项过门禁，任何一项不通过则禁止交付：
| 门禁项 | 标准 | 检查方式 |
|---|---|---|
| 图表渲染率 | 所有Mermaid图表在最终交付物中实际渲染为图形，渲染率100% | 逐张目检，禁止只交付代码块或空白占位 |
| 痛点量化 | 每个痛点有量化数据（耗时/流失量级/出错率），区间或点估计均可但需标注依据 | 抽查 |
| 测算严谨性 | 经济性测算为区间估计，附关键假设清单和敏感性说明 | 逐项核对 |
| 断点模板 | 特殊业态断点全部使用标准化六字段模板 | 逐项核对 |
| 信息截止日期 | 文档头部标注信息截止日期与调研方法 | 目检 |
教训来源：v1.0产出PDF中全部Mermaid图表丢失为空白；经济性测算只有单点估计、无假设说明。v1.1起"图表实际渲染"为一票否决项。
9.2 迭代融合模式（同一主题已有历史产出时）
当调用者提供同一主题的历史产出时，切换为迭代融合模式：
- 对比（Diff）：逐章对比历史产出与新调研，差异分为四类——旧内容仍有效/旧内容已失效/新内容增补/新旧冲突。
- 增补（Augment）：新产出聚焦旧版缺失或过时部分——新的从业者公开信息、旧版缺失的角色/模块、旧版未渲染图表的重绘、测算方法的修正（单点→区间）。
- 融合（Merge）：产出单一整合文档——旧内容全文保留（失效内容标注"已被vX更新取代"）、新内容以"【增补】"并入对应章节、每章结尾设"【融合结论】"、冲突时新证据优先或并列标注"分歧待验证"、卷首附"新旧对比一览表"。
十、版本记录
| 版本 | 日期 | 变更 |
|---|---|---|
| v1.0 | 2026-08-20 | 初始版本，基于酒店行业一线作业调研实践抽象 |
| v1.1 | 2026-08-21 | 新增：交付质量门禁（图表渲染率一票否决）、迭代融合模式、断点标准化六字段模板、经济性测算强化（区间估计+假设清单+敏感性）、信息截止日期标注 |
附录A：HyperReality底座上下文（动态读取前置环节 + 兜底摘要）
本技能的产出需要频繁引用HyperReality的定位与能力（差异化对比、AI替代映射、SOP/Skills设计）。HyperReality是活的开源项目，禁止凭记忆引用其功能。执行前必须按 A.1 动态读取最新代码；代码不可得时按 A.2 兜底摘要执行并显著标注。
A.1 前置环节：HyperReality最新代码动态轻量读取（强制）
读取目标：HyperReality开源仓库 https://github.com/workloom-ai/workloom-im（主干即可，无需全量clone历史）。
轻量读取清单（按优先级，预计10-20分钟）：
| 优先级 | 路径 | 提取什么 |
|---|---|---|
| P0 | README.md | 产品定位、仓库地图、最小跑通路径、当前版本状态 |
| P0 | bundles/hotel/bundle.json（或目标行业bundle） | 该Bundle提供的资产清单（presets/fences/skills/schemas/ui）与版本号 |
| P0 | bundles/<行业>/fences/*.yml | 基线围栏规则（rule_id/level/when表达式/default_level） |
| P1 | bundles/<行业>/schemas/objects.json、stages.json | 经营对象枚举、经营阶段枚举（现有多少类，扩展空间） |
| P1 | bundles/<行业>/presets/*.yml | Agent班组清单与各自围栏绑定 |
| P1 | bundles/<行业>/skills/*/SKILL.md | 已有官方Skill的功能边界（避免重复设计） |
| P2 | packages/shared/src/event-schema.ts | 五元事件schema字段（Who/Context/Object/Decision/RuleImpact）与冻结范围 |
| P2 | packages/base/各包文件头注释 | 九域能力的关键设计约束（围栏三级/哈希链/夜班状态机等） |
| P2 | docs/03-功能清单-用户版.md、docs/DECISIONS.md | 用户版功能全表、关键架构决策（ADR） |
| P3 | CHANGELOG.md | 最近变更（判断能力演进方向） |
读取产出（写入调研/方案文档的"HyperReality底座上下文"小节）：
- 底座能力清单：本次读取确认存在的能力（标注代码路径）
- 目标行业Bundle现状：对象/阶段/围栏/Agent/Skill的数量与清单
- 引用锚点表：本报告引用的每个HyperReality能力 → 对应代码路径或规则号
- 读取时间戳：如"代码快照：2026-08-21 main分支"
代码不可得时的兜底：使用 A.2 摘要，并在产出物头部标注："⚠️ 本报告的HyperReality能力引用基于兜底摘要（PRD V2.5 + 2026-08-21代码快照），未经实时代码核验，关键结论建议复核。"
A.2 HyperReality定位与能力兜底摘要（PRD V2.5 + 2026-08-21代码快照提炼）
一句话定位：HyperReality是企业级 Agent IM——以消息（五元事件）为唯一事实源、以规则围栏为行动权限边界、以三态会话（Ask/Agent/Quest）为人机分工范式的人机协作网络。不是工作台（工作台只是交互皮肤）、不是传统SaaS（它按意图动态组装能力）、不是单个智能体（Agent班组只是它雇佣的"数码员工"）。人只做三件事：供给（定目标/给素材）、裁决（围栏审批拍板）、沉淀（固化SOP为技能），其余执行、巡检、对账、夜班值守全部交给Agent班组。
架构分层：L0 基础设施（PostgreSQL 17+pgvector，本地优先/数据主权）→ L1 运行时（DeepSeek Harness，vendor锁定rc.8）→ L2 Base Bundle（九域能力，底座不内置行业词汇）→ L3 行业Bundle（六装配槽填充）→ L4 客户Patch（只可收紧不可放宽）。
九域能力清单（代码已实现）：
| 域 | 包 | 关键能力 |
|---|---|---|
| 数据大脑 | workdata | 五元事件库（append-only + SHA-256哈希链 + 幂等）；安全网关三段瀑布（权限→PII脱敏→高危授权）；组织记忆（workspace/agent/run三级作用域，preference/pattern/sop/forbidden四类，pgvector语义检索） |
| 围栏引擎 | fence-engine | auto/review/block三级判定（deny优先、求值异常按block"宁可错杀"）；YAML围栏包DSL（沙箱表达式，禁eval）；基线单调守卫（is_baseline规则只可加严）；dry-run回放10条历史事件验证；对象级写锁 |
| 审批触达 | review-console | 统一审批队列；三手势（采纳/编辑后采纳/驳回，驳回必填原因）；审批卡片为IM原生消息（inapp/钉钉/企微/飞书/Slack）；高危项不过期自动放行；驳回回流为记忆校准样本 |
| IM通道 | im-channels | 入站消息五元化、幂等去重；外部通道经dsh-im插件 |
| 夜班班组 | night-shift | 18:00候选清单→22:00-08:00围栏内自治→08:30清晨决策包（已完成/待审批/需介入三栏，≤20条）；一键暂停≤60s；自研cron触发器；夜班动作100%过围栏（版本快照） |
| 巡检中心 | inspection | 只读巡检（工具集裁剪保证）；异常分级P0/P1/P2聚合推送防风暴；一键派单回链；检项由行业包定义 |
| 技能市场 | skills | official/team/industry三级（industry上架必须脱敏）；安装即绑定围栏、卸载即收缩；forge零代码自建（触发/步骤/边界三要素）；安装前必须dry-run；意识系统（同类动作≥3次/周产出固化建议） |
| 多租户 | tenancy | 四版本能力矩阵：community（无Quest/夜班/巡检）/pro/teams/vpc；越版访问403+升级提示 |
| 模型路由 | model-router | 记忆复用优先→确定性任务分级→峰谷窗口（22:00-08:00谷时费率≤20%）→降级链→熔断；逐事件计量（账单=事件投影）；降级写事件禁静默换模型 |
五元事件模型：Who（human/agent/system）× Context（tenant/workspace/time/channel/stage）× Object（行业化枚举）× Decision（action/before/after/basis/memory_refs）× RuleImpact[]（rule_id/version/result）。附加：Receipt回执（未核实不得转完成）、ModelTrace（逐事件模型计量）。schema v1冻结，行业仅可在context/object/decision内loose扩展。
执行面五级分层：L1官方API（零token主路径）→ L2确定性适配器 → L3确定性剧本（AI浏览器模拟，频次自律）→ L4自主探索（冷启动，探明后固化为L3）→ L5人工接管（进决策包"需介入"栏）。
酒店行业Bundle现状（2026-08-21代码快照，bundles/hotel v1.0.0，演示Bundle）：
- 7个Agent preset：pricing-agent / review-agent / reconcile-agent / inspection-agent / content-agent / competitor-agent / desktop-agent
- 基线围栏R1-R6（default_level=review）：R1房价涨幅≤8% auto；R2保底价¥380 block；R3新渠道首发改价/发布必审；R4退款≥¥500必审；R5担保订单异常block；R6差评必审
- 3个官方Skill：revenue-manager / review-crisis / channel-reconciler
- 经营对象8类：room_type/room_price/channel/order/guest/review/store/staff
- 经营阶段5个：ramp（爬坡）/stable（稳定）/peak（旺季）/off_season（淡季）/turnaround（调整）
- 一店一档Schema + UI用例（cases.json）
行业可配置范围（六装配槽）：①档案Schema（一X一档）②对象与阶段枚举 ③工具集（MCP优先，每动作标注读/写）④围栏包（阈值默认值行业定、客户patch只收紧）⑤Agent班组preset（未声明fence_bindings禁止写动作）⑥工作台UI。全局枚举与五元事件v1 schema冻结不可改；写类动作前缀可经registerWriteActions扩展；模型任务分级表与降级链可按工作区覆盖。
质量与验收基线：371条全场景测试套件（域A-Q）+ dsh-gate崩溃重放/验链/幂等门禁；全局验收口径G1-G11（如事件检索P95≤3s、夜班成本谷时≤20%、留痕100%）。
版本补充记录
| 版本 | 日期 | 变更 |
|---|---|---|
| v1.2 | 2026-08-21 | 修正技能关系：技能一/二并行独立（原"输入←技能一"依赖降级为非必需参考）；新增附录A——HyperReality最新代码动态读取前置环节与兜底能力摘要，一线环节映射HyperReality能力前必须动态读取或标注使用兜底 |