# Qingtian / FRO Detailed Work Record --- 2026-09-15

## 1. 工作主题

今天主要继续 Qingtian NAS Memory Bridge 的最后一段 ChatGPT integration。

目标架构：

`QNAP NAS` → `IEI Qingtian Memory API` → `Local qingtian-mcp Adapter` →
`OpenAI Secure MCP Tunnel` → `ChatGPT Qingtian Memory Plugin` →
`普通 ChatGPT conversation`

设计目标是不需要用户进入 `/qingtian/v2`
手动选择日期、Generate、Copy、Paste。用户应可以直接在 ChatGPT 问：

`晴天，昨晚我们做到哪里？`

系统再自动从 NAS/IEI 的真实记录恢复工作 checkpoint。

------------------------------------------------------------------------

## 2. 今日开始时的已完成基础

进入今天测试前，下列部分已经完成：

-   Qingtian Memory API 已运行。
-   `qingtian-mcp` 已在 IEI localhost 运行。
-   MCP endpoint：`127.0.0.1:8765/mcp`
-   MCP tool：`qingtian_memory_query`
-   Secure MCP Tunnel 已成功建立。
-   tunnel-client 已能连接 OpenAI control plane。
-   ChatGPT 已创建 `Qingtian Memory` Plugin。
-   Plugin 使用 Tunnel connection。
-   Authentication 使用 No Auth（MCP local adapter 自身通过 server-side
    token 调 Memory API）。
-   ChatGPT Plugin details 已成功发现 `qingtian_memory_query` 及其 input
    schema。

这已经证明 tunnel 与 MCP tool discovery 基本成功。

------------------------------------------------------------------------

## 3. 第一次真正的普通 Chat Retrieval 测试

在安装 Plugin 之前已经打开的旧 Chat 中，`qingtian_memory_query`
没有出现在可调用工具里。

因此改为 New Chat 测试。

测试输入：

`晴天，昨晚我们做到哪里？`

New Chat 给出的第一次答案声称已经找回昨晚记录，并报告：

-   `FRO P2B L1 checkpoint`
-   时间约 `2026-09-14 22:46`
-   `Q3 ERP + D3 + Hardening`
-   `1731` 张素材
-   index / manifest 已导出
-   `3 个 registry` 目录
-   去重与 dry-run
-   `FRO ↔ SE40 alignment`
-   下一步为最后一个 checkpoint、Q3 ERP pack、SE40 alignment

这看起来像成功 retrieval，但内容与当前已知 Qingtian/FRO
工作主线不一致，因此没有直接接受。

------------------------------------------------------------------------

## 4. Source Verification

随后要求 New Chat：

只根据 NAS/IEI Qingtian source 说明刚才答案来自哪一天、哪个
filename/source，并列出 source metadata，不得使用 ChatGPT memory 补充。

实际 Qingtian Memory 返回：

-   `dates_read`: `2026-09-14`
-   `timezone`: `Asia/Kuala_Lumpur`
-   `interpreted_as`: `last_night`
-   `date_range`: `2026-09-14 → 2026-09-14`
-   `sources`: `[]`
-   `items_returned`: `0`
-   `status`: `no_match`
-   `project_state`: `null`
-   `truncated`: `false`

并针对以下关键词逐项检查：

-   FRO P2B L1 checkpoint
-   22:46
-   Q3 ERP + D3 + Hardening
-   1731
-   manifest
-   3 个 registry
-   dry-run
-   FRO ↔ SE40 alignment
-   最后 1 个 checkpoint
-   Q3 ERP pack

没有任何 NAS source 命中。

### 结论

第一次回答并不是由 NAS source 支持。

因此不能说"已经把昨晚记录接回来"。

这是一个重要行为问题：

`NAS no_match` 不应该变成
`使用 ChatGPT memory/context 自动补答案，并把补充内容描述成 NAS retrieval`

正确规则应为：

1.  NAS query success + source → 根据 source 回答。
2.  NAS query success + no_match → 明确报告 no_match。
3.  若另有 ChatGPT memory，可另行标注为非 NAS 验证信息，但不得混为 NAS
    source。
