@oisincoveney/pipeline 1.24.0 → 1.25.0

package/.agents/skills/execute/SKILL.md

@@ -20,11 +20,11 @@ hooks: generated-defaults-audit
 Instructions:
 Orchestrate package-owned pipeline config.
 
-Submit Kubernetes runner Jobs by default through `oisin-pipeline quick` and `oisin-pipeline execute`.
+Submit Momokaya work as Argo Workflows through `moka submit` and `moka submit --quick`.
 
 Generate a schedule for entrypoint `execute` and the user task.
 The schedule policy is `execute-schedule`.
-Run `oisin-pipeline execute <task description>` to submit the pipeline as a k8s job.
-The pipeline runtime executes inside a Kubernetes pod using the package-owned runner image.
-Use `oisin-pipeline execute --local <task description>` for local execution instead.
-Use `oisin-pipeline run --schedule <schedule.yaml>` only when rerunning an existing schedule artifact.
+Run `moka submit <task description>` to submit the `execute` graph as an Argo Workflow.
+The pipeline runtime executes as Argo DAG tasks using the package-owned runner image.
+Use `--kubeconfig <path>` and `--namespace <namespace>` to target a local or remote Kubernetes cluster.
+Use `moka submit --schedule <schedule.yaml> <task description>` only when rerunning an existing schedule artifact.

package/.agents/skills/inspect/SKILL.md

@@ -36,6 +36,6 @@ For each CLI node prompt include:
 - dependency outputs
 
 Only package-configured gates are blocking. Do not invent RED, GREEN, full-suite, typecheck, or unrelated-drift gates.
-If a node returns targeted evidence and has no configured blocking gate, advance to the next workflow node.
-Do not bypass configured runner subprocesses or package-configured gates when executing workflow nodes.
+If a node returns targeted evidence and has no configured blocking gate, advance to the next node.
+Do not bypass configured runner subprocesses or package-configured gates when executing nodes.
 Do not claim these nodes are Codex subagents.

package/.agents/skills/quick/SKILL.md

@@ -20,11 +20,11 @@ hooks: generated-defaults-audit
 Instructions:
 Orchestrate package-owned pipeline config.
 
-Submit Kubernetes runner Jobs by default through `oisin-pipeline quick` and `oisin-pipeline execute`.
+Submit Momokaya work as Argo Workflows through `moka submit` and `moka submit --quick`.
 
 Generate a schedule for entrypoint `quick` and the user task.
 The schedule policy is `quick-schedule`.
-Run `oisin-pipeline quick <task description>` to submit the pipeline as a k8s job.
-The pipeline runtime executes inside a Kubernetes pod using the package-owned runner image.
-Use `oisin-pipeline quick --local <task description>` for local execution instead.
-Use `oisin-pipeline run --schedule <schedule.yaml>` only when rerunning an existing schedule artifact.
+Run `moka submit --quick <task description>` to submit the graph as an Argo Workflow.
+The pipeline runtime executes as Argo DAG tasks using the package-owned runner image.
+Use `--kubeconfig <path>` and `--namespace <namespace>` to target a local or remote Kubernetes cluster.
+Use `moka submit --schedule <schedule.yaml> <task description>` only when rerunning an existing schedule artifact.

package/README.md

@@ -1,22 +1,38 @@
 # @oisincoveney/pipeline
 
-Config-driven multi-agent pipeline runner for repository work. Runtime config is
-owned by the installed `@oisincoveney/pipeline` package. Repo-local `.pipeline`
-paths are runtime artifact locations only; they are not the runtime config
-source.
+Config-driven multi-agent pipeline runner for repository work. The installed
+package owns the runtime defaults; target repositories use `.pipeline/runs/` for
+generated schedules and run artifacts, not as the source of runtime config.
 
-## Requirements
+The published command is `moka`.
+
+## Install
+
+Requirements:
 
-- Bun 1.1 or newer
 - Node.js 22.13 or newer
-- `npx`, `backlog`, `uvx`, and Docker on `PATH` for default skills and MCP gateway setup
-- At least one configured runner CLI on `PATH`: `codex`, `opencode`, `kimi`,
-  `pi`, or a declared command runner
+- Bun 1.1 or newer for repository development and package build scripts
+- `npx`, `backlog`, `uvx`, and Docker on `PATH` for default skills and MCP
+  gateway setup
+- At least one runner CLI on `PATH`: `opencode` or a configured command runner
+
+Install the package in a target repository:
+
+```shell
+npm install --save-dev @oisincoveney/pipeline
+```
+
+Then run the local package binary:
+
+```shell
+moka --help
+```
 
