15.附录C：网站取材与内容维护
1.本手册就是网站的原始材料
依照HFL-016规定的依赖顺序，内容从HiveFlow规范进入介绍，再供网站取材。HiveFlow网站以本手册的介绍、解释和案例为主要内容来源，可以压缩篇幅、重组导航、增加图示和交互，但不能另写一套与上游矛盾的产品承诺。
三处材料各有责任：
| 材料 | 保存什么 | 更新时怎样使用 |
|---|---|---|
docs/06-自动化/ |
唯一权威执行规范与验收记录 | 判断允许行为、精确条件与证据范围 |
| 本手册 | 面向人的连续介绍、案例和解释 | 作为网站正文的原始材料，并回链所依据规范 |
| 独立flow网站仓库 | 经整理的公开展示内容与网页实现 | 固定来源版本，依据本手册更新并验证展示 |
正式规则变化时，先在规范中确认，再同步手册，最后更新网站。若发现手册有错，先修正文档解释；不能让网站文案悄悄决定新的任务行为。
网站更新时，需要读取网站仓库当时的规则、内容结构与构建命令；介绍材料不替代网站自己的实现与检查要求。
2.网站入口与内容边界
展示网站由独立flow仓库维护。它帮助读者理解方法、场景和接入条件，不是群机器人、任务调度器或业务操作入口。
独立hive-flow仓库已按Apache-2.0开源，供读者取得规范参考版、介绍和离线工具。网站源码仓库flow同样已采用Apache-2.0，两仓各自保留LICENSE与NOTICE。网站实现、介绍材料与第三方内容按各自分发声明使用，许可不覆盖私有HiveOS未分发材料或真实业务访问权。
网站不因展示了“完整交付”就已经具备执行权限，也不因介绍了原生自动化就证明真实链路已启用。公开内容应同时讲清方法、现有实践和未验收范围。
面向公众的叙述可以使用本书的合成案例。实际群身份、私有决定、环境配置、凭据、内部运行标识及完整日志不属于网站素材。源文档可以引用规范解释边界，网站应按公开范围提供可访问的说明，不能把私有文档整包导出。
3.建议的网站阅读顺序
首页先回答三个问题：HiveFlow解决什么问题、用户与负责人怎样参与、一项反馈会怎样结束。再引导读者进入详细流程和接入说明，不把配置字段堆在第一屏。
首页流程应显示Issue前后的承接关系：云端dots调查并登记，GitHub Issue交接到Director的MacMini，本地Codex再按“手动／定时”与“PR待审／完整交付”两组独立选择推进。四种组合及Director介入时点应一起展示，避免读者需要跨章拼出主线。
建议按照“认识方法→看懂流程→判断能否接入→查看实例和依据”的顺序组织。网页可以合并若干章节，但应保留来源映射，使维护者知道每段内容来自哪里。
下面是取材建议，不要求网站一定做成15个页面。
| 网站内容 | 主要取材章节 | 需要保留的关键事实 |
|---|---|---|
| 首页介绍与核心价值 | 第1章、第3章 | 连接反馈、决定与可核验交付，代码只是中间一步 |
| 角色与工具关系 | 第2章 | 云端与MacMini的分工、Issue交接点，以及各工具责任 |
| 反馈与研发总流程 | 第3章、第4章 | 先调查登记，再由本地承接；Issue存在不等于获准开工 |
| 采纳与授权 | 第5章 | 价值判断与实施范围分开，有效授权内连续推进 |
| 事项与状态说明 | 第6章、第13章 | 评审、进度、正式登记与交付事实分别表达 |
| 启动方式、交付模式与Director介入 | 第3章、第7章、第9章 | 手动和定时都可选两种终点；PR后再介入，完整授权内连续交付 |
| 交付与回执 | 第8章 | 业务结束与消息传输分开，未知不换路径重发 |
| 自动化工作方式 | 第9章、第10章 | 有界配置、新事项、真实认领，当前启用状态需复核 |
| 调查与异常处理 | 第11章 | 版本和环境依据、隐私、取消与恢复条件 |
| 接入准备与验证 | 第12章 | 离线、模拟与现场证据分层，不夸大已验收能力 |
| 常见问题 | 第13章 | 用读者的问题解释容易混淆的边界 |
| 完整案例 | 第14章 | 合成示例与真实交付证据明确分开 |
| 来源与维护说明 | 本附录 | 固定版本、标明更新范围、保留未验证事实 |
涉及精确执行条件时，应回查对应规范。网站不用复制全部字段，但删减不能改变条件组合，例如把“有效配置下的新采纳，经核验认领后可执行”缩成“回复采纳即可自动开发”。
4.从哪一版材料生成网站
网站更新应固定到包含目标手册内容的HiveOS完整提交SHA。SHA是Git提交的唯一版本标识；只写分支名无法说明当时实际读取了哪一版内容。
至少保留以下来源信息，具体存放方式服从网站自己的规则：
- 来源仓库及完整提交SHA。
- 采用的手册目录、章节文件和必要规范文件。
- 对应文件的内容摘要或哈希，用于核对提取内容。
- 本次整理与事实复核日期。
- 采用的章节与网页内容之间的对应关系。
- 被保留的未启用、未验证和适用范围说明。
提交SHA证明来源版本，文件哈希帮助识别内容；两者都不能证明文案已经审阅，也不能证明真实工具已接入。网站构建成功同样不等于业务链路验收通过。
规范与介绍采用同一HiveOS提交中的内容；网站实际更新时，固定包含两者同步修订的完整提交。旧写作基线、只有介绍变化的中间提交或网站以前记录的来源，均不能冒充这次同步后的规范与手册来源。
独立hive-flow仓库只是按需导出副本。网站来源信息也不应让读者误以为它仍是HiveFlow执行规范的主仓库。
5.怎样把章节改写成网页
先提炼读者的问题，再取对应段落。比如首页的“怎样开始”可以用三步解释：用户描述现象，负责人决定范围，执行者交付并带回结果；点击后再展开调查、登记、授权和验收的细节。
流程图应与文字条件一致。可以为不同受众提供简图，但不能让箭头跳过授权和验收，也不能把“通知待确认”画成“用户已收到”。
表格中的对照适合保留。手动与定时、PR待审与完整交付是两组独立选择，Director的介入次数需说明统计范围；事项状态与采纳记录状态、受理与平台确认也各有含义。这些区别帮助读者避免误解，不应只留下一个更简短却失真的结论。
合成案例可以分成场景卡片或连续故事，但应保留“示例，不代表真实验收”的说明。不能把假定的37条导出结果改成客户成功案例，或给它加上真实账号、头像与项目背景。
章节引用在网站中可以变成公开可访问的来源说明或版本信息。仓库相对链接不能直接照搬成失效网页链接；需要在网页环境里实际检查导航、锚点和外链。
6.哪些话需要事实复核
长期方法与当前接入状态分开维护。下面的表达需要不同依据：
| 拟发布的说法 | 需要什么依据 | 资料不足时怎样写 |
|---|---|---|
| 支持PR待审和完整交付两种模式 | 对应正式规范 | “规范定义了两种交付终点” |
| 已经具备离线检查 | 实际脚本与对应通过记录 | 说明检查范围，不扩展到真实平台 |
| 原来源回执已经实践 | 对应场景的现场证据 | 说明单次实践及环境范围 |
| 新采纳可以自动进入研发 | 真实启用配置、认领及端到端验收 | “受控自动路径已定义，业务自动执行尚未启用” |
| 取消与重启恢复可靠 | 对应现场用例和结果 | 区分规则、模拟结果与尚待现场验证 |
| 所有用户都可以使用 | 真实开放范围及适用条件 | 说明接入需具备的权限和环境条件 |
HFL-019保存有日期和范围的验收记录。网站采用时要核对当时状态与最新事实；历史记录中“尚未初始化”或“曾经通过”都不能脱离日期写成永久现状。
对未完成的真实链路不设置营销倒计时，不以演示图代替验证，不把文档检查通过写成生产可用。
7.一次网站更新怎样完成
- 读取网站仓库自己的规则，核实它当前使用的内容和来源版本。
- 选择包含已审阅手册内容的HiveOS完整提交，比较相关规范与章节变化。
- 按本附录映射整理页面，保留必要条件、证据范围和示例说明。
- 复核时效性表述与公开范围，不从私有配置或聊天补入未经处理的细节。
- 运行网站仓库要求的检查，并在实际预览中核对文字、图示、导航和不同屏幕表现。
- 在网站规定的位置更新来源信息，报告采用章节、实际检查、遗漏和剩余问题。
- 发布动作按仓库和当次任务授权执行；本附录不扩大外部影响或生产权限。
如果文案审阅发现正式规则存在歧义，应回到HiveOS修正依据，再同步网页。单纯润色可以在不改变含义的前提下进行，但不能通过更换词语隐藏必要条件。
8.手册怎样持续维护
本手册的目录负责阅读路线，章节负责解释与示例，docs/06-自动化/负责精确规则。章节不复制大段配置和全部接口字段，减少多处改同一事实的负担。
维护时先判断变化属于哪一种：规则变化回到规范；解释不清修手册；网页导航或显示问题修网站。一个改动涉及多处时，分别更新并说明实际完成到哪一步，不能只因手册已修改就宣布网站已同步。
上游介绍手册保持Review状态，没有改变已有正式规范的状态；本站整理不把手册提升为执行规范。网站取材时应核对实际采用版本的审阅与公开范围，不能把文档状态字段当成业务授权。
任何后来参与维护的人，都应能从来源版本和章节映射还原一句网站文案的依据，并看见它没有覆盖的场景。这才是把手册作为原始材料的目的。
本章依据
- HFL-001：权威规范来源
- HFL-016：文档维护与公开范围
- HFL-017：公开材料的安全边界
- HFL-019：有日期和范围的事实依据