GO — Healthy across the board

• Last commit 2d ago
• 10 active contributors
• Distributed ownership (top contributor 40% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

DORA is a 100% Rust middleware framework for building real-time robotics and AI applications using declarative dataflow pipelines (directed acyclic graphs). It provides 10-17x faster latency than ROS2 Python through zero-copy shared memory IPC, Zenoh SHM data plane integration, and Apache Arrow columnar memory format, enabling low-latency distributed robotics applications with Python, Rust, and C++ node support. Monorepo organized as: binaries/ (cli, coordinator, daemon, runtime), apis/ (C/C++/Python/Rust node and operator SDKs), libraries/ (core, message, arrow-convert, recording, telemetry extensions), and examples/. The YAML dataflow spec (docs/yaml-spec.md referenced in README) is the declarative contract; the Rust daemon and coordinator orchestrate graph execution; language bindings (apis/python/node, apis/rust/node) allow heterogeneous pipelines.

Roboticists and AI engineers building real-time autonomous systems (drones, robots, computer vision pipelines) who need sub-millisecond latency, cross-language composability, and distributed deployment without ROS2's Python performance overhead. Contributors range from systems engineers working on the Rust core (binaries/coordinator, binaries/daemon, binaries/runtime) to application developers writing YAML dataflow configs and Python/Rust nodes.

Actively developed and production-ready: the project has comprehensive CI/CD (.github/workflows/ shows cargo-release, pip-release, docker-image, nightly builds), dense test coverage evidenced by cargo test infrastructure, and clear monorepo structure across multiple stable language bindings (Rust, Python, C/C++). Regular commits and agentic engineering practices (CLAUDE.md indicates AI-driven development) show ongoing maintenance.

Low risk for core functionality but high complexity: the Rust-heavy codebase (2.5MB) requires systems-level expertise, and distributed dataflow introduces debugging difficulty across machines. No visible single-maintainer bottleneck given organizational structure (dora-rs GitHub org), but users should monitor breaking changes across major versions since the Arrow integration and Zenoh data plane are tightly coupled.

Active development across CI/CD infrastructure (workflows for cargo-release, pip-release, docker-image, nightly testing), language API expansion (C++/Python/Rust SDKs in apis/), extension system for telemetry (libraries/extensions/telemetry/), and ROS2 bridge integration (examples/ros2-bridge/, apis/c++). The agentic engineering model (CLAUDE.md, .claude/skills/) suggests ongoing code generation and refactoring automation.

Clone the repo: git clone https://github.com/dora-rs/dora.git && cd dora. Install Rust (cargo is configured in Cargo.toml workspace). Run cargo build to compile the entire workspace, or cd binaries/cli && cargo build --release for the CLI. Then dora --help to verify the CLI is available. For examples: cd examples/rust-dataflow && cargo build followed by dora run dataflow.yaml.

Daily commands: Build all: cargo build --release. Run a dataflow: dora run <path-to-dataflow.yaml> (dataflow.yaml specifies nodes, connections, operators). Run coordinator + daemon for distributed setup: dora up (see binaries/coordinator, binaries/daemon). Local development: cargo watch -x 'build --all' for continuous compilation. Tests: cargo test --all --lib to run unit tests across workspace.

• Cargo.toml — Workspace root defining all member crates (APIs, binaries, examples); essential for understanding project structure and dependency graph.
• apis/rust/node/src/event_stream/event.rs — Core event abstraction for the Rust node API; defines how dataflow messages flow through the system.
• apis/rust/node/src/daemon_connection/mod.rs — Daemon connection abstraction layer; handles communication between nodes and the DORA daemon.
• apis/python/node/dora/__init__.py — Python node API entry point; primary interface for Python-based dataflow nodes.
• apis/c/operator/operator_api.h — C API contract for operators; defines the low-level interface for C/C++ integration.
• README.md — Project overview and getting started guide; essential context on DORA's purpose as a dataflow-oriented robotic middleware.
• .github/workflows/ci.yml — CI/CD pipeline configuration; reveals testing strategy, supported platforms, and build process for all language bindings.

Add a new Rust operator

1. Create a new operator crate under examples/rust-dataflow/ or as a new workspace member (Cargo.toml (add to [workspace] members))
2. Use the operator derive macro to define inputs, outputs, and process logic (apis/rust/operator/macros (reference existing #[dora::operator] usage))
3. Implement the operator by receiving events via the event stream API (apis/rust/node/src/event_stream/event.rs (consume Event types))
4. Send results back to the daemon via the output sender (apis/rust/node/src/daemon_connection/tcp.rs (use send methods))

Add a new Python node

1. Create a Python script importing the dora module (apis/python/node/dora/__init__.py (use Node or NodeBuilder classes))
2. Define inputs and outputs via the builder API (apis/python/node/dora/builder.py (call .input() and .output()))
3. Implement event polling loop to receive dataflow messages (apis/python/node/tests/test_dora_compat.py (see example event loop))
4. Send outputs back to the dataflow graph (apis/python/node/dora/__init__.py (call .send_output()))

Add a new C/C++ operator binding

1. Create FFI header with operator lifecycle hooks (init, process, drop) (apis/c/operator/operator_api.h (extend with new function signatures))
2. Implement Rust wrapper to call C code and marshal data via Arrow (apis/c/operator/src/lib.rs (add new binding functions))
3. Convert JSON/Arrow serialized inputs to C-native structures (apis/rust/node/src/daemon_connection/json_to_arrow.rs (extend conversion logic))
4. Build and test via Cargo with cc crate for C compilation (apis/c/operator/Cargo.toml (reference cc crate and build.rs))

Integrate a dataflow with ROS 2

1. Create a bridge node that subscribes to ROS 2 topics (binaries/ros2-bridge-node (reference existing bridge implementation))
2. Serialize ROS message types to Arrow format for dataflow compatibility (apis/rust/node/src/daemon_connection/json_to_arrow.rs (extend type support))
3. Publish dataflow outputs back to ROS 2 topics (examples/ros2-bridge (see publisher patterns))
4. Deploy the bridge node alongside dataflow nodes using CLI (binaries/cli (use dora up/start commands))

• Apache Arrow + Shared Memory — Zero-copy, language-agnostic serialization for sub-millisecond latency between nodes; critical for real-time robotics.
• Multi-language FFI (Rust → C/C++/Python) — Rust core provides safety and performance, while FFI bindings let users write in preferred languages without sacrificing daemon efficiency.
• TCP daemon + event stream model — Decouples node lifecycle from computation; allows dynamic deployment, restarts, and monitoring without graph disruption.
• Directed acyclic graph (DAG) topology — Enables static scheduling, cycle detection, and distributed execution planning without deadlock risk.
• ROS 2 bridge abstraction — Allows DORA dataflows to compose with existing ROS ecosystem, bridging two robotic middleware paradigms.

• Shared memory via Arrow instead of message passing

  • Why: Minimizes latency and CPU overhead for high-throughput sensor data (cameras, lidar).
  • Consequence: Nodes must run on same machine; not suitable for wide-area distributed systems. Requires careful serialization overhead management.

• Daemon-mediated architecture instead of peer-to-peer

  • Why: Centralized routing, monitoring, and lifecycle management simplifies reasoning about dataflow state.
  • Consequence: Daemon becomes a single point of failure; cluster-wide failures require coordinator intervention.

• Stateless operators with explicit message passing

  • Why: Determinism, replay-ability, and easy distributed scaling.
  • Consequence: No built-in state backends; users must implement durable storage if needed.

• Operator registration at startup vs. dynamic loading

  • Why: Static YAML graph definition simplifies deployment, CI/CD, and auditing.
  • Consequence: Cannot add/remove operators at runtime; requires dataflow restart.

• Does not provide real-time OS guarantees (RTOS); runs on general-purpose Linux/macOS.
• Does not enforce distributed transactions or ACID semantics; dataflow is best-effort.
• Does not include built-in machine learning training; focuses on inference pipelines and data orchestration.
• Does not handle long-lived request-response protocols; optimized for streaming and event-driven workloads.
• Does not provide automatic GPU scheduling or CUDA memory management; users must manage CUDA

Zenoh SHM requires specific OS support: Zero-copy SHM falls back to network transport automatically, but Linux/macOS have best support; Windows may have limitations. Arrow format is end-to-end: Serialization happens only at language boundary (Rust ↔ Python/C++) — payloads must fit Arrow columnar schema or custom serialization via arrow-convert is needed. Daemon must run before nodes: dora run spawns a local daemon, but distributed setups require dora up to start coordinator + daemons first; nodes will fail to connect otherwise. YAML dataflow.yaml is strict: missing required fields (nodes, operators) or circular dependencies cause silent/cryptic failures — validate early with dora build. Operator macros require exact signatures: the #[dora::operator] macro expects specific function signatures (Input/Output types must derive ArrowSerialize); mismatches cause opaque compile errors.

• ros-infrastructure/ros2 — ROS2 is the predecessor robotics middleware; DORA explicitly claims 10-17x faster Python performance and shares the dataflow/node abstraction but with Rust-native low-latency internals
• apache/arrow — Apache Arrow is the columnar memory format used end-to-end in DORA pipelines; critical for zero-copy serialization and cross-language compatibility
• eclipse-zenoh/zenoh — Zenoh is the underlying pub/sub transport for DORA; provides shared memory data plane and automatic network fallback for distributed deployments
• PyO3/pyo3 — PyO3 is the FFI bridge used in apis/python/node for writing Python nodes; essential dependency for polyglot dataflow support
• tokio-rs/tokio — Tokio async runtime powers the non-blocking event loops in binaries/daemon and binaries/runtime; critical for handling high-throughput dataflows without blocking

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive cross-language integration tests for C/C++/Python/Rust APIs

The repo has APIs for C, C++, Python, and Rust (apis/c/, apis/c++/, apis/python/, apis/rust/) but there's no visible test suite validating interoperability between these language bindings. Given DORA's focus on composable dataflows, a new contributor could create integration tests that verify nodes written in different languages can communicate correctly. This would catch breaking changes early and increase confidence in the multi-language architecture.

• [ ] Create tests/integration/cross-language/ directory structure
• [ ] Write test harnesses in apis/c/operator/src and apis/c++/operator/src that spawn simple producer/consumer nodes
• [ ] Add Python test cases in tests/integration/cross-language/ using apis/python/operator
• [ ] Create Rust coordination test in tests/integration/cross-language/ using apis/rust/operator
• [ ] Add GitHub Actions workflow in .github/workflows/cross-language-tests.yml to run these tests on every push
• [ ] Document expected behavior in each language API's README.md (apis/*/README.md)

Add telemetry and performance benchmarking tests for the dataflow runtime

The repo has a benchmarking example (examples/benchmark/node, examples/benchmark/sink) and telemetry extensions (libraries/extensions/telemetry/*), but there's no CI workflow that tracks performance regressions. A new contributor could create automated benchmark tests that measure throughput, latency, and memory usage of the dataflow pipeline, storing results for trend analysis. This is critical for a middleware that emphasizes 'low latency'.

• [ ] Create tests/benchmarks/runtime_performance.rs with criterion benchmarks for dora-runtime and dora-coordinator message passing
• [ ] Add Cargo.toml benchmark configuration with criterion dependency in libraries/core/Cargo.toml
• [ ] Write baseline benchmarks for node-to-node communication, operator throughput, and memory allocations
• [ ] Create .github/workflows/benchmark.yml that runs benchmarks and posts results as PR comments using benchmark-action
• [ ] Document baseline performance metrics in docs/ or a new BENCHMARKS.md file

Create unified logging and tracing test suite for all language bindings

The repo has libraries/log-utils and examples of log sinks (examples/log-sink-tcp, examples/log-sink-file, examples/log-sink-alert), but there's no validation that logging works consistently across C, C++, Python, and Rust APIs. A new contributor could build tests verifying that structured logs, trace spans, and error propagation work identically regardless of which language API is used, catching subtle inconsistencies in the logging abstraction layer.

• [ ] Create tests/logging/ directory with test fixtures for each language API
• [ ] Add tests/logging/test_unified_logging.rs as the Rust test harness that spawns nodes in different languages
• [ ] Write tests verifying structured logging format consistency (apis/c/node/, apis/c++/node/, apis/python/node/)
• [ ] Add error propagation tests in tests/logging/ that verify error codes and messages match across languages (see examples/error-propagation/)
• [ ] Create .github/workflows/logging-tests.yml to run on every push
• [ ] Update libraries/log-utils/README.md with language-specific logging guarantees

• Add integration tests for the Python-Rust interop layer: apis/python/node/src/lib.rs lacks explicit tests for PyO3 FFI edge cases (null handles, message serialization round-trips). Create tests/python_rust_integration.rs with pytest + cargo test coordination.
• Document the Arrow columnar format contract: libraries/arrow-convert/src/lib.rs implements zero-copy serialization but has no examples for users defining custom message types. Add an examples/arrow-custom-types/ directory with a worked example of ArrowSerialize trait implementation.
• Add CLI validation command: binaries/cli/src/cli.rs lacks a dora validate <dataflow.yaml> subcommand to catch YAML errors early without running the daemon. Implement validation by parsing YAML against the spec (docs/yaml-spec.md) and checking node/operator existence.

The DORA project shows a reasonable security posture overall with active CI/CD pipelines and multi-language support. However, there are concerns around credential exposure (the .adora-token file), lack of visible unified dependency vulnerability scanning across the multi-language workspace, and the inherent security risks of maintaining FFI boundaries across C, C++, Python, and Rust. The codebase would benefit from: (1) immediate removal of the .adora-token file, (2) implementation of automated SCA and SAST tools, (3) rigorous FFI boundary testing and fuzzing, and (4) a formal security policy. The presence of comprehensive CI/CD workflows and adherence to organized directory structures are positive indicators.

• Medium · Presence of Token File in Repository — .adora-token. The file '.adora-token' is present in the repository root. This appears to be a token or credential file that should not be committed to version control, as it may contain sensitive authentication material. Fix: Remove '.adora-token' from the repository immediately. Add it to .gitignore to prevent future commits. Rotate any credentials that may have been exposed.
• Medium · Potential Exposure of Development/Debug Configuration — .claude/skills/, .unwrap-budget, .adora-token. Files like '.claude/skills/adora-project/SKILL.md', '.unwrap-budget', and '.adora-token' suggest development-time configuration and tooling files that may contain sensitive project information or debugging aids. The '.unwrap-budget' file is particularly concerning as it may relate to Rust panic handling configuration. Fix: Review all dotfiles and configuration files to ensure no sensitive information is exposed. Consider whether development-specific files should be excluded from the repository or marked as internal documentation only.
• Low · Multiple Release and Build Workflow Files — .github/workflows/. The repository contains numerous GitHub Actions workflows (.github/workflows/) including cargo-release, pip-release, and docker-image pipelines. While workflows themselves are normal, they should be reviewed for proper secret management and secure handling of credentials during automated builds. Fix: Audit all CI/CD workflows to ensure: (1) Secrets are stored in GitHub Secrets, not hardcoded; (2) Build artifacts are signed; (3) Docker images are scanned for vulnerabilities; (4) Release processes enforce code review and verification.
• Low · Workspace Members Without Visible Security Configuration — Cargo.toml workspace configuration. The Cargo.toml workspace includes many members (C, C++, Python, Rust APIs and binaries) but there's no visible evidence of unified dependency vulnerability scanning, supply chain security, or Software Composition Analysis (SCA) configuration in the provided file structure. Fix: Implement automated dependency scanning using: (1) cargo-audit or cargo-deny for Rust dependencies; (2) pip-audit for Python dependencies; (3) clippy for static analysis; (4) Integrate these into CI/CD pipelines to fail builds on high-severity vulnerabilities.
• Low · Large Monorepo with Multiple Language Bindings — apis/c/, apis/c++/, apis/python/node/src/. The project maintains FFI bindings across C, C++, Python, and Rust. FFI boundaries are common sources of security issues including memory safety violations, type confusion, and incorrect buffer handling. Fix: Implement rigorous testing including: (1) Memory safety tools (valgrind, ASAN, MSAN) for C/C++; (2) Fuzzing at FFI boundaries; (3) Type safety validation; (4) Regular security audits of FFI code; (5) Use tools like miri for Rust unsafe code.
• Low · Missing SECURITY.md or Security Policy — Repository root. While CONTRIBUTING.md exists, there is no visible SECURITY.md or security policy file to guide responsible vulnerability disclosure. Fix: Create a SECURITY.md file documenting: (1) How to report security vulnerabilities responsibly; (2) Security contact information; (3) Expected response timelines; (4) Whether security advisories will be published.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/dora-rs/dora shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live dora-rs/dora repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/dora-rs/dora.

What it runs against: a local clone of dora-rs/dora — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in dora-rs/dora | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 32 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of dora-rs/dora. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/dora-rs/dora.git
#   cd dora
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of dora-rs/dora and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "dora-rs/dora(\\.git)?\\b" \\
  && ok "origin remote is dora-rs/dora" \\
  || miss "origin remote is not dora-rs/dora (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"
test -f "apis/rust/node/src/event_stream/event.rs" \\
  && ok "apis/rust/node/src/event_stream/event.rs" \\
  || miss "missing critical file: apis/rust/node/src/event_stream/event.rs"
test -f "apis/rust/node/src/daemon_connection/mod.rs" \\
  && ok "apis/rust/node/src/daemon_connection/mod.rs" \\
  || miss "missing critical file: apis/rust/node/src/daemon_connection/mod.rs"
test -f "apis/python/node/dora/__init__.py" \\
  && ok "apis/python/node/dora/__init__.py" \\
  || miss "missing critical file: apis/python/node/dora/__init__.py"
test -f "apis/c/operator/operator_api.h" \\
  && ok "apis/c/operator/operator_api.h" \\
  || miss "missing critical file: apis/c/operator/operator_api.h"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 32 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/dora-rs/dora"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.