{"owner":"elsa-workflows","repo":"elsa-core","hasSkills":true,"totalSkillsCount":5,"totalTokensCount":3464,"categories":["root-instruction","copilot-instructions","mcp-config","marketplace","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"elsa-core":{"command":"npx","args":["-y","@modelcontextprotocol/server-elsa-core"]}}},"found":["AGENTS.md",".github/copilot-instructions.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json"],"skills":{"AGENTS.md":"# AGENTS.md\n\nGuidance for AI coding agents working in this repository.\n\n## Project Overview\n\n- Elsa Core is a .NET solution centered on `Elsa.sln`.\n- Products live under `core/`, `extensions/`, `studio/`, `apps/`, and `templates/`. Apps contains official released-package application hosts and Python container-policy tests under `apps/scripts/tests/`; its contributor entrypoint is [Apps](apps/README.md).\n- The root solution, solution filters, build automation, scripts and central policy are shared. Templates keeps its independent product solution; root `Elsa.sln` includes navigation items only for that product.\n- Read the product documentation entrypoints: [Core](core/docs/README.md), [Extensions](extensions/docs/README.md), [Studio](studio/docs/README.md), [Apps](apps/docs/README.md), and [Templates](templates/docs/README.md).\n- Build automation is implemented with NUKE in `build/Build.cs` and exposed through `build.sh`, `build.ps1`, and `build.cmd`.\n\n## Working Rules\n\n- Keep changes focused on the requested task. Do not mix unrelated cleanup, formatting, or dependency updates into functional changes.\n- Preserve existing public APIs unless the task explicitly requires an API change.\n- Update tests when behavior changes and add tests for new behavior where practical.\n- Update documentation when changing externally visible behavior, configuration, APIs, or developer workflows.\n- Do not delete generated-looking, artifact, or IDE files unless the task explicitly asks for cleanup.\n- If the worktree contains unrelated user changes, leave them untouched.\n- Before opening a PR, read `.github/reviewers.md`: Greptile is required (re-request with `@greptileai` after each push), and request at most one additional advisory reviewer from the list once the PR is open.\n\n## Agent Operating Principles\n\n- Do not assume, hide confusion, or flatten uncertainty; surface questions, constraints, and tradeoffs explicitly.\n- Write the minimum code that solves the defined problem; do not add speculative abstractions, features, or cleanup.\n- Touch only the files and behavior required for the task; clean up only issues introduced by your own changes.\n- Define success criteria before implementation, then iterate until the criteria are verified or clearly state what could not be verified.\n\n## Build And Test Commands\n\n- Build the default target: `./build.sh`\n- Run NUKE test target: `./build.sh Test`\n- Build with dotnet directly: `dotnet build Elsa.sln`\n- Focus a product build with `dotnet build Elsa.Core.slnf`, `dotnet build Elsa.Extensions.slnf`, `dotnet build Elsa.Studio.slnf`, or `dotnet build Elsa.Apps.slnf`; see product docs for selection boundaries.\n- Build Templates separately: `dotnet build Elsa.Templates.slnf` or `dotnet build templates/Elsa.Templates.slnx`; test with `dotnet test templates/test/Elsa.Templates.Tests/Elsa.Templates.Tests.csproj`. Read [Templates guidance](templates/AGENTS.md) before changing that product.\n- Run shared-solution tests directly: `dotnet test Elsa.sln`\n- Run a specific test project: `dotnet test core/test/unit/Elsa.Workflows.Core.UnitTests/Elsa.Workflows.Core.UnitTests.csproj`\n- Run ElsaScript DSL integration tests: `./run-dsl-tests.sh`\n\nPrefer targeted `dotnet test <project>` commands while iterating, then run a broader build or test command when the change affects shared infrastructure or cross-module behavior.\n\n## Code Style\n\n- C# uses `LangVersion` `latest`, nullable reference types, and implicit usings from `Directory.Build.props`.\n- Product source libraries target `net8.0`, `net9.0`, and `net10.0` through their product `src/Directory.Build.props`; hosts and tests may select a specific framework.\n- Follow `.editorconfig`: 4-space indentation for C#, file-scoped namespaces, braces required, `var` preferred, usings outside namespaces, and sorted system directives.\n- Prefer clear domain names over abbreviations. Keep types small and responsibilities explicit.\n- Avoid suppressing warnings unless compatibility or framework constraints make the warning unavoidable; explain the reason near the suppression.\n\n## Repository Structure\n\n- `core/src/apps/`, `core/src/clients/`, `core/src/common/`, `core/src/modules/`: Core hosts, clients, shared infrastructure and modules.\n- `core/test/`: Core unit, integration, component and performance tests.\n- `extensions/src/`, `extensions/test/`, `extensions/docs/`, `extensions/samples/`: Extensions-owned code, tests, documentation and samples.\n- `studio/react/`: React Studio Preview frontend and host; read its contributor guidance.\n- `studio/src/`, `studio/test/`, `studio/docs/`, `studio/samples/`: Studio-owned code, tests, documentation and samples. Read [Studio contributor guidance](studio/src/AGENTS.md) for Studio modules, hosts, frameworks and tests.\n- `apps/src/`, `apps/scripts/`, `apps/docs/`: official net10 application/image hosts, container policy tests and source-import guidance. Read [Apps agent guidance](apps/AGENTS.md). Apps consumes released packages and does not add Core NuGet release units.\n- `templates/src/`, `templates/test/`, `templates/docs/`: independent Elsa 3 .NET project-template pack, smoke tests and contributor guidance. Embedded starter project files are data; keep all Templates projects outside root `Elsa.sln` packing.\n- `core/docs/specs/` and `studio/docs/specs/`: product feature plans and specifications.\n- `docs/adr/`: shared architecture decisions; `docs/integration-program/`: retained consolidation and proof records.\n- `build/`, `scripts/`, `docker/`, root solution/filter files and central `Directory.*` files: shared tooling and policy.\n- `design/`: shared design assets; `core/docs/design/`: Core persistence design notes.\n\n## Architecture Decision Records\n\n- ADRs live in `docs/adr/`. New records are named `YYYY-MM-DD-slug.md`, and the `# ` heading carries the\n  title alone with no numeric prefix. Do not continue the legacy `NNNN-` sequence: it collided on every\n  concurrent branch, which is what the date prefix exists to stop.\n- Records `0001`-`0027` keep their existing names and headings. Do not renumber or rename them.\n- `docs/adr/toc.md` is generated. Never edit it by hand: run `scripts/adr/generate-toc.sh` and commit the\n  result. `scripts/adr/generate-toc.sh --check` verifies it is current, and CI runs the same check.\n- The rationale is recorded in\n  [Identify new ADRs by date instead of a sequential number](docs/adr/2026-08-25-date-prefixed-adr-identifiers.md).\n\n## Testing Guidance\n\n- Place tests near the relevant existing test project rather than creating a new project by default.\n- Use the existing shared testing helpers under `core/src/common/Elsa.Testing.Shared*` when they fit the scenario.\n- For regressions, add a failing test that demonstrates the bug before or alongside the fix.\n- For multi-targeting issues, consider whether the test must run against all target frameworks or only the affected one.\n\n## Dependency And Package Guidance\n\n- Central package versions are managed in the root and product `Directory.Packages.props` files; do not add ad hoc versions to individual project files unless the repository already uses that pattern for the package.\n- Keep target framework changes centralized in the relevant product `src/Directory.Build.props` unless a project has a specific reason to differ.\n- Be cautious with package upgrades because this repository targets multiple frameworks and modules.\n\n## Review Checklist\n\nBefore handing off changes, verify the following when applicable:\n\n- The project or solution builds.\n- Relevant unit or integration tests pass.\n- Public API or behavior changes are documented.\n- New code follows nullable annotations and existing style.\n- No unrelated files were changed.\n- The change follows `.github/quality/PRINCIPLES.md`, which is the bar for public API, simplicity, domain language, tests, CI and docs. In particular, public API changes in 3.x deprecate rather than break (principle 6). `.github/quality/README.md` explains the audit and fix loop and its labels.\n",".github/copilot-instructions.md":"# Elsa 3 coding instructions\n\nFollow the repository [AGENTS.md](../AGENTS.md) for scope, code style, tests, package versions, and ADR rules. Check the current issue and source before changing behavior. This file is a short map for the consolidated product layout; it does not authorize publishing packages or archiving source repositories.\n\n## Source and development workflow\n\n- `core/src/modules/`, `core/src/common/`, `core/src/clients/`, and `core/src/apps/` contain the Core backend and hosts.\n- `extensions/src/` contains imported Extensions modules and connectors. Keep public package IDs and activity identities stable during consolidation.\n- `studio/src/` contains Blazor Studio framework, modules, hosts, browser bundles, and tests. Use the [Studio development guide](../studio/docs/README.md) for current paths, local backend binding, and paired debugging. The former standalone Studio instructions remain only as [import provenance](../docs/integration-program/legacy/studio/.github/copilot-instructions.md.source).\n- Open the canonical [`Elsa.sln`](../Elsa.sln) for backend and Studio changes together. Use the targeted project or test when iterating; run broader checks when a shared dependency or build integration changes.\n\nThe Studio Designer and DomInterop ClientLib projects require Node 22. From the repository root, build their browser assets with:\n\n```sh\n./scripts/integration-program/build_studio_clientlibs.sh\n```\n\nThen build the affected .NET projects or `dotnet build Elsa.sln`. Production projects target net8.0, net9.0, and net10.0 unless a project explicitly overrides the shared target frameworks. Run the relevant tests with `dotnet test <project> --framework net10.0`; include the other target frameworks when the change affects multi-target behavior. Studio has tests, so do not treat an empty `dotnet test` run as proof of coverage.\n\nFor a local backend/Blazor session, follow the Studio guide's separate backend and `Elsa.Studio.Host.Server` hosts and its ignored `appsettings.Local.json` URL binding. Keep local credentials and client secrets out of tracked files. Do not assume a backend route exists merely because a Studio client declares it; verify the actual host configuration and permissions.\n\n## Build, compatibility, and releases\n\nCentral package versions live in `Directory.Packages.props`; framework defaults live in each product’s `src/Directory.Build.props`. Prefer the repository's existing build and test commands in `AGENTS.md`. Investigate restore or build failures rather than changing package versions to a guessed \"nearest\" version or masking a required source failure.\n\nThe [integration program](../docs/integration-program/README.md) records import evidence, package boundaries, and pending gates. Imported Extensions/Studio publishers are retained as inert provenance. The [first consolidated release policy](../docs/adr/2026-09-28-lockstep-consolidated-release-and-publisher-cutover.md) governs lockstep 3.10 and the single Core publisher. The earlier [release-unit manifest](../docs/integration-program/release-units.json) and [publisher handoff](../docs/integration-program/publisher-handoff.md) retain their bounded proof scope; they do not establish live publisher cutover. Do not enable a publisher, push a package to a feed, or treat a local proof version as a release allocation without the program's explicit cutover approval.\n\nThe history-bearing import landed through [PR #8409](https://github.com/elsa-workflows/elsa-core/pull/8409), with later source/release catch-up through [PR #8624](https://github.com/elsa-workflows/elsa-core/pull/8624). Preserve that history and check current source pins and exact-head CI before claiming acceptance of a relocated tree. Do not replace imported source with a local checkout.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elsa-workflows/elsa-core/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elsa-workflows/elsa-core/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elsa-workflows/elsa-core/HEAD/.claude-plugin/plugin.json)"},"files":{"AGENTS.md":"# AGENTS.md\n\nGuidance for AI coding agents working in this repository.\n\n## Project Overview\n\n- Elsa Core is a .NET solution centered on `Elsa.sln`.\n- Products live under `core/`, `extensions/`, `studio/`, `apps/`, and `templates/`. Apps contains official released-package application hosts and Python container-policy tests under `apps/scripts/tests/`; its contributor entrypoint is [Apps](apps/README.md).\n- The root solution, solution filters, build automation, scripts and central policy are shared. Templates keeps its independent product solution; root `Elsa.sln` includes navigation items only for that product.\n- Read the product documentation entrypoints: [Core](core/docs/README.md), [Extensions](extensions/docs/README.md), [Studio](studio/docs/README.md), [Apps](apps/docs/README.md), and [Templates](templates/docs/README.md).\n- Build automation is implemented with NUKE in `build/Build.cs` and exposed through `build.sh`, `build.ps1`, and `build.cmd`.\n\n## Working Rules\n\n- Keep changes focused on the requested task. Do not mix unrelated cleanup, formatting, or dependency updates into functional changes.\n- Preserve existing public APIs unless the task explicitly requires an API change.\n- Update tests when behavior changes and add tests for new behavior where practical.\n- Update documentation when changing externally visible behavior, configuration, APIs, or developer workflows.\n- Do not delete generated-looking, artifact, or IDE files unless the task explicitly asks for cleanup.\n- If the worktree contains unrelated user changes, leave them untouched.\n- Before opening a PR, read `.github/reviewers.md`: Greptile is required (re-request with `@greptileai` after each push), and request at most one additional advisory reviewer from the list once the PR is open.\n\n## Agent Operating Principles\n\n- Do not assume, hide confusion, or flatten uncertainty; surface questions, constraints, and tradeoffs explicitly.\n- Write the minimum code that solves the defined problem; do not add speculative abstractions, features, or cleanup.\n- Touch only the files and behavior required for the task; clean up only issues introduced by your own changes.\n- Define success criteria before implementation, then iterate until the criteria are verified or clearly state what could not be verified.\n\n## Build And Test Commands\n\n- Build the default target: `./build.sh`\n- Run NUKE test target: `./build.sh Test`\n- Build with dotnet directly: `dotnet build Elsa.sln`\n- Focus a product build with `dotnet build Elsa.Core.slnf`, `dotnet build Elsa.Extensions.slnf`, `dotnet build Elsa.Studio.slnf`, or `dotnet build Elsa.Apps.slnf`; see product docs for selection boundaries.\n- Build Templates separately: `dotnet build Elsa.Templates.slnf` or `dotnet build templates/Elsa.Templates.slnx`; test with `dotnet test templates/test/Elsa.Templates.Tests/Elsa.Templates.Tests.csproj`. Read [Templates guidance](templates/AGENTS.md) before changing that product.\n- Run shared-solution tests directly: `dotnet test Elsa.sln`\n- Run a specific test project: `dotnet test core/test/unit/Elsa.Workflows.Core.UnitTests/Elsa.Workflows.Core.UnitTests.csproj`\n- Run ElsaScript DSL integration tests: `./run-dsl-tests.sh`\n\nPrefer targeted `dotnet test <project>` commands while iterating, then run a broader build or test command when the change affects shared infrastructure or cross-module behavior.\n\n## Code Style\n\n- C# uses `LangVersion` `latest`, nullable reference types, and implicit usings from `Directory.Build.props`.\n- Product source libraries target `net8.0`, `net9.0`, and `net10.0` through their product `src/Directory.Build.props`; hosts and tests may select a specific framework.\n- Follow `.editorconfig`: 4-space indentation for C#, file-scoped namespaces, braces required, `var` preferred, usings outside namespaces, and sorted system directives.\n- Prefer clear domain names over abbreviations. Keep types small and responsibilities explicit.\n- Avoid suppressing warnings unless compatibility or framework constraints make the warning unavoidable; explain the reason near the suppression.\n\n## Repository Structure\n\n- `core/src/apps/`, `core/src/clients/`, `core/src/common/`, `core/src/modules/`: Core hosts, clients, shared infrastructure and modules.\n- `core/test/`: Core unit, integration, component and performance tests.\n- `extensions/src/`, `extensions/test/`, `extensions/docs/`, `extensions/samples/`: Extensions-owned code, tests, documentation and samples.\n- `studio/react/`: React Studio Preview frontend and host; read its contributor guidance.\n- `studio/src/`, `studio/test/`, `studio/docs/`, `studio/samples/`: Studio-owned code, tests, documentation and samples. Read [Studio contributor guidance](studio/src/AGENTS.md) for Studio modules, hosts, frameworks and tests.\n- `apps/src/`, `apps/scripts/`, `apps/docs/`: official net10 application/image hosts, container policy tests and source-import guidance. Read [Apps agent guidance](apps/AGENTS.md). Apps consumes released packages and does not add Core NuGet release units.\n- `templates/src/`, `templates/test/`, `templates/docs/`: independent Elsa 3 .NET project-template pack, smoke tests and contributor guidance. Embedded starter project files are data; keep all Templates projects outside root `Elsa.sln` packing.\n- `core/docs/specs/` and `studio/docs/specs/`: product feature plans and specifications.\n- `docs/adr/`: shared architecture decisions; `docs/integration-program/`: retained consolidation and proof records.\n- `build/`, `scripts/`, `docker/`, root solution/filter files and central `Directory.*` files: shared tooling and policy.\n- `design/`: shared design assets; `core/docs/design/`: Core persistence design notes.\n\n## Architecture Decision Records\n\n- ADRs live in `docs/adr/`. New records are named `YYYY-MM-DD-slug.md`, and the `# ` heading carries the\n  title alone with no numeric prefix. Do not continue the legacy `NNNN-` sequence: it collided on every\n  concurrent branch, which is what the date prefix exists to stop.\n- Records `0001`-`0027` keep their existing names and headings. Do not renumber or rename them.\n- `docs/adr/toc.md` is generated. Never edit it by hand: run `scripts/adr/generate-toc.sh` and commit the\n  result. `scripts/adr/generate-toc.sh --check` verifies it is current, and CI runs the same check.\n- The rationale is recorded in\n  [Identify new ADRs by date instead of a sequential number](docs/adr/2026-08-25-date-prefixed-adr-identifiers.md).\n\n## Testing Guidance\n\n- Place tests near the relevant existing test project rather than creating a new project by default.\n- Use the existing shared testing helpers under `core/src/common/Elsa.Testing.Shared*` when they fit the scenario.\n- For regressions, add a failing test that demonstrates the bug before or alongside the fix.\n- For multi-targeting issues, consider whether the test must run against all target frameworks or only the affected one.\n\n## Dependency And Package Guidance\n\n- Central package versions are managed in the root and product `Directory.Packages.props` files; do not add ad hoc versions to individual project files unless the repository already uses that pattern for the package.\n- Keep target framework changes centralized in the relevant product `src/Directory.Build.props` unless a project has a specific reason to differ.\n- Be cautious with package upgrades because this repository targets multiple frameworks and modules.\n\n## Review Checklist\n\nBefore handing off changes, verify the following when applicable:\n\n- The project or solution builds.\n- Relevant unit or integration tests pass.\n- Public API or behavior changes are documented.\n- New code follows nullable annotations and existing style.\n- No unrelated files were changed.\n- The change follows `.github/quality/PRINCIPLES.md`, which is the bar for public API, simplicity, domain language, tests, CI and docs. In particular, public API changes in 3.x deprecate rather than break (principle 6). `.github/quality/README.md` explains the audit and fix loop and its labels.\n",".github/copilot-instructions.md":"# Elsa 3 coding instructions\n\nFollow the repository [AGENTS.md](../AGENTS.md) for scope, code style, tests, package versions, and ADR rules. Check the current issue and source before changing behavior. This file is a short map for the consolidated product layout; it does not authorize publishing packages or archiving source repositories.\n\n## Source and development workflow\n\n- `core/src/modules/`, `core/src/common/`, `core/src/clients/`, and `core/src/apps/` contain the Core backend and hosts.\n- `extensions/src/` contains imported Extensions modules and connectors. Keep public package IDs and activity identities stable during consolidation.\n- `studio/src/` contains Blazor Studio framework, modules, hosts, browser bundles, and tests. Use the [Studio development guide](../studio/docs/README.md) for current paths, local backend binding, and paired debugging. The former standalone Studio instructions remain only as [import provenance](../docs/integration-program/legacy/studio/.github/copilot-instructions.md.source).\n- Open the canonical [`Elsa.sln`](../Elsa.sln) for backend and Studio changes together. Use the targeted project or test when iterating; run broader checks when a shared dependency or build integration changes.\n\nThe Studio Designer and DomInterop ClientLib projects require Node 22. From the repository root, build their browser assets with:\n\n```sh\n./scripts/integration-program/build_studio_clientlibs.sh\n```\n\nThen build the affected .NET projects or `dotnet build Elsa.sln`. Production projects target net8.0, net9.0, and net10.0 unless a project explicitly overrides the shared target frameworks. Run the relevant tests with `dotnet test <project> --framework net10.0`; include the other target frameworks when the change affects multi-target behavior. Studio has tests, so do not treat an empty `dotnet test` run as proof of coverage.\n\nFor a local backend/Blazor session, follow the Studio guide's separate backend and `Elsa.Studio.Host.Server` hosts and its ignored `appsettings.Local.json` URL binding. Keep local credentials and client secrets out of tracked files. Do not assume a backend route exists merely because a Studio client declares it; verify the actual host configuration and permissions.\n\n## Build, compatibility, and releases\n\nCentral package versions live in `Directory.Packages.props`; framework defaults live in each product’s `src/Directory.Build.props`. Prefer the repository's existing build and test commands in `AGENTS.md`. Investigate restore or build failures rather than changing package versions to a guessed \"nearest\" version or masking a required source failure.\n\nThe [integration program](../docs/integration-program/README.md) records import evidence, package boundaries, and pending gates. Imported Extensions/Studio publishers are retained as inert provenance. The [first consolidated release policy](../docs/adr/2026-09-28-lockstep-consolidated-release-and-publisher-cutover.md) governs lockstep 3.10 and the single Core publisher. The earlier [release-unit manifest](../docs/integration-program/release-units.json) and [publisher handoff](../docs/integration-program/publisher-handoff.md) retain their bounded proof scope; they do not establish live publisher cutover. Do not enable a publisher, push a package to a feed, or treat a local proof version as a release allocation without the program's explicit cutover approval.\n\nThe history-bearing import landed through [PR #8409](https://github.com/elsa-workflows/elsa-core/pull/8409), with later source/release catch-up through [PR #8624](https://github.com/elsa-workflows/elsa-core/pull/8624). Preserve that history and check current source pins and exact-head CI before claiming acceptance of a relocated tree. Do not replace imported source with a local checkout.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elsa-workflows/elsa-core/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elsa-workflows/elsa-core/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elsa-workflows/elsa-core/HEAD/.claude-plugin/plugin.json)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/elsa-workflows/elsa-core/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AGENTS.md\n\nGuidance for AI coding agents working in this repository.\n\n## Project Overview\n\n- Elsa Core is a .NET solution centered on `Elsa.sln`.\n- Products live under `core/`, `extensions/`, `studio/`, `apps/`, and `templates/`. Apps contains official released-package application hosts and Python container-policy tests under `apps/scripts/tests/`; its contributor entrypoint is [Apps](apps/README.md).\n- The root solution, solution filters, build automation, scripts and central policy are shared. Templates keeps its independent product solution; root `Elsa.sln` includes navigation items only for that product.\n- Read the product documentation entrypoints: [Core](core/docs/README.md), [Extensions](extensions/docs/README.md), [Studio](studio/docs/README.md), [Apps](apps/docs/README.md), and [Templates](templates/docs/README.md).\n- Build automation is implemented with NUKE in `build/Build.cs` and exposed through `build.sh`, `build.ps1`, and `build.cmd`.\n\n## Working Rules\n\n- Keep changes focused on the requested task. Do not mix unrelated cleanup, formatting, or dependency updates into functional changes.\n- Preserve existing public APIs unless the task explicitly requires an API change.\n- Update tests when behavior changes and add tests for new behavior where practical.\n- Update documentation when changing externally visible behavior, configuration, APIs, or developer workflows.\n- Do not delete generated-looking, artifact, or IDE files unless the task explicitly asks for cleanup.\n- If the worktree contains unrelated user changes, leave them untouched.\n- Before opening a PR, read `.github/reviewers.md`: Greptile is required (re-request with `@greptileai` after each push), and request at most one additional advisory reviewer from the list once the PR is open.\n\n## Agent Operating Principles\n\n- Do not assume, hide confusion, or flatten uncertainty; surface questions, constraints, and tradeoffs explicitly.\n- Write the minimum code that solves the defined problem; do not add speculative abstractions, features, or cleanup.\n- Touch only the files and behavior required for the task; clean up only issues introduced by your own changes.\n- Define success criteria before implementation, then iterate until the criteria are verified or clearly state what could not be verified.\n\n## Build And Test Commands\n\n- Build the default target: `./build.sh`\n- Run NUKE test target: `./build.sh Test`\n- Build with dotnet directly: `dotnet build Elsa.sln`\n- Focus a product build with `dotnet build Elsa.Core.slnf`, `dotnet build Elsa.Extensions.slnf`, `dotnet build Elsa.Studio.slnf`, or `dotnet build Elsa.Apps.slnf`; see product docs for selection boundaries.\n- Build Templates separately: `dotnet build Elsa.Templates.slnf` or `dotnet build templates/Elsa.Templates.slnx`; test with `dotnet test templates/test/Elsa.Templates.Tests/Elsa.Templates.Tests.csproj`. Read [Templates guidance](templates/AGENTS.md) before changing that product.\n- Run shared-solution tests directly: `dotnet test Elsa.sln`\n- Run a specific test project: `dotnet test core/test/unit/Elsa.Workflows.Core.UnitTests/Elsa.Workflows.Core.UnitTests.csproj`\n- Run ElsaScript DSL integration tests: `./run-dsl-tests.sh`\n\nPrefer targeted `dotnet test <project>` commands while iterating, then run a broader build or test command when the change affects shared infrastructure or cross-module behavior.\n\n## Code Style\n\n- C# uses `LangVersion` `latest`, nullable reference types, and implicit usings from `Directory.Build.props`.\n- Product source libraries target `net8.0`, `net9.0`, and `net10.0` through their product `src/Directory.Build.props`; hosts and tests may select a specific framework.\n- Follow `.editorconfig`: 4-space indentation for C#, file-scoped namespaces, braces required, `var` preferred, usings outside namespaces, and sorted system directives.\n- Prefer clear domain names over abbreviations. Keep types small and responsibilities explicit.\n- Avoid suppressing warnings unless compatibility or framework constraints make the warning unavoidable; explain the reason near the suppression.\n\n## Repository Structure\n\n- `core/src/apps/`, `core/src/clients/`, `core/src/common/`, `core/src/modules/`: Core hosts, clients, shared infrastructure and modules.\n- `core/test/`: Core unit, integration, component and performance tests.\n- `extensions/src/`, `extensions/test/`, `extensions/docs/`, `extensions/samples/`: Extensions-owned code, tests, documentation and samples.\n- `studio/react/`: React Studio Preview frontend and host; read its contributor guidance.\n- `studio/src/`, `studio/test/`, `studio/docs/`, `studio/samples/`: Studio-owned code, tests, documentation and samples. Read [Studio contributor guidance](studio/src/AGENTS.md) for Studio modules, hosts, frameworks and tests.\n- `apps/src/`, `apps/scripts/`, `apps/docs/`: official net10 application/image hosts, container policy tests and source-import guidance. Read [Apps agent guidance](apps/AGENTS.md). Apps consumes released packages and does not add Core NuGet release units.\n- `templates/src/`, `templates/test/`, `templates/docs/`: independent Elsa 3 .NET project-template pack, smoke tests and contributor guidance. Embedded starter project files are data; keep all Templates projects outside root `Elsa.sln` packing.\n- `core/docs/specs/` and `studio/docs/specs/`: product feature plans and specifications.\n- `docs/adr/`: shared architecture decisions; `docs/integration-program/`: retained consolidation and proof records.\n- `build/`, `scripts/`, `docker/`, root solution/filter files and central `Directory.*` files: shared tooling and policy.\n- `design/`: shared design assets; `core/docs/design/`: Core persistence design notes.\n\n## Architecture Decision Records\n\n- ADRs live in `docs/adr/`. New records are named `YYYY-MM-DD-slug.md`, and the `# ` heading carries the\n  title alone with no numeric prefix. Do not continue the legacy `NNNN-` sequence: it collided on every\n  concurrent branch, which is what the date prefix exists to stop.\n- Records `0001`-`0027` keep their existing names and headings. Do not renumber or rename them.\n- `docs/adr/toc.md` is generated. Never edit it by hand: run `scripts/adr/generate-toc.sh` and commit the\n  result. `scripts/adr/generate-toc.sh --check` verifies it is current, and CI runs the same check.\n- The rationale is recorded in\n  [Identify new ADRs by date instead of a sequential number](docs/adr/2026-08-25-date-prefixed-adr-identifiers.md).\n\n## Testing Guidance\n\n- Place tests near the relevant existing test project rather than creating a new project by default.\n- Use the existing shared testing helpers under `core/src/common/Elsa.Testing.Shared*` when they fit the scenario.\n- For regressions, add a failing test that demonstrates the bug before or alongside the fix.\n- For multi-targeting issues, consider whether the test must run against all target frameworks or only the affected one.\n\n## Dependency And Package Guidance\n\n- Central package versions are managed in the root and product `Directory.Packages.props` files; do not add ad hoc versions to individual project files unless the repository already uses that pattern for the package.\n- Keep target framework changes centralized in the relevant product `src/Directory.Build.props` unless a project has a specific reason to differ.\n- Be cautious with package upgrades because this repository targets multiple frameworks and modules.\n\n## Review Checklist\n\nBefore handing off changes, verify the following when applicable:\n\n- The project or solution builds.\n- Relevant unit or integration tests pass.\n- Public API or behavior changes are documented.\n- New code follows nullable annotations and existing style.\n- No unrelated files were changed.\n- The change follows `.github/quality/PRINCIPLES.md`, which is the bar for public API, simplicity, domain language, tests, CI and docs. In particular, public API changes in 3.x deprecate rather than break (principle 6). `.github/quality/README.md` explains the audit and fix loop and its labels.\n","isInternal":false,"tokens":1764,"sizeBytes":8016},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","rawUrl":"https://raw.githubusercontent.com/elsa-workflows/elsa-core/HEAD/.github/copilot-instructions.md","title":"GitHub Copilot Instructions","category":"copilot-instructions","format":"markdown","content":"# Elsa 3 coding instructions\n\nFollow the repository [AGENTS.md](../AGENTS.md) for scope, code style, tests, package versions, and ADR rules. Check the current issue and source before changing behavior. This file is a short map for the consolidated product layout; it does not authorize publishing packages or archiving source repositories.\n\n## Source and development workflow\n\n- `core/src/modules/`, `core/src/common/`, `core/src/clients/`, and `core/src/apps/` contain the Core backend and hosts.\n- `extensions/src/` contains imported Extensions modules and connectors. Keep public package IDs and activity identities stable during consolidation.\n- `studio/src/` contains Blazor Studio framework, modules, hosts, browser bundles, and tests. Use the [Studio development guide](../studio/docs/README.md) for current paths, local backend binding, and paired debugging. The former standalone Studio instructions remain only as [import provenance](../docs/integration-program/legacy/studio/.github/copilot-instructions.md.source).\n- Open the canonical [`Elsa.sln`](../Elsa.sln) for backend and Studio changes together. Use the targeted project or test when iterating; run broader checks when a shared dependency or build integration changes.\n\nThe Studio Designer and DomInterop ClientLib projects require Node 22. From the repository root, build their browser assets with:\n\n```sh\n./scripts/integration-program/build_studio_clientlibs.sh\n```\n\nThen build the affected .NET projects or `dotnet build Elsa.sln`. Production projects target net8.0, net9.0, and net10.0 unless a project explicitly overrides the shared target frameworks. Run the relevant tests with `dotnet test <project> --framework net10.0`; include the other target frameworks when the change affects multi-target behavior. Studio has tests, so do not treat an empty `dotnet test` run as proof of coverage.\n\nFor a local backend/Blazor session, follow the Studio guide's separate backend and `Elsa.Studio.Host.Server` hosts and its ignored `appsettings.Local.json` URL binding. Keep local credentials and client secrets out of tracked files. Do not assume a backend route exists merely because a Studio client declares it; verify the actual host configuration and permissions.\n\n## Build, compatibility, and releases\n\nCentral package versions live in `Directory.Packages.props`; framework defaults live in each product’s `src/Directory.Build.props`. Prefer the repository's existing build and test commands in `AGENTS.md`. Investigate restore or build failures rather than changing package versions to a guessed \"nearest\" version or masking a required source failure.\n\nThe [integration program](../docs/integration-program/README.md) records import evidence, package boundaries, and pending gates. Imported Extensions/Studio publishers are retained as inert provenance. The [first consolidated release policy](../docs/adr/2026-09-28-lockstep-consolidated-release-and-publisher-cutover.md) governs lockstep 3.10 and the single Core publisher. The earlier [release-unit manifest](../docs/integration-program/release-units.json) and [publisher handoff](../docs/integration-program/publisher-handoff.md) retain their bounded proof scope; they do not establish live publisher cutover. Do not enable a publisher, push a package to a feed, or treat a local proof version as a release allocation without the program's explicit cutover approval.\n\nThe history-bearing import landed through [PR #8409](https://github.com/elsa-workflows/elsa-core/pull/8409), with later source/release catch-up through [PR #8624](https://github.com/elsa-workflows/elsa-core/pull/8624). Preserve that history and check current source pins and exact-head CI before claiming acceptance of a relocated tree. Do not replace imported source with a local checkout.\n","isInternal":false,"tokens":800,"sizeBytes":3788},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/elsa-workflows/elsa-core/HEAD/.claude-plugin/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elsa-workflows/elsa-core/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":203},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/elsa-workflows/elsa-core/HEAD/.claude-plugin/plugin.json","title":"claude-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elsa-workflows/elsa-core/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":189},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/elsa-workflows/elsa-core/HEAD/.cursor/mcp.json","title":"Model Context Protocol (MCP) Configuration","category":"mcp-config","format":"json","content":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elsa-workflows/elsa-core/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":182}],"systemPromptSnippet":"<yakaai_skills repo=\"elsa-workflows/elsa-core\">\n<!-- File: AGENTS.md (Tokens: ~1764 | Category: root-instruction) -->\n# AGENTS.md\n\nGuidance for AI coding agents working in this repository.\n\n## Project Overview\n\n- Elsa Core is a .NET solution centered on `Elsa.sln`.\n- Products live under `core/`, `extensions/`, `studio/`, `apps/`, and `templates/`. Apps contains official released-package application hosts and Python container-policy tests under `apps/scripts/tests/`; its contributor entrypoint is [Apps](apps/README.md).\n- The root solution, solution filters, build automation, scripts and central policy are shared. Templates keeps its independent product solution; root `Elsa.sln` includes navigation items only for that product.\n- Read the product documentation entrypoints: [Core](core/docs/README.md), [Extensions](extensions/docs/README.md), [Studio](studio/docs/README.md), [Apps](apps/docs/README.md), and [Templates](templates/docs/README.md).\n- Build automation is implemented with NUKE in `build/Build.cs` and exposed through `build.sh`, `build.ps1`, and `build.cmd`.\n\n## Working Rules\n\n- Keep changes focused on the requested task. Do not mix unrelated cleanup, formatting, or dependency updates into functional changes.\n- Preserve existing public APIs unless the task explicitly requires an API change.\n- Update tests when behavior changes and add tests for new behavior where practical.\n- Update documentation when changing externally visible behavior, configuration, APIs, or developer workflows.\n- Do not delete generated-looking, artifact, or IDE files unless the task explicitly asks for cleanup.\n- If the worktree contains unrelated user changes, leave them untouched.\n- Before opening a PR, read `.github/reviewers.md`: Greptile is required (re-request with `@greptileai` after each push), and request at most one additional advisory reviewer from the list once the PR is open.\n\n## Agent Operating Principles\n\n- Do not assume, hide confusion, or flatten uncertainty; surface questions, constraints, and tradeoffs explicitly.\n- Write the minimum code that solves the defined problem; do not add speculative abstractions, features, or cleanup.\n- Touch only the files and behavior required for the task; clean up only issues introduced by your own changes.\n- Define success criteria before implementation, then iterate until the criteria are verified or clearly state what could not be verified.\n\n## Build And Test Commands\n\n- Build the default target: `./build.sh`\n- Run NUKE test target: `./build.sh Test`\n- Build with dotnet directly: `dotnet build Elsa.sln`\n- Focus a product build with `dotnet build Elsa.Core.slnf`, `dotnet build Elsa.Extensions.slnf`, `dotnet build Elsa.Studio.slnf`, or `dotnet build Elsa.Apps.slnf`; see product docs for selection boundaries.\n- Build Templates separately: `dotnet build Elsa.Templates.slnf` or `dotnet build templates/Elsa.Templates.slnx`; test with `dotnet test templates/test/Elsa.Templates.Tests/Elsa.Templates.Tests.csproj`. Read [Templates guidance](templates/AGENTS.md) before changing that product.\n- Run shared-solution tests directly: `dotnet test Elsa.sln`\n- Run a specific test project: `dotnet test core/test/unit/Elsa.Workflows.Core.UnitTests/Elsa.Workflows.Core.UnitTests.csproj`\n- Run ElsaScript DSL integration tests: `./run-dsl-tests.sh`\n\nPrefer targeted `dotnet test <project>` commands while iterating, then run a broader build or test command when the change affects shared infrastructure or cross-module behavior.\n\n## Code Style\n\n- C# uses `LangVersion` `latest`, nullable reference types, and implicit usings from `Directory.Build.props`.\n- Product source libraries target `net8.0`, `net9.0`, and `net10.0` through their product `src/Directory.Build.props`; hosts and tests may select a specific framework.\n- Follow `.editorconfig`: 4-space indentation for C#, file-scoped namespaces, braces required, `var` preferred, usings outside namespaces, and sorted system directives.\n- Prefer clear domain names over abbreviations. Keep types small and responsibilities explicit.\n- Avoid suppressing warnings unless compatibility or framework constraints make the warning unavoidable; explain the reason near the suppression.\n\n## Repository Structure\n\n- `core/src/apps/`, `core/src/clients/`, `core/src/common/`, `core/src/modules/`: Core hosts, clients, shared infrastructure and modules.\n- `core/test/`: Core unit, integration, component and performance tests.\n- `extensions/src/`, `extensions/test/`, `extensions/docs/`, `extensions/samples/`: Extensions-owned code, tests, documentation and samples.\n- `studio/react/`: React Studio Preview frontend and host; read its contributor guidance.\n- `studio/src/`, `studio/test/`, `studio/docs/`, `studio/samples/`: Studio-owned code, tests, documentation and samples. Read [Studio contributor guidance](studio/src/AGENTS.md) for Studio modules, hosts, frameworks and tests.\n- `apps/src/`, `apps/scripts/`, `apps/docs/`: official net10 application/image hosts, container policy tests and source-import guidance. Read [Apps agent guidance](apps/AGENTS.md). Apps consumes released packages and does not add Core NuGet release units.\n- `templates/src/`, `templates/test/`, `templates/docs/`: independent Elsa 3 .NET project-template pack, smoke tests and contributor guidance. Embedded starter project files are data; keep all Templates projects outside root `Elsa.sln` packing.\n- `core/docs/specs/` and `studio/docs/specs/`: product feature plans and specifications.\n- `docs/adr/`: shared architecture decisions; `docs/integration-program/`: retained consolidation and proof records.\n- `build/`, `scripts/`, `docker/`, root solution/filter files and central `Directory.*` files: shared tooling and policy.\n- `design/`: shared design assets; `core/docs/design/`: Core persistence design notes.\n\n## Architecture Decision Records\n\n- ADRs live in `docs/adr/`. New records are named `YYYY-MM-DD-slug.md`, and the `# ` heading carries the\n  title alone with no numeric prefix. Do not continue the legacy `NNNN-` sequence: it collided on every\n  concurrent branch, which is what the date prefix exists to stop.\n- Records `0001`-`0027` keep their existing names and headings. Do not renumber or rename them.\n- `docs/adr/toc.md` is generated. Never edit it by hand: run `scripts/adr/generate-toc.sh` and commit the\n  result. `scripts/adr/generate-toc.sh --check` verifies it is current, and CI runs the same check.\n- The rationale is recorded in\n  [Identify new ADRs by date instead of a sequential number](docs/adr/2026-08-25-date-prefixed-adr-identifiers.md).\n\n## Testing Guidance\n\n- Place tests near the relevant existing test project rather than creating a new project by default.\n- Use the existing shared testing helpers under `core/src/common/Elsa.Testing.Shared*` when they fit the scenario.\n- For regressions, add a failing test that demonstrates the bug before or alongside the fix.\n- For multi-targeting issues, consider whether the test must run against all target frameworks or only the affected one.\n\n## Dependency And Package Guidance\n\n- Central package versions are managed in the root and product `Directory.Packages.props` files; do not add ad hoc versions to individual project files unless the repository already uses that pattern for the package.\n- Keep target framework changes centralized in the relevant product `src/Directory.Build.props` unless a project has a specific reason to differ.\n- Be cautious with package upgrades because this repository targets multiple frameworks and modules.\n\n## Review Checklist\n\nBefore handing off changes, verify the following when applicable:\n\n- The project or solution builds.\n- Relevant unit or integration tests pass.\n- Public API or behavior changes are documented.\n- New code follows nullable annotations and existing style.\n- No unrelated files were changed.\n- The change follows `.github/quality/PRINCIPLES.md`, which is the bar for public API, simplicity, domain language, tests, CI and docs. In particular, public API changes in 3.x deprecate rather than break (principle 6). `.github/quality/README.md` explains the audit and fix loop and its labels.\n\n<!-- File: .github/copilot-instructions.md (Tokens: ~800 | Category: copilot-instructions) -->\n# Elsa 3 coding instructions\n\nFollow the repository [AGENTS.md](../AGENTS.md) for scope, code style, tests, package versions, and ADR rules. Check the current issue and source before changing behavior. This file is a short map for the consolidated product layout; it does not authorize publishing packages or archiving source repositories.\n\n## Source and development workflow\n\n- `core/src/modules/`, `core/src/common/`, `core/src/clients/`, and `core/src/apps/` contain the Core backend and hosts.\n- `extensions/src/` contains imported Extensions modules and connectors. Keep public package IDs and activity identities stable during consolidation.\n- `studio/src/` contains Blazor Studio framework, modules, hosts, browser bundles, and tests. Use the [Studio development guide](../studio/docs/README.md) for current paths, local backend binding, and paired debugging. The former standalone Studio instructions remain only as [import provenance](../docs/integration-program/legacy/studio/.github/copilot-instructions.md.source).\n- Open the canonical [`Elsa.sln`](../Elsa.sln) for backend and Studio changes together. Use the targeted project or test when iterating; run broader checks when a shared dependency or build integration changes.\n\nThe Studio Designer and DomInterop ClientLib projects require Node 22. From the repository root, build their browser assets with:\n\n```sh\n./scripts/integration-program/build_studio_clientlibs.sh\n```\n\nThen build the affected .NET projects or `dotnet build Elsa.sln`. Production projects target net8.0, net9.0, and net10.0 unless a project explicitly overrides the shared target frameworks. Run the relevant tests with `dotnet test <project> --framework net10.0`; include the other target frameworks when the change affects multi-target behavior. Studio has tests, so do not treat an empty `dotnet test` run as proof of coverage.\n\nFor a local backend/Blazor session, follow the Studio guide's separate backend and `Elsa.Studio.Host.Server` hosts and its ignored `appsettings.Local.json` URL binding. Keep local credentials and client secrets out of tracked files. Do not assume a backend route exists merely because a Studio client declares it; verify the actual host configuration and permissions.\n\n## Build, compatibility, and releases\n\nCentral package versions live in `Directory.Packages.props`; framework defaults live in each product’s `src/Directory.Build.props`. Prefer the repository's existing build and test commands in `AGENTS.md`. Investigate restore or build failures rather than changing package versions to a guessed \"nearest\" version or masking a required source failure.\n\nThe [integration program](../docs/integration-program/README.md) records import evidence, package boundaries, and pending gates. Imported Extensions/Studio publishers are retained as inert provenance. The [first consolidated release policy](../docs/adr/2026-09-28-lockstep-consolidated-release-and-publisher-cutover.md) governs lockstep 3.10 and the single Core publisher. The earlier [release-unit manifest](../docs/integration-program/release-units.json) and [publisher handoff](../docs/integration-program/publisher-handoff.md) retain their bounded proof scope; they do not establish live publisher cutover. Do not enable a publisher, push a package to a feed, or treat a local proof version as a release allocation without the program's explicit cutover approval.\n\nThe history-bearing import landed through [PR #8409](https://github.com/elsa-workflows/elsa-core/pull/8409), with later source/release catch-up through [PR #8624](https://github.com/elsa-workflows/elsa-core/pull/8624). Preserve that history and check current source pins and exact-head CI before claiming acceptance of a relocated tree. Do not replace imported source with a local checkout.\n\n<!-- File: .claude-plugin/marketplace.json (Tokens: ~300 | Category: marketplace) -->\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elsa-workflows/elsa-core/HEAD/.claude-plugin/marketplace.json)\n\n<!-- File: .claude-plugin/plugin.json (Tokens: ~300 | Category: plugin-manifest) -->\n# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elsa-workflows/elsa-core/HEAD/.claude-plugin/plugin.json)\n\n<!-- File: .cursor/mcp.json (Tokens: ~300 | Category: mcp-config) -->\n# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elsa-workflows/elsa-core/HEAD/.cursor/mcp.json)\n</yakaai_skills>"}