Conversation
|
rfc 内容总结： 功能点包括：
可能需要讨论确定的事项：
|
PsiACE
left a comment
PsiACE
left a comment
There was a problem hiding this comment.
Please keep the RFC focused on the user model and architectural contracts, following the existing RFC example.
| P2 expansion. Include empty/multi-page, model-free/configured cases. D7 owns the published budget; there is no current | ||
| performance claim. Transport/notification operating caps do not replace measurements. | ||
|
|
||
| ## 17. Delivery phases |
There was a problem hiding this comment.
Please follow the structure in our existing RFC example, especially the Guide-level and Reference-level explanations. Explain the user model through examples, then define the architecture and contracts supporting those examples.
RFC
+-- Guide: connect -> choose Scope -> manage context
`-- Reference: UI -> typed IPC -> Rust -> public API -> Server
#1428 / delivery plan
`-- Implementation phases, task owners, acceptance matrix and evidence
Keep observable guarantees in the RFC, such as the Server continuing to run after the desktop closes. Move the full implementation and acceptance plan out so it can evolve independently.
There was a problem hiding this comment.
Thank you for the guidance. Updated in d2734e3, with both language versions following the RFC template.
The Guide-level section now walks through connecting, choosing a Scope, managing context, reviewing a proposal, interpreting incomplete notification scans, and switching/recovering connections. The Reference-level section connects those examples to the UI → typed IPC → Rust → public API → Server boundary and its contracts.
The implementation phases, owner assignments, acceptance matrix and qualification evidence now live in a separate delivery plan, linked from the RFC and tracked under #1428. Observable guarantees, including the Server continuing after the desktop exits, remain in the RFC.
I would appreciate another look when convenient.
| Initial Review limits: one request at a time, at most 100 Candidates/page, five page requests/minute, 60-second polling | ||
| with up to 20% jitter. Continue bounded paging without treating its cursor as an event cursor. Discard a traversal that | ||
| cannot finish within five minutes, refresh and report partial coverage. Complete global counts/history need another | ||
| Server contract; this background limit does not prevent explicit paged Review navigation. |
There was a problem hiding this comment.
Please avoid committing to implementation details too early. Define the required behavior and tradeoffs first, then establish tuning values through implementation and measurement.
RFC: bounded polling, accurate counts, private notifications
Implementation: polling interval, page size, jitter, retention settings
Validation: behavior tests, regression tests, measurements
For example, explain how incomplete scans affect displayed counts without fixing a 60-second interval or 20% jitter yet. Keep a specific value in the RFC only when it is essential to the contract.
There was a problem hiding this comment.
Thank you; agreed that the RFC should establish behavior and tradeoffs before tuning values. Addressed in d2734e3 in both languages.
Removed the fixed polling interval, jitter, request rate, scan expiry, backoff and notification retention/capacity values. The delivery plan now records the implementation measurements needed to select them. The RFC retains bounded work, truthful coverage/counts, deduplication and private notifications.
The incomplete-scan example explicitly labels counts as observed and never treats unread pages as zero. It also explains that finishing a traversal does not establish an exact current total without a Server snapshot/count contract. The existing API limit of 100 Candidates per page remains documented as a Server constraint, not a chosen desktop page size.
The four documents pass MDX/GFM compilation and targeted documentation checks. The PR description records the existing Windows type-check and site-wide link-validation limitations separately.
2 participants
Which issue or RFC does this PR close?
Refs #1428. This design proposal and delivery plan do not close the issue; closure requires the complete installed-product journey on one qualified platform.
Rationale for this change
PowerContext needs a desktop control center for connections, local setup, context assets, Review and supported Handoff workflows. The desktop must use public Server contracts while keeping the Python Server independent of the desktop lifecycle.
The proposal uses Tauri 2, a bundled React + TypeScript client built by Vite, and a constrained Rust host. It shares suitable presentation resources with the personal Dashboard and keeps a separate client management entry. Source facts are pinned to upstream
62e4c821709c18b832c77363fdd428765bee6a96; release compatibility requires separate qualification.What changes are included in this PR?
Are there any user-facing changes?
The product changes are documentation only; runtime behavior, OpenAPI, dependencies and persisted formats are unchanged. CI installation and failure diagnostics also receive the scoped changes described above. The proposed first target is Windows 11 x64 with SQLite. A clearly limited connect-only preview may precede managed installation and durable delivery. Proposed producer interfaces are identified as dependencies, not existing capabilities.
How was this change tested?
All 21 PR checks passed on
f890f13115d16dd12972d215b271dd6d702b201a, including native services, the Python matrix, quality and website checks, and SQLite/OceanBase acceptance. The macOS job compiled 8,794 files during installation and completed its lifecycle suite with 5 passed and the existing Windows-only case skipped, without changing the service startup deadline.Passed locally:
pnpm --dir website install --frozen-lockfileandpnpm --dir website lint.SKIP=ty-check uv run --locked --no-sync prek run -a.git diff --checkandgit diff --cached --check.pytest -q tests/test_native_service_diagnostics.py tests/test_workflow_actions.py: 12 passed; changed workflow and tests also pass YAML, Ruff and whitespace hooks.Local full-check limitations on Windows, not counted as passes:
uv run --locked prek run -a: the type hook reports seven existing diagnostics in processing workers/tests (ConnectionversusPipeConnection, and POSIX-onlyos.WNOHANG). No runtime files are changed by this PR.pnpm --dir website build: generation completes, but the site-wide link validator fails across existing pages on this Windows checkout. Local link targets in the four affected documents were independently verified; the full website build is not claimed as passing.AI usage statement
OpenAI Codex assisted with repository and review research, RFC design, English/Chinese documentation, validation and PR preparation.