[Nabzx]

Closes #78.

Research output only - ADR-0024, filed as Proposed. Not ready-for-agent yet; three genuine open questions need a grilling round first, same shape ADR-0021's research went through before its own build issue.

Findings

• Address side unchanged from ADR-0020. DescribeAddresses/ReleaseAddress, both confirmed to support DryRun.
• Instance/idle side: DescribeInstances, StopInstances, and CloudWatch GetMetricData (not GetMetricStatistics - it batches up to 500 metrics per call). Real shapes confirmed via botocore's service models.
• A real gap, not just a number to re-check: AWS's own published Trusted Advisor algorithm counts a per-day CPU/network boolean across a 14-day lookback and flags on ≥4 days - not the single-average-checked-once shape IdleInstanceAdapter (Build idle-EC2-instance detection (v1.1) for cloud-waste, per ADR-0022 #73) actually implements. The 10%/5MB numbers were right; the shape around them wasn't. Likely a related naming gap too: the network threshold reads as a daily total (Sum), not the average avg_network_bytes implies.
• Credentials: recommends NOT copying the Stripe-shaped pydantic-settings pattern. boto3's own credential chain already handles env vars/profiles/IAM roles/SSO correctly; re-wrapping it in a project-specific settings class would regress real users away from those.
• Sandbox-first: DryRun gates the two mutating calls (confirmed present, plus on both read calls, though reads have no side effect to gate). GetMetricData has no DryRun at all (read-only). AWS gives a stronger double-gate than Stripe's key-prefix split - a real client can read a real account for real and still structurally never release/stop anything unless a second allow_live=True is passed.
• Least-privilege IAM policy, concretely scoped: exactly ec2:DescribeAddresses, ec2:ReleaseAddress, ec2:DescribeInstances, ec2:StopInstances, cloudwatch:GetMetricData.
• Testing: moto presented as a real alternative to ADR-0013's hand-monkeypatching pattern - a dedicated, actively-maintained library that simulates AWS at the transport layer, catching a class of bug hand-typed canned responses can't. Left open, not decided - a real dependency-vs-plumbing-coverage trade-off.

Open questions for a grilling round

1. Faithful "≥4-of-14-days" algorithm vs. a documented v1 simplification - the one finding that touches already-shipped, tested code (Instance/IdleInstanceCandidate/detector.py).
2. moto vs. hand-monkeypatching boto3.
3. Whether the maintainer wants to spend anything running this for real - every call, including reads, is a genuinely billable AWS API call against a real account, unlike Stripe's free test-mode API.

FakeCloudClient stays the only thing any test, demo, or CI job in this repo talks to either way.