-Install dependencies:
+For development inside this repository:
 
 ```shell
 bun install --frozen-lockfile
+bun run build:cli
 ```
 
 ## Start A Repository
@@ -24,259 +40,198 @@ bun install --frozen-lockfile
 Initialize package-owned pipeline support:
 
 ```shell
-pipe init
+moka init
 ```
 
-`pipe init` installs default project skills with
-`npx skills add oisincoveney/skills`, then writes generated OpenCode and Codex
-command surfaces plus their singleton `pipeline-gateway` MCP entries. OpenCode
-is the package default runtime; Codex remains a compatibility runner and host
-surface. The command does not create repo-local `.pipeline` config files.
+`moka init` installs default project skills with `npx @uidotsh/install`, then
+writes generated OpenCode command surfaces plus the singleton `pipeline-gateway`
+MCP entry. Set `UIDOTSH_TOKEN` before running `moka init` so the ui.sh installer
+does not prompt for the token. OpenCode is the package default runtime. The
+command does not create repo-local `.pipeline` config files.
 
-The default MCP gateway can run locally or point at the hosted Momokaya
-gateway. Set `PIPELINE_MCP_GATEWAY_AUTHORIZATION` to the full HTTP
-`Authorization` header value before starting Codex or OpenCode when using a
-protected gateway:
+The default MCP gateway can run locally or point at the hosted Momokaya gateway.
+Set `PIPELINE_MCP_GATEWAY_AUTHORIZATION` to the full HTTP `Authorization` header
+value before starting OpenCode when using a protected gateway:
 
 ```shell
 export PIPELINE_MCP_GATEWAY_AUTHORIZATION="Basic $(printf '%s' 'user:password' | base64)"
 ```
 
-To refresh or check generated host files later, use:
+Check or refresh generated host files after package upgrades:
 
 ```shell
-pipe install-commands --host all --check
+moka install-commands --host all --check
 ```
 
 Check local prerequisites and config health:
 
 ```shell
-pipe doctor
+moka doctor
 ```
 
-For a compact operator guide covering every command plus how to attach skills
-and MCP servers to agent profiles, see `docs/operator-guide.md`.
-
-Validate the config and compiled DAG:
+Validate the package-owned config and compiled workflow plan:
 
 ```shell
-pipe validate
+moka validate
 ```
 
-Inspect the execution plan before running:
+Inspect the execution plan:
 
 ```shell
-pipe explain-plan
+moka explain-plan
 ```
 
-Generate the default schedule artifact:
+## Command Surface
+
+`moka submit "<task>"`
+
+Generates the full graph schedule for a task, builds the runner payload from the
+current git context, and submits an Argo Workflow to the configured Momokaya
+cluster.
 
 ```shell
-pipe "Implement PIPE-123 user-facing behavior"
+moka submit "Implement PIPE-123 user-facing behavior"
 ```
 
-This writes `.pipeline/runs/<runId>/schedule.yaml` and stops for approval. Run
-the approved artifact explicitly:
+`moka submit "<task>" --quick`
+
+Uses the compact graph for smaller work.
 
 ```shell
-pipe run --schedule .pipeline/runs/<runId>/schedule.yaml "Implement PIPE-123 user-facing behavior"
+moka submit "Fix the login bug" --quick
 ```
 
-Run a read-only repository inspection:
+`moka submit --schedule <schedule.yaml> "<task>"`
+
+Submits a previously approved schedule artifact.
 
 ```shell
-pipe run --workflow inspect "Report the app structure and available checks. Do not modify files."
+moka submit --schedule .pipeline/runs/<runId>/schedule.yaml "Implement PIPE-123"
 ```
 
-Run a configured entrypoint alias:
+`moka submit --command -- <argv...>`
+
+Submits one explicit command as a one-task Argo Workflow.
 
 ```shell
-pipe run --entrypoint dogfood "Run deterministic local verification."
+moka submit --command -- opencode run "fix this bug"
 ```
 
-Run an epic drain workflow:
+`moka run "<task>"`
+
+Runs package-owned workflow config from the current worktree. Scheduled
+entrypoints generate a schedule artifact under `.pipeline/runs/<runId>/` and run
+the compiled schedule through the runtime.
 
 ```shell
-pipe epic PIPE-31
+moka run "Implement PIPE-123 user-facing behavior"
+moka run --schedule .pipeline/runs/<runId>/schedule.yaml "Implement PIPE-123"
+moka run --workflow inspect "Report the app structure and available checks. Do not modify files."
+moka run --entrypoint quick "Implement a focused fix"
 ```
 
