import type { IssueCommandDeps } from './issue-command.js';
/**
 * kickoff 正文。写给 agent 看，所以要把它开工需要的一切都说全：干什么、在哪干、
 * 做完怎么交付。
 *
 * 最后那句 `botmux report` 不是客套：它是**本机唯一**会把 issue 推到 in_review 的信号
 * （见 [[issue-status-projector]] 的计划）。不写进 kickoff，agent 干完了平台也不知道。
 */
export declare function buildKickoffPrompt(args: {
    title: string;
    body?: string;
    workingDir: string;
    issueId: string;
}): string;
/**
 * 激活会话（把 held 群变成真的在跑的会话）。
 *
 * ⚠️ **不能用「让 worker bot 在群里 @ 自己」实现**——飞书不会把一个应用自己发的消息推回给
 * 它自己（见 event-dispatcher 里那段注释：无 receive-all scope 的应用收不到自己发的消息），
 * 所以那条 @ 永远不会变成一次 daemon 事件。`createGroupWithBots` 的 kickoff 能work，是因为它
 * 由**另一个** bot 代发（它显式拒绝 `creator_cannot_kickoff_self`）。
 *
 * 而我们这里 creator 与 worker 是同一个 bot（「你 @ 谁谁就接手」），所以代发那条路也走不通。
 *
 * 正解是**根本不发消息**：botmux 自己就是 daemon，直接内部建会话即可——`autoStartOnGroupJoin`
 * 走的就是这条路（daemon.ts `handleBotAdded`），全程没有任何 @。这也跟 held 模型天然契合：
 * 群先建好、什么都不跑，等我们决定激活时再起会话。
 *
 * 该入口目前还没有从 daemon 暴露出来，所以这里由调用方注入。没注入时领取会**干净地停在
 * activate 阶段**——按 issue-claim-flow 的约定，此时 binding 已 bound、群已就绪，补一次
 * 激活即可，不必重领。宁可这样，也不要塞一个「看起来发出去了其实永远不触发」的实现。
 */
export type ActivateSession = (args: {
    chatId: string;
    larkAppId: string;
    prompt: string;
    workingDir: string;
}) => Promise<string>;
export declare function setIssueActivate(fn: ActivateSession): void;
export declare function buildIssueCommandDeps(activate?: ActivateSession | undefined): IssueCommandDeps;
//# sourceMappingURL=issue-command-deps.d.ts.map