🐞 FDE 看板 — 上报 → 分类 → 排期 → 后台迭代

包内没有证据显示服务端把 RX 音频做小了（同一会话里 tap 抓到 peak 9065/32767 属正常电平），音量上限卡在「电台 AF 增益 + App 播放增益 min(10, vol/255×boost)」；另外发现 1.27.0

ft8/core/worker.py:handle_decode（shared_memory_unavailable 唯一来源）/ ft8/engine/dsp_decode.py:SupervisorDecoder._ensure_segment；音频设备解析见 audio_handler.py 设备名→索引路径

三个症状里「不能发射」和「没频谱」是 FTX-1F 这一未验证 profile 的既定行为（TX 门禁 + 无 CAT 波形协议）；「频率不同步」在包里没有 FTX-1 的 CAT 交换证据，无法判定，需补证据。

backends/yaesu/backend.py:_tx_allowed / backends/yaesu/yaesu_profiles.py:FTX1（scope_type 由 backend.py:67 固定为 none）；频率路径候选点 backends/yaesu/cat_core.py:set_frequency（未确证，需 _diag_yaesu.py 实测）

诊断包确认了 FT8 DSP worker 每个时隙都崩溃、FT8 全程 0 解码，但用户报告的「服务器进程消失 + 电台卡在发射」那一刻的日志并未进包（无 PTT/unkey 行、无主进程致命 traceback），因此卡键根因证据不足，

候选待确认：ft8/core/worker.py:handle_decode（原生 binding.decode 崩溃使 worker 每时隙死亡）与 ft8/core/supervisor.py:_roundtrip_locked（报出 worker_exit）；主进程消失路径未定位

现象指向控制链路/子进程在与电台通信期间异常中断（半开或服务异常退出），但包内日志不含 PTT 卡键那一小段，无法定因；先按安全闸门与 USB 链路两条可执行路径处理，并补齐事故日志。

server.py:_ptt_key_ws 与 _tx_liveness_watchdog（PTT 键控/存活闸门，默认关闭，待事故日志确认是否回归）；config.py:MRRC_REMOTE_SESSION_TX_HEARTBEAT_S / MRRC_PTT_MAX_TX_SECONDS

摘要里的『S 表合成回退』是频谱客户端接入后首个广播 tick 的正常瞬态（包内日志证明真 FT4222 频谱随后就出帧并持续工作），不是缺陷；真正无法判定的是 17 条 Traceback —— 摘要只打印了 traceback 头部，包

诊断包未填写问题描述，且自动体检报告的两条结论均被包内证据推翻/解释：真频谱实际已工作、音频告警是 10-11/10-12 的历史且已在 10-13 自动恢复——需用户补充具体现象。

server.py:1809-1816（首帧前的 S 表回退日志带 if _first，仅过渡态一次；与 v1.25.1 的 scope_pipe 启动缺陷签名相反，非缺陷）

本包未见可确认的产品缺陷：串口掉线与 PortAudio -9999 都自动恢复、真实 FT4222 频谱已出帧；自动体检的「S 表合成回退」是启动瞬态导致的误报，但 37 条 Traceback 的正文不在这份摘要里、问题描述为空，无法定

未定位到用户侧产品代码缺陷；次要点 support_bundle.py:summarize_log 的 S-meter fallback 判定过宽（本包误报，真帧已收到）

诊断包显示服务端本身健康、包内没有任何 cloud_hub/portal/frpc 日志行，无法判断「申请/链接 portal」卡在哪一步，需要按下「申请」那一刻的日志才能定性——现有证据下判 need_more_info。

server.py: _cloud_portal / api_cloud_apply / api_cloud_refresh 与 cloud_hub.py（TunnelProcess.connect）是历史修复点；本次包内无 portal 日志，未定位到具体代码缺陷，仅作复核方向

本机服务与电台一切正常（启动完整、[已隐去] 已连、频谱/发射正常），502 出现在云端入口→本机隧道的链路；这与本仓记录过的『入口 502 而租户侧一切看起来正常』同签名，1.25.3 应已包含相关修复 → 按回归排查。

cloud_hub.py:TunnelProcess（隧道启动/注册）+ server.py:_cloud_start_tunnel（启动时自拉隧道、证书判据）

决策备注：自动分类：环境/误报，答复页已回

服务端收到 0 帧麦克风上行（frames=0/peak=0%，CQ 走服务端注入却正常），与仓库 V2.71 记录并修复过的「键控了却没有声音」同签名，而现场 1.25.5 已包含该修复，按回归排查。

server.py:_claim_tx_owner_for_token / _same_session_uplink_takeover / _assign_tx_owner_on_connect（TX 上行认领）；static/ft710_main.js + tx_capture_worklet.js（浏览器麦采集是否出帧）

决策备注：自动分类：环境/误报，答复页已回

与 SDD V2.78（同日 2026-10-10、同为 v1.25.4 + IC-7300 的发射声音问题）同签名：软件链路清白，根因在电台侧调制输入源（Icom MOD Input / USB MOD Level），非产品缺陷。