-The `epic` entrypoint generates a specialized schedule for the epic, writes the
-schedule artifact, and stops. Execution uses the same `pipe run --schedule`
-approval boundary as `pipe`.
+`moka inspect "<task>"`
 
-The `pipe` binary also accepts the task directly:
+Runs the configured read-only inspection entrypoint.
 
 ```shell
-pipe "Implement PIPE-123 user-facing behavior"
+moka inspect "Explain the app structure and available checks"
 ```
 
-Use `PIPELINE_TARGET_PATH=/path/to/worktree` when invoking from outside the
-target repository.
+Use `PIPELINE_TARGET_PATH=/path/to/worktree` when invoking `moka` from outside
+the target repository.
 
-## Pipeline Console Runner Image
+For a compact command reference, see
+[`docs/operator-guide.md`](docs/operator-guide.md).
 
-`oisin-pipeline` is also the runner package/image used by `pipeline-console`.
-The control plane owns Argo Workflow submission, run listing, cancellation,
-event storage, Kueue discovery, and UI rendering. This package owns the
-in-container `runner-command` command used by Argo Workflow DAG tasks: payload
-validation, direct argv execution, event translation, authenticated event
-posting, signal cancellation, and final event flushing.
+## Momokaya Runner Image
+
+The package is also the runner code used by the Momokaya runner image. The
+control plane owns Argo Workflow submission, run listing, cancellation, event
+storage, Kueue discovery, and UI rendering. This package owns the in-container
+`moka runner-command` and `moka runner-finalize` commands used by Argo Workflow
+DAG tasks.
 
 Argo starts the image with payload, schedule, and per-task descriptor files
 mounted from ConfigMaps, plus the event auth token mounted from a Secret. The
 runner reads `--payload-file`, `--schedule-file`, and `/etc/pipeline/task.json`;
-the payload contains the workflow id and the task descriptor contains the node
-id. The event auth token still comes from the file path specified in
-`events.authTokenFile`; payload JSON, task identity, and auth token material are
-not delivered through environment variables. The payload contract is documented in
+payload JSON, task identity, and auth token material are not delivered through
+environment variables. The payload contract is documented in
 [`docs/pipeline-console-runner-contract.md`](docs/pipeline-console-runner-contract.md).
-The executable contract is exported from
+
+Submitters can import the executable contract from
 `@oisincoveney/pipeline/runner-command-contract` for payload construction,
 validation, contract-version checks, and JSON Schema generation.
-Use `PIPELINE_TARGET_PATH=/path/to/worktree` when the checked-out target repo is
-mounted somewhere other than the process working directory.
 
-## Custom YAML Parts
+## Configuration Model
 
 Runtime execution uses package-owned defaults. Tests and advanced embedding code
 can still parse explicit YAML parts with `parsePipelineConfigParts()`.
 
-`runners`:
+Package-owned defaults declare:
 
-```yaml
-version: 1
-
-runners:
-  codex:
-    type: codex
-    command: codex
-    model: gpt-5.5
-    capabilities:
-      native_subagents: true
-      tools: [read, grep, bash, edit, write]
-      filesystem: [read-only, workspace-write]
-      network: [inherit]
-      output_formats: [text, json, jsonl, json_schema]
-```
+- runner adapters and capabilities
+- profiles, rules, skills, tools, filesystem grants, network grants, and output
+  contracts
+- the singleton `pipeline-gateway` MCP connection
+- workflows, schedules, hooks, gates, artifacts, retries, and timeouts
+- generated OpenCode host resources
+- goal-loop contracts and continuation context
 
-`profiles`:
+Current default entrypoints:
 
 ```yaml
-version: 1
-
-profiles:
-  orchestrator:
-    runner: codex
-    instructions:
-      inline: Coordinate the workflow from this YAML file only.
-    tools: [read, grep, bash]
-    filesystem:
-      mode: read-only
-    network:
-      mode: inherit
-  implementer:
-    runner: codex
-    instructions:
-      inline: Implement the requested change and return evidence.
-    tools: [read, grep, bash, edit, write]
-    filesystem:
-      mode: workspace-write
-    output:
-      format: text
+entrypoints:
+  quick:
+    schedule: quick-schedule
+  execute:
+    schedule: execute-schedule
+  inspect:
+    workflow: inspect
 ```
 
