feat(workflows): Templates gallery + PR code-review automation

[xBalbinus]

Templates gallery + PR code-review automation

A Zapier-style Templates gallery on top of the dag/v1 workflow interpreter (#43), plus the first template: an automated PR code-review workflow driven by the org's GitHub App. Installing a template creates a real, published, runnable workflow via the canonical create → publish → trigger path — no bespoke execution engine — and the code-review template can be armed on a repo with one click, no manual webhook setup.

What's included

• Templates gallery — plugin-owned templates (each plugin ships the templates for the actions it owns); a source-agnostic install service that mirrors the HTTP create/publish path. GET /api/templates filters by the org_plugins switch, so disabling a plugin removes its templates.
• Code-review automation — a github-app trigger type: one App delivery fans out to every matching repo trigger. Claude reviews the PR diff on three axes — intent vs. changeset, conventions, correctness — and posts a single review comment, leading with an intent check.
• Org + user settings — org codeReviewEnabled / enforced / mentionOnly plus per-owner prefs, precedence modeled on the action-policy system (admin GitHub settings + Settings → Agent).
• Install prompt — arming an uncovered repo prompts to install the Valet GitHub App; credential:'app' posts as the org bot, never as a person.

How it works

/webhooks/github receives App deliveries; dispatchGithubAppReviews reads the org policy once (an org OFF is absolute), then per armed trigger evaluates resolveCodeReviewGate(org, owner, reason). Precedence is an org ceiling — the owner may only loosen, never tighten past the org or override an org OFF (the same shape as resolveEffectiveActionPolicy). decideReview applies a Greptile-style policy: skip drafts/pushes, review on open/reopen/ready, re-review only on an @<bot> mention. Dispatch is best-effort — one trigger failure never blocks the webhook 200.

The review posts under the App-installation (bot) token: credential:'app' resolves the bot token only and fails with an actionable "install the App" message if it's unavailable — it does not silently fall back to the caller's personal token. github.inspect_pull_request gains an opt-in includePatch (backward-compatible) so the reviewer sees the actual diff.

Two run paths: an armed App trigger (automatic, every PR) and manual "Run now" with { owner, repo, pullNumber } via the gate's isEmpty arm. A manual per-repo webhook remains as a demoted fallback.

Testing

Full local end-to-end: install via API and gallery UI, then both trigger paths through all nodes to a real generated review (which correctly caught injected bugs). Unit/integration coverage for the credential resolver (app vs. default), the code-review gate matrix, dispatch-level no-dispatch paths (draft/push, generic @valet, wrong repo, disabled trigger, org gates), and template install (structural validity, publish, trigger creation, repeat-install collision). tsc clean across worker/shared/client; worker 1250, client 174 vitest green.

Follow-ups

• Non-policy per-template tunables (review prompt, model) deferred — currently template-fixed; they don't map onto the policy resolver, so they'd be plain settings.
• Rolling the code-review gate into the action_policies framework proper (org rows + user allow-rows) is a natural next step — the settings were shaped to migrate cleanly.
• Real GitHub App install is required for post-as-bot; up to that step the mechanism is verified end-to-end.

[github-actions]

Preview deployment: https://pr-75.dev-valet-turnkey-client.pages.dev

[xBalbinus]

Solid draft overall — architecture is coherent and the intent is delivered. A few issues worth addressing before merge.

Intent check: The diff delivers everything described: WorkflowTemplate types in the SDK/shared, the GitHub code-review template, install service with rollback, two new API routes, and the gallery UI with search/filter/setup dialog. The double-prefix bug fix in trace cards, canvas subtitles, and approval prompts is a genuine pre-existing problem correctly addressed here.

Findings:

• packages/worker/src/routes/templates.ts — unauthenticated install endpoint. GET /api/templates and POST /api/templates/:id/install don't verify c.get('user') before use. If the auth middleware is applied globally this is fine, but the install handler dereferences user.id without a guard. Compare to how other routes in routes/workflows.ts handle this — add an explicit 401 check or confirm middleware is unconditional.

• packages/worker/src/routes/templates.ts — webhook URL construction is fragile. c.req.url.startsWith('https') matches the full request URL (e.g. https://example.com/api/templates/code-review/install), so this works, but it also matches any URL whose path happens to start with https (contrived but worth noting). More importantly, if the worker is behind a proxy sending X-Forwarded-Proto, the req.url may still be http://. Consider reading X-Forwarded-Proto or using a configured BASE_URL env var, consistent with how other routes construct external URLs.

• packages/plugin-github/src/actions/templates.ts — apps array repeats 'github' with 'claude' in the middle, but AppGlyph in the client only checks for service === 'claude' || service === 'anthropic'. If a future template uses openai or another LLM brand token, getServiceIcon('openai') will be called — verify getServiceIcon handles unknown service ids gracefully (returns a fallback) or document the supported token set.

• packages/worker/src/services/workflow-templates.ts — templateRunInputs silently drops fields whose type is not 'string' or 'number' (e.g. boolean, array). The code-review template only uses those two types, so it's fine for now, but the filter with no warning makes it easy to ship a template whose fields quietly vanish from the UI. At minimum, add a comment; ideally log a warning in dev.

• packages/client/src/routes/automation/templates/index.tsx — dialog state is not reset on close. installedWorkflowId, webhook, and values are all in TemplateSetupDialog state, but they survive if the user dismisses the dialog and reopens it for the same template (since TemplateCard mounts the dialog inside the same component instance). The second open will show the "Run now" form for an already-installed workflow. Add a React.useEffect that resets state when open goes false, or lift/clear state on close.

• packages/shared/src/types/workflow-templates.ts — WorkflowTemplateSummary.inputs is always present (never optional), but TemplateSetupDialog guards template.inputs.length > 0 before rendering the "Run now" section — that's fine. However, WorkflowTemplateInput.required is boolean | undefined; the client's missingRequired check (i.required && ...) correctly treats undefined as falsy, but it would be cleaner to normalise this to boolean in templateRunInputs.

[xBalbinus]

Solid PR overall — the architecture is clean, the atomicity story for install is well-handled, and the test coverage is meaningfully hermetic. A few real issues worth acting on:

• Webhook URL construction is wrong in routes/templates.ts: c.req.url.startsWith('https') matches the full URL string (e.g. https://...), so http requests will never be detected — this always resolves to https in production (fine) but silently breaks in local dev. Use new URL(c.req.url).protocol instead, or inherit c.req.url directly for the origin. (packages/worker/src/routes/templates.ts, ~line 84)

• issue_comment dispatch fires for all repos, not just repos with a matching trigger: dispatchGithubAppReviews looks up findGithubAppTriggersForRepo(env.DB, owner, repo) where owner/repo come from payload.repository. For issue_comment events, payload.repository is present in GitHub webhook deliveries, so this is actually fine — but decideReview extracts owner/repo from repository and returns them, while dispatchGithubAppReviews re-extracts them from decision rather than from the payload. Verify these are always consistent; if a future event type sets them differently the dispatch could silently mis-route. Minor, but worth a comment. (packages/worker/src/services/webhooks.ts)

• GithubAppInstallSection checks alreadyInstalled against triggersData which may be stale: after handleEnable succeeds, justInstalled correctly flips the UI, but if the user closes and reopens the dialog (resetting justInstalled to false), the stale triggersData cache (not yet invalidated — useEnableTemplateApp.onSuccess invalidates triggerKeys.lists() but the component reads from the already-cached query) can make the "Enable" button reappear. useEnableTemplateApp should also invalidate or the component should keep justInstalled across the reset. (packages/client/src/routes/automation/templates/index.tsx ~line 226, and packages/client/src/api/templates.ts useEnableTemplateApp.onSuccess)

• Silent fullName split on / is brittle: e.target.value.split('/') assumes repo names contain no slashes; GitHub org/repo names never do, but a comment would make this contract explicit. More importantly, if fullName is somehow missing a / (e.g. a bare org name leaks into the list), r is undefined and you silently set repo: ''. A ?? '' guard is already there but the invariant should be asserted or the option filtered. (packages/client/src/routes/automation/templates/index.tsx ~line 297)