/**
 * multiMachineCapstoneMatrix — the §7.5 scenario matrix for the cross-machine
 * transfer capstone (docs/specs/live-user-channel-proof-standard.md §7.5). It is
 * the deterministic list of risk-categorised scenarios the LiveTestHarness runs
 * AFTER the seat has been moved to the target machine, each asserting the reply was
 * served FROM that machine (the cross-machine proof).
 *
 * The builder is a PURE function (no IO, no clock) so the route can construct the
 * matrix and a unit test can assert the exact scenario set / risk-category coverage.
 * Every move-to-target scenario sets `expect.responderMachine = targetMachine` — the
 * deterministic protocol evidence the harness verdicts on.
 *
 * Scenario design (the eight §7.5 categories):
 *   - idle-move             happy-path  — a calm topic moves, the reply comes from target.
 *   - active-drain          lifecycle   — an active conversation's transfer COMPLETES (drain leg).
 *   - reverse-move          happy-path  — moving back also lands on the (re-)target.
 *   - telegram-vs-slack     channel-parity — both surfaces reply from the same target.
 *   - offline-target-refusal failure-rollback — a refused move records the refusal, not a fake PASS.
 *   - crash-mid-move-single-owner failure-rollback — only ONE owner survives a crash mid-move.
 *   - false-positive-guard  regression  — a transfer that didn't move reports it (the #1188 honesty fix).
 *   - repeat-transfer       idempotency — re-issuing the same transfer is a stable no-op move.
 *
 * The failure-rollback / crash / refusal scenarios are SAFE-volatility here because
 * they target the SAME demo topic/channel the move uses (no destructive side effect —
 * they assert the transfer's HONESTY, they do not run a dangerous operation). A
 * genuinely destructive permission scenario would be marked volatile and the harness's
 * §5.3 guard would refuse it on a non-demo channel.
 */
import type { HarnessMatrix } from './LiveTestHarness.js';
export interface CapstoneMatrixOpts {
    featureId?: string;
    /** The machine the seat moved to — also the expected responder for every move-to-target scenario. */
    targetMachine: string;
    /** The throwaway Telegram topic id (the placement key the responder reader uses). */
    telegramTopicId: string;
    /** Optional Slack channel id — present ⇒ the channel-parity half runs. */
    slackChannelId?: string;
    /** The user message each scenario sends. */
    message: string;
    /** Per-scenario reply timeout. */
    timeoutMs?: number;
}
/**
 * Build the §7.5 capstone matrix. Telegram-only when `slackChannelId` is absent (the
 * channel-parity scenario is omitted, not faked). Deterministic — same inputs, same
 * matrix.
 */
export declare function buildMultiMachineCapstoneMatrix(opts: CapstoneMatrixOpts): HarnessMatrix;
//# sourceMappingURL=multiMachineCapstoneMatrix.d.ts.map