-Example workflow shape:
+Current schedule policies:
 
 ```yaml
-version: 1
-default_workflow: default
-
-orchestrator:
-  profile: orchestrator
-
-hooks:
-  functions: {}
-  on: {}
-
-workflows:
-  default:
-    execution:
-      fail_fast: true
-      max_parallel_nodes: 2
-    nodes:
-      - id: implement
-        kind: agent
-        profile: implementer
-        timeout_ms: 300000
-        retries:
-          max_attempts: 2
-          retry_on: [exit_nonzero, gate_failure, timeout]
-        gates:
-          - kind: builtin
-            builtin: test
-          - kind: builtin
-            builtin: typecheck
+scheduler:
+  commands:
+    quick:
+      schedule: quick-schedule
+      catalog: quick
+    execute:
+      schedule: execute-schedule
+      catalog: execute
 ```
 
-Package-owned defaults declare `entrypoints` that expose stable app or CLI names
-resolving to workflows or schedule policies. Direct `--workflow` selection
-remains available and takes precedence over `--entrypoint` when both are set.
-
-The package defaults include a full research, red, green, verify, learn
-workflow. See `docs/config-architecture.md` for the host support matrix.
-
-### Structural Parallelism
-
 Workflows and generated schedules can express fixed parallel structure. A
 `kind: parallel` node contains a fixed set of child nodes that run concurrently
 after dependencies pass. A `kind: group` node groups existing nodes behind a
-single dependency target. This is structural parallelism, not dynamic fanout:
-agents may route work to tracks, but the branch topology stays auditable in YAML
-or in the generated schedule artifact.
+single dependency target. Agents may route work to tracks, but the branch
+topology stays auditable in YAML or in the generated schedule artifact.
 
-The scheduler emits explicit root DAGs for epics:
+See [`docs/config-architecture.md`](docs/config-architecture.md) for the config
+shape and [`docs/xstate-runtime-actor-model.md`](docs/xstate-runtime-actor-model.md)
+for the runtime actor model.
 
