Fix mobile review pane scrolling and improve delta colors

.agents/skills/codex-app-parity/SKILL.md

@@ -218,6 +218,45 @@ If a finding conflicts with current official docs or current official code, trea
   - Run build/typecheck.
   - Run Playwright in headless mode and capture a screenshot showing sidebar order.
 
+## Findings: Plugin Runtime Surface (2026-04-17)
+
+- On `codex-cli 0.121.0`, `meta/methods` exposes stable plugin-related RPCs through the app bridge:
+  - `plugin/list`
+  - `plugin/read`
+  - `plugin/install`
+  - `plugin/uninstall`
+  - `app/list`
+  - `mcpServerStatus/list`
+  - `mcpServer/oauth/login`
+  - `config/mcpServer/reload`
+- `experimentalFeature/list` reports both `apps` and `plugins` as `stage: "stable"` and enabled by default in this runtime.
+- `plugin/read` is the best detail source for desktop-parity plugin UI:
+  - plugin marketplace name/path
+  - manifest/interface display metadata
+  - bundled skills with effective enabled state
+  - related apps with `needsAuth`
+  - MCP server names
+- `plugin/install` has side effects on the user Codex environment and returns connector follow-up data:
+  - response shape includes `authPolicy`
+  - response shape includes `appsNeedingAuth[]`
+  - use a real install only from an explicit user action, not from capability probing
+- `app/list/updated` notifications arrive after connector data refreshes, so plugin/app settings pages should subscribe and update in-place rather than requiring a full page reload.
+- `app/list/updated` already carries the latest merged `data` payload; a UI that reacts by issuing a new foreground `app/list` fetch can flash back to a loading state and lose scroll position on the Apps page. Consume the notification payload in place when possible.
+- Composer invocation parity for plugins is validated against live `turn/start` payloads:
+  - selected plugin should prepend a UI token such as `@linear` into the text input payload
+  - selected plugin should also add a separate `mention` content item with `path: "plugin://linear@openai-curated"`
+  - both are needed for reliable app-server routing; a mention item alone is not the documented parity path
+
+## Findings: Automations Surface (2026-04-17)
+
+- Official Codex app docs expose a first-class `Automations` concept and deeplink, but `codex-cli 0.121.0` app-server does not currently expose any `automation/*` or `automations/*` RPC methods in `meta/methods`.
+- In this runtime, automation parity therefore cannot be implemented as a thin app-server proxy the way `Plugins` and `Apps` can.
+- The closest official execution surface available locally is `codex exec`, which the official repository explicitly describes as the headless/non-interactive automation surface.
+- A web-shell automation feature built on current official surfaces should:
+  - persist its own schedule/task metadata locally
+  - schedule background runs in the web server process while the app is running
+  - invoke `codex exec` with explicit cwd/model/sandbox overrides rather than waiting for missing app-server automation RPCs
+
 ## Findings: Context Usage Meter (2026-04-01)
 
 - Official `openai/codex` app-server protocol exposes per-thread context telemetry via `thread/tokenUsage/updated` with:
@@ -534,3 +573,17 @@ If a finding conflicts with current official docs or current official code, trea
 - A safer mobile fallback is:
   - hide the floating badge on mobile
   - expose the same version/worktree string inside the existing Settings panel instead of adding another mobile-only surface
+
+## Findings: App-Server Files UI Baseline (2026-04-14)
+
+- In Codex CLI `0.120.0`, `codex app-server generate-ts --experimental` exposes a stable read-only filesystem baseline for UI work: `fs/readDirectory`, `fs/getMetadata`, and `fs/readFile`, plus write/watch methods that can be layered later.
+- The generated protocol is enough to implement an in-app file browser even when official public docs or official repo UI references do not provide a concrete desktop/web file-explorer spec.
+- `fs/watch` is explicitly connection-scoped via `watchId`; for web clients that use stateless HTTP RPC plus a separate notification transport, treating watch support as a later phase is safer than coupling it into an MVP explorer.
+
+## Findings: Model Catalog Metadata (2026-04-25)
+
+- In Codex CLI `0.125.0`, `model/list` returns structured model metadata for the default picker, not just ids. Visible entries include fields such as `displayName`, `description`, `supportedReasoningEfforts`, `defaultReasoningEffort`, and `isDefault`.
+- The visible default-picker set observed in this environment includes `gpt-5.4`, `gpt-5.4-mini`, `gpt-5.3-codex`, `gpt-5.3-codex-spark`, `gpt-5.2`, `gpt-5.2-codex`, `gpt-5.1-codex-max`, and `gpt-5.1-codex-mini`.
+- `gpt-5.4` is currently marked `isDefault: true` here, so web fallback/retry logic should prefer the app-server default model instead of hardcoding an older fallback such as `gpt-5.2-codex`.
+- Some models expose narrower reasoning sets than the full global enum. For example, `gpt-5.1-codex-mini` only advertises `medium` and `high`, while `gpt-5.3-codex-spark` defaults to `high`.
+- For codexui parity, model pickers should render `displayName`, and Thinking controls should be derived from the selected model's `supportedReasoningEfforts` plus `defaultReasoningEffort`.

.agents/skills/npm-publish/SKILL.md

@@ -42,6 +42,12 @@ description: 用于本仓库的 npm 发布流程。当用户提到发布到 npm
   - 执行 `npm run build`
   - 执行 `npm publish --access public`
 
+实际发布完成后，skill 还必须继续执行一次远端推送，把 release commit 与 tag 一并推到当前分支的 upstream：
+
+```bash
+git push --follow-tags
+```
+
 默认必须通过仓库现有脚本发布：
 
 ```bash
@@ -98,9 +104,15 @@ npm view "$(node -p "require('./package.json').name")" dist-tags.latest version
 bash publish.sh
 ```
 
+如果 `bash publish.sh` 成功，默认还要继续执行：
+
+```bash
+git push --follow-tags
+```
+
 除非命中上面的两个例外，否则不要改用手动 `npm publish` 流程。
 如果 `publish.sh` 明显失效，应先修复脚本或修复它依赖的发布配置，再重新执行 `bash publish.sh`。
-脚本当前的实际发布顺序应理解为：先改版本，再提交并打 tag，然后 build，最后 npm publish。
+默认发布顺序应理解为：先改版本，再提交并打 tag，然后 build，接着 npm publish，最后 `git push --follow-tags`。
 在进入改版本之前，脚本还会先同步 tracking branch 的远端状态；如果本地落后且无法安全 fast-forward，或同步后没有待发布改动，都会直接终止。
 
 ### 4. 发布后验证
@@ -128,6 +140,7 @@ npm pack --dry-run
 - 发布前的分支同步结果（up to date / fast-forward / 因落后或分叉被阻止）
 - 发布前本地版本、registry 最新版本、最终发布版本
 - 本次生成的 release commit 和 tag
+- 发布后是否已执行 `git push --follow-tags`，以及远端推送结果
 - 发布后 `latest` 是否已指向预期版本
 
 如果发布失败，要说明失败命令、失败阶段和下一步阻塞点。
@@ -136,4 +149,4 @@ npm pack --dry-run
 
 - 如果为了发布修改了仓库代码或发布脚本，完成后仍要遵循仓库默认收口：`npm run build`，并重启 `4173` 的 `tmux` 会话
 - 如果用户要求验证 `npx` 行为，先发布，再验证已发布的 `@latest` 包；不要用本地未发布结果代替
-- “push” 在本仓库语境下不等于推送远端；除非用户明确要求，否则不要执行远端推送
+- 对 `npm-publish` skill 而言，“实际发布”默认包含发布成功后的远端推送；应执行 `git push --follow-tags`，而不是停留在本地 release commit/tag

package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nervmor/codexui",
-  "version": "1.0.16",
+  "version": "1.0.23",
   "description": "A lightweight web interface for Codex that runs on top of the Codex app-server, allowing remote access from any browser",
   "type": "module",
   "license": "MIT",
@@ -39,11 +39,13 @@
     "build:frontend": "vue-tsc --noEmit && vite build",
     "build:cli": "tsup",
     "build": "npm run build:frontend && npm run build:cli",
+    "test": "vitest run",
     "preview": "vite preview",
     "prepublishOnly": "npm run build"
   },
   "dependencies": {
     "commander": "^13.1.0",
+    "cron-parser": "^5.5.0",
     "express": "^5.1.0",
     "firebase": "^12.2.1",
     "highlight.js": "^11.11.1",
@@ -57,10 +59,12 @@
     "@types/qrcode-terminal": "^0.12.2",
     "@types/ws": "^8.18.1",
     "@vitejs/plugin-vue": "^5.2.1",
+    "playwright": "^1.59.1",
     "tailwindcss": "^4.1.18",
     "tsup": "^8.4.0",
     "typescript": "^5.7.3",
     "vite": "^6.1.0",
+    "vitest": "^4.1.5",
     "vue": "^3.5.13",
     "vue-router": "^4.6.4",
     "vue-tsc": "^2.2.0"