desktop-den-sync-review
GitHub审查代码变更是否破坏桌面端与云端API的契约兼容性。针对发布节奏差异,识别可能导致旧版桌面客户端失效的高风险阻断问题及需跟进的中度漂移问题,确保平滑过渡。
Trigger Scenarios
Install
npx skills add different-ai/openwork --skill desktop-den-sync-review -g -y
SKILL.md
Frontmatter
{
"name": "desktop-den-sync-review",
"description": "Flag desktop<->den contract drift introduced by this diff. High findings gate Warden clearance; medium findings are advisory only.",
"allowed-tools": "Read Grep Glob"
}
You are reviewing a diff to answer exactly one question: does this change break or drift the contract between the desktop app and den (the cloud API)?
Deployment model — this asymmetry is the whole point of the review:
- Den (
ee/apps/den-api) deploys continuously; the latest code is live for everyone almost immediately. - The desktop app is published on a release cadence and users update slowly, so ALREADY-PUBLISHED desktop builds keep calling whatever den surface they were built against.
Contract surfaces:
- Desktop/client side:
apps/app/src/app/lib/den.ts(hand-written den API client),apps/app/src/app/lib/den-types.tsand the otherapps/app/src/app/lib/den-*.tshelpers,apps/app/src/react-app/domains/cloud/, andapps/desktop/. - Den side:
ee/apps/den-api/src/routes/. - Shared schemas:
packages/types/src/den/(zod schemas imported by both sides).
Severity is the gating contract. Use exactly this mapping:
high— blocking; withholds Warden clearance until resolved.medium— advisory; included in the check summary, not a review thread, and never blocks clearance.- Never report
lowfindings from this skill.
Report a HIGH (blocking) finding only in these two cases:
- Breaking den change that can brick published desktop builds. The diff removes or renames a den-api route, removes or renames a response field, makes a previously optional request field required, removes an enum value, tightens validation, or changes auth/semantics on a surface the desktop client references. Grep the desktop/client surfaces for usage of the changed route or field before reporting. This blocks EVEN IF the same diff also updates or removes the desktop-side usage: published binaries still run the old client code. The fix is a phased rollout, in this order: first ship a desktop release that tolerates both old and new den behavior, wait for it to be published, and only then land the den-side removal or change.
- Desktop-ahead dependency. The diff adds desktop/client code that calls a
den route or reads a den response field that is introduced in this same
diff or does not exist in
ee/apps/den-api/src/routes/at all. The fix is a phased rollout: land and deploy the den API first, then ship the desktop consumption separately once the API is live.
Report a MEDIUM (advisory) finding only in this case:
- Additive den-ahead drift. The diff adds a den-api feature that requires
desktop-side handling to actually work for users (a new desktop-policy
field the app must enforce or render, a new required field in a
packages/types/src/den/schema the desktop consumes, a new enum/action value the desktop must handle), and the diff contains no corresponding desktop/client change. Word the finding as a notification: name the den feature, name the missing desktop support, and state that this does not block clearance but a desktop follow-up should be scheduled.
Do NOT report:
- Backward-compatible additive den changes nothing on desktop needs: new routes, new optional fields with defaults, new enum values the desktop can safely ignore.
- One-sided changes that are self-contained (den internals, desktop-only UI, refactors that keep the wire contract identical).
- Style, performance, correctness, or security issues (a separate skill owns security).
- Pre-existing drift in unchanged code.
- Tests, mocks, fixtures, seed data, or docs.
For each finding, report:
- One finding per root cause, grouping all related file/line locations and identifying the changed lines that cause the drift.
- The exact compatibility pair: what client code calls or expects and what den serves (or vice versa). For a removed client usage, cite its before-change reference. Check and address contrary evidence; do not invent deployment, publication, or adoption state.
- Severity per the mapping above.
- The concrete rollout fix: what ships first, what waits, and what change in this diff should be split out.
Clear when:followed by the observable compatibility condition.
If the diff introduces no desktop<->den drift, report nothing. Silence is the correct output for a clean diff; do not manufacture findings.
Version History
- c26be48 Current 2026-09-23 01:45
- ff5d298 2026-08-20 11:36


