wsr-execution
Host-neutral execution boundary for workflow-self-recursive: resolves and validates one exact Workflow Package, binds an immutable Delivery Manifest, coordinates the Delivery, and emits bounded OTLP observations. · 与宿主无关的 Agent 工作流执行边界:解析并校验确定的 Workflow Package,绑定不可变 Delivery Manifest,协调交付并发出有界观测。
安装
此插件尚未提供可验证的 bundle,或兼容性检查未通过。请先阅读仓库说明。 阅读完整 README ↗
说明文档
阅读完整 README ↗Workflow Self-Recursive — Execution System
English | 中文

Turn every agent conversation into an auditable, recoverable, version-bound delivery.
The Execution System is the host-neutral execution boundary of workflow-self-recursive: it resolves and validates one exact Workflow Package, binds it in an immutable Delivery Manifest, coordinates the Delivery inside an isolated Runner-owned execution context, recovers from the last durable boundary after crashes, and emits bounded observations over OTLP — observation never controls execution.
Delivery forms (交付形态)
The Execution System is a host-neutral product, not a plugin. DSH is one entry point among several:
| Form | Package | Audience |
|---|---|---|
| Embedded library | wsr-execution | Host-neutral embedding — import ExecutionApplicationFactory and bootstrap with create(configFile, dependencies) |
| DSH plugin entry | wsr-dsh-intake | DeepSeek Harness users — run workflows from chat and sidebar tabs |
| CLI | execution-config (in wsr-execution) | Configuration init / copy / validate / dump-effective |
The DSH plugin is the first product entry; every admitted Workflow Action runs in a Runner-owned, isolated DSH execution context (DSH-E), never in the Intake context (DSH-I).
Why it exists
| Bare agent chat | What actually happens | Execution System |
|---|---|---|
| Execution is a black box | What the model did, and with which workflow definition, cannot be audited afterwards | Every Delivery binds one exact version + SHA-256 into an immutable Manifest |
| Interruptions lose state | After a crash or restart there is nowhere to look | Manifest/current-slot persist; /wsr recover resumes from the last durable boundary |
| Version drift | The same request can execute different definitions at different times | Exact name@version selectors, immutable GitHub assets, and a validated exact-content READY cache |
| Observation couples to execution | A telemetry outage can take the run down with it | One-way, best-effort OTLP; Execution continues when Evidence or telemetry is unavailable |
How it works
Three modules carry the responsibility:
- Delivery Binding resolves one exact, locally
READYWorkflow Package (selector → validation → localMISSING/STAGING/READYstore) and constructs the Manifest content. - Runtime Interaction owns canonical worktree exclusivity, the current Delivery slot, Manifest persistence, Runtime invocation, recovery, and final handling.
- Delivery Observation maps outbound bounded facts to a one-way, best-effort OTLP profile without controlling execution.
The default Source is the configured firestige/workflow-package GitHub Release. implementation-workflow@0.3.0 and system-design-workflow@0.3.0 are downloaded, validated, and published to the local READY store; neither is embedded in an Execution artifact.

Install (DSH entry, one command)
# 1. Approve the better-sqlite3 native build once (pnpm 11)
dsh plugin --profile web config set --location=project --json allowBuilds '{"better-sqlite3":true}'
# 2. Install the Intake entry — the engine (wsr-execution) comes as its dependency
dsh plugin --profile web add wsr-dsh-intake
Requires Node `>=24.12 /wsr recover [delivery-id] /wsr status [delivery-id] /wsr action finish /wsr abandon
The explicit first-party skill `/workflow-execution` performs exactly one closed operation through the DSH-I-only `workflow_execution_intake` tool.
## Compatibility
| Dimension | Requirement |
|---|---|
| Node.js | `>=24.12.0 /.wsr/role-provider-bindings.json` with an exact Provider identity/version and Provider-owned model coordinate. Admission validates required Workflow capabilities, freezes the factory descriptor digest into `execution.delivery-manifest@2.0.0`, and never performs priority selection or fallback. Recovery accepts only the same descriptor and starts realms only for Providers actually used by the persisted Delivery. See `config/schema/execution.config.v2.schema.json`.
The package-root `createCopilotAgentProviderFactory()` registers `provider.copilot@1.0.78`. It imports the SDK bundled by the exact `@github/copilot@1.0.78` platform payload, reuses the local logged-in user through the SDK, and never asks the embedding host for token material. A Delivery realm admits only `github-copilot` model coordinates frozen for its Roles, runs sessions in the canonical worktree with an allowlisted Action tool surface, and fails closed on runtime, login, model, recovery, or binding drift.
## Get the source
This repository is normally consumed as a submodule of [workflow-self-recursive](https://github.com/firestige/workflow-self-recursive):
```sh
git clone --recurse-submodules https://github.com/firestige/workflow-self-recursive.git
To clone it standalone:
git clone https://github.com/firestige/execution-system.git
Documentation
- Execution System design
- Conceptual architecture
- Workflow composition model
- Execution–Evidence interaction contract
- Planned first-party LangGraph runtime profile