@raishin/vanguard-frontier-agentic 2.2.0 → 2.5.0

package/skills/salesforce/salesforce-release-readiness-skill/references/release-checklist.md

@@ -0,0 +1,191 @@
+# Release Checklist Reference
+
+Pre-deployment gates and validation requirements for Salesforce releases
+across change set, Salesforce DX, and unlocked package deployment paths.
+
+---
+
+## Deployment Gate Categories
+
+### Gate 1: Code Quality (Static Analysis)
+
+All items must pass before proceeding to QA.
+
+- [ ] PMD scan: zero CRITICAL violations (Apex security and performance rules).
+- [ ] PMD scan: zero HIGH violations (or all HIGH findings documented with
+  accepted risk justification).
+- [ ] ESLint scan: zero errors in LWC JavaScript files.
+- [ ] RetireJS/npm audit: no HIGH or CRITICAL CVEs in static resources.
+- [ ] No hardcoded Salesforce IDs in Apex, Flow, or Formula fields.
+- [ ] All new Apex classes declare `with sharing` or `without sharing`
+  explicitly (no implicit system mode).
+
+### Gate 2: Test Coverage
+
+- [ ] Apex test coverage: >= 75% aggregate (Salesforce deploy requirement).
+- [ ] Apex test coverage: >= 85% on classes modified in this release (internal standard).
+- [ ] All new Apex classes have at least one test class.
+- [ ] All test classes include `System.assert` statements (not just line coverage).
+- [ ] No test classes use `@isTest(SeeAllData=true)`.
+- [ ] Test classes pass in full sandbox with no `System.debug` errors.
+
+```bash
+# Run all tests via CLI before deploy
+sf apex run test \
+  --test-level AllLocalTests \
+  --result-format tap \
+  --code-coverage \
+  -o sandbox-org-alias
+```
+
+### Gate 3: Flow and Automation
+
+- [ ] All new record-triggered flows have fault paths on DML elements.
+- [ ] No new DML-in-loop patterns in any flow.
+- [ ] Any new flow has been tested manually in sandbox for all trigger conditions.
+- [ ] Flows that replace Workflow Rules have been validated to produce identical outcomes.
+- [ ] Flow API version is current (within 2 versions of org API version).
+
+### Gate 4: Schema and Data Migration
+
+- [ ] Destructive changes (field/object deletions) reviewed and approved.
+- [ ] Data export of affected fields completed before deployment.
+- [ ] Field deletions confirmed empty (zero records with non-null value).
+- [ ] Required new fields have default values or are nullable (to prevent
+  breaking existing records and automations).
+
+### Gate 5: Security
+
+- [ ] No new `@AuraEnabled` methods without FLS enforcement.
+- [ ] No new Remote Site Settings with `DisableProtocolSecurity = true`.
+- [ ] No new OAuth flows using Username-Password grant type.
+- [ ] No secrets or credentials in any metadata file.
+- [ ] Any new Connected App has IP restrictions configured.
+
+### Gate 6: Performance
+
+- [ ] SOQL queries in modified Apex reviewed for missing indexes.
+- [ ] No new SOQL without LIMIT clauses on objects with > 100,000 records.
+- [ ] Batch jobs have been tested with full production-scale data volumes in sandbox.
+- [ ] No new synchronous callouts in trigger context.
+
+---
+
+## Change Freeze Windows
+
+### Standard Change Freeze Periods
+
+| Period | Freeze Level |
+|--------|-------------|
+| Salesforce Seasonal Release window (3x per year) | No deployments 24h before to 48h after release |
+| End of fiscal quarter (last 2 weeks) | No non-critical changes |
+| Black Friday / Cyber Monday (retail) | 2-week freeze |
+| Holiday season (Dec 20 - Jan 3) | Full freeze except emergency |
+| Major product launches | As defined by change board |
+
+Salesforce release schedule: verify current dates at
+https://help.salesforce.com/s/articleView?id=release-dates
+
+### Salesforce Release Timeline Impact
+
+Salesforce releases three major updates per year (Spring, Summer, Winter).
+Each release may change:
+- Default behavior of existing features.
+- Governor limit adjustments.
+- API version deprecations.
+- Security policy defaults.
+
+**Pre-release checklist for Salesforce release windows:**
+- [ ] Review Salesforce Release Notes for breaking changes relevant to org's features.
+- [ ] Test org in preview sandbox (sandboxes receive the release 4 weeks before production).
+- [ ] Validate all active Flows and Apex triggers in preview sandbox.
+- [ ] Check Salesforce Optimizer for new recommendations added in the release.
+
+---
+
+## Sandbox Refresh Cadence
+
+| Sandbox Type | Recommended Refresh | Purpose |
+|-------------|---------------------|---------|
+| Developer sandbox | Ad hoc | Individual developer work |
+| Developer Pro sandbox | Weekly | Team feature development |
+| Partial Copy sandbox | Monthly | Integration testing |
+| Full Copy sandbox | Before major release | Production-scale performance testing |
+
+### Post-Refresh Validation
+
+After each sandbox refresh:
+1. Run all active test classes: `sf apex run test --test-level AllLocalTests`.
+2. Verify all Named Credential endpoints point to sandbox counterparts (not prod).
+3. Confirm email deliverability is set to "System Email Only".
+4. Run masking batch if sandbox contains production data.
+5. Verify connected app OAuth callback URLs match sandbox URLs.
+
+---
+
+## Deployment Commands Reference
+
+### Salesforce DX: Deploy to Org
+
+```bash
+# Validate without deploying (check-only)
+sf project deploy start \
+  --source-dir force-app \
+  --target-org sandbox-alias \
+  --check-only \
+  --test-level RunLocalTests
+
+# Deploy with test run
+sf project deploy start \
+  --source-dir force-app \
+  --target-org sandbox-alias \
+  --test-level RunLocalTests
+
+# Deploy with specific test classes
+sf project deploy start \
+  --source-dir force-app \
+  --target-org sandbox-alias \
+  --test-level RunSpecifiedTests \
+  --tests AccountTriggerTest ContactControllerTest
+```
+
+### Destructive Changes Deployment
+
+```bash
+# Deploy components AND destructive changes in one step
+sf project deploy start \
+  --source-dir force-app \
+  --post-destructive-changes destructiveChangesPost.xml \
+  --target-org prod-alias \
+  --test-level RunLocalTests
+```
+
+---
+
+## Pre-Deployment Sign-Off Matrix
+
+| Role | Responsibility | Sign-Off Required For |
+|------|---------------|----------------------|
+| Developer | Code quality and test coverage | All changes |
+| QA Engineer | Functional testing in sandbox | All changes |
+| Security Reviewer | Security gates | Auth, FLS, integration changes |
+| Business Owner | Functional acceptance | New features |
+| Release Manager | Change freeze compliance | All production deploys |
+| DBA/Architect | Schema changes | Object and field changes |
+
+---
+
+## Deployment Emergency Rollback Procedure
+
+If a deployment must be rolled back within the deployment window:
+
+1. Do NOT re-deploy the old version immediately — assess what data has been
+   modified by the new version since deployment.
+2. If DML has occurred on changed fields, data migration back may be required.
+3. For Apex/Flow changes with no schema changes: re-deploy previous version from
+   source control.
+4. For schema changes (new fields): set field to deprecated/hidden rather than
+   deleting (deletion requires empty field).
+5. For destructive changes (deleted fields): restore is not possible — this is
+   why pre-deployment data export is mandatory.
+6. Document the incident, root cause, and rollback action in the change log.

