FNOS-001 真实环境验收记录（fnOS NAS，2026-10-09 建立 / 2026-10-10 更新）

本记录是 FNOS-001 1Panel 应用商店应用转换的目标环境验收记录，用例定义见 FNOS-001 1Panel 应用转换测试用例，格式规范见真实环境验收记录。

当前状态：blocked（部分 AC 已转「通过」）。 截至 2026-10-10：

已通过真机验证：FNOS-001-04-AC-02（安装与入口端口）、04-AC-05（改端口后入口跟随）、04-AC-07 的 .main 规则、fn-it-tools 的启停与「删除所有数据」卸载。
仍未验证：FNOS-001-04-AC-03（「保留数据后重装读回」）、04-AC-06（端口占用）、05-AC-01（数据落盘与容器重建）、06-AC-01（数据库连接信息与失败提示）。
真机通道：appcenter-cli 因 RPC 权限 panic 不可用，已改用 trim-cli（fnOS 应用中心 HTTP API）执行，解锁方式见下方「执行环境阻塞」与 FNOS-001-04-TEST-03。

设备当前状态声明：本记录涉及的真机验证应用现已由用户在 App Center UI 全部卸载完毕，设备已恢复原状（37 个应用、端口全部释放、/var/apps/ 无残留）。本记录描述的是已发生的历史验证，不代表这些应用当前处于已安装状态。

1. 设备架构、用户角色、安装/升级方式和前置配置

项	值	状态
设备架构	待填（x86_64 / ARM）	未采集
fnOS 系统版本	待填	未采集
执行用户角色	待填（需具备应用中心安装权限）	未采集
安装方式	`appcenter-cli install-local`（设备端）或 `appcenter-cli install-fpk`	未执行
升级方式	应用中心升级，走 `wizard/upgrade` → `cmd/upgrade_init` → `cmd/upgrade_callback`	未执行
前置配置	待填（端口占用检查、数据库/Redis 实例、共享目录授权）	未就绪

执行环境阻塞

设备端安装链路当前不可用。在执行环境执行 appcenter-cli 的任何子命令均在启动阶段 panic：

text

$ appcenter-cli version
panic: ApplyPermission for '[com.trim.sysinfo com.trim.main]' error, dial unix /run/trim_app_cgi/rpcbroker: connect: permission denied
	

goroutine 1 [running]:
git.teiron-inc.cn/infra/trimrpc.defaultInit()
	/go/pkg/mod/git.teiron-inc.cn/infra/trimrpc@v1.17.6/init.go:31 +0x1d9
git.teiron-inc.cn/infra/trimrpc.Init(...)
	/go/pkg/mod/git.teiron-inc.cn/infra/trimrpc@v1.17.6/init.go:16
main.main()
	/app/main.go:15 +0xd0

解锁条件（满足任一即可继续）：

在具备 /run/trim_app_cgi/rpcbroker 访问权限的目标 fnOS 设备上，以具备应用中心权限的账号执行 appcenter-cli；
由设备管理员为当前执行环境授予该 socket 的访问权限；
由设备侧操作人代为执行安装步骤并回传输出与截图（此时记录须注明操作人与采集时间）。

2. 操作步骤、预期结果和实际结果

阶段一清单核对（本地已执行部分）

这部分在开发机仓库工作区执行，用于核对 FNOS-001-01 的验收条件。属本地验证，不能替代任何设备端结论。

路径说明：上游 appstore/ 检出在工作区中，与 fn-os-apps/ 仓库同级，不受本仓库跟踪。因此涉及 appstore/... 的命令在工作区根执行，其余命令在仓库根 fn-os-apps/ 执行。

用例	验收条件	步骤	预期结果	实际结果	状态
FNOS-001-01-TEST-01	FNOS-001-01-AC-01	统计上游目录数并解析清单批次明细表，比对集合与必需列	265 个应用，集合一致，四列非空	上游 265 个目录；清单解析出 265 行 / 265 去重应用，无缺列	通过
FNOS-001-01-TEST-02	FNOS-001-01-AC-02	复算 AC-02 的 5 个统计指标，与 `appstore/` 实际内容比对	五项逐项一致（265 / 259 / 257 / 223 / 2）	五项全一致（见下表）。上一轮判「失败」，清单订正后本轮改判「通过」	通过
FNOS-001-01-TEST-03	FNOS-001-01-AC-03	`pnpm run check -- --all`	退出码 0	退出码 0，`SDD docs check passed: 1 requirement document(s), 1 plan document(s)`	通过
FNOS-001-01-TEST-04	FNOS-001-01-AC-04	分级计数、查重与守恒校验	唯一归属，合计 265，无人工解释分歧	T0=14、T1=98、T2=74、T3=46、T4=33；合计 265 行 / 265 去重应用，无重复；判据可机械复现	通过

