@rudderhq/server 0.7.2 → 0.7.3

package/resources/bundled-skills/rudder-docs/evals/retrieval-authority-evals.json

@@ -258,5 +258,45 @@
     "expected_public_path": "https://docs.rudderhq.dev/zh/reference/permissions-and-platforms",
     "expected_anchor": "boundaries",
     "illustrative_case_sufficient": false
+  },
+  {
+    "query": "How does Rudder build, review, approve, and sign Windows Desktop releases?",
+    "locale": "en",
+    "query_mode": "current",
+    "expected_source_class": "official_public_docs_primary",
+    "required_contract_ids": [],
+    "expected_public_path": "https://docs.rudderhq.dev/reference/code-signing-policy",
+    "expected_anchor": null,
+    "illustrative_case_sufficient": false
+  },
+  {
+    "query": "Rudder 如何构建、审查、批准并签名 Windows Desktop 发布产物？",
+    "locale": "zh",
+    "query_mode": "current",
+    "expected_source_class": "official_public_docs_primary",
+    "required_contract_ids": [],
+    "expected_public_path": "https://docs.rudderhq.dev/zh/reference/code-signing-policy",
+    "expected_anchor": null,
+    "illustrative_case_sufficient": false
+  },
+  {
+    "query": "Which Rudder data stays local and which optional services process data?",
+    "locale": "en",
+    "query_mode": "current",
+    "expected_source_class": "official_public_docs_primary",
+    "required_contract_ids": ["ANALYTICS.TELEMETRY.001"],
+    "expected_public_path": "https://docs.rudderhq.dev/reference/privacy",
+    "expected_anchor": null,
+    "illustrative_case_sufficient": false
+  },
+  {
+    "query": "哪些 Rudder 数据保留在本地，哪些可选服务会处理数据？",
+    "locale": "zh",
+    "query_mode": "current",
+    "expected_source_class": "official_public_docs_primary",
+    "required_contract_ids": ["ANALYTICS.TELEMETRY.001"],
+    "expected_public_path": "https://docs.rudderhq.dev/zh/reference/privacy",
+    "expected_anchor": null,
+    "illustrative_case_sufficient": false
   }
 ]

package/resources/bundled-skills/rudder-docs/evals/trigger-evals.json