package/skills/salesforce/salesforce-release-readiness-skill/references/rollback-strategy.md

@@ -0,0 +1,234 @@
+# Rollback Strategy Reference
+
+Rollback patterns and considerations for Salesforce releases across package,
+change set, and direct metadata deployment paths.
+
+---
+
+## Rollback Principles
+
+1. Plan rollback BEFORE deploying, not after something breaks.
+2. Rollback complexity scales with the types of metadata changed.
+3. Data that was written by the new version before rollback may create
+   inconsistencies that require manual repair.
+4. Schema changes (fields, objects) are significantly harder to roll back
+   than code changes.
+
+---
+
+## Deployment Method Impact on Rollback
+
+| Deployment Method | Rollback Speed | Complexity |
+|-------------------|---------------|------------|
+| Unlocked Package | Fast (install previous version) | Low |
+| Managed Package | Fast (install previous version) | Low-Medium |
+| Salesforce DX (source deploy) | Medium (re-deploy previous from VCS) | Medium |
+| Change Sets | Slow (rebuild previous change set) | High |
+| Direct Metadata Deploy | Slow (manual retrieval of previous version) | High |
+
+---
+
+## Rollback by Component Type
+
+### Apex Classes and Triggers
+
+**Rollback approach:** Re-deploy the previous version from source control.
+
+```bash
+# Check out previous version from git
+git checkout HEAD~1 -- force-app/main/default/classes/AccountController.cls
+
+# Deploy the reverted class
+sf project deploy start \
+  --source-dir force-app/main/default/classes/AccountController.cls \
+  --target-org prod-alias \
+  --test-level RunSpecifiedTests \
+  --tests AccountControllerTest
+```
+
+**Key risk:** If the previous Apex version references a field that was also
+removed in this deployment, the rollback will fail. Always roll back in reverse
+order: restore code before restoring schema.
+
+### Flows
+
+**Rollback approach:** Re-activate the previous active version.
+
+```bash
+# Query version history
+sf data query \
+  --query "SELECT Id, VersionNumber, Status, ActiveVersion.VersionNumber \
+           FROM FlowDefinition \
+           WHERE ApiName = 'Account_Update_Flow'" \
+  --use-tooling-api \
+  -o prod-alias
+```
+
+In Setup > Flows > [Flow Name]:
+- If previous version was not deleted: set previous version as Active.
+- If previous version was deleted: restore from source control and re-deploy.
+
+**Key risk:** Flows are versioned but old versions may be deleted automatically
+when a new version is activated (depending on org setting). Confirm old versions
+are retained before deployment.
+
+### Custom Fields
+
+**Rollback approach (new fields added):** Delete the field.
+
+- Safe if no data was written to it.
+- If data was written: export data first, then delete field, then re-import if
+  rollback is needed later.
+
+**Rollback approach (field deleted):** Cannot restore from Salesforce — must
+re-create from source control metadata. Data is permanently lost unless backed up.
+
+```bash
+# Create field backup before deployment
+sf data query \
+  --query "SELECT Id, LegacyField__c FROM Account WHERE LegacyField__c != null" \
+  --result-format csv \
+  -o prod-alias \
+  > legacy-field-backup-$(date +%Y%m%d).csv
+```
+
+### Permission Sets
+
+**Rollback approach:** Re-deploy previous version or manually restore removed permissions.
+
+```bash
+# Re-deploy previous permission set version
+sf project deploy start \
+  --source-dir force-app/main/default/permissionsets/Sales_Rep.permissionset-meta.xml \
+  --target-org prod-alias
+```
+
+### Named Credentials
+
+**Rollback approach:** Re-deploy previous version. Credentials are stored separately
+from metadata — re-deploying the Named Credential metadata restores the URL and
+settings but does NOT restore passwords/secrets (these must be re-entered manually).
+
+---
+
+## Unlocked Package Rollback
+
+Unlocked packages support version-based rollback:
+
+```bash
+# List installed package versions
+sf package version list \
+  --packages MyPackage \
+  -o prod-alias
+
+# Install previous version to roll back
+sf package install \
+  --package 04t... (previous version ID) \
+  --target-org prod-alias \
+  --wait 20
+```
+
+**Caution:** If the new version added a field or object that has data, rolling
+back to the previous package version may fail because the previous version does
+not include that field/object metadata — but the field still exists in the org.
+You may need to manually delete the new fields before the previous version can
+be installed cleanly.
+
+---
+
+## Destructive Change Rollback Considerations
+
+Destructive changes (deleted fields, objects, classes) are the highest-risk
+deployment type for rollback.
+
+### Pre-Deployment Requirements (Mandatory)
+- Export all data from fields being deleted.
+- Store export in secure, versioned storage (e.g., S3 with versioning).
+- Record the deletion in the change log with the export file location.
+
+### If Rollback Is Needed After Destructive Change
+
+1. **Field deleted, no data written in the interim:**
+   - Re-create field with same API name.
+   - Re-import data from pre-deployment export.
+
+2. **Field deleted, new data exists (e.g., 2 hours of production use):**
+   - Re-create field.
+   - Re-import pre-deployment data.
+   - Manually reconcile any new records created after deletion (no historical value for them).
+
+3. **Object deleted:**
+   - Re-create object and all fields.
+   - Re-import data.
+   - Re-create relationships (lookups from other objects will need re-configuration).
+   - This is extremely high effort — treat object deletion as irreversible in practice.
+
+---
+
+## Rollback Decision Tree
+
+```
+Is the deployment causing production issues?
+  YES -> Assess impact severity
+
+    Is this a code/flow change only (no schema change)?
+      YES -> Roll back code immediately via re-deploy
+      NO  ->
+        Was data written by the new code since deployment?
+          NO  -> Roll back code and schema changes
+          YES ->
+            Can data inconsistency be manually corrected?
+              YES -> Roll back, then run data correction script
+              NO  -> Activate kill switch / feature flag instead of rollback
+                     Escalate to emergency change board
+```
+
+---
+
+## Feature Flags for Safe Rollback
+
+For high-risk changes, implement a feature flag pattern to enable rapid
+disable without a deployment:
+
+```apex
+// Custom Metadata: FeatureFlag__mdt
+// Fields: IsEnabled__c (Checkbox), DeveloperName (Text)
+
+public class FeatureFlag {
+    private static Map<String, FeatureFlag__mdt> flagCache;
+
+    public static Boolean isEnabled(String flagName) {
+        if (flagCache == null) {
+            flagCache = new Map<String, FeatureFlag__mdt>;
+            for (FeatureFlag__mdt f : [SELECT DeveloperName, IsEnabled__c FROM FeatureFlag__mdt]) {
+                flagCache.put(f.DeveloperName, f);
+            }
+        }
+        return flagCache.containsKey(flagName) && flagCache.get(flagName).IsEnabled__c;
+    }
+}
+
+// Usage in Apex trigger handler
+if (FeatureFlag.isEnabled('New_Account_Routing_Logic')) {
+    // New routing logic
+} else {
+    // Legacy routing logic
+}
+```
+
+To roll back: set `IsEnabled__c = false` in the Custom Metadata record via
+Setup — no code deployment required.
+
+---
+
+## Rollback Drill
+
+Rollback plans should be tested at least quarterly:
+
+1. Deploy a test change to a staging environment.
+2. Simulate a production issue requiring rollback.
+3. Execute the rollback procedure.
+4. Measure time from incident detection to rollback completion.
+5. Document actual time vs target (target: < 30 minutes for code changes,
+   < 2 hours for schema changes).
+6. Update runbook based on findings.