Expose the execution engine module from the SDK

[xIrusux]

The execution-engine module (MessageBusJobHandler, the job contracts, the progress calculators, step trackers and rehydration registry) lives in core only. A third-party bundle can reach the engine through the DI container but cannot feed the jobs panel that renders a job's progress.

Add the sdk/modules/execution-engine barrel and its module federation entry so bundles can register a MessageBusJobHandler and show the same running-jobs and progress UI as core features.

Changes in this pull request

Resolves #

Additional info

[Copilot]

Pull request overview

Verdict: Needs changes. The PR adds the execution-engine SDK surface and Module Federation entry.

Changes:

• Exposes execution-engine services, hooks, jobs, calculators, trackers, and rehydration APIs.
• Registers the new SDK module federation path.

Review assessment:

• Root cause addressed at assets/rsbuild.sdk.config.ts:147 and the new barrel.
• The SDK boundary is appropriate and additive.
• No existing call sites or compatibility are affected.
• index.ts:32 omits the required PROGRESS_NO_UPDATE sentinel.
• Public SDK documentation is missing.
• No behavioral test gap identified; build/type verification remains unverified.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
assets/rsbuild.sdk.config.ts	Adds the execution-engine federation entry.
assets/js/src/sdk/modules/execution-engine/index.ts	Defines the public execution-engine SDK exports.

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[xIrusux]

Revision summary (2026-09-15)

• Merged 2026.x into the branch (144 commits); the only conflict was the build-dist archive rename, resolved to the base's archive and rebuilt by CI (9cbbd748e, one zip).
• Completed the barrel so every contract it exports is implementable from a bundle: PROGRESS_NO_UPDATE, ProgressResult, ProgressCalculatorContext (the handler checks the sentinel by identity), StepTrackerState, and resolveChildJobRunOptions as the rehydration counterpart of ChildJobStepTracker.
• Deliberately not exported: core job classes (AbstractBatchEditJob, DeleteJob, …), JobRunPolling, the redux slice, notification components. No consumer yet; exporting would freeze their option shapes as public API.
• Docs: new example page doc/04_Extending/02_Plugin_Development_Examples/20_Run_a_Background_Job.md covering the backend contract (Studio execution context, owner, 201 {jobRunId}, state subscriber, progress trait) and the frontend recipe (JobInterface with jobNames/rehydrate, registry registration in onInit, runJob, calculator choice), linked from the examples index and from SDK Imports.
• Verified: check-types, eslint, execution-engine jest (76 tests) locally; all workflows green on 83b7d6eba.

🤖 Generated with Claude Code

[xIrusux]

Barrel trimmed (2026-09-15, 6beeb1c82)

Following review feedback that the export list was wider than needed: dropped getUniqueId (only called by MessageBusJobHandler.createJob()), useJobs (core panel components only), AbstractJob, JobRun (reachable as JobRunList[number]), DefaultStepTracker, ChildJobStepTracker, resolveChildJobRunOptions, ProgressFieldCalculator and BatchedStepProgressCalculator; ExecutionEngine is exported as a type only. What stays is the run/rehydrate set the first consumer imports plus the types needed to implement ProgressCalculator, StepTracker and MessageBusJobHandlerOptions. Adding exports later is additive; removing them on a release line is a BC break. Doc paragraph on calculators adjusted to match.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud