Handle Governor Limits

// A bulk update: 200 Opportunities all moving to Closed Won at once
List<Opportunity> opportunities = [SELECT Id FROM Opportunity WHERE StageName != 'Closed Won' LIMIT 200];
for (Opportunity opp : opportunities) {
    opp.StageName = 'Closed Won';
}
update opportunities; // fires OpportunityTrigger with all 200 records at once

1. // A bulk update: 200 Opportunities all moving to Closed Won at once — the scenario being traced through.
2. List<Opportunity> opportunities = [SELECT Id FROM Opportunity WHERE StageName != 'Closed Won' LIMIT 200]; — one query, fetching the maximum realistic batch.
3. for (Opportunity opp : opportunities) { — loops over them, in memory.
4. opp.StageName = 'Closed Won'; — changes the field.
5. } — closes the loop.
6. update opportunities; — fires OpportunityTrigger with all 200 records at once. Tracing through afterUpdate for this batch: the for loop over 200 records runs zero SOQL and zero DML — it only builds amountAdjustmentByAccountId in memory (Module 25's "collect" half). applyAdjustments then runs exactly one query and one update, regardless of whether those 200 Opportunities point to 200 different Accounts or all share the same one.

Scanning beforeUpdate and afterUpdate for anything that could scale with record count: the for loops themselves are pure in-memory work (no SOQL/DML inside them), addError() doesn't count as DML, and both applyAdjustments's query and update run exactly once regardless of batch size. This handler is bulk-safe as written — genuinely satisfying Module 25's core requirement, not just appearing to.

// applyAdjustments updates Account — if an AccountTrigger existed
// that itself updated related Opportunities, this could chain back
// into OpportunityTrigger again.

1. // applyAdjustments updates Account — if an AccountTrigger existed — applyAdjustments's update accounts is itself a DML statement.
2. // that itself updated related Opportunities, this could chain back — that could, in a more complex org with an AccountTrigger of its own, trigger a chain of further automation.
3. // into OpportunityTrigger again. — this is exactly Module 24's trigger recursion concern, worth being aware of even though this specific module's simple version doesn't need a recursion guard yet.