@raishin/vanguard-frontier-agentic 2.3.0 → 2.5.0

package/skills/salesforce/salesforce-deployment-validator-skill/references/test-selection-strategy.md

@@ -0,0 +1,250 @@
+# Test Selection Strategy
+
+Reference for choosing the correct Apex test level for deployment validation
+and constructing an accurate test class list.
+
+---
+
+## Test Level Options
+
+| Test Level | When to Use | Coverage Source |
+|---|---|---|
+| `RunSpecifiedTests` | Preferred for scoped changes — Apex classes or triggers changed | Specified test classes only |
+| `RunLocalTests` | When broader confidence is needed — profile, permission set, or cross-class changes | All local (non-managed) test classes in the org |
+| `RunAllTestsInOrg` | Only for major releases — full org regression | All test classes including managed packages |
+| `NoTestRun` | Metadata-only changes with NO Apex content (labels, static resources, custom fields without triggers) | Not applicable — no coverage check |
+
+**Default for this skill:** `RunSpecifiedTests`. Always prefer the narrowest
+scope that still satisfies the 75% coverage requirement.
+
+---
+
+## 75% Coverage Requirement
+
+Salesforce requires that each Apex class and trigger included in the
+deployment has at least **75% code coverage** as measured by the tests
+run during validation. This is an absolute requirement — deployments fail
+if any component falls below this threshold.
+
+**Coverage is per-class, not aggregate** for the purposes of deployment
+validation. An org-wide aggregate of 75% does not override a single class
+at 40%.
+
+**Exception:** Classes with `@isTest` annotation are exempt — they are test
+classes themselves and do not require coverage.
+
+---
+
+## RunSpecifiedTests — When and How
+
+### When to use
+
+Use `RunSpecifiedTests` when:
+- The deployment touches specific Apex classes or triggers
+- The test classes that cover those specific classes are known
+- You want to minimize validation time and test org impact
+
+### How to construct the test list
+
+For each Apex class or trigger in the deployment manifest, identify the
+test classes that cover it. The mapping can be derived from:
+
+1. **Source code inspection** — search the test classes for methods that
+   instantiate or call the production class:
+
+   ```bash
+   grep -r "MyProductionClass" force-app/main/default/classes/*Test*.cls
+   grep -r "MyProductionClass" force-app/main/default/classes/*_Test.cls
+   ```
+
+2. **sf CLI coverage report** — run `sf apex run test --code-coverage` against
+   the sandbox to see which test classes cover which production classes:
+
+   ```bash
+   sf apex run test \
+     --class-names MyTest1 MyTest2 \
+     --code-coverage \
+     --result-format json \
+     --target-org <sandbox_alias>
+   ```
+
+3. **Naming convention regex** — common patterns for test class names:
+
+   ```
+   # Convention 1: <ClassName>Test
+   ^<ClassName>Test$
+
+   # Convention 2: <ClassName>_Test
+   ^<ClassName>_Test$
+
+   # Convention 3: Test<ClassName>
+   ^Test<ClassName>$
+
+   # Convention 4: <ClassName>Tests (plural)
+   ^<ClassName>Tests$
+   ```
+
+   Apply all four patterns to the available test class list to identify
+   candidates, then verify coverage via `sf apex run test --code-coverage`.
+
+### Constructing the --tests flag
+
+```bash
+sf project deploy validate \
+  --manifest package.xml \
+  --target-org <sandbox_alias> \
+  --test-level RunSpecifiedTests \
+  --tests MyClass_Test AnotherClass_Test ThirdClass_Test \
+  --wait 30 \
+  --json
+```
+
+Space-separate multiple test class API names. Do not use commas.
+
+---
+
+## RunLocalTests — When and How
+
+### When to use
+
+Use `RunLocalTests` when:
+- The deployment includes profile changes, permission set changes, or
+  custom object changes that could affect multiple classes
+- The specific test classes covering changed components are unknown
+- The deployment is a significant refactor touching many classes
+- `RunSpecifiedTests` produced coverage warnings despite adding all known
+  test classes (RunLocalTests may reveal additional covering tests)
+
+### Caveats
+
+- `RunLocalTests` runs ALL non-managed test classes in the org. For large
+  orgs with extensive test suites, this can take 30–60+ minutes.
+- Adjust `--wait` accordingly:
+
+  ```bash
+  sf project deploy validate \
+    --manifest package.xml \
+    --target-org <sandbox_alias> \
+    --test-level RunLocalTests \
+    --wait 60 \
+    --json
+  ```
+
+- Failures in unrelated test classes will cause the validation to fail even
+  if the deployment components themselves are correct. Investigate whether
+  pre-existing test failures exist in the sandbox before running RunLocalTests.
+
+---
+
+## RunAllTestsInOrg — When and How
+
+### When to use
+
+Use `RunAllTestsInOrg` only when:
+- Preparing for a major release that touches core shared utilities
+- The org has managed packages with test classes that must be included
+- Compliance or audit requirements mandate full-suite regression
+
+### Caveats
+
+- This is the slowest option — expect 60–120+ minutes in large orgs.
+- Managed package test failures can block validation even when unrelated
+  to the deployment. Document known pre-existing managed package test
+  failures before running.
+- Set `--wait` to at least 120 minutes:
+
+  ```bash
+  sf project deploy validate \
+    --manifest package.xml \
+    --target-org <sandbox_alias> \
+    --test-level RunAllTestsInOrg \
+    --wait 120 \
+    --json
+  ```
+
+---
+
+## NoTestRun — Metadata-Only Changes
+
+Use `NoTestRun` only when the deployment manifest contains NO Apex classes
+or triggers — for example:
+
+- Custom labels, custom metadata records
+- Static resources, documents
+- Custom fields without associated triggers
+- Page layouts, list views
+- Email templates, dashboards, reports (when no Apex is involved)
+
+**Do not use `NoTestRun` if there is any doubt about whether the changed
+metadata triggers Apex.** Flows that invoke Apex actions, validation rules
+with custom formula references, and workflow rules can indirectly involve
+Apex — use `RunLocalTests` when uncertain.
+
+---
+
+## Coverage Delta Analysis
+
+After a validation run, compare the coverage result against the baseline
+to identify regressions.
+
+### Extracting coverage from validation output
+
+```bash
+sf project deploy validate --manifest package.xml --target-org <alias> --json \
+  | jq '.result.runTestResult.codeCoverageWarnings[] | {class: .name, warning: .message}'
+```
+
+### Coverage delta calculation
+
+1. **Baseline:** The most recent successful RunLocalTests or RunAllTestsInOrg
+   result in the sandbox (stored as a JSON file in your CI pipeline).
+2. **Current:** The coverage percentages from this validation run.
+3. **Delta:** Current − Baseline per class.
+
+Flag any class where:
+- Coverage drops below 75% (deployment blocker)
+- Coverage drops by more than 10 percentage points (regression risk)
+- A previously-100%-covered class drops below 90% (regression signal)
+
+Include this analysis in the `coverage_delta` field of the skill output.
+
+### Coverage formula
+
+```
+coverage_percent = (total_lines - uncovered_lines) / total_lines * 100
+```
+
+Salesforce reports this per class in the `codeCoverageResult` array within
+the test run output.
+
+---
+
+## Test Class List Construction Checklist
+
+Before running `RunSpecifiedTests`, verify:
+
+- [ ] All Apex classes in the deployment manifest have at least one test class
+      mapped to them
+- [ ] All Apex triggers in the manifest have at least one test class mapped
+- [ ] The test classes mapped actually cover the production classes (verify
+      via `sf apex run test --code-coverage` if uncertain)
+- [ ] Test class API names are correct (case-sensitive match to the class
+      name in the org)
+- [ ] No test classes are in the list that are themselves managed packages
+      (managed package test classes cannot be run via RunSpecifiedTests in
+      most orgs)
+
+If any Apex class in the manifest cannot be mapped to a test class, escalate
+to `RunLocalTests` rather than proceeding with incomplete coverage.
+
+---
+
+## Common Coverage Failures and Remediation
+
+| Failure | Likely Cause | Remediation |
+|---|---|---|
+| Class at 0% coverage | No test class covers it; test class not included in `--tests` | Add the covering test class to the `--tests` list |
+| Class at 60–74% coverage | Test class exists but doesn't cover all branches | Add more test methods; or use RunLocalTests to find broader coverage |
+| Previously-passing class now at 0% | Test class was deleted or renamed | Identify the replacement test class |
+| Managed package class coverage warning | RunAllTestsInOrg picked up managed test classes | Switch to RunLocalTests to exclude managed tests |
+| Validation timeout | Test suite too large for `--wait` value | Increase `--wait`; switch to RunSpecifiedTests to reduce scope |

