docs(plan): record publish management research and phase plan

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

findings.md

@@ -7,6 +7,13 @@
 - For desktop AI monitoring, put scheduling authority on the client, keep scraping silent/background-only, allow stale cross-day tasks to be dropped, and avoid fanning one question to all models at once.
 
 ## Research Findings
+- Current 2026-05-07 publish-management request targets `apps/admin-web`: the user wants a new content-management page showing publish title, account/platform, status, task info, time, and actions for external link, opening the desktop client workbench, and retrying.
+- Desktop client already has `PublishManagementView.vue` with the desired table shape and action semantics, but it calls Electron IPC (`window.desktopBridge`). Admin-web needs tenant-authenticated HTTP endpoints instead.
+- Existing backend desktop endpoints are `/api/desktop/publish-tasks` and `/api/desktop/publish-tasks/:id/retry`, but they require desktop client token auth. Tenant API currently exposes publish-job creation only, not publish task list/retry.
+- `DesktopTaskService.ListPublishTasks` already has the correct pagination/title-search/status ordering behavior, but accepts a desktop client context. A tenant variant should scope by request actor/current workspace and created-by user.
+- `PublishJobService.RetryByDesktopTask` already contains retry reconstruction logic, but accepts desktop client context. A tenant variant can reuse the same core flow with actor workspace/user ownership checks.
+- Admin-web content-management nav currently includes media, knowledge, and images under `AppShell.vue`; publish management should join that group as `/publish-management`.
+- Web "open workbench" cannot call Electron IPC directly. A desktop deep-link URL can be used as a link-style entry; if the desktop app does not register that scheme yet, the link is still a front-end contract for the desktop client to adopt.
 - Current review scope: determine whether the monitoring data detail path and the daily scheduled generation of question collection tasks are working.
 - `cmd/scheduler` starts `ScheduleDispatchWorker`, monitoring result recovery, lease recovery, received inspection, and knowledge cleanup; it does not start a worker that generates daily `monitoring_collect_tasks`.
 - The only production code path found so far that inserts `monitoring_collect_tasks` is `MonitoringService.CollectNow` via `ensureCollectNowTasks`; this writes `trigger_source = 'manual'`.

progress.md

@@ -807,3 +807,10 @@
   - `git diff --check`
 - Caveat:
   - `pnpm --filter @geo/desktop-client test -- src/main/device-id.test.ts` ran unrelated existing tests and failed in `deepseek.test.ts` due to a pre-existing missing `electron/main` mock; the new device-id test passes when run directly with vitest.
+
+## 2026-05-07T11:26:26+08:00 - Admin-web publish management start
+
+- Started Phase 48/49 for the user's content-management "发文管理" request.
+- Confirmed desktop-client already has a publish management table with the requested columns/actions, but admin-web needs tenant HTTP APIs because Electron IPC is unavailable in the browser.
+- Scoped implementation to tenant publish task list/retry endpoints plus a new admin-web `/publish-management` page under 内容管理.
+- Noted existing dirty files in i18n/Knowledge/TemplateWizard/config/swagger/knowledge service and will avoid reverting or overwriting unrelated changes.

task_plan.md

@@ -329,6 +329,18 @@ Phase 47
 - [x] Record residual test caveats
 - **Status:** complete
 
+### Phase 48: Admin-Web Publish Management
+- [ ] Expose tenant-authenticated publish task listing and retry APIs
+- [ ] Add admin-web publish-management API client, route, nav entry, and i18n labels
+- [ ] Build the content-management publish management page with title, account/platform, status, task info, time, and action controls
+- **Status:** in_progress
+
+### Phase 49: Publish Management Verification
+- [ ] Run targeted backend and frontend checks
+- [ ] Record changed files, test results, and remaining desktop deep-link caveats
+- [ ] Deliver the completed scope to the user
+- **Status:** pending
+
 ## Key Questions
 1. How should the desktop client defer and locally optimize monitor-task execution without violating one-task-per-platform serialism?
 2. What is the smallest durable local cache that allows same-day resume while safely dropping stale next-day monitor tasks?