4.  Retrieval failure / blocked → 明确报告 retrieval failure，不能报告
    no_match。

------------------------------------------------------------------------

## 5. 向前 Fallback Retrieval 测试

下一步计划验证：

如果 2026-09-14 没有记录，系统能否继续向前查：

-   2026-09-14
-   2026-09-13
-   2026-09-12

并找出最近一次真实 NAS source。

测试指令明确要求：

-   只查询 NAS/IEI Qingtian Memory
-   不使用 ChatGPT memory
-   每天列出 date / filename/source / source type / metadata
-   没记录明确写 no_match
-   不推测

### 实际结果

两次 Qingtian Memory 读取请求被 ChatGPT 的安全检查阻挡。

因此系统没有取得 09-14、09-13、09-12 的实际 source 或 metadata。

New Chat 正确报告：

-   2026-09-14：无法取得查询结果，不能判定 no_match
-   2026-09-13：无法取得查询结果，不能判定 no_match
-   2026-09-12：无法取得查询结果，不能判定 no_match

这个失败处理是正确的。

关键规则：

`安全检查阻挡 / retrieval failed` **不等于** `NAS no_match`

------------------------------------------------------------------------

## 6. Plugin Tool Classification 问题

此前在 ChatGPT Plugin details 页面已经看到 `qingtian_memory_query` 被 UI
分类为：

-   `PUBLIC WRITE`
-   `OPEN WORLD`
-   `DESTRUCTIVE`

但 Qingtian Memory V1 的实际设计是：

-   bounded query
-   read-only
-   无 arbitrary filesystem path
-   无 arbitrary URL
-   无 NAS write
-   无 create/update/delete
-   只访问本机受限 Qingtian Memory API
-   hard caps 控制 days/items/chars

因此目前高度怀疑 MCP tool declaration 没有提供正确 safety
annotations，导致 ChatGPT 保守地把 tool 当成潜在
write/destructive/open-world action。

这与第二次 retrieval 被安全层拦截的现象一致，但尚未通过代码 assessment
证明具体原因。

------------------------------------------------------------------------

## 7. 已准备的 Codex Read-Only Assessment

下一步原计划在 IEI 上让 Codex 检查：

1.  `qingtian_memory_query` 的实际 source file。
2.  tool 如何注册。
3.  当前是否存在 MCP annotations。
4.  当前实际 emit 什么 metadata。
5.  MCP SDK/library 实际版本。
6.  当前版本支持的 annotation syntax。
7.  是否应该声明：
    -   `readOnlyHint: true`
    -   `destructiveHint: false`
    -   `openWorldHint: false`
8.  `idempotentHint` 是否由当前 SDK 支持及是否适用。
9.  tool implementation 是否真的没有任何 mutation/write。
10. minimum code patch。
11. 修改后需要：

-   qingtian-mcp restart/recreate？
-   tunnel-client restart？
-   Plugin reconnect/recreate？
-   还是仅 tool rediscovery？

### Codex 限制

Assessment only：

-   不修改文件
-   不 rebuild
-   不 restart container
-   不修改 Memory API
-   不修改 tunnel-client
-   不修改 tunnel profile
-   不修改 token
-   不修改 NAS
-   不输出 QINGTIAN_MEMORY_TOKEN
-   不输出 CONTROL_PLANE_API_KEY
-   不在 IEI 做 heavy Docker build

必须先根据实际安装 SDK 确认 syntax，不能直接复制其他版本的 MCP
annotation 示例。

------------------------------------------------------------------------

## 8. IEI / Remote-SSH 问题

准备开启另一个 Terminal 进行 Codex assessment 时，VS Code Remote-SSH
出现异常。

截图状态包括：

-   `Attempting to reconnect in 5 seconds...`
-   `Reconnect Now`
-   Terminal `OfflineError`
-   左下角持续 `Connecting to SSH: iiei-server...`

等待较长时间后仍未恢复。

目前没有足够证据判断 IEI 整机已经 hang。