package/skills/salesforce/salesforce-devsecops-pipeline-skill/SKILL.md

@@ -0,0 +1,195 @@
+---
+name: salesforce-devsecops-pipeline-skill
+description: Use this skill when Salesforce development pipelines must be reviewed for DevSecOps compliance — covering Salesforce Code Analyzer (SCA) finding triage and false positive review, sandbox data governance and PII masking strategy, change impact analysis across metadata dependencies and downstream automation, CI/CD security gate requirements, and DevOps Center deployment governance. Trigger phrases: "review SCA findings", "triage code analyzer results", "assess sandbox data masking", "review change impact", "audit DevSecOps pipeline", "check CI/CD security gates", "review Salesforce DevOps". Do not use when Apex or LWC code patterns are the focus (use salesforce-apex-lwc-code-review-skill), when release readiness approval is needed (use salesforce-release-readiness-skill), when a live deployment is being executed (use salesforce-live-change-approval-protocol), or when permission model changes are under review (use salesforce-permission-model-review-skill). Works from sanitized exports and tool outputs only; never requests live org access.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-21"
+  category: delivery
+  lifecycle: experimental
+---
+
+# Salesforce DevSecOps Pipeline Skill
+
+## Purpose
+This skill conducts a structured DevSecOps review of Salesforce development pipelines — including Salesforce Code Analyzer (SCA) finding triage, sandbox data governance and PII masking adequacy, change impact assessment across metadata dependencies and downstream automation, CI/CD security gate compliance, and DevOps Center deployment governance. It produces a prioritized remediation register without accessing live orgs or executing deployments. It is the shared workflow called by DevSecOps and pipeline governance agents in the Salesforce agent catalog.
+
+## When to use
+- SCA or PMD/ESLint/RetireJS findings from a pipeline run require structured triage and severity classification.
+- Sandbox refresh governance and PII masking adequacy must be assessed before data is loaded.
+- A change impact analysis is needed to identify metadata dependencies, downstream automation risk, and destructive change exposure.
+- CI/CD pipeline security gate configuration must be reviewed against a minimum control baseline.
+- DevOps Center deployment governance — work item traceability, approval gates, promotion rules — needs audit.
+
+## When not to use
+- Apex or LWC code pattern review (logic-level code review) — use `salesforce-apex-lwc-code-review-skill`.
+- Release readiness approval gate with sign-off workflow — use `salesforce-release-readiness-skill`.
+- Live deployment execution or change approval — use `salesforce-live-change-approval-protocol`.
+- Permission model or sharing rule changes — use `salesforce-permission-model-review-skill`.
+- Full org posture assessment combining all domains — use `salesforce-org-assessment-skill`.
+
+## Minimum payload (required inputs)
+- SCA output: PMD rule violations, ESLint issues, RetireJS CVEs, tool version, scan scope (full org vs. delta).
+- Sandbox inventory relevant to the pipeline: sandbox type, data masking configuration, last refresh date.
+- Change inventory: metadata types being deployed, destructive change manifest (if any), field type changes.
+- CI/CD pipeline configuration summary: gate names, pass/fail criteria, tool integrations.
+- Context: deployment target environment (sandbox, staging, production), release timeline, regulatory framework.
+
+## Workflow
+
+### 1. SCA findings triage
+- Review all PMD rule violations from the SCA output.
+- Classify findings by severity tier:
+  - P1 Critical: security vulnerabilities (SOQL injection, XSS, credential exposure, `without sharing` on PII classes).
+  - P2 High: governor-limit risks, missing FLS enforcement, unsafe async patterns.
+  - P3 Medium: code quality issues, missing documentation, test coverage gaps.
+  - P4 Advisory: style suggestions, minor refactor recommendations.
+- Flag: any P1 Critical finding — these must block deployment until resolved.
+- Review ESLint issues for LWC components: flag any security-relevant rules (no-eval, no-inner-html, no-unsanitized).
+- Review RetireJS CVE list: flag CVEs with CVSS score ≥ 7.0 as P1; flag CVSS 4.0–6.9 as P2.
+- Record total finding count by severity tier and tool source (PMD / ESLint / RetireJS).
+
+### 2. False positive review
+- For each finding flagged for false positive consideration, require:
+  - The rule ID and description.
+  - The specific code pattern triggering the finding.
+  - A documented rationale for why the pattern is not a risk in this context.
+- Flag: false positive claims on security-critical rules (SOQL injection, XSS, credential exposure) — these require security specialist sign-off, not self-service suppression.
+- Flag: blanket suppression annotations (`@SuppressWarnings('all')` or equivalent) without scoped justification.
+- Record false positive claims with rule IDs and rationale for audit trail.
+
+### 3. Sandbox governance check
+- Review sandbox type against the intended test data classification:
+  - Developer or Developer Pro sandbox: must not receive masked-production data without explicit governance approval.
+  - Partial sandbox: confirm masking rules cover all regulated field types before refresh.
+  - Full sandbox: confirm masking configuration is applied before every refresh from production.
+- Flag: Full or Partial sandbox refreshed from production without a data masking configuration present.
+- Flag: sandbox with external vendor or contractor access that lacks network access restrictions.
+- Flag: sandbox refresh policy absent or refresh interval undocumented for sandboxes used in the pipeline.
+- Flag: pipeline configured to deploy directly to Full sandbox without a preceding security gate pass.
+- Record sandbox type, masking status, last refresh date, and external-access flag.
+
+### 4. Change impact assessment
+- Review the metadata deployment inventory for dependency risk:
+  - Flag: custom field type changes (e.g., Text → Picklist, Number → Text) — data conversion risk.
+  - Flag: destructive changes in the deployment manifest (field deletions, object deletions, class removals) — confirm rollback plan exists.
+  - Flag: Apex class changes that affect trigger handlers, batch jobs, or scheduled classes without test coverage update.
+  - Flag: Flow or Process Builder metadata changes that affect production-active automations without deactivation plan.
+  - Flag: permission set or profile changes included in the deployment — require permission model review handoff.
+- Map downstream automation impact: identify Flows, Process Builders, triggers, or scheduled jobs that reference changed metadata.
+- Flag: changed metadata referenced by active production automations with no stated deactivation or coordination plan.
+- Flag: API version downgrade in any Apex class or LWC component included in the deployment.
+- Record total metadata component count, destructive change count, and downstream automation impact count.
+
+### 5. CI/CD security gate compliance
+- Review the pipeline configuration for the following required security gates:
+  - SCA scan with fail threshold on P1 findings (required).
+  - Test execution with minimum 75% code coverage gate (required; 85% recommended for regulated orgs).
+  - Static analysis for dependency CVEs (RetireJS or equivalent) (required).
+  - Destructive change review gate — manual approval required before any destructive change deployment (required).
+  - Sandbox deployment verification before production promotion (required).
+- Flag: any required gate absent from the pipeline configuration.
+- Flag: SCA gate configured as advisory-only (no fail threshold) — this does not constitute a security gate.
+- Flag: test coverage gate absent or set below 75%.
+- Flag: production promotion path that bypasses sandbox deployment verification.
+- Record gate presence matrix: gate name → present | absent | advisory-only.
+
+### 6. Risk register assembly
+- Consolidate findings from steps 1–5.
+- Assign risk_tier per finding: Critical | High | Medium | Low.
+- Map each finding to its pipeline domain: sca | false_positive | sandbox | change_impact | cicd_gate.
+- Assign remediation priority: P1 must block deployment; P2 should resolve before promotion; P3 resolve within sprint; P4 advisory.
+- Identify findings that meet escalation gates from salesforce-risk-taxonomy.
+
+## Evidence requirements
+- SCA output with rule IDs and finding counts is required for step 1; absence produces "insufficient evidence — assume all gates unverified".
+- Sandbox inventory with masking configuration is required for step 3.
+- Metadata deployment manifest is required for step 4; absence produces "change impact assessment not possible".
+- CI/CD pipeline configuration or gate summary is required for step 5.
+- Absence of any required input produces an "insufficient evidence" note with conservative (worst-case) rating for that domain.
+
+## Output format
+```
+devsecops_pipeline_findings:
+  sca_findings:
+    - tool: PMD | ESLint | RetireJS
+      rule_id: [rule identifier]
+      severity_tier: P1 | P2 | P3 | P4
+      description: [brief]
+      false_positive_claim: true | false
+      false_positive_rationale: [if applicable]
+      recommendation: [brief]
+  sandbox_governance_findings:
+    - sandbox_name: [sanitized name or type label]
+      sandbox_type: Developer | Developer Pro | Partial | Full
+      masking_configured: true | false | unknown
+      finding: [description]
+      severity: Critical | High | Medium | Low
+      recommendation: [brief]
+  change_impact_findings:
+    - metadata_type: [e.g., CustomField, ApexClass, Flow]
+      component: [sanitized name]
+      finding: [description]
+      severity: Critical | High | Medium | Low
+      downstream_automation_impact: [list or "none identified"]
+      recommendation: [brief]
+  cicd_gate_findings:
+    - gate: [gate name]
+      status: present | absent | advisory-only
+      severity: Critical | High | Medium | Low
+      recommendation: [brief]
+
+sca_summary:
+  p1_critical: [count]
+  p2_high: [count]
+  p3_medium: [count]
+  p4_advisory: [count]
+  false_positive_claims: [count]
+
+cicd_gate_matrix:
+  sca_fail_threshold: present | absent | advisory-only
+  test_coverage_gate: present | absent | below-minimum
+  cve_scan: present | absent | advisory-only
+  destructive_change_approval: present | absent
+  sandbox_verification: present | absent
+
+escalation_gates_fired: [from salesforce-risk-taxonomy, or "none"]
+summary:
+  total_findings: [count]
+  critical_count: [count]
+  high_count: [count]
+  deployment_recommendation: block | conditional | proceed
+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, sandbox names before sharing in outputs.
+- SCA output must not include hardcoded credentials or API keys found in code — stop and request sanitized version.
+
+## Privilege / data handling rules
+- Works from SCA tool output, sanitized pipeline configs, and metadata manifests only.
+- Sandbox findings involving unmasked production data must be flagged for compliance specialist review.
+- P1 SCA findings in Apex classes handling PII or financial data must trigger escalation review.
+- Destructive change findings must be escalated to a change advisory board or equivalent human review.
+
+## Handoff rules
+- Hands off to: salesforce-apex-lwc-code-review-skill (if P1 SCA findings require deeper code-level review), salesforce-release-readiness-skill (after pipeline findings are remediated and deployment approval is needed), salesforce-permission-model-review-skill (if permission set or profile changes are in the deployment), salesforce-case-capsule (for any P1 Critical finding or missing required CI/CD gate).
+- Required handoff fields: matter_id, risk_register (summary), escalation_gates_fired, missing_evidence, assumptions.
+
+## Audit log fields
+- matter_id, skill_id, skill_version, invoked_by, input_hash, evidence_quality, output_verdict, escalation_fired, timestamp
+
+## Stop conditions
+- SCA output or pipeline config contains live credentials, session tokens, or unredacted customer PII — stop and request sanitized version.
+- P1 Critical SCA finding confirmed on a production-bound deployment with no remediation plan — stop, output ESCALATE, require human review before continuing.
+- Destructive change manifest confirmed for a production deployment without a documented rollback plan — stop and require change advisory board review.
+- Full sandbox confirmed to contain unmasked production PII feeding a pipeline with no masking gate — stop and require compliance specialist review.
+
+## Security notes
+- Read-only static review; never requests live org access, executes deployments, or triggers pipeline runs.
+- Sanitized inputs only; SCA outputs containing hardcoded credentials must be refused.
+- Risk register is advisory; P1 blocking decisions and destructive change approvals require human authorization.
+- RetireJS CVE findings reference public CVE records; applicability to the specific Salesforce runtime context requires qualified assessor confirmation.

package/skills/salesforce/salesforce-devsecops-pipeline-skill/metadata.json

@@ -0,0 +1,19 @@
+{
+  "id": "salesforce-devsecops-pipeline-skill",
+  "name": "Salesforce DevSecOps Pipeline Skill",
+  "type": "skill",
+  "provider": "salesforce",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Structured DevSecOps review workflow for Salesforce pipelines covering SCA finding triage, sandbox data governance and PII masking, change impact analysis across metadata dependencies, CI/CD security gate compliance, and DevOps Center deployment governance.",
+  "source_type": "original",
+  "official_docs": [
+    "https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/guide/index.html",
+    "https://help.salesforce.com/s/articleView?id=sf.data_masking_intro.htm",
+    "https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_develop.htm"
+  ],
+  "security_notes": "Read-only static review; sanitized inputs only; never requests live org credentials, session tokens, or API access. Risk register is advisory; remediation requires human authorization.",
+  "last_verified": "2026-05-21",
+  "path": "skills/salesforce/salesforce-devsecops-pipeline-skill",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/salesforce/salesforce-devsecops-pipeline-skill/references/change-impact-categories.md

@@ -0,0 +1,216 @@
+# Change Impact Categories Reference
+
+Classification of Salesforce metadata changes by risk level, dependency
+impact, and rollback complexity.
+
+---
+
+## Category 1: Destructive Changes
+
+Destructive changes remove metadata from an org. They are irreversible if no
+backup exists and can silently break dependent components.
+
+### Destructive Change Types
+
+| Metadata Type | API Name | Risk Level | Rollback Complexity |
+|---------------|----------|------------|---------------------|
+| Custom Object deletion | `CustomObject` | CRITICAL | High (data loss) |
+| Custom Field deletion | `CustomField` | CRITICAL | High (data loss if not empty) |
+| Apex Class removal | `ApexClass` | HIGH | Medium |
+| Apex Trigger removal | `ApexTrigger` | HIGH | Medium |
+| Flow deactivation | `Flow` | HIGH | Low |
+| Flow version deletion | `Flow` | MEDIUM | Medium |
+| Permission Set deletion | `PermissionSet` | HIGH | Medium |
+| Named Credential deletion | `NamedCredential` | HIGH | Medium |
+| Custom Label deletion | `CustomLabel` | MEDIUM | Low |
+| Static Resource deletion | `StaticResource` | MEDIUM | Low |
+
+### Destructive Change Deployment
+
+Destructive changes are deployed via `destructiveChanges.xml` (pre-deployment)
+or `destructiveChangesPost.xml` (post-deployment).
+
+```xml
+<!-- destructiveChangesPost.xml example -->
+<?xml version="1.0" encoding="UTF-8"?>
+<Package xmlns="http://soap.sforce.com/2006/04/metadata">
+  <types>
+    <members>OldHandler</members>
+    <name>ApexClass</name>
+  </types>
+  <types>
+    <members>Account.LegacyStatus__c</members>
+    <name>CustomField</name>
+  </types>
+  <version>59.0</version>
+</Package>
+```
+
+**Pre-deployment gate requirements for destructive changes:**
+- Confirm the field/object is empty (zero records with non-null values).
+- Identify all metadata referencing the removed component (use `sf scanner` or
+  `sfdx-project.json` dependency analysis).
+- Get explicit sign-off from org owner before deploying.
+
+---
+
+## Category 2: Dependent Metadata Chains
+
+Changes to foundational metadata cascade impact to dependent components.
+Use the Metadata API `listMetadata` and `readMetadata` calls to trace these chains.
+
+### Common Dependency Chains
+
+**Custom Object -> Downstream Dependents**
+```
+CustomObject
+  -> CustomField (fields on the object)
+  -> ValidationRule
+  -> ApexTrigger (trigger on object)
+  -> Flow (flows referencing object)
+  -> Layout (page layouts)
+  -> ListType (list views)
+  -> PermissionSet (CRUD/FLS permissions)
+  -> Report (reports using the object)
+  -> Dashboard (dashboards from reports)
+```
+
+**Custom Field -> Downstream Dependents**
+```
+CustomField
+  -> ValidationRule (references field)
+  -> Formula fields (dependent on field value)
+  -> Flow (Flow element referencing field)
+  -> Apex code (field reference in SOQL/DML)
+  -> LWC (getRecord fields, @salesforce/schema imports)
+  -> Report columns
+  -> PermissionSet (FLS entries)
+```
+
+**Apex Class -> Downstream Dependents**
+```
+ApexClass
+  -> ApexTrigger (if trigger uses class)
+  -> Other ApexClass (if class is a dependency)
+  -> Flow (Apex action invocation)
+  -> VF Page (if class is controller)
+  -> PermissionSet (Apex class access)
+```
+
+### Tracing Dependencies via CLI
+
+```bash
+# List all references to a field in metadata
+sf project retrieve start --metadata ApexClass,Flow,ValidationRule -o my-org
+grep -r "LegacyStatus__c" force-app/ --include="*.{cls,xml,js}" -l
+
+# Use Salesforce Dependency API (tooling API)
+curl -s "$SF_INSTANCE_URL/services/data/v59.0/tooling/query/?q=SELECT+\
+MetadataComponentName,MetadataComponentType+FROM+MetadataComponentDependency+\
+WHERE+RefMetadataComponentName='LegacyStatus__c'" \
+-H "Authorization: Bearer $SF_ACCESS_TOKEN"
+```
+
+---
+
+## Category 3: Automation Chain Ripple Effects
+
+Changes to one automation layer can trigger unintended execution in connected
+layers. Understanding the execution order is critical before modifying any
+automation.
+
+### Salesforce Automation Execution Order (per-record)
+
+```
+1. System validation (required fields, data type checks)
+2. Before-save flows (Record-Triggered Flows in Before Save mode)
+3. Before triggers (Apex)
+4. System validation again (after before triggers)
+5. Duplicate Rules
+6. After triggers (Apex)
+7. Assignment Rules
+8. Auto-Response Rules
+9. Workflow Rules (LEGACY - being sunset)
+10. After-save flows (Record-Triggered Flows in After Save mode)
+    -> Escalation Rules
+    -> Entitlement Rules
+11. Processes (Process Builder - LEGACY)
+12. Chatter notifications
+```
+
+Workflow Rules and Process Builder are on the Salesforce
+end-of-life roadmap. Verify sunset dates before referencing in audit reports.
+
+### Ripple Scenarios to Check
+
+| Change | Potential Ripple | Check Before Deploying |
+|--------|-----------------|----------------------|
+| Add Before-Save Flow | Overwrites field before Apex trigger sees it | Review trigger field dependencies |
+| Activate new Apex trigger | Recursive trigger if trigger updates same object | Check for recursion guards |
+| Change field default value | May break validation rules checking for null | Scan all ValidationRule formulas |
+| Add required field | Breaks flows/processes that create records without that field | Search flows for record-create actions |
+| Change picklist value | Breaks flows/processes filtering on old value | Search flows for Equals comparisons on that field |
+| Remove sharing rule | Records may become inaccessible to flows running in user context | Audit flows that use User-context on affected object |
+
+### Recursion Guard Pattern (Apex)
+
+```apex
+// Prevent trigger recursion
+public class AccountTriggerHandler {
+    private static Boolean alreadyRunning = false;
+
+    public static void onAfterUpdate(List<Account> newAccounts, Map<Id, Account> oldMap) {
+        if (alreadyRunning) return;
+        alreadyRunning = true;
+        try {
+            // trigger logic that may update Account records
+        } finally {
+            alreadyRunning = false;
+        }
+    }
+}
+```
+
+---
+
+## Change Risk Scoring Matrix
+
+Use this matrix during change impact review:
+
+| Dimension | Low (1) | Medium (2) | High (3) |
+|-----------|---------|-----------|---------|
+| Component type | Config (picklist value) | Apex/Flow | Schema (object/field) |
+| Data at risk | 0 records | < 10,000 records | > 10,000 records |
+| Dependent components | 0-2 | 3-10 | > 10 |
+| Automation chain length | 0-1 steps | 2-3 steps | > 3 steps |
+| Rollback complexity | Deploy inverse change | Restore from backup | Manual data repair |
+| Business criticality | Low-traffic feature | Daily-use process | Revenue-critical path |
+
+**Risk Score = Sum of dimension scores**
+- 6-9: Low risk, standard deployment window acceptable.
+- 10-14: Medium risk, require QA sandbox validation before production deploy.
+- 15-18: High risk, require change freeze approval, staged rollout, and rollback plan.
+
+---
+
+## Rollback Checklist by Component Type
+
+### Schema Changes (fields, objects)
+- [ ] Export data from affected fields before deployment.
+- [ ] Use `destructiveChangesPost.xml` not `destructiveChanges.xml` to delete
+  after new components are deployed.
+- [ ] Store data export in secure storage for 30-day recovery window.
+
+### Apex Changes
+- [ ] Previous version retrievable from Version Control.
+- [ ] Test class coverage > 75% on incoming version.
+- [ ] If rollback needed: retrieve previous version and redeploy.
+
+### Flow Changes
+- [ ] Previous active version noted before deactivation.
+- [ ] Rollback: reactivate previous version.
+- [ ] If version deleted: restore from source control and re-deploy.
+
+### Permission Set Changes
+- [ ] Clone permission set before modification for rollback reference.
+- [ ] Document which users had access before change.