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,协调交付并发出有界观测。
AI Analysis
核心用途是提供独立于宿主的 Agent 工作流执行与审计边界。适合需要对 Agent 交付过程进行版本控制和 OTLP 观测的系统集成任务。
Install
This plugin has no verified bundle, or compatibility checks failed. Read the repository notes first. Read the full README ↗
README
Read the full 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