CtrlK
BlogDocsLog inGet started
Tessl Logo

desktop-den-sync-review

Flag desktop<->den contract drift introduced by this diff. High findings gate Warden clearance; medium findings are advisory only.

64

Quality

76%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.warden/skills/desktop-den-sync-review/SKILL.md
SKILL.md
Quality
Evals
Security

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.ts and the other apps/app/src/app/lib/den-*.ts helpers, apps/app/src/react-app/domains/cloud/, and apps/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 low findings from this skill.

Report a HIGH (blocking) finding only in these two cases:

  1. 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.
  2. 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:

  1. 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.

Repository
different-ai/openwork
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.