支持回路。
两条产品线在一周内发出十个发布物。安装包背后，是一条五段式链条——发布 → 升级 → 诊断 → 分析 → 答复——再往前一步：一块公开看板，让分类即决策；一个无人值守的实施者，在隔离分支上产出经过测试的补丁，而 main 永不移动。
这是一篇把风景留在画面里的发布记。两条产品线——MRRC（基于 Hamlib 的通用远程电台，Windows 线，v6.1.x）与 MRRC Modern（面向 FT-710 与 IC-7300 级电台的现代化姊妹线，Windows + macOS，v1.18.x）——在 2026 年 9 月 17 日前后的 48 小时里发出了十个发布物。安装包只是可见的一半；另一半是产出它们的支持链：用户侧的一键升级与一键回退，一份脱敏诊断包，维护者侧跑在十分钟 cron 上的机器首轮判读，以及一个每条结论都附原始日志行的公开答复页。这篇记录发了什么、头几天的分诊教了什么，以及这条链对智能体工程——把判断与执行分离的纪律——在仓库之外、在用户所在之处意味着什么。而从 9 月 19 日起，这条链还长出了公开看板与无人值守的实施者——它的第四项回路实践。
TL;DR — 六条发现里的回路
- 事实两条线，一周，十个发布物。MRRC 发了三个安装版（v6.1.15 / v6.1.16 / v6.1.18）和五个热修；MRRC Modern 发了 v1.18.0（macOS DMG + 实时更新通道）与 v1.18.1（签名与麦克风权限修复，Windows 包同步重建）。
- 事实这条链是一个两端自助的回路。用户不开工单就能升级、回退、打包诊断、按编号查到答复；维护者侧由十分钟 cron 自动分诊。机器分诊的头四天：MRRC 公开答复 7 条（6 条已答复、1 条退回补证据），另有 1 张已知问题卡（6.1.13 已修复）；Modern 的前两个诊断包到达后一天内出了 2 条答复。
- 推断一次上报是案例；重复出现的签名是需求。9 月 17 日的两个小时里，两个用户撞上同一堵 rigctld 墙；自启动修复当天发布。NR2 水声的答复先变成等级表改动，再变成暴露的旋钮，最后变成第三种降噪引擎。
- 推断判定本体论就是需求筛。环境 ≠ 缺陷不是官僚流程：把环境误判成缺陷，路线图会被幽灵需求填满；把缺陷误判成环境，用户会被搁浅。每张公开答复卡都附原始证据行，读者可以核对推理。
- 推断回路现在触达代码。MRRC Modern 的第四项回路实践（9 月 19 日）：每条分析都带着分类落进公开看板——noise 自行闭环、bug 自动排期、feature 等待决策——cron 实施者对已排期条目产出受护栏保护的 unified diff 补丁，只落在隔离的
fde/<id>分支，全套测试绿才提交。main永不被触碰；合入仍是人的动作。 - 论点支持是智能体工程最外侧的回路。迭代单位不是提交——是未被解答的用户症状。在仓库内闭合的回路，可以对现场敞开几个月；这条链把它闭上。
一周，两条线，十个发布物
用户实际拿到的东西——不是 changelog，是体验。
| 发布物 | 日期 | 用户拿到什么 |
|---|---|---|
| MRRC V6.1.15（安装版） | 9 月 17 日 | Windows 安装版自动拉起 rigctld——电台 CAT 守护进程随包分发（vendor 内置 rigctld.exe + DLL），并带机型名 → 编号解析：配置里写 FT-891 就能用，不再要求 -m 1036。 |
| MRRC V6.1.16（安装版） | 9 月 17 日 | 加固：内置 rigctld 路径以 manager 为主，兜底实现只让位、绝不阻塞启动——自启动不能变成「起不来」。 |
| MRRC V6.1.18（安装版） | 9 月 18 日 | 第三种降噪引擎：NR3 —— RNNoise（Xiph 神经降噪，v0.2，BSD-3），[WDSP] nr3 = plus|only|off；libwdsp 重建，暴露新的 EMNR alpha/npMax 旋钮；NR2 等级表下移（−6/−9/−12/−16）；以及一个门控修复——关降噪现在是真旁路。 |
| MRRC 热修 6.1.14 → 6.1.18 | 9 月 17–18 日 | 同一批修复走热修通道：不用重装——重启 MRRC 即生效。自启动（6.1.14）、名字→编号（6.1.15）、兜底让位（6.1.16）、NR2 等级表（6.1.17）、NR3 + 门控（6.1.18）。 |
| MRRC Modern v1.18.0 | 9 月 17 日 | 首个正式 macOS 版（Apple Silicon DMG，macOS 11+）与 Windows 安装版并行，加上实时更新通道（latest.json，SHA-256 直接取自产物）和完整的支持链：🐞 诊断包、答复页、打包版日志落盘。 |
| MRRC Modern v1.18.1 | 9 月 18 日 | 两个 macOS 修复：应用签名了（不再「已损坏，无法打开」）；.bundle 正确申请麦克风权限（不再无声 RX）。Windows 包从同一份源码同步重建。 |
与发布物同周进场的，还有 Modern 线上的性能工作：发射后的 TX→RX 采集重开从约 270 ms 降到约 200 ms；PTT 按住期间不再广播已静音的 RX 帧；PTT 释放延迟在 SDD 有了自己的版本行（V2.55）。没有一项光鲜，但全部可测。
回路自身当周也发布了：9 月 19 日，MRRC Modern 上线 FDE 看板——血统里的第四项回路实践——一块公开看板，让每条分析带着分类落板（bug / feature / noise），后面接一个无人值守实施者，把已排期条目变成隔离分支上、以全量测试为门的补丁。它不是安装包，所以不在表里；它是 §05 的主题。
每个安装版的 previous 都留在服务器上——而且必须 git 入库，因为部署是 rsync --delete，没入库的服务器文件会被删掉（回退按钮就曾这样 404 过一次）。热修通道版本必须低于安装版版本；回退目标必须真实存在、不能是已知坏版本；清单的 SHA-256 在服务器侧复核，因为本机下载链路不可信。跨项目可比的数字（测试数、约束数、各产品族版本）只在一个地方：证据台账——子站和博客链接它，不复述它。
「自助服务」和「自诊断」到底是什么意思
五段——发布 → 升级 → 诊断 → 分析 → 答复——把往返都工程掉。
大多数支持链是一个带希望的邮箱别名。这一条是两端各装了一台仪器的流水线。在用户侧，应用的设计目标是：用户需要的四件事，永远不需要开工单——
⬆️ 升级，不用去找下载页
Web 界面一个按钮（或启动器里按 U）。服务端先做 PTT 门禁——电台发射中，升级请求直接被 423 拒绝。下载先写 .part 文件，校验 SHA-256，原子改名，再静默安装，启动器干净交接。
↩️ 成功判据造不了假
「已拉起安装器」不算成功。唯一的成功判定是 state.json → lastResult.status == "ok"，由新版本在自己的启动时自证。新版没说话之前，升级就没发生。一键回退走同一条静默安装路径，指向上一个安装包。
🐞 诊断，不用读日志
菜单里一个入口生成脱敏诊断包：日志尾部、白名单脱敏的配置、环境快照（版本、平台、音频设备表、生效的热修层），以及自动体检摘要 diagnostics/summary.txt——它用启动次数和时间跨度区分「重启」与「崩溃」。密码、密钥、令牌、录音、存储信道、天调学习数据永远不出机器。
📖 答复，不用写邮件
公开的答复页可搜索、可按上报编号直达。每张卡结构固定：编号 / 症状 / 诊断（附原始证据）/ 结论 / 你要做的 / 状态。缺陷修复发布后，卡片翻成「已修复 · 版本号」。
在维护者侧，同一条链跑在十分钟 cron 上：取新包 → 摘要（复用客户端跑的同一个摘要器，两端对「摘要意味着什么」有共同语言）→ 模型在成文纪律下分析 → 结构化 JSON 结论 → 渲染答复卡 → 发布。发布默认拒绝（显式参数才发布）；按包 ID 幂等；半包跳过；每轮最多处理两条。
支持曾经是一场访谈：一封邮件 = 一个问题，每个来回隔着几小时，用户靠记忆作答。诊断包把访谈变成测量：一次上传 = 一个现场，带采集健康度百分比、设备表、重启与崩溃的判别。这个转换不是 UX 修饰——它是机器分诊成为可能的前提。你无法委托机器去「访谈的第一轮判读」；你可以委托它去「测量的第一轮判读」。
两个产品族现在跑的是同一条链。Modern 在 v1.18.0 整体继承了它——包格式、摘要器、答复页、更新检查——它的前两个自动分诊答复已于 9 月 19 日发出，距第一批诊断包到达不到一天。
三起事故，三个已发布的功能
被解决的问题如何挖出新需求——讲机制，不讲口号。
同一堵墙，一个早晨撞了两次
9 月 17 日，两份 FT-891 上报在两小时内先后到达——20260917-073700-14ef（07:36）与 20260917-085736-ebd2（08:53）。症状相同（「电台连不上；音频同步正常」），诊断包给出的结论相同：CAT 守护进程 rigctld 没在跑，配置正确，日志里三次超时，无崩溃。按判定表，两例都是环境，两张答复卡教的是同一段 PowerShell 咒语。
单个看都关闭了。合起来看是一条产品裂缝：一台「通用遥控」要求每个新用户手工拉起守护进程，等于对所有人提出同一个要求。重复本身完成了转换。当天：热修 6.1.14 发布自启动（rigctld_supervisor.py）；热修 6.1.15 修复机型名→编号解析（rigctld --list）并把 rigctld.exe 收进安装包（V6.1.15）；V6.1.16 让兜底路径让位、永不阻塞启动。答复页新增一张公开卡：FT-891 用户升级即可。
「环境」这个判定回答用户。几小时内两次环境判定同时出现回答路线图。真正值得关注的工程量从来不是单次判定——而是跨上报的签名，以及从签名到修复上线的时长：这一次，不到一天。
一条答复变成默认值；一个默认值变成引擎
上报 20260917-132643-020a：「NR2 开 2 级后水声大、有失真」。诊断包自己的数字让结论可证而非可信——音频采集健康度 99.9%、无 Traceback、无双重降噪叠加——答复卡据此判定为经典的谱减法音乐噪声副作用，并给出动作：级别 2→1、AGC 模式、带宽。
然后，产品在三天里分三步吸收了这条结论。默认值改变：NR2 等级表整体下移一档（热修 6.1.17），再落到 −6/−9/−12/−16。旋钮暴露：重建的 libwdsp 增加 C 层 alpha/npMax 设置接口，新默认值经闭环实测（npmax 0.98，AE 20/0.50）。引擎增加：NR3 —— Xiph 的神经降噪 RNNoise，可选 plus|only|off，随 V6.1.18 上线，同时带上让「关」成为真旁路的门控修复（此前有用户报告关掉降噪后仍失真——这本身也是一条值得挖的上报）。
答复卡在几分钟内修好一个电台。改默认值在无声处修好所有未来的电台。新引擎改变可能性的边界。停在第一步的支持是成本中心；跑完「答复 → 默认值 → 引擎」这条弧的支持队列，才是需求流水线。
两次静默失败，与一套回归协议
Modern 的第一个 macOS 版撞上两个静默失败，两个修复都是可观测性的教材。「已损坏」：此前所有 macOS 构建其实都没签上名——签名步骤一直在静默失败——于是 Gatekeeper 弹出一个右键也绕不开的对话框。修复是双的：把 bundle 按 codesign 的要求重新布局，并让签名失败直接中止构建。静默失败才是缺陷；对话框只是症状。无声 RX：bundle 没有声明音频输入权限，macOS 的回应是把采集流打开、往里填零——日志提示「检查电台」，CoreAudio 却报无错误。修复是正确申请权限，并把警告指向系统设置而不是电台。
第三个案例是分诊系统咬了自己的尾巴，还咬出了价值。诊断包 20260918-114118-9ad3 带着一条「录音掉块 / 队列满」的签名，与 V2.44/V2.45 修掉的缺陷同签名——但所有命中行都落在 9 月 12 日（修复发布之前）。公开结论拒绝了两个顺手答案（「早已修复」/「回归了！」），改为执行一套协议：用户录一段新 QSO 再回报；后续包（20260919-085517-b3aa）关闭了它——9 月 19 日的日志健康，旧行被确认为修复前的残留。让这一切成为可能的，是一条作为流程提交的改动（ecb2652）：模型在写结论前必须先读项目自己的事故史——SDD 版本史、CHANGELOG、精确到行的代码位置是输入，不是事后补充。
Modern 的两条结论都逐行引用证据：server.py:348 _ensure_rec_writer()（修复本体，已在当代码中）、SDD V2.44/V2.45 的记录行、带时间戳的摘要行、健康的 9 月 19 日会话日志。材料不足时，卡片明说，而不是猜——MRRC 最早的七条答复里有一条至今停在「需要补充信息」，那是诚实的台阶，不是失败状态。
机器的首轮判读，人的判定
分诊是一份契约，不是一种感觉：结构化输出、判定本体论、失败即关闭的护栏。
分析器的输出是一份固定的 JSON 契约——verdict、status（answered | needs_fix | need_more_info）、category、diagnosis[]、solution[]、evidence[]、keys[]、needs_code_change、code_hint——原样渲染进答复卡，证据行一并呈现。判定本体论写成表格，不写成感觉：Traceback 或反复同一处异常 → 缺陷；多次启动而无 Traceback → 不是崩溃；-9996 且设备表为空 → 环境（无声卡的虚拟机）；rigctld 未运行 → 环境；采集健康度低于阈值 → 性能；证书告警 → 正常噪声。
本体论就是筛子
环境 ≠ 缺陷是需求决策，不是较真。把环境误判成缺陷，路线图会被幽灵需求填满（「自动拉起用户从没要求过的东西」）。把缺陷误判成环境，用户会被搁浅在一个永远变不成修复的规避动作里。这张表让两种错误都变得昂贵。
按规则保守
材料不足 → need_more_info。没有 Traceback → 永远不叫崩溃。环境类 → 永远不算缺陷。结论必须落到用户动作——「去系统设置重选音频设备」，绝不写「等维护者修」。答复页是公开页面：只发可公开的结论，不带用户数据。
失败即关闭的护栏
默认拒绝发布（显式参数才发布）。按包 ID 幂等。半包与非 zip 载荷跳过、不重试。每轮两条上限、九分钟模型超时、cron 用绝对 venv 路径。自动化允许「什么都没做」；不允许「做错了什么」。
分工
机器做首轮判读——便宜、一致、不疲倦，十分钟一轮，每个论断都挂在某行日志上。人拥有 needs_code_change：改代码、决定发版、判定答复能否按原文发布。产品由维护者构建；智能体负责分诊、起草与渲染。
MRRC 答复页：7 条分诊答复——6 条给出可执行步骤（4 条环境、1 条音频调参、1 条无需修复），1 条退回补证据——另有 1 张已知问题卡，按用户可见的现象写（「页面按钮点不动」），其根因（6.1.12 的内联 JS 语法错误）变成了 tests/test_web_inline_js.py：如今每次发布，所有内联脚本都要过 node --check。MRRC Modern：上线 48 小时内 2 条答复，都引用了代码位置与版本史。零条答复以「等维护者修」收尾。
从已答复到已实施
9 月 19 日，这条链长出了公开看板与无人值守实施者——回路触达了代码。
分类即决策
9 月 19 日之前，回路能读、能答；但分析产出的 bug/feature 分类无处可去——仍要由人挑出要修的、动手修、手动收尾。看板（vlsc.net/mrrc_modern/board）补上了缺的另一半，它的规则只有一句：分类即决策。分析契约增加三个可选字段（kind：bug / feature / noise，外加 severity 与 title），分类学就此变成调度器：
| 分类 | 自动动作 | 依据 |
|---|---|---|
| noise——环境 / 误报 / 已修复签名 | 答复客户；看板列「已答复」——终态，无代码工作 | 答复页已回，无需代码 |
| bug——可定位的产品缺陷 | 答复客户，并自动排期进无人值守实施队列 | 修它是验证问题，不是产品选择 |
| feature——新能力 / 新参数 | 答复客户；看板列「待决策」——等操作员 | 排期是产品决策，不自动化 |
| need_more_info | 永不闭环——留在待决策跟进 | 未答复的上报不允许假装闭环 |
看板与答复页共用同一个隐私过滤器（redact_public），互链。一次用户上报变成一张带状态列的卡片——反馈不再是邮箱，而是位置可见的队列；这也是一份公开承诺：什么闭环了、什么排期了、什么还在等，以及为什么。
一个测试过的补丁落在分支上，而 main 在睡觉
同一条 cron 现在带着 --implement 运行。对每条已排期条目，单飞——每轮一条，且只在干净的 main 工作区上——流水线用只读工具（read,grep,find,ls）调用模型，要求一份 JSON 契约：understanding、unified diff 补丁、test_plan、risk、commit_message——或 no_action，后者带理由落进看板 Rejected。模型没有写权限；补丁在流水线决定采纳之前只是文本。
流水线拿到这段文本之后做的事，才是安全所在：
- 护栏先行——两个跨文件工具护栏脚本、
certs/、win/、packaging/与安装器清单（.iss）一律拒绝；单个补丁最多 8 个文件。 git apply --check先跑；失败即终止，理由记入看板。- 隔离分支——补丁只落在新拉出的
fde/<id>分支，永不落在main。 - 全量测试是门——绿则提交到分支（看板记录
branch@hash与测试结果行）；红则删除分支、还原工作区，记 failed 与日志尾部。 main永不移动。无人值守进程碰不到它；合入分支是人的动作。
设计观与 PTT 门禁同源：机器可以提议，证据决定，人接受。电台相关没有任何东西被自动化掉，代码也没有一行未经审查地落地——变化在于：一条已排期的 bug，不再需要等一个人坐到键盘前才能开始。
回路自身的两次失败——以及它们证明了什么
无人值守回路有自己的失效模式，头一天就冒出两个——每一个都比它拖延的功能更有价值。
跑不起来的模型运行器。cron 分诊的 pi 连续两天以 SIGABRT 死亡。根因：一次 Homebrew 升级打断了 bottled Node 的 dylib 链接（llhttp）——是模型运行器，不是模型。修复不是重试，而是诊断：run_pi 现在会在信号死亡时点名成因。无声失败的回路与无事可做的回路无法区分；无人值守回路必须能解释自己的沉默。
进入生产的测试夹具。测试运行只改写了本地页面路径，却仍把夹具版答复页/看板页发布到了线上服务器——发现它，是因为生产看板上突然出现了一个测试包编号。修复把页面发布收敛为唯一一个可拦截的接缝（_ship_page()），而验证才是重点：完整跑一轮 1,299 项测试后，本地看板状态与线上看板页逐字节一致。回路自己的发布路径也在测试之下。
两次事故之所以被抓到，是因为回路的产物是公开且逐字节核对的。私有自动化可以静默失败数周；公开回路会把自己的失败泄漏进与产品同一个证据面。看板上出现测试编号很难看——也正因如此，接缝当天就修了。
人的工作压缩成两个动词
对照 §04 读，看板改变了自动化的权限边界。之前：机器读并分类，人挑、人修、人发。之后：分类即调度——noise 自行闭环、bug 自行入队——人的介入压缩为决策（每个 feature 一次排期备注）与合入（接受一个已测试分支）。这与整个工程体系是同一套分工——判断归人、执行委托、证据把关——只是作用对象从源码树变成了产品自己的待办。
回路的边界又移动了。它曾止于一条已答复的工单；后来止于一个已发布的修复；现在止于一个已审查的分支——一份无人醒着时产出、经测试、可回滚的补丁，等待人点头。最后一句留给人，不是因为机器不能合入，而是因为「算不算数」是这个项目唯一拒绝委托的动作。
截至写作时，线上看板有两条已分类条目，都是 noise → 已答复；第一条真实 bug 还在等它的第一次真实排期，第一份无人值守补丁还在等它的第一次人工合入。端到端路径——上报 → 排期 → 无人值守实施 → 合入——由测试验证，尚未由真实案例验证；SDD 条目（V2.56）写下了同一道边界：实施模型的探查预算与 diff 质量待真实样本校准。当周流水线的门槛计数：9 月 19 日提交中的 1,299 项测试；维护中的可比数字在证据台账。
这条链对智能体工程说了什么
智能体工程把判断与执行分离。支持链是这套分离在用户所在之处的应用。
回路有边界——而仓库是错误的那一个
台账一文（七十亿 token 的全程拆解）测量的是内环：契约测试先红、智能体交付到绿、中位 19 分钟。那个回路闭合在仓库内部。但如果产品的迭代单位不是提交——而是未被解答的用户症状——那么全绿的测试套件就是绕着错误边界闭合的回路。产品可以连续几个月测试全绿、同时每个新用户都卡在同一堵墙上，因为仓库边界之内没有任何东西看得见那堵墙。支持链把回路拉长：现场 → 诊断包 → 判定 → 产品变更 → 发布 → 用户自助。只有当用户的下一次点击在没有人工介入的路径上成功时，回路才算闭合。
自助是带宽，不是客气
每向用户侧移动一步，就从回路里减掉一个往返：升级不用找下载页、回退不用重装、诊断不用读日志、答复不用写邮件。每一步的设计检验是同一句话：用户能不能在不理解日志的前提下完成这个动作？这正是「自诊断」不是营销词的原因——诊断包是放在用户侧的一台仪器，为接收者而不是发送者设计：白名单脱敏、为「一眼读」写的摘要、重启与崩溃的判别、附上的设备表。这也是答复页公开原始证据行的原因：一个能核对推理的用户，会在读下一条答复之前就信任它。
自助是回路的带宽。一条需要人来中转每条消息的支持链，把产品的总迭代速度封顶在一个人的注意力上。一条用户侧能独立完成升级、回退、测量、查答复的链，让回路的速度由最慢的自动化环节决定，而不是由人决定。
晋升进路线图的是签名，不是单次判定
一次上报是案例。重复的签名是需求。判定本体论是保持诚实的东西——它是那个筛子，替路线图挡住幽灵需求（环境被误读为缺陷），也替用户挡住搁浅（缺陷被误读为环境）。但真正驱动迭代的量是跨上报的签名，加上从签名到修复上线的时长。9 月 17 日：两条环境判定，相隔两小时 → 当天热修。9 月 17–18 日：一条调参答复 → 等级表 → 旋钮 → 第三引擎。支持队列和路线图是同一本账，只是读取的周期不同。
是一个节拍栈，不是一条回路
| 回路 | 周期（实测） | 捕捉什么 |
|---|---|---|
| 分诊 | 10 分钟（cron） | 每个诊断包都得到首轮判读；没有东西在邮箱里排队 |
| 答复 | 当天 | 环境 / 使用 / 调参类问题的用户侧解决 |
| 实施 | 每条分钟–小时级（单飞、测试为门） | 已排期的 bug 变成隔离分支上经测试的补丁；合入仍归人 |
| 热修 | 小时级（6.1.14 → 6.1.16 一天之内） | 可热修面内的缺陷与缺口（www/**、应用模块、vendor） |
| 发布 | 天级（V6.1.15 → V6.1.18；v1.18.0 → v1.18.1） | 安装器级变更：内置引擎、签名、权限 |
| 免疫 | 事故 → 守卫，永久 | 每起事故留下一道守卫：内联 JS 守卫、站点的测试数与中英成对检查、签名失败即中止构建 |
系统的学习速率，由「能捕捉每一类事故的最快回路」决定。支持链给节拍栈补上了最外侧的周期——唯一能捕捉那些永远不会出现在仓库里的事故类别的回路：没有声卡的虚拟机、USB 重枚举、macOS 权限弹窗、Gatekeeper。台账里的事故链从事故到机器强制约束跑了 13 天、再 7 天；本周的当天支持弧是同一个原理在不同半径上的测量。
两本账的纪律同样适用于答复
「已答复」是过程证据：它说这个案例被读过、被分类、得到了一个可执行的动作。「已修复 · 6.1.13」是绑定到已发布产物的产品主张。答复页把两者分开，而 need_more_info 是那个诚实的台阶——最早的七条答复里有一条站在那里。支持卡里的任何内容都不晋升产品主张；晋升它的是发布台账里的版本行。这与主证据台账（/zh/agentic.html#evidence）是同一门纪律：过程徽章永远不晋升产品主张，边界永远写下来。
哪些环节故意留给人
这条链里有三件事是刻意只留给人的。射频安全：升级路径拒绝触碰正在发射的电台（423 门禁）——没有自动化可以越过 PTT 门禁，也没有自动化结论可以触碰发射行为。隐私锚点：密钥、密码、录音、存储信道永不离开用户的机器；脱敏是白名单，不是承诺。对代码的判定：needs_code_change、改动本身、发布决定，都归维护者——机器的边界止步于 diff 之前。深度硬件排障（边缘的 USB 供电、CI-V 的怪癖）也依然是手工活，而且生命周期文档把自身的边界明明白白写下来——基于摘要的分诊读的是摘要，不是完整环境——而不是暗示一种自己并不具备的自动化。总纲把保留的这一半命名为——意图、边界与裁决；它的规则正是这一节存在的原因：智能体承担执行，不承担问责（分工）。
在论纲页的血统里，FDE——前沿部署工程——是第一个把现场证据带回设计的回路：Echo → Delta → Product，由一名身处现场的工程师承担。支持链没有改变这个回路的形状，改变的是它的 staffing：它现在跑在 cron 上，两端各有一台仪器，路径上那位「现场部署工程师」变成了一条流水线。同一拓扑，新的经济学——这就是一个实践从「依赖英雄」毕业为「工程」的含义。
我主张什么，不主张什么
主张：这条链把现场症状转变成已发布的产品变更，且每一步都有可引用的证据；多数问题类别用户不需要人工往返即可解决；每条已发布的结论都可以对着原始日志行核对；分诊自动化自身的失效模式是有界且成文的。不主张：对路线图的自主权——人读答复页，人决定一个签名值多少；安全自动化——流水线里没有任何东西触碰发射路径；完备性——基于摘要的分诊不可能看见完整环境的一切，这正是 need_more_info 作为一等结果存在的原因。产品由维护者的双手和流水线构建；智能体的角色是分诊、首轮判读与发布机制——产品这一周变得更好，是因为回路带回了什么，而不是因为打字的是谁。
闭上那个触碰用户的回路
一周，两次发布，一句留下来。
自助不是成本优化；它是产品的传感网络。只会回邮件的支持链是成本中心；能把重复签名变成已发布功能的支持链——当天热修、改掉的默认值、新引擎——是需求引擎。触碰用户的那个回路决定产品是否进化，所以要刻意地闭上它：先让故障可观测，再让答复自助化，让重复签名自己晋升进路线图，而判定始终留在人手里。当回路长出实施者，同一门纪律继续放大：分类决策、机器提议、测试把关、合入归人。
先让失败可观测。再让答复自助化。然后让重复签名自己晋升进路线图——判定，留给人类。
去试试这些端点：MRRC 答复页 · MRRC Modern 答复页 · MRRC 下载 · MRRC Modern 下载。跨项目可比的数字（测试数、约束数、版本）只在一个地方：证据台账。