FR-171 · 需求索引 · 本頁由 build 掃資料夾生成

FR-171 主系統與 Agent 通訊重整

指令不再等心跳，身分不再靠人換：主系統直接打 Agent 下指令、心跳只同步有變的設定、憑證到期自己換、兩個方向同一套簽章規則。

狀態：討論中文件 1 份 handoff 2 份

§1

🔴 先看哪一份

文件	性質	看什麼
discussion.md	討論稿（v1）	現況四條通訊路地圖、業界對照、九個半套的洞、目標設計六主題、D1～D12 待裁
design.md	設計（未寫）	裁完 D1～D12 後落地
handoff/FR-171-STATE.md	接手現況	第 2 棒首腦從這裡接；§3 下一步、§2 已定裁示
handoff/FR-171-LOG.md	歷史	第 1 棒做了什麼、撤回了什麼

§2

尚未定案。討論稿 v1 已交決策者審閱（2026-10-31）。

§3

棒	卡	做什麼	狀態
1	—	首腦探脈＋討論稿 v1＋交接	✅ 2026-11-01
2	—	接手首腦：併 11-01「心跳不帶訊息」裁示出 v2，等決策者裁 D1～D12	⬜

§4

2026-10-31 決策者：「等心跳太偷懶、越塞越多，要改雙向。」「反正都要重構了，我希望是好的設計。mTLS 10 年過了要怎麼更新？客戶沒有 IT。」「機制沒錯但都做一半或沒統一，兩個月後沒人記得。」「要真的分析過，不合理要反駁我。」
2026-10-31 首腦撤回兩項先前說法：「三種票共用一把私鑰是洞」（RFC 8725 現況合規，分鑰是縱深）、「CA 縮到 3 年」（NIST 要求能換不是定期換）。
2026-10-31 首腦提 DPoP 式持有證明取代心跳改 mTLS（不動前門、兩向同規則）。
2026-10-31 決策者問「註冊 token 重新產生跟撤銷差在哪」→ 查證現況一租戶一組永久有效、兩者對舊 token 動作相同；已註冊 Agent 不受影響。D9 要擴大。
2026-11-01 決策者（另一 session）：「之後不要再用心跳帶訊息了，雷到一個不行。」討論稿 v1 主題 B 與此衝突，v2 要重審。
2026-11-01 決策者：轉給另一個首腦主持。

§5

FR-170 第 4 棒分析心跳回應 24 鍵分三類，決策者裁 P4 暫緩等重構完再議。FR-170 P0～P3 已於 2026-10-31 合回主線，本案接續。

§6

以下全部由 build 掃資料夾產生，新增檔案重 build 即自動出現。標題連結指向渲染後的 HTML，md 連向源檔。

文件	類型	標題	最後更新
discussion ／ md	需求討論稿	指令不再等心跳，身分不再靠人換	2026-10-31

由新到舊。每份是某一棒次交接當下的完整現況快照，看某個時間點「當時知道什麼」請從這裡進。

日期	文件	標題
未提交	FR-171-STATE ／ md	FR-171 交接現況（STATE）
未提交	FR-171-LOG ／ md	FR-171 交接紀錄（LOG，append-only）

§7

相關需求：