HX111 Production Code Lab Workflow

HX111 turns a source file into a repeatable HyperionX extension build. Code Lab compiles one custom project; it is not a one-file runner or a per-script NuGet project.

Lesson 1: Choose A Runtime-Enabled Contract

The established HyperionX 1.1.10 authoring path discovers the HyperionX.Custom indicator, strategy, add-on, bar-type, optimizer, fitness, money-management, and commission models described in API Status And Compatibility.

The active release-candidate source also contains a runtime host generator for direct HyperionX.SDK.IndicatorBase and HyperionX.SDK.StrategyBase subclasses. It maps the SDK lifecycle into native hosts, but it remains Preview and unreleased until the exact signed installer includes and validates it. Continue to use HyperionX.Custom for public examples and distributable 1.1.10 extensions; do not treat OnInitialize, OnBar(int), or OnDispose as the established release-safe lifecycle.

Start from the closest Code Lab template and verify the current namespace, base type, lifecycle, and API reference before using a method copied from another platform.

Lesson 2: Understand The Atomic Build

The source root is:

%USERPROFILE%\Documents\HyperionX\Bin\Custom

Code Lab compiles every .cs file below that tree except build-output folders. One unrelated syntax error, duplicate public class, missing reference, or generated-helper conflict can block the complete build.

The supported loop is:

1. Save the source in the matching category folder.
2. Disable affected running strategies and remove affected indicator/extension instances.
3. Select Build.
4. Fix the first compiler error and rebuild.
5. Create a fresh instance in the real host.
6. Verify an explicit output and inspect Logs.
7. Repeat the build/reload once to test cleanup.

Moving a broken .cs file to another folder under Custom does not exclude it. Move it outside the tree or change its extension while diagnosing.

Lesson 3: Do Not Assume Hot Replacement

Code Lab loads a new collectible custom assembly after a successful build, but an existing indicator or strategy object still belongs to the assembly that created it.

• Disable a running strategy before rebuilding.
• If it remained enabled during the build, toggling Enabled off/on afterward reuses that old object.
• Remove and add the strategy again, or reload the owning chart/strategy host.
• Apply the same fresh-instance rule to indicators and other in-process extensions.

A successful build proves compilation and discovery; it does not prove that an already-open object changed code.

Lesson 4: Use Supported Indicator Declarations

In the active release-candidate source, Code Lab, Script Editor, and runtime source refresh use the same indicator-support generator. Both block-scoped and file-scoped namespaces are supported. A generated helper still requires the indicator class to declare the direct Indicator base:

namespace HyperionX.Custom.Indicators
{
    public class MyIndicator : Indicator
    {
        // Current HyperionX lifecycle.
    }
}

An indirect subclass can be discovered as an indicator, but the current helper generator recognizes only the directly declared Indicator base. Do not paste a generated cache region into customer source. Because the shared generator changes are still in candidate source, verify helper compilation and runtime activation against the exact signed target build before distribution.

Lesson 5: Separate Compile Checks From Runtime Checks

Compilation catches syntax, type, namespace, reference, and some generated-code problems. It does not prove:

• bar-index guards are correct
• rendering survives scroll, zoom, resize, or theme changes
• an order workflow handles rejection, cancellation, or partial fills
• events and resources are released on reload
• a provider supplies the data capability the extension expects

Test the extension in its real host. Follow the type-specific matrix in Build, Test, And Debug.

Lesson 6: Respect The Dependency Boundary

Code Lab compiles against the assemblies provided by the installed application. It does not restore an arbitrary project-level NuGet graph for each script.

• Do not add PackageReference and assume the Build button restores it.
• Do not copy HyperionX binaries into a distributed source package.
• Treat manually copied third-party DLLs as unsupported unless a deployment contract documents them.
• Use an external process plus the provisioned Preview Local Desktop API when a separate package graph or process boundary is required.

Lesson 7: Import And Share Carefully

Tools > Import copies executable C# into the custom project. Review the source before building.

The 1.1.10 import classifier recognizes direct platform base declarations more reliably than the normal generated Strategy and Indicator aliases. A valid alias-based script can be labeled as an Addon during import even though runtime discovery later identifies its actual type. Manual placement in the matching source folder is more predictable when classification is wrong.

Never import a module from an untrusted source to work around a missing public-installer prerequisite. Follow Share And Deploy Extensions.

Lesson 8: Create A Supportable Failure Record

For a build or runtime failure, preserve:

• HyperionX version
• script name, version, category, and source revision
• first compiler error and full build summary
• exact host and reproduction steps
• provider/instrument/timeframe when relevant
• expected and actual result
• exported support archive after inspecting it for sensitive data

Use concise Print, Log, or Ctx.Log output during a bounded diagnostic run. Remove high-frequency per-tick logging before normal use.

Completion Check

• The full custom project builds with zero errors.
• The script uses a runtime-enabled 1.1.10 contract.
• A fresh instance was created after the build.
• Indicator helper generation was tested through a dependent script when applicable.
• Runtime behavior was checked in the actual chart/research/order host.
• The package contains source and instructions, not copied HyperionX binaries or secrets.