InkkOops

Host integration

This page explains how an app host plugs into InkkOops. It focuses on configuration, runtime startup, policy injection, and the boundary between reusable runtime code and repository-specific host behavior.

What the host owns

The host owns the profile. The runtime core does not decide which scripts exist, where artifacts go, how replay tail behavior works, or how diagnostics are formatted. Those choices come from InkkOopsHostConfiguration.

  • Default pipe name
  • Default artifact root
  • Default recording root
  • Script catalog
  • Artifact naming policy
  • Replay postamble policy
  • Diagnostics contributors and serializer

Typical startup wiring

var hostConfiguration =
    InkkOopsHostConfiguration.CreateDefault(typeof(Game1).Assembly);

var gameHost = new InkkOopsGameHost(this, hostConfiguration);
var runtimeService = new InkkOopsRuntimeService(
    gameHost,
    runtimeOptions,
    hostConfiguration,
    exitCode =>
    {
        Environment.ExitCode = exitCode;
        Exit();
    });

This is the common pattern in this repository. The app creates the host configuration once, gives it to the game-host adapter, and gives the same configuration to the runtime service.

Default profile in this repository

  • Pipe name: InkkOops
  • Run root: artifacts/inkkoops
  • Recording root: artifacts/inkkoops-recordings
  • Script catalog: reflection-backed built-in scripts from the app assembly
  • Replay tail: wait for diagnostics stability, capture final frame, dump final telemetry

These are repository defaults. They are not core runtime requirements.

Customizing the profile

var configuration = new InkkOopsHostConfiguration
{
    DefaultPipeName = "inkkoops-dev",
    DefaultArtifactRoot = Path.Combine("artifacts", "inkkoops-dev"),
    DefaultRecordingRoot = Path.Combine("artifacts", "inkkoops-dev-recordings"),
    ScriptCatalog = new ReflectionInkkOopsScriptCatalog(typeof(Game1).Assembly),
    ArtifactNamingPolicy = new DefaultInkkOopsArtifactNamingPolicy()
};

The host can replace the catalog, naming policy, and default paths. Runtime telemetry capture is built into the host rather than supplied through contributor and serializer services.

Catalog strategies

There are two useful patterns.

Reflection-backed catalog

Best when built-in scripts are part of the host assembly and you want low-friction discovery during local framework development.

Explicit catalog

Best when you want strict registration, modular packages, or environment-specific script exposure.

Diagnostics registration

The visual-tree dump is built from contributors. The host chooses which contributors are installed and in what order. This lets framework-specific diagnostics stay detailed without requiring the core runtime to own every control-specific fact.

Host-specific scripts stay host-specific

Scripts that depend on ControlsCatalogView, CatalogSidebarScrollViewer, or other demo-surface identifiers belong in the repository host layer. They are valid and useful, but they are examples of host data, not infrastructure.

When to create a new host profile

  • You want different default roots for CI, local development, or per-branch runs.
  • You want a different script catalog for a different app shell.
  • You want replay to append different proof commands.
  • You want a different diagnostics serializer or contributor set.