-```yaml
-workflows:
-  root:
-    nodes:
-      - id: research
-        kind: agent
-        profile: pipeline-researcher
-      - id: plan
-        kind: agent
-        profile: pipeline-epic-router
-        needs: [research]
-      - id: implement
-        kind: parallel
-        needs: [plan]
-        nodes:
-          - id: test
-            kind: agent
-            profile: pipeline-code-writer
-          - id: frontend
-            kind: agent
-            profile: pipeline-code-writer
-          - id: backend
-            kind: agent
-            profile: pipeline-code-writer
-          - id: k8s
-            kind: agent
-            profile: pipeline-code-writer
-      - id: verify
-        kind: agent
-        profile: pipeline-verifier
-        needs: [implement]
+## Generated Host Resources
+
+Generate native host files during setup:
+
+```shell
+moka init
 ```
 
-For Argo execution, Git refs carry node state across DAG tasks. Runner tasks
-derive state refs from `payload.run.id`, `payload.workflow.id`, and the mounted
-task descriptor node id.
+Generated resources are derived from package-owned config; they are not separate
+sources of truth. Host resources use OpenCode native agents for model-backed
+nodes. Otherwise generated instructions dispatch to the configured command
+runner.
 
-Default profile skills and generated host resources are installed by
-`pipe init`. Runtime MCP projection and host-specific isolation policy live in
-`src/mcp`; see [`docs/mcp-host-isolation.md`](docs/mcp-host-isolation.md) and
-[`docs/mcp-gateway.md`](docs/mcp-gateway.md).
+| Host | Generated files | Invocation |
+| --- | --- | --- |
+| OpenCode | `.opencode/commands/<entrypoint>.md`, `.opencode/agents/*.md`, `.opencode/skills/*/SKILL.md`, `.opencode/plugins/*.ts`, `.opencode/opencode.json` | `/quick <task>`, `/execute <task>`, `/inspect <task>` |
+
+The installer is idempotent, supports `--check` and `--dry-run`, and refuses to
+overwrite manually edited files unless `--force` is supplied.
 
 ## OpenCode-First Goal Loop
 
@@ -286,69 +241,19 @@ evidence, acceptance evidence, changed files, and failed gates are stored by the
 pipeline, not inferred from an OpenCode session. A goal is complete only when
 deterministic verifier evidence and acceptance coverage are both present.
 
-The curated OpenCode stack generated by package config includes:
-
-- project commands, agents, projected skills, explicit permissions, LSP, and the
-  singleton `pipeline-gateway` MCP server;
-- `.opencode/plugins/pipeline-goal-context.ts`, a package-owned compaction hook
-  that injects current goal-loop context into OpenCode continuation summaries;
-- `@devtheops/opencode-plugin-otel@1.1.0` in `.opencode/opencode.json`;
-- surfaced ecosystem inputs for DCP code, handoff/session capture,
-  background-agent delegation, prompt snippets, memory/context helpers, and
-  policy hooks.
-
 Team mode is generated as an auditable schedule graph. OpenCode subagents can
 execute graph nodes, but dependencies, retries, gates, verifier passes, and
 acceptance evidence stay pipeline-owned.
 
-## Generated Host Resources
-
-Generate native host files during setup:
-
-```shell
-pipe init
-```
-
-Generated resources are derived from package-owned config; they are not separate
-sources of truth. Host resources use exact native agents when the node runner
-matches the host. OpenCode also uses native subagents for cross-runner
-model-backed nodes when the runner/profile provides an OpenCode-compatible
-`model` or `host_models.opencode` value. Otherwise generated instructions
-dispatch to that runner's CLI instead of inventing a host model.
-The installer creates one command surface per configured entrypoint.
-
-| Host        | Generated files                                                   | Invocation                         |
-| ----------- | ----------------------------------------------------------------- | ---------------------------------- |
-| Codex       | `.agents/skills/<entrypoint>/SKILL.md`, `.agents/plugins/oisin-pipeline/commands/<entrypoint>.md`, `.agents/plugins/oisin-pipeline/agents/*.md`, `.codex/config.toml` | `$pipe <task>`, `$inspect <task>`, `$epic <task>`, `/pipe <task>`, `/inspect <task>`, `/epic <task>` |
-| OpenCode    | `.opencode/commands/<entrypoint>.md`, `.opencode/agents/*.md`, `.opencode/skills/*/SKILL.md`, `.opencode/plugins/*.ts`, `.opencode/opencode.json` | `/pipe <task>`, `/inspect <task>`, `/epic <task>` |
-| Kimi        | `.kimi/commands/<entrypoint>.md`, `.kimi/agents/*.yaml`           | `/pipe <task>`, `/inspect <task>`, `/epic <task>` |
-| Pi          | `.pi/prompts/<entrypoint>.md`                                     | `/pipe <task>`, `/inspect <task>`, `/epic <task>` |
-
-The installer is idempotent, supports `--check` and `--dry-run`, and refuses to
-overwrite manually edited files unless `--force` is supplied.
-
-Runner `model` is the canonical model id. Optional `host_models.<host>` entries
-are only needed when a host uses a different model identifier:
-
-```yaml
-runners:
-  kimi:
-    type: kimi
-    command: kimi
-    model: moonshot/kimi-k2.6
-```
-
 ## Runtime Guarantees
 
-- `pipe run` loads package-owned `@oisincoveney/pipeline` config even when the
+- `moka run` loads package-owned `@oisincoveney/pipeline` config even when the
   repository has no repo-local `.pipeline` config files.
 - Multi-agent workflows execute as separate agent boundaries; nodes are not
   merged into one prompt.
 - Native subagent strategy is preferred when the selected runner can represent
   the configured semantics. Otherwise the runtime uses a subprocess boundary.
 - Parallel DAG batches run concurrently after dependencies and gates pass.
-- `kind: parallel` child sets are fixed in YAML; routing agents decide which
-  work belongs in each declared track, not how many tracks exist.
 - Workflow execution can cap parallelism and enable fail-fast batch stopping.
 - Nodes can declare bounded retries, retry reasons, backoff, and execution
   timeouts.
@@ -360,7 +265,7 @@ runners:
 
 ## App-Facing API
 
-External apps can import the stable config, planner, schedule, and runtime surfaces
+External apps can import stable config, planner, schedule, and runtime surfaces
 without deep-importing private source paths:
 
 ```ts
@@ -400,9 +305,17 @@ import {
 } from "@oisincoveney/pipeline/runner-command-contract";
 ```
 
-## Verification
+Argo Workflows can be rendered with `buildRunnerArgoWorkflowManifest` from
+`@oisincoveney/pipeline/argo-workflow` and submitted with
+`submitRunnerArgoWorkflow` from `@oisincoveney/pipeline/argo-submit`.
 
-Use these commands before committing changes in this repository:
+## Release And Verification
+
+Package and container publishing is owned by GitHub Actions. Do not publish from
+a workstation with `npm publish`, `semantic-release`, Docker pushes, or direct
+registry commands.
+
+Before committing changes in this repository, run:
 
 ```shell
 bun run typecheck
@@ -411,7 +324,8 @@ bun run test
 bun run build:cli
 ```
 
+For runner-image wiring, also run:
 
-Argo Workflows can be rendered with `buildRunnerArgoWorkflowManifest` from
-`@oisincoveney/pipeline/argo-workflow` and submitted with
-`submitRunnerArgoWorkflow` from `@oisincoveney/pipeline/argo-submit`.
+```shell
+bun run test:image
+```

package/defaults/install-manifest.json

@@ -2,8 +2,7 @@
   "version": 1,
   "skills": [
     {
-      "source": "oisincoveney/skills",
-      "args": ["--agent", "codex", "--skill", "*", "--yes", "--copy"]
+      "source": "@uidotsh/install"
     }
   ]
 }

package/defaults/opencode-ecosystem.yaml

@@ -2,7 +2,7 @@ version: 1
 generated_by: "@oisincoveney/pipeline"
 runtime:
   default_runner: opencode
-  compatibility_runners: [codex]
+  compatibility_runners: []
   default_stack_direct: true
   state_authority: pipeline
 official_dependencies:
@@ -56,7 +56,7 @@ ecosystem_code:
     plugin:
       kind: npm
       package: "@prevalentware/opencode-goal-plugin"
-    role: Codex-style long-running goal mode with /goal slash command, persistent state, evidence-gated completion, and TUI sidebar
+    role: long-running goal mode with /goal slash command, persistent state, evidence-gated completion, and TUI sidebar
     default_stack: true
     source: https://www.npmjs.com/package/@prevalentware/opencode-goal-plugin
   - id: oc-codex-multi-auth
@@ -88,7 +88,7 @@ mcp_backends:
     locality: project-remote
     required: true
     credentials: [PIPELINE_MCP_GATEWAY_AUTHORIZATION]
-    role: singleton MCP server exposed to generated Codex and OpenCode host config
+    role: singleton MCP server exposed to generated OpenCode host config
   - id: context7
     name: Context7
     locality: shared-remote

package/dist/argo-submit.d.ts

@@ -4,7 +4,6 @@ import { CoreV1Api, CustomObjectsApi, KubeConfig } from "@kubernetes/client-node
 
 //#region src/argo-submit.d.ts
 declare const submitRunnerArgoWorkflowOptionsSchema: z.ZodObject<{
-  codexAuthSecretName: z.ZodOptional<z.ZodString>;
   eventAuthSecretKey: z.ZodOptional<z.ZodString>;
   eventAuthSecretName: z.ZodOptional<z.ZodString>;
   generateName: z.ZodOptional<z.ZodString>;
@@ -20,10 +19,6 @@ declare const submitRunnerArgoWorkflowOptionsSchema: z.ZodObject<{
   name: z.ZodOptional<z.ZodString>;
   namespace: z.ZodDefault<z.ZodString>;
   opencodeAuthSecretName: z.ZodOptional<z.ZodString>;
-  orchestrator: z.ZodDefault<z.ZodEnum<{
-    codex: "codex";
-    opencode: "opencode";
-  }>>;
   payloadJson: z.ZodString;
   queueName: z.ZodOptional<z.ZodString>;
   scheduleYaml: z.ZodString;
@@ -49,7 +44,7 @@ type SubmitRunnerArgoWorkflowOptions = z.input<typeof submitRunnerArgoWorkflowOp
 type SubmitRunnerArgoWorkflowResult = z.infer<typeof submitRunnerArgoWorkflowResultSchema>;
 type CommandScheduleOptions = z.input<typeof commandScheduleOptionsSchema>;
 type CoreApi = Pick<CoreV1Api, "createNamespacedConfigMap">;
-type WorkflowApi = Pick<CustomObjectsApi, "createNamespacedCustomObject" | "getClusterCustomObject">;
+type WorkflowApi = Pick<CustomObjectsApi, "createNamespacedCustomObject">;
 interface SubmitRunnerArgoWorkflowDependencies {
   coreApi?: CoreApi;
   kubeConfig?: KubeConfig;