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

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