{"owner":"argoproj","repo":"argo-workflows","hasSkills":true,"totalSkillsCount":5,"totalTokensCount":3269,"categories":["root-instruction","claude-rule","project-spec"],"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md","CLAUDE.md","docs/AGENTS.md","docs/architecture.md","ui/AGENTS.md"],"skills":{"AGENTS.md":"# Argo Workflows\n\nKubernetes-native workflow engine: workflows are CRDs, each step runs as a container. Components: `workflow-controller` (reconciles Workflows into pods), `argo-server` (gRPC+HTTP API, hosted inside the `argo` CLI binary), `argoexec` (runs inside workflow pods), and a React UI. Go module `github.com/argoproj/argo-workflows/v4` (imports need `/v4`), vendored deps.\n\nThe repo must be checked out at `$GOPATH/src/github.com/argoproj/argo-workflows` or codegen breaks.\n\nPer-directory guidance lives in nested AGENTS.md files: `workflow/controller/AGENTS.md`, `ui/AGENTS.md`, `docs/AGENTS.md`. Read the relevant one before working in those areas — agents that only auto-load CLAUDE.md files must read these explicitly.\n\n## Commands\n\n- Build: `make cli` (`dist/argo`), `make controller`, `make dist/argoexec`.\n- Unit tests: `make test`. Single test: `KUBECONFIG=/dev/null go test -run TestFoo ./workflow/controller/`.\n- E2E: bring the local stack up first (`make start PROFILE=mysql`), then `make test-<tag>` where `<tag>` is the `//go:build` tag at the top of the test file. Single e2e test: `make TestArtifactServer` (any `Test*` name works as a make target).\n- Local dev stack (k3d + Tilt, everything in-cluster with hot reload), ports, profiles, debugging: see docs/running-locally.md.\n- Lint: `make lint` (golangci-lint `--fix` + UI lint — commit what `--fix` changes; CI runs `git diff --exit-code`).\n- Codegen: `make codegen -B`. Pre-PR: `make pre-commit -B` (= codegen, lint, docs).\n\n## Conventions\n\n- Commits and PRs: follow the checklist in docs/pull-requests.md (DCO sign-off + Conventional Commits enforced by the commit-msg hook, `make pre-commit -B`, feature files for `feat:`, tests required, AI declaration). A bot checks PR descriptions against `.github/pull_request_template.md` and drafts non-conforming PRs.\n- Logging is the repo's own `util/logging`, not logrus: level methods take ctx (`logger.Info(ctx, \"msg\")`); get the logger with `logging.RequireLoggerFromContext(ctx)`; tests use `logging.TestContext(t.Context())`.\n- Errors: `errors/` for coded, user-visible `ArgoError`s; `util/errors.IsTransientErr(ctx, err)` for retry decisions.\n- Every env var read via `os.Getenv`/`util/env` must be documented in docs/environment-variables.md — `make docs` fails on undocumented or stale entries.\n\n### Generated files — never hand-edit, regenerate with `make codegen -B`\n\nCI regenerates and fails on diff: `pkg/client/`, `*.pb.go`, `generated.proto`, `zz_generated.deepcopy.go`, `openapi_generated.go`, `*.swagger.json`, `api/openapi-spec/`, `api/jsonschema/`, `manifests/install*.yaml`, `manifests/quick-start-*.yaml`, CRDs under `manifests/base/crds/`, `**/mocks/` (mockery), `sdks/java/client`, `sdks/go` — plus several docs/ pages generated from Go source that carry no DO-NOT-EDIT header (see docs/AGENTS.md).\n\n`examples/` are validated by a unit test (a malformed example fails `make test`) and feed the generated `docs/fields.md`.\n\n## Architecture\n\nEntrypoints: `cmd/workflow-controller` → `workflow/controller/` (reconciliation; see workflow/controller/AGENTS.md); `cmd/argo` → `cmd/argo/commands/` (includes `argo server` → `server/`); `cmd/argoexec` → `workflow/executor/`.\n\nCross-cutting invariants: the executor never writes the Workflow object — outputs travel through `WorkflowTaskResult` CRs merged by the controller. Large node status is compressed and, if still too big, offloaded to SQL (`workflow/hydrator/`, `persist/sqldb/`) — any reader outside the controller must hydrate first.\n\n### Executor (`workflow/executor/`)\n\n`argoexec emissary` is PID 1 wrapping the user command in every container: writes `/var/run/argo/ctr/<name>/exitcode`, waits on ContainerSet dependencies, reads the template from `/var/run/argo/template`. `init`/`wait` (legacy pod layout) or `supervisor` (init-less beta) stage input artifacts before main and run the shared `PostMain` capture sequence after (script result → parameters/artifacts/logs → report outputs). Output capture deliberately uses a background context so termination doesn't lose outputs.\n\nA task's flow is a `Plan` of three phases (Prepare, Run, Collect) over named `Stage`s. Every stage is declared in `workflow/executor/stages.go` (the registry, enforced by a test) and plans are selected per template in `workflow/executor/plan.go`. New executor behaviour is a new stage or a new plan, not a new hand-written sequence in a command.\n\n### Server (`server/`)\n\n`server/apiserver` serves gRPC and grpc-gateway HTTP on one port; artifact up/download endpoints and the embedded UI (`ui/embed.go`) are mounted directly. Auth (`server/auth`) is chosen per-request from the Authorization header: `client` (caller's k8s token, their RBAC), `server` (server's service account), `sso` (OIDC claims mapped to service accounts via RBAC labels); gatekeeper interceptors stash per-request clients in ctx (`auth.GetWfClient(ctx)`). Workflow archive lives in `server/workflowarchive` over `persist/sqldb` (Postgres/MySQL).\n\n`pkg/apiclient` gives every CLI command four transports behind one interface: argo-server gRPC, HTTP1 fallback, offline (lint without a cluster), and direct-kube (no server — service logic runs in-process against the k8s API).\n\n### Shared layers\n\n`workflow/common` (label/annotation keys, container names, `/var/run/argo` paths), `workflow/validate` (lint/submit/controller all share it), `workflow/templateresolution` (resolves `templateRef` chains, caches in `Status.StoredTemplates`), `workflow/artifacts` (driver per storage backend: s3, gcs, azure, oss, hdfs, git, http, raw, plugin), `workflow/sync` (semaphores/mutexes, configmap- or database-backed), `workflow/util` (submit/retry/resubmit operations shared by CLI and server), `workflow/cron`.\n","CLAUDE.md":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\nThe master record is @AGENTS.md — follow it.\n","docs/AGENTS.md":"# Docs\n\n- Follow `doc-changes.md` and the Kubernetes style guide it links: active voice, present tense, \"you\" for the reader, no statements about the future, and one sentence per line, also in the sources of generated pages.\n- API kinds are plain text (Workflow, WorkflowTemplate); field names, values and commands go in back-ticks.\n- Describe only what the release does, and name versions explicitly (\"v4.2 or later\", not \"this release\"); open proposals and planned features stay out.\n- `upgrading.md` is replaced at each minor release, so don't link into or out of it.\n- `.features/` notes become release notes: write for users, not reviewers, and remember featuregen drops blank lines, so no indented code blocks, unindented lists or separate paragraphs.\n- Use Argo's terms only for what they name (\"task\" is a DAG task; likewise step, node, template, pod), and name the exact resource or tool (`workflow-controller-configmap` or a namespace's `artifact-repositories` configmap; `kubectl`).\n- Be exact about behavior, checked against the code: whether a limit is per call or in total, whether a failure errors the node, when a boolean is true, what breaks on rollback or without the RBAC, the replacement for a deprecated field.\n- Examples must work when copied as they are and follow the advice next to them; detail too long for a table cell goes in a section below the table that the row links to.\n- New pages must be added to the `nav:` in `properdocs.yml` — the build is strict and fails otherwise.\n- `make docs-serve` builds and serves on :8000 with the same checks as CI; `make docs` runs spellcheck, markdownlint, and the env-var documentation check.\n- Generated pages — edit the source, not the markdown, then `make codegen -B`: `fields.md` (from swagger + `examples/`), `cli/` (from Cobra), `workflow-controller-configmap.md` (from doc comments on structs in `config/`), `metrics.md`/`tracing.md` (from `util/telemetry/builder/values.yaml`), `database-migrations.md` (from `persist/sqldb/migrate.go` and `util/sync/db/migrate.go`), `variable-flow/variables.md` (from `util/variables/`), `executor_swagger.md` (from doc comments in `pkg/plugins/executor/`), `docs/README.md` (copied from the root README); when rewording, also update the sample configmaps, `.features/` notes and code comments that repeat the text.\n- `go-sdk-guide.md` is half-generated: prose is hand-edited, but code blocks between `<embed>` markers are injected from `sdks/go` sources by embeddoc — edit the source, not the block.\n","docs/architecture.md":"# Architecture\n\n## Diagram\n\nThe following diagram shows the components of the Argo Workflows architecture. There are two Deployments: Workflow Controller and Argo Server. The former does all of the reconciling, and the latter serves the API. Note that the Controller can be used stand alone.\n\nThe reconciliation code for the `WorkflowController` can be found in [`workflow/controller/controller.go`](https://github.com/argoproj/argo-workflows/blob/main/workflow/controller/controller.go). The Argo Server opens up an HTTP(S) listener at [`server/apiserver/argoserver.go`](https://github.com/argoproj/argo-workflows/blob/main/server/apiserver/argoserver.go).\n\n![diagram](assets/diagram.png)\n\n---\n\n## Argo Workflow Overview\n\nThe diagram below provides a little more detail as far as namespaces. The Workflow Controller and Argo Server both run in the `argo` namespace. Assuming Argo Workflows was installed as a Cluster Install or as a Managed Namespace Install (described [here](installation.md)), the Workflows and the Pods generated from them run in a separate namespace.\n\nThe internals of a Pod are also shown. Each Step and each DAG Task cause a Pod to be generated, and each of these is composed of 3 containers:\n\n- `main` container runs the Image that the user indicated, where the `argoexec` utility is volume mounted and serves as the main command which calls the configured Command as a sub-process\n- `init` container is an `InitContainer`, fetching artifacts and parameters and making them available to the `main` container\n- `wait` container performs tasks that are needed for clean up, including saving off parameters and artifacts\n\nLook in [`cmd/argoexec`](https://github.com/argoproj/argo-workflows/blob/main/cmd/argoexec) for this code.\n\n### Init-less pod layout (opt-in, beta)\n\nWhen the controller is configured with `initlessPod.enabled: true`, workflow pods use an alternate two-container layout with zero init containers. The `argoexec` binary is delivered into `main` via a Kubernetes image volume ([KEP-4639](https://kep.k8s.io/4639) — Beta in 1.33 behind a feature gate, GA in 1.36), and a new `supervisor` container takes over both the pre-main responsibilities of the legacy init container (template write, script staging, input artifact download) and the post-main responsibilities of the legacy `wait` container (observe main, capture outputs, save artifacts and logs). Artifact plugins run as regular sidecars rather than as init containers, and `supervisor` drives each sidecar for both Load (pre-main) and Save (post-main). See [Init-less Pod Layout](initless-pod.md) for details.\n\n![diagram](assets/overview.jpeg)\n\n---\n\n## Workflow controller architecture\n\nThe following diagram shows the process for reconciliation, whereby a set of worker goroutines process the Workflows which have been added to a Workflow queue based on adds and updates to Workflows and Workflow Pods. Note that in addition to the Informers shown, there are Informers for the other CRDs that Argo Workflows uses as well. You can find this code in [`workflow/controller/controller.go`](https://github.com/argoproj/argo-workflows/blob/main/workflow/controller/controller.go). Note that the controller only ever processes a single Workflow at a time.\n\n![diagram](assets/workflow-controller-queue.png)\n\n---\n\n## Various configurations for Argo UI and Argo Server\n\nThe top diagram below shows what happens when you run \"make start\" locally. This runs a React application (`Webpack` HTTP server) locally which serves the `index.html` and typescript files from port 8080. From the typescript code there are calls made to the back end API (Argo Server) at port 2746. The `Webpack` HTTP server is configured for hot reload, meaning the UI will update automatically based on local code changes.\n\nThe second diagram is an alternative approach for rare occasions that the React files are broken and you're doing local development. In this case, everything is served from the Argo Server at port 2746.\n\nThe third diagram shows how things are configured for a Kubernetes environment. It is similar to the second diagram in that the Argo Server hosts everything for the UI.\n\n![diagram](assets/argo-server-ui-configurations.png)\n","ui/AGENTS.md":"# UI\n\nReact 18 + TypeScript, webpack, rxjs observables (no Redux), `argo-ui` component library pinned to a git SHA. Feature areas map 1:1 to `src/` directories; API clients live in `src/shared/services`. `src/shared/pod-name.ts` must stay in sync with the controller's pod naming.\n\n- Dev server: `yarn start` (:8080) proxies API and artifact routes to argo-server on :2746 (usually from `make start`).\n- Tests: `yarn test` (jest). E2E: `make test-ui-e2e` (playwright; needs `make start AUTH_MODE=client`; first run: `yarn playwright install --with-deps chromium`).\n- Lint: `yarn lint` (eslint `--fix` on `src` and `e2e`, then `tsc --noEmit` for both the app and `e2e/tsconfig.json`) — commit what `--fix` changes.\n- The production bundle is embedded into the server binary via `ui/embed.go`.\n"},"files":{"AGENTS.md":"# Argo Workflows\n\nKubernetes-native workflow engine: workflows are CRDs, each step runs as a container. Components: `workflow-controller` (reconciles Workflows into pods), `argo-server` (gRPC+HTTP API, hosted inside the `argo` CLI binary), `argoexec` (runs inside workflow pods), and a React UI. Go module `github.com/argoproj/argo-workflows/v4` (imports need `/v4`), vendored deps.\n\nThe repo must be checked out at `$GOPATH/src/github.com/argoproj/argo-workflows` or codegen breaks.\n\nPer-directory guidance lives in nested AGENTS.md files: `workflow/controller/AGENTS.md`, `ui/AGENTS.md`, `docs/AGENTS.md`. Read the relevant one before working in those areas — agents that only auto-load CLAUDE.md files must read these explicitly.\n\n## Commands\n\n- Build: `make cli` (`dist/argo`), `make controller`, `make dist/argoexec`.\n- Unit tests: `make test`. Single test: `KUBECONFIG=/dev/null go test -run TestFoo ./workflow/controller/`.\n- E2E: bring the local stack up first (`make start PROFILE=mysql`), then `make test-<tag>` where `<tag>` is the `//go:build` tag at the top of the test file. Single e2e test: `make TestArtifactServer` (any `Test*` name works as a make target).\n- Local dev stack (k3d + Tilt, everything in-cluster with hot reload), ports, profiles, debugging: see docs/running-locally.md.\n- Lint: `make lint` (golangci-lint `--fix` + UI lint — commit what `--fix` changes; CI runs `git diff --exit-code`).\n- Codegen: `make codegen -B`. Pre-PR: `make pre-commit -B` (= codegen, lint, docs).\n\n## Conventions\n\n- Commits and PRs: follow the checklist in docs/pull-requests.md (DCO sign-off + Conventional Commits enforced by the commit-msg hook, `make pre-commit -B`, feature files for `feat:`, tests required, AI declaration). A bot checks PR descriptions against `.github/pull_request_template.md` and drafts non-conforming PRs.\n- Logging is the repo's own `util/logging`, not logrus: level methods take ctx (`logger.Info(ctx, \"msg\")`); get the logger with `logging.RequireLoggerFromContext(ctx)`; tests use `logging.TestContext(t.Context())`.\n- Errors: `errors/` for coded, user-visible `ArgoError`s; `util/errors.IsTransientErr(ctx, err)` for retry decisions.\n- Every env var read via `os.Getenv`/`util/env` must be documented in docs/environment-variables.md — `make docs` fails on undocumented or stale entries.\n\n### Generated files — never hand-edit, regenerate with `make codegen -B`\n\nCI regenerates and fails on diff: `pkg/client/`, `*.pb.go`, `generated.proto`, `zz_generated.deepcopy.go`, `openapi_generated.go`, `*.swagger.json`, `api/openapi-spec/`, `api/jsonschema/`, `manifests/install*.yaml`, `manifests/quick-start-*.yaml`, CRDs under `manifests/base/crds/`, `**/mocks/` (mockery), `sdks/java/client`, `sdks/go` — plus several docs/ pages generated from Go source that carry no DO-NOT-EDIT header (see docs/AGENTS.md).\n\n`examples/` are validated by a unit test (a malformed example fails `make test`) and feed the generated `docs/fields.md`.\n\n## Architecture\n\nEntrypoints: `cmd/workflow-controller` → `workflow/controller/` (reconciliation; see workflow/controller/AGENTS.md); `cmd/argo` → `cmd/argo/commands/` (includes `argo server` → `server/`); `cmd/argoexec` → `workflow/executor/`.\n\nCross-cutting invariants: the executor never writes the Workflow object — outputs travel through `WorkflowTaskResult` CRs merged by the controller. Large node status is compressed and, if still too big, offloaded to SQL (`workflow/hydrator/`, `persist/sqldb/`) — any reader outside the controller must hydrate first.\n\n### Executor (`workflow/executor/`)\n\n`argoexec emissary` is PID 1 wrapping the user command in every container: writes `/var/run/argo/ctr/<name>/exitcode`, waits on ContainerSet dependencies, reads the template from `/var/run/argo/template`. `init`/`wait` (legacy pod layout) or `supervisor` (init-less beta) stage input artifacts before main and run the shared `PostMain` capture sequence after (script result → parameters/artifacts/logs → report outputs). Output capture deliberately uses a background context so termination doesn't lose outputs.\n\nA task's flow is a `Plan` of three phases (Prepare, Run, Collect) over named `Stage`s. Every stage is declared in `workflow/executor/stages.go` (the registry, enforced by a test) and plans are selected per template in `workflow/executor/plan.go`. New executor behaviour is a new stage or a new plan, not a new hand-written sequence in a command.\n\n### Server (`server/`)\n\n`server/apiserver` serves gRPC and grpc-gateway HTTP on one port; artifact up/download endpoints and the embedded UI (`ui/embed.go`) are mounted directly. Auth (`server/auth`) is chosen per-request from the Authorization header: `client` (caller's k8s token, their RBAC), `server` (server's service account), `sso` (OIDC claims mapped to service accounts via RBAC labels); gatekeeper interceptors stash per-request clients in ctx (`auth.GetWfClient(ctx)`). Workflow archive lives in `server/workflowarchive` over `persist/sqldb` (Postgres/MySQL).\n\n`pkg/apiclient` gives every CLI command four transports behind one interface: argo-server gRPC, HTTP1 fallback, offline (lint without a cluster), and direct-kube (no server — service logic runs in-process against the k8s API).\n\n### Shared layers\n\n`workflow/common` (label/annotation keys, container names, `/var/run/argo` paths), `workflow/validate` (lint/submit/controller all share it), `workflow/templateresolution` (resolves `templateRef` chains, caches in `Status.StoredTemplates`), `workflow/artifacts` (driver per storage backend: s3, gcs, azure, oss, hdfs, git, http, raw, plugin), `workflow/sync` (semaphores/mutexes, configmap- or database-backed), `workflow/util` (submit/retry/resubmit operations shared by CLI and server), `workflow/cron`.\n","CLAUDE.md":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\nThe master record is @AGENTS.md — follow it.\n","docs/AGENTS.md":"# Docs\n\n- Follow `doc-changes.md` and the Kubernetes style guide it links: active voice, present tense, \"you\" for the reader, no statements about the future, and one sentence per line, also in the sources of generated pages.\n- API kinds are plain text (Workflow, WorkflowTemplate); field names, values and commands go in back-ticks.\n- Describe only what the release does, and name versions explicitly (\"v4.2 or later\", not \"this release\"); open proposals and planned features stay out.\n- `upgrading.md` is replaced at each minor release, so don't link into or out of it.\n- `.features/` notes become release notes: write for users, not reviewers, and remember featuregen drops blank lines, so no indented code blocks, unindented lists or separate paragraphs.\n- Use Argo's terms only for what they name (\"task\" is a DAG task; likewise step, node, template, pod), and name the exact resource or tool (`workflow-controller-configmap` or a namespace's `artifact-repositories` configmap; `kubectl`).\n- Be exact about behavior, checked against the code: whether a limit is per call or in total, whether a failure errors the node, when a boolean is true, what breaks on rollback or without the RBAC, the replacement for a deprecated field.\n- Examples must work when copied as they are and follow the advice next to them; detail too long for a table cell goes in a section below the table that the row links to.\n- New pages must be added to the `nav:` in `properdocs.yml` — the build is strict and fails otherwise.\n- `make docs-serve` builds and serves on :8000 with the same checks as CI; `make docs` runs spellcheck, markdownlint, and the env-var documentation check.\n- Generated pages — edit the source, not the markdown, then `make codegen -B`: `fields.md` (from swagger + `examples/`), `cli/` (from Cobra), `workflow-controller-configmap.md` (from doc comments on structs in `config/`), `metrics.md`/`tracing.md` (from `util/telemetry/builder/values.yaml`), `database-migrations.md` (from `persist/sqldb/migrate.go` and `util/sync/db/migrate.go`), `variable-flow/variables.md` (from `util/variables/`), `executor_swagger.md` (from doc comments in `pkg/plugins/executor/`), `docs/README.md` (copied from the root README); when rewording, also update the sample configmaps, `.features/` notes and code comments that repeat the text.\n- `go-sdk-guide.md` is half-generated: prose is hand-edited, but code blocks between `<embed>` markers are injected from `sdks/go` sources by embeddoc — edit the source, not the block.\n","docs/architecture.md":"# Architecture\n\n## Diagram\n\nThe following diagram shows the components of the Argo Workflows architecture. There are two Deployments: Workflow Controller and Argo Server. The former does all of the reconciling, and the latter serves the API. Note that the Controller can be used stand alone.\n\nThe reconciliation code for the `WorkflowController` can be found in [`workflow/controller/controller.go`](https://github.com/argoproj/argo-workflows/blob/main/workflow/controller/controller.go). The Argo Server opens up an HTTP(S) listener at [`server/apiserver/argoserver.go`](https://github.com/argoproj/argo-workflows/blob/main/server/apiserver/argoserver.go).\n\n![diagram](assets/diagram.png)\n\n---\n\n## Argo Workflow Overview\n\nThe diagram below provides a little more detail as far as namespaces. The Workflow Controller and Argo Server both run in the `argo` namespace. Assuming Argo Workflows was installed as a Cluster Install or as a Managed Namespace Install (described [here](installation.md)), the Workflows and the Pods generated from them run in a separate namespace.\n\nThe internals of a Pod are also shown. Each Step and each DAG Task cause a Pod to be generated, and each of these is composed of 3 containers:\n\n- `main` container runs the Image that the user indicated, where the `argoexec` utility is volume mounted and serves as the main command which calls the configured Command as a sub-process\n- `init` container is an `InitContainer`, fetching artifacts and parameters and making them available to the `main` container\n- `wait` container performs tasks that are needed for clean up, including saving off parameters and artifacts\n\nLook in [`cmd/argoexec`](https://github.com/argoproj/argo-workflows/blob/main/cmd/argoexec) for this code.\n\n### Init-less pod layout (opt-in, beta)\n\nWhen the controller is configured with `initlessPod.enabled: true`, workflow pods use an alternate two-container layout with zero init containers. The `argoexec` binary is delivered into `main` via a Kubernetes image volume ([KEP-4639](https://kep.k8s.io/4639) — Beta in 1.33 behind a feature gate, GA in 1.36), and a new `supervisor` container takes over both the pre-main responsibilities of the legacy init container (template write, script staging, input artifact download) and the post-main responsibilities of the legacy `wait` container (observe main, capture outputs, save artifacts and logs). Artifact plugins run as regular sidecars rather than as init containers, and `supervisor` drives each sidecar for both Load (pre-main) and Save (post-main). See [Init-less Pod Layout](initless-pod.md) for details.\n\n![diagram](assets/overview.jpeg)\n\n---\n\n## Workflow controller architecture\n\nThe following diagram shows the process for reconciliation, whereby a set of worker goroutines process the Workflows which have been added to a Workflow queue based on adds and updates to Workflows and Workflow Pods. Note that in addition to the Informers shown, there are Informers for the other CRDs that Argo Workflows uses as well. You can find this code in [`workflow/controller/controller.go`](https://github.com/argoproj/argo-workflows/blob/main/workflow/controller/controller.go). Note that the controller only ever processes a single Workflow at a time.\n\n![diagram](assets/workflow-controller-queue.png)\n\n---\n\n## Various configurations for Argo UI and Argo Server\n\nThe top diagram below shows what happens when you run \"make start\" locally. This runs a React application (`Webpack` HTTP server) locally which serves the `index.html` and typescript files from port 8080. From the typescript code there are calls made to the back end API (Argo Server) at port 2746. The `Webpack` HTTP server is configured for hot reload, meaning the UI will update automatically based on local code changes.\n\nThe second diagram is an alternative approach for rare occasions that the React files are broken and you're doing local development. In this case, everything is served from the Argo Server at port 2746.\n\nThe third diagram shows how things are configured for a Kubernetes environment. It is similar to the second diagram in that the Argo Server hosts everything for the UI.\n\n![diagram](assets/argo-server-ui-configurations.png)\n","ui/AGENTS.md":"# UI\n\nReact 18 + TypeScript, webpack, rxjs observables (no Redux), `argo-ui` component library pinned to a git SHA. Feature areas map 1:1 to `src/` directories; API clients live in `src/shared/services`. `src/shared/pod-name.ts` must stay in sync with the controller's pod naming.\n\n- Dev server: `yarn start` (:8080) proxies API and artifact routes to argo-server on :2746 (usually from `make start`).\n- Tests: `yarn test` (jest). E2E: `make test-ui-e2e` (playwright; needs `make start AUTH_MODE=client`; first run: `yarn playwright install --with-deps chromium`).\n- Lint: `yarn lint` (eslint `--fix` on `src` and `e2e`, then `tsc --noEmit` for both the app and `e2e/tsconfig.json`) — commit what `--fix` changes.\n- The production bundle is embedded into the server binary via `ui/embed.go`.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/argoproj/argo-workflows/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Argo Workflows\n\nKubernetes-native workflow engine: workflows are CRDs, each step runs as a container. Components: `workflow-controller` (reconciles Workflows into pods), `argo-server` (gRPC+HTTP API, hosted inside the `argo` CLI binary), `argoexec` (runs inside workflow pods), and a React UI. Go module `github.com/argoproj/argo-workflows/v4` (imports need `/v4`), vendored deps.\n\nThe repo must be checked out at `$GOPATH/src/github.com/argoproj/argo-workflows` or codegen breaks.\n\nPer-directory guidance lives in nested AGENTS.md files: `workflow/controller/AGENTS.md`, `ui/AGENTS.md`, `docs/AGENTS.md`. Read the relevant one before working in those areas — agents that only auto-load CLAUDE.md files must read these explicitly.\n\n## Commands\n\n- Build: `make cli` (`dist/argo`), `make controller`, `make dist/argoexec`.\n- Unit tests: `make test`. Single test: `KUBECONFIG=/dev/null go test -run TestFoo ./workflow/controller/`.\n- E2E: bring the local stack up first (`make start PROFILE=mysql`), then `make test-<tag>` where `<tag>` is the `//go:build` tag at the top of the test file. Single e2e test: `make TestArtifactServer` (any `Test*` name works as a make target).\n- Local dev stack (k3d + Tilt, everything in-cluster with hot reload), ports, profiles, debugging: see docs/running-locally.md.\n- Lint: `make lint` (golangci-lint `--fix` + UI lint — commit what `--fix` changes; CI runs `git diff --exit-code`).\n- Codegen: `make codegen -B`. Pre-PR: `make pre-commit -B` (= codegen, lint, docs).\n\n## Conventions\n\n- Commits and PRs: follow the checklist in docs/pull-requests.md (DCO sign-off + Conventional Commits enforced by the commit-msg hook, `make pre-commit -B`, feature files for `feat:`, tests required, AI declaration). A bot checks PR descriptions against `.github/pull_request_template.md` and drafts non-conforming PRs.\n- Logging is the repo's own `util/logging`, not logrus: level methods take ctx (`logger.Info(ctx, \"msg\")`); get the logger with `logging.RequireLoggerFromContext(ctx)`; tests use `logging.TestContext(t.Context())`.\n- Errors: `errors/` for coded, user-visible `ArgoError`s; `util/errors.IsTransientErr(ctx, err)` for retry decisions.\n- Every env var read via `os.Getenv`/`util/env` must be documented in docs/environment-variables.md — `make docs` fails on undocumented or stale entries.\n\n### Generated files — never hand-edit, regenerate with `make codegen -B`\n\nCI regenerates and fails on diff: `pkg/client/`, `*.pb.go`, `generated.proto`, `zz_generated.deepcopy.go`, `openapi_generated.go`, `*.swagger.json`, `api/openapi-spec/`, `api/jsonschema/`, `manifests/install*.yaml`, `manifests/quick-start-*.yaml`, CRDs under `manifests/base/crds/`, `**/mocks/` (mockery), `sdks/java/client`, `sdks/go` — plus several docs/ pages generated from Go source that carry no DO-NOT-EDIT header (see docs/AGENTS.md).\n\n`examples/` are validated by a unit test (a malformed example fails `make test`) and feed the generated `docs/fields.md`.\n\n## Architecture\n\nEntrypoints: `cmd/workflow-controller` → `workflow/controller/` (reconciliation; see workflow/controller/AGENTS.md); `cmd/argo` → `cmd/argo/commands/` (includes `argo server` → `server/`); `cmd/argoexec` → `workflow/executor/`.\n\nCross-cutting invariants: the executor never writes the Workflow object — outputs travel through `WorkflowTaskResult` CRs merged by the controller. Large node status is compressed and, if still too big, offloaded to SQL (`workflow/hydrator/`, `persist/sqldb/`) — any reader outside the controller must hydrate first.\n\n### Executor (`workflow/executor/`)\n\n`argoexec emissary` is PID 1 wrapping the user command in every container: writes `/var/run/argo/ctr/<name>/exitcode`, waits on ContainerSet dependencies, reads the template from `/var/run/argo/template`. `init`/`wait` (legacy pod layout) or `supervisor` (init-less beta) stage input artifacts before main and run the shared `PostMain` capture sequence after (script result → parameters/artifacts/logs → report outputs). Output capture deliberately uses a background context so termination doesn't lose outputs.\n\nA task's flow is a `Plan` of three phases (Prepare, Run, Collect) over named `Stage`s. Every stage is declared in `workflow/executor/stages.go` (the registry, enforced by a test) and plans are selected per template in `workflow/executor/plan.go`. New executor behaviour is a new stage or a new plan, not a new hand-written sequence in a command.\n\n### Server (`server/`)\n\n`server/apiserver` serves gRPC and grpc-gateway HTTP on one port; artifact up/download endpoints and the embedded UI (`ui/embed.go`) are mounted directly. Auth (`server/auth`) is chosen per-request from the Authorization header: `client` (caller's k8s token, their RBAC), `server` (server's service account), `sso` (OIDC claims mapped to service accounts via RBAC labels); gatekeeper interceptors stash per-request clients in ctx (`auth.GetWfClient(ctx)`). Workflow archive lives in `server/workflowarchive` over `persist/sqldb` (Postgres/MySQL).\n\n`pkg/apiclient` gives every CLI command four transports behind one interface: argo-server gRPC, HTTP1 fallback, offline (lint without a cluster), and direct-kube (no server — service logic runs in-process against the k8s API).\n\n### Shared layers\n\n`workflow/common` (label/annotation keys, container names, `/var/run/argo` paths), `workflow/validate` (lint/submit/controller all share it), `workflow/templateresolution` (resolves `templateRef` chains, caches in `Status.StoredTemplates`), `workflow/artifacts` (driver per storage backend: s3, gcs, azure, oss, hdfs, git, http, raw, plugin), `workflow/sync` (semaphores/mutexes, configmap- or database-backed), `workflow/util` (submit/retry/resubmit operations shared by CLI and server), `workflow/cron`.\n","isInternal":false,"tokens":1474,"sizeBytes":5784},{"name":"AGENTS.md","path":"docs/AGENTS.md","rawUrl":"https://raw.githubusercontent.com/argoproj/argo-workflows/HEAD/docs/AGENTS.md","title":"docs - AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Docs\n\n- Follow `doc-changes.md` and the Kubernetes style guide it links: active voice, present tense, \"you\" for the reader, no statements about the future, and one sentence per line, also in the sources of generated pages.\n- API kinds are plain text (Workflow, WorkflowTemplate); field names, values and commands go in back-ticks.\n- Describe only what the release does, and name versions explicitly (\"v4.2 or later\", not \"this release\"); open proposals and planned features stay out.\n- `upgrading.md` is replaced at each minor release, so don't link into or out of it.\n- `.features/` notes become release notes: write for users, not reviewers, and remember featuregen drops blank lines, so no indented code blocks, unindented lists or separate paragraphs.\n- Use Argo's terms only for what they name (\"task\" is a DAG task; likewise step, node, template, pod), and name the exact resource or tool (`workflow-controller-configmap` or a namespace's `artifact-repositories` configmap; `kubectl`).\n- Be exact about behavior, checked against the code: whether a limit is per call or in total, whether a failure errors the node, when a boolean is true, what breaks on rollback or without the RBAC, the replacement for a deprecated field.\n- Examples must work when copied as they are and follow the advice next to them; detail too long for a table cell goes in a section below the table that the row links to.\n- New pages must be added to the `nav:` in `properdocs.yml` — the build is strict and fails otherwise.\n- `make docs-serve` builds and serves on :8000 with the same checks as CI; `make docs` runs spellcheck, markdownlint, and the env-var documentation check.\n- Generated pages — edit the source, not the markdown, then `make codegen -B`: `fields.md` (from swagger + `examples/`), `cli/` (from Cobra), `workflow-controller-configmap.md` (from doc comments on structs in `config/`), `metrics.md`/`tracing.md` (from `util/telemetry/builder/values.yaml`), `database-migrations.md` (from `persist/sqldb/migrate.go` and `util/sync/db/migrate.go`), `variable-flow/variables.md` (from `util/variables/`), `executor_swagger.md` (from doc comments in `pkg/plugins/executor/`), `docs/README.md` (copied from the root README); when rewording, also update the sample configmaps, `.features/` notes and code comments that repeat the text.\n- `go-sdk-guide.md` is half-generated: prose is hand-edited, but code blocks between `<embed>` markers are injected from `sdks/go` sources by embeddoc — edit the source, not the block.\n","isInternal":false,"tokens":613,"sizeBytes":2518},{"name":"AGENTS.md","path":"ui/AGENTS.md","rawUrl":"https://raw.githubusercontent.com/argoproj/argo-workflows/HEAD/ui/AGENTS.md","title":"ui - AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# UI\n\nReact 18 + TypeScript, webpack, rxjs observables (no Redux), `argo-ui` component library pinned to a git SHA. Feature areas map 1:1 to `src/` directories; API clients live in `src/shared/services`. `src/shared/pod-name.ts` must stay in sync with the controller's pod naming.\n\n- Dev server: `yarn start` (:8080) proxies API and artifact routes to argo-server on :2746 (usually from `make start`).\n- Tests: `yarn test` (jest). E2E: `make test-ui-e2e` (playwright; needs `make start AUTH_MODE=client`; first run: `yarn playwright install --with-deps chromium`).\n- Lint: `yarn lint` (eslint `--fix` on `src` and `e2e`, then `tsc --noEmit` for both the app and `e2e/tsconfig.json`) — commit what `--fix` changes.\n- The production bundle is embedded into the server binary via `ui/embed.go`.\n","isInternal":false,"tokens":230,"sizeBytes":794},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/argoproj/argo-workflows/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\nThe master record is @AGENTS.md — follow it.\n","isInternal":false,"tokens":39,"sizeBytes":164},{"name":"architecture.md","path":"docs/architecture.md","rawUrl":"https://raw.githubusercontent.com/argoproj/argo-workflows/HEAD/docs/architecture.md","title":"docs - System Architecture & Module Boundaries","category":"project-spec","format":"markdown","content":"# Architecture\n\n## Diagram\n\nThe following diagram shows the components of the Argo Workflows architecture. There are two Deployments: Workflow Controller and Argo Server. The former does all of the reconciling, and the latter serves the API. Note that the Controller can be used stand alone.\n\nThe reconciliation code for the `WorkflowController` can be found in [`workflow/controller/controller.go`](https://github.com/argoproj/argo-workflows/blob/main/workflow/controller/controller.go). The Argo Server opens up an HTTP(S) listener at [`server/apiserver/argoserver.go`](https://github.com/argoproj/argo-workflows/blob/main/server/apiserver/argoserver.go).\n\n![diagram](assets/diagram.png)\n\n---\n\n## Argo Workflow Overview\n\nThe diagram below provides a little more detail as far as namespaces. The Workflow Controller and Argo Server both run in the `argo` namespace. Assuming Argo Workflows was installed as a Cluster Install or as a Managed Namespace Install (described [here](installation.md)), the Workflows and the Pods generated from them run in a separate namespace.\n\nThe internals of a Pod are also shown. Each Step and each DAG Task cause a Pod to be generated, and each of these is composed of 3 containers:\n\n- `main` container runs the Image that the user indicated, where the `argoexec` utility is volume mounted and serves as the main command which calls the configured Command as a sub-process\n- `init` container is an `InitContainer`, fetching artifacts and parameters and making them available to the `main` container\n- `wait` container performs tasks that are needed for clean up, including saving off parameters and artifacts\n\nLook in [`cmd/argoexec`](https://github.com/argoproj/argo-workflows/blob/main/cmd/argoexec) for this code.\n\n### Init-less pod layout (opt-in, beta)\n\nWhen the controller is configured with `initlessPod.enabled: true`, workflow pods use an alternate two-container layout with zero init containers. The `argoexec` binary is delivered into `main` via a Kubernetes image volume ([KEP-4639](https://kep.k8s.io/4639) — Beta in 1.33 behind a feature gate, GA in 1.36), and a new `supervisor` container takes over both the pre-main responsibilities of the legacy init container (template write, script staging, input artifact download) and the post-main responsibilities of the legacy `wait` container (observe main, capture outputs, save artifacts and logs). Artifact plugins run as regular sidecars rather than as init containers, and `supervisor` drives each sidecar for both Load (pre-main) and Save (post-main). See [Init-less Pod Layout](initless-pod.md) for details.\n\n![diagram](assets/overview.jpeg)\n\n---\n\n## Workflow controller architecture\n\nThe following diagram shows the process for reconciliation, whereby a set of worker goroutines process the Workflows which have been added to a Workflow queue based on adds and updates to Workflows and Workflow Pods. Note that in addition to the Informers shown, there are Informers for the other CRDs that Argo Workflows uses as well. You can find this code in [`workflow/controller/controller.go`](https://github.com/argoproj/argo-workflows/blob/main/workflow/controller/controller.go). Note that the controller only ever processes a single Workflow at a time.\n\n![diagram](assets/workflow-controller-queue.png)\n\n---\n\n## Various configurations for Argo UI and Argo Server\n\nThe top diagram below shows what happens when you run \"make start\" locally. This runs a React application (`Webpack` HTTP server) locally which serves the `index.html` and typescript files from port 8080. From the typescript code there are calls made to the back end API (Argo Server) at port 2746. The `Webpack` HTTP server is configured for hot reload, meaning the UI will update automatically based on local code changes.\n\nThe second diagram is an alternative approach for rare occasions that the React files are broken and you're doing local development. In this case, everything is served from the Argo Server at port 2746.\n\nThe third diagram shows how things are configured for a Kubernetes environment. It is similar to the second diagram in that the Argo Server hosts everything for the UI.\n\n![diagram](assets/argo-server-ui-configurations.png)\n","isInternal":false,"tokens":913,"sizeBytes":4215}],"systemPromptSnippet":"<yakaai_skills repo=\"argoproj/argo-workflows\">\n<!-- File: AGENTS.md (Tokens: ~1474 | Category: root-instruction) -->\n# Argo Workflows\n\nKubernetes-native workflow engine: workflows are CRDs, each step runs as a container. Components: `workflow-controller` (reconciles Workflows into pods), `argo-server` (gRPC+HTTP API, hosted inside the `argo` CLI binary), `argoexec` (runs inside workflow pods), and a React UI. Go module `github.com/argoproj/argo-workflows/v4` (imports need `/v4`), vendored deps.\n\nThe repo must be checked out at `$GOPATH/src/github.com/argoproj/argo-workflows` or codegen breaks.\n\nPer-directory guidance lives in nested AGENTS.md files: `workflow/controller/AGENTS.md`, `ui/AGENTS.md`, `docs/AGENTS.md`. Read the relevant one before working in those areas — agents that only auto-load CLAUDE.md files must read these explicitly.\n\n## Commands\n\n- Build: `make cli` (`dist/argo`), `make controller`, `make dist/argoexec`.\n- Unit tests: `make test`. Single test: `KUBECONFIG=/dev/null go test -run TestFoo ./workflow/controller/`.\n- E2E: bring the local stack up first (`make start PROFILE=mysql`), then `make test-<tag>` where `<tag>` is the `//go:build` tag at the top of the test file. Single e2e test: `make TestArtifactServer` (any `Test*` name works as a make target).\n- Local dev stack (k3d + Tilt, everything in-cluster with hot reload), ports, profiles, debugging: see docs/running-locally.md.\n- Lint: `make lint` (golangci-lint `--fix` + UI lint — commit what `--fix` changes; CI runs `git diff --exit-code`).\n- Codegen: `make codegen -B`. Pre-PR: `make pre-commit -B` (= codegen, lint, docs).\n\n## Conventions\n\n- Commits and PRs: follow the checklist in docs/pull-requests.md (DCO sign-off + Conventional Commits enforced by the commit-msg hook, `make pre-commit -B`, feature files for `feat:`, tests required, AI declaration). A bot checks PR descriptions against `.github/pull_request_template.md` and drafts non-conforming PRs.\n- Logging is the repo's own `util/logging`, not logrus: level methods take ctx (`logger.Info(ctx, \"msg\")`); get the logger with `logging.RequireLoggerFromContext(ctx)`; tests use `logging.TestContext(t.Context())`.\n- Errors: `errors/` for coded, user-visible `ArgoError`s; `util/errors.IsTransientErr(ctx, err)` for retry decisions.\n- Every env var read via `os.Getenv`/`util/env` must be documented in docs/environment-variables.md — `make docs` fails on undocumented or stale entries.\n\n### Generated files — never hand-edit, regenerate with `make codegen -B`\n\nCI regenerates and fails on diff: `pkg/client/`, `*.pb.go`, `generated.proto`, `zz_generated.deepcopy.go`, `openapi_generated.go`, `*.swagger.json`, `api/openapi-spec/`, `api/jsonschema/`, `manifests/install*.yaml`, `manifests/quick-start-*.yaml`, CRDs under `manifests/base/crds/`, `**/mocks/` (mockery), `sdks/java/client`, `sdks/go` — plus several docs/ pages generated from Go source that carry no DO-NOT-EDIT header (see docs/AGENTS.md).\n\n`examples/` are validated by a unit test (a malformed example fails `make test`) and feed the generated `docs/fields.md`.\n\n## Architecture\n\nEntrypoints: `cmd/workflow-controller` → `workflow/controller/` (reconciliation; see workflow/controller/AGENTS.md); `cmd/argo` → `cmd/argo/commands/` (includes `argo server` → `server/`); `cmd/argoexec` → `workflow/executor/`.\n\nCross-cutting invariants: the executor never writes the Workflow object — outputs travel through `WorkflowTaskResult` CRs merged by the controller. Large node status is compressed and, if still too big, offloaded to SQL (`workflow/hydrator/`, `persist/sqldb/`) — any reader outside the controller must hydrate first.\n\n### Executor (`workflow/executor/`)\n\n`argoexec emissary` is PID 1 wrapping the user command in every container: writes `/var/run/argo/ctr/<name>/exitcode`, waits on ContainerSet dependencies, reads the template from `/var/run/argo/template`. `init`/`wait` (legacy pod layout) or `supervisor` (init-less beta) stage input artifacts before main and run the shared `PostMain` capture sequence after (script result → parameters/artifacts/logs → report outputs). Output capture deliberately uses a background context so termination doesn't lose outputs.\n\nA task's flow is a `Plan` of three phases (Prepare, Run, Collect) over named `Stage`s. Every stage is declared in `workflow/executor/stages.go` (the registry, enforced by a test) and plans are selected per template in `workflow/executor/plan.go`. New executor behaviour is a new stage or a new plan, not a new hand-written sequence in a command.\n\n### Server (`server/`)\n\n`server/apiserver` serves gRPC and grpc-gateway HTTP on one port; artifact up/download endpoints and the embedded UI (`ui/embed.go`) are mounted directly. Auth (`server/auth`) is chosen per-request from the Authorization header: `client` (caller's k8s token, their RBAC), `server` (server's service account), `sso` (OIDC claims mapped to service accounts via RBAC labels); gatekeeper interceptors stash per-request clients in ctx (`auth.GetWfClient(ctx)`). Workflow archive lives in `server/workflowarchive` over `persist/sqldb` (Postgres/MySQL).\n\n`pkg/apiclient` gives every CLI command four transports behind one interface: argo-server gRPC, HTTP1 fallback, offline (lint without a cluster), and direct-kube (no server — service logic runs in-process against the k8s API).\n\n### Shared layers\n\n`workflow/common` (label/annotation keys, container names, `/var/run/argo` paths), `workflow/validate` (lint/submit/controller all share it), `workflow/templateresolution` (resolves `templateRef` chains, caches in `Status.StoredTemplates`), `workflow/artifacts` (driver per storage backend: s3, gcs, azure, oss, hdfs, git, http, raw, plugin), `workflow/sync` (semaphores/mutexes, configmap- or database-backed), `workflow/util` (submit/retry/resubmit operations shared by CLI and server), `workflow/cron`.\n\n<!-- File: docs/AGENTS.md (Tokens: ~613 | Category: root-instruction) -->\n# Docs\n\n- Follow `doc-changes.md` and the Kubernetes style guide it links: active voice, present tense, \"you\" for the reader, no statements about the future, and one sentence per line, also in the sources of generated pages.\n- API kinds are plain text (Workflow, WorkflowTemplate); field names, values and commands go in back-ticks.\n- Describe only what the release does, and name versions explicitly (\"v4.2 or later\", not \"this release\"); open proposals and planned features stay out.\n- `upgrading.md` is replaced at each minor release, so don't link into or out of it.\n- `.features/` notes become release notes: write for users, not reviewers, and remember featuregen drops blank lines, so no indented code blocks, unindented lists or separate paragraphs.\n- Use Argo's terms only for what they name (\"task\" is a DAG task; likewise step, node, template, pod), and name the exact resource or tool (`workflow-controller-configmap` or a namespace's `artifact-repositories` configmap; `kubectl`).\n- Be exact about behavior, checked against the code: whether a limit is per call or in total, whether a failure errors the node, when a boolean is true, what breaks on rollback or without the RBAC, the replacement for a deprecated field.\n- Examples must work when copied as they are and follow the advice next to them; detail too long for a table cell goes in a section below the table that the row links to.\n- New pages must be added to the `nav:` in `properdocs.yml` — the build is strict and fails otherwise.\n- `make docs-serve` builds and serves on :8000 with the same checks as CI; `make docs` runs spellcheck, markdownlint, and the env-var documentation check.\n- Generated pages — edit the source, not the markdown, then `make codegen -B`: `fields.md` (from swagger + `examples/`), `cli/` (from Cobra), `workflow-controller-configmap.md` (from doc comments on structs in `config/`), `metrics.md`/`tracing.md` (from `util/telemetry/builder/values.yaml`), `database-migrations.md` (from `persist/sqldb/migrate.go` and `util/sync/db/migrate.go`), `variable-flow/variables.md` (from `util/variables/`), `executor_swagger.md` (from doc comments in `pkg/plugins/executor/`), `docs/README.md` (copied from the root README); when rewording, also update the sample configmaps, `.features/` notes and code comments that repeat the text.\n- `go-sdk-guide.md` is half-generated: prose is hand-edited, but code blocks between `<embed>` markers are injected from `sdks/go` sources by embeddoc — edit the source, not the block.\n\n<!-- File: ui/AGENTS.md (Tokens: ~230 | Category: root-instruction) -->\n# UI\n\nReact 18 + TypeScript, webpack, rxjs observables (no Redux), `argo-ui` component library pinned to a git SHA. Feature areas map 1:1 to `src/` directories; API clients live in `src/shared/services`. `src/shared/pod-name.ts` must stay in sync with the controller's pod naming.\n\n- Dev server: `yarn start` (:8080) proxies API and artifact routes to argo-server on :2746 (usually from `make start`).\n- Tests: `yarn test` (jest). E2E: `make test-ui-e2e` (playwright; needs `make start AUTH_MODE=client`; first run: `yarn playwright install --with-deps chromium`).\n- Lint: `yarn lint` (eslint `--fix` on `src` and `e2e`, then `tsc --noEmit` for both the app and `e2e/tsconfig.json`) — commit what `--fix` changes.\n- The production bundle is embedded into the server binary via `ui/embed.go`.\n\n<!-- File: CLAUDE.md (Tokens: ~39 | Category: claude-rule) -->\n# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\nThe master record is @AGENTS.md — follow it.\n\n<!-- File: docs/architecture.md (Tokens: ~913 | Category: project-spec) -->\n# Architecture\n\n## Diagram\n\nThe following diagram shows the components of the Argo Workflows architecture. There are two Deployments: Workflow Controller and Argo Server. The former does all of the reconciling, and the latter serves the API. Note that the Controller can be used stand alone.\n\nThe reconciliation code for the `WorkflowController` can be found in [`workflow/controller/controller.go`](https://github.com/argoproj/argo-workflows/blob/main/workflow/controller/controller.go). The Argo Server opens up an HTTP(S) listener at [`server/apiserver/argoserver.go`](https://github.com/argoproj/argo-workflows/blob/main/server/apiserver/argoserver.go).\n\n![diagram](assets/diagram.png)\n\n---\n\n## Argo Workflow Overview\n\nThe diagram below provides a little more detail as far as namespaces. The Workflow Controller and Argo Server both run in the `argo` namespace. Assuming Argo Workflows was installed as a Cluster Install or as a Managed Namespace Install (described [here](installation.md)), the Workflows and the Pods generated from them run in a separate namespace.\n\nThe internals of a Pod are also shown. Each Step and each DAG Task cause a Pod to be generated, and each of these is composed of 3 containers:\n\n- `main` container runs the Image that the user indicated, where the `argoexec` utility is volume mounted and serves as the main command which calls the configured Command as a sub-process\n- `init` container is an `InitContainer`, fetching artifacts and parameters and making them available to the `main` container\n- `wait` container performs tasks that are needed for clean up, including saving off parameters and artifacts\n\nLook in [`cmd/argoexec`](https://github.com/argoproj/argo-workflows/blob/main/cmd/argoexec) for this code.\n\n### Init-less pod layout (opt-in, beta)\n\nWhen the controller is configured with `initlessPod.enabled: true`, workflow pods use an alternate two-container layout with zero init containers. The `argoexec` binary is delivered into `main` via a Kubernetes image volume ([KEP-4639](https://kep.k8s.io/4639) — Beta in 1.33 behind a feature gate, GA in 1.36), and a new `supervisor` container takes over both the pre-main responsibilities of the legacy init container (template write, script staging, input artifact download) and the post-main responsibilities of the legacy `wait` container (observe main, capture outputs, save artifacts and logs). Artifact plugins run as regular sidecars rather than as init containers, and `supervisor` drives each sidecar for both Load (pre-main) and Save (post-main). See [Init-less Pod Layout](initless-pod.md) for details.\n\n![diagram](assets/overview.jpeg)\n\n---\n\n## Workflow controller architecture\n\nThe following diagram shows the process for reconciliation, whereby a set of worker goroutines process the Workflows which have been added to a Workflow queue based on adds and updates to Workflows and Workflow Pods. Note that in addition to the Informers shown, there are Informers for the other CRDs that Argo Workflows uses as well. You can find this code in [`workflow/controller/controller.go`](https://github.com/argoproj/argo-workflows/blob/main/workflow/controller/controller.go). Note that the controller only ever processes a single Workflow at a time.\n\n![diagram](assets/workflow-controller-queue.png)\n\n---\n\n## Various configurations for Argo UI and Argo Server\n\nThe top diagram below shows what happens when you run \"make start\" locally. This runs a React application (`Webpack` HTTP server) locally which serves the `index.html` and typescript files from port 8080. From the typescript code there are calls made to the back end API (Argo Server) at port 2746. The `Webpack` HTTP server is configured for hot reload, meaning the UI will update automatically based on local code changes.\n\nThe second diagram is an alternative approach for rare occasions that the React files are broken and you're doing local development. In this case, everything is served from the Argo Server at port 2746.\n\nThe third diagram shows how things are configured for a Kubernetes environment. It is similar to the second diagram in that the Argo Server hosts everything for the UI.\n\n![diagram](assets/argo-server-ui-configurations.png)\n</yakaai_skills>"}