@rudderhq/agent-runtime-opencode-local 0.7.2 → 0.7.3

package/skills/app-builder/scripts/report-build-status.mjs

@@ -0,0 +1,83 @@
+#!/usr/bin/env node
+
+const STATUS = process.argv[2];
+const APP_ID = process.argv[3];
+const ALLOWED_STATUSES = new Set(["building", "verified_source_ready", "failed"]);
+const UUID_PATTERN = /^[0-9a-f]{8}-[0-9a-f]{4}-[1-5][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i;
+
+if (!ALLOWED_STATUSES.has(STATUS) || !UUID_PATTERN.test(APP_ID ?? "")) {
+  console.error("Usage: report-build-status.mjs <building|verified_source_ready|failed> <app-id>");
+  process.exit(2);
+}
+
+const apiUrl = process.env.RUDDER_API_URL?.trim();
+const apiKey = process.env.RUDDER_API_KEY?.trim();
+const orgId = process.env.RUDDER_ORG_ID?.trim();
+const runId = process.env.RUDDER_RUN_ID?.trim();
+if (!apiUrl || !apiKey || !orgId || !runId) {
+  console.error("Rudder run context is unavailable; do not report a completed App handoff.");
+  process.exit(2);
+}
+
+const base = apiUrl.replace(/\/+$/u, "");
+const apiBase = new URL(base).pathname.replace(/\/+$/u, "").endsWith("/api")
+  ? base
+  : `${base}/api`;
+const endpoint = `${apiBase}/app-builder/${encodeURIComponent(APP_ID)}/build?orgId=${encodeURIComponent(orgId)}`;
+const headers = {
+  authorization: `Bearer ${apiKey}`,
+  "content-type": "application/json",
+};
+const currentResponse = await fetch(
+  `${apiBase}/orgs/${encodeURIComponent(orgId)}/app-builder`,
+  { headers },
+);
+if (!currentResponse.ok) {
+  console.error(`Rudder could not read the App handoff state (${currentResponse.status}).`);
+  process.exit(1);
+}
+const current = (await currentResponse.json()).find((app) => app.id === APP_ID);
+if (!current) {
+  console.error("Rudder App handoff identity was not found in this organization.");
+  process.exit(1);
+}
+const duplicateRunId = STATUS === "verified_source_ready"
+  ? current.latestVerificationRunId
+  : current.latestBuildRunId;
+if (current.buildStatus === STATUS && duplicateRunId === runId) {
+  console.log(`App Builder status: ${current.buildStatus}`);
+  process.exit(0);
+}
+const allowedCurrentStatuses = STATUS === "building"
+  ? new Set(["preparing", "ready", "launch_failed", "failed"])
+  : STATUS === "verified_source_ready"
+    ? new Set(["building"])
+    : new Set(["preparing", "building"]);
+if (!allowedCurrentStatuses.has(current.buildStatus)) {
+  console.error(
+    `Rudder rejected the stale App handoff transition ${current.buildStatus} -> ${STATUS}.`,
+  );
+  process.exit(1);
+}
+const response = await fetch(
+  endpoint,
+  {
+    method: "PATCH",
+    headers,
+    body: JSON.stringify({
+      status: STATUS,
+      expectedStatus: current.buildStatus,
+      runId,
+      runKind: STATUS === "verified_source_ready" ? "verification" : "build",
+    }),
+  },
+);
+
+if (!response.ok) {
+  const detail = await response.text();
+  console.error(`Rudder rejected the App handoff (${response.status}): ${detail.slice(0, 500)}`);
+  process.exit(1);
+}
+
+const app = await response.json();
+console.log(`App Builder status: ${app.buildStatus}`);

package/skills/rudder-docs/SKILL.md

@@ -134,8 +134,8 @@ Read only the reference needed for the request:
    installed CLI fallback catalog plus exact command semantics.
 3. [Agent creation](references/agent-creation.md) — permission-aware Agent
    configuration, governed hiring, approval, revision, and evidence workflow.
-4. [Plugin authoring](references/plugin-authoring.md) — current scaffold,
-   manifest, worker, UI, capability, route, and verification workflow.
+4. [Plugin authoring](references/plugin-authoring.md) — Codex-compatible
+   package layout, manifest, Skills, MCPs, Apps, and verification workflow.
 5. [Work practices](references/operating-practices.md) — exact
    conditional behavior for ownership, reviews, approvals, budgets,
    workspaces, Library handoff, authentication, and safe git use.

package/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/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/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/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/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