@raishin/vanguard-frontier-agentic 2.2.0 → 2.5.0

package/skills/salesforce/salesforce-permission-model-review-skill/references/permission-set-strategy.md

@@ -0,0 +1,203 @@
+# Permission Set Strategy Reference
+
+Design principles and patterns for Salesforce permission set architecture
+aligned with least-privilege and scalable access management.
+
+---
+
+## Profile vs Permission Set: Design Philosophy
+
+In modern Salesforce security design, the profile should carry the minimum
+viable baseline, and Permission Sets (and Permission Set Groups) should be
+used to grant everything additional.
+
+### Profile Responsibilities (Minimal)
+
+| What Profile Should Control | Why |
+|-----------------------------|-----|
+| Login hours | Can only be set on profile |
+| Login IP ranges | Can only be set on profile |
+| Object-level CRUD defaults (read-only or no access) | Baseline denial |
+| Page layout assignments | User experience baseline |
+| License type | Determined by profile |
+
+### What Profile Should NOT Control (Move to Permission Sets)
+
+- Field-level security beyond the minimum.
+- Specific object permissions for data access.
+- Application permissions.
+- System permissions (e.g., API Enabled, Export Reports).
+
+This approach means users can be on a minimal baseline profile and receive
+job-specific permissions through Permission Sets without needing a new profile
+for every combination.
+
+---
+
+## Permission Set Group Design
+
+Permission Set Groups aggregate multiple Permission Sets into a single
+assignable unit. Assign the group, not individual permission sets.
+
+### Example Architecture: Sales User
+
+```
+Permission Set Group: Sales_Representative
+  |- Permission Set: Core_CRM_Access
+  |    CRM Objects: Account (R), Contact (R/W), Opportunity (R/W)
+  |    Fields: Standard fields only
+  |
+  |- Permission Set: Sales_Territory_Management
+  |    Custom Fields: Territory__c, RegionOwner__c
+  |
+  |- Permission Set: Report_Export_Allowed
+       System Permission: Export Reports
+
+Profile (baseline): Minimum_Internal_User
+  No object permissions
+  Login hours: 6am-8pm Mon-Fri
+  Login IP: [corporate VPN range]
+```
+
+### Role-Based vs Persona-Based
+
+**Role-based** permission sets grant access based on the user's job function
+within a team:
+
+```
+Sales_Manager_Access
+  Apex Class: SalesDashboardController (exec)
+  Object: Opportunity (View All)
+  Reports: All Sales Reports folder (View)
+```
+
+**Persona-based** permission sets grant access based on a named user persona
+that cuts across multiple roles:
+
+```
+Power_User_Data_Export
+  System: Export Reports
+  System: Mass Delete Records
+  (granted only to named Power Users regardless of role)
+```
+
+Use role-based as the primary model. Persona-based for cross-cutting elevated
+privileges that need tight control.
+
+---
+
+## Principle of Least Privilege in Practice
+
+### Field-Level Security (FLS) Baseline
+
+For sensitive fields, default FLS should be hidden to all profiles:
+
+```
+Setup > Object Manager > Contact > Fields and Relationships > SSN__c
+  Field-Level Security:
+    Default (all profiles): Read = false, Edit = false
+    (Access granted via Permission Set for specific roles only)
+```
+
+Then grant via Permission Set:
+```
+Permission Set: PII_Data_Steward
+  Object: Contact
+  Fields: SSN__c (Read), SSN__c (Edit)
+```
+
+### Object Permission Baseline
+
+Start new custom objects with no access in default profile:
+```
+Custom Object: PatientRecord__c
+  Profile (Minimum_Internal): No CRUD access
+  Permission Set: Clinical_Team_Access -> CRUD
+  Permission Set: Billing_Team_Access -> Read only
+```
+
+### System Permission Least Privilege
+
+| Permission | When to Grant | Avoid Granting To |
+|------------|--------------|-------------------|
+| API Enabled | Integration users, developers | All standard users |
+| Modify All Data | System Administrator only | Any non-admin user |
+| View All Data | Compliance/audit role only | General users |
+| Manage Users | HR/IT admin team | Regular users |
+| Export Reports | Named power users only | Default profile |
+| ViewEncryptedData | Compliance team only | All users |
+| Bulk API Hard Delete | Integration admin only | General users |
+
+---
+
+## Permission Set Lifecycle Management
+
+### Provisioning Process
+
+```
+1. New employee joins:
+   a. Assign role-based Permission Set Group for their function.
+   b. Do NOT assign individual Permission Sets unless the Group doesn't cover.
+
+2. User changes roles:
+   a. Remove old Permission Set Group.
+   b. Assign new Permission Set Group.
+   c. Review any individually assigned Permission Sets; remove if no longer valid.
+
+3. Employee offboards:
+   a. Deactivate user account (removes all permission set assignments).
+   b. Document any records they owned that need reassignment.
+```
+
+### Permission Set Audit Query
+
+```sql
+-- Find all active users and their permission set assignments
+SELECT Assignee.Name, Assignee.Username, PermissionSet.Name,
+       PermissionSet.IsOwnedByProfile, PermissionSet.ProfileId
+FROM PermissionSetAssignment
+WHERE Assignee.IsActive = true
+  AND PermissionSet.IsOwnedByProfile = false  -- excludes profile-owned sets
+ORDER BY Assignee.Name, PermissionSet.Name
+```
+
+### Orphaned Assignments (Users Deactivated but Assignments Not Cleaned)
+
+```sql
+SELECT Assignee.Name, Assignee.Username, PermissionSet.Name
+FROM PermissionSetAssignment
+WHERE Assignee.IsActive = false
+  AND PermissionSet.IsOwnedByProfile = false
+ORDER BY Assignee.Name
+LIMIT 200
+```
+Deactivated users retain permission set assignments in the database. These
+are not a live security risk (inactive users cannot log in) but represent
+cleanup debt and can cause confusion during re-activation.
+
+---
+
+## Permission Set vs Permission Set Group: Decision Guide
+
+| Scenario | Use |
+|----------|-----|
+| Single capability (e.g., "Export Reports") | Permission Set |
+| Job function requiring multiple capabilities | Permission Set Group |
+| Temporary elevated access for a project | Permission Set (time-limited manual assignment) |
+| System-level access (admin equivalents) | Permission Set Group with approval workflow |
+| Integration user access | Dedicated Permission Set matching integration's exact needs |
+
+---
+
+## Salesforce Recommended Security Patterns
+
+1. **One profile per user type** — minimize the number of profiles to reduce
+   maintenance burden.
+2. **Never grant system permissions at the profile level** — use Permission Sets.
+3. **Use Permission Set Groups** for all job-function bundles.
+4. **Name Permission Sets by capability**, not by user type:
+   - GOOD: `Can_Export_Reports`, `Read_Financial_Data`, `API_Integration_Access`
+   - BAD: `Sales_Rep_Set`, `Marketing_User`, `IT_Admin_Plus`
+5. **Review all Permission Set assignments quarterly** for critical permissions.
+6. **Use muting Permission Sets** in Permission Set Groups to selectively remove
+   permissions granted by included sets without removing the entire set.

package/skills/salesforce/salesforce-permission-model-review-skill/references/toxic-combinations.md

@@ -0,0 +1,228 @@
+# Toxic Combinations Reference
+
+Permission combinations in Salesforce that create disproportionate security
+risk when held by the same user or profile. Each combination requires
+documented justification or remediation.
+
+---
+
+## Definition: Toxic Combination
+
+A toxic combination is two or more permissions that, when held together, provide
+a level of access significantly more dangerous than either permission alone.
+
+---
+
+## Tier 1: Critical Combinations (Zero Tolerance in Production)
+
+### 1.1 ModifyAllData + API Enabled
+
+**Why Critical:**
+A user with ModifyAllData can update, delete, or create any record in the org.
+Combined with API Enabled, this access is available programmatically — scripts,
+bots, or attackers who compromise the credentials can automate mass data
+destruction or exfiltration without any UI friction.
+
+**Detection:**
+```sql
+SELECT Id, Name, Profile.Name,
+       Profile.PermissionsModifyAllData,
+       Profile.PermissionsApiEnabled
+FROM User
+WHERE IsActive = true
+  AND Profile.PermissionsModifyAllData = true
+  AND Profile.PermissionsApiEnabled = true
+  AND Profile.Name != 'System Administrator'
+```
+
+**Acceptable:** System Administrator profile only, with < 5 named users,
+no shared logins, IP restrictions enforced.
+
+### 1.2 ModifyAllData + ManageUsers
+
+**Why Critical:**
+A user who can modify all data AND manage users can create new admin users,
+reset passwords, and potentially create a persistent backdoor even if their
+original account is revoked.
+
+**Detection:**
+```sql
+SELECT Id, Name, Profile.Name
+FROM User
+WHERE IsActive = true
+  AND Profile.PermissionsModifyAllData = true
+  AND Profile.PermissionsManageUsers = true
+  AND Profile.Name != 'System Administrator'
+```
+
+### 1.3 ViewEncryptedData + API Enabled
+
+**Why Critical:**
+ViewEncryptedData allows a user to see Shield Platform Encryption
+encrypted field values in plaintext. Combined with API Enabled, encrypted
+data (SSNs, financial accounts, health data) can be bulk-exported via API
+without any additional UI barrier.
+
+**Detection:**
+```sql
+SELECT Id, Name, Profile.Name, Profile.PermissionsViewEncryptedData
+FROM User
+WHERE IsActive = true
+  AND Profile.PermissionsViewEncryptedData = true
+  AND Profile.PermissionsApiEnabled = true
+LIMIT 100
+```
+
+**Expected:** Only users with documented business need for decrypted field
+access (e.g., compliance team, specific data stewards). Count should be < 10.
+
+---
+
+## Tier 2: High-Risk Combinations (Require Documented Justification)
+
+### 2.1 ViewAllData + Export Reports
+
+A user who can view all records AND export report results can bulk-extract
+any data in the org into a spreadsheet. Without Export Reports, ViewAllData
+is limited to on-screen viewing.
+
+**Detection:**
+```sql
+SELECT Id, Name, Profile.Name,
+       Profile.PermissionsViewAllData
+FROM User
+WHERE IsActive = true
+  AND Profile.PermissionsViewAllData = true
+LIMIT 200
+-- Then separately check if profile has Export Reports permission
+-- (PermissionsExportReport not available in simple SOQL — use Metadata API)
+```
+
+### 2.2 ManageDataCategories + Manage Knowledge
+
+A user who controls Knowledge Data Categories AND manages Knowledge Articles
+can restructure the knowledge base in ways that affect Agentforce grounding,
+search relevance, and customer-facing help content simultaneously.
+
+**Finding:** No justification needed if role is explicitly Knowledge Manager —
+document the role and ensure the account has MFA.
+
+### 2.3 AuthorApex + ManageFlowMigrateConnections
+
+**Why Risky:**
+A developer who can write Apex AND migrate Flow connections between objects
+can potentially combine automation layers to bypass business logic or access
+controls in non-obvious ways.
+
+### 2.4 PermissionsManageIPAddresses + PermissionsManageUsers
+
+Managing IP restrictions AND managing users allows an attacker (or insider
+threat) to whitelist their own IP and then create accounts for persistent access.
+
+---
+
+## Tier 3: Elevated-Risk Profiles for Regular Review
+
+The following profiles/permission set combinations should be reviewed quarterly
+regardless of whether a specific toxic combination is present:
+
+| Profile / Permission Set | Review Frequency | Why |
+|--------------------------|-----------------|-----|
+| System Administrator | Quarterly | Highest privilege; any user is a critical risk |
+| Profiles with ModifyAllData | Quarterly | Mass data write capability |
+| Profiles with ViewAllData | Semi-annually | Mass data read capability |
+| Integration user profiles | Quarterly | API access; no interactive MFA |
+| Guest User profile | Monthly | Public-facing; controls unauthenticated access |
+
+---
+
+## Guest User Profile: Special Handling
+
+The Salesforce Guest User profile controls access for unauthenticated visitors
+to Experience Cloud sites
+and Salesforce Embedded Service.
+
+### Required Restrictions
+
+```
+Guest User profile must NOT have:
+  [ ] API Enabled
+  [ ] View All Data
+  [ ] Modify All Data
+  [ ] Export Reports
+  [ ] Access to any custom object with sensitive data (PHI, financial, PII)
+
+Guest User profile OWD access:
+  [ ] Guest User visibility settings reviewed annually
+  [ ] Objects accessible by Guest User limited to genuinely public content
+```
+
+### Query for Guest User Profile Users
+```sql
+SELECT Id, Name, Profile.Name, Profile.UserLicense.Name
+FROM User
+WHERE Profile.UserLicense.Name = 'Guest User'
+  AND IsActive = true
+```
+
+---
+
+## Broad Profile Assignments
+
+Beyond specific permission combinations, a finding category is "excessive
+users on high-privilege profiles."
+
+### Thresholds
+
+| Profile Name | Acceptable User Count | Action if Exceeded |
+|-------------|----------------------|-------------------|
+| System Administrator | < 5 | Immediate remediation |
+| Standard User with ModifyAllData | 0 (this is System Admin) | Report as misconfiguration |
+| Custom admin-equivalent profile | < 10 | Review and justify each |
+| Read-only integration profile | No limit | Ensure no write permissions |
+
+**Query:**
+```sql
+SELECT Profile.Name, COUNT(Id) userCount
+FROM User
+WHERE IsActive = true
+GROUP BY Profile.Name
+ORDER BY COUNT(Id) DESC
+LIMIT 30
+```
+
+---
+
+## Toxic Combination Detection Script (Anonymous Apex)
+
+```apex
+// Report users with both ModifyAllData and ManageUsers (non-sys-admin)
+List<User> riskyUsers = [
+    SELECT Id, Name, Username, Profile.Name,
+           Profile.PermissionsModifyAllData,
+           Profile.PermissionsManageUsers,
+           Profile.PermissionsApiEnabled,
+           Profile.PermissionsViewAllData
+    FROM User
+    WHERE IsActive = true
+      AND Profile.Name != 'System Administrator'
+      AND (
+        (Profile.PermissionsModifyAllData = true AND Profile.PermissionsManageUsers = true)
+        OR
+        (Profile.PermissionsModifyAllData = true AND Profile.PermissionsApiEnabled = true)
+        OR
+        (Profile.PermissionsViewAllData = true AND Profile.PermissionsApiEnabled = true)
+      )
+];
+
+for (User u : riskyUsers) {
+    System.debug(
+        'RISK FINDING - User: ' + u.Name +
+        ' | Profile: ' + u.Profile.Name +
+        ' | ModAll: ' + u.Profile.PermissionsModifyAllData +
+        ' | ManageUsers: ' + u.Profile.PermissionsManageUsers +
+        ' | API: ' + u.Profile.PermissionsApiEnabled
+    );
+}
+System.debug('Total risky users found: ' + riskyUsers.size);
+```

package/skills/salesforce/salesforce-release-readiness-skill/SKILL.md

@@ -0,0 +1,185 @@
+---
+name: salesforce-release-readiness-skill
+description: Use this skill when a Salesforce release must be evaluated for deployment readiness. Covers: sandbox refresh strategy, source tracking state, package version diff, destructiveChanges.xml review, test coverage threshold verification, post-deploy steps, rollback plan, comms plan, and approval matrix. Trigger phrases: "is this release ready to deploy", "review the destructive changes for this release", "check our sandbox strategy", "validate the release checklist", "pre-deploy readiness review". Do not use when you need to approve a live production mutation at execution time (use salesforce-live-change-approval-protocol), when code quality is the focus (use salesforce-apex-lwc-code-review-skill), or when automation logic needs review (use salesforce-flow-automation-review-skill). Works from release artifacts and plans only; never requests live org access or executes deployments.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-20"
+  category: delivery
+  lifecycle: experimental
+---
+
+# Salesforce Release Readiness Skill
+
+## Purpose
+This skill evaluates a Salesforce release for deployment readiness. It produces
+a structured readiness assessment covering sandbox strategy, source tracking,
+package diff, destructive changes, test coverage, post-deploy steps, rollback
+plan, communications plan, and approval matrix. It does not execute deployments,
+access live orgs, or authorize production changes.
+
+## When to use
+- A Salesforce release is being prepared and readiness must be assessed.
+- A change set or DX package deployment is planned and the checklist must be verified.
+- A destructiveChanges.xml must be reviewed before a production deploy.
+- A release retrospective revealed a gap in the pre-deploy process.
+
+## When not to use
+- Live production mutation approval at execution time — use `salesforce-live-change-approval-protocol`.
+- Code quality review — use `salesforce-apex-lwc-code-review-skill`.
+- Automation logic review — use `salesforce-flow-automation-review-skill`.
+- Metadata quality review — use `salesforce-metadata-review-skill`.
+
+## Minimum payload (required inputs)
+- Release description: what is being deployed (features, fixes, metadata types).
+- Target environment: sandbox → sandbox, sandbox → production (use placeholder, not real org ID).
+- Deployment method: change set, SFDX/SF CLI deploy, CI/CD pipeline, ISV package install.
+- Available artifacts: package diff, destructiveChanges.xml (if applicable), test run output.
+- Rollback plan (or note that it is missing).
+
+## Workflow
+
+### 1. Sandbox refresh strategy
+- Verify that testing occurred in a sandbox refreshed from production within
+  a defined window (configurable threshold, e.g., 30 days).
+- Flag: testing only in a developer sandbox without a full-copy or partial-copy
+  refresh for complex data-dependent features.
+- Flag: sandbox refresh done after feature development began (data divergence risk).
+
+### 2. Source tracking state
+- Review source tracking status: are there untracked local changes?
+- Flag: uncommitted changes in tracked source that are not part of the release.
+- Flag: metadata retrieved outside source tracking that may overwrite tracked changes.
+- Verify: scratch org (
+Salesforce DX)
+  or sandbox state matches the deployment package.
+
+### 3. Package version diff
+- Review the list of metadata components in the deployment package.
+- Flag: metadata types that are unexpectedly included (scope creep).
+- Flag: metadata components that are expected but missing from the package.
+- Flag: large diff (> configurable threshold components) without a phased
+  deployment plan.
+
+### 4. Destructive changes review
+- If destructiveChanges.xml is present:
+  - List all components marked for deletion.
+  - Flag: deletion of custom fields on objects with active sharing rules or
+    automation referencing those fields.
+  - Flag: deletion of Apex classes referenced by other classes not in the package.
+  - Flag: deletion without a data migration plan for fields containing data.
+  - Flag: deletion of permission sets that are actively assigned.
+- If destructiveChanges.xml is absent but deletions are expected: flag missing
+  destructive changes manifest.
+
+### 5. Test coverage threshold
+- Verify that Apex test coverage meets the org threshold (default 75%; flag if
+  org has a higher custom threshold).
+- Flag: test classes with `SeeAllData=true` in the test run.
+- Flag: test run results showing failures (zero failures required for production deploy).
+- Flag: test coverage calculated only on deployed classes, not org-wide (insufficient).
+- Recommend: run all tests (`RunAllTestsInOrg`) for production deployments.
+
+### 6. Post-deploy steps
+- Verify that a post-deploy step list exists and is documented.
+- Flag: manual configuration steps not captured in the package (e.g., custom
+  metadata values, permission set assignments, named credential setup).
+- Flag: post-deploy steps that require production data access without a
+  documented data-access control.
+
+### 7. Rollback plan
+- Verify that a rollback plan exists and is actionable.
+- Flag: rollback plan that is "redeploy the previous package" without a
+  version reference.
+- Flag: rollback plan for destructive changes (field/object deletion is
+  irreversible without data backup).
+- Recommend: document rollback estimated time and who authorizes rollback.
+
+### 8. Communications plan
+- Verify that a user communications plan exists for user-visible changes.
+- Flag: changes to page layouts, record types, or permissions without a
+  comms plan.
+- Flag: scheduled deployments during business hours without maintenance window
+  notification.
+
+### 9. Approval matrix
+- Verify that the approval matrix is documented: who approved the release,
+  at what level (developer, tech lead, architect, change advisory board).
+- Flag: production deployments without documented architecture or change board
+  approval for significant changes.
+- Flag: emergency deployments without a documented fast-track approval path.
+
+## Evidence requirements
+- Release description, deployment method, and target environment.
+- Package component list or diff.
+- Test run output (or note that it is unavailable).
+- Rollback plan (or note that it is missing).
+
+## Output format
+```
+release_readiness_assessment:
+  sandbox_refresh:
+    status: ready | at-risk | not-ready
+    findings: [list]
+  source_tracking:
+    status: ready | at-risk | not-ready
+    findings: [list]
+  package_version_diff:
+    status: ready | at-risk | not-ready
+    findings: [list]
+  destructive_changes:
+    status: ready | at-risk | not-ready | not-applicable
+    findings: [list]
+  test_coverage:
+    status: ready | at-risk | not-ready
+    findings: [list]
+  post_deploy_steps:
+    status: ready | at-risk | not-ready
+    findings: [list]
+  rollback_plan:
+    status: ready | at-risk | not-ready
+    findings: [list]
+  communications_plan:
+    status: ready | at-risk | not-ready
+    findings: [list]
+  approval_matrix:
+    status: ready | at-risk | not-ready
+    findings: [list]
+
+overall_readiness: ready | at-risk | not-ready
+blocking_issues: [list — items that must be resolved before deploy]
+non_blocking_issues: [list — recommendations for improvement]
+escalation_gates_fired: [from salesforce-risk-taxonomy, or "none"]
+assumptions: [list]
+missing_evidence: [what would improve the assessment]
+```
+
+## 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.
+- Do not include real usernames or approver identities; use role references.
+
+## Privilege / data handling rules
+- Release artifacts must not contain production data samples.
+- Destructive changes review involving regulated-data fields escalates to compliance review.
+
+## Handoff rules
+- Hands off to: salesforce-live-change-approval-protocol (if overall_readiness = ready and
+  production deploy is next), salesforce-apex-lwc-code-review-skill (if test coverage gaps
+  need code-level review), salesforce-case-capsule (if escalation_gates_fired).
+- Required handoff fields: matter_id, overall_readiness, blocking_issues,
+  escalation_gates_fired.
+
+## Audit log fields
+- matter_id, skill_id, skill_version, invoked_by, input_hash, evidence_quality, output_verdict, escalation_fired, timestamp
+
+## Stop conditions
+- Destructive changes include field deletion on objects with unreviewed data — stop and flag irreversible-deploy gate.
+- Test run shows failures — overall_readiness = not-ready; do not proceed.
+- Rollback plan is absent and deployment includes irreversible changes — stop and require rollback plan before assessment can complete.
+
+## Security notes
+- Read-only advisory assessment; never executes deployments or requests live org access.
+- Destructive changes are irreversible; always require human-authorized rollback plan documentation.
+- Approval matrix verification is a governance control; its absence is a high-severity finding.

package/skills/salesforce/salesforce-release-readiness-skill/metadata.json

@@ -0,0 +1,18 @@
+{
+  "id": "salesforce-release-readiness-skill",
+  "name": "Salesforce Release Readiness Skill",
+  "type": "skill",
+  "provider": "salesforce",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Pre-release checklist assessment for Salesforce deployments — covers sandbox refresh strategy, source tracking state, package version diff, destructiveChanges.xml review, test coverage threshold, post-deploy steps, rollback plan, comms plan, and approval matrix. Advisory only; never executes deployments.",
+  "source_type": "original",
+  "official_docs": [
+    "https://help.salesforce.com/",
+    "https://developer.salesforce.com/docs"
+  ],
+  "security_notes": "Read-only advisory assessment; sanitized release artifacts only; never requests live org credentials or executes deployments. Irreversible destructive changes always require documented rollback plan. Regulated-data field deletions escalated to compliance review.",
+  "last_verified": "2026-05-20",
+  "path": "skills/salesforce/salesforce-release-readiness-skill",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}