elsa-workflows/elsa-foundation

Última atividade de origem registrada: 23 de outubro de 2026 às 12:59

Catálogo do SkillsMP atualizado: 9 de novembro de 2026 às 14:22

skills coletadas: 40

Estrelas no GitHub: 10
Forks no GitHub: 3

Instalar com um assistente de IA

Copie este prompt para o assistente de IA que você usa.

Follow https://skillsmp.com/skill-install/prompt.md to install Agent Skills from https://github.com/elsa-workflows/elsa-foundation.

README do repositório

Arquivo de origem do README: README.md

Ler o README original

Expandir README completo

![Elsa 4, a modern .NET workflow engine, illustrated with branching activity paths, a modular runtime and layered checkpoints](docs/assets/elsa-foundation-header.png) # Elsa Foundation `elsa-foundation` is the transitional Elsa 4 foundation workspace. It contains the Elsa backend and Studio in three product roots: - `Essentials/`: backend libraries, tests and host applications. - `Extensions/<capability>/`: optional backend implementations, tests and Studio components where present. - `Studio/`: the Studio shell, shared UI, tests and frontend tooling. Shared engineering documentation, tools and workflows remain at the root. Public Elsa 4 documentation source lives in `website/docs/` and syncs to GitBook. Server and Studio retain independent builds and package identities. These repositories develop the Elsa 4 preview. Elsa 3 uses the separate [elsa-core](https://github.com/elsa-workflows/elsa-core) and [elsa-studio](https://github.com/elsa-workflows/elsa-studio) repositories. - **Try Elsa 4:** [run Workbench and Studio from published Docker images](docker/compose/README.md#quick-start--published-images-no-clone-or-build). - **Contribute to the server:** follow the [Elsa Foundation contribution guide](CONTRIBUTING.md). - **Contribute to Studio:** follow the [Elsa Foundation Studio contribution guide](Studio/CONTRIBUTING.md). ## Screenshots Elsa Studio running against Workbench from the [published Docker images](docker/compose/README.md#quick-start--published-images-no-clone-or-build). Captured with Studio rev `7cb2f2c2`; Write Line `4.0.5-preview`, Flowchart `4.0.3-preview`; the preview UI may change. | Designer | Completed run | | --- | --- | | <img src="website/docs/assets/elsa4/elsa4-04-designer_studio-7cb2f2c2_act-4.0.5-preview.png" alt="Studio designer with one Write Line activity" width="420"> | <img src="website/docs/assets/elsa4/elsa4-07-run-timeline_studio-7cb2f2c2_act-4.0.5-preview.png" alt="Completed run 14J7GJS3fOg with execution timeline" width="420"> | See [Your first workflow](website/docs/essentials/first-workflow.md) for the full walkthrough. ## Philosophy Elsa Foundation should be a thin protocol, not a fat one. Its job is to define the narrow shared surface that lets modules cooperate: domain language, core contracts, extension points, invariants, and the quality gates needed to keep the system understandable. It should not become a platform-shaped dependency that every feature inherits by default. Modules should stay opt-in. A shell composes only the capabilities it needs, and features such as persistence, HTTP, JavaScript, scheduling, and host-specific integrations should enter through explicit dependencies and composition. Keeping the foundation thin makes coupling visible, protects extension authors from choices they did not select, and keeps feature-workspace assets movable as Elsa continues the modular refactor. ## Start here - The process entry point is [`Essentials/apps/Elsa.Workbench/Program.cs`](Essentials/apps/Elsa.Workbench/Program.cs); which features it composes is decided by [`Essentials/apps/Elsa.Workbench/shells.json`](Essentials/apps/Elsa.Workbench/shells.json). - [How a workflow executes](docs/how-a-workflow-executes.md) traces one request from that entry point to a durable checkpoint, file by file. - [AGENTS.md](AGENTS.md) is the provider-neutral entrypoint for AI agents and engineers. - [docs/README.md](docs/README.md) routes to glossary, skills, maps, reports, and architecture orientation. - `.specify/memory/constitution-framework.md` and `.specify/memory/constitution.md` are the two-layer constitution and should be treated as quality gates, not as the primary learning path. ## Repository role This repo currently supports two roles: - **Feature development:** shipping and testing Elsa foundation features through Speckit specs under `specs/`. - **Architecture development:** reviewing, revising, and verifying the modular framework constitution and Elsa-specific architecture. Feature-development workflows remain here for now, but the documentation and operating model are shaped so they can move to a future `elsa-workspace` repository with minimal churn. ## Build ```powershell dotnet build Elsa.Server.slnx ``` For faster inner-loop work, open or build one of the committed [developer solution filters](docs/reference/developer-solution-filters.md). The full solution remains the completion gate. To build and run the backend from source, check readiness, and execute a sample workflow, follow the [backend source quickstart](docs/contributing/backend-source-quickstart.md). To pair that Workbench with Studio from `Studio/` in this repository, follow the [Studio source quickstart](Studio/docs/contributing/studio-source-quickstart.md). ## Supported management APIs Management-client APIs are owned by their Elsa domains and can be composed directly by custom applications. `Elsa.Workbench` is a reference composition, not the implementation home of a server-wide management facade. The canonical areas are Workflow Design, Activity Design, Expressions, Publishing, Runtime, and [API Capabilities](Essentials/src/Api/Capabilities/Elsa.Api.Capabilities/README.md). An authenticated client loads one shell-relative `GET /capabilities` document, then follows the advertised domain links. Omitted domain features advertise no capability and expose no routes; endpoint-level action permissions remain authoritative. See the [domain-owned API specification](specs/220-domain-owned-apis/spec.md), [OpenAPI contract](specs/220-domain-owned-apis/contracts/management-api.openapi.yaml), and [validation quickstart](specs/220-domain-owned-apis/quickstart.md) for composition and compatibility details. Opt-in [direct BPMN hosting](Essentials/src/Activities/Bpmn/Api/README.md) adds model publication, execution, human completion, cancellation and service-incident retry APIs. Native workflows can embed a published model with `RunBpmn`; the [host adapter](Essentials/src/Activities/Bpmn/Elsa.Activities.Bpmn/README.md) describes its binding profiles, compatibility and recovery evidence. Existing Studio BPMN authoring is preserved; first-class direct-model Studio support remains tracked by the execution-model program. ## Run with Docker The fastest way to try the stack is to [run the published images with Docker Compose](docker/compose/README.md#with-docker-compose), without cloning or building the repositories. That guide includes macOS/Linux and Windows PowerShell commands. This starts **Elsa.Workbench** (`http://localhost:13000`) and **Elsa Studio** (`http://localhost:14000`) from the Docker Hub images `elsaworkflows/elsa-workbench` and `elsaworkflows/elsa-studio` (SQLite, ephemeral). The [Docker quickstart](docker/compose/README.md) covers this plus the build-from-source path with PostgreSQL, and explains the settings that wire Studio to the server backend (`Studio__BackendBaseUrl`, the Elsa host management key, CORS). For the full container/image reference (environment variables, mounts, persistence composition, troubleshooting), see [docs/docker.md](docs/docker.md).

Carregando o README do repositório…

Skills neste repositório

Desenvolvedores de software Analistas de garantia de qualidade de software e testadores

2 categorias ocupacionais · 40% classificado

skill

ocupação

descrição

atualizado