@raishin/vanguard-frontier-agentic 2.3.0 → 2.5.0

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

@@ -0,0 +1,206 @@
+# LWC Security Reference
+
+Security vulnerabilities specific to Lightning Web Components and the
+Lightning Platform security model.
+
+---
+
+## 1. XSS in Lightning Web Components
+
+### Lightning Locker and LWS
+
+Lightning Web Security (LWS)
+replaced Lightning Locker as the
+default security model for LWC. LWS provides DOM isolation via a JavaScript
+membrane rather than a full sandbox iframe.
+
+Key properties:
+- Third-party scripts that manipulate `window` or `document` directly may break
+  under LWS — this is by design.
+- `eval`, `new Function`, and dynamic script injection are blocked.
+- Cross-namespace DOM access is restricted.
+
+### XSS Risk: `innerHTML` Assignment
+
+```javascript
+// VULNERABLE: setting innerHTML from user-supplied data
+this.template.querySelector('.content').innerHTML = this.userInput;
+
+// SAFE: use textContent for text-only content
+this.template.querySelector('.content').textContent = this.userInput;
+
+// SAFE: use lwc:dom="manual" only when HTML structure is needed
+// and sanitize with DOMPurify (self-hosted) before assignment
+import DOMPurify from 'c/domPurify';  // if available in your org
+const clean = DOMPurify.sanitize(this.userInput, { ALLOWED_TAGS: ['b', 'i', 'em'] });
+this.template.querySelector('.content').innerHTML = clean;
+```
+
+### `lwc:dom="manual"` Risks
+
+Using `lwc:dom="manual"` opts an element out of LWC's rendering pipeline and
+puts DOM management responsibility on the developer.
+
+```html
+<!-- Requires careful handling -->
+<div lwc:dom="manual" class="rich-content"></div>
+```
+
+Rules when using `lwc:dom="manual"`:
+- Never assign `element.innerHTML = userControlledString` without sanitization.
+- Sanitize all content before insertion.
+- Remove event listeners when component is disconnected to prevent memory leaks.
+
+---
+
+## 2. SOQL Injection in LWC (via Apex)
+
+LWC does not execute SOQL directly. The risk is when user input from an LWC
+is passed to an Apex method that concatenates it into a SOQL string.
+
+### Vulnerable Pattern
+```apex
+@AuraEnabled
+public static List<Account> searchAccounts(String searchTerm) {
+    // VULNERABLE: SOQL injection via string concatenation
+    String query = 'SELECT Id, Name FROM Account WHERE Name LIKE \'%' + searchTerm + '%\'';
+    return Database.query(query);
+}
+```
+
+Adversarial input: `%' OR OwnerId != NULL OR Name LIKE '%`
+This returns all accounts regardless of filter intent.
+
+### Secure Pattern
+```apex
+@AuraEnabled
+public static List<Account> searchAccounts(String searchTerm) {
+    // SAFE: bind variable prevents injection
+    String searchPattern = '%' + String.escapeSingleQuotes(searchTerm) + '%';
+    return [SELECT Id, Name FROM Account WHERE Name LIKE :searchPattern WITH SECURITY_ENFORCED LIMIT 100];
+}
+```
+
+Additional hardening:
+- `String.escapeSingleQuotes` on any dynamic string used in SOQL.
+- Use bind variables (`:variable`) rather than concatenation.
+- `WITH SECURITY_ENFORCED` enforces FLS and object-level security at query time.
+- `WITH USER_MODE` (API 57.0+)
+enforces full user-context security
+  including sharing rules, FLS, and CRUD.
+
+---
+
+## 3. Field-Level Security Enforcement in LWC Apex
+
+### Problem
+`@AuraEnabled` Apex methods with `with sharing` enforce row-level access but
+NOT field-level security. Users can receive field values they lack FLS access
+to if the Apex code does not explicitly check FLS.
+
+### Detection
+Review all `@AuraEnabled` methods that return SObjects or field values. Check
+whether field values are stripped before returning.
+
+### Solutions
+
+**Option A: `WITH SECURITY_ENFORCED` in SOQL**
+```apex
+@AuraEnabled
+public static List<Contact> getContacts {
+    // Throws QueryException if FLS blocks any field in SELECT list
+    return [SELECT Id, Name, Email, SSN__c FROM Contact WITH SECURITY_ENFORCED LIMIT 50];
+}
+```
+
+**Option B: `Security.stripInaccessible`**
+```apex
+@AuraEnabled
+public static List<Contact> getContacts {
+    List<Contact> rawContacts = [SELECT Id, Name, Email, SSN__c FROM Contact LIMIT 50];
+    SObjectAccessDecision decision = Security.stripInaccessible(AccessType.READABLE, rawContacts);
+    return (List<Contact>) decision.getRecords;
+    // SSN__c is automatically stripped if user lacks read FLS
+}
+```
+
+---
+
+## 4. Cross-Site Request Forgery (CSRF) in LWC
+
+Salesforce's platform automatically includes anti-CSRF tokens on Visualforce
+pages but LWC-to-Apex wire/imperative calls use session cookies that are
+same-site by default.
+
+**Risk areas:**
+- Custom REST endpoints (`@RestResource`) called by LWC via `fetch`.
+- Aura endpoints exposed to unauthenticated access.
+
+**Mitigation:**
+- For custom REST endpoints called from LWC, verify the `Origin` header server-side.
+- Set `Samesite=Strict` or `Samesite=Lax` on session cookies (configured in
+  Setup > Session Settings
+).
+- Do not expose `@AuraEnabled(cacheable=false)` methods to unauthenticated sites
+  without additional CSRF protection.
+
+---
+
+## 5. Secure Wire Adapter Usage
+
+The `@wire` decorator fetches data reactively. Misuse can cause excessive data
+exposure or SOQL limit exhaustion.
+
+```javascript
+// SAFE: wire with specific ID, not open-ended query
+import { LightningElement, wire, api } from 'lwc';
+import { getRecord, getFieldValue } from 'lightning/uiRecordApi';
+import NAME_FIELD from '@salesforce/schema/Account.Name';
+
+export default class AccountDetail extends LightningElement {
+    @api recordId;
+
+    @wire(getRecord, { recordId: '$recordId', fields: [NAME_FIELD] })
+    account;
+
+    get name {
+        return getFieldValue(this.account.data, NAME_FIELD);
+    }
+}
+```
+
+**Anti-patterns with @wire:**
+- Using `@wire` to fetch unbounded lists (no LIMIT or filter) — use Apex with
+  server-side pagination instead.
+- Passing `recordId` from URL parameters directly to a wire without validating
+  the ID format (18-character Salesforce ID: `[a-zA-Z0-9]{18}`).
+- Exposing a wire result directly in the template without null checks.
+
+---
+
+## 6. Content Security Policy Compliance
+
+Experience Cloud sites
+and Embedded Service can apply CSP.
+LWC components must comply:
+
+- Do not load scripts from external CDNs inline; use Static Resources.
+- Do not use `eval` or `setTimeout(string)`.
+- If using third-party libraries, host them in Static Resources and declare
+  their origin in CSP Trusted Sites (Setup > CSP Trusted Sites).
+- Images fetched via `fetch` from external sources require the domain listed
+  in CSP `img-src`.
+
+---
+
+## LWC Security Review Checklist
+
+- [ ] No `innerHTML` assignment from user-controlled data without sanitization.
+- [ ] No dynamic SOQL string concatenation in Apex methods called from LWC.
+- [ ] All `@AuraEnabled` methods use `with sharing`.
+- [ ] FLS is enforced via `WITH SECURITY_ENFORCED` or `Security.stripInaccessible`.
+- [ ] No hardcoded Salesforce IDs in component JavaScript.
+- [ ] `lwc:dom="manual"` usage documented and reviewed for XSS.
+- [ ] External scripts hosted as Static Resources, not loaded from CDN inline.
+- [ ] API responses from custom REST endpoints checked for CSRF exposure.
+- [ ] Wire adapters include error handling (`account.error` checked alongside `account.data`).