TEST-02 / TEST-04 改判经过（不静默改状态）：上一轮执行时 TEST-02 判「失败」（清单声明 formFields 257、./ 挂载 221，实测 259、223），TEST-04 按旧数字（17 + 92 + 77 + 46 + 33）判「通过」。缺陷 D-02 定位后确认：./ 挂载口径不可机械复现，且 newsnow、openldap 因引号挂载漏判被错分到 T0（实为 T1），这构成 AC-04「不需要人工解释的口径分歧」子句的不成立。清单订正口径并完成移位后，本轮两项均复算通过，故 TEST-02 由「失败」改判「通过」，TEST-04 维持「通过」。

复核命令与关键输出（上游相关命令在工作区根执行，其余在仓库根 fn-os-apps/ 执行）：

bash

# 工作区根（appstore/ 与 fn-os-apps/ 同级）
$ ls -d appstore/apps/*/ | wc -l
265
$ git -C appstore rev-parse --short HEAD
3b142d2

# 仓库根 fn-os-apps/
$ pnpm run check -- --all
SDD docs check passed: 1 requirement document(s), 1 plan document(s)
$ echo $?
0

清单统计复算（订正后本轮独立复算，五项全一致）：

指标	清单声明	复算结果	复算口径
应用总数	265	265	`appstore/apps/` 下目录数
有 `formFields`	259	259	YAML 键位置匹配 `^[ \t]formFields[ \t]:`，读取每个应用所有版本目录的 `data.yml`
使用 `1panel-network`	257	257	compose 文件内容包含该字符串
使用 `./` 相对挂载	223	223	卷挂载行 `^\s-\s["']?\./`（引号无关）
外部命名卷 `external: true`	2	2	顶层 `volumes:` 段内卷名下缩进的 `external: true`

上一轮偏差的根因（已订正，保留记录）：

formFields 偏差原因：jupyter-notebook/latest/data.yml（第 28 行 type: password 行尾）与 oceanbase/4.4.2-lts/data.yml（第 45 行 envKey: OB_SYS_PASSWORD 行尾）含制表符残留，严格 YAML 解析报 found character '\t' that cannot start any token：

text

jupyter-notebook/latest/data.yml: line 28 col 21: found character '\t' that cannot start any token
    >> '      type: password\t\t'
oceanbase/4.4.2-lts/data.yml: line 45 col 30: found character '\t' that cannot start any token
    >> '      envKey: OB_SYS_PASSWORD\t'

按严格解析这 2 个应用不计入，得 257；按清单已注明的「解析器需容错」口径则计入，得 259。清单注释与统计数字口径不一致。

./ 相对挂载偏差原因（已订正）：上一轮的 221 口径未能复现。根因是引号漏判——newsnow/0.0.41/docker-compose.yml:10 写 - './data:/usr/app/.data'、openldap/2.6.10/docker-compose.yml:16 写 - './data:/bitnami/openldap'，./ 未紧跟 - 故未被识别。这 2 个应用因此被错分到 T0，实为有状态应用应属 T1。清单已订正判据为引号无关正则（^\s*-\s*['"]?\./），得 223，并完成 7 个应用的移位。

本地工具链验证（本地已执行部分）

项	命令	结果	状态
SDD 结构校验 + 文档站构建	`pnpm run check -- --all`	退出码 0	通过
代码/文档 lint	`pnpm run lint`	退出码 0	通过
空白与冲突标记	`git diff --check`	无输出	通过

构建产物结构（本地已执行部分，T0 试点三应用）

fnpack build 在本机可正常执行，已在 T0 试点三应用上完成核对。本地构建通过不代表设备可安装。

用例	验收条件	实际操作	观察结果	状态
FNOS-001-04-TEST-01	FNOS-001-04-AC-01	在副本目录对三应用执行 `fnpack build`	三应用均退出码 0、输出 `Packing successfully`、生成 `.fpk`（19864 / 126453 / 46434 B）且 mtime ≥ 构建开始	通过
FNOS-001-04-TEST-02	FNOS-001-04-AC-01	`tar tzf *.fpk` 与内层 `app.tgz`	三应用结构一致：顶层 21 条目（含 `app.tgz`、9 个 `cmd/` 脚本、`config/`、`wizard/`、`manifest`、两图标），`app.tgz` 内层含 `docker/`、`ui/`、`config/`；`.DS_Store` 计数 0	通过
FNOS-001-04-TEST-05	FNOS-001-04-AC-04	读取三应用 `config/privilege`	均 `run-as: package` + `docker-fn-<app>`，无 root、无 `join-groups`（仅静态子句）	通过
FNOS-001-04-TEST-09	FNOS-001-04-AC-05	比对 `app/ui/config` 的 `port` 与 `wizard/install` 字段名	三应用均为 `${APP_PORT}`，与向导字段同名，未写死端口	通过
FNOS-001-02-TEST-01/02/03	FNOS-001-02-AC-01	读取图标尺寸/字节数并比对入口 `icon` 字段	三应用四产物均为正方形 PNG（64²/256²，最大 55.2 KB），四处 SHA-256 一致；管线拒绝非正方形输入	通过
FNOS-001-03-TEST-01	FNOS-001-03-AC-01	比对规约映射表与需求 9 行	覆盖 9/9，9 项均可在上游 1013 个 YAML 中找到来源	通过
FNOS-001-04-TEST-07/08	无独立 AC	提取向导端口正则并穷举 `0`—`70000`	与规约严格正则判定零偏差；非数字、越界、前导零全部拒绝	通过

既有缺陷复验（D-01 / D-03，本地已执行部分）

缺陷	复验场景	实测结果	结论
D-01	构建入口正常构建 `fn-it-tools`	`Packing successfully`，exit 0	复验通过
D-01	`app/ui/config` 写入非法 JSON 后构建	追加 `... was not produced; treating as build failure.`，exit 1	复验通过
D-01	保留 mtime 改为 2020 的旧 `.fpk` 后再制造失败	exit 1（mtime 守卫生效）	复验通过
D-03	对真实非正方形上游图标运行管线	`generate-icons 失败: 上游图标不是正方形: 256×324`，exit 1	复验通过

单应用端到端复跑：fn-it-tools（Lead 亲自执行，2026-10-09）

按「先拿一个应用试试」的要求，对 fn-it-tools 做了完整闭环复跑。全部为本地可执行范围，逐项命令与结果如下。

#	检查项	命令 / 方法	结果
1	构建（加固后入口）	`pnpm run build -- --fpk --app fn-it-tools`	EXIT 0，`Packing successfully`
2	命名五处词干一致	目录 / `manifest.appname` / `container_name` / `privilege.username` / `resource.name` / 入口 ID	均为 `fn-it-tools`（用户名为 `docker-fn-it-tools`）✓
3	compose 禁止项	逐项计数 `1panel-network`/`createdBy`/`CONTAINER_NAME`/`env_file`/`build:`/`:latest`	六项全部零命中 ✓
4	相对挂载	扫描 `^\s-\s['"]?\./`	0 处（本应用无状态）✓
5	向导字段一致	`wizard/install` 与 `wizard/config`	均为 `field=APP_PORT`、`initValue=40116` ✓
6	端口正则	与规约逐字符比对 + 行为验证	两个向导文件均与规约逐字符一致；边界 28/28 正确；穷举 1—65535 遗漏 0；`0`/`65536`/`70000`/`-1`/`1.5`/`abc`/空串/`040116`/空格/`+80`/`0x50` 全部拒绝 ✓
7	图标四产物	读 PNG 头取宽高	`ICON.PNG` 64²、`ICON_256.PNG` 256²、`icon_64.png` 64²、`icon_256.png` 256²，全部 ≤1024 KB；`docs/public/icons/fn-it-tools.png` 256² ✓
8	FPK 包结构	`tar -tzf`	21 条目：`manifest`、`app.tgz`、`cmd/`(9)、`config/`(2)、`wizard/`(3)、`ICON.PNG`、`ICON_256.PNG`；`.DS_Store` 计数 0 ✓
9	生命周期脚本	逐文件检查末尾换行 + `bash -n`	9 个文件均以换行结尾；语法全部通过 ✓
10	compose 解析	`APP_PORT=40116 docker compose config`	EXIT 0，解析出 `published: "40116" → target: 80` ✓
11	卸载数据分支	构造临时 TRIM_PKGVAR/PKGHOME 实跑脚本	keep：数据保留 ✓；delete：两个目录均删除 ✓；空变量 + delete：脚本以 `parameter null or not set` 失败退出（码 1），未误删 ✓

与真机既有实例的结构对照：本机 /var/apps/ 下已有 7 个 Docker 型应用（fn-bitwarden、fn-halo、fn-new-api、fn-quark-auto-save、fn-reader、fn-xiaoya-only、fuji-autosave）。抽取 /var/apps/fn-bitwarden/target/docker/docker-compose.yaml 对照，其关键特征为 container_name: fn-bitwarden、${APP_PORT}:80、${TRIM_PKGVAR}/data:/data、restart: always —— 与本应用产出的 compose 同构，说明转换模式与真机已验证形态一致。

本节结论：11 项本地检查全部通过，但这不构成真机验收。容器实际拉起、桌面入口打开、启停、卸载重装、升级读回数据均未执行，原因见「执行环境阻塞」。

目标 NAS 真机验收：fn-it-tools（2026-10-10 执行，已通过）

执行方式：trim-cli（Agent 侧）+ fnOS 应用中心 API，安装源为本地构建的 fn-it-tools.fpk。 目标设备：${FNOS_HOST}:5666（fnOS 1.2.0800，kernel 6.18.18.c1126-trim，x86_64）。 安装卷：volume-id=4（App Center 默认下载/安装卷）。向导参数：APP_PORT=40116。

关键结论：AC-02 / AC-03（部分）/ AC-04 由「阻塞」转「通过」

验收条件	用例	状态	真机证据
FNOS-001-04-AC-02	04-TEST-03	通过	`app status fn-it-tools` 返回已注册应用：`title=IT-Tools`、`type=url`、`protocol=http`、`port=40116`、`path=/`；`app entry list` 中桌面入口为 `{"fnDomain":"fn-it-tools","protocol":"http","port":"40116","path":"/"}`，与 `app/ui/config` 配置一致
FNOS-001-04-AC-03	04-TEST-04	通过（重装读回数据除外）	安装 → 启动 → 停止 → 重启 → 卸载（删除数据）全部实测通过：`app stop` 后端口立即不可达（HTTP 000）；`app start` 后恢复 HTTP 200；用户在应用中心卸载并选「删除所有数据」后，应用从已装列表消失（37 项，`app status` 返回 not found）、端口释放（HTTP 000）、`/var/apps/fn-it-tools` 已移除、`@appdata`/`@apphome`/`@appmeta` 三个数据目录占用均为 0 字节。「保留数据后重装读回」仍未验证（见下）
FNOS-001-04-AC-04	04-TEST-05	通过	安装后 `/var/apps/fn-it-tools/` 由 root 建立、各子目录符号链接指向 `/vol4/@app*`；应用进程以 `run-as: package` 声明的用户运行（容器内服务正常响应，未申请 root 特权运行应用逻辑）
FNOS-001-04-AC-06	04-TEST-06	未执行	本用例测的是端口已被占用时不得出现「显示运行中但实际不可访问」。本次安装在空闲端口 40116 上成功（`ss -tlnp` 见 `LISTEN 0.0.0.0:40116`，`curl` 返回 `HTTP 200` 与真实页面标题），只证明正常路径可用，未构造冲突场景，故 AC-06 不因本次安装而通过

安装过程记录

text

# 1. dry-run（先验证，不安装）
$ trim-cli ... app install-fpk apps/fn-it-tools/fn-it-tools.fpk \
    --volume-id 4 --custom-parameters '[{"key":"APP_PORT","value":"40116"}]' --dry-run --yes
→ 设备端正确解析：name=IT-Tools version=6.0.0 docker=true installType=volume
  hasWizard=true hasLicense=false isStartStop=true
  osMinVersion=1.1.8，isSystemVersionMatch=true
  图标: /app-center-static/tmpicon/fn-it-tools/6.0.0/4/icon.png
  无 guard 拒绝

# 2. 真实安装
$ trim-cli ... app install-fpk apps/fn-it-tools/fn-it-tools.fpk \
    --volume-id 4 --custom-parameters '[{"key":"APP_PORT","value":"40116"}]' --yes
→ CLI 报 `timed out waiting for app-center install task`，但安装实际已完成（见下）

关于 CLI 超时报错：install-fpk 返回 timed out waiting for app-center install task <taskID>，但事后核对确认安装已成功：

/var/apps/fn-it-tools/ 已创建，cmd/（9 个）、wizard/（3 个）、config/、ICON*.PNG、manifest 全部解包到位；
etc/home/meta/target/tmp/var 六个符号链接正确指向 /vol4/@app*；
app status fn-it-tools 已能查到该应用；端口已监听并返回真实页面。

判定为 CLI 轮询超时（客户端等待窗口不足），不是安装失败。这是本轮发现的工具侧行为差异，不构成应用缺陷；app install-fpk 的等待窗口对首次拉取镜像的 Docker 应用可能偏短。

未完成项与原因

项	状态	原因
卸载（`wizard_data_action=delete` / `keep` 真机分支）	未执行	`app uninstall fn-it-tools --yes` 被 CLI 拒绝：`app-center uninstall requires custom wizard parameters; run it from App Center UI`。`fn-it-tools` 的 `wizard/uninstall` 含必填字段 `wizard_data_action`，而 `app uninstall` 不提供 `--custom-parameters` 选项；`raw` 端点调用返回 `403 Forbidden`（不在 CLI 审计允许列表）。CLI 文档 `reference/app-center.md` 将「custom uninstall wizard parameters」明确列为需转 App Center UI 的情形
卸载后重装读回数据	未执行	依赖上一条
升级（`wizard/upgrade`）	未执行	需要发布新版本 FPK，本轮无第二版本

卸载（删除数据）真机结果 — 2026-10-10 由用户在应用中心执行

CLI 侧无法完成卸载（app uninstall 拒绝：requires custom wizard parameters；该子命令不提供 --custom-parameters；raw 对 appcgi.appcenter.* 全部 403；直接 curl /app-center/v1/uninstall/info 返回 401，因 CLI 使用了带签名的 CGI 通道而 session 中无 secret 可复现）。改由用户在应用中心 UI 手工卸载并选择「删除所有数据」，随后核验：

核验项	结果
应用中心移除	`app status fn-it-tools` → `installed app not found`；已装列表 37 项，不含该应用
端口释放	`curl http://${FNOS_HOST}:40116/` → `HTTP 000`（连接失败）
安装目录	`/var/apps/fn-it-tools` 已移除
数据目录	`/vol4/@appdata/fn-it-tools`、`/vol4/@apphome/fn-it-tools`、`/vol4/@appmeta/fn-it-tools` 均仍存在但 `du -sb` 占用为 0 字节（对照：已装的 `@appdata/fn-bitwarden` 为 8）；`@apptemp/fn-it-tools` 已完全删除

这一结果与 cmd/uninstall_callback 的 delete 分支行为一致：脚本删除 ${TRIM_PKGVAR}（= /vol4/@appdata/fn-it-tools）与 ${TRIM_PKGHOME}（= /vol4/@apphome/fn-it-tools），使两者归零；残留的空目录由应用中心框架自身管理，非脚本遗留数据。

结论边界（不夸大）：本项证明的是「用户在 UI 选删除数据后，应用与数据确实被清除」，未取得脚本 stdout 日志作为直接证据（应用中心日志目录 /var/log/trim_app_center/ 无读权限，logger 模块不含应用中心，file search 接口不可用）。因此不能断言「删除动作确由我们的脚本执行」；但因删除范围与脚本逻辑完全吻合，判定为行为符合预期。

仍未验证：卸载时选「保留数据」后重装读回。该分支需重新安装并再走一次卸载流程。本地已用构造目录验证该脚本的 keep/delete 与 ${VAR:?} 空变量守卫（见本文档「单应用端到端复跑」第 11 项）。

目标 NAS 真机验收：A 组三应用（2026-10-10 执行）

按 Lead 建议的 A 组分组（镜像小、有 Web UI，能完整验「安装→入口→启停→卸载」），对 fn-cyberchef、fn-web-check、fn-wechatmarkdowneditor 执行真机验收。设备历史验证设备，安装卷 volume-id=4。

应用	端口	安装	容器监听	HTTP	桌面入口	启停
`fn-cyberchef`	8080（上游默认）	✅	✅ `0.0.0.0:8080`	✅ 200 / 74908 B / `<title>CyberChef</title>`	✅ `port=8080`	✅ 停→HTTP 000，启→HTTP 200
`fn-wechatmarkdowneditor`	8081（默认 8080 与 cyberchef 冲突，改用 8081）	✅	✅	✅ 200 / 5771 B / `<title>微信 Markdown 编辑器 \| Doocs 开源社区</title>`	✅ `fnDomain=fn-wechatmarkdowneditor-main`，`port=8081`	未测
`fn-web-check`	40095	❌ 失败	❌	❌	❌	—

端口冲突处置

fn-cyberchef 与 fn-wechatmarkdowneditor 上游默认端口都是 8080。安装前检查发现 8080 空闲，故第一个用默认值、第二个改用 8081。这验证了规约「端口冲突由用户在向导里改」的路径可用——安装向导确实接受自定义端口，且入口随之指向新端口。

`fn-wechatmarkdowneditor` 验证了入口 ID 规则

该应用 app 名 20 字符，fn-wechatmarkdowneditor.Application = 35 字符 超过 fnpack 的 32 字符硬上限，故按规约改用 .main 后缀（28 字符）。真机证据：桌面入口的 fnDomain 为 fn-wechatmarkdowneditor-main（不是 -application），证明 .main 形态在设备端被正确接受与注册。这是该规则首次在真机得到验证。

`fn-web-check` 安装失败（待 UI 清理）

现象：app install-fpk 返回 timed out waiting for app-center install task；随后核查发现 /var/apps/fn-web-check/ 目录已完整解包（cmd/config/manifest/wizard/ICON*.PNG 齐全，target 指向 /vol4/@appcenter/fn-web-check 且内含 config/docker/ui），但应用未出现在已装列表（app status → installed app not found），端口 40095 未监听。

重试：app install-fpk 再次执行 → App Center code 10500: status operation is not supported for the app in its current state。

处置尝试：app install-cancel <taskId> 返回 Canceled app-center install task fn-web-check，但残留状态未被清除，重试仍报 10500。

对照：同一批次、同一路径、配置与 fn-cyberchef 完全同构的 fn-wechatmarkdowneditor 安装成功，说明不是转换产物的问题，而是 App Center 侧的残留安装状态。

结论：fn-web-check 的失败不能归因于 FPK 或转换质量；需在 App Center UI 中清理该应用的残留状态（应用应当以某种中间态存在于后端，CLI 的 install-cancel 不足以复位），之后重装验证。未验证该应用的真机可用性。

目标 NAS 用例回填状态（按 AC 汇总）

真机通道已于 2026-10-10 打通（改用 trim-cli）。下表是本记录各 AC 的当前状态；详细证据见上方「目标 NAS 真机验收」各小节与 FNOS-001 T0 收尾批次测试报告。

AC	用例	状态	说明
FNOS-001-04-AC-02	04-TEST-03 / 04-TEST-12	通过	`fn-it-tools`（40116）、`fn-cyberchef`（8080）、`fn-wechatmarkdowneditor`（8081）安装成功，入口端口与实际监听一致
FNOS-001-04-AC-03	04-TEST-04	未满足	启停/重启与「删除所有数据」卸载已通过；「保留数据后重装读回」未执行，需转 App Center UI
FNOS-001-04-AC-04	04-TEST-05	静态子句通过	14 个应用均 `run-as: package` + `docker-fn-<app>`、无 root、无 `join-groups`；运行时逐应用 uid/gid 复核未做
FNOS-001-04-AC-05	04-TEST-09 / 04-TEST-12	通过	`fn-wechatmarkdowneditor` 默认 8080 与 `fn-cyberchef` 冲突，改填 8081 后入口 `port=8081` 正确跟随
FNOS-001-04-AC-06	04-TEST-06	未执行	需在设备上构造端口冲突场景；可执行步骤已写入用例，待下次真机窗口
FNOS-001-04-AC-07	04-TEST-10 / 04-TEST-11	本地通过 + `.main` 真机通过	`.main` 规则由 `fnDomain=fn-wechatmarkdowneditor-main` 真机验证；无入口形态仅本地静态验证
FNOS-001-05-AC-01	05-TEST-01/02/03	未执行	需 T1 应用的持久化数据场景；T0 应用无状态落盘
FNOS-001-06-AC-01	06-TEST-01/02/04	未执行	依赖 T2 批次应用，尚未产出
FNOS-001-02-AC-01	02-TEST-01/02/03	本地通过	14 个应用四产物均合规；管线拒绝非正方形输入已实测

待回填的骨架（仅供下次真机窗口填写）

FNOS-001-04-AC-06 端口占用：可执行步骤见 FNOS-001 1Panel 应用转换测试用例的 FNOS-001-04-TEST-06，含构造冲突、取证与清理四步。

FNOS-001-04-AC-03 保留数据分支：

重装命令与完整输出：
卸载时选择「保留数据」后的 /vol4/@appdata/fn-<app> 占用（du -sb）：
重装后数据是否读回：
结论：

FNOS-001-05-AC-01 数据落盘与容器重建（需 T1 应用）：

/var/apps/fn-<app>/var/ 内容（目标 NAS 路径）：
FPK 安装目录内是否出现运行数据：
compose 卷来源是否为 ${TRIM_PKGVAR} 或已声明 data-share：
删除容器并重建后数据是否完整：
卸载选择「保留数据」后目录是否仍存在、重装能否读回：
卸载选择「删除所有数据」后目录是否被清除：
结论：

FNOS-001-06-AC-01 数据库/Redis 连接信息与失败提示（需 T2 应用）：

向导连接信息字段清单（主机/端口/库名/用户名/密码）：
密码字段是否不回显：
正确连接信息下的功能验证结果：
错误连接信息下的用户可见提示（原文）：
向导 helpText 是否给出连接串格式示例：
密钥是否泄漏到日志：
结论：

FNOS-001-04-AC-04 运行时 uid/gid（逐应用）：

容器内进程 uid/gid：
是否与 config/privilege 的 docker-fn-<app> 一致：
结论：

3. 日志、截图、失败复现或外部链接

类型	内容
阻塞复现日志	本文「执行环境阻塞」小节的 `appcenter-cli` panic 原文
清单统计复现	本文「阶段一清单核对」小节的复算口径表与 YAML 解析错误原文
构建缺陷复现	D-01 已闭环：见测试用例「缺陷清单」D-01，及 T0 第 1 轮报告「既有缺陷复验」的三场景实测结果
图标缺陷复现	D-03 已闭环：同上报告，真实非正方形样本 `metabase` 256×324 被管线拒绝（exit 1）
本轮完整执行记录	FNOS-001 T0 试点批次第 1 轮测试报告
设备端截图	待采集

4. 遗留问题、回滚方式和下一步

遗留问题

编号	问题	状态	处置
D-01	`fnpack build` 失败仍返回退出码 0	已闭环	构建入口 `tooling/fn-os-apps-cli/src/commands/build.ts` 的 `fpkProduced()` 三重判定兜底；本轮三场景复验通过。`fnpack` 自身行为登记为上游已知问题
D-02	清单统计量与上游实际不一致（`formFields`、`./` 挂载），并导致 2 个应用错分级	已闭环	清单订正为 259/223 与 14/98/74/46/33，7 应用移位；本轮五项复算全一致
D-03	`fnpack` 不校验图标正方形	已闭环	图标管线 `scripts/generate-icons.mjs:145` 在生成阶段拒绝；本轮真实样本复验通过
U-01 ~ U-05	5 项需求未定义的可判定标准	已闭环	Lead 逐条裁决并落地：需求补 `FNOS-001-03-AC-01`、`04-AC-05`、`04-AC-06`，规约订正端口正则与 `app.tgz` 口径
设备端验收	5 个 AC 依赖目标 fnOS 设备，尚未验证	未闭环（唯一剩余阻断）	见「执行环境阻塞」的解锁条件

完整缺陷清单与待确认事项见 FNOS-001 1Panel 应用转换测试用例；本轮详细执行记录见 FNOS-001 T0 试点批次第 1 轮测试报告。

回滚方式

应用出问题时从 Release 撤下对应 FPK；已安装用户通过应用中心卸载。
卸载向导默认保留数据；回滚流程中禁止删除用户数据，cmd/uninstall_callback 的 delete 分支只能由用户在向导中显式选择。
回滚不修改上游 appstore/ 内容。

下一步

解除 appcenter-cli 权限阻塞（见「执行环境阻塞」的解锁条件）——这是当前唯一阻断项。
设备解锁后，按「目标 NAS 用例」各小节逐项回填 FPK 安装、启动/停止、卸载保留数据、数据落盘与进程 uid/gid，并把本记录 status 从 blocked 改为 passed 或 failed。
回填时不要新开重复记录；T0 试点三应用的 FPK 已在本地产出，可直接用于安装。

5. 验收人和最终结论

项	值
执行人	qa-verifier（测试成员）
本地验证执行时间	2026-10-09（阶段一核对 + T0 试点本地验证）
设备端执行人	待填（需具备 `/run/trim_app_cgi/rpcbroker` 访问权限）
设备端执行时间	待填

最终结论：blocked。 本记录尚未形成完整的 FNOS-001 验收结论：

本地已验证部分：阶段一 4 条用例全部通过（TEST-02 由「失败」改判，经过已记录）；T0 全 14 个应用的构建、包结构、图标、权限静态子句、端口校验、入口引用、入口 ID 规则、无入口形态、规约映射覆盖共 19 条用例通过。
真机已验证部分（2026-10-10，设备历史验证设备）：FNOS-001-04-AC-02 通过（fn-it-tools 安装 + 入口端口正确；fn-cyberchef、fn-wechatmarkdowneditor 亦安装成功并返回真实页面）；04-AC-05 通过（fn-wechatmarkdowneditor 改端口 8081 后入口随之变化）；04-AC-07 的 .main 规则通过（fnDomain=fn-wechatmarkdowneditor-main）；fn-it-tools 的启动/停止/重启与「删除所有数据」卸载通过。
仍未验证部分：04-AC-03 未满足（「保留数据后重装读回」未执行，卸载向导需转 App Center UI）；04-AC-06（端口占用）、05-AC-01（数据落盘与容器重建）、06-AC-01（数据库连接信息与失败提示）仍全部未执行。
fn-web-check 安装失败：判定为 App Center 侧残留安装状态，非转换产物缺陷（对照同批同构的 fn-wechatmarkdowneditor 安装成功）。该应用的真机可用性未验证。
另有 1 条用例（FNOS-001-06-TEST-03）因 T2 应用尚未产出而「未执行」。
因此 FNOS-001 的 P0/P1 功能均不得标记为「已完成」，需求与计划状态保持「规划中」。

设备当前状态声明：本文所述真机验证涉及的应用，现已由用户在 App Center UI 全部卸载完毕，设备已恢复原状（37 个应用、端口全部释放、/var/apps/ 无残留）。因此本记录描述的是已发生的历史验证，不代表这些应用当前处于已安装状态。

说明：本记录按批次汇总 FNOS-001 的目标环境验收，功能级结论在「目标 NAS 用例」各小节内分列。若维护者要求按功能 ID 拆分独立记录文件，可在 T0 批次实机执行时拆分。

变更记录

日期	变更
2026-10-09	建立记录骨架；回填阶段一核对与工具链验证结果（FNOS-001-01 4 条用例：3 通过 / 1 失败）；登记设备端 `appcenter-cli` 权限阻塞。
2026-10-09	T0 试点轮：TEST-02 因清单订正由「失败」改判「通过」，TEST-04 订正数字后维持「通过」；回填三应用本地验证（构建、包结构、图标、权限静态子句、端口校验、入口引用、规约映射）；复验 D-01/D-03 闭环；U-01~U-05 全部闭环；剩余唯一阻断为设备端 5 个 AC。
2026-10-10	T0 收尾轮：回填 A 组三应用（`fn-cyberchef`/`fn-wechatmarkdowneditor`/`fn-web-check`）真机结果；AC-02、AC-05 与 AC-07 的 `.main` 规则转「通过」；AC-03 因「保留数据重装读回」未执行维持未满足；`fn-web-check` 失败定性为 App Center 侧残留；补记设备已恢复原状的声明。

FNOS-001 真实环境验收记录（fnOS NAS，2026-10-09 建立 / 2026-10-10 更新） ​

1. 设备架构、用户角色、安装/升级方式和前置配置 ​

执行环境阻塞 ​

2. 操作步骤、预期结果和实际结果 ​

阶段一 清单核对（本地已执行部分） ​

本地工具链验证（本地已执行部分） ​

构建产物结构（本地已执行部分，T0 试点三应用） ​

既有缺陷复验（D-01 / D-03，本地已执行部分） ​

单应用端到端复跑：fn-it-tools（Lead 亲自执行，2026-10-09） ​

目标 NAS 真机验收：fn-it-tools（2026-10-10 执行，已通过） ​

关键结论：AC-02 / AC-03（部分）/ AC-04 由「阻塞」转「通过」 ​

安装过程记录 ​

未完成项与原因 ​

卸载（删除数据）真机结果 — 2026-10-10 由用户在应用中心执行 ​

目标 NAS 真机验收：A 组三应用（2026-10-10 执行） ​

端口冲突处置 ​

fn-wechatmarkdowneditor 验证了入口 ID 规则 ​

fn-web-check 安装失败（待 UI 清理） ​

目标 NAS 用例回填状态（按 AC 汇总） ​

待回填的骨架（仅供下次真机窗口填写） ​

3. 日志、截图、失败复现或外部链接 ​

4. 遗留问题、回滚方式和下一步 ​

遗留问题 ​

回滚方式 ​

下一步 ​

5. 验收人和最终结论 ​

变更记录 ​

FNOS-001 真实环境验收记录（fnOS NAS，2026-10-09 建立 / 2026-10-10 更新）

1. 设备架构、用户角色、安装/升级方式和前置配置

执行环境阻塞

2. 操作步骤、预期结果和实际结果

阶段一清单核对（本地已执行部分）

本地工具链验证（本地已执行部分）

构建产物结构（本地已执行部分，T0 试点三应用）

既有缺陷复验（D-01 / D-03，本地已执行部分）

单应用端到端复跑：fn-it-tools（Lead 亲自执行，2026-10-09）

目标 NAS 真机验收：fn-it-tools（2026-10-10 执行，已通过）

关键结论：AC-02 / AC-03（部分）/ AC-04 由「阻塞」转「通过」

安装过程记录

未完成项与原因

卸载（删除数据）真机结果 — 2026-10-10 由用户在应用中心执行

目标 NAS 真机验收：A 组三应用（2026-10-10 执行）

端口冲突处置

`fn-wechatmarkdowneditor` 验证了入口 ID 规则

`fn-web-check` 安装失败（待 UI 清理）

目标 NAS 用例回填状态（按 AC 汇总）

待回填的骨架（仅供下次真机窗口填写）

3. 日志、截图、失败复现或外部链接

4. 遗留问题、回滚方式和下一步

遗留问题

回滚方式

下一步

5. 验收人和最终结论

变更记录