go-workflows is a Go library for building durable, fault-tolerant workflow applications. It implements an event-sourced execution engine inspired by Temporal/Cadence: workflows are modeled as histories of events, and workers execute them by replaying those histories against backend queues. The library exposes a public client API for starting, signaling, and waiting on workflows, and provides a workflow/activity authoring model with sub-workflows, timers, signals, retries, cancellation, and context propagation. Execution is built on a custom coroutine-based async runtime (internal/sync) that gives workflows deterministic control flow, and multiple storage backends (Redis, MySQL, PostgreSQL, SQLite, plus in-memory/monoprocess) implement the same backend interface. Key entry points include the client package, the worker package, the workflow/activity authoring packages, and the tester package for unit testing workflows without a real backend. The repository also contains a separate static analyzer module (analyzer/) that enforces workflow determinism at compile time, and a benchmark tool (bench/) for comparing backend performance. External dependencies include OpenTelemetry for tracing, slog for structured logging, and backend-specific drivers for Redis, MySQL, PostgreSQL, and SQLite. CI runs tests with the race detector across all backends, and Docker Compose provides the required databases. The codebase is substantial and well-tested, but carries maintainability debt: each backend duplicates significant logic (diagnostics queries, event insertion), Redis uses hand-written Lua scripts that can drift, and the embedded diagnostic web app requires a separate Node.js build step. The separate analyzer module also risks version drift from the main module. Despite these caveats, the core abstractions are clean and several components are genuinely reusable.
FlowGram is a comprehensive, production-grade visual workflow development framework from ByteDance. The codebase implements two distinct editing paradigms — fixed-layout (automatic positioning with composite nodes like loops, branches) and free-layout (node-position-free with lines) — both built on a shared plugin architecture using inversify for dependency injection. The framework includes a form engine with reactive fields, validation, and effects; a variable engine with AST-based type inference and scoped lifecycle; and a runtime engine capable of executing workflows with executors for LLM, HTTP, code (QuickJS sandbox), and conditions. The repository contains over 40 packages managed via Rush monorepo, encompassing core libraries, plugins (history, minimap, auto-layout, group, snap, clipboard, export), UI material libraries (Semi UI, Ant Design), a CLI tool for scaffolding, multiple demo applications, and comprehensive documentation. The system is actively maintained with regular commits, CI workflows, and E2E tests. Notable technical decisions include a local fork of the use-gesture library for canvas interaction, heavy decorator-based IoC, and support for both React 17 and 18. While the architecture is well-structured and extensible, the codebase shows signs of duplication between fixed and free layouts, numerous demo-specific components, and some deprecated APIs that indicate ongoing refactoring.
SpiffWorkflow is a Python library for executing BPMN 2.0 and DMN 1.x workflows. It provides a complete workflow engine with parsing, execution, serialization, and migration capabilities. The library supports standard BPMN constructs (gateways, events, subprocesses, multi-instance loops, call activities) and DMN decision tables with UNIQUE and COLLECT hit policies. It includes a pluggable Python script engine for evaluating expressions and scripts within tasks, and a comprehensive serialization framework with version migration for workflow persistence. The architecture is modular, with separate packages for core workflow specs, BPMN specifics, DMN integration, Camunda-compatible extensions, and Spiff-specific customizations. This is not a standalone application but a library intended for embedding in larger systems; it is used as the backend for the SpiffWorkflow frontend tools.
This repository implements a GitHub Action that cancels previous workflow runs that are not completed (queued or in_progress) for a given workflow. The action is written in TypeScript and bundled using vercel/ncc for distribution. It processes inputs to determine which workflows to target, handles various GitHub events (push, pull_request, workflow_run), and uses the GitHub API via @actions/github to query and cancel workflow runs based on configurable conditions like ignoring SHA, canceling all but the latest, filtering by status, or force canceling. The architecture is a single source file (src/index.ts) that collects context from the GitHub Actions environment, resolves target workflows, lists relevant runs, applies filters, and cancels matching runs. The action demonstrates proper error handling, logging, and use of the GitHub Actions toolkit, making it a reliable tool for managing workflow concurrency.
Pneumatic is an open-source SaaS workflow management system built with a Django backend and React/TypeScript frontend. The platform enables users to create workflow templates, execute workflows, manage tasks, collaborate with teams, and track progress through a comprehensive UI. It features multi-tenancy, payment processing (Stripe integration), notification systems, file attachments, reporting, and various third-party integrations. The architecture follows a microservices-like separation using Docker Compose, with distinct services for backend, frontend, database (PostgreSQL), caching (Redis), messaging (RabbitMQ), and file storage. The codebase demonstrates solid engineering practices with clear separation of concerns, though it shows some technical debt from using Django 2.2 and accumulated migration complexity.
Hyrax is a Ruby on Rails engine for building digital repository applications, part of the Samvera community. It provides core functionality for managing scholarly works, collections, file sets, and administrative sets with full lifecycle support: ingest, metadata management, access control (permissions, embargoes, leases), workflow (mediated deposit), analytics (GA4, Matomo), IIIF manifests, fixity checking, and derivatives generation. The architecture is a monolith with a modular actor middleware stack (chain of responsibility) for work creation/update/destroy, dry-transaction steps for resource operations, and a pub/sub event system for decoupled side effects. It supports dual persistence via ActiveFedora (Fedora) and Valkyrie (PostgreSQL, Fedora 6), with migration infrastructure (Wings, Freyja) and a Solr indexing layer. Key entry points include Rails controllers (Blacklight-based search, admin dashboard, API), the actor stack, and transaction steps. The codebase is heavily engineered with reusable patterns but carries significant technical debt from the ongoing migration to Valkyrie, deprecation warnings, and conditional code paths.
Magic is a large, polyglot enterprise AI-agent and collaboration platform. The production core is a PHP Hyperf backend (`backend/magic-service`) with strict DDD layering, a Python agent runtime (`backend/super-magic`) for tools/skills/browser automation, a Go engine for knowledge processing/embedding, and a React/TypeScript frontend (`frontend/magic-web`) that spans desktop, mobile, admin, and a visual flow editor. The platform delivers chat/messaging, AI agents, workflow automation (MagicFlow), knowledge bases with vector search, an LLM/model gateway, file storage, low-code data tables (MagicBase), MCP integration, and multi-channel bot deployment (DingTalk, Feishu, WeCom). It is fundamentally an application rather than a research repository; the knowledge-base and data-processing subsystems serve product features, not analysis. Architecturally, the strongest parts are the PHP library packages — async-event, cloudfile, flow-expr-engine, code-executor, and easy-dingtalk — which are cleanly separated and demonstrate genuine, extractable craftsmanship. The frontend likewise includes reusable packages for flow editing, HTML-to-PPTX conversion, and UI components. However, the repository is physically enormous and shows maintenance risk: substantial code duplication exists between `backend/magic-service` and `backend/super-magic-module`, several enterprise features are intentionally stubbed out with open-source no-ops, migration rollback methods are frequently empty, and the mix of PHP, Python, Go, and TypeScript adds integration complexity. The codebase is actively developed, but quality is uneven across the many modules.
Eko is a TypeScript framework for building production-ready AI agents that can automate workflows across browser, Node.js, and web extension environments. The core orchestration engine (Eko class) takes a natural language task, uses an LLM to generate a multi-agent workflow plan encoded as XML, then executes it with parallel/serial agent execution, replanning, and human-in-the-loop support. The system provides a clean abstraction over LLM providers (OpenAI, Anthropic, etc.) with retry and fallback, a ReAct tool-calling loop, and built-in browser automation agents that operate via screenshots or DOM labels. It also includes MCP client implementations (SSE, HTTP, stdio) for integrating external tools, and a chat agent for conversational interactions with tool delegation. The architecture is modular with separate npm packages: @eko-ai/eko-core (core engine), @eko-ai/eko-nodejs (Playwright-based browser agent), @eko-ai/eko-extension (Chrome extension agent), and @eko-ai/eko-web (web environment agent). The repository includes working examples (Chrome extension with side panel, Node.js automation using Playwright, and a React web app). The framework is designed for developers who want to automate complex, multi-step tasks using language models, with a focus on reliability, human oversight, and extensibility via custom agents and tools.
ChatWiki is an open-source, multi-service AI chatbot and workflow automation platform primarily targeting the WeChat ecosystem. In production, it operates as a suite of Go microservices (chatwiki, message_service, code_run, websocket, plugin, llm_runner) behind a Gin web server, with a Vue 3 admin panel, separate mobile/PC/Electron frontends, and an embeddable SDK. The core functionality includes knowledge base management (document ingestion, chunking, vector storage with pgvector), a LogicFlow-based visual workflow builder, multi-channel messaging (WeChat Official Account, Mini Program, Feishu, DingTalk, Telegram, WhatsApp, LINE), and an AI agent framework called Clawbot with skill reuse. External dependencies include PostgreSQL (with pgvector and AGE graph extension), Redis, NSQ message queue, and optional Neo4j and E2B sandbox. While the system is primarily an application, it incorporates data-intensive components such as RAG pipelines, LLM request logging, and daily statistics, giving it a hybrid character.
OptimaJet.Workflow is a .NET workflow engine library designed for business process management and automation. It provides a core runtime for defining, executing, and persisting workflow schemes (process definitions) across multiple database backends including SQL Server, MySQL, PostgreSQL, Oracle, SQLite, and MongoDB. The engine supports multi-tenancy, version control of workflow schemes, and includes a visual HTML5 designer for creating workflows. It is architected as a library/framework layer, intended to be integrated into applications rather than running as a standalone service. The codebase demonstrates a hybrid architecture, combining modern .NET Core samples with legacy .NET Framework implementations using Windows Workflow Foundation (WWF). This duality is evident in the presence of both `OptimaJet.Workflow.Core` (modern) and `Other/WorkflowFoundation` (legacy) directories. The library relies heavily on the Provider Pattern for persistence, allowing developers to swap database backends via dependency injection. It also features a robust migration framework (FluentMigrator for SQL, custom scripts for MongoDB) to manage schema evolution, particularly around multi-tenancy support (`TenantId` columns). While the library offers solid engineering patterns like generic database abstraction (`DbObject<T>`) and async/await persistence, the codebase suffers from significant technical drift. It includes deprecated technologies such as `System.Workflow` and WCF, and sample applications rely on older versions of frameworks like ABP (v6.5.0) and .NET Core 2.2. The duplication of persistence logic across five different database providers increases maintenance overhead and the risk of schema drift between implementations.
This repository is a comprehensive collection of example applications for the Apache KIE ecosystem, specifically Kogito, Drools, and jBPM. It demonstrates how to build cloud-native business automation services using DMN decision models, PMML predictive models, DRL rules, and BPMN process orchestration. The examples are structured as runnable microservices for both Quarkus and Spring Boot runtimes, covering a wide range of capabilities including event-driven messaging with Kafka, persistence with PostgreSQL/MongoDB/Infinispan, security with Keycloak OIDC, monitoring with Prometheus/Grafana, and deployment on Kubernetes/OpenShift. The repository serves primarily as a learning and demonstration resource, not as a production library. It features high duplication across the two runtime stacks, with many near-identical examples maintained in parallel. The code is functional and follows standard Kogito patterns, but the emphasis is on showcasing features rather than providing reusable, production-grade components. Some examples use snapshot versions and older infrastructure configurations, indicating active development but also potential drift.
TACTIC is an open-source enterprise workflow and digital asset management (DAM) platform, primarily targeting media and entertainment production pipelines. It provides a full-stack web application built on CherryPy/Cheroot, featuring a custom widget framework, a client-server API (XML-RPC/REST), and a database abstraction layer supporting PostgreSQL, MySQL, Oracle, SQLite, and SQL Server. The system manages assets, shots, tasks, pipelines, check-ins, and user permissions, with integrations for DCC tools like Maya, Houdini, and Nuke. The architecture is monolithic, with a Python backend serving a JavaScript-heavy frontend (MooTools-based, with some React components). Key entry points include the web server (CherryPy adapter), the client library (`TacticServerStub`), and command/trigger systems for business logic. The codebase is large and feature-rich but carries significant technical debt: bundled third-party libraries for multiple Python versions (2, 3.6, 3.x), deprecated modules, hardcoded paths, and inconsistent coding styles. Despite active development (recent commits), the drift from modern Python and library ecosystems is high, making long-term maintenance challenging.