package/skills/salesforce/salesforce-apex-test-generator-skill/SKILL.md

@@ -0,0 +1,274 @@
+---
+name: salesforce-apex-test-generator-skill
+description: "Generates Apex test classes with TestDataFactory patterns, Assert class usage, bulkification (200+ records), positive/negative/bulk test method separation, async test patterns (Test.startTest/stopTest), and proper @TestSetup usage. T0 static generation — no org connection required. TRIGGER when: user asks to write Apex test classes, create @isTest code, generate test setup data, scaffold test coverage for a class, or add a test class for a .cls file. Trigger phrases: write apex tests, test class for, @isTest class, test setup data, generate test coverage. DO NOT TRIGGER when: user wants to execute tests against a live org (use salesforce-apex-test-runner-skill), generating production Apex logic (use salesforce-apex-generator-skill), debugging test failures from log output (use salesforce-apex-log-analyzer-skill)."
+license: MIT
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-21"
+  category: generation
+  lifecycle: experimental
+  execution_tier: static-review
+  mcp_servers: []
+  oauth_scopes: []
+  run_as_permissions:
+    required: []
+    denied: []
+---
+
+# salesforce-apex-test-generator-skill
+
+T0 static code generation for Apex test classes. This skill authors test coverage
+that is **bulkified, assertion-rich, and factory-patterned** — the three qualities
+most often missing from hand-rolled Apex tests. No org connection required.
+
+## When This Skill Owns the Task
+
+Use `salesforce-apex-test-generator-skill` when the work requires **authoring new test classes**:
+
+- "Write tests for the AccountService class"
+- "Generate a @isTest class for my Queueable job"
+- "Create test setup data using TestDataFactory"
+- "Add positive, negative, and bulk test methods for OrderTriggerHandler"
+- "Scaffold an @TestSetup method for the Contact selector tests"
+- "Write async test patterns for my batch class"
+
+**Delegate elsewhere when:**
+
+| Situation | Skill to use |
+|---|---|
+| User wants to run the tests against a live org | `salesforce-apex-test-runner-skill` |
+| User needs the production Apex class authored first | `salesforce-apex-generator-skill` |
+| User is analyzing a test failure from logs | `salesforce-apex-log-analyzer-skill` |
+| User needs to deploy validated code | `salesforce-deployment-validator-skill` |
+
+---
+
+## Required Context to Gather First
+
+Before generating, confirm:
+
+1. **Class under test** — the production Apex class name and its purpose
+2. **Class type** — service, selector, domain, batch, queueable, schedulable, invocable, REST resource, trigger
+3. **SObjects involved** — what objects the production class creates, reads, or updates
+4. **TestDataFactory availability** — does the project already have a TestDataFactory class?
+   If yes, use it. If no, scaffold a minimal factory or factory pattern.
+5. **Key behaviors to test** — what are the main positive paths, exception paths, and
+   governor-limit edge cases?
+6. **API version** — default `62.0` minimum
+
+If the user provides the production class source, read it to infer what test scenarios
+are needed. If not, ask for the class name and its purpose.
+
+---
+
+## Recommended Workflow
+
+### Step 1 — Read the production class (if available)
+
+Use `Read` or `Grep` to locate the class under test. Identify:
+- Public methods that need coverage
+- Exception paths (try/catch blocks, explicit throws)
+- DML operations that need TestDataFactory data
+- Async paths (Queueable, Batch, Schedulable enqueue/execute calls)
+- callout paths (HTTP callout mocks needed?)
+
+### Step 2 — Design test structure
+
+Map each method to test scenarios using the three-path model:
+
+| Path | What to test |
+|---|---|
+| **Positive** | Happy path with valid data; asserts on expected outcome |
+| **Negative** | Invalid input, missing required data, exception thrown; asserts on expected error |
+| **Bulk** | 200+ record insert/update/delete; asserts governor-limit safety |
+
+### Step 3 — Plan TestDataFactory usage
+
+Consult `references/test-data-factory.md`. If a project factory exists, extend it.
+If not, scaffold factory methods as static helpers in the test class or a companion
+`TestDataFactory` class.
+
+### Step 4 — Author the test class
+
+Follow all hard-stop constraints (see Rules section). Generate:
+- `@isTest` class declaration with `private` access
+- `@TestSetup` for shared data (when multiple methods need the same records)
+- Separate `@isTest` methods for each positive, negative, and bulk scenario
+- `Test.startTest` / `Test.stopTest` wrapping all async enqueue or execute calls
+- `Assert` class usage throughout (never bare `System.assert`)
+- No `SeeAllData=true` unless explicitly required by an external tool pattern
+
+### Step 5 — Generate metadata XML
+
+Produce `{ClassName}Test.cls-meta.xml` with correct `apiVersion` and `status: Active`.
+
+### Step 6 — Score against the quality rubric
+
+Run the 100-point rubric (see below). If score is below 80, revise before presenting.
+
+### Step 7 — Recommend test runner pairing
+
+Always end with an explicit recommendation to execute the tests using
+`salesforce-apex-test-runner-skill`, noting the test class name and expected coverage.
+
+---
+
+## Rules
+
+### Hard-Stop Constraints (Must Enforce)
+
+| Constraint | Rationale |
+|---|---|
+| Never use `@isTest(SeeAllData=true)` unless testing external tools that require live data | Test isolation; prevents reliance on org-specific state |
+| Every test method must have at least one `Assert` statement | Tests without assertions give false confidence |
+| Bulk test methods must use 200+ records | Triggers process in batches of 200; 201 records crosses the boundary |
+| Use `Assert` class methods (`Assert.areEqual`, `Assert.isTrue`, etc.) not bare `System.assert` | Produces meaningful failure messages; follows Apex best practices |
+| Use `Test.startTest` / `Test.stopTest` around all async enqueue or execute calls | Flushes async queue; required for governor-limit isolation in tests |
+| All DML in test setup must use `insert` not `Database.insert` unless testing saveResults | Clarity; reserve `Database.insert` for tests specifically checking partial success |
+| Do not hardcode record Ids in test assertions | Ids vary by org; use the returned record.Id |
+| Separate positive, negative, and bulk methods — do not combine in one method | Maintainability and clarity of failure attribution |
+
+### Naming Conventions
+
+| Element | Pattern | Example |
+|---|---|---|
+| Test class | `{ProductionClass}Test` | `AccountServiceTest` |
+| Positive test | `test{Method}Success` or `test{Scenario}` | `testGetAccountByOwnerSuccess` |
+| Negative test | `test{Method}ThrowsWhenInvalid` or `test{Scenario}Error` | `testGetAccountByOwnerThrowsWhenNullId` |
+| Bulk test | `test{Method}Bulk` or `test{Scenario}Bulk` | `testGetAccountByOwnerBulk` |
+| @TestSetup | `setup` (conventional) | `static void setup` |
+
+---
+
+## Quality Scoring Rubric (100-point)
+
+Score the test class before presenting. Threshold: 80+ pass, 60–79 caveat, below 60 revise.
+
+| Dimension | Points | What earns full marks |
+|---|---|---|
+| **Bulkification** | 25 | At least one bulk test method with 200+ records; asserts on all bulk records not just first |
+| **Positive/negative/bulk coverage** | 25 | All three paths present and distinct; each method has a clear purpose |
+| **TestDataFactory used** | 15 | Factory methods used or scaffolded; no inline SObject construction scattered across methods |
+| **Assert class used** | 15 | `Assert.areEqual`, `Assert.isTrue`, `Assert.isNotNull` used throughout; no bare `System.assert(condition)` |
+| **Governor-limit aware** | 10 | `Test.startTest` / `Test.stopTest` wraps async paths; no unnecessary SOQL in each test method |
+| **No SeeAllData** | 10 | `@isTest(SeeAllData=true)` is absent unless explicitly justified with a comment |
+
+**Scoring penalties:**
+- Missing bulk test: -20
+- Bare `System.assert` without message: -10 per occurrence (max -20)
+- `SeeAllData=true` without justification: -15
+- No `Test.startTest` on async path: -10
+- Assertions only on first record in bulk test: -10
+- Missing `@TestSetup` when multiple methods share data setup: -5
+
+---
+
+## T0 Contract
+
+This skill operates exclusively at T0 — static generation only.
+
+- **No org connection:** No `sf` CLI calls, no MCP tool calls, no live execution.
+- **No OAuth required:** Zero-scope, zero-credential, zero-network.
+- **Output is draft code:** All generated test classes are starting points for review.
+  Coverage percentages are estimated, not measured. Use `salesforce-apex-test-runner-skill`
+  for actual execution and coverage measurement.
+
+---
+
+## Refusal Triggers
+
+Stop and do not generate if:
+
+- The user requests `SeeAllData=true` for a standard use case — explain the isolation risk
+  and generate test-isolated factory data instead. Only emit `SeeAllData=true` if the user
+  provides a documented reason (e.g., testing a legacy package that requires live data).
+- The user requests test methods that assert on hardcoded record Ids — explain the org-portability
+  risk and generate assertions using returned record Ids instead.
+
+---
+
+## Output Format
+
+```yaml
+verdict: "pass | caveat | reject"
+quality_score: <0-100>
+quality_notes: "<scoring rationale>"
+
+generated_files:
+  - path: "{ClassName}Test.cls"
+    content: |
+      <apex test code>
+  - path: "{ClassName}Test.cls-meta.xml"
+    content: |
+      <meta xml>
+
+test_scenarios_covered:
+  positive: ["<method name: scenario description>"]
+  negative: ["<method name: scenario description>"]
+  bulk: ["<method name: scenario description>"]
+
+factory_approach: "existing-factory | scaffolded-factory | inline-helpers"
+factory_notes: "<what factory methods were used or created>"
+
+estimated_coverage_areas:
+  - "<class/method: coverage area>"
+
+async_patterns_used: ["Test.startTest/stopTest", "callout mock", "schedulable mock"]
+
+runner_recommendation:
+  companion_skill: "salesforce-apex-test-runner-skill"
+  test_class: "{ClassName}Test"
+  expected_coverage_target: ">=75%"
+
+assumptions:
+  - "<list of assumptions made>"
+
+missing_context:
+  - "<what the user should provide to improve coverage>"
+```
+
+---
+
+## Handoff Rules
+
+| Output | Hand off to |
+|---|---|
+| Generated test class ready for execution | `salesforce-apex-test-runner-skill` (T1) |
+| Production class still needed | `salesforce-apex-generator-skill` |
+| Test failures need log analysis | `salesforce-apex-log-analyzer-skill` |
+| Ready for sandbox deploy | `salesforce-deployment-validator-skill` (T2) |
+
+---
+
+## Stop Conditions
+
+Stop and do not continue if:
+
+- The production class under test cannot be located and the user has not provided its
+  source or purpose — ask for the class content or a description of its methods.
+- The requested test patterns would require live org data not expressible via factory
+  records — explain the limitation and recommend an approach.
+
+---
+
+## Security Notes
+
+- **T0 static generation only:** No org connection, no OAuth, no secrets.
+- **No SeeAllData by default:** Test isolation is enforced. Live org data access in tests
+  is a security and reliability anti-pattern.
+- **No credential generation:** Test classes never contain hardcoded credentials, org Ids,
+  or session tokens.
+- **Factory data only:** All test data is generated via factory methods in the test class
+  or `TestDataFactory`. No reliance on existing org records.
+
+---
+
+## Reference File Index
+
+| File | When to read |
+|---|---|
+| `references/test-data-factory.md` | TestDataFactory pattern, builder pattern, field overrides, lazy init, duplicate rule handling |
+| `references/assertion-patterns.md` | Assert class methods, error messages, multi-assert vs single, bulk assertion patterns |
+| `references/async-testing.md` | Test.startTest/stopTest, mocking Schedulable/Batchable, HTTP callout mocks |

