Declaring capability across both layers, publishing the session ports, keeping saved profiles byte-compatible, and passing the two merge gates every trading venue is held to.

Two capability layers

A broker declares capability twice, at two different times, and the two are not redundant.

Narrowing at runtime is not a bug — it is the point. A broker whose Flex credentials are absent genuinely cannot serve trade history this session, and expresses that by not publishing the port. The host logs a wider-than-declared port as a venue bug at bring-up.

Declaring honestly

Flags are deliberately fine-grained so a partial implementation can declare exactly what it supports. A read-only "show me my live positions" phase declares AccountDiscovery | PositionStream and nothing else; the UI greys out the rest instead of throwing at click time.

Synthesised capabilities

A capability your plugin implements by synthesis still counts — declare it. Modify via cancel-replace is ModifyOrders. Flatten via cancel-all plus market-close is FlattenPositions. The contract kit then pins that the declared capability actually works, which is exactly the check that keeps a synthesis honest as the vendor API drifts.

Session ports

Side channels are ordinary session ports, probed with AsPort<T>() and registered by the host's port registrar while the session is connected. Declare the matching manifest flag so the registrar looks for them.

IVenueCashActivitySource.cspublic sealed record VenueCashActivity(
    string AccountId,            // the VENUE's raw account id — the host recorder scopes it
    CashActivityKind Kind,
    decimal Amount,              // NORMATIVE sign: positive = collected, negative = paid
    string Currency,
    DateTime TimestampUtc,
    string VenueTransactionId);  // the dedup identity

public interface IVenueCashActivitySource
{
    Task<IReadOnlyList<VenueCashActivity>> GetCashActivityAsync(
        DateTime sinceUtc, CancellationToken ct = default);
}

Settings & credential rotation

A broker's legacy profile JSON typically nests: a UsePaper boolean at the root, a PlainValues object, a ProtectedSecretsBase64 object, and a GatewaySecretsBase64 bag for vendor tokens. All of it rides the schema's dotted StorageName mechanism, so the shape survives the move byte-for-byte.

Broker settings schemaSettingsSchema: new[]
{
    new ProviderCredentialField("UsePaper", "Paper trading",
        ProviderCredentialKind.Toggle, Required: false, DefaultValue: "false"),

    new ProviderCredentialField("Environment", "Environment",
        ProviderCredentialKind.Choice,
        Choices: new[] { "Live", "Demo" },
        StorageName: "PlainValues.Environment"),

    new ProviderCredentialField("ClientId", "Client ID",
        ProviderCredentialKind.Plain,
        StorageName: "PlainValues.ClientId"),

    new ProviderCredentialField("ClientSecret", "Client secret",
        ProviderCredentialKind.Secret,
        StorageName: "ProtectedSecretsBase64.ClientSecret"),

    // Rotating OAuth tokens: written back through IVenueCredentialWriter and stored
    // in the legacy encrypted bag, so the next start does not re-prompt for login.
    new ProviderCredentialField("RefreshToken", "Refresh token",
        ProviderCredentialKind.Secret, Required: false, ReadOnly: true,
        StorageName: "GatewaySecretsBase64.refresh_token"),
}

Persisting a refresh// After every successful token refresh — not just the first.
context.Credentials.Persist(new Dictionary<string, string>
{
    ["AccessToken"]  = tokens.Access,
    ["RefreshToken"] = tokens.Refresh,
});

The trading contract kit

TradingProviderContractKit (in SabrTrader.Pipeline.Venues.Tests) is the merge gate for any direct ITradingProvider implementation. You supply a harness — a connected provider over a scripted venue double — and the kit drives the incident-derived behavioural contracts through it.

ITradingProviderContractHarness.cspublic interface ITradingProviderContractHarness : IAsyncDisposable
{
    ITradingProvider Provider { get; }        // connected, under test
    AccountId Account { get; }                // must appear in Provider.Accounts

    OrderRequest CreateRestingOrderRequest(); // acked Working, never filled unprompted
    Task FillCompletelyAsync(Order order);    // script the venue to fill it
}

public sealed class MyBrokerContractTests : TradingProviderContractKit
{
    protected override async Task<ITradingProviderContractHarness> CreateConnectedHarnessAsync()
        => await MyBrokerHarness.StartAsync();
}

The seam conformance kit

Every venue, trading or not, also subclasses VenuePluginConformanceKit — loader compatibility, manifest validity, verbatim legacy TypeIds, schema well-formedness, contracts-only references, offline lifecycle safety. See Instruments & discovery for the full check list.

MyBrokerConformanceTests.cspublic sealed class MyBrokerVenuePluginConformanceTests : VenuePluginConformanceKit
{
    protected override IVenuePlugin CreatePlugin() => new MyBrokerVenuePlugin();
    protected override IReadOnlyList<string> LegacyTypeIds => new[] { "mybroker" };
}

Shipping the broker

• One DLL per broker, publishing the FULL transitive vendor closure from its CopyLocalLockFileAssemblies bin — never a hand-written dependency list.
• Native assets (runtimes\) and content files ship with it. A vendor sidecar in the app root resolves through the plugin load context's last-chance hook.
• Build with -p:SkipPluginDeploy=true when an app instance may hold the DLL.
• Run all three suites before merging: your own tests, the conformance kit, and the trading contract kit.