docs: record Phase 21 foreground publish admission

Log the decision to implement publish priority through admission control
and reserved capacity rather than queue sort order, and capture the
preexisting electron.vite.config.ts typecheck mismatch that blocked a
clean desktop-client typecheck run.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-04-24 09:44:15 +08:00
parent 58207f7f03
commit 4174aafcbc
3 changed files with 35 additions and 1 deletions
+8
View File
@@ -87,6 +87,12 @@
- The `admin-web` tracking page still used the removed browser-plugin monitoring bridge for `立即采集`, even though the current monitoring architecture is desktop-client driven and runs silently in the background.
- The user clarified that `立即采集` must only be available when the current logged-in user's own desktop client is online; another user's online client in the same workspace must not make the action available.
- `MonitoringService.CollectNow` previously fell back to the most recently online workspace client regardless of `user_id`, so the backend rule did not match the desired UI rule until this turn.
- Media publishing is now treated as the desktop runtime foreground channel, while AI monitoring remains background/best-effort. This is implemented through admission control rather than queue ordering alone.
- A new in-memory `publish-scheduler.ts` owns publish queue selection, per-platform active locks, and 3-6 second post-completion platform cooldowns. It intentionally does not persist state or copy monitor scheduler question/cross-day semantics.
- `runtime-controller.ts` now uses per-kind lease-in-flight tracking, so a monitor lease request no longer blocks a publish lease request at the runtime-controller guard.
- Total runtime concurrency is now derived from hardware class, current Electron process health, and optional `GEO_DESKTOP_MAX_TOTAL_CONCURRENCY`, while monitor capacity is capped to leave a reserved foreground publish slot.
- When publish is queued or publish lease is in flight, monitor admission returns zero; even a same-platform/cooldown-blocked publish backlog prevents monitor from consuming the publish reserve.
- Desktop runtime diagnostics now expose `publishScheduler` alongside `monitorScheduler` in the runtime snapshot.
## Technical Decisions
| Decision | Rationale |
@@ -111,6 +117,8 @@
| Only enforce active auth preflight for monitor tasks on `yuanbao`, `kimi`, and `deepseek` | The user explicitly allowed anonymous execution for the other AI monitoring platforms |
| Gate tracking `collect-now` on the current actor's online desktop client, not any workspace client | The user explicitly wants the action tied to the current logged-in account's client presence |
| Expose current-user desktop-client availability through the monitoring dashboard response | `TrackingView` already loads the dashboard, so returning the runtime bit there avoids a second frontend probe and keeps button gating aligned with backend validation |
| Implement publish priority through runtime admission control, not just queue sort order | Already-running monitor tasks cannot be moved by queue priority; publish needs reserved execution capacity to avoid starvation |
| Keep monitor hard preemption out of the first publish-priority slice | Soft priority with reserved capacity avoids browser half-submit and lease/result inconsistency while still preventing monitor saturation |
## Issues Encountered
| Issue | Resolution |