feat(desktop): add Webhooks page for subscription CRUD

[austinpickett]

Brings the desktop GUI to parity with the dashboard's Webhooks page.

Adds a /webhooks route that lists webhook subscriptions, enables the webhook gateway platform, and creates/toggles/deletes subscriptions, hitting the same /api/webhooks* endpoints the dashboard and CLI use.

Changes

• types/hermes.ts: WebhookRoute, WebhooksResponse, WebhookCreatePayload, WebhookCreateResponse, WebhookEnableResponse
• hermes.ts: getWebhooks, enableWebhooks, createWebhook, deleteWebhook, setWebhookEnabled (profile-scoped) + type re-exports
• app/webhooks/index.tsx: WebhooksView (enable card, restart banner, subscription list with copy/toggle/delete, create dialog with one-time secret reveal); optimistic toggle, profile re-home
• routing: routes.ts, contrib/surfaces.tsx, chat/route-tile.tsx
• nav: command palette, keybind nav.webhooks, sidebar row
• i18n: en + zh full, types interface; ja/zh-hant fall back to English
• test: webhooks-rest.test.ts covers the REST helper contracts

Verification

• typecheck: clean
• lint: clean on touched files
• webhooks-rest.test.ts: 5/5 pass

[alt-glitch]

This was generated by AI during triage.

Related competing work: #42817 adds a skill-oriented endpoint view, while this PR adds profile-scoped general subscription CRUD plus gateway enable/restart handling. Both occupy the Desktop Webhooks surface; maintainer decision is needed on the UI contract or consolidation.

[github-actions]

૮ >ﻌ< ა ci review

_{ran on 73509e7}

all good!

[austinpickett]

Re: overlap with #42817.

Both PRs target the same Desktop Webhooks surface (app/webhooks/index.tsx, /api/webhooks, same route). I've folded #42817's skill-endpoint case into this PR so it's now a superset:

This PR now covers:

• subscription CRUD (create/list/enable-disable/delete), copy URL + one-time secret
• skills field in the create form + skill badges on rows (the feat(desktop): add skill API endpoints view #42817 case)
• gateway platform enable + restart handling
• profile-scoped REST calls
• deliver / deliver_only options
• status bar entry point
• full i18n (en, zh) + webhooks-rest.test.ts

#42817 is narrower: no gateway enable/restart, no profile scoping, no deliver options, no tests/i18n, and it hangs off the sidebar nav.

Recommend consolidating onto this PR and closing #42817 with credit to @LionGateOS for the skill-endpoint framing, which is now included here. Happy to adjust the UI contract (sidebar vs status bar, skill-first vs general CRUD framing) if you'd prefer a different split.

[alt-glitch]

This was generated by AI during triage.

Re-triage correction: the current patch includes #42817's skill-endpoint flow alongside broader profile-scoped subscription CRUD, gateway enablement, delivery options, and coverage. It is a broader related successor, so the stale needs-decision framing is removed.

[OutThisLife]

Approve. Verified against the backend: every REST call maps to a real route in hermes_cli/web_server.py (GET/POST /api/webhooks, POST /api/webhooks/enable, DELETE /api/webhooks/{name}, PUT /api/webhooks/{name}/enabled) and the desktop TS types match the response shapes field-for-field. Real parity gap with the dashboard's WebhooksPage.tsx, cleanly scoped to apps/desktop, profile-scoped calls, enable→restart handling, one-time secret reveal, en/zh i18n + REST-contract test. Nicely supersedes the now-closed #42817 with credit.

Advances #67144.

Optional, non-blocking follow-ups: deliver_chat_id is typed/backend-accepted but never collected in the form; DELIVER_OPTIONS is a static list while the cron-blueprints PR derives targets from configured gateways; the delete success toast shows the bare name with no verb.

[OutThisLife]

Code's approved — but before this lands, can you make the UI match the rest of the app? Right now each of these pages has its own design for the items, and we already have that pattern set elsewhere. As it stands the cron Jobs tab, the cron Blueprints tab, and this Webhooks page each render list items three different ways. Please align this page with the existing overlay idiom.

Concrete deltas I found where this reinvents primitives instead of reusing them:

• Item rows. WebhookRow is a hand-rolled <li className="... rounded-md border border-border p-4"> block card. The Panel system is explicitly borderless (app/overlays/panel.tsx: "NO container borders — rows separate via row-hover/active bg + gaps"). Use the established item idiom: either PanelBody + PanelList/PanelListRow + PanelDetail (see app/profiles/index.tsx and the sibling cron Jobs tab), or the messaging idiom MasterDetail + ListColumn/DetailColumn + ListRow (app/messaging/index.tsx) — messaging is the closest analog since it's also a list of platforms with enable/disable + status.

• Copy button. There's a shared CopyButton (components/ui/copy-button.tsx, appearance=\"icon\"). The inline one here calls navigator.clipboard.writeText directly and swallows failures with .catch(() => {}) — that bypasses writeClipboardText, which prefers the Electron bridge window.hermesDesktop.writeClipboard, plus you lose the haptic + error state. This one's a real desktop behavior delta, not just style.

• Banners. The enable/restart callouts hand-roll a one-off amber palette (border-amber-500/40 bg-amber-500/5). Use Alert + AlertTitle/AlertDescription variant=\"warning\" (components/ui/alert.tsx) or messaging's ErrorBanner (components/ui/error-state.tsx) — those use the primary/destructive color-mix tokens instead of raw amber.

• Chips. Uses Badge here; the panel idiom (and your own Blueprints PR) uses PanelPill with tones (good/muted/warn/bad). Pick PanelPill for consistency on a Panel page.

• Toggle + form controls. The per-row Enable/Disable is a text ghost Button; messaging uses the Switch primitive for exactly this. The create dialog uses a raw <input type=\"checkbox\"> (use Checkbox, components/ui/checkbox.tsx) and a bespoke Field wrapper that duplicates the settings field primitives (ListRow in app/settings/primitives.tsx).

• Data fetch (minor). Manual useState/useEffect load here vs. useQuery in the Blueprints PR and elsewhere — worth aligning on the query layer.

Nothing wrong with the logic — it's the presentation layer picking its own primitives. Reusing the existing ones will also shrink this file a lot.

[OutThisLife]

Logic's good, but requesting changes on the UI layer — please align this page with the app's existing item idiom and primitives before it lands. Details in my comment above: the hand-rolled bordered item cards, the inline copy button (bypasses the Electron clipboard bridge + swallows errors), the one-off amber banners, Badge vs PanelPill, the text-button toggle vs Switch, and the raw checkbox/Field vs Checkbox/ListRow.

[OutThisLife]

Re-reviewed — this addresses everything. The page now speaks the app's overlay language: Panel + PanelBody/PanelList/PanelListRow + PanelDetail/PanelMeta master-detail, PanelPill chips, Alert variant="warning" banners, the shared CopyButton, Switch + PanelRowMenu for enable/disable, ListRow/ToggleRow for the create form, and the fetch moved onto react-query with an optimistic cache paint + invalidate. Item chrome now matches profiles / the cron Jobs tab. CI green. Nice cleanup.

Non-blocking: the one-time secret box still carries a raw amber-500 highlight — fine as a deliberate "copy this once" cue, just the last bit of one-off palette if you want full token purity later.

[OutThisLife]

Looked at this running with seeded subscriptions — the overlay's on the right primitives now (master/detail PanelList/PanelDetail, PanelPill, Alert, Switch, CopyButton, ListRow). Two small things before it lands:

1. Delete copy — drop the em-dash, match the cron convention. deleteDescription reads "${name}" — this will permanently remove this webhook subscription. The cron page (app/cron/index.tsx) already sets the house style for this exact dialog: a deleteDescPrefix + a bolded name <span className="font-medium text-foreground"> + a deleteDescSuffix, no em-dash and no wrapping quotes. Please mirror that phrasing/markup so the two delete dialogs read the same.

2. Redundant delete affordance in the detail header. The detail header has a Switch plus a bare Trash2 icon button, but delete already lives in the row's PanelRowMenu kebab (alongside enable/disable). Two delete entry points and a naked trash glyph isn't a pattern the app uses — profiles/cron detail panes expose actions via the kebab or PanelAction ghost buttons, not a lone icon. Keep the toggle as the Switch, and drop the header trash icon (delete stays in the kebab), or move it into a PanelAction if you want it in the detail.

Everything else looks good.

[OutThisLife]

Fuller pass on apps/desktop/src/app/webhooks/index.tsx against the cron page's conventions and apps/desktop/DESIGN.md. The overlay's on the right primitives now (PanelList/PanelDetail/PanelMeta/PanelPill/PanelBlock, Alert, Switch, CopyButton), and the detail <h3> matches CronJobDetail. Remaining deltas:

1. Delete copy — drop the em-dash. deleteDescription(name) = "${name}" — this will permanently remove.... The cron delete dialog sets the house style: deleteDescPrefix + a bolded name <span className="font-medium text-foreground"> + deleteDescSuffix, no em-dash, no wrapping quotes. Mirror it.

2. Bare Trash2 icon in the detail header. Delete already lives in the row PanelRowMenu kebab, and the canonical detail-header action is PanelAction (ghost, icon + label — see CronJobDetail's pause/resume/trigger). A lone trash glyph isn't a pattern used anywhere. Either drop it (keep delete in the kebab) or make it a PanelAction icon="trash" with a label. DESIGN.md Principle 5: the button re-specifies chrome via className (text-muted-foreground hover:bg-(--ui-row-hover-background) hover:text-destructive) instead of going through a variant.

3. The detail Switch also restates the kebab's enable/disable. So the detail header duplicates both row-menu actions. CronJobDetail never restates its kebab; it exposes distinct actions. Pick one home for enable/delete rather than kebab + Switch + trash all overlapping.

4. Three copyable-value box styles in one file. Detail URL row is rounded bg-foreground/5 px-2.5 py-1.5; the create-result URL box is rounded-md border border-border bg-background/40 px-3 py-2; the secret box is amber. DESIGN.md opens with "one source per concern, tokens over literals, flat over boxed... there's already a primitive for it," and Principle 4: "Reference CSS vars (--ui-*), never raw hex / ad-hoc rgba." Those are three chromes + raw literals (bg-background/40, border-amber-500/40, bg-foreground/5) for the same "value + CopyButton" affordance. Settle on one.

5. Delete success toast is just the raw name. notify({ kind: 'success', message: \${pendingDelete}` })— no title/verb. Cron doesnotify({ kind: 'success', title: c.deleted, message: ... }). Add a w.deleted` title so it reads like every other delete toast.

6. (Lower priority) Delete confirm hand-rolls a Dialog. There's a shared ConfirmDialog (components/ui/confirm-dialog.tsx) that owns Enter-to-confirm, pending->done state, and inline error; the webhook dialog reimplements a subset. Cron hand-rolls too, so this is optional — but ConfirmDialog exists for exactly this.

Everything else looks good.

Superseded by the consolidated review below.

[OutThisLife]

Re-reviewed at 73509e7 with the same magnifying glass — all points addressed:

• Detail pane is read-only: the bare Trash2 icon and the duplicate Switch are gone; enable/disable/delete live only in the row PanelRowMenu.
• The three copyable-value chromes are unified into one flat, token-backed CopyValueRow (reused by the detail URL and the create-result URL/secret) — no more raw bg-background/40 / amber literals.
• Delete now uses the shared ConfirmDialog with deleteDescPrefix + bold name + deleteDescSuffix (no em-dash, no wrapping quotes), and the delete toast carries a w.deleted title like the cron idiom.

Two optional, non-blocking nits for whenever: the create dialog pairs fields with grid-cols-2 where the cron editor uses sm:grid-cols-2 (collapses on a narrow window), and the one-time secret lost its amber emphasis — fine by DESIGN.md flatness, just flagging in case you want a token-based "copy once" cue.

LGTM.