From d17db41108bc7123f1ead809f1256921dd53836e Mon Sep 17 00:00:00 2001 From: liangxu Date: Thu, 7 May 2026 12:08:24 +0800 Subject: [PATCH] docs(plan): record publish management research and phase plan Co-Authored-By: Claude Opus 4.7 (1M context) --- findings.md | 7 +++++++ progress.md | 7 +++++++ task_plan.md | 12 ++++++++++++ 3 files changed, 26 insertions(+) diff --git a/findings.md b/findings.md index ca337ae..2d19429 100644 --- a/findings.md +++ b/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'`. diff --git a/progress.md b/progress.md index 036ed5f..cac5838 100644 --- a/progress.md +++ b/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. diff --git a/task_plan.md b/task_plan.md index 84f59e3..9c39a38 100644 --- a/task_plan.md +++ b/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?