root/geo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
liangxu
2026-05-07 12:08:24 +08:00
parent 21fee01688
commit d17db41108
3 changed files with 26 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
findings.md
+7
View File
@@ -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. - 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 ## 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. - 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`. - `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'`. - 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
+7
View File
@@ -807,3 +807,10 @@
- `git diff --check` - `git diff --check`
- Caveat: - 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. - `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
+12
View File
@@ -329,6 +329,18 @@ Phase 47
- [x] Record residual test caveats - [x] Record residual test caveats
- **Status:** complete - **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 ## Key Questions
1. How should the desktop client defer and locally optimize monitor-task execution without violating one-task-per-platform serialism? 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? 2. What is the smallest durable local cache that allows same-day resume while safely dropping stale next-day monitor tasks?