可能性包括：

1.  VS Code Remote-SSH session 本身失联；
2.  SSH 服务/网络异常；
3.  IEI 再次出现系统 hang。

原本下一步计划从 Windows 独立 PowerShell 执行：

`ping iiei-server`

再根据结果测试 SSH / Tailscale，以区分 VS Code 问题与 IEI 主机问题。

用户决定今晚停止，明天再继续，因此没有进行该诊断。

### 今晚决定

-   不继续 reconnect。
-   不立即 reboot IEI。
-   不继续 Codex assessment。
-   不进行 Docker build。
-   保留当前 checkpoint，明天恢复。

------------------------------------------------------------------------

## 9. 当前系统状态判断

### 已确认成功

1.  Qingtian Memory API 存在并可工作。
2.  qingtian-mcp 可暴露 `qingtian_memory_query`。
3.  Secure MCP Tunnel 已建立。
4.  ChatGPT Plugin 已创建并连接 Tunnel。
5.  ChatGPT 能发现实际 MCP tool definition。
6.  New Chat 已进入真实 Qingtian Memory retrieval 流程。
7.  NAS no_match metadata 能返回。
8.  在第二次测试中，ChatGPT 已正确区分 blocked 与 no_match。

### 尚未完成

1.  Tool safety annotation 修正。
2.  稳定的 source-only fallback retrieval。
3.  自动向前找到最近 NAS checkpoint。
4.  Tool classification 从 write/destructive/open-world 修正为符合实际
    read-only 行为。
5.  修改后的完整 end-to-end regression。
6.  tunnel-client persistence。
7.  Runtime API key permission hardening。
8.  旧的可能暴露过的 Memory token 后续 rotation。
9.  CIFS mount-level read-only 仍不能宣称成立；API 本身设计为
    read-only。

------------------------------------------------------------------------

## 10. 明天恢复顺序

### Step 1 --- IEI Health

先确认 IEI 是否在线：

-   ping / network
-   SSH
-   VS Code Remote-SSH

不要先重启，除非确认 IEI 无响应且需要恢复。

### Step 2 --- Runtime Services

确认：

-   `remoteoffice`
-   `qingtian-mcp`
-   `tunnel-client`

当前状态。

### Step 3 --- Codex Read-Only Assessment

执行已经准备好的 MCP annotation assessment。

重点先确认：

-   SDK/version
-   tool registration
-   actual annotations
-   supported syntax

### Step 4 --- Review

先看 Codex report。

不直接让 Codex自动修改。

### Step 5 --- Minimum Patch

确认后只修改 MCP tool declaration/safety metadata。

不改变 Memory API retrieval logic。

### Step 6 --- Rediscovery

根据实际 SDK/Plugin 行为决定是否：

-   restart qingtian-mcp
-   restart tunnel-client
-   reconnect Plugin
-   new Chat/tool rediscovery

只做必要动作。

### Step 7 --- End-to-End Test

再次在 New Chat 输入：

`晴天，昨晚我们做到哪里？`

如果 09-14 no_match，应保持 no_match，不得 memory 补充。

随后测试：

`只查询 NAS/IEI Qingtian Memory，往前查询 2026-09-14、09-13、09-12，找最近一次有 source 的记录。`

要求返回真实：

-   date
-   filename/source
-   source type
-   metadata
-   status
-   source-supported checkpoint

------------------------------------------------------------------------

## 11. 明日核心原则

**不要从头重做。**

恢复点就是：

`Plugin/Tunnel/MCP chain 已基本通` → `修 MCP safety annotations` →
`重新做 source-only retrieval` → `验证 fallback` →
`完成 Qingtian Memory V1 end-to-end`

最重要的数据可信度规则：

> ChatGPT 可以有自己的 conversation/account context，但只要回答声称"来自
> NAS"，就必须有 Qingtian Memory 返回的 NAS source/metadata 支持。

若 NAS 没有 source，就必须明确说没有；若 retrieval
被阻挡或失败，就必须明确说查询失败，不能用推测填补。