instar 1.3.595 → 1.3.597

package/dist/core/LiveTestRunner.d.ts

@@ -0,0 +1,66 @@
+/**
+ * LiveTestRunner — the orchestrator that APPLIES the live-user-channel-proof standard
+ * to the cross-machine transfer (docs/specs/live-user-channel-proof-standard.md §6 —
+ * the first feature held to the bar). It encodes the capstone flow that a user-role
+ * session runs:
+ *
+ *   1. MOVE THE SEAT FIRST — transfer the (throwaway) topic to the target machine.
+ *      If the transfer reports the seat did NOT move, the capstone premise is false and
+ *      we stop loudly (that "ok:true but moved nothing" lie is the original bug — we
+ *      refuse to paper over it).
+ *   2. Then run the LiveTestHarness over a scenario matrix that sends a real message
+ *      through each channel and asserts the reply was served FROM the target machine
+ *      (the `responderMachine` expectation — the deterministic cross-machine proof).
+ *
+ * This module is pure orchestration over the injected harness + an injected `transfer`
+ * action, so it is unit-testable with fakes. The server.ts route wires the real
+ * RealChannelDriver (real senders + placement reader) into the harness and the real
+ * `POST /pool/transfer` into `transfer`.
+ *
+ * Honesty contract: a non-moved seat THROWS (never records a misleading PASS); a moved
+ * seat that then fails to reply-from-target is a normal harness FAIL (recorded with the
+ * responder mismatch). The artifact only ever shows PASS when the seat moved AND the
+ * reply genuinely came from the target machine.
+ */
+import type { LiveTestHarness } from './LiveTestHarness.js';
+export interface TransferResult {
+    /** Did the seat genuinely move (the honest signal, NOT a bare ok:true)? */
+    seatMoved: boolean;
+    detail?: string;
+}
+export interface MultiMachineCapstoneOpts {
+    featureId?: string;
+    /** The machine the seat must move to (e.g. the Mini's machine id) — also the expected responder. */
+    targetMachine: string;
+    /** The throwaway Telegram topic id (also the placement key the responder reader uses). */
+    telegramTopicId: string;
+    /** Optional Slack channel id for the Slack half of the Telegram-AND-Slack bar. */
+    slackChannelId?: string;
+    /** The real transfer action (server.ts injects POST /pool/transfer). MUST report seatMoved honestly. */
+    transfer: (topicId: string, toMachine: string) => Promise<TransferResult>;
+    /** The user message to send (default a benign probe). */
+    message?: string;
+    timeoutMs?: number;
+    runId?: string;
+}
+export declare class LiveTestRunnerError extends Error {
+    constructor(message: string);
+}
+export declare class LiveTestRunner {
+    private readonly deps;
+    constructor(deps: {
+        harness: LiveTestHarness;
+        logger?: (m: string) => void;
+    });
+    private log;
+    /**
+     * Run the multi-machine transfer capstone. Throws LiveTestRunnerError if the seat did
+     * not move (the capstone cannot meaningfully run). Otherwise returns the harness
+     * artifact (PASS only when the reply came FROM `targetMachine`).
+     */
+    runMultiMachineTransferCapstone(opts: MultiMachineCapstoneOpts): Promise<{
+        artifact: import("./LiveTestArtifactStore.js").LiveTestArtifact;
+        entry: ReturnType<import("./LiveTestArtifactStore.js").LiveTestArtifactStore["write"]>;
+    }>;
+}
+//# sourceMappingURL=LiveTestRunner.d.ts.map

package/dist/core/LiveTestRunner.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"LiveTestRunner.d.ts","sourceRoot":"","sources":["../../src/core/LiveTestRunner.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AAEH,OAAO,KAAK,EAAE,eAAe,EAAkC,MAAM,sBAAsB,CAAC;AAG5F,MAAM,WAAW,cAAc;IAC7B,2EAA2E;IAC3E,SAAS,EAAE,OAAO,CAAC;IACnB,MAAM,CAAC,EAAE,MAAM,CAAC;CACjB;AAED,MAAM,WAAW,wBAAwB;IACvC,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,oGAAoG;IACpG,aAAa,EAAE,MAAM,CAAC;IACtB,0FAA0F;IAC1F,eAAe,EAAE,MAAM,CAAC;IACxB,kFAAkF;IAClF,cAAc,CAAC,EAAE,MAAM,CAAC;IACxB,wGAAwG;IACxG,QAAQ,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,SAAS,EAAE,MAAM,KAAK,OAAO,CAAC,cAAc,CAAC,CAAC;IAC1E,yDAAyD;IACzD,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,KAAK,CAAC,EAAE,MAAM,CAAC;CAChB;AAED,qBAAa,mBAAoB,SAAQ,KAAK;gBAChC,OAAO,EAAE,MAAM;CAC5B;AAED,qBAAa,cAAc;IACb,OAAO,CAAC,QAAQ,CAAC,IAAI;gBAAJ,IAAI,EAAE;QAAE,OAAO,EAAE,eAAe,CAAC;QAAC,MAAM,CAAC,EAAE,CAAC,CAAC,EAAE,MAAM,KAAK,IAAI,CAAA;KAAE;IAE7F,OAAO,CAAC,GAAG;IAEX;;;;OAIG;IACG,+BAA+B,CAAC,IAAI,EAAE,wBAAwB;;;;CAiDrE"}

package/dist/core/LiveTestRunner.js

@@ -0,0 +1,85 @@
+/**
+ * LiveTestRunner — the orchestrator that APPLIES the live-user-channel-proof standard
+ * to the cross-machine transfer (docs/specs/live-user-channel-proof-standard.md §6 —
+ * the first feature held to the bar). It encodes the capstone flow that a user-role
+ * session runs:
+ *
+ *   1. MOVE THE SEAT FIRST — transfer the (throwaway) topic to the target machine.
+ *      If the transfer reports the seat did NOT move, the capstone premise is false and
+ *      we stop loudly (that "ok:true but moved nothing" lie is the original bug — we
+ *      refuse to paper over it).
+ *   2. Then run the LiveTestHarness over a scenario matrix that sends a real message
+ *      through each channel and asserts the reply was served FROM the target machine
+ *      (the `responderMachine` expectation — the deterministic cross-machine proof).
+ *
+ * This module is pure orchestration over the injected harness + an injected `transfer`
+ * action, so it is unit-testable with fakes. The server.ts route wires the real
+ * RealChannelDriver (real senders + placement reader) into the harness and the real
+ * `POST /pool/transfer` into `transfer`.
+ *
+ * Honesty contract: a non-moved seat THROWS (never records a misleading PASS); a moved
+ * seat that then fails to reply-from-target is a normal harness FAIL (recorded with the
+ * responder mismatch). The artifact only ever shows PASS when the seat moved AND the
+ * reply genuinely came from the target machine.
+ */
+export class LiveTestRunnerError extends Error {
+    constructor(message) { super(message); this.name = 'LiveTestRunnerError'; }
+}
+export class LiveTestRunner {
+    deps;
+    constructor(deps) {
+        this.deps = deps;
+    }
+    log(m) { this.deps.logger?.(`[live-test-runner] ${m}`); }
+    /**
+     * Run the multi-machine transfer capstone. Throws LiveTestRunnerError if the seat did
+     * not move (the capstone cannot meaningfully run). Otherwise returns the harness
+     * artifact (PASS only when the reply came FROM `targetMachine`).
+     */
+    async runMultiMachineTransferCapstone(opts) {
+        // 1. Move the seat FIRST — and demand the honest seatMoved signal.
+        const t = await opts.transfer(opts.telegramTopicId, opts.targetMachine);
+        if (!t.seatMoved) {
+            throw new LiveTestRunnerError(`transfer to ${opts.targetMachine} did not move the seat (${t.detail ?? 'seatMoved=false'}) — ` +
+                `capstone cannot run (refusing to record a misleading PASS over a non-move)`);
+        }
+        this.log(`seat moved to ${opts.targetMachine}; running channel scenarios`);
+        // 2. Build the matrix — each channel asserts the reply was served FROM targetMachine.
+        const message = (opts.message ?? `live-test probe ${opts.runId ?? ''}`).trim();
+        const surfaces = opts.slackChannelId ? ['telegram', 'slack'] : ['telegram'];
+        const scenarios = [
+            {
+                id: 'mm-transfer-telegram-reply-from-target',
+                description: `after transfer to ${opts.targetMachine}, the Telegram reply is served FROM it`,
+                surface: 'telegram',
+                riskCategory: 'happy-path',
+                volatility: 'safe',
+                channelId: opts.telegramTopicId,
+                input: message,
+                expect: { replyNotEmpty: true, responderMachine: opts.targetMachine },
+                ...(opts.timeoutMs ? { timeoutMs: opts.timeoutMs } : {}),
+            },
+        ];
+        if (opts.slackChannelId) {
+            scenarios.push({
+                id: 'mm-transfer-slack-reply-from-target',
+                description: `after transfer to ${opts.targetMachine}, the Slack reply is served FROM it (channel parity)`,
+                surface: 'slack',
+                riskCategory: 'channel-parity',
+                volatility: 'safe',
+                channelId: opts.slackChannelId,
+                input: message,
+                expect: { replyNotEmpty: true, responderMachine: opts.targetMachine },
+                ...(opts.timeoutMs ? { timeoutMs: opts.timeoutMs } : {}),
+            });
+        }
+        const matrix = {
+            featureId: opts.featureId ?? 'multi-machine-transfer',
+            surfaces,
+            riskCategories: opts.slackChannelId ? ['happy-path', 'channel-parity'] : ['happy-path'],
+            scenarios,
+        };
+        return this.deps.harness.run(matrix, opts.runId ? { runId: opts.runId } : {});
+    }
+}
+//# sourceMappingURL=LiveTestRunner.js.map

package/dist/core/LiveTestRunner.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"LiveTestRunner.js","sourceRoot":"","sources":["../../src/core/LiveTestRunner.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AA2BH,MAAM,OAAO,mBAAoB,SAAQ,KAAK;IAC5C,YAAY,OAAe,IAAI,KAAK,CAAC,OAAO,CAAC,CAAC,CAAC,IAAI,CAAC,IAAI,GAAG,qBAAqB,CAAC,CAAC,CAAC;CACpF;AAED,MAAM,OAAO,cAAc;IACI;IAA7B,YAA6B,IAAgE;QAAhE,SAAI,GAAJ,IAAI,CAA4D;IAAG,CAAC;IAEzF,GAAG,CAAC,CAAS,IAAU,IAAI,CAAC,IAAI,CAAC,MAAM,EAAE,CAAC,sBAAsB,CAAC,EAAE,CAAC,CAAC,CAAC,CAAC;IAE/E;;;;OAIG;IACH,KAAK,CAAC,+BAA+B,CAAC,IAA8B;QAClE,mEAAmE;QACnE,MAAM,CAAC,GAAG,MAAM,IAAI,CAAC,QAAQ,CAAC,IAAI,CAAC,eAAe,EAAE,IAAI,CAAC,aAAa,CAAC,CAAC;QACxE,IAAI,CAAC,CAAC,CAAC,SAAS,EAAE,CAAC;YACjB,MAAM,IAAI,mBAAmB,CAC3B,eAAe,IAAI,CAAC,aAAa,2BAA2B,CAAC,CAAC,MAAM,IAAI,iBAAiB,MAAM;gBAC/F,4EAA4E,CAC7E,CAAC;QACJ,CAAC;QACD,IAAI,CAAC,GAAG,CAAC,iBAAiB,IAAI,CAAC,aAAa,6BAA6B,CAAC,CAAC;QAE3E,sFAAsF;QACtF,MAAM,OAAO,GAAG,CAAC,IAAI,CAAC,OAAO,IAAI,mBAAmB,IAAI,CAAC,KAAK,IAAI,EAAE,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC;QAC/E,MAAM,QAAQ,GAAc,IAAI,CAAC,cAAc,CAAC,CAAC,CAAC,CAAC,UAAU,EAAE,OAAO,CAAC,CAAC,CAAC,CAAC,CAAC,UAAU,CAAC,CAAC;QACvF,MAAM,SAAS,GAAsB;YACnC;gBACE,EAAE,EAAE,wCAAwC;gBAC5C,WAAW,EAAE,qBAAqB,IAAI,CAAC,aAAa,wCAAwC;gBAC5F,OAAO,EAAE,UAAU;gBACnB,YAAY,EAAE,YAAY;gBAC1B,UAAU,EAAE,MAAM;gBAClB,SAAS,EAAE,IAAI,CAAC,eAAe;gBAC/B,KAAK,EAAE,OAAO;gBACd,MAAM,EAAE,EAAE,aAAa,EAAE,IAAI,EAAE,gBAAgB,EAAE,IAAI,CAAC,aAAa,EAAE;gBACrE,GAAG,CAAC,IAAI,CAAC,SAAS,CAAC,CAAC,CAAC,EAAE,SAAS,EAAE,IAAI,CAAC,SAAS,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;aACzD;SACF,CAAC;QACF,IAAI,IAAI,CAAC,cAAc,EAAE,CAAC;YACxB,SAAS,CAAC,IAAI,CAAC;gBACb,EAAE,EAAE,qCAAqC;gBACzC,WAAW,EAAE,qBAAqB,IAAI,CAAC,aAAa,sDAAsD;gBAC1G,OAAO,EAAE,OAAO;gBAChB,YAAY,EAAE,gBAAgB;gBAC9B,UAAU,EAAE,MAAM;gBAClB,SAAS,EAAE,IAAI,CAAC,cAAc;gBAC9B,KAAK,EAAE,OAAO;gBACd,MAAM,EAAE,EAAE,aAAa,EAAE,IAAI,EAAE,gBAAgB,EAAE,IAAI,CAAC,aAAa,EAAE;gBACrE,GAAG,CAAC,IAAI,CAAC,SAAS,CAAC,CAAC,CAAC,EAAE,SAAS,EAAE,IAAI,CAAC,SAAS,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;aACzD,CAAC,CAAC;QACL,CAAC;QAED,MAAM,MAAM,GAAkB;YAC5B,SAAS,EAAE,IAAI,CAAC,SAAS,IAAI,wBAAwB;YACrD,QAAQ;YACR,cAAc,EAAE,IAAI,CAAC,cAAc,CAAC,CAAC,CAAC,CAAC,YAAY,EAAE,gBAAgB,CAAC,CAAC,CAAC,CAAC,CAAC,YAAY,CAAC;YACvF,SAAS;SACV,CAAC;QACF,OAAO,IAAI,CAAC,IAAI,CAAC,OAAO,CAAC,GAAG,CAAC,MAAM,EAAE,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,EAAE,KAAK,EAAE,IAAI,CAAC,KAAK,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC;IAChF,CAAC;CACF"}

package/dist/core/TelegramLiveSender.d.ts

@@ -0,0 +1,53 @@
+/**
+ * TelegramLiveSender — the real Telegram `SurfaceSender` for the live-test harness
+ * (docs/specs/live-user-channel-proof-standard.md §5.4). It posts a message into a
+ * Telegram forum topic AS A NON-AGENT IDENTITY (a DEMO bot / second account in a demo
+ * group — NOT the agent's own bot, which the agent would not treat as inbound), then
+ * waits for the AGENT's reply by polling the topic history for the next agent-authored
+ * message.
+ *
+ * Same shape as SlackLiveSender: the send transport (the demo-bot post) and the
+ * history read are INJECTED, so the CODE is complete + unit-testable here and the only
+ * wiring-time dependency is the demo-bot CREDENTIAL + a demo group/topic (provisioning).
+ *
+ * The agent's reply is identified DETERMINISTICALLY: the earliest history entry with
+ * `fromUser === false` (an agent outbound) whose messageId is strictly after the one we
+ * sent. Null on timeout. The responder-MACHINE attribution (the cross-machine proof) is
+ * the RealChannelDriver's injected placement reader, not this sender.
+ */
+import type { SurfaceSender } from './RealChannelDriver.js';
+import type { SendResult, ReplyResult } from './LiveTestHarness.js';
+/** The subset of TelegramAdapter.getTopicHistory's LogEntry this sender reads. */
+export interface TelegramHistoryEntry {
+    messageId: number;
+    text: string;
+    /** true = inbound user message; false = an agent (bot) outbound — the reply we wait for. */
+    fromUser: boolean;
+}
+export interface TelegramLiveSenderDeps {
+    /** Post a message into the topic AS THE DEMO identity (demo-bot token). Returns the new message id. */
+    postAsDemoUser: (topicId: number, text: string) => Promise<{
+        messageId: number;
+    }>;
+    /** Read recent topic history (Echo's getTopicHistory), newest-or-oldest order tolerated. */
+    getHistory: (topicId: number, limit?: number) => TelegramHistoryEntry[] | Promise<TelegramHistoryEntry[]>;
+    pollIntervalMs?: number;
+    sleep?: (ms: number) => Promise<void>;
+    now?: () => number;
+    logger?: (m: string) => void;
+}
+export declare class TelegramLiveSender implements SurfaceSender {
+    private readonly d;
+    constructor(deps: TelegramLiveSenderDeps);
+    private now;
+    private sleep;
+    private log;
+    private topicNum;
+    send(channelId: string, text: string): Promise<SendResult>;
+    awaitReply(channelId: string, opts: {
+        timeoutMs: number;
+        afterMessageId?: string;
+    }): Promise<Omit<ReplyResult, 'responderMachineId'> | null>;
+    private findAgentReply;
+}
+//# sourceMappingURL=TelegramLiveSender.d.ts.map

package/dist/core/TelegramLiveSender.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"TelegramLiveSender.d.ts","sourceRoot":"","sources":["../../src/core/TelegramLiveSender.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;GAgBG;AAEH,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,wBAAwB,CAAC;AAC5D,OAAO,KAAK,EAAE,UAAU,EAAE,WAAW,EAAE,MAAM,sBAAsB,CAAC;AAEpE,kFAAkF;AAClF,MAAM,WAAW,oBAAoB;IACnC,SAAS,EAAE,MAAM,CAAC;IAClB,IAAI,EAAE,MAAM,CAAC;IACb,4FAA4F;IAC5F,QAAQ,EAAE,OAAO,CAAC;CACnB;AAED,MAAM,WAAW,sBAAsB;IACrC,uGAAuG;IACvG,cAAc,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,IAAI,EAAE,MAAM,KAAK,OAAO,CAAC;QAAE,SAAS,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;IAClF,4FAA4F;IAC5F,UAAU,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,KAAK,CAAC,EAAE,MAAM,KAAK,oBAAoB,EAAE,GAAG,OAAO,CAAC,oBAAoB,EAAE,CAAC,CAAC;IAC1G,cAAc,CAAC,EAAE,MAAM,CAAC;IACxB,KAAK,CAAC,EAAE,CAAC,EAAE,EAAE,MAAM,KAAK,OAAO,CAAC,IAAI,CAAC,CAAC;IACtC,GAAG,CAAC,EAAE,MAAM,MAAM,CAAC;IACnB,MAAM,CAAC,EAAE,CAAC,CAAC,EAAE,MAAM,KAAK,IAAI,CAAC;CAC9B;AAED,qBAAa,kBAAmB,YAAW,aAAa;IACtD,OAAO,CAAC,QAAQ,CAAC,CAAC,CAAyB;gBAC/B,IAAI,EAAE,sBAAsB;IAExC,OAAO,CAAC,GAAG;YACG,KAAK;IAGnB,OAAO,CAAC,GAAG;IAEX,OAAO,CAAC,QAAQ;IAMV,IAAI,CAAC,SAAS,EAAE,MAAM,EAAE,IAAI,EAAE,MAAM,GAAG,OAAO,CAAC,UAAU,CAAC;IAQ1D,UAAU,CAAC,SAAS,EAAE,MAAM,EAAE,IAAI,EAAE;QAAE,SAAS,EAAE,MAAM,CAAC;QAAC,cAAc,CAAC,EAAE,MAAM,CAAA;KAAE,GAAG,OAAO,CAAC,IAAI,CAAC,WAAW,EAAE,oBAAoB,CAAC,GAAG,IAAI,CAAC;YAepI,cAAc;CAW7B"}

package/dist/core/TelegramLiveSender.js

@@ -0,0 +1,69 @@
+/**
+ * TelegramLiveSender — the real Telegram `SurfaceSender` for the live-test harness
+ * (docs/specs/live-user-channel-proof-standard.md §5.4). It posts a message into a
+ * Telegram forum topic AS A NON-AGENT IDENTITY (a DEMO bot / second account in a demo
+ * group — NOT the agent's own bot, which the agent would not treat as inbound), then
+ * waits for the AGENT's reply by polling the topic history for the next agent-authored
+ * message.
+ *
+ * Same shape as SlackLiveSender: the send transport (the demo-bot post) and the
+ * history read are INJECTED, so the CODE is complete + unit-testable here and the only
+ * wiring-time dependency is the demo-bot CREDENTIAL + a demo group/topic (provisioning).
+ *
+ * The agent's reply is identified DETERMINISTICALLY: the earliest history entry with
+ * `fromUser === false` (an agent outbound) whose messageId is strictly after the one we
+ * sent. Null on timeout. The responder-MACHINE attribution (the cross-machine proof) is
+ * the RealChannelDriver's injected placement reader, not this sender.
+ */
+export class TelegramLiveSender {
+    d;
+    constructor(deps) { this.d = deps; }
+    now() { return (this.d.now ?? Date.now)(); }
+    async sleep(ms) {
+        return (this.d.sleep ?? ((m) => new Promise((r) => setTimeout(r, m))))(ms);
+    }
+    log(m) { this.d.logger?.(`[telegram-live-sender] ${m}`); }
+    topicNum(channelId) {
+        const n = Number(channelId);
+        if (!Number.isFinite(n))
+            throw new Error(`telegram channelId "${channelId}" is not a numeric topic id`);
+        return n;
+    }
+    async send(channelId, text) {
+        const res = await this.d.postAsDemoUser(this.topicNum(channelId), text);
+        if (!Number.isFinite(res?.messageId)) {
+            throw new Error(`postAsDemoUser returned no messageId — message not posted`);
+        }
+        return { messageId: String(res.messageId) };
+    }
+    async awaitReply(channelId, opts) {
+        const topic = this.topicNum(channelId);
+        const afterId = opts.afterMessageId != null ? Number(opts.afterMessageId) : -Infinity;
+        const deadline = this.now() + opts.timeoutMs;
+        const pollMs = this.d.pollIntervalMs ?? 2000;
+        for (let first = true; first || this.now() < deadline; first = false) {
+            const reply = await this.findAgentReply(topic, afterId);
+            if (reply)
+                return reply;
+            if (this.now() >= deadline)
+                break;
+            await this.sleep(pollMs);
+        }
+        this.log(`no agent reply in topic ${topic} within ${opts.timeoutMs}ms`);
+        return null;
+    }
+    async findAgentReply(topicId, afterId) {
+        const entries = await this.d.getHistory(topicId, 100);
+        // Oldest-first by messageId so we return the EARLIEST agent reply after the prompt.
+        const oldestFirst = [...entries].sort((a, b) => a.messageId - b.messageId);
+        for (const e of oldestFirst) {
+            if (e.messageId <= afterId)
+                continue; // strictly after the prompt
+            if (e.fromUser)
+                continue; // skip inbound user messages (incl. our own demo post)
+            return { text: e.text ?? '', messageId: String(e.messageId) };
+        }
+        return null;
+    }
+}
+//# sourceMappingURL=TelegramLiveSender.js.map

package/dist/core/TelegramLiveSender.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"TelegramLiveSender.js","sourceRoot":"","sources":["../../src/core/TelegramLiveSender.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;GAgBG;AAwBH,MAAM,OAAO,kBAAkB;IACZ,CAAC,CAAyB;IAC3C,YAAY,IAA4B,IAAI,IAAI,CAAC,CAAC,GAAG,IAAI,CAAC,CAAC,CAAC;IAEpD,GAAG,KAAa,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,GAAG,IAAI,IAAI,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC,CAAC;IACpD,KAAK,CAAC,KAAK,CAAC,EAAU;QAC5B,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,KAAK,IAAI,CAAC,CAAC,CAAS,EAAE,EAAE,CAAC,IAAI,OAAO,CAAO,CAAC,CAAC,EAAE,EAAE,CAAC,UAAU,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC;IAC3F,CAAC;IACO,GAAG,CAAC,CAAS,IAAU,IAAI,CAAC,CAAC,CAAC,MAAM,EAAE,CAAC,0BAA0B,CAAC,EAAE,CAAC,CAAC,CAAC,CAAC;IAExE,QAAQ,CAAC,SAAiB;QAChC,MAAM,CAAC,GAAG,MAAM,CAAC,SAAS,CAAC,CAAC;QAC5B,IAAI,CAAC,MAAM,CAAC,QAAQ,CAAC,CAAC,CAAC;YAAE,MAAM,IAAI,KAAK,CAAC,uBAAuB,SAAS,6BAA6B,CAAC,CAAC;QACxG,OAAO,CAAC,CAAC;IACX,CAAC;IAED,KAAK,CAAC,IAAI,CAAC,SAAiB,EAAE,IAAY;QACxC,MAAM,GAAG,GAAG,MAAM,IAAI,CAAC,CAAC,CAAC,cAAc,CAAC,IAAI,CAAC,QAAQ,CAAC,SAAS,CAAC,EAAE,IAAI,CAAC,CAAC;QACxE,IAAI,CAAC,MAAM,CAAC,QAAQ,CAAC,GAAG,EAAE,SAAS,CAAC,EAAE,CAAC;YACrC,MAAM,IAAI,KAAK,CAAC,2DAA2D,CAAC,CAAC;QAC/E,CAAC;QACD,OAAO,EAAE,SAAS,EAAE,MAAM,CAAC,GAAG,CAAC,SAAS,CAAC,EAAE,CAAC;IAC9C,CAAC;IAED,KAAK,CAAC,UAAU,CAAC,SAAiB,EAAE,IAAoD;QACtF,MAAM,KAAK,GAAG,IAAI,CAAC,QAAQ,CAAC,SAAS,CAAC,CAAC;QACvC,MAAM,OAAO,GAAG,IAAI,CAAC,cAAc,IAAI,IAAI,CAAC,CAAC,CAAC,MAAM,CAAC,IAAI,CAAC,cAAc,CAAC,CAAC,CAAC,CAAC,CAAC,QAAQ,CAAC;QACtF,MAAM,QAAQ,GAAG,IAAI,CAAC,GAAG,EAAE,GAAG,IAAI,CAAC,SAAS,CAAC;QAC7C,MAAM,MAAM,GAAG,IAAI,CAAC,CAAC,CAAC,cAAc,IAAI,IAAI,CAAC;QAC7C,KAAK,IAAI,KAAK,GAAG,IAAI,EAAE,KAAK,IAAI,IAAI,CAAC,GAAG,EAAE,GAAG,QAAQ,EAAE,KAAK,GAAG,KAAK,EAAE,CAAC;YACrE,MAAM,KAAK,GAAG,MAAM,IAAI,CAAC,cAAc,CAAC,KAAK,EAAE,OAAO,CAAC,CAAC;YACxD,IAAI,KAAK;gBAAE,OAAO,KAAK,CAAC;YACxB,IAAI,IAAI,CAAC,GAAG,EAAE,IAAI,QAAQ;gBAAE,MAAM;YAClC,MAAM,IAAI,CAAC,KAAK,CAAC,MAAM,CAAC,CAAC;QAC3B,CAAC;QACD,IAAI,CAAC,GAAG,CAAC,2BAA2B,KAAK,WAAW,IAAI,CAAC,SAAS,IAAI,CAAC,CAAC;QACxE,OAAO,IAAI,CAAC;IACd,CAAC;IAEO,KAAK,CAAC,cAAc,CAAC,OAAe,EAAE,OAAe;QAC3D,MAAM,OAAO,GAAG,MAAM,IAAI,CAAC,CAAC,CAAC,UAAU,CAAC,OAAO,EAAE,GAAG,CAAC,CAAC;QACtD,oFAAoF;QACpF,MAAM,WAAW,GAAG,CAAC,GAAG,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,SAAS,GAAG,CAAC,CAAC,SAAS,CAAC,CAAC;QAC3E,KAAK,MAAM,CAAC,IAAI,WAAW,EAAE,CAAC;YAC5B,IAAI,CAAC,CAAC,SAAS,IAAI,OAAO;gBAAE,SAAS,CAAG,4BAA4B;YACpE,IAAI,CAAC,CAAC,QAAQ;gBAAE,SAAS,CAAe,uDAAuD;YAC/F,OAAO,EAAE,IAAI,EAAE,CAAC,CAAC,IAAI,IAAI,EAAE,EAAE,SAAS,EAAE,MAAM,CAAC,CAAC,CAAC,SAAS,CAAC,EAAE,CAAC;QAChE,CAAC;QACD,OAAO,IAAI,CAAC;IACd,CAAC;CACF"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "instar",
-  "version": "1.3.595",
+  "version": "1.3.597",
   "description": "Coherence infrastructure for self-evolving AI agents — on the Claude Code or Codex subscription you already have.",
   "type": "module",
   "main": "dist/index.js",

package/src/data/builtin-manifest.json

@@ -1,8 +1,8 @@
 {
   "$schema": "./builtin-manifest.schema.json",
   "schemaVersion": 1,
-  "generatedAt": "2026-06-16T10:03:21.927Z",
-  "instarVersion": "1.3.595",
+  "generatedAt": "2026-06-16T10:44:35.492Z",
+  "instarVersion": "1.3.597",
   "entryCount": 201,
   "entries": {
     "hook:session-start": {

package/upgrades/1.3.596.md

@@ -0,0 +1,21 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+`TelegramLiveSender` — a real Telegram `SurfaceSender` for the live-test harness (spec §5.4), ships DARK (not wired). Posts into a forum topic as a non-agent demo identity (injected post fn), awaits the agent's reply by polling topic history for the earliest `fromUser===false` entry strictly after the sent messageId. Parameterized on the demo-bot post fn + history reader, so only the demo-bot credential + demo group need provisioning.
+
+## What to Tell Your User
+
+Nothing yet — internal harness infrastructure, ships dark (no runtime surface, no behavior change).
+
+## Summary of New Capabilities
+
+None user-facing. Internally: the real Telegram drive for the live-test harness (Telegram half of the Telegram-AND-Slack bar). No new routes, config, or flags.
+
+## Evidence
+
+- `tests/unit/TelegramLiveSender.test.ts` — 8 tests: post→id, non-numeric-topic throw, no-id throw, earliest-agent-reply-after-prompt, ignores inbound, poll-until-lands, timeout→null, async getHistory.
+- `tsc --noEmit` clean. instar-dev gate green.

package/upgrades/1.3.597.md

@@ -0,0 +1,21 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+`LiveTestRunner` (spec §6) — the orchestrator that applies the live-test standard to the cross-machine transfer, ships DARK (not wired). It transfers the throwaway topic to the target machine, demands the honest `seatMoved` signal (throws if the seat didn't move — no misleading PASS over the original "ok:true but moved nothing" bug), then runs the LiveTestHarness over a matrix asserting the reply was served FROM the target machine (the cross-machine proof). Pure orchestration over an injected harness + transfer action.
+
+## What to Tell Your User
+
+Nothing yet — internal harness infrastructure, ships dark (no runtime surface). The payoff is the capstone: proving a real Laptop↔Mini seat move with a reply served from the destination, through the real channels.
+
+## Summary of New Capabilities
+
+None user-facing. Internally: the orchestration that runs the multi-machine transfer capstone and records the signed PASS/FAIL artifact. No new routes, config, or flags (the route wrapper is the next increment).
+
+## Evidence
+
+- `tests/unit/LiveTestRunner.test.ts` — 5 tests: non-move throws (no harness run), moved+reply-from-target→PASS, moved+wrong-machine→FAIL, slack channel-parity scenario added, empty-reply→FAIL.
+- `tsc --noEmit` clean. instar-dev gate green.

package/upgrades/side-effects/live-test-runner.md

@@ -0,0 +1,28 @@
+# Side-Effects Review — LiveTestRunner (multi-machine transfer capstone orchestrator)
+
+**Slug:** live-test-runner
+**Spec:** docs/specs/live-user-channel-proof-standard.md §6 (apply the standard to multi-machine — the first feature)
+**Files:** src/core/LiveTestRunner.ts, tests/unit/LiveTestRunner.test.ts
+**Posture:** ships DARK — pure orchestration over an injected harness + transfer action. NOT wired into server.ts.
+
+## What it is
+LiveTestRunner encodes the capstone flow: (1) transfer the throwaway topic to the target machine and DEMAND the honest `seatMoved` signal (throw if it didn't move — refuse a misleading PASS over the original "ok:true but moved nothing" bug); (2) run the LiveTestHarness over a matrix that sends a real message per channel and asserts the reply was served FROM the target machine (the `responderMachine` expectation = the cross-machine proof).
+
+## Phase 1 — Principle check (signal vs authority)
+Not a decision gate over agent behavior — it's a test orchestrator. The one control-flow decision (throw on `seatMoved===false`) is a FAIL-LOUD on a test premise, not a runtime authority over messages/sessions. Compliant: it produces a PASS/FAIL artifact (a signal the completion gate already consumes), holds no blocking authority.
+
+## Phase 4 — Side-effects answers
+1. **Over-block** — n/a (no runtime block). Throwing on a non-moved seat is intended: it prevents recording a PASS when the premise failed. The alternative (running anyway) would manufacture a misleading verdict.
+2. **Under-block** — the runner trusts the injected `transfer`'s `seatMoved`. If a transfer LIES (reports seatMoved=true but didn't move), the harness still catches it downstream: the reply's `responderMachine` won't equal target → FAIL. So a lying transfer can't produce a false PASS — the responder assertion is the real backstop.
+3. **Level-of-abstraction fit** — correct: thin orchestration over the merged harness + an injected transfer. It does NOT reimplement transfer or the harness; it sequences them. The server.ts route injects the real `/pool/transfer` + RealChannelDriver.
+4. **Signal vs authority** — compliant (produces an artifact; no authority).
+5. **Interactions** — none yet (dark, unwired). When wired, it CALLS `/pool/transfer` (a real seat move on a THROWAWAY topic) then sends real messages — those surfaces are the server.ts route's review. The runner itself only sequences injected actions.
+6. **External surfaces** — none in this increment (unwired). When wired, the real transfer + sends are external — but scoped to a throwaway topic/demo channel by the caller (the §5.3 isolation in DemoChannelRegistry + the throwaway-topic choice).
+7. **Multi-machine posture** — this IS the multi-machine capstone: it proves a seat moves between machines and the reply is served from the destination. The `responderMachine` assertion (via the driver's placement reader, which reads the authoritative `/pool/placement`) is the cross-machine proof. No single-machine assumption — the whole point is cross-machine.
+8. **Rollback cost** — trivial: dark, unwired. Revert the commit.
+
+## No-deferrals
+The server.ts route (`POST /live-test/run`) that wires the real driver + transfer, and the demo-channel sender-credential provisioning, are the NEXT tracked steps (CMT-1568, `.instar/plans/live-test-harness-drivers-BUILD.md` GATE 1/2), not deferrals of this orchestrator. This module is complete + unit-tested (5 tests: non-move throws, moved+reply-from-target PASS, wrong-machine FAIL, slack-parity scenario, empty-reply FAIL).
+
+## Phase 5 — Second-pass review
+Borderline (it has a control-flow throw), but it adds no runtime authority over messages/sessions/lifecycle — it orchestrates a test and records an artifact. The genuine cross-machine safety (no false PASS) rests on the harness's responder assertion (reviewed in #1195/#1196), which this can't bypass. Not required; noted.

package/upgrades/side-effects/live-test-telegram-sender.md

@@ -0,0 +1,28 @@
+# Side-Effects Review — Live-test Telegram sender
+
+**Slug:** live-test-telegram-sender
+**Spec:** docs/specs/live-user-channel-proof-standard.md §5.4 (Platform-Sanctioned Automation)
+**Files:** src/core/TelegramLiveSender.ts, tests/unit/TelegramLiveSender.test.ts
+**Posture:** ships DARK — one pure/injectable SurfaceSender, NOT wired into server.ts.
+
+## What it is
+TelegramLiveSender — the real Telegram `SurfaceSender`: posts into a forum topic AS A NON-AGENT identity (an injected demo-bot post fn), then `awaitReply` polls the topic history for the AGENT's reply (the earliest entry with `fromUser === false` strictly after the sent messageId). Same proven shape as SlackLiveSender; parameterized on the demo-bot post fn + the history reader, so only the demo-bot CREDENTIAL + a demo group/topic need provisioning.
+
+## Phase 1 — Principle check (signal vs authority)
+Not a decision point — transport (post + poll). No block/filter/gate. Compliant.
+
+## Phase 4 — Side-effects answers
+1. **Over-block** — n/a. Worst case: the reply match misses a genuine agent reply → scenario records no-reply FAIL. Mitigated by the deterministic `fromUser===false` + strictly-after-messageId match over the full poll window.
+2. **Under-block** — n/a. Risk of matching a STALE agent message mitigated by the `messageId > afterId` strictly-after guard + oldest-first scan (earliest reply after the prompt).
+3. **Level-of-abstraction fit** — correct: the concrete Telegram adapter for the harness's `SurfaceSender` seam. Wraps the demo-bot post + getTopicHistory rather than reinventing them.
+4. **Signal vs authority** — compliant (transport, no authority).
+5. **Interactions** — none yet (dark, unwired). The demo-bot identity is SEPARATE from Echo's own bot, so a demo post can't be confused with Echo's outbound; history read is read-only.
+6. **External surfaces** — when wired, it WILL post a real message into a demo Telegram group via the demo-bot token. THIS increment: no wiring, no external surface. The demo-bot token + demo group is the provisioning dependency; the code is parameterized on it.
+7. **Multi-machine posture** — machine-agnostic (talks to the Telegram Bot API + reads topic history). The cross-machine attribution is the RealChannelDriver's PlacementResponderReader, not this sender. No single-machine assumption.
+8. **Rollback cost** — trivial: dark, unwired. Revert the commit.
+
+## No-deferrals
+The runner route (wires both senders + RealChannelDriver + harness + the multi-machine matrix) is the NEXT tracked increment (CMT-1568, `.instar/plans/live-test-harness-drivers-BUILD.md`), not a deferral. This sender is complete + fully unit-tested (8 tests). The demo-bot/group provisioning is an external-credential dependency tracked in the plan, not a code deferral — the code is parameterized so only the credential is missing.
+
+## Phase 5 — Second-pass review
+Not required: transport adapter, no block/allow/lifecycle/sentinel/gate surface (the Phase-5 triggers).