@@ -20,11 +20,11 @@
     "should_trigger": true
   },
   {
-    "query": "Scaffold a new Rudder Plugin named @acme/quality-gate in a temporary external package directory. Verify the current create-rudder-plugin and SDK workflow first, then run its typecheck, tests, and build.",
+    "query": "Create a Codex-compatible Rudder Plugin named quality-gate in a temporary directory with one Skill. Verify plugin.json and the current import boundary, then test the package.",
     "should_trigger": true
   },
   {
-    "query": "Rudder Plugin 的 worker capability、same-origin UI、routePath 和 ctx.assets 现在到底有哪些边界？请查当前 authoring guide、SDK 和源码后回答。",
+    "query": "Rudder Plugin 的 Codex package、Skills、MCP、App、导入检查和运行权限现在有哪些边界？请查当前 authoring guide 和源码后回答。",
     "should_trigger": true
   },
   {

package/resources/bundled-skills/rudder-docs/references/api-reference.md

@@ -246,8 +246,6 @@ or editing that URL by hand.
 
 - `GET /api/approvals/:approvalId`
 - `GET /api/approvals/:approvalId/issues`
-- `GET /api/approvals/:approvalId/comments`
-- `POST /api/approvals/:approvalId/comments`
 - `POST /api/approvals/:approvalId/request-revision`
 - `POST /api/approvals/:approvalId/resubmit`
 - `POST /api/approvals/:approvalId/approve`

package/resources/bundled-skills/rudder-docs/references/plugin-authoring.md

@@ -1,116 +1,40 @@
 # Plugin Authoring
 
-Use this workflow for a Rudder Plugin source question or an explicit request to
-scaffold, develop, or verify a Plugin. Reading authoring guidance is read-only.
-Only an explicit user request to scaffold or modify a package authorizes writes,
-and those writes must stay inside the requested repository or target directory.
-
-The current fact sources are
-`doc/engineering/PLUGIN_AUTHORING_GUIDE.md` and
-`packages/plugins/sdk/README.md`. Use
-`doc/engineering/PLUGIN_RUNTIME_CONTRACT.md` only to understand the implemented
-runtime boundary, and label future ideas as non-current.
-
-## Section Map
-
-- [Confirm scope and package layout](#confirm-scope-and-package-layout)
-- [Scaffold from the current package](#scaffold-from-the-current-package)
-- [Implement within current boundaries](#implement-within-current-boundaries)
-- [Wire a bundled example only when requested](#wire-a-bundled-example-only-when-requested)
-- [Verify the package and host](#verify-the-package-and-host)
-
-## Confirm Scope And Package Layout
-
-Before writing, determine whether the Plugin is:
-
-- a repository-local example under `packages/plugins/examples/`;
-- another Rudder monorepo package under `packages/plugins/`; or
-- an external npm package in an absolute target directory.
-
-Repository-local examples are a development workflow. For deployable Plugins,
-prefer an npm package installed from a public or private npm-compatible
-registry. GitHub installs are not a first-class path today.
-
-Treat both Plugin workers and Plugin UI as trusted code. Plugin UI runs as
-same-origin JavaScript and is not sandboxed by manifest capabilities.
-Worker-side host APIs are capability-gated. Keep these boundaries visible when
-reviewing third-party code or selecting capabilities.
-
-## Scaffold From The Current Package
-
-Use `create-rudder-plugin` instead of hand-writing boilerplate. In a Rudder
-checkout, first build the scaffold package, then run its generated CLI for the
-requested npm package name and output root. `--output` names the parent
-directory; the CLI appends the package basename, and that destination must not
-already exist. Verify the exact commands in
-the current authoring guide before execution.
-
-For a repository-local package, the scaffold uses `workspace:*` for
-`@rudderhq/plugin-sdk`. For an external package, pass `--sdk-path` pointing to
-the checkout's `packages/plugins/sdk`; the scaffold snapshots the SDK/shared
-packages into `.rudder-sdk/` so the Plugin can build and test before an npm
-publication exists.
-
-The generated package should include:
-
-- `src/manifest.ts`;
-- `src/worker.ts`;
-- `src/ui/index.tsx` when UI is used;
-- `tests/plugin.spec.ts`;
-- `package.json` and current build configuration.
-
-Scaffold only under the explicit output root and confirm the derived package
-directory before execution. Do not install the generated Plugin into a running
-Rudder instance unless the user also requested that host mutation.
-
-## Implement Within Current Boundaries
-
-Review the manifest, worker, UI, and tests together:
-
-- Declare only capabilities used by the worker-side host APIs.
-- Keep tool names Plugin-namespaced; they must not shadow core or other Plugin
-  tools.
-- Keep UI self-contained. Rudder does not provide a shared Plugin React
-  component kit yet.
-- Do not use `ctx.assets`; it is not supported in the current runtime.
-- Use `routePath` only for a `page` slot. It must be one lowercase slug and may
-  not collide with a reserved host route or another installed Plugin page.
-- Use the SDK's declared worker, UI, testing, bundler, and dev-server surfaces
-  rather than undocumented application internals.
-- Treat jobs and webhooks as namespaced external execution surfaces and keep
-  their capabilities, ownership, logs, and failure evidence explicit.
-
-Local development installs must use an absolute filesystem path. The server
-can watch a local-path Plugin and restart its worker after rebuilds, but that
-does not make a repo-local checkout a production deployment artifact.
-
-## Wire A Bundled Example Only When Requested
-
-Only if the user explicitly asks for bundled example or discoverable host
-wiring, update the host's bundled-example list and the documentation that
-enumerates in-repo examples. A request to scaffold or develop a Plugin alone
-does not authorize changing `server/src/routes/plugins.ts` or other host
-registration surfaces.
-
-If host runtime, SDK, capability validation, static UI serving, or lifecycle
-code changes, follow the repository's Plugin engineering and Product Logic
-rules in addition to the package workflow.
-
-## Verify The Package And Host
-
-At minimum, run the generated or existing Plugin package's:
-
-- `typecheck`;
-- `test`; and
-- `build`.
-
-Use the package scripts or the monorepo's `pnpm --filter <plugin-package>`
-forms. For a new scaffold, execute them in a temporary or explicitly requested
-target and confirm that its worker, manifest, UI bundle, and
-`tests/plugin.spec.ts` compile against the selected SDK layout.
-
-When host or SDK code changed, also run the relevant host integration tests,
-repository typecheck, test suite, and build. If the user asked to install the
-Plugin, verify the real host from its absolute local path and surface worker
-health, logs, route behavior, and capability failures. Package creation alone
-is not evidence that a Plugin is installed or active in Rudder.
+Use this reference for explicit requests to create, inspect, import, or verify a
+Rudder Plugin. Rudder V1 consumes the Codex Plugin package format and does not
+provide a Plugin worker SDK or extension runtime.
+
+## Before Writing
+
+- Confirm the requested target directory and whether the package needs Skills,
+  MCP definitions, App aliases, or a combination.
+- Read `doc/engineering/PLUGIN_AUTHORING_GUIDE.md` and the current upstream
+  Codex Plugin manifest specification.
+- Keep the required manifest at `.codex-plugin/plugin.json` with a lower-case
+  hyphenated name and strict semantic version.
+- Do not recreate legacy Rudder workers, jobs, webhooks, UI slots, generic
+  state, host tools, or SDK dependencies.
+
+## Component Rules
+
+- Put Skills at the default `skills/<slug>/SKILL.md` location or declare the
+  custom root in the manifest. Keep each Skill's scripts and references inside
+  its root.
+- Declare MCP servers inline or through `.mcp.json`. Use environment references
+  for credentials; never embed tokens, passwords, authorization headers, or API
+  keys in the package.
+- Treat `.app.json` as OpenAI registered App aliases only. It is not a Rudder
+  Local App definition or an MCP endpoint.
+- Hooks, assets, and unknown fields may be preserved but are not executable in
+  Rudder V1.
+
+## Rudder Verification
+
+Import only when the user requested that Organization mutation. Use Plugins >
+Import and review the compatibility report. Verify inspection executes nothing.
+After installation, verify the public workflow relevant to the
+package: Agent Skill assignment, Managed MCP setup, Local App launch,
+disable/re-enable, and non-destructive uninstall.
+
+Package creation is not evidence of installation. Installation is not evidence
+that MCP credentials or Agent access are active. Keep those states explicit.

package/resources/bundled-skills/rudder-docs/references/source-map.md

@@ -48,6 +48,8 @@ Other lookup pages are similarly narrow:
 | Workspace and file placement | `https://docs.rudderhq.dev/reference/workspace-boundaries` | `https://docs.rudderhq.dev/zh/reference/workspace-boundaries` |
 | Automation result destinations | `https://docs.rudderhq.dev/reference/automation-output-routing` | `https://docs.rudderhq.dev/zh/reference/automation-output-routing` |
 | Deployment trust, credentials, Browser, and platform behavior | `https://docs.rudderhq.dev/reference/permissions-and-platforms` | `https://docs.rudderhq.dev/zh/reference/permissions-and-platforms` |
+| Windows Desktop release signing policy | `https://docs.rudderhq.dev/reference/code-signing-policy` | `https://docs.rudderhq.dev/zh/reference/code-signing-policy` |
+| Local data and optional service privacy | `https://docs.rudderhq.dev/reference/privacy` | `https://docs.rudderhq.dev/zh/reference/privacy` |
 
 ## Product Logic Registry
 

package/skills/app-builder/SKILL.md

@@ -28,6 +28,9 @@ loopback attestation, and embedded opening.
      manager, development script, data boundary, and tests before editing.
      Preserve its stack and conventions; never replace it with the maintained
      scaffold merely to make it a Rudder App.
+   When the originating prompt includes `Rudder App handoff`, retain its App ID
+   for the completion protocol below. Do not guess an App ID or use one from a
+   different conversation.
 3. Read [references/scaffold-contract.md](references/scaffold-contract.md)
    before changing the runtime, database foundation, manifest, health endpoint,
    import/export contract, or background-job runner.
@@ -37,27 +40,51 @@ loopback attestation, and embedded opening.
    already has data, imports user data, changes its schema, or needs a real-data
    diagnosis.
 6. Follow [references/design-guidelines.md](references/design-guidelines.md)
-   for visible UI work. Prefer coherent workflow screens over a generic
-   dashboard assembled from decorative cards.
+   for visible UI work. For a new App, also read
+   [references/rudder-ui-preset.md](references/rudder-ui-preset.md) and start
+   from the versioned Rudder UI preset already present in the maintained
+   scaffold. Keep its semantic tokens and source-owned shadcn primitives unless
+   the brief explicitly requires a different product identity. For an existing
+   project, preserve its design system by default; align it to Rudder only when
+   the user asks for that change. Prefer coherent workflow screens over a
+   generic dashboard assembled from decorative cards.
 7. Run migrations against development or snapshot data, then run typecheck,
-   unit tests, build, and relevant app E2E tests.
+   unit tests, build, and relevant app E2E tests. Review the final source and
+   rendered product for correctness, regressions, usability, data safety, and
+   evidence integrity; resolve every blocking finding before handoff.
 8. Prepare the website for its Rudder Apps handoff:
-   - A new managed App created from Apps Home keeps its typed manifest and
-     returns to that App's **Register & preview** action. Do not load the same
-     source again through the manual Local App path.
+   - A new managed App created from Apps Home keeps its typed manifest. After
+     the completion gate passes, report `verified_source_ready` with the
+     originating App ID so Rudder Desktop can verify, start, and open that App
+     automatically. Do not load the same source through the manual Local App
+     path.
    - An independently authored existing project keeps a direct supported
      development script. Add the `package.json` `rudder` readiness or open-path
      fields only when discovery cannot infer them safely, then direct the
      operator to **Apps + > Add local web project** to select the folder and
      review the launch definition.
-   The Agent writes and verifies source; Desktop alone owns runtime approval and
-   process start. Do not invent a public URL, tunnel, cloud deployment, or
+   The Agent writes and verifies source; Desktop alone owns runtime admission
+   and process start. Do not invent a public URL, tunnel, cloud deployment, or
    unreviewed launch command.
 9. Read [references/verification.md](references/verification.md), then verify
    the rendered app with Rudder Browser. Exercise the main workflow plus at
    least one production-shaped edge case and inspect console errors.
 10. Materialize final screenshots and validation evidence in the originating
     Chat or Run. A localhost URL or tool-only screenshot is not durable output.
+11. For an originating managed App handoff, use the injected run context without
+    printing or requesting credentials:
+    - Run `node scripts/report-build-status.mjs building <app-id>` when
+      implementation begins.
+    - Run `node scripts/report-build-status.mjs verified_source_ready <app-id>`
+      only after every Completion Gate item passes. This is the machine-visible
+      signal that authorizes Desktop to verify, start, and open the exact
+      assigned source root.
+    - Run `node scripts/report-build-status.mjs failed <app-id>` when work ends
+      in a terminal failure. Do not emit `verified_source_ready` for a question,
+      partial implementation, canceled run, missing evidence, or blocker.
+    Finish by telling the user the App is opening and that they can continue
+    improving it in this Chat. If the status command fails, report that failure
+    honestly instead of claiming the App opened.
 
 ## Real Data Decision
 
@@ -86,7 +113,8 @@ controls and least-data workflow choices; explain the boundary honestly.
   screenshots, test fixtures, or logs. V1 does not provide a Rudder Secret
   binding UI, so ask the user how the App should obtain any required
   integration credential.
-- Opening Chat, Apps, an App tab, or a saved view must not passively start an app.
+- Opening Chat, Apps Home, or a saved view must not passively start an app. A
+  run-scoped `verified_source_ready` handoff may start and open its managed App.
 - Cloud builds, hosted runtimes, public preview links, custom domains, managed
   cloud databases, and cross-device synchronization are outside this skill.
 
@@ -96,8 +124,10 @@ Do not call the app complete until:
 
 - source and any required manifest or `package.json` Rudder configuration are durable;
 - typecheck, unit tests, and build pass;
+- blocking code and product review findings are resolved;
 - the reviewed readiness path is ready on an attested loopback process;
 - Browser verification covers the primary workflow and a relevant edge case;
+- the versioned Rudder UI preset check passes for a new maintained App;
 - persistence behavior is verified against development or snapshot data;
 - current screenshot evidence is attached to the work;
 - user data was not modified without explicit intent; and

package/skills/app-builder/assets/scaffold/app/globals.css

@@ -1,32 +1,125 @@
 @import "tailwindcss";
 
+@custom-variant dark (&:is(.dark *));
+
 :root {
-  --background: #f8fafc;
-  --foreground: #172033;
-  --card: #ffffff;
-  --card-foreground: #172033;
-  --muted: #eef2f7;
-  --muted-foreground: #64748b;
-  --primary: #2563eb;
-  --primary-foreground: #ffffff;
-  --destructive: #dc2626;
-  --border: #dbe3ee;
-  --ring: #3b82f6;
-  --radius: 0.75rem;
+  color-scheme: light;
+  --background: oklch(0.975 0.008 80);
+  --foreground: oklch(0.22 0.012 75);
+  --card: oklch(0.992 0.004 80);
+  --card-foreground: oklch(0.22 0.012 75);
+  --popover: oklch(0.992 0.004 80);
+  --popover-foreground: oklch(0.22 0.012 75);
+  --primary: oklch(0.53 0.135 162);
+  --primary-foreground: oklch(0.985 0.01 160);
+  --secondary: oklch(0.94 0.009 78);
+  --secondary-foreground: oklch(0.29 0.012 75);
+  --muted: oklch(0.945 0.008 78);
+  --muted-foreground: oklch(0.52 0.014 75);
+  --accent: oklch(0.925 0.025 162);
+  --accent-foreground: oklch(0.32 0.08 162);
+  --destructive: oklch(0.56 0.2 27);
+  --destructive-foreground: oklch(0.985 0.005 27);
+  --border: oklch(0.875 0.01 75);
+  --input: oklch(0.875 0.01 75);
+  --ring: oklch(0.58 0.12 162);
+  --radius: 0.375rem;
 }
 
-* {
-  border-color: var(--border);
+.dark {
+  color-scheme: dark;
+  --background: oklch(0.18 0.012 75);
+  --foreground: oklch(0.93 0.008 75);
+  --card: oklch(0.215 0.012 75);
+  --card-foreground: oklch(0.93 0.008 75);
+  --popover: oklch(0.215 0.012 75);
+  --popover-foreground: oklch(0.93 0.008 75);
+  --primary: oklch(0.68 0.135 162);
+  --primary-foreground: oklch(0.17 0.03 162);
+  --secondary: oklch(0.27 0.012 75);
+  --secondary-foreground: oklch(0.91 0.008 75);
+  --muted: oklch(0.255 0.011 75);
+  --muted-foreground: oklch(0.69 0.012 75);
+  --accent: oklch(0.29 0.05 162);
+  --accent-foreground: oklch(0.88 0.06 162);
+  --destructive: oklch(0.66 0.18 27);
+  --destructive-foreground: oklch(0.98 0.005 27);
+  --border: oklch(0.34 0.012 75);
+  --input: oklch(0.34 0.012 75);
+  --ring: oklch(0.68 0.11 162);
+}
+
+@media (prefers-color-scheme: dark) {
+  :root:not(.light) {
+    color-scheme: dark;
+    --background: oklch(0.18 0.012 75);
+    --foreground: oklch(0.93 0.008 75);
+    --card: oklch(0.215 0.012 75);
+    --card-foreground: oklch(0.93 0.008 75);
+    --popover: oklch(0.215 0.012 75);
+    --popover-foreground: oklch(0.93 0.008 75);
+    --primary: oklch(0.68 0.135 162);
+    --primary-foreground: oklch(0.17 0.03 162);
+    --secondary: oklch(0.27 0.012 75);
+    --secondary-foreground: oklch(0.91 0.008 75);
+    --muted: oklch(0.255 0.011 75);
+    --muted-foreground: oklch(0.69 0.012 75);
+    --accent: oklch(0.29 0.05 162);
+    --accent-foreground: oklch(0.88 0.06 162);
+    --destructive: oklch(0.66 0.18 27);
+    --destructive-foreground: oklch(0.98 0.005 27);
+    --border: oklch(0.34 0.012 75);
+    --input: oklch(0.34 0.012 75);
+    --ring: oklch(0.68 0.11 162);
+  }
+}
+
+@theme inline {
+  --color-background: var(--background);
+  --color-foreground: var(--foreground);
+  --color-card: var(--card);
+  --color-card-foreground: var(--card-foreground);
+  --color-popover: var(--popover);
+  --color-popover-foreground: var(--popover-foreground);
+  --color-primary: var(--primary);
+  --color-primary-foreground: var(--primary-foreground);
+  --color-secondary: var(--secondary);
+  --color-secondary-foreground: var(--secondary-foreground);
+  --color-muted: var(--muted);
+  --color-muted-foreground: var(--muted-foreground);
+  --color-accent: var(--accent);
+  --color-accent-foreground: var(--accent-foreground);
+  --color-destructive: var(--destructive);
+  --color-destructive-foreground: var(--destructive-foreground);
+  --color-border: var(--border);
+  --color-input: var(--input);
+  --color-ring: var(--ring);
+  --radius-sm: calc(var(--radius) - 2px);
+  --radius-md: var(--radius);
+  --radius-lg: calc(var(--radius) + 2px);
 }
 
 body {
   margin: 0;
+  min-width: 320px;
   background: var(--background);
   color: var(--foreground);
   font-family: Inter, ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
+  text-rendering: optimizeLegibility;
 }
 
 button,
-input {
-  font: inherit;
+input,
+select,
+textarea {
+  color: inherit;
+}
+
+* {
+  border-color: var(--border);
+}
+
+::selection {
+  background: var(--accent);
+  color: var(--accent-foreground);
 }