---
title: FR-193 現況（STATE）
h1: FR-193 現況
subtitle: Agent 主機 rootless Docker；現行版 Agent 1.7.9（含 FR-195 資安修正）已發布；主系統 1.31.0 待發
lede: "只描述此刻。沿革看 fr193-LOG.md 與 git log。接手讀完本檔與指定讀序、答完自檢題、跑完唯讀盤點後停下，等決策者發令。"
---

## 🧭 原始需求（先懂這個再往下讀）

決策者 2026-11-10 裁示：Docker 要做 rootless，照 Docker 官方 Rootless mode 完整做，PM 不接受替代方案（userns-remap 已排除）。**Agent 先出安裝包，主系統晚一點**。背景是部署同仁要在台灣把 Agent 裝好帶去印尼，連回 GCP 上的主系統。

rootless 的意思：客戶主機上開容器的 Docker 引擎不再用 root 跑，改由一個不能登入、沒有 sudo 的普通帳號 `guidant` 跑。容器裡面 FR-180 已全數非 root，這案補的是引擎那一層。程式碼與 image 不動，改動全在安裝程式、維運指令與主機設定。

決策者沒有這類經驗，回報一律白話、講到「不做會怎樣」。當天多次點名：做太多不必要的事、驗收卡拆太細反覆裝機、解釋太細看不懂。**接手後不要擴大範圍，不要為了驗一件事去補一堆測試。**

## §0 接手讀序與自檢

必讀，依序：

1. 本檔全部
2. `fr193-LOG.md` 最後一個 block
3. `../design-v1.4.md` §1 決策表（D1～D11）、§3 詳細設計
4. `../evidence/agent-rootless-probe.md` §3 壞掉清單、§7

冷接自檢題（答得出來才算讀懂）：

- 為什麼維運指令本身用 root 跑，而不是用 `guidant`？那「把主機目錄掛進容器」為什麼還是會壞？
- `uninstall` 在 `wipe` 之後原本為什麼沒還原主機設定？
- 今天抓到的兩個壞指令，哪一個是 rootless 造成的、哪一個不是？
- 192 現在是什麼狀態，可以直接拿來重裝嗎？

## §1 此刻的狀態（2026-11-11 00:30）

### 沒有做到一半的事

Agent 1.7.9 已正式發布（pipeline 3054021918，更新站 `published` 2026-11-11 20:01，sha256 `77140520…`）。內容＝1.7.7 ＋ FR-195 十二張資安修正（Agent `b011adc`）＋ 主控台隱藏線上開通（FE `b61597bc`）＋ jedi-ldap 0.1.1（本棒發上 Nexus）。1.7.8 建到推 Harbor 後被更新站拒收（版本說明單條 >500 字），未發布，Harbor 上 `1.7.8-518b5863` 映像留著不動。桌面只留 1.7.9 下載文件（連結到 11-12 20:02）。沒有未 commit 的程式改動。

**主系統 1.31.0 還沒發**：GCP 跑 1.30.2，發的登入票帶舊 7 個權限名，Agent 1.7.x 一個都不認得，從主系統「連線至 Agent」等於沒權限；1.31.0 的 migration 會把既有角色自動展開成 26 個新權限。發 1.31.0 前要先處理 BE 映像 2 條白名單外 High（net-ssh 7.3.3）。

### Notion 卡

| 卡 | 做什麼 | 狀態 |
|---|---|---|
| CM-3804 | 母卡（Agent 先行） | Not started（母卡狀態不代表進度） |
| CM-3805～3809、3812、3813 | A0～A4、A7、A8 | Done |
| CM-3810、CM-3811 | 已併入 CM-3809 | 暫緩 |
| CM-3814 A9 | 出貨包總驗 | Done（決策者收） |
| CM-3865 A10 | 部署／演練／健康檢查腳本跟上 rootless | 修正待驗證（首腦親手做，commit `710467e`） |
| CM-3867 | 指令改名 guidant-agent-compose → guidant-agent | 程式已做（Agent `b8b1158`、BE `8211b2ab5`、FE `1a297c7d`），卡未回寫 |
| CM-3868 | console-login 壞掉（FR-180 留下） | 待修 |
| CM-3818 | 上線前就緒檢查 | 另一個 session，與本案無關 |

### 指令改名（CM-3867）已定的三件事

安裝包檔名 `guidant-agent-compose-<版>.tar.gz` 不改；原生版 `guidant-agent-ctl` 不動；舊指令名不保留（1.7.x 還沒發給客戶）。程式與進包的 `deploy/README.md`、BE／FE 憑證到期提示、Claude Docs 安裝手冊都已改。**還沒改的**：BE 客戶手冊 `docs/user-manual/agent/` 十四章（約 87 處）、`docs/spec-site/current/`（61 處）、test repo（16 處）、Agent `docs/security-scan/` 歷史報告（刻意不動）。決策者裁「舊文件先不管」。

### 三個 repo

| repo | branch | HEAD | 與遠端 |
|---|---|---|---|
| evidence-agent | feature/FR-172 | `dca3c62`（tag `v1.7.9` 已發布；`v1.7.8` 未發布） | 相同 |
| compliance-manager-be | feature/FR-172 | `88f3228fa` ＋本檔與 LOG | 本檔未 commit |
| compliance-manager-fe | feature/FR-172 | `1a297c7d` | 相同 |

### 測試機 192.168.50.192