无代码缺陷；用户指引见 docs/OPERATION_GUIDE.md §0.6.2（IC-7300 MOD Input）与 static/modules 的 🎙 Vol 设备侧麦克风增益

决策备注：自动分类：环境/误报，答复页已回

用户版本 v1.24.0 上「接入云端→申请」返回 500，正是本仓 v1.24.1 已修复的同一缺陷（server.py 未导入 cloud_hub → NameError 500）；该版本不含修复，升级到 v1.24.1 或更高即可。

server.py/api_cloud_apply（v1.24.0 缺 `import cloud_hub`；v1.24.1 起在 server.py:67 补上，当前仓库已含修复）

决策备注：自动分类：环境/误报，答复页已回

软件把语音送进了电台（52% 峰值的音频确证写进 USB 声卡），电台也真的在发射，但调制为零 —— 根因是**电台侧的调制输入源没选 USB**（`SET` → `Connectors` → `MOD Input`），不是音频链路故障

决策备注：电台侧 MOD Input 未选 USB（根因非软件）；答复页已回，文档已补 + 守卫测试

同一条根因的 SSB 版本：电台在发射，但实测 `ALC=0`、`Po≈0`，而服务端同时在把音频写进电台 USB 声卡 —— SSB 没有调制就没有射频功率；先查电台 `MOD Input`（`DATA OFF MOD` / `DATA

决策备注：电台侧 MOD Input 未选 USB（根因非软件）；答复页已回，文档已补 + 守卫测试

没有开蒲公英，从外网进入https://bg7zhs.mrrc.vlsc.net/网页显示无法打开，更新md文件后显示网页出错，现在又显示无法打开网页

决策备注：补记：发布者已答复（本机状态文件重建时从答复页回收，分类 网络）

how to config the *.mrrc.vlsc.net? how can I make it work?

决策备注：补记：发布者已答复（本机状态文件重建时从答复页回收，分类 环境）

analysis the logs

决策备注：补记：发布者已答复（本机状态文件重建时从答复页回收，分类 环境）

录音签名与 V2.44/V2.45 修复的「写入端一次性生命周期」缺陷同签名，当前 v1.18.1 已包含修复；包内命中行全部为 2026-09-12 修复前的历史日志，9/18 当天无新录音丢弃，按回归排查（用户先做一次新录音验证），其余

决策备注：自动分类：环境/误报，答复页已回

无在发产品缺陷：录音「dropped/queue full」签名与 V2.44/V2.45（v1.15.0 发布）修复的写入端生命周期缺陷同签名，但均为 2026-09-12 旧日志、当前 v1.18.1 已含修复（server.py:34

决策备注：自动分类：环境/误报，答复页已回

Launcher 的首启探测白名单 `VALID_MODELS` 只含 ft710/ic7300/ic7300mk2，所选 ftx1 因此每次启动都被判为「未配置」，探测到 Yaesu 应答后把型号改写成 ft710 —— 于是续跑成 FT

macos/first_run.py:VALID_MODELS / needs_first_run / apply_first_run / probe_radio_model（应由 backends.known_models() 派生白名单，并让 probe 返回 "ftx1" 而非 "ft710"）

git apply --check 失败：error: corrupt patch at line 118

启动器首次自检不认 FTX-1：它把 ftx1 当作“机型未设置”，每次启动都重新探测串口、把机型改写成 ft710 存回配置 —— 不是用户选错，也不是电台的问题

macos/first_run.py:VALID_MODELS / needs_first_run() / apply_first_run() / probe_radio_model()（白名单应改为 backends.known_models()，探测需返回真实机型或保留用户已选机型，不得把 ftx1/ic705/ic7610/ic7760/ftdx10/ftdx101d/ftdx101mp/f

git apply --check 失败：error: patch fragment without header at line 38: @@ -282,11 +301,21 @@

1.28.1 的启动器首启探测仍用硬编码三机型白名单（ft710/ic7300/ic7300mk2）判定型号，FTX-1（ftx1）被视为「未设置」，于是每次启动都重新探测并回写成 ft710 —— 这是产品缺陷，不是用户操作问题。

macos/first_run.py:needs_first_run()/apply_first_run()（VALID_MODELS 硬编码三键 → 应由 backends.known_models() 派生，探测失败时保留用户已选的型号而不是回写 ft710）

git apply --check 失败：error: corrupt patch at line 97

日志签名 `TX session: frames=0 … written=0 … peak=0%`（键控了却没有声音）与 v1.25.4 修复的「同一 30 天令牌下多条 /WSaudioTX 上行归属错误」同签名，而当前版本正是 1.25

server.py:_claim_tx_owner_for_token / server.py:_same_session_uplink_takeover（TX 上行归属；配套 _register_tx_socket/_forget_tx_socket）

决策备注：模型判定不涉及代码：1) 版本判据：CHANGELOG `[v1.25.4]`（CHANGELOG.md:869 起，915-921 行明确列出 `_claim_tx_owner_for_token` / `_same_session_uplink_takeover` 两条链并逐字节比对了源码包）才是该修复到达用户的版本，1.25.0–1.25.3 出这个签名是预期行为，不是回归；HEAD 的 s