@raishin/vanguard-frontier-agentic 2.2.0 → 2.5.0

package/skills/salesforce/salesforce-flow-debugger-skill/references/flow-error-patterns.md

@@ -0,0 +1,247 @@
+# Flow Error Patterns Reference
+
+## Pattern 1: UNHANDLED_FAULT on Action Element
+
+**Error signature:**
+```
+An unhandled fault has occurred in this flow
+An unhandled fault has occurred while processing the flow with name <FlowName>.
+Here's how to locate the problem:
+Failed Flow Interviews section: <ElementName>
+```
+
+**Root cause:** An Action element (Send Email, Apex Action, HTTP Callout,
+Create Records, Update Records, etc.) threw an exception and there is no
+fault connector on that element.
+
+**Fix:**
+1. In Flow Builder, click the failing Action element
+2. Open the "Add Fault Path" option (icon at the bottom of the element)
+3. Connect the fault path to a Fault Handler subflow or a Screen element
+   that displays `{!$Flow.FaultMessage}`
+4. Deploy the updated Flow version
+
+**Key note:** Every Action element that can fail in production MUST have a
+fault connector unless the Flow is designed to surface unhandled errors to
+the platform exception log intentionally.
+
+---
+
+## Pattern 2: NullPointerException on Assignment or Decision
+
+**Error signature:**
+```
+NullPointerException: Attempt to dereference a null object
+Element: <AssignmentOrDecisionName>
+```
+
+**Root cause variants:**
+1. A variable used in an Assignment or Decision was never populated (loop
+   ran zero iterations; GetRecords returned no records)
+2. A collection variable element is accessed by index when the collection
+   is empty
+3. A record variable's field is accessed after a GetRecords that returned
+   null
+
+**Fix:**
+1. Add a Decision element BEFORE the failing element to check if the
+   variable or record is null:
+   - `{!recordVar} Is Null → True` → fault path / error screen
+   - `{!collectionVar} Is Empty → True` → skip the loop
+2. For GetRecords: set "How Many Records to Store" to "Only the First Record"
+   and enable "Automatically store all fields" — then add a null check on
+   `{!recordVar}` before use
+3. For Loops: ensure the loop's collection has at least one element before
+   entering the loop (check collection size Decision)
+
+---
+
+## Pattern 3: DML Exception in Update Records / Create Records
+
+**Error signature:**
+```
+FIELD_INTEGRITY_EXCEPTION: <field>: value not valid for org
+REQUIRED_FIELD_MISSING: Required fields are missing: [<field>]
+DUPLICATE_VALUE: duplicate value found
+```
+
+**Root cause variants:**
+1. A required field on the record is null when Flow tries to update
+2. A validation rule on the object is blocking the save
+3. A duplicate management rule is firing
+4. The record is locked (approval process lock or record lock)
+
+**Fix:**
+1. For required field: add an Assignment before Update Records to ensure
+   the required field has a value; add a Decision to check first
+2. For validation rule conflict: work with the admin to add a Flow-user
+   bypass on the validation rule, or ensure Flow populates all required
+   fields
+3. For duplicate rule: check if Flow should merge or skip duplicates;
+   update duplicate rule configuration
+4. For record lock: add error handling and a custom notification to the
+   approver
+
+---
+
+## Pattern 4: Governor Limit in Loop
+
+**Error signature:**
+```
+CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY: <object>: Too many SOQL queries: 101
+CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY: <object>: Too many DML statements: 151
+```
+
+**Root cause:** DML operations (Create Records, Update Records, Delete
+Records) or subflows that query data are inside a Loop element. Each
+iteration consumes one DML statement or SOQL query.
+
+**Fix:**
+1. Move all Get Records and Create/Update Records elements OUTSIDE the loop
+2. Inside the loop: add items to a Record Collection variable
+3. After the loop: use a single Create Records or Update Records element
+   with "All records from collection"
+4. Check if subflows called inside the loop perform DML — move DML to
+   after the loop if possible
+
+**Pattern: Bulk-safe loop structure**
+```
+Get Records → (populate collection)
+Loop (iterate collection):
+  → Assignment: add modified record to output collection
+After loop:
+  → Update Records: update all records in output collection (single DML)
+```
+
+---
+
+## Pattern 5: Missing Fault Connector on Send Email
+
+**Error signature:**
+```
+UNHANDLED_FAULT: Email send failed: invalid address <address>
+SendEmailException: From address is not allowed in this context
+```
+
+**Root cause:** Flow attempts to send email to an invalid or restricted
+address, but the Send Email element has no fault connector.
+
+**Fix:**
+1. Add a fault connector on the Send Email element
+2. Log the fault message to a custom object field or platform event
+3. Send a fallback admin notification using `{!$Flow.FaultMessage}`
+4. Consider validating the email address in a Decision element before
+   reaching Send Email (regex formula or ISBLANK check)
+
+---
+
+## Pattern 6: Record Not Found (GetRecords Returns Null)
+
+**Error signature (implicit — no record, then null dereference follows):**
+```
+NullPointerException after GetRecords element
+Variable <recordVar> has null value
+```
+
+**Root cause:** GetRecords found no matching records and returned null.
+The next element attempts to use the record variable.
+
+**Fix:**
+1. After GetRecords, add a Decision element:
+   - Condition: `{!recordVar} Is Null → True` → null handling branch
+   - Default (record found) → continue the happy path
+2. Alternatively, if GetRecords is set to collect into a collection, check
+   if the collection `Is Empty` before the loop
+3. For critical lookups (e.g., finding the Pricebook), add a fault screen
+   with a user-friendly message
+
+---
+
+## Pattern 7: Type Mismatch in Assignment
+
+**Error signature:**
+```
+INVALID_TYPE: Illegal assignment from <TypeA> to <TypeB>
+```
+
+**Root cause:** Attempting to assign a value of one type to a variable
+of another type. Common examples:
+- Assigning a Number to a Text variable without conversion
+- Assigning a Date to a DateTime variable
+- Assigning a record collection to a single record variable
+
+**Fix:**
+1. Use intermediate variables with the correct type
+2. For Number → Text: use a Formula resource of type Text that references
+   the Number variable
+3. For Date → DateTime: use a Formula `DATETIMEVALUE(TEXT(dateVar))`
+4. Verify the variable types in the Resources panel — check all variables
+   used in Assignments
+
+---
+
+## Pattern 8: Recursive Flow / Loop Count Limit
+
+**Error signature:**
+```
+FLOW_LOOP_COUNT_LIMIT: Maximum loop iterations exceeded
+Recursive entry: Flow <FlowName> has been entered recursively
+```
+
+**Root cause:**
+1. A Record-Triggered Flow updates a field on the same record, causing
+   the trigger to fire again (recursion)
+2. A Loop element exceeds the 2,000 iteration limit
+
+**Fix for recursion:**
+1. Add a custom checkbox field `Flow_Processed__c` to the object
+2. Add an Entry Condition: only trigger the Flow when `Flow_Processed__c = False`
+3. At the end of the Flow, set `Flow_Processed__c = True`
+4. Alternatively, use `ISCHANGED(field)` entry conditions to limit when the
+   Flow re-enters
+
+**Fix for loop limit:**
+1. Identify why the collection has > 2,000 items
+2. Implement a Scheduled Flow with smaller batches
+3. Move bulk processing to Apex
+
+---
+
+## Pattern 9: Subflow Not Found / Version Error
+
+**Error signature:**
+```
+CANNOT_EXECUTE_FLOW_TRIGGER: <SubflowName>: active version not found
+Flow Reference Error: <SubflowName> is not active
+```
+
+**Root cause:** The called subflow is not active in this org (may have been
+deployed in a deactivated state or not deployed at all).
+
+**Fix:**
+1. In Setup → Flows, find `<SubflowName>` and verify it is Active
+2. If not deployed, deploy it first (via Change Set or `sf project deploy`)
+3. If there are multiple versions, verify the parent Flow references the
+   correct version or "Latest Active Version"
+
+---
+
+## Pattern 10: Insufficient Access / FLS Error
+
+**Error signature:**
+```
+INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY: insufficient access rights on cross-reference id
+FIELD_ACCESS_EXCEPTION: No access to field <FieldApiName>
+```
+
+**Root cause:** The user running the Flow (or the System Context setting)
+does not have access to the object or field being read/written.
+
+**Fix:**
+1. Check the Flow's "Run As" context: is it "User" or "System Context with
+   Sharing" or "System Context without Sharing"?
+2. For Record-Triggered Flows that update related records: use
+   "System Context without Sharing" if cross-object access is required
+3. For Screen Flows that fail for specific users: check profile/permission
+   set field-level security on the failing field
+4. Route access investigation to `salesforce-permission-model-review-skill`

