@raishin/vanguard-frontier-agentic 2.2.0 → 2.5.0

package/skills/salesforce/salesforce-apex-lwc-code-review-skill/SKILL.md

@@ -0,0 +1,195 @@
+---
+name: salesforce-apex-lwc-code-review-skill
+description: Use this skill when Salesforce Apex classes, triggers, Lightning Web Components (LWC), or async jobs (Queueable, Batch, Future, Schedulable) must be reviewed for security vulnerabilities and governor-limit risk. Flags: SOQL and DML inside loops, missing test coverage patterns, WITH SECURITY_ENFORCED or WITH USER_MODE or stripInaccessible usage, sharing keyword omission, governor-limit risk, LWC XSS surface, and Locker Service issues. Trigger phrases: "review this Apex class", "check this trigger for SOQL in loops", "is this LWC safe", "review this batch job", "check sharing enforcement in this code". Do not use when Flow automation (not code) is the primary subject (use salesforce-flow-automation-review-skill), when metadata quality is the focus (use salesforce-metadata-review-skill), or when a live code deployment is proposed (use salesforce-live-change-approval-protocol). Works from pasted code only; never requests live org access or executes code.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-20"
+  category: security
+  lifecycle: experimental
+---
+
+# Salesforce Apex and LWC Code Review Skill
+
+## Purpose
+This skill reviews Salesforce Apex classes, triggers, Lightning Web Components
+(
+LWC), and async jobs for security
+vulnerabilities, governor-limit risk, test coverage patterns, and sharing
+enforcement. It flags patterns that cause data exposure, runaway resource
+consumption, or privilege escalation. It does not execute code, access live
+orgs, or authorize deployments.
+
+## When to use
+- Apex or LWC code must be reviewed before a release.
+- A code review has raised security or governor-limit concerns.
+- A trigger is suspected of causing SOQL or DML governor limit errors.
+- LWC components are being reviewed for XSS or Locker Service issues.
+- Async job design (Batch, Queueable, Future, Schedulable) needs safety review.
+
+## When not to use
+- Flow automation (not code) is the primary subject — use `salesforce-flow-automation-review-skill`.
+- Metadata quality (not code logic) — use `salesforce-metadata-review-skill`.
+- Live code deployment proposal — use `salesforce-live-change-approval-protocol`.
+- Full org posture assessment — use `salesforce-org-assessment-skill`.
+
+## Minimum payload (required inputs)
+- Pasted Apex code (class, trigger, or test class) or LWC component files
+  (JS controller, HTML template, or Apex controller).
+- Context: what the code does, what object(s) it operates on, execution context
+  (trigger, batch, scheduled, invocable, REST endpoint, LWC component).
+- Whether the code is deployed in production, sandbox, or scratch org.
+
+## Workflow
+
+### 1. SOQL inside loops
+- Scan for SOQL queries (`[SELECT ... FROM ...]`) inside `for` loops,
+  `while` loops, or recursive method calls.
+- Flag every SOQL-in-loop occurrence as a governor-limit risk.
+- Recommend: bulkify by collecting IDs outside the loop and running a single
+  SOQL query.
+
+### 2. DML inside loops
+- Scan for DML statements (`insert`, `update`, `delete`, `upsert`, `merge`,
+  `undelete`) inside loops.
+- Flag every DML-in-loop occurrence.
+- Recommend: collect records in a list and perform a single DML outside the loop.
+
+### 3. Sharing enforcement
+- Check every Apex class declaration for the `sharing` keyword:
+  - `with sharing` — enforces the running user's sharing rules (recommended default).
+  - `without sharing` — bypasses sharing; flag all usages and require documented justification.
+  - `inherited sharing` — flag if used in entry-point classes where explicit control is expected.
+  - No keyword — implicitly `without sharing` in most contexts; flag all missing keywords.
+- Flag any class that handles PII or financial data and uses `without sharing`
+  or omits the keyword.
+
+### 4. Field-level security enforcement
+- Check SOQL queries for `WITH SECURITY_ENFORCED` or `WITH USER_MODE` clause.
+- Absence on queries returning PII or sensitive fields → flag as data exposure risk.
+- Check for `Security.stripInaccessible` usage before accessing returned field values.
+- Flag: stripping only on output but not on input (incomplete FLS enforcement).
+
+### 5. Governor limit risk
+- SOQL: flag if total distinct SOQL calls per transaction could exceed 100.
+- DML: flag if total DML statements per transaction could exceed 150.
+- Heap: flag large in-memory collections (Lists, Maps, Sets) that grow with record volume.
+- CPU: flag complex nested loops or recursive methods without break conditions.
+- Callouts: flag synchronous callouts from triggers (not allowed); flag callouts
+  without timeout handling.
+
+### 6. Test coverage patterns
+- Check for test classes covering the reviewed code.
+- Flag: test classes with `SeeAllData=true` (
+deprecated pattern).
+- Flag: test methods with no assertions (`System.assertEquals`, `System.assertNotEquals`,
+  `System.assert`).
+- Flag: test data that is hardcoded with real org IDs or email addresses.
+- Flag: missing negative test cases for validation or error paths.
+
+### 7. LWC security surface
+- HTML template: flag dynamic `<lightning-formatted-rich-text>` or
+  `innerHTML` bindings with unsanitized values (XSS risk).
+- JavaScript: flag `eval`, `Function` constructor, or `dangerouslySetInnerHTML`
+  equivalents.
+- Wire adapters: flag wire adapters returning PII fields exposed in template
+  without FLS enforcement in the backing Apex.
+- Locker Service
+: flag cross-namespace
+  DOM access patterns that depend on bypassing Locker Service.
+
+### 8. Async job design
+- Batch Apex: flag `Database.Batchable` implementations that query without
+  scope limitation; flag missing `finish` method implementations.
+- Queueable: flag Queueable chains > configured depth without a termination
+  condition (runaway chaining).
+- Future: flag `@future(callout=true)` methods called from loops.
+- Schedulable: flag scheduled classes that chain into Batch without a
+  concurrency guard.
+
+## Evidence requirements
+- Pasted code; no credentials, session tokens, or customer data in code comments.
+- If code contains hardcoded credentials or tokens, stop and ask for sanitized version.
+- Context about the object and field sensitivity helps calibrate sharing and FLS findings.
+
+## Output format
+```
+apex_lwc_code_review_findings:
+  soql_in_loops:
+    - location: [class/method or line range]
+      severity: High
+      recommendation: [brief]
+  dml_in_loops:
+    - location: [...]
+      severity: High
+      recommendation: [...]
+  sharing_enforcement:
+    - class: [name]
+      keyword: with sharing | without sharing | inherited sharing | missing
+      severity: Critical | High | Medium | Low
+      justification_required: true | false
+      recommendation: [...]
+  fls_enforcement:
+    - query_location: [...]
+      with_security_enforced: present | absent
+      strip_inaccessible: present | partial | absent
+      severity: [...]
+      recommendation: [...]
+  governor_limit_risks:
+    - pattern: [description]
+      severity: [...]
+      recommendation: [...]
+  test_coverage_patterns:
+    - finding: [description]
+      severity: [...]
+      recommendation: [...]
+  lwc_security_findings:
+    - finding: [description]
+      severity: [...]
+      recommendation: [...]
+  async_job_findings:
+    - finding: [description]
+      severity: [...]
+      recommendation: [...]
+
+summary:
+  total_findings: [count]
+  critical_count: [count]
+  high_count: [count]
+escalation_gates_fired: [from salesforce-risk-taxonomy, or "none"]
+assumptions: [list]
+missing_evidence: [what would improve the review]
+```
+
+## Redaction rules
+- Never request secrets, credentials, OAuth tokens, refresh tokens, session IDs, MFA seeds, customer PII.
+- Sanitize org IDs, user IDs (replace with placeholders) before sharing in outputs.
+- If pasted code contains hardcoded credentials or tokens, stop and ask for sanitized version.
+
+## Privilege / data handling rules
+- Code review is logic-level only; do not carry record data from code samples.
+- `without sharing` classes handling PII must be flagged for compliance review.
+- Test code containing real org IDs or customer email addresses must be refused.
+
+## Handoff rules
+- Hands off to: salesforce-flow-automation-review-skill (if automation logic is intertwined),
+  salesforce-permission-model-review-skill (if sharing or FLS findings are systemic),
+  salesforce-release-readiness-skill (for deployment readiness after review).
+- If escalation gate fires: salesforce-case-capsule with escalation_required = true.
+- Required handoff fields: matter_id, critical_count, high_count, escalation_gates_fired,
+  sharing_enforcement summary.
+
+## Audit log fields
+- matter_id, skill_id, skill_version, invoked_by, input_hash, evidence_quality, output_verdict, escalation_fired, timestamp
+
+## Stop conditions
+- Pasted code contains live credentials, session tokens, or customer PII in comments — stop and ask for sanitized version.
+- Critical `without sharing` on PII-handling class in production — flag immediately and require human review.
+- SOQL-in-loop count is very high (systemic) — escalate to salesforce-org-assessment-skill for full automation review.
+
+## Security notes
+- Read-only static code review; never executes code or requests live org access.
+- `without sharing` is a security-relevant decision; every usage must have documented justification.
+- LWC XSS patterns are particularly high risk in Experience Cloud guest-user context.
+- Test class quality is a proxy for deployment safety; missing assertions are a reliability risk.

