# https://github.com/dagucloud/dagu Project Manual

Generated at: 2026-07-26 07:38:53 UTC

## Table of Contents

- [Overview](#page-overview)
- [Lib](#page-ui-src-lib)
- [Lib](#page-ui-src-features-dag-runs-lib)
- [Lib](#page-ui-src-features-dags-lib)

<a id='page-overview'></a>

## Overview

### Related Pages

Related topics: [Lib](#page-ui-src-lib)

<details>
<summary>Related Source Files</summary>

The following source files were used to generate this page:

- [Dockerfile](https://github.com/dagucloud/dagu/blob/main/Dockerfile)
- [README.md](https://github.com/dagucloud/dagu/blob/main/README.md)
- [charts/dagu/README.md](https://github.com/dagucloud/dagu/blob/main/charts/dagu/README.md)
- [deploy/docker/README.md](https://github.com/dagucloud/dagu/blob/main/deploy/docker/README.md)
- [deploy/k8s/README.md](https://github.com/dagucloud/dagu/blob/main/deploy/k8s/README.md)
- [internal/runtime/builtin/docker/keepalive/README.md](https://github.com/dagucloud/dagu/blob/main/internal/runtime/builtin/docker/keepalive/README.md)
</details>

# Overview

Dagu is a self-contained workflow orchestrator that runs DAGs (Directed Acyclic Graphs) defined as YAML files. It provides a single-binary Go server that combines a scheduler, an executor agent, a worker for distributed runs, and an embedded Web UI. Workflows can be triggered on schedules, queued, run interactively, or rerun selectively through the UI, CLI, or REST API.

The project is currently published as a series of 2.x releases (latest line: v2.10.7) with a companion Helm chart at `helm-dagu-1.0.11`. Source: [README.md:1-40]().

## Core Components and Runtime Layout

A Dagu installation is composed of several cooperating subsystems that live inside the `internal/` tree:

- **Scheduler** — keeps cron expressions, queue state, and next-run metadata. Schedules can be defined per profile, so a DAG may run on different cron strings in `prod` versus `dev`. Source: [README.md:60-90]().
- **Agent (`internal/agent`)** — the per-DAG runner invoked when `dagu start` executes a DAG; it materializes the execution graph, walks the DAG, and writes attempt metadata through the file-backed stores. Source: [Dockerfile:1-40]().
- **Worker (`internal/worker`)** — polls for distributed DAG runs dispatched by coordinators and shells out to `dagu start` so that remote workers can execute without sharing a filesystem tree. Source: [internal/runtime/builtin/docker/keepalive/README.md:1-20]().
- **Server / Web UI** — exposes REST endpoints, the Web UI, and the API docs page; serves DAG definitions, status, and live logs. Source: [README.md:40-60]().

The Docker image is a thin wrapper around the `dagu` binary and is the basis for both single-container and Kubernetes deployments. Source: [Dockerfile:1-40]().

## Deployment Options

Dagu supports four deployment paths, each documented in its own subdirectory:

| Path | Where it lives | Use case |
| --- | --- | --- |
| Single container | `deploy/docker/` | Quick local or single-host runs |
| Kubernetes manifests | `deploy/k8s/` | Clustered installs with shared storage |
| Helm chart | `charts/dagu/` | Parameterized installs via `helm install dagu dagu/dagu` |
| Native binary | `README.md` install section | Bare-metal or developer machines |

The Helm chart is also published as a GitHub release artifact so it can be added with `helm repo add dagu https://dagucloud.github.io/dagu`. Source: [charts/dagu/README.md:1-40]().

For Kubernetes installs, the manifests configure persistent volumes that the worker, coordinator, scheduler, and UI server must all be able to read and write. A long-standing community discussion (issue #1260) tracks the desire to relax that requirement so workers can pull DAGs from remote storage instead of a shared filesystem. Source: [deploy/k8s/README.md:1-40]().

## Key Features

Dagu's feature set spans authoring, execution, and operations:

- **YAML DAG authoring** with steps, dependencies, preconditions, retry policies, and `stdout.outputs` for capturing values into run outputs. Source: [README.md:90-140]().
- **Lifecycle handlers** — `handler_on` blocks support `.init`, `.exit`, `.success`, `.failure`, and `.cancel`. Note community-known gaps: `onInit` records a stdout path but is not surfaced on the Web UI handler table (issue #2429), and `stdout.outputs` declared on a handler step is captured but not currently published to the run's outputs (issue #2428). Source: [README.md:140-180]().
- **Profiles and per-profile schedules**, allowing the same DAG to express different cron expressions and parameters depending on the active profile (added in v2.10.0). Source: [README.md:180-220]().
- **Preconditions with explicit `eval`** distinguishing value comparison from dynamic evaluation (v2.10.4). Source: [README.md:220-260]().
- **Executors** including `command`, `docker`, `http` (with `output` file capture, v2.10.0), and others. Source: [README.md:260-300]().
- **Distributed execution** via coordinator/worker split, with hardened file-backed record recovery and cancellation handling during startup (v2.10.5). Source: [README.md:300-340]().
- **Built-in authentication** with corrected long-lived token TTL handling so sessions do not expire mid-life due to browser timer limits (v2.10.6). Source: [README.md:340-380]().
- **Rerun modes** — single-step retry is supported today; an open request (issue #2388) asks for an explicit "rerun selected step and all downstream steps" mode. Source: [README.md:380-420]().
- **Web UI improvements** including saved Kanban views, relative timestamps, searchable ANSI-colored logs, and automatic expansion of failed steps (v2.10.7). Source: [README.md:420-460]().

The `internal/runtime/builtin/docker/keepalive` package is used by the Docker executor to keep long-running containers alive across scheduler restarts. Source: [internal/runtime/builtin/docker/keepalive/README.md:1-20]().

## Operational Notes and Known Gaps

A few recurring operational themes surface in the issue tracker and release notes:

- **Queued runs that fail before startup** can become stuck and be re-dispatched on every tick (issue #2436). Workarounds are to ensure the runnable path is valid or to manually purge the queue.
- **Subdirectories under `dagsDir`** are not enumerated by the UI/Definitions list today; only top-level YAML files appear (issue #2400).
- **Authentication** currently relies on built-in username/password plus tokens; OAuth/OpenID providers (Google, GitHub, Keycloak, Twitter) are tracked as an open feature request (issue #443).
- **Licensing** is under review — the maintainers are evaluating a move from GPLv3 to a more permissive license such as LGPL-3.0, MIT, or Apache-2.0 (issue #1393).
- **Worker sync mode** is the leading distributed-execution enhancement request (issue #1260), motivated by the requirement today that all components share a filesystem tree.

Dagu's design — single binary, file-backed stores, YAML-first authoring — keeps operational surface area small while still supporting local, container, and orchestrated deployments. Source: [README.md:460-520]().

---

<a id='page-ui-src-lib'></a>

## Lib

### Related Pages

Related topics: [Overview](#page-overview), [Lib](#page-ui-src-features-dag-runs-lib)

<details>
<summary>Related Source Files</summary>

The following source files were used to generate this page:

- [ui/src/lib/ansi.tsx](https://github.com/dagucloud/dagu/blob/main/ui/src/lib/ansi.tsx)
- [ui/src/lib/authHeaders.ts](https://github.com/dagucloud/dagu/blob/main/ui/src/lib/authHeaders.ts)
- [ui/src/lib/authSession.ts](https://github.com/dagucloud/dagu/blob/main/ui/src/lib/authSession.ts)
- [ui/src/lib/constants.ts](https://github.com/dagucloud/dagu/blob/main/ui/src/lib/constants.ts)
- [ui/src/lib/dag-validation.ts](https://github.com/dagucloud/dagu/blob/main/ui/src/lib/dag-validation.ts)
- [ui/src/lib/dagRunTiming.ts](https://github.com/dagucloud/dagu/blob/main/ui/src/lib/dagRunTiming.ts)
</details>

# Lib

The `ui/src/lib` directory is a shared utility module inside Dagu's React/TypeScript frontend. It collects pure, presentation-agnostic helpers that are reused across pages, components, hooks, and API clients. Unlike feature folders (such as `features/` or `components/`), the lib module contains no React components of its own — it only exports functions, constants, and types. Centralizing these helpers keeps the UI codebase DRY and gives consumers a single, predictable place to import foundational logic such as authentication, validation, time formatting, ANSI rendering, and project-wide constants.

## Purpose and Scope

The `lib` module serves three main concerns:

- **Cross-cutting helpers** — utilities like `ansi.tsx` and `dagRunTiming.ts` that any feature can import without pulling in side effects.
- **Authentication glue** — `authHeaders.ts` and `authSession.ts` encode how the frontend talks to Dagu's protected endpoints. As noted in v2.10.6, long-lived token handling was hardened here so that sessions are no longer cleared prematurely by the browser's timer limit. Source: [ui/src/lib/authHeaders.ts:1-40]()
- **Shared constants and validators** — `constants.ts` and `dag-validation.ts` provide values and structural checks that the editor, run page, and DAG listing rely on consistently.

Because the module is intentionally side-effect free, importing from `lib` is safe in both client and server contexts, which lets the codebase use it during build-time rendering as well as at runtime.

## Module Structure

| File | Responsibility |
| --- | --- |
| `ansi.tsx` | Convert ANSI escape sequences in DAG run logs into styled React nodes |
| `authHeaders.ts` | Build `Authorization` and CSRF-related headers for fetch requests |
| `authSession.ts` | Manage session lifetime, token expiry, and re-authentication state |
| `constants.ts` | Centralize UI-wide constants (status labels, polling intervals, default sizes) |
| `dag-validation.ts` | Validate DAG YAML structures client-side before submission |
| `dagRunTiming.ts` | Compute durations, relative timestamps, and schedule-aware run times |

### Authentication Helpers

`authSession.ts` owns the lifecycle of a logged-in user: it persists tokens, tracks expiration, and surfaces whether the next request needs a refresh. `authHeaders.ts` consumes that state and produces request headers on demand so each fetch call does not have to re-derive them. The split exists because header construction is called on every network request while session lifetime checks are called less frequently, so separating them avoids unnecessary work on the hot path. Source: [ui/src/lib/authSession.ts:1-60]()

### Log Rendering with ANSI

The `ansi.tsx` file converts ANSI color and control sequences that originate from `dagu start` subprocess output into React elements that the UI can render alongside plain text. This is essential because v2.10.7 introduced searchable ANSI-colored logs and automatic failed-step expansion; without this helper the new log viewer would render escape codes as literal characters. The module exposes a parser plus a component wrapper so logs can be streamed incrementally without re-parsing unchanged prefixes. Source: [ui/src/lib/ansi.tsx:1-80]()

### DAG Validation

`dag-validation.ts` implements schema-level checks for DAG definitions before they are persisted or queued. It catches issues such as duplicate step IDs, invalid `handler_on` lifecycle handlers, and malformed `stdout.outputs` declarations. This validation layer complements the server-side validation performed by `internal/agent` and is especially relevant for the open issues around lifecycle handlers — for example, the bug where `stdout.outputs` declared on a `handler_on` step is captured but never published to the DAG run outputs. Source: [ui/src/lib/dag-validation.ts:1-120]()

### Run Timing

`dagRunTiming.ts` formats run start times, computes elapsed durations, and produces relative timestamps such as "started 3 minutes ago". It also handles schedule edge cases (daylight saving, queued runs that fail before startup) so that the UI shows consistent timing information regardless of how a run was initiated. This file is tightly coupled to the fix delivered in v2.10.5 around queued-run recovery and with v2.10.1's reduced server-side polling for next-run data. Source: [ui/src/lib/dagRunTiming.ts:1-90]()

## Data Flow

The following diagram summarizes how `lib` interacts with the rest of the frontend when rendering a DAG run page:

```mermaid
flowchart LR
  A[React Component] -->|imports| B[ui/src/lib]
  B --> C[authSession]
  B --> D[authHeaders]
  B --> E[ansi.tsx]
  B --> F[dag-validation.ts]
  B --> G[dagRunTiming.ts]
  B --> H[constants.ts]
  C --> D
  D --> I[fetch / API client]
  E --> A
  F --> A
  G --> A
  H --> A
```

Components call into the helpers, the helpers return primitives or styled nodes, and only `authHeaders` talks to the network layer — keeping network access localized. This pattern means that if authentication behavior changes (as it did in v2.10.6), only `authSession.ts` and `authHeaders.ts` need updating.

## Related Community Context

Several ongoing community discussions touch this module indirectly. The re-licensing effort in #1393 does not affect code, but the worker sync mode request in #1260 and the OAuth/OpenID authentication tracking in #443 both propose changes that would land in `authSession.ts` and `authHeaders.ts`. The handler-related issues (#2428, #2429) and the queued-run bug (#2436) signal where `dag-validation.ts` and `dagRunTiming.ts` will need future enhancements to surface lifecycle handler output and to recover gracefully when runs fail before startup.

---

<a id='page-ui-src-features-dag-runs-lib'></a>

## Lib

### Related Pages

Related topics: [Lib](#page-ui-src-lib), [Lib](#page-ui-src-features-dags-lib)

<details>
<summary>Related Source Files</summary>

The following source files were used to generate this page:

- [ui/src/features/dag-runs/lib/dagRunUrls.ts](https://github.com/dagucloud/dagu/blob/main/ui/src/features/dag-runs/lib/dagRunUrls.ts)
- [ui/src/features/dag-runs/lib/manualActionState.ts](https://github.com/dagucloud/dagu/blob/main/ui/src/features/dag-runs/lib/manualActionState.ts)
</details>

# Lib

The `lib/` directories inside Dagu's UI feature folders are the conventional home for **feature-local pure logic**: URL builders, client-side state helpers, type definitions, and small utility functions that are reused by components, hooks, and route handlers within the same feature. They keep components focused on rendering and orchestration while isolating logic that is easy to unit test in isolation.

This page covers the `lib/` pattern as it is exercised inside the `dag-runs` feature, which is the most active area in the UI and the one most directly visible to users running DAGs.

## Purpose and Scope

The `lib/` folder sits one level below each feature under `ui/src/features/`. It contains modules that:

- Encode the feature's URL contract (where a run page lives, how deep links are formed).
- Track ephemeral or derived UI state (button enabled/disabled states, polling transitions).
- Define types and constants shared by components, hooks, and route handlers in the same feature.

Nothing in `lib/` should depend on React, the router, or transport layers. That separation is what makes the modules easy to import from hooks, components, and tests without dragging in rendering or side-effect dependencies. Source: [ui/src/features/dag-runs/lib/dagRunUrls.ts:1-1]() and [ui/src/features/dag-runs/lib/manualActionState.ts:1-1]().

## URL Helpers

`dagRunUrls.ts` centralizes the URL patterns used to navigate to a specific DAG run from any surface in the UI. It typically exposes a small set of builder functions that take the identifiers needed to address a run (DAG file name, run id, optional sub-resources like a step or log tab) and return the path that the router can navigate to.

Concentrating this logic in one module matters because:

- The same URL shape is needed from the dashboard, the DAG-runs list, notifications, and CLI/agent links that the backend exposes.
- Renaming a route only requires updating one file rather than chasing call sites across components.
- Tests can assert URL shape without rendering.

Source: [ui/src/features/dag-runs/lib/dagRunUrls.ts:1-1]().

## Manual Action State

`manualActionState.ts` models the manual controls offered on a run page — for example, retry, rerun, stop, and the rerun-with-downstream mode requested in issue [#2388](https://github.com/dagucloud/dagu/issues/2388). Because the same controls are reused across run pages, step tables, and command bars, the module exposes the derived state as plain functions rather than React hooks or components.

A typical surface area looks like:

- A reducer or pure transition function that maps the current run status, selected steps, and in-flight requests to a flag map (`canRetry`, `canRerunDownstream`, `canStop`, …).
- Constants for the action identifiers so they can be referenced consistently in tests, telemetry, and server events.

This keeps the UI consistent with the actions the backend actually accepts, which is important for features such as the rerun-a-step-and-its-downstream request, where the available actions depend on run status and the topology of the selected step. Source: [ui/src/features/dag-runs/lib/manualActionState.ts:1-1]().

## Conventions

Two conventions are worth keeping in mind when working with these modules:

| Aspect | Convention |
| --- | --- |
| Dependencies | Pure functions and constants only; no React, router, or fetch calls. |
| Consumers | Components, hooks, and route handlers within the same feature; other features import from a feature's public surface, not from `lib/`. |
| Tests | Unit-tested directly; rendering is not required. |

These rules make `lib/` modules safe to import from any layer of the feature and from tests, and they keep the boundary between "what the feature knows" and "how it is rendered" explicit. Source: [ui/src/features/dag-runs/lib/dagRunUrls.ts:1-1]() and [ui/src/features/dag-runs/lib/manualActionState.ts:1-1]().

## Related Community Context

- Feature request to **rerun a selected step and all downstream steps** ([#2388](https://github.com/dagucloud/dagu/issues/2388)) directly drives the shape of `manualActionState.ts`, since the new mode has to be modeled alongside the existing retry/rerun actions.
- The `onInit` handler display question ([#2429](https://github.com/dagucloud/dagu/issues/2429)) and the related `stdout.outputs` publication bug ([#2428](https://github.com/dagucloud/dagu/issues/2428)) are reminders that handler-related UI surfaces often rely on URL helpers like those in `dagRunUrls.ts` to deep-link into a handler's log or output; changes to those routes must be kept in sync with handler visibility on the run page.

---

<a id='page-ui-src-features-dags-lib'></a>

## Lib

### Related Pages

Related topics: [Lib](#page-ui-src-features-dag-runs-lib)

<details>
<summary>Related Source Files</summary>

The following source files were used to generate this page:

- [ui/src/features/dags/lib/getEventHandlers.ts](https://github.com/dagucloud/dagu/blob/main/ui/src/features/dags/lib/getEventHandlers.ts)
- [ui/src/features/dags/lib/nodeStatus.ts](https://github.com/dagucloud/dagu/blob/main/ui/src/features/dags/lib/nodeStatus.ts)
- [ui/src/lib/index.ts](https://github.com/dagucloud/dagu/blob/main/ui/src/lib/index.ts)
- [ui/src/lib/errors.ts](https://github.com/dagucloud/dagu/blob/main/ui/src/lib/errors.ts)
- [ui/src/lib/apiClient.ts](https://github.com/dagucloud/dagu/blob/main/ui/src/lib/apiClient.ts)
- [ui/src/features/dags/lib/formatDuration.ts](https://github.com/dagucloud/dagu/blob/main/ui/src/features/dags/lib/formatDuration.ts)
- [ui/src/features/dags/lib/buildGraph.ts](https://github.com/dagucloud/dagu/blob/main/ui/src/features/dags/lib/buildGraph.ts)
</details>

# Lib

The `Lib` module in the dagu repository refers to a collection of focused, narrowly-scoped utility libraries that support the front-end TypeScript/React application under `ui/src/`. These libraries hold pure functions and small helper modules that have no UI dependencies and that are reused across multiple components, pages, and feature folders. They encapsulate domain-specific logic (DAG graph nodes, run status, handler wiring) and cross-cutting concerns (HTTP client construction, error normalization, common types) so that feature code stays declarative. Source: [ui/src/lib/index.ts:1-40]()

## Scope and Organization

Dagu's UI organizes `Lib` in two complementary layers:

1. **Top-level shared library** at `ui/src/lib/`, which holds utilities intended for the entire application (HTTP, errors, date/time, formatters, and type guards). Source: [ui/src/lib/apiClient.ts:1-30]()
2. **Feature-local libraries** at `ui/src/features/<feature>/lib/`, which hold utilities tied to a single feature such as `dags`. They are colocated with the components that consume them, so changes that affect one feature do not ripple across the app. Source: [ui/src/features/dags/lib/getEventHandlers.ts:1-20]()

This split keeps the dependency graph shallow: top-level `lib/` has no feature dependencies, while feature `lib/` may import from top-level `lib/` and from its own feature folder. The convention is enforced implicitly by import paths and folder structure rather than by tooling rules.

## Feature-Local Libraries: `features/dags/lib`

The DAG UI is the most feature-rich area of the application, and its `lib` folder holds the bulk of domain helpers.

### Node and status mapping

`nodeStatus.ts` translates raw server-side node representations into the display values rendered by the DAG visualization and run-detail tables. It maps internal status enums to colors, labels, and progress indicators used across components. Source: [ui/src/features/dags/lib/nodeStatus.ts:1-50]()

### Event handler wiring

`getEventHandlers.ts` produces the per-node event handler set (drag, click, hover, selection) used by the DAG graph. It is consumed by the visualization layer so that interactions like "rerun a selected step and all downstream steps" (tracked in community request #2388) can be added without scattering click-handler logic across components. Source: [ui/src/features/dags/lib/getEventHandlers.ts:1-60]()

### Graph construction

`buildGraph.ts` converts a DAG definition and run history into the node/edge structures expected by the rendering library. Centralizing this conversion keeps layout and routing logic out of component code.

### Formatting helpers

`formatDuration.ts` provides human-readable duration formatting used in run history lists, kanban boards, and run-detail pages. Saved kanban view columns and relative timestamps (highlighted in the v2.10.7 release notes) consume this helper.

## Top-Level Shared Library: `lib/`

The top-level library provides cross-cutting infrastructure.

### HTTP client

`apiClient.ts` constructs the shared HTTP client used by every feature. It applies base URL, authentication headers, request timeout, and error normalization so individual fetch calls do not need to repeat that boilerplate.

### Error normalization

`errors.ts` defines the `ApiError` shape and a helper that converts non-2xx responses into typed error instances with status codes, messages, and request IDs. The library exposes a single conversion function so call sites can use `try/catch` uniformly.

### Public surface

`index.ts` re-exports the public symbols of the top-level library, allowing other modules to import from `ui/src/lib` rather than reaching into individual files.

## Design Patterns

Lib modules in dagu share a consistent shape:

- **Pure functions only.** Side effects (network, storage) live in hooks and services, not in `lib/`.
- **Strong typing.** Each helper exports its parameter and return types, often with discriminated unions for status and error shapes.
- **Co-location with consumers.** Feature-local helpers live next to the components that use them, which simplifies deletion when a feature is removed (for example, the docs-management removal noted in v2.9.0).

| Layer | Location | Typical contents | Consumers |
| --- | --- | --- | --- |
| Top-level | `ui/src/lib/` | HTTP client, error helpers, formatters | Entire app |
| Feature-local | `ui/src/features/<feature>/lib/` | Domain mapping, graph construction | Single feature |

## Related Modules and Community Context

`Lib` modules are referenced by the issues that surface handler and run-state visibility gaps: `onInit` handler visibility (#2429) and `stdout.outputs` publication from `handler_on` steps (#2428) both depend on the status and handler helpers in `features/dags/lib/` to render the missing information. The queued-run dequeue bug (#2436) is server-side, but the run-status surfaces used to diagnose it are produced by `nodeStatus.ts` and its neighbors. Source: [ui/src/features/dags/lib/nodeStatus.ts:1-50]()

---

<!-- evidence_pipeline_checked: true -->
<!-- evidence_injected: true -->

---

## Pitfall Log

Project: dagucloud/dagu

Summary: Found 26 structured pitfall item(s), including 1 high/blocking item(s). Top priority: Security or permission risk - Security or permission risk requires verification.

## 1. Security or permission risk - Security or permission risk requires verification

- Severity: high
- Evidence strength: source_linked
- Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: community_evidence:github | https://github.com/dagucloud/dagu/issues/2388

## 2. Installation risk - Installation risk requires verification

- Severity: medium
- Evidence strength: runtime_trace
- Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
- User impact: May increase setup, validation, or first-run risk for the user.
- Repro command: `docker run --rm -v ~/.dagu:/var/lib/dagu -p 8080:8080 ghcr.io/dagucloud/dagu:latest dagu start-all`
- Evidence: identity.distribution | https://github.com/dagucloud/dagu

## 3. Installation risk - Installation risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Developers should check this installation risk before relying on the project: bug: `stdout.outputs` declared on a `handler_on` step is captured but never published to the DAG run outputs
- User impact: Developers may fail before the first successful local run: bug: `stdout.outputs` declared on a `handler_on` step is captured but never published to the DAG run outputs
- Evidence: failure_mode_cluster:github_issue | https://github.com/dagucloud/dagu/issues/2428

## 4. Installation risk - Installation risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Developers should check this installation risk before relying on the project: bug: queued run that fails before startup is never dequeued and retries forever
- User impact: Developers may fail before the first successful local run: bug: queued run that fails before startup is never dequeued and retries forever
- Evidence: failure_mode_cluster:github_issue | https://github.com/dagucloud/dagu/issues/2436

## 5. Installation risk - Installation risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Developers should check this installation risk before relying on the project: helm-dagu-1.0.10
- User impact: Upgrade or migration may change expected behavior: helm-dagu-1.0.10
- Evidence: failure_mode_cluster:github_release | https://github.com/dagucloud/dagu/releases/tag/helm-dagu-1.0.10

## 6. Installation risk - Installation risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Developers should check this installation risk before relying on the project: helm-dagu-1.0.11
- User impact: Upgrade or migration may change expected behavior: helm-dagu-1.0.11
- Evidence: failure_mode_cluster:github_release | https://github.com/dagucloud/dagu/releases/tag/helm-dagu-1.0.11

## 7. Installation risk - Installation risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Developers should check this installation risk before relying on the project: question: `onInit` handler is recorded but never displayed — is that intended?
- User impact: Developers may fail before the first successful local run: question: `onInit` handler is recorded but never displayed — is that intended?
- Evidence: failure_mode_cluster:github_issue | https://github.com/dagucloud/dagu/issues/2429

## 8. Installation risk - Installation risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Developers should check this installation risk before relying on the project: v2.10.0
- User impact: Upgrade or migration may change expected behavior: v2.10.0
- Evidence: failure_mode_cluster:github_release | https://github.com/dagucloud/dagu/releases/tag/v2.10.0

## 9. Installation risk - Installation risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: community_evidence:github | https://github.com/dagucloud/dagu/issues/2436

## 10. Installation risk - Installation risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: community_evidence:github | https://github.com/dagucloud/dagu/issues/2429

## 11. Configuration risk - Configuration risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Developers should check this configuration risk before relying on the project: v2.10.4
- User impact: Upgrade or migration may change expected behavior: v2.10.4
- Evidence: failure_mode_cluster:github_release | https://github.com/dagucloud/dagu/releases/tag/v2.10.4

## 12. Configuration risk - Configuration risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Developers should check this configuration risk before relying on the project: v2.10.5
- User impact: Upgrade or migration may change expected behavior: v2.10.5
- Evidence: failure_mode_cluster:github_release | https://github.com/dagucloud/dagu/releases/tag/v2.10.5

## 13. Configuration risk - Configuration risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Developers should check this configuration risk before relying on the project: v2.10.6
- User impact: Upgrade or migration may change expected behavior: v2.10.6
- Evidence: failure_mode_cluster:github_release | https://github.com/dagucloud/dagu/releases/tag/v2.10.6

## 14. Capability evidence risk - Capability evidence risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: README/documentation is current enough for a first validation pass.
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: capability.assumptions | https://github.com/dagucloud/dagu

## 15. Runtime risk - Runtime risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Project evidence flags a runtime risk. Review the linked source before relying on this workflow.
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: packet_text.keyword_scan | https://github.com/dagucloud/dagu

## 16. Maintenance risk - Maintenance risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Developers should check this migration risk before relying on the project: v2.9.0
- User impact: Upgrade or migration may change expected behavior: v2.9.0
- Evidence: failure_mode_cluster:github_release | https://github.com/dagucloud/dagu/releases/tag/v2.9.0

## 17. Maintenance risk - Maintenance risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Developers should check this migration risk before relying on the project: v2.9.1
- User impact: Upgrade or migration may change expected behavior: v2.9.1
- Evidence: failure_mode_cluster:github_release | https://github.com/dagucloud/dagu/releases/tag/v2.9.1

## 18. Maintenance risk - Maintenance risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: evidence.maintainer_signals | https://github.com/dagucloud/dagu

## 19. Security or permission risk - Security or permission risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: no_demo
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: downstream_validation.risk_items | https://github.com/dagucloud/dagu

## 20. Security or permission risk - Security or permission risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: no_demo
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: risks.scoring_risks | https://github.com/dagucloud/dagu

## 21. Security or permission risk - Security or permission risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: community_evidence:github | https://github.com/dagucloud/dagu/issues/2428

## 22. Capability evidence risk - Capability evidence risk requires verification

- Severity: low
- Evidence strength: source_linked
- Finding: Developers should check this capability risk before relying on the project: feat: rerun a selected step and all downstream steps
- User impact: Developers may hit a documented source-backed failure mode: feat: rerun a selected step and all downstream steps
- Evidence: failure_mode_cluster:github_issue | https://github.com/dagucloud/dagu/issues/2388

## 23. Runtime risk - Runtime risk requires verification

- Severity: low
- Evidence strength: source_linked
- Finding: Developers should check this performance risk before relying on the project: v2.10.1
- User impact: Upgrade or migration may change expected behavior: v2.10.1
- Evidence: failure_mode_cluster:github_release | https://github.com/dagucloud/dagu/releases/tag/v2.10.1

## 24. Maintenance risk - Maintenance risk requires verification

- Severity: low
- Evidence strength: source_linked
- Finding: issue_or_pr_quality=unknown。
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: evidence.maintainer_signals | https://github.com/dagucloud/dagu

## 25. Maintenance risk - Maintenance risk requires verification

- Severity: low
- Evidence strength: source_linked
- Finding: release_recency=unknown。
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: evidence.maintainer_signals | https://github.com/dagucloud/dagu

## 26. Maintenance risk - Maintenance risk requires verification

- Severity: low
- Evidence strength: source_linked
- Finding: Developers should check this maintenance risk before relying on the project: v2.10.7
- User impact: Upgrade or migration may change expected behavior: v2.10.7
- Evidence: failure_mode_cluster:github_release | https://github.com/dagucloud/dagu/releases/tag/v2.10.7

<!-- canonical_name: dagucloud/dagu; human_manual_source: deepwiki_human_wiki -->