package/skills/salesforce/salesforce-flow-debugger-skill/references/interview-log-redaction.md

@@ -0,0 +1,171 @@
+# Interview Log Redaction Reference
+
+## What Is a FlowInterviewLog
+
+`FlowInterviewLog` is a Salesforce object that records details of each Flow
+execution (interview). It is available when Flow Interview Logging is enabled
+in Setup → Process Automation Settings.
+
+**Key fields on FlowInterviewLog:**
+
+| Field | Contains | Redaction required? |
+|---|---|---|
+| `Id` | 18-char Salesforce ID | Yes — `<log_id_placeholder>` |
+| `FlowApiName` | Developer name of the Flow | No |
+| `FlowVersionRunNumber` | Integer version number | No |
+| `InterviewLabel` | Display label of the interview | No |
+| `CurrentElement` | Element where the interview is at | No |
+| `ErrorCode` | Error type string | No |
+| `ErrorMessage` | Full error message text | Yes — sanitize embedded IDs and values |
+| `StartTime` | ISO datetime | No |
+| `EndTime` | ISO datetime | No |
+| `Status` | Fault, Finished, etc. | No |
+| `RunningUserId` | 18-char User ID | Yes — `<user_id_placeholder>` |
+
+**Key fields on FlowInterviewLogEntry (child object):**
+
+| Field | Contains | Redaction required? |
+|---|---|---|
+| `InterviewId` | Parent FlowInterviewLog ID | Yes — `<log_id_placeholder>` |
+| `ElementApiName` | Element API name | No |
+| `ElementLabel` | Element display label | No |
+| `Input` | Input variables serialized as JSON | Yes — mask all variable values |
+| `Output` | Output variables serialized as JSON | Yes — mask all variable values |
+| `DurationMillis` | Execution time | No |
+
+---
+
+## Redaction Steps for FlowInterviewLog Output
+
+### Step 1 — Strip Record IDs
+
+Replace all 15-character and 18-character Salesforce record IDs with placeholders.
+
+Patterns to match:
+- 18-character: `[0-9a-zA-Z]{18}` where the prefix identifies the object type
+  (e.g., `00D` for Org, `005` for User, `001` for Account, `006` for Opportunity)
+- 15-character: Shorter version of the same
+
+Common prefixes to watch for in error messages:
+
+| Prefix | Object |
+|---|---|
+| `00D` | Organization ID |
+| `005` | User |
+| `001` | Account |
+| `006` | Opportunity |
+| `003` | Contact |
+| `00Q` | Lead |
+| `500` | Case |
+| `a00` or similar | Custom objects |
+
+### Step 2 — Mask Variable Values in Input/Output Fields
+
+The `Input` and `Output` JSON fields in `FlowInterviewLogEntry` contain
+serialized variable values. These can include:
+
+- Email addresses
+- Phone numbers
+- Names and company names
+- Record IDs
+- Picklist values that may indicate sensitive categories
+
+**Masking approach:**
+
+```bash
+# Using jq to mask all values while preserving keys
+echo '<log_json>' | jq '
+  .result.records[] |
+  {
+    ElementApiName: .ElementApiName,
+    ElementLabel: .ElementLabel,
+    Input: (.Input | fromjson | with_entries(.value = "<redacted>") | tojson),
+    Output: (.Output | fromjson | with_entries(.value = "<redacted>") | tojson),
+    DurationMillis: .DurationMillis
+  }
+'
+```
+
+For debugging purposes, preserve the variable **keys** (names) but mask
+the **values**. This allows root cause analysis without exposing data.
+
+### Step 3 — Sanitize ErrorMessage Field
+
+The `ErrorMessage` field often contains embedded record IDs and sometimes
+field values in the error context. Apply a regex pass:
+
+```python
+import re
+
+def redact_sf_ids(text):
+    # Replace 18-char Salesforce IDs
+    text = re.sub(r'\b[0-9a-zA-Z]{18}\b', '<record_id_placeholder>', text)
+    # Replace 15-char Salesforce IDs
+    text = re.sub(r'\b[0-9a-zA-Z]{15}\b', '<record_id_placeholder>', text)
+    return text
+```
+
+### Step 4 — Aggregate Failure Counts Instead of Listing Individual Records
+
+When multiple records fail with the same error pattern, aggregate rather
+than listing each failing record ID:
+
+**Before redaction:**
+```
+Record 001Xx000001ABCDEF failed: Required field missing
+Record 001Xx000001GHIJKL failed: Required field missing
+Record 001Xx000001MNOPQR failed: Required field missing
+```
+
+**After aggregation and redaction:**
+```
+3 records failed with: Required field missing
+Failing element: Update Records (UpdateOpportunity)
+Sample error: Required field missing: [CloseDate]
+```
+
+---
+
+## Minimum Safe Output for Debugging
+
+The minimum information needed for diagnosis without exposing sensitive data:
+
+```yaml
+flow_interview_summary:
+  flow_api_name: "<FlowApiName>"
+  flow_version: "<integer>"
+  error_code: "<ErrorCode>"
+  error_message_sanitized: "<sanitized error — IDs replaced with placeholder>"
+  failing_element_api_name: "<ElementApiName>"
+  failing_element_label: "<ElementLabel>"
+  status: "Fault"
+  duration_ms: <integer>
+
+variable_context:
+  # Keys preserved, values masked
+  variables_in_scope:
+    - name: "<variableName>"
+      type: "<Text|Number|Record|Boolean>"
+      value: "<redacted>"
+      was_null: <true|false>
+```
+
+The `was_null` field can be inferred from the error type (NullPointerException
+or similar) without revealing the actual value.
+
+---
+
+## Enabling Flow Interview Logging
+
+If `FlowInterviewLog` is not queryable, it must be enabled first:
+
+1. Setup → Process Automation Settings
+2. Enable "Flow Interview Logging"
+3. Choose log level: "Minimal", "Standard", or "Detailed"
+4. Note: Detailed logging can consume significant storage — enable during
+   debugging only, then disable after resolution
+
+**Fallback when logging is not enabled:**
+Use the Flow debug run in Setup → Flows → Debug (sandbox only) to
+generate a step-by-step debug log. Paste the debug output into
+T0 mode of this skill for analysis.

package/skills/salesforce/salesforce-infrastructure-audit-skill/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: salesforce-infrastructure-audit-skill
+description: Use this skill when Salesforce infrastructure security posture must be audited — covering network security policies, trusted IP ranges, login IP ranges per profile, CSP Trusted Sites configuration, session security settings, sandbox isolation strategy, sandbox data-sensitivity alignment, Hyperforce deployment controls, and data residency commitments. Trigger phrases: "audit Salesforce infrastructure security", "review network policies", "check IP allowlist config", "assess sandbox isolation", "review session settings", "check Hyperforce security posture". Do not use when identity or IAM permissioning is the focus (use salesforce-permission-model-review-skill), when a live production change is being made (use salesforce-live-change-approval-protocol), or when zero-trust maturity scoring across NIST pillars is needed (use salesforce-zero-trust-maturity-skill). Works from sanitized config exports only; never requests live org access.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-21"
+  category: security
+  lifecycle: experimental
+---
+
+# Salesforce Infrastructure Audit Skill
+
+## Purpose
+This skill conducts a structured security audit of Salesforce infrastructure controls — network access policies, session security settings, sandbox isolation, Hyperforce deployment configuration, and CSP Trusted Sites. It produces a tiered risk register of findings without accessing live orgs or executing API calls. It is the shared workflow called by all infrastructure security agents in the Salesforce agent catalog.
+
+## When to use
+- A compliance review or certification requires evidence of infrastructure security controls.
+- Sandbox environments handle production-equivalent data and isolation must be verified.
+- Network access policy, IP allowlisting, or CSP configuration is being assessed before audit.
+- Hyperforce deployment region selection or data residency commitments need review.
+- Session security settings (timeout, clickjack, HTTPS enforcement) are under scrutiny.
+
+## When not to use
+- Identity or IAM review (profiles, permission sets, sharing rules) — use `salesforce-permission-model-review-skill`.
+- Live production configuration changes — use `salesforce-live-change-approval-protocol`.
+- Zero-trust maturity scoring across NIST ZTA pillars — use `salesforce-zero-trust-maturity-skill`.
+- Full org posture assessment combining all domains — use `salesforce-org-assessment-skill`.
+
+## Minimum payload (required inputs)
+- Sanitized network access exports: trusted IP ranges, login IP ranges per profile.
+- CSP Trusted Sites list (URLs and directive scope).
+- Session settings export: timeout values, clickjack protection level, HTTPS enforcement flag, high-assurance session trigger configuration.
+- Sandbox inventory: sandbox name, type (Developer, Developer Pro, Partial, Full), last refresh date, data masking configuration.
+- Hyperforce configuration summary: deployment region, data residency scope, Infrastructure Access audit log status.
+- Context: industry vertical, regulatory framework (e.g., HIPAA, PCI-DSS, GDPR), approximate user population.
+
+## Workflow
+
+### 1. Network policy inventory
+- List all configured trusted IP ranges (Network Access).
+- List login IP ranges applied per profile.
+- Flag: no IP restriction on profiles with `API Enabled` or `ModifyAllData`.
+- Flag: overly broad CIDR ranges (e.g., /8 or wider) applied to sensitive profiles.
+- Flag: CSP Trusted Sites entries using wildcard (`*`) domains or non-HTTPS origins.
+- Flag: CSP Trusted Sites entries pointing to third-party origins not documented in vendor inventory.
+- Record total trusted IP range count and CIDR surface area.
+
+### 2. Session security review
+- Review session timeout values per security zone (standard users, admins, privileged service accounts).
+- Flag: session timeout > 2 hours for profiles with `Modify All Data`, `Manage Users`, or `View All Data`.
+- Flag: `Lock sessions to the IP address from which they originated` disabled for privileged profiles.
+- Flag: clickjack protection set below `Allow framing by same-origin pages only` in production.
+- Flag: HTTPS-only enforcement not enabled at org level.
+- Flag: high-assurance session triggers absent for sensitive operations (e.g., report export, data export).
+- Record clickjack protection level and HTTPS enforcement status.
+
+### 3. Sandbox isolation check
+- Map each sandbox to its type and the data sensitivity of workloads it hosts.
+- Flag: Full or Partial sandbox refreshed from production without data masking configuration present.
+- Flag: Full sandbox type used for external vendor or contractor access without network restriction.
+- Flag: sandbox refresh policy absent or refresh interval > 90 days for sandboxes handling regulated data.
+- Flag: Developer sandbox used to test integrations that require production-equivalent PII volume.
+- Record sandbox count by type, masking coverage, and refresh cadence.
+
+### 4. Hyperforce posture review
+- Confirm deployment region matches documented data residency commitments.
+- Flag: Hyperforce region selection inconsistent with regulatory data-localization requirements.
+- Flag: Infrastructure Access
+not configured or audit log not enabled.
+- Flag: data residency scope documentation absent or not reviewed within the last 12 months.
+- Record region, residency commitment document reference, and Infrastructure Access status.
+
+### 5. Risk register assembly
+- Consolidate findings from steps 1–4.
+- Assign risk_tier per finding: Critical | High | Medium | Low.
+- Map each finding to its relevant control domain (network, session, sandbox, Hyperforce, CSP).
+- Identify findings that meet escalation gates from salesforce-risk-taxonomy.
+
+## Evidence requirements
+- Sanitized exports only; no credentials, session tokens, or customer records.
+- Sandbox inventory must include type and data masking status to produce sandbox findings.
+- Hyperforce region and data residency documentation are required for step 4.
+- Session settings export is required for step 2; absence produces an "insufficient evidence" note.
+
+## Output format
+```
+infrastructure_audit_findings:
+  network_policy_findings:
+    - finding: [description]
+      severity: Critical | High | Medium | Low
+      control_domain: network | session | sandbox | hyperforce | csp
+      evidence: [what in the export supports this]
+      recommendation: [brief]
+  session_security_findings: [same structure]
+  sandbox_isolation_findings: [same structure]
+  hyperforce_findings: [same structure]
+  csp_findings: [same structure]
+
+escalation_gates_fired: [from salesforce-risk-taxonomy, or "none"]
+summary:
+  critical_count: [count]
+  high_count: [count]
+  medium_count: [count]
+  low_count: [count]
+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 before sharing in outputs.
+- Do not include actual IP addresses in outputs; use range notation and CIDR width only.
+
+## Privilege / data handling rules
+- Works from schema-level exports and sanitized configs only.
+- Sandbox findings involving regulated-data exposure must be flagged for compliance specialist review.
+- Hyperforce data residency gaps in regulated industries (healthcare, finance) must trigger escalation review.
+
+## Handoff rules
+- Hands off to: salesforce-permission-model-review-skill (if IP restriction gaps require permission-level review), salesforce-zero-trust-maturity-skill (if session or network findings indicate broader ZTA gaps), salesforce-case-capsule (for any Critical finding requiring human authorization).
+- 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
+- Export contains live credentials, session tokens, or unredacted customer PII — stop and request sanitized version.
+- Hyperforce data residency gap confirmed in a regulated industry with active data-localization obligation — stop, output ESCALATE, require compliance specialist review before continuing.
+- Sandbox confirmed to contain unmasked production PII with external-vendor access — stop and require human review.
+
+## Security notes
+- Read-only static review; never requests live org access or API credentials.
+- Sanitized inputs only; any input containing credentials or session tokens must be refused.
+- Risk register is advisory; remediation requires human-authorized change management.
+- CSP Trusted Sites wildcard entries are always at least High severity regardless of context.

package/skills/salesforce/salesforce-infrastructure-audit-skill/metadata.json

@@ -0,0 +1,19 @@
+{
+  "id": "salesforce-infrastructure-audit-skill",
+  "name": "Salesforce Infrastructure Audit Skill",
+  "type": "skill",
+  "provider": "salesforce",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Structured audit workflow for Salesforce infrastructure security posture covering network policies, IP allowlisting, session settings, CSP Trusted Sites, sandbox isolation and data masking, and Hyperforce deployment controls and data residency commitments.",
+  "source_type": "original",
+  "official_docs": [
+    "https://help.salesforce.com/s/articleView?id=sf.security_networkaccess.htm",
+    "https://help.salesforce.com/s/articleView?id=sf.security_session_settings.htm",
+    "https://help.salesforce.com/s/articleView?id=sf.hyperforce_overview.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-infrastructure-audit-skill",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}