package/skills/salesforce/salesforce-apex-test-generator-skill/metadata.json

@@ -0,0 +1,29 @@
+{
+  "id": "salesforce-apex-test-generator-skill",
+  "name": "Salesforce Apex Test Generator Skill",
+  "type": "skill",
+  "provider": "salesforce",
+  "harnesses": ["claude-code", "codex", "cursor", "gemini", "kiro", "other"],
+  "summary": "Generates Apex test classes with TestDataFactory patterns, Assert class usage, bulkification (200+ records), positive/negative/bulk test method separation, async test patterns (Test.startTest/stopTest), and proper @TestSetup usage. T0 static generation — no org connection required. Emits @isTest .cls + .cls-meta.xml with a 100-point quality score. Pairs with salesforce-apex-test-runner-skill for live execution.",
+  "source_type": "adapted",
+  "source_attribution": "Adapted from forcedotcom/sf-skills generating-apex-test (Apache-2.0). Vanguard-specific additions: T0 tier declaration, 100-point scoring rubric with bulkification gate, Assert class enforcement, SeeAllData refusal policy, and handoff routing model.",
+  "category": "generation",
+  "execution_tier": "static-review",
+  "oauth_scopes": [],
+  "mcp_servers": [],
+  "run_as_permissions": {},
+  "sandbox_only": false,
+  "production_allowed": true,
+  "official_docs": [
+    "https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing.htm",
+    "https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_testsetup_annotation.htm",
+    "https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_assert_class.htm",
+    "https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_data_factory.htm",
+    "https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_tools_start_stop_test.htm"
+  ],
+  "security_notes": "T0 static generation only. No org connection, no OAuth, no secrets. Generated test classes use SeeAllData=false by default to ensure test isolation. No hardcoded credentials, org IDs, session tokens, or record IDs are generated. All test data created via factory methods. Output is draft code requiring human review before deployment.",
+  "last_verified": "2026-05-21",
+  "path": "skills/salesforce/salesforce-apex-test-generator-skill",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/salesforce/salesforce-apex-test-generator-skill/references/assertion-patterns.md

@@ -0,0 +1,174 @@
+# Apex Assertion Patterns Reference
+
+Adapted from forcedotcom/sf-skills generating-apex-test references (Apache-2.0).
+
+## Assert Class (Apex API v55.0+)
+
+Always use the `Assert` class instead of bare `System.assert`. The `Assert` class
+provides meaningful failure messages by default and aligns with modern Apex best practices.
+
+## Core Assert Methods
+
+```apex
+// Assert equality (most common)
+Assert.areEqual(expected, actual, 'Optional failure message');
+
+// Assert inequality
+Assert.areNotEqual(unexpected, actual, 'Optional failure message');
+
+// Assert boolean true
+Assert.isTrue(condition, 'Optional failure message');
+
+// Assert boolean false
+Assert.isFalse(condition, 'Optional failure message');
+
+// Assert not null
+Assert.isNotNull(value, 'Optional failure message');
+
+// Assert null
+Assert.isNull(value, 'Optional failure message');
+
+// Assert instanceof (type check)
+Assert.isInstanceOfType(obj, MyClass.class, 'Optional failure message');
+
+// Explicit failure (use in exception testing)
+Assert.fail('Should have thrown an exception before reaching this line');
+```
+
+## Error Messages
+
+Always provide a descriptive failure message. Bare assertions without messages produce
+"Assertion failed" with no context — useless when multiple assertions fail in a test run.
+
+```apex
+// BAD — no context on failure
+Assert.areEqual(5, results.size);
+
+// GOOD — clear what failed and what was expected
+Assert.areEqual(5, results.size, 'Expected 5 accounts returned for active owners');
+```
+
+## Positive Path Assertions
+
+```apex
+@isTest
+static void testGetAccountsByOwner_Success {
+    // Arrange
+    User owner = TestDataFactory.createUser(true);
+    List<Account> accounts = TestDataFactory.createAccounts(3, false);
+    for (Account acc : accounts) acc.OwnerId = owner.Id;
+    insert accounts;
+
+    // Act
+    Test.startTest;
+    List<Account> results = AccountSelector.getAccountsByOwnerId(owner.Id);
+    Test.stopTest;
+
+    // Assert
+    Assert.areEqual(3, results.size, 'Expected 3 accounts for owner');
+    Assert.areEqual(owner.Id, results[0].OwnerId, 'OwnerId should match');
+}
+```
+
+## Negative Path / Exception Assertions
+
+```apex
+@isTest
+static void testGetAccountsByOwner_ThrowsOnNullId {
+    // Arrange — no setup needed
+
+    // Act + Assert
+    Test.startTest;
+    try {
+        AccountSelector.getAccountsByOwnerId(null);
+        Assert.fail('Expected IllegalArgumentException for null ownerId');
+    } catch (IllegalArgumentException e) {
+        Assert.isTrue(
+            e.getMessage.contains('ownerId cannot be null'),
+            'Exception message should mention ownerId: ' + e.getMessage
+        );
+    }
+    Test.stopTest;
+}
+```
+
+## Bulk Assertions
+
+Do not assert only on the first record. Assert on all records when testing bulk behavior.
+
+```apex
+@isTest
+static void testUpdateIndustry_Bulk {
+    // Arrange
+    List<Account> accounts = TestDataFactory.createAccounts(201, true);
+
+    // Act
+    Test.startTest;
+    AccountService.updateIndustry(new Map<Id, Account>(accounts).keySet, 'Finance');
+    Test.stopTest;
+
+    // Assert — check ALL records
+    List<Account> updated = [SELECT Industry FROM Account WHERE Id IN :accounts];
+    Assert.areEqual(201, updated.size, 'All 201 accounts should be retrieved');
+    for (Account acc : updated) {
+        Assert.areEqual('Finance', acc.Industry,
+            'Industry should be Finance for account: ' + acc.Id);
+    }
+}
+```
+
+## Multi-Assert vs Single Assert
+
+Prefer multiple specific assertions over a single compound assertion. Each assertion
+provides independent failure context:
+
+```apex
+// BAD — single compound assertion hides which field failed
+Assert.isTrue(acc.Name == 'Acme' && acc.Industry == 'Tech' && acc.Active__c == true);
+
+// GOOD — each assertion independently identifiable
+Assert.areEqual('Acme', acc.Name, 'Account Name mismatch');
+Assert.areEqual('Tech', acc.Industry, 'Account Industry mismatch');
+Assert.isTrue(acc.Active__c, 'Account should be active');
+```
+
+## Asserting Exception Types
+
+When testing that specific exception types are thrown, assert the type explicitly:
+
+```apex
+@isTest
+static void testService_ThrowsCustomException {
+    Test.startTest;
+    try {
+        MyService.processWithInvalidData(null);
+        Assert.fail('Expected MyCustomException was not thrown');
+    } catch (MyCustomException e) {
+        Assert.isTrue(
+            e.getMessage.startsWith('Invalid'),
+            'Exception message should start with Invalid: ' + e.getMessage
+        );
+    } catch (Exception e) {
+        Assert.fail('Unexpected exception type: ' + e.getTypeName + ': ' + e.getMessage);
+    }
+    Test.stopTest;
+}
+```
+
+## Deprecated Patterns to Avoid
+
+```apex
+// DEPRECATED — use Assert.isTrue instead
+System.assert(condition);
+System.assert(condition, 'message');
+
+// DEPRECATED — use Assert.areEqual instead
+System.assertEquals(expected, actual);
+System.assertEquals(expected, actual, 'message');
+
+// DEPRECATED — use Assert.areNotEqual instead
+System.assertNotEquals(unexpected, actual);
+```
+
+These deprecated forms still compile and work but are not the modern Apex testing
+standard. All new test code should use the `Assert` class.