feat(operators): add script operation support for DiscoverySpace

[michael-johnston]

This PR adds first-class support for inline script operations on DiscoverySpace instances, so custom sampling code can store measurements under a proper OperationResource without registering an operator plugin or going through orchestrate().

• Introduces ScriptOperatorConf - specifies a "dynamic" operator that doesn't require the operator registry
• Adds DiscoverySpace.operation_context() to create and lifecycle-manage a script operation (CREATED → STARTED → FINISHED/SUCCESS or FAIL), yielding an operation_id for use with Actuators
• Ensures script-run measurements appear in sampledEntities(), space summaries, and ado show operation commands
• Can be used to record any type of operation

Use

Combined with #169 you can now do the following to iterate over a space, make measurements synchronously, store them without ray objects.

  space = DiscoverySpace.from_stored_configuration(
                      project_context=ctx,
                      space_identifier=space_id,
                      )

  actuators = {}
  for experiment in space.measurementSpace.experiments:
      aid = experiment.actuatorIdentifier
      if aid in actuators:
          continue
      actuator_cls = registry.actuatorForIdentifier(aid)
      actuators[aid] = actuator_cls()

  with space.operation_context(
      name="direct-standard-actuator-grid",
      description="Example of iterating over a discrete space",
  ) as operation_id:
      sampler = ExplicitEntitySpaceGridSampleGenerator(mode=WalkModeEnum.SEQUENTIAL)
      request_index = 0
      for batch in sampler.entityIterator(space, batchsize=1):
          for experiment in space.measurementSpace.experiments:
              ref = experiment.reference
              actuator = actuators[ref.actuatorIdentifier]
              completed = actuator.execute(
                  entities=batch,
                  experimentReference=ref,
                  requesterid=operation_id,
                  requestIndex=request_index,
                  use_ray=False,
              )
              space.addMeasurement(completed)
              request_index += 1

Motivation

Developers want to use DiscoverySpace for sampling and result storage from custom scripts or lightweight inline operator logic, perhaps inside an existing operator. Previously this required a registered explore operator in order to create the required OperationResource to associate measurements to (measurements stored without a linked OperationResource were invisible to most ADO query paths.)

[DRL-NextGen]

Checks Summary

Last run: 2026-05-29T09:01:22.823Z

Mend Unified Agent vulnerability scan found 2 vulnerabilities:

Severity	Identifier	Package	Details	Fix
🔷 Medium	CVE-2026-48710	starlette-0.52.1-py3-none-any.whl	Starlette is a lightweight ASGI framework/toolkit. Prior to version 1.0.1, the HTTP "Host" request h... Starlette is a lightweight ASGI framework/toolkit. Prior to version 1.0.1, the HTTP "Host" request header was not validated before being used to reconstruct "request.url". Because the routing algorithm relies on the raw HTTP path while "request.url" is rebuilt from the "Host" header, a malformed header could make "request.url.path" differ from the path that was actually requested. Middleware and endpoints that apply security restrictions based on "request.url" (rather than the raw "scope" path) could therefore be bypassed. Users should upgrade to a version greater than or equal to version 1.0.1, which validates the "Host" header against the grammar of RFC 9112 §3.2 / RFC 3986 §3.2.2 when constructing "request.url" and falls back to "scope["server"]" for malformed values.	Upgrade to version starlette - 1.0.1,starlette - 1.0.1,https://github.com/Kludex/starlette.git - 1.0.1
🔷 Medium	CVE-2026-45409	idna-3.14-py3-none-any.whl	This is the same issue as CVE-2024-3651, however the original remediation in 2024 was not a complete... This is the same issue as CVE-2024-3651, however the original remediation in 2024 was not a complete fix. Payloads such as ""\u0660" * N" or ""\u30fb" * N + "\u6f22"" utilize the "valid_contexto" function prior to length rejection, and for high values of "N" will take a long time to process. Impact A specially crafted argument to the "idna.encode()" function could consume significant resources. This may lead to a denial-of-service. Patches Starting in version 3.14, the function rejects long inputs as soon as practicable prior to any further processing to minimize resource consumption. In version 3.15, this approach was extended to lesser used alternate functions (i.e. per-label conversions and codec support). Workarounds Domain names cannot exceed 253 characters in length, if this length limit is enforced prior to passing the domain to the "idna.encode()" function it should no longer consume significant resources. This is triggered by arbitrarily large inputs that would not occur in normal usage, but may be passed to the library assuming there is no preliminary input validation by the higher-level application.	Upgrade to version idna - 3.15