決策者 2026-11-10 還原成乾淨 Ubuntu 24.04 後，用含全部修正的測試包（188 22:55 出，sha256 `68f561e7…`）首裝通過：rootless dockerd／containerd 都是 `guidant`、兩顆容器 healthy、`sudo guidant-agent status` 正常、已註冊 GCP 主系統 `guidant-ai.jedicotech.com`、本機對外位址 `https://192.168.50.192:8443`。188 的公鑰要重新加進 `authorized_keys`（還原後消失）。

### 建置機 192.168.50.188

`/opt/guidant-ai-agent` 是 detached HEAD（CI 的常態，`git checkout --detach`）。快取 `.build/docker-debs/`、`.build/tpm2-debs/` 已各有 `ubuntu-26.04`。2026-11-10 清出 30 GB（docker builder prune、Agent compose 目錄的 1.6.0／1.7.0／1.7.2／1.7.3 測試包、BE bundle 1.30.0／1.30.1、Agent bundle 1.7.0／1.7.3），1.7.5 發完又降到 28 GB，再清 `bundle/stage/` 舊版骨架（只留 1.7.5）與 1.7.4 測試包後 50 GB。`release-archive/` 沒動（演練起點來源）。**每次發版前先 `df -h /`，低於 30 GB 先清 `bundle/stage/` 舊版。**留著可刪：`/home/jedi/vulnscan-USfH/`（弱點掃描暫存）、`/home/jedi/fr193-*.log`。

**188 的 bats 1.2.1 沒有 `BATS_TEST_TMPDIR`**，`test/shell/` 跑起來 61 條紅都是這個原因（改名前同 commit 一樣紅），bats 不在 CI 內。

## §2 下一步（建議，不是授權；每一項等決策者發令）

1. 發主系統 1.31.0（先修 net-ssh 兩條 High），GCP 升級後從主系統登入 Agent 才會通。
1a. 192／193 用 1.7.9 走一次 `upgrade`（這條路至今沒真機走到底）。
1b. 找一台乾淨 Ubuntu 26.04 用 1.7.6 首裝一次（Docker 離線裝、tpm2 離線裝兩段只有真機走得到）。
2. 發布後把 1.7.5 正式包升到 192 走一次 `upgrade`（`upgrade` 這條至今只在測試包驗過「失敗時不弄壞」，沒走到底）。
3. 192 接上主系統後補驗：主控台網路診斷（ping／traceroute／MTU）、派一次掃描、主系統發更新的自動升級。
4. CM-3867 卡回寫（做了什麼、三件裁示、哪些文件沒改）；CM-3865 由決策者收。
5. BE 下次進版前處理 net-ssh 7.3.3 的 2 條 High（GHSA-qpg5-fx6p-8cq3、GHSA-vxj5-fg65-x765，CINC 內嵌；tools-manifest 有 `cinc-gem-<名>` 補升機制）。
6. 主系統的 rootless（FR-193.1）還沒有設計。

## §3 待辦清單

**本案內、擋出貨**

- 正式發版 pipeline 3050615877 綠（§2 第 1 項）
- `upgrade` 走到底（§2 第 2 項）

**本案內、不擋出貨**

- `wipe` 的說明寫「不會刪除設定檔」，實際清掉了設定檔的加密存放，之後 `status` 不能用。行為合理，文字要改
- RHEL 系（el-9）那組套件還有 4 個 systemd 相關的檔，沒在實機驗過
- 這輪的修正只在 Ubuntu 24.04 實測，Ubuntu 22.04、Debian 12、el-9 未驗
- Ubuntu 26.04 目前不支援離線安裝（包只帶四組）
- uninstall 後的三個小尾巴：`/var/lib/guidant-agent` 空目錄沒刪；`systemctl --failed` 留一筆升級單元的失敗紀錄（該 `reset-failed`）；`ping_group_range` 執行中的值到重開機才回預設
- `test/shell/manual_upgrade.bats` 有 4 條在本案之前就紅（第 2、3、4、10 條）。bats 不在 CI 與 pytest 內，不擋發版
- 正式發版前：換新版號、寫 `RELEASE_NOTES.md` 新版段（1.7.4 已發過）；不要勾升級演練（190／188／189 同機有主系統，新版安裝程式會拒絕）

**另開的卡**：CM-3868（console-login）；CM-3867（改名）程式已做、文件尾巴見 §1

## §4 已定裁示（不要重新問）

- 完整 rootless，不用 userns-remap。Agent 先行。
- D1 主系統對外一律 8443（PM 裁）。只影響 FR-193.1。
- D2 ping sysctl 全開；D3 網路驅動預設 slirp4netns；D4 包裡帶 Docker Engine；D7 不留 root Docker 相容路徑。
- GCP 主系統從 root 轉 rootless 要用「遷移子命令」原地轉，不用 uninstall 重裝。屬 FR-193.1，還沒寫進設計。
- 推送：可直接推自己當下的 feature branch，不推 main、不 force、不切 branch。
- 唯讀查任何環境不必請示；改 STG／POC 要當次明確指示。192 是測試機可任意裝拆。
- `wipe`、`uninstall` 設計上要人在終端機前打確認字串，不繞過；請決策者自己跑。

## §5 行為規範（今天被點名的）

- 不要寫「私下盤點」式的長篇推理給決策者看，查完只講結論。
- 回報問題固定「問題 → 建議 → 理由」，不能只列問題。
- 「未驗」不可以直接丟給決策者，能跑就先跑。
- 碎片修正不補新的單元測試。驗證靠實機。
- 動 git 前先 `git status`。**不帶路徑的 `git stash` 禁用**（今天誤用過一次，已還原）。
- 進行中的卡不要再往卡尾疊修正段，小弟看不到。