import * as ec2 from "aws-cdk-lib/aws-ec2";
import { REGION } from "../config";

/**
 * The baked open-swe base AMI (ARM64 Ubuntu 24.04 + uv/py3.12 + nginx + CW agent
 * + boot templates — NO secrets), produced by `deploy/ami/open-swe-base.pkr.hcl`.
 * Pinned by EXACT id (not a name filter) so synth/deploy is fully offline and
 * deterministic.
 *
 * Built 2026-06-26 from open-swe-base-arm64-20260626-203433.
 *
 * ── EBS / AMI replacement discipline (memory feedback_inline_ebs_volumes) ──
 *
 * Refresh DELIBERATELY: `cd deploy/ami && packer build open-swe-base.pkr.hcl`,
 * then update this id. A new id → EC2 instance REPLACEMENT. Pinning by exact id
 * (vs a `most_recent` name filter) is what prevents a routine deploy from silently
 * swapping the AMI — the root cause of the file-share data-loss incidents
 * (5/15, 5/27, 6/5).
 *
 * `userDataCausesReplacement: true` (AppService) is likewise DELIBERATE: user-data
 * is provisioning-only and the box holds NO durable state (the langgraph store is
 * in-memory, rebuilt every boot from S3 + Secrets Manager / SSM), so there is
 * intentionally no standalone `ec2.Volume` + `removalPolicy.RETAIN`. The design
 * goal is replacement-TOLERANCE, not avoidance.
 *
 * Operational guard before ANY replacing deploy (AMI / userData / instance-type):
 * snapshot the root volume AND wait `state=completed`, re-verify "no local-only
 * durable state", and review the `cdk diff` replacement at PR time.
 */
export const BAKED_OPEN_SWE_AMI_ID = "ami-00080084502093021";

/** The baked open-swe base image, pinned by id (offline, deterministic). */
export function bakedOpenSweArm64(): ec2.IMachineImage {
  return ec2.MachineImage.genericLinux({ [REGION]: BAKED_OPEN_SWE_AMI_ID });
}