@rudderhq/server 0.7.2 → 0.7.4

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

@@ -52,6 +52,11 @@ operating-practices guide for operating behavior:
 | `rudder_agent_skills_create` | `rudder agent skills create [agent-id] --name <name> [--enable]` | Create an agent-private skill package under AGENT_HOME/skills. | yes | no | no | attached when available |
 | `rudder_agent_skills_enable` | `rudder agent skills enable <agent-id> <selection-ref...>` | Add skill selections to an agent without replacing existing enabled skills. | yes | no | no | attached when available |
 | `rudder_agent_skills_sync` | `rudder agent skills sync <agent-id>` | Sync the desired enabled skill set for an agent. | yes | no | no | attached when available |
+| `rudder_goal_list` | `rudder goal list [--lifecycle <draft|active|closed|all>] [--focus <true|false>] [--facet <facet>] [--limit <n>]` | Discover Goals owned by the authenticated Agent; defaults to active Goals and returns current progress, next step, and attention state. | no | required | required | no |
+| `rudder_goal_context` | `rudder goal context <goal-id>` | Read the owned Goal agreement and current operating context before acting: contract revision, criteria, boundaries, progress, next step, attention, proposals, and recent feedback. | no | no | required | no |
+| `rudder_goal_progress` | `rudder goal progress <goal-id> --summary <text> --evidence-refs <json> --idempotency-key <key>` | Record evidence-backed progress for a Goal owned by the authenticated Agent and attribute it to the current Run. | yes | no | required | required |
+| `rudder_goal_change_propose` | `rudder goal change propose <goal-id> --contract-revision <n> --after-contract <json> --rationale <text> --idempotency-key <key>` | Propose a reviewable change to the current Goal contract when evidence shows its outcome, criteria, boundaries, or deadlines should change. | yes | no | required | required |
+| `rudder_goal_result_propose` | `rudder goal result propose <goal-id> --contract-revision <n> --criteria <json> --evidence-refs <json> --risk-summary <text> --idempotency-key <key>` | Submit an evidence-backed Goal result for mandatory human acceptance without closing the Goal. | yes | no | required | required |
 | `rudder_issue_get` | `rudder issue get <issue>` | Read a full issue by UUID or identifier. | no | no | no | no |
 | `rudder_issue_list` | `rudder issue list --org-id <id>` | List issues with optional status, assignee, and project filters without requiring a search query. | no | required | no | no |
 | `rudder_issue_search` | `rudder issue search <query> [--org-id <id>]` | Search issues with the server-side issue index across title, identifier, description, and comments. | no | required | no | no |
@@ -64,7 +69,7 @@ operating-practices guide for operating behavior:
 | `rudder_issue_review` | `rudder issue review <issue> --decision <decision> --comment-file <path>` | Record a structured reviewer decision with a required comment. | yes | no | no | attached when available |
 | `rudder_issue_commit` | `rudder issue commit <issue> --sha <sha> --message <subject>` | Report a code commit created during issue work as structured issue activity. | yes | no | no | attached when available |
 | `rudder_issue_done` | `rudder issue done <issue> --comment-file <path> [--image <path>]` | Mark an issue done with a required completion comment, optionally uploading images. | yes | no | no | attached when available |
-| `rudder_issue_block` | `rudder issue block <issue> --comment-file <path> [--image <path>]` | Mark an issue blocked with a required blocker comment, optionally uploading images. | yes | no | no | attached when available |
+| `rudder_issue_block` | `rudder issue block <issue> --comment-file <path> [--image <path>]` | Request human assistance after bounded recovery attempts; repeated matching claims are audited before the Issue becomes blocked. | yes | no | no | attached when available |
 | `rudder_project_list` | `rudder project list --org-id <id>` | List projects in an organization. | no | required | no | no |
 | `rudder_project_get` | `rudder project get <project-id-or-shortname> [--org-id <id>]` | Read one project by ID or shortname. | no | no | no | no |
 | `rudder_project_create` | `rudder project create --org-id <id> --name <name>` | Create a project in the organization. | yes | required | no | attached when available |
@@ -147,7 +152,7 @@ Operating rules live in [ownership, checkout, and wake scope](operating-practice
 
 - progress: `rudder issue comment <issue> --body-file <path> [--image <path>]`
 - done: `rudder issue done <issue> --comment-file <path> [--image <path>]`
-- blocked: `rudder issue block <issue> --comment-file <path> [--image <path>]`
+- assistance/block audit: `rudder issue block <issue> --comment-file <path> [--image <path>]`
 
 Issue comment and close-out commands accept comment bodies only from files or stdin. For multiline Markdown, command names, code spans, code blocks, test summaries, or screenshot evidence, pass `--body-file <path>` or `--comment-file <path>`, or pass `-` to read the body from stdin.
 

package/resources/bundled-skills/rudder-docs/references/operating-practices.md

@@ -83,12 +83,16 @@ because work is executable, durable, long-running, or reviewable.
 ## Review And Close-Out
 
 Use the close-out signal matching the outcome: a progress comment when work
-remains, done with completion evidence, blocked with a blocker comment, or an
-explicit handoff comment with an ownership change.
-
-If blocked, set the issue to `blocked`, identify the blocker, name the next
-actor or action, and leave the blocker comment before exit. Do not present
-partial work as complete.
+remains, done with completion evidence, a blocker claim after bounded recovery,
+or an explicit handoff comment with an ownership change.
+
+Complete the real task. If an action fails, investigate and try a bounded,
+materially different recovery path before requesting human help. A blocker
+claim must identify the blocker and exact human input or action required.
+Rudder records the Assistance Request and audits the same blocker across
+separate execution Runs; the first claim does not directly establish a blocked
+Issue. Do not repeat a failed action inside one Run merely to increase the
+audit count, and do not present partial work as complete.
 
 A reviewer does not take over implementation unless explicitly asked. Ordinary
 explicit reviewer work may happen in any issue status while preserving

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);
 }