package/skills/salesforce/salesforce-apex-lwc-code-review-skill/metadata.json

@@ -0,0 +1,18 @@
+{
+  "id": "salesforce-apex-lwc-code-review-skill",
+  "name": "Salesforce Apex and LWC Code Review Skill",
+  "type": "skill",
+  "provider": "salesforce",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Reviews Salesforce Apex classes, triggers, LWC components, and async jobs (Queueable, Batch, Future, Schedulable) for SOQL and DML inside loops, missing test coverage patterns, WITH SECURITY_ENFORCED and stripInaccessible usage, sharing keyword omission, governor-limit risk, LWC XSS surface, and Locker Service issues.",
+  "source_type": "original",
+  "official_docs": [
+    "https://help.salesforce.com/",
+    "https://developer.salesforce.com/docs"
+  ],
+  "security_notes": "Read-only static code review; sanitized code only; never executes code or requests live org credentials. Refuses inputs with hardcoded credentials or customer data. without-sharing usage on PII classes always escalated for human review.",
+  "last_verified": "2026-05-20",
+  "path": "skills/salesforce/salesforce-apex-lwc-code-review-skill",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/salesforce/salesforce-apex-lwc-code-review-skill/references/apex-anti-patterns.md

@@ -0,0 +1,270 @@
+# Apex Anti-Patterns Reference
+
+Patterns that cause governor limit violations, security vulnerabilities, or
+maintainability failures in Apex code.
+
+---
+
+## 1. SOQL in a Loop
+
+### Why It Fails
+Each SOQL query inside a loop consumes one query against the 100-per-transaction
+governor limit. With even 10 records, a nested SOQL loop exhausts limits fast.
+
+### Detection
+```
+grep -rn "\bfor\b.*{" --include="*.cls" .
+# Then inspect each loop body for SELECT keywords
+```
+PMD rule: `AvoidSoqlInLoops`
+
+### Bad Pattern
+```apex
+for (Account acc : accounts) {
+    List<Contact> contacts = [SELECT Id FROM Contact WHERE AccountId = :acc.Id];
+    // SOQL inside loop: LIMIT EXCEPTION at 101st account
+}
+```
+
+### Correct Pattern
+```apex
+Set<Id> accountIds = new Map<Id, Account>(accounts).keySet;
+Map<Id, List<Contact>> contactsByAccount = new Map<Id, List<Contact>>;
+
+for (Contact c : [SELECT Id, AccountId FROM Contact WHERE AccountId IN :accountIds]) {
+    if (!contactsByAccount.containsKey(c.AccountId)) {
+        contactsByAccount.put(c.AccountId, new List<Contact>);
+    }
+    contactsByAccount.get(c.AccountId).add(c);
+}
+
+for (Account acc : accounts) {
+    List<Contact> contacts = contactsByAccount.get(acc.Id) ?? new List<Contact>;
+}
+```
+
+---
+
+## 2. DML in a Loop
+
+### Why It Fails
+Each DML statement (insert/update/delete/upsert) inside a loop consumes one
+DML statement against the 150-per-transaction limit and creates excessive CPU time.
+
+### Detection
+PMD rule: `AvoidDmlStatementsInLoops`
+
+### Bad Pattern
+```apex
+for (Lead l : leadsToConvert) {
+    Database.LeadConvert lc = new Database.LeadConvert;
+    lc.setLeadId(l.Id);
+    Database.convertLead(lc); // DML in loop
+}
+```
+
+### Correct Pattern
+```apex
+List<Database.LeadConvert> conversions = new List<Database.LeadConvert>;
+for (Lead l : leadsToConvert) {
+    Database.LeadConvert lc = new Database.LeadConvert;
+    lc.setLeadId(l.Id);
+    lc.setConvertedStatus('Closed - Converted');
+    conversions.add(lc);
+}
+Database.LeadConvertResult[] results = Database.convertLead(conversions);
+for (Database.LeadConvertResult r : results) {
+    if (!r.isSuccess) {
+        System.debug('Conversion failed: ' + r.getErrors[0].getMessage);
+    }
+}
+```
+
+---
+
+## 3. Missing `with sharing` Declaration
+
+### Why It Is a Security Risk
+Without `with sharing`, a class runs in system context, bypassing the org's
+sharing rules. An LWC that calls such an Apex method can expose records the
+user has no business accessing.
+
+### Detection
+```
+grep -L "with sharing\|without sharing\|inherited sharing" src/classes/*.cls
+```
+Any class that has an `@AuraEnabled` or `@RemoteAction` method and no sharing
+declaration is a finding.
+
+### Patterns
+
+```apex
+// WRONG — implicit system mode
+public class AccountController {
+    @AuraEnabled
+    public static List<Account> getAccounts {
+        return [SELECT Id, Name FROM Account]; // returns ALL accounts
+    }
+}
+
+// CORRECT — explicit sharing enforcement
+public with sharing class AccountController {
+    @AuraEnabled
+    public static List<Account> getAccounts {
+        return [SELECT Id, Name FROM Account]; // respects user's visibility
+    }
+}
+
+// INTENTIONAL system mode — document why
+public without sharing class IntegrationBatchProcessor {
+    // System mode required: processes inbound integration records
+    // that may belong to service users without record access.
+}
+```
+
+---
+
+## 4. Hardcoded IDs
+
+### Why It Fails
+Record IDs, User IDs, Profile IDs, and RecordType IDs differ between sandboxes
+and production. Hardcoded IDs cause deployment failures or silent wrong-record
+references.
+
+### Detection
+```
+grep -rn "00[0-9A-Za-z]\{15,17\}" --include="*.cls" .
+```
+
+### Bad Pattern
+```apex
+Id adminProfileId = '00e000000000001'; // Profile ID: System Administrator
+Id recordTypeId = '012000000000001';   // RecordType: Enterprise Account
+```
+
+### Correct Pattern
+```apex
+Id adminProfileId = [SELECT Id FROM Profile WHERE Name = 'System Administrator' LIMIT 1].Id;
+Id recordTypeId = Schema.SObjectType.Account
+    .getRecordTypeInfosByDeveloperName
+    .get('Enterprise_Account')
+    .getRecordTypeId;
+```
+
+For RecordType lookups, use `getRecordTypeInfosByDeveloperName` (API name is
+stable) rather than `getRecordTypeInfosByName` (label is translatable and may
+change).
+
+---
+
+## 5. Unhandled Governor Limit Approaching
+
+### Description
+Code does not check remaining limits before high-volume operations and will
+throw `LimitException` in large orgs or during scheduled/batch peaks.
+
+### Detection
+Look for missing `Limits` class usage in batch or trigger contexts processing
+large volumes.
+
+### Safeguard Pattern
+```apex
+public class BulkProcessor {
+    public static void processRecords(List<SObject> records) {
+        Integer queriesRemaining = Limits.getLimitQueries - Limits.getQueries;
+        if (queriesRemaining < 10) {
+            System.debug(LoggingLevel.WARN,
+                'Near SOQL limit before processing. Queries used: ' + Limits.getQueries);
+            // Abort or defer remainder to async context
+            return;
+        }
+        // Proceed with processing
+    }
+}
+```
+
+---
+
+## 6. Trigger Logic in Trigger Body
+
+### Why It Is a Problem
+Placing business logic directly in trigger files (rather than in handler classes)
+makes testing, debugging, and future refactoring difficult. It also breaks the
+single-responsibility principle.
+
+### Correct Architecture
+
+```apex
+// AccountTrigger.trigger — thin router only
+trigger AccountTrigger on Account (before insert, before update, after insert, after update) {
+    AccountTriggerHandler handler = new AccountTriggerHandler;
+    if (Trigger.isBefore) {
+        if (Trigger.isInsert) handler.onBeforeInsert(Trigger.new);
+        if (Trigger.isUpdate) handler.onBeforeUpdate(Trigger.new, Trigger.oldMap);
+    }
+    if (Trigger.isAfter) {
+        if (Trigger.isInsert) handler.onAfterInsert(Trigger.new);
+        if (Trigger.isUpdate) handler.onAfterUpdate(Trigger.new, Trigger.oldMap);
+    }
+}
+
+// AccountTriggerHandler.cls — business logic
+public with sharing class AccountTriggerHandler {
+    public void onBeforeInsert(List<Account> newAccounts) { ... }
+    public void onAfterInsert(List<Account> newAccounts) { ... }
+}
+```
+
+---
+
+## 7. Missing FLS Enforcement in Apex
+
+### Description
+SOQL queries in Apex run in system context by default. `with sharing` enforces
+row-level sharing but NOT Field-Level Security (FLS). Sensitive fields can be
+returned even if the user's profile lacks read permission on those fields.
+
+### Detection
+Look for `@AuraEnabled` methods that return SObject records directly without
+`Schema.SObjectField.getDescribe.isAccessible` checks.
+
+### Correct Pattern
+```apex
+public with sharing class SecureContactController {
+    @AuraEnabled
+    public static Contact getContact(Id contactId) {
+        // Enforce FLS before returning
+        if (!Schema.SObjectType.Contact.fields.SSN__c.isAccessible) {
+            throw new AuraHandledException('Insufficient field permissions.');
+        }
+        return [SELECT Id, Name, SSN__c FROM Contact WHERE Id = :contactId LIMIT 1];
+    }
+}
+```
+
+Alternatively, use `Security.stripInaccessible` which handles FLS in bulk:
+```apex
+SObjectAccessDecision decision = Security.stripInaccessible(
+    AccessType.READABLE,
+    [SELECT Id, Name, SSN__c FROM Contact WHERE Id = :contactId]
+);
+List<Contact> safeContacts = (List<Contact>) decision.getRecords;
+```
+
+---
+
+## Governor Limits Quick Reference
+
+| Limit | Synchronous | Asynchronous (Batch/Future/Queueable) |
+|-------|------------|--------------------------------------|
+| SOQL queries | 100 | 200 |
+| SOQL rows returned | 50,000 | 50,000 |
+| DML statements | 150 | 150 |
+| DML rows | 10,000 | 10,000 |
+| CPU time | 10,000ms | 60,000ms |
+| Heap size | 6MB | 12MB |
+| Callouts | 100 | 100 |
+| Future method calls | 50 | N/A |
+| Queueable jobs | 50 | 1 child per job |
+
+Limits are subject to change per Salesforce release.

package/skills/salesforce/salesforce-apex-lwc-code-review-skill/references/governor-limits-reference.md

@@ -0,0 +1,198 @@
+# Governor Limits Reference
+
+Comprehensive reference for Salesforce Apex governor limits organized by
+execution context, with bulkification strategies and monitoring patterns.
+
+Verify all limit values against current Salesforce documentation
+before citing these in audit findings — values may change between releases.
+
+---
+
+## Execution Contexts
+
+| Context | How Triggered |
+|---------|--------------|
+| Synchronous Apex | Triggers, VF controllers, LWC Apex imperative calls, REST API |
+| Asynchronous Apex | `@future`, `Queueable`, `Schedulable`, `Batchable` |
+| Batch Apex execute | Each `execute` call in a `Database.Batchable` job |
+
+---
+
+## Per-Transaction Limit Table
+
+| Resource | Synchronous | Asynchronous | Batch execute |
+|----------|------------|--------------|----------------|
+| SOQL queries | 100 | 200 | 200 |
+| SOQL rows returned total | 50,000 | 50,000 | 50,000 |
+| DML statements | 150 | 150 | 150 |
+| DML rows processed | 10,000 | 10,000 | 10,000 |
+| CPU time (ms) | 10,000 | 60,000 | 60,000 |
+| Heap size | 6 MB | 12 MB | 12 MB |
+| Callouts (HTTP/SOAP) | 100 | 100 | 100 |
+| Email invocations | 10 | 10 | 10 |
+| Push notification calls | 10 | 10 | 10 |
+| Future method calls | 50 | N/A | N/A |
+| Queueable jobs enqueued | 50 | 1 (child) | 1 (child) |
+| `System.schedule` calls | 100 | 100 | 100 |
+| Describe calls | 100 | 100 | 100 |
+| Characters in dynamic SOQL | 20,000 | 20,000 | 20,000 |
+
+---
+
+## Daily Limits (Org-Wide)
+
+| Resource | Limit |
+|----------|-------|
+| Async Apex executions | 250,000 per license (varies by edition) |
+| `@future` calls from triggers | 200 per transaction; daily per org varies |
+| Scheduled Apex concurrent jobs | 100 at any time |
+| Batch jobs in Apex Flex Queue | 100 |
+| Active Scheduled Jobs | 100 |
+
+---
+
+## Checking Limits Programmatically
+
+```apex
+// In Apex — available Limits class methods
+System.debug('SOQL queries used: ' + Limits.getQueries);
+System.debug('SOQL queries limit: ' + Limits.getLimitQueries);
+System.debug('DML statements used: ' + Limits.getDMLStatements);
+System.debug('DML rows used: ' + Limits.getDMLRows);
+System.debug('CPU time used (ms): ' + Limits.getCpuTime);
+System.debug('Heap size used (bytes): ' + Limits.getHeapSize);
+System.debug('Callouts used: ' + Limits.getCallouts);
+
+// Safety check pattern
+public static Boolean isSafeToQuery(Integer reserveCount) {
+    return (Limits.getLimitQueries - Limits.getQueries) > reserveCount;
+}
+```
+
+---
+
+## Bulkification Rules
+
+### Rule 1: Collect, then DML
+Never DML inside a loop. Collect all records to modify in a list, then DML once.
+
+```apex
+List<Contact> toUpdate = new List<Contact>;
+for (Contact c : Trigger.new) {
+    if (c.Email != null && !c.Email.contains('@')) {
+        c.addError('Invalid email format');
+    } else {
+        toUpdate.add(new Contact(Id = c.Id, EmailVerified__c = true));
+    }
+}
+if (!toUpdate.isEmpty) {
+    Database.update(toUpdate, false); // allOrNone = false for resilience
+}
+```
+
+### Rule 2: Batch at 200 for DML
+The DML per-batch row limit aligns with trigger batch size (200 by default).
+For manual batching in anonymous Apex:
+
+```apex
+Integer BATCH_SIZE = 200;
+for (Integer i = 0; i < records.size; i += BATCH_SIZE) {
+    Integer endIdx = Math.min(i + BATCH_SIZE, records.size);
+    Database.update(records.subList(i, endIdx), false);
+}
+```
+
+### Rule 3: Query Once, Map Results
+```apex
+// Query all related records in one SOQL
+Map<Id, List<OpportunityLineItem>> linesByOpp = new Map<Id, List<OpportunityLineItem>>;
+for (OpportunityLineItem oli : [
+    SELECT Id, OpportunityId, Quantity, TotalPrice
+    FROM OpportunityLineItem
+    WHERE OpportunityId IN :oppIds
+]) {
+    if (!linesByOpp.containsKey(oli.OpportunityId)) {
+        linesByOpp.put(oli.OpportunityId, new List<OpportunityLineItem>);
+    }
+    linesByOpp.get(oli.OpportunityId).add(oli);
+}
+```
+
+---
+
+## Batch Apex Sizing Guide
+
+| Volume | Recommended Batch Size | Notes |
+|--------|----------------------|-------|
+| < 10,000 records | 200 (default) | Standard SOQL-queried batch |
+| 10,000 – 1M records | 200 | Increase if processing is CPU-light |
+| 1M+ records | 2,000 (Bulk API mode) | Use `Database.QueryLocator` with Bulk API |
+| Heavy callouts per record | 1–10 | Callout limit is per transaction |
+| Complex transformations | 50–100 | Watch CPU time |
+
+```apex
+Database.executeBatch(new MyBatchClass, 200); // override default batch size
+```
+
+The `Database.QueryLocator` can return up to 50 million rows (vs. 50,000 for
+standard SOQL in non-batch context).
+
+---
+
+## `@future` vs `Queueable` vs `Batch` Decision Guide
+
+| Need | Best Choice |
+|------|------------|
+| Fire-and-forget, no result needed | `@future` |
+| Chaining jobs, need result | `Queueable` |
+| Process > 10,000 records | `Batchable` |
+| Scheduled recurring | `Schedulable` |
+| Callout from trigger | `@future(callout=true)` |
+| Callout + chaining | `Queueable` implementing `Database.AllowsCallouts` |
+
+---
+
+## Heap Size Management
+
+Heap limit is 6 MB synchronous, 12 MB asynchronous. Common causes of heap overflow:
+
+- Large `String` or `Blob` values stored in variables.
+- Accumulating records in a list when only a subset is needed.
+- Deserializing large JSON payloads without streaming.
+
+Mitigation:
+```apex
+// Release memory by nulling unused collections
+List<SObject> bigList = fetchLargeDataset;
+process(bigList);
+bigList = null; // eligible for GC — reduces heap pressure
+
+// Parse only needed JSON fields instead of full deserialization
+Map<String, Object> parsed = (Map<String, Object>) JSON.deserializeUntyped(rawJson);
+String neededField = (String) parsed.get('fieldName');
+parsed = null;
+```
+
+---
+
+## Error Handling with `Database.SaveResult`
+
+Always use `allOrNone=false` in batch contexts to ensure partial success:
+
+```apex
+Database.SaveResult[] results = Database.insert(records, false);
+List<String> errors = new List<String>;
+for (Integer i = 0; i < results.size; i++) {
+    if (!results[i].isSuccess) {
+        for (Database.Error err : results[i].getErrors) {
+            errors.add('Record index ' + i + ': ' + err.getStatusCode +
+                ' - ' + err.getMessage +
+                ' Fields: ' + String.join(err.getFields, ', '));
+        }
+    }
+}
+if (!errors.isEmpty) {
+    // Log to custom object, Platform Event, or System.debug
+    System.debug(LoggingLevel.ERROR, String.join(errors, '\n'));
+}
+```