/**
 * 自己更新（npm でこのプロセス自身のパッケージを差し替えて再実行する方式）が
 * 成立する実行環境かどうかを判定する。
 *
 * 自動アップデートの再起動は `update-checker.ts` の `reExecProcess()` が担い、
 * 「detached な子プロセスを spawn して自分は `process.exit(0)`」という形をとる。
 * これは「終了したら誰かが起動し直してくれる」監督プロセス（systemd のユーザー
 * ユニット、ホスト側の DockerSupervisor）を前提にした設計であり、その前提が無い
 * 環境では次のように壊れる。
 *
 *   1. コンテナの ENTRYPOINT は `exec "$@"` するため、エージェントは PID 1 になる
 *   2. 更新後の `process.exit(0)` で PID 1 が消え、コンテナ自体が終了する
 *   3. PID 1 が死ぬと同じ PID 名前空間に残った detached の子もカーネルに殺されるため、
 *      再実行したはずの新バージョンも即座に消える
 *   4. オーケストレータがコンテナを再作成する。中身はイメージのものに戻るので、
 *      npm で入れた新バージョンは残らない
 *   5. しばらくして再びチェックが走り、同じことを繰り返す
 *
 * つまり「更新できないまま再起動を繰り返す」だけになる。これらの環境での正しい
 * バージョンアップはイメージタグの差し替えであり、自己更新は設定に関わらず
 * 行わせない。
 */
/** 自己更新が成立しない理由。 */
export type SelfUpdateBlockReason = 'kubernetes' | 'pid1-no-supervisor';
export interface SelfUpdateCapability {
    /** true なら自己更新方式でのバージョンアップが成立する。 */
    capable: boolean;
    /** `capable` が false のときだけ設定される。 */
    reason?: SelfUpdateBlockReason;
}
/**
 * 実行環境から自己更新の可否を判定する。
 *
 * 判定順序には意味がある。Kubernetes の判定を `AI_SUPPORT_AGENT_IN_DOCKER` より
 * 先に置くのは、Pod にはホスト側の DockerSupervisor が存在しないためである
 * （マニフェストが何らかの理由でこの変数を立てていても、更新を引き受ける相手は
 * いない）。
 *
 * @param env 判定に使う環境変数（既定は現在のプロセスのもの）
 * @param pid 判定に使うプロセスID（既定は現在のプロセスのもの）
 */
export declare function resolveSelfUpdateCapability(env?: NodeJS.ProcessEnv, pid?: number): SelfUpdateCapability;
/**
 * ログ・ハートビート通知に載せる説明文。
 *
 * 「なぜ止めたか」だけでなく「代わりに何をすればよいか」まで書く。これを読む人は
 * 管理画面で自動アップデートを ON にしたのに動かない、という状況にいるため。
 */
export declare function describeSelfUpdateBlockReason(reason: SelfUpdateBlockReason): string;
//# sourceMappingURL=self-update-capability.d.ts.map