@raishin/vanguard-frontier-agentic 2.3.0 → 2.6.0

package/skills/salesforce/salesforce-soql-generator-skill/references/common-patterns.md

@@ -0,0 +1,293 @@
+# Common SOQL Patterns
+
+Pre-built patterns for the most frequent admin and RevOps use cases. Copy,
+adapt field names to your org's schema, and verify with
+`salesforce-soql-explorer-skill` before use in automation.
+
+---
+
+## Pipeline by Stage (Sum and Count)
+
+Aggregate deal value and count grouped by stage, filtered to open opportunities.
+
+```soql
+SELECT StageName,
+       COUNT(Id) deal_count,
+       SUM(Amount) total_amount,
+       AVG(Amount) avg_deal_size
+FROM Opportunity
+WHERE IsClosed = false
+  AND ForecastCategoryName != 'Omitted'
+GROUP BY StageName
+ORDER BY MIN(Probability) ASC
+```
+
+**Variant — by owner and stage:**
+
+```soql
+SELECT Owner.Name, StageName, COUNT(Id) deal_count, SUM(Amount) total_amount
+FROM Opportunity
+WHERE IsClosed = false
+  AND CloseDate >= THIS_QUARTER
+GROUP BY Owner.Name, StageName
+ORDER BY Owner.Name ASC, MIN(Probability) ASC
+```
+
+**Governor notes:** Aggregate query returns one row per group — LIMIT rarely
+needed but add it if GROUP BY cardinality could be very high.
+
+---
+
+## Opportunities Without Next Activity
+
+Identify open deals where no future activity is scheduled (common pipeline
+hygiene signal).
+
+```soql
+SELECT Id, Name, Owner.Name, StageName, Amount, CloseDate, LastActivityDate
+FROM Opportunity
+WHERE IsClosed = false
+  AND CloseDate >= TODAY
+  AND Id NOT IN (
+    SELECT WhatId FROM Task
+    WHERE ActivityDate >= TODAY
+      AND Status != 'Completed'
+      AND WhatId != null
+  )
+ORDER BY CloseDate ASC
+LIMIT 200
+```
+
+**Notes:**
+- The anti-join pattern (`NOT IN` subquery) uses a semi-join against Task.
+- `WhatId` on Task is a polymorphic field — this query only captures Task-based
+  activities, not Events. Run a parallel query against `Event.WhatId` if Events
+  are tracked separately.
+- Index: `CloseDate` and `IsClosed` are standard indexed fields on Opportunity.
+
+---
+
+## Stale Leads (No Update in N Days)
+
+Find leads that have not been modified recently, indicating decay.
+
+```soql
+SELECT Id, FirstName, LastName, Email, Company, Status, Owner.Name,
+       LastModifiedDate, CreatedDate
+FROM Lead
+WHERE IsConverted = false
+  AND LastModifiedDate < LAST_N_DAYS:90
+  AND Status NOT IN ('Closed - Not Converted', 'Unqualified')
+ORDER BY LastModifiedDate ASC
+LIMIT 500
+```
+
+**Variant — parameterised threshold (Apex context):**
+
+```soql
+SELECT Id, FirstName, LastName, Company, Status, LastModifiedDate
+FROM Lead
+WHERE IsConverted = false
+  AND LastModifiedDate < :thresholdDate
+ORDER BY LastModifiedDate ASC
+LIMIT 1000
+```
+
+**Notes:**
+- `LastModifiedDate` is indexed on Lead.
+- Adjust the `LAST_N_DAYS:90` threshold to your org's sales cadence (30/60/90).
+- Exclude statuses that represent legitimate terminal states in your process.
+
+---
+
+## Account Ownership Audit
+
+Surface accounts assigned to inactive users or with no recent activity.
+
+```soql
+SELECT Id, Name, Owner.Name, Owner.IsActive, Owner.Profile.Name,
+       LastModifiedDate, LastActivityDate, Type, BillingCountry
+FROM Account
+WHERE Owner.IsActive = false
+   OR LastActivityDate < LAST_N_DAYS:180
+ORDER BY Owner.IsActive ASC, LastActivityDate ASC NULLS FIRST
+LIMIT 500
+```
+
+**Variant — find accounts with no owner (public queue owned):**
+
+```soql
+SELECT Id, Name, OwnerId, Owner.Type, LastModifiedDate
+FROM Account
+WHERE Owner.Type = 'Queue'
+  AND LastModifiedDate < LAST_N_DAYS:30
+ORDER BY LastModifiedDate ASC
+LIMIT 200
+```
+
+**Notes:**
+- `Owner.IsActive` traverses the User relationship — not indexed, but
+  `OwnerId` is. Performance depends on the number of inactive owners.
+- For large orgs, add a `Type` or `RecordType.Name` filter to narrow scope.
+
+---
+
+## Contacts with Bouncing Emails
+
+Find contacts flagged as email-invalid or undeliverable (uses EmailBouncedDate
+or a custom field depending on org configuration).
+
+```soql
+SELECT Id, FirstName, LastName, Email, EmailBouncedDate, EmailBouncedReason,
+       Account.Name, Owner.Name
+FROM Contact
+WHERE EmailBouncedDate != null
+  AND HasOptedOutOfEmail = false
+ORDER BY EmailBouncedDate DESC
+LIMIT 500
+```
+
+**Variant — contacts with no email at all:**
+
+```soql
+SELECT Id, FirstName, LastName, Account.Name, Owner.Name, CreatedDate
+FROM Contact
+WHERE Email = null
+  AND HasOptedOutOfEmail = false
+ORDER BY CreatedDate DESC
+LIMIT 500
+```
+
+**Notes:**
+- `EmailBouncedDate` is a standard field on Contact populated by Salesforce
+  email features (not always by third-party ESPs — check your org config).
+- If your org uses Marketing Cloud or Pardot, bounce data may live in a
+  custom field or a related object.
+
+---
+
+## Field History Tracking Queries
+
+Query the history tracking object for a standard or custom object. The history
+object is named `<SObject>History` (e.g., `OpportunityFieldHistory`,
+`AccountHistory`, `My_Object__History`).
+
+**Track when a field changed on Opportunity:**
+
+```soql
+SELECT Id, OpportunityId, Field, OldValue, NewValue, CreatedDate, CreatedBy.Name
+FROM OpportunityFieldHistory
+WHERE Field = 'StageName'
+  AND CreatedDate = LAST_N_DAYS:30
+ORDER BY CreatedDate DESC
+LIMIT 500
+```
+
+**Track all field changes on a specific record:**
+
+```soql
+SELECT Id, Field, OldValue, NewValue, CreatedDate, CreatedBy.Name
+FROM AccountHistory
+WHERE AccountId = '001Xx000001PLACEHOLDER'
+ORDER BY CreatedDate DESC
+LIMIT 200
+```
+
+**Notes:**
+- Field history tracking must be enabled for each field in Setup. Not all
+  fields support history tracking.
+- History objects retain data for 18 months in most orgs (configurable with
+  add-ons).
+- Replace `'001Xx000001PLACEHOLDER'` with the actual record Id or a bind
+  variable.
+
+---
+
+## Junction Object Queries
+
+Query a many-to-many relationship via its junction object. Example: Campaign
+Member (junction between Campaign and Lead/Contact).
+
+```soql
+SELECT Id, CampaignId, Campaign.Name, LeadId, Lead.FirstName, Lead.LastName,
+       Lead.Email, Status, HasResponded, FirstRespondedDate
+FROM CampaignMember
+WHERE CampaignId = '701Xx000001PLACEHOLDER'
+  AND Status = 'Responded'
+ORDER BY FirstRespondedDate DESC
+LIMIT 500
+```
+
+**Custom junction object pattern (e.g., Account_Product__c linking Account
+and Product2):**
+
+```soql
+SELECT Id, Account__c, Account__r.Name, Product__c, Product__r.Name,
+       Quantity__c, Start_Date__c
+FROM Account_Product__c
+WHERE Account__r.Type = 'Customer'
+  AND Start_Date__c >= THIS_YEAR
+ORDER BY Account__r.Name ASC
+LIMIT 500
+```
+
+**Notes:**
+- Use `__r` suffix to traverse a custom lookup relationship by API name.
+- For standard relationships use the relationship name (e.g., `Campaign`,
+  `Lead`), not a `__r` suffix.
+
+---
+
+## Polymorphic Owner Queries (User vs Queue)
+
+The `OwnerId` field on most sObjects can reference either a User or a Queue.
+Use `TYPEOF` (or a Type filter on a subquery) to distinguish.
+
+```soql
+SELECT Id, Name,
+  TYPEOF Owner
+    WHEN User THEN FirstName, LastName, Email, IsActive
+    WHEN Group THEN Name, Type
+  END
+FROM Case
+WHERE IsClosed = false
+  AND CreatedDate >= THIS_MONTH
+ORDER BY CreatedDate DESC
+LIMIT 500
+```
+
+**Simpler pattern — split into two queries:**
+
+```soql
+-- User-owned open cases
+SELECT Id, Subject, OwnerId, Owner.Name, Owner.IsActive, Priority
+FROM Case
+WHERE IsClosed = false
+  AND Owner.Type = 'User'
+LIMIT 500
+
+-- Queue-owned open cases
+SELECT Id, Subject, OwnerId, Owner.Name, Priority
+FROM Case
+WHERE IsClosed = false
+  AND Owner.Type = 'Queue'
+LIMIT 500
+```
+
+**Notes:**
+- `TYPEOF` is supported in API version 26.0+ but has limited support in some
+  Apex SOQL contexts. Test before embedding in Apex.
+- The `Group` type in `TYPEOF` represents a Queue (Salesforce's internal type
+  name for queues is `Group`).
+
+---
+
+## Usage Notes
+
+- All record IDs in these patterns are placeholders (`001Xx000001PLACEHOLDER`,
+  `701Xx000001PLACEHOLDER`, etc.). Replace before executing.
+- Field API names may differ in your org (custom fields, custom objects, or
+  managed package prefixes). Verify with `sf sobject describe` or the Object
+  Manager before use.
+- LIMIT values are conservative defaults. Adjust to your org's data volume.
+- For live execution of any pattern, use `salesforce-soql-explorer-skill`.

package/skills/salesforce/salesforce-soql-generator-skill/references/governor-limits.md

@@ -0,0 +1,171 @@
+# SOQL Governor Limits and Performance Guidance
+
+Reference for generating governor-limit-safe SOQL. Every generated query must
+be assessed against these limits before emission.
+
+---
+
+## Core Query Limits
+
+| Limit | Value | Notes |
+|---|---|---|
+| Total SOQL queries per synchronous Apex transaction | 100 | Shared across all triggers, classes, and flows in the transaction |
+| Total SOQL queries per asynchronous Apex (batch, future, queueable) | 200 | Higher ceiling for async contexts |
+| Total rows returned across all queries in a synchronous transaction | 50,000 | Hard ceiling — query that would return > 50k rows fails |
+| Total rows returned in an asynchronous Apex transaction | 50,000,000 | Batch Apex contexts only |
+| Maximum rows returned by a single synchronous query | 50,000 | Applies per query; aggregate queries not affected |
+| Maximum LIMIT value (synchronous API query) | 2,000 | Interactive/SOQL via API |
+| Maximum LIMIT value (Apex query) | 50,000 | Apex can hold more; still constrained by 50k total |
+| Maximum OFFSET value | 2,000 | Use keyset pagination beyond 2k rows |
+| Maximum fields per SELECT | 200 | API-enforced |
+| Maximum relationship traversal depth (parent) | 5 levels | e.g., `Contact.Account.Owner.Profile.Name` |
+| Maximum subquery nesting (child) | 1 level | One child subquery per parent query |
+| Query timeout | ~120 seconds | Varies; complex scans on large objects time out earlier |
+
+---
+
+## 50,000-Row Ceiling: Critical Guidance
+
+The 50,000-row limit is the most commonly hit governor in SOQL-heavy
+automation. Every generated query must account for this.
+
+**Rules for generated queries:**
+
+1. If the object could realistically hold > 50k records (Account, Contact,
+   Opportunity, Lead, Task, Event, Case in large orgs), always include LIMIT.
+2. If the user's stated purpose is "export all", warn about the ceiling and
+   recommend `salesforce-bulk-data-ops-skill` for volumes > 2,000 records.
+3. If the query is embedded in an Apex transaction (trigger, controller,
+   flow-called Apex), assume the 50k total is shared — a conservative LIMIT
+   of 200–1,000 per query is safer.
+4. Use `COUNT` queries to estimate volume before recommending a non-LIMIT
+   query:
+
+```soql
+SELECT COUNT FROM Account WHERE Type = 'Customer'
+```
+
+---
+
+## 100-SOQL-per-Transaction Ceiling
+
+In Apex (triggers, controllers, batch execute, queueable), every `[SOQL]`
+call or `Database.query` counts against the 100-query limit for synchronous
+contexts.
+
+**Implications for generation:**
+
+- Do not generate patterns that imply a query per record (query-in-loop
+  anti-pattern). Always note if the pattern must be bulkified.
+- If the user describes a loop-based need, suggest a single query with an
+  `IN` clause or a subquery instead:
+
+```soql
+-- WRONG (query-in-loop implication): one query per account
+-- CORRECT: single query covering all accounts
+SELECT Id, Name, AccountId
+FROM Contact
+WHERE AccountId IN :accountIds
+```
+
+---
+
+## Large Data Volume (LDV) Considerations
+
+For orgs with millions of records on a single object:
+
+| Consideration | Guidance |
+|---|---|
+| Filter on indexed fields | Always use Id, Name, ExternalId, standard indexed lookups in WHERE first |
+| Avoid leading wildcard LIKE | `WHERE Name LIKE '%Corp'` defeats the text index — use `LIKE 'Corp%'` or SOSL |
+| Custom indexes | Request custom indexes from Salesforce Support for frequently-filtered non-standard fields |
+| Skinny tables | Org admins can enable skinny tables for specific objects and field sets — reduces I/O for wide-table queries |
+| Selective query threshold | Salesforce requires a WHERE filter to be selective (< 10% of rows) on objects with > 100k records; non-selective queries are throttled or rejected |
+
+**Selectivity threshold rule of thumb:**
+
+- Object has < 100k records: most queries are acceptable
+- Object has 100k–1M records: WHERE must include at least one indexed field
+- Object has > 1M records: WHERE must be highly selective (prefer Id or ExternalId filters, date range with indexed fields)
+
+---
+
+## Indexed Fields
+
+Standard indexed fields (available by default, no admin action needed):
+
+| Object | Indexed Fields |
+|---|---|
+| All objects | `Id`, `Name`, `OwnerId`, `CreatedDate`, `LastModifiedDate`, `SystemModstamp` |
+| All objects with ExternalId | Custom fields marked as External ID |
+| Account | `BillingCountry`, `ParentId`, `RecordTypeId` |
+| Contact | `AccountId`, `Email`, `RecordTypeId` |
+| Opportunity | `AccountId`, `CloseDate`, `IsClosed`, `StageName`, `RecordTypeId` |
+| Lead | `Email`, `IsConverted`, `Status`, `OwnerId` |
+| Case | `AccountId`, `ContactId`, `IsClosed`, `Status`, `RecordTypeId` |
+| Task / Event | `WhatId`, `WhoId`, `OwnerId`, `ActivityDate` |
+
+**Custom indexes** can be requested for non-standard fields via Salesforce
+Support (for non-formula, non-encrypted, non-text-area fields). Use the
+`suggested_index` field in the skill output to flag candidates.
+
+**Formula field rule:** Formula fields are **never indexed**. Never place a
+formula field as the sole filter in a WHERE clause on a high-volume object.
+Instead, filter on the underlying source fields or use a custom index on a
+stored (non-formula) equivalent field.
+
+---
+
+## Aggregate Queries and Limits
+
+Aggregate queries (`GROUP BY`, `COUNT`, `SUM`, etc.) are **not subject to the
+50,000-row-returned limit** in the same way as record queries — they return
+aggregated results, not raw rows. However:
+
+- The rows *scanned* during aggregation still count toward internal processing
+  limits and can time out on very large objects without a selective WHERE.
+- The result set of an aggregate query (number of groups) can still be large
+  — apply a LIMIT or HAVING clause if the GROUP BY field has high cardinality.
+
+---
+
+## Query Timeout Signals
+
+A query is at risk of timeout when:
+
+- No indexed filter is present and the object has > 100k records
+- A `LIKE '%pattern'` leading wildcard is used on a large text field
+- A formula field appears in WHERE without a companion indexed filter
+- A subquery result set is large (> 10k rows in the IN clause)
+- Relationships are traversed more than 2 levels deep on a large object
+
+Always flag these risks in `governor_limit_notes` in the skill output.
+
+---
+
+## Bulk Data Operations — When to Escalate
+
+Generated SOQL is for synchronous interactive or Apex-transaction use. When
+the user's need implies:
+
+- Exporting > 2,000 records interactively
+- Processing > 50,000 records in a single operation
+- Scheduled batch extraction or load
+
+Escalate to `salesforce-bulk-data-ops-skill`. The Bulk API 2.0 bypasses the
+50,000-row governor for export and is the correct tool for large-volume work.
+
+---
+
+## Recommended Query Size Budget
+
+Use this as a default budget when the user does not specify volume:
+
+| Use case | Recommended LIMIT |
+|---|---|
+| UI display / developer inspection | 5–50 |
+| Admin review / hygiene report | 200–500 |
+| Export to CSV (small set) | 500–2,000 |
+| Apex selector (per-transaction) | 200 |
+| Aggregate (few groups) | Omit LIMIT or use 50–200 |
+| Count only | No LIMIT needed (COUNT aggregate) |

package/skills/salesforce/salesforce-soql-generator-skill/references/soql-syntax-quickref.md

@@ -0,0 +1,255 @@
+# SOQL Syntax Quick Reference
+
+Quick-reference for generating correct SOQL. For full governor-limit context
+see `governor-limits.md`. For pre-built patterns see `common-patterns.md`.
+
+---
+
+## Basic Query Shape
+
+```soql
+SELECT field1, field2, field3
+FROM SObjectApiName
+WHERE condition
+ORDER BY field1 ASC NULLS LAST
+LIMIT 200
+OFFSET 0
+```
+
+All clauses except `SELECT` and `FROM` are optional. Order is fixed:
+`SELECT … FROM … WHERE … WITH … GROUP BY … HAVING … ORDER BY … LIMIT … OFFSET … FOR …`
+
+---
+
+## SELECT
+
+- Enumerate fields explicitly — `SELECT *` is not valid SOQL.
+- Field API names are case-insensitive but use the documented casing for
+  readability (`AccountId`, not `accountid`).
+- Maximum 200 fields per query (API limit).
+- Aggregate functions: `COUNT`, `COUNT(field)`, `COUNT_DISTINCT(field)`,
+  `SUM(field)`, `AVG(field)`, `MIN(field)`, `MAX(field)`.
+
+### Parent field traversal (child-to-parent)
+
+Access parent fields via dot notation. Up to 5 levels deep.
+
+```soql
+SELECT Id, Name, Account.Name, Account.Owner.Name
+FROM Contact
+WHERE Account.BillingCountry = 'US'
+```
+
+### Child subquery (parent-to-child)
+
+One level of child subquery nesting. Use the child relationship name
+(not the sObject API name).
+
+```soql
+SELECT Id, Name,
+  (SELECT Id, StageName, Amount FROM Opportunities WHERE IsClosed = false)
+FROM Account
+WHERE Type = 'Customer'
+LIMIT 100
+```
+
+### Polymorphic fields (TYPEOF)
+
+Use `TYPEOF` for fields that can reference multiple sObject types.
+
+```soql
+SELECT Id, Subject,
+  TYPEOF Who
+    WHEN Contact THEN FirstName, LastName, Email
+    WHEN Lead THEN FirstName, LastName, Company
+  END
+FROM Task
+WHERE ActivityDate = TODAY
+```
+
+---
+
+## FROM
+
+Single sObject name. SOQL does not support multi-object joins — use a
+subquery or two separate queries.
+
+---
+
+## WHERE
+
+### Comparison operators
+
+| Operator | Meaning |
+|---|---|
+| `=` | Equals |
+| `!=` | Not equals |
+| `<` `>` `<=` `>=` | Numeric / date comparison |
+| `LIKE` | String pattern; `%` is wildcard, `_` is single char |
+| `IN` | Value in list: `Status IN ('Open', 'Working')` |
+| `NOT IN` | Value not in list |
+| `INCLUDES` | Multi-select picklist includes value |
+| `EXCLUDES` | Multi-select picklist excludes value |
+
+### Logical operators
+
+`AND`, `OR`, `NOT`. Use parentheses to control precedence.
+
+### Date literals
+
+Use these instead of hardcoded dates to respect user timezone.
+
+| Literal | Meaning |
+|---|---|
+| `TODAY` | Current day |
+| `YESTERDAY` | Previous day |
+| `TOMORROW` | Next day |
+| `THIS_WEEK` | Sun–Sat week containing today |
+| `LAST_WEEK` | Previous Sun–Sat week |
+| `NEXT_WEEK` | Next Sun–Sat week |
+| `THIS_MONTH` | Calendar month of today |
+| `LAST_MONTH` | Previous calendar month |
+| `NEXT_MONTH` | Next calendar month |
+| `THIS_QUARTER` | Current fiscal/calendar quarter |
+| `LAST_QUARTER` | Previous quarter |
+| `NEXT_QUARTER` | Next quarter |
+| `THIS_YEAR` | Current year |
+| `LAST_YEAR` | Previous year |
+| `NEXT_YEAR` | Next year |
+| `LAST_N_DAYS:n` | Last n days (0 = today) |
+| `NEXT_N_DAYS:n` | Next n days |
+| `LAST_N_WEEKS:n` | Last n weeks |
+| `NEXT_N_WEEKS:n` | Next n weeks |
+| `LAST_N_MONTHS:n` | Last n months |
+| `NEXT_N_MONTHS:n` | Next n months |
+| `LAST_N_QUARTERS:n` | Last n quarters |
+| `NEXT_N_QUARTERS:n` | Next n quarters |
+| `LAST_N_YEARS:n` | Last n years |
+| `NEXT_N_YEARS:n` | Next n years |
+
+Date literals evaluate at query execution time in the running user's timezone.
+Do not mix date literals with hardcoded ISO datetime strings.
+
+### NULL handling
+
+```soql
+WHERE Email = null        -- no email
+WHERE Email != null       -- has email
+WHERE LastActivityDate = null  -- never had activity
+```
+
+---
+
+## WITH
+
+Optional security and data-category clauses. Most commonly:
+
+```soql
+WITH SECURITY_ENFORCED  -- respects FLS and object permissions at query time
+```
+
+Use `WITH SECURITY_ENFORCED` in Apex contexts where FLS must be explicitly
+enforced server-side. Not required for API queries (FLS is enforced by default).
+
+---
+
+## GROUP BY and HAVING
+
+Use with aggregate functions. All non-aggregate SELECT fields must appear
+in GROUP BY.
+
+```soql
+SELECT StageName, COUNT(Id) deal_count, SUM(Amount) total_amount
+FROM Opportunity
+WHERE IsClosed = false
+GROUP BY StageName
+HAVING COUNT(Id) > 5
+ORDER BY SUM(Amount) DESC
+```
+
+`ROLLUP` and `CUBE` extensions are available for subtotal aggregation:
+
+```soql
+SELECT Type, BillingCountry, COUNT(Id)
+FROM Account
+GROUP BY ROLLUP(Type, BillingCountry)
+```
+
+---
+
+## ORDER BY
+
+```soql
+ORDER BY FieldName ASC NULLS FIRST   -- nulls sort first
+ORDER BY FieldName DESC NULLS LAST   -- nulls sort last (default)
+```
+
+Multiple fields: `ORDER BY LastModifiedDate DESC, Name ASC`
+
+---
+
+## LIMIT and OFFSET
+
+```soql
+LIMIT 200          -- max rows returned
+OFFSET 0           -- skip first n rows (zero-indexed)
+```
+
+Ceiling: LIMIT max is 2,000 for synchronous queries (API). Governor limit:
+50,000 rows total per transaction. OFFSET max is 2,000.
+
+Prefer keyset pagination (WHERE Id > :lastId ORDER BY Id ASC LIMIT 200)
+over OFFSET for large datasets to avoid the 2,000 OFFSET ceiling.
+
+---
+
+## FOR Clauses
+
+```soql
+FOR REFERENCE   -- updates LastReferencedDate on records
+FOR VIEW        -- updates LastViewedDate on records
+FOR UPDATE      -- locks records for DML (Apex only, not usable in read contexts)
+```
+
+Use `FOR REFERENCE` when the query is part of a "recently viewed" tracking
+workflow. Avoid `FOR UPDATE` in generation contexts — that is a T3 concern.
+
+---
+
+## USING SCOPE
+
+Filter by scope without additional WHERE conditions:
+
+```soql
+SELECT Id, Name FROM Account USING SCOPE mine       -- only records owned by running user
+SELECT Id, Name FROM Account USING SCOPE team       -- team-owned records
+SELECT Id, Name FROM Account USING SCOPE allRecords -- include archived/deleted (Recycle Bin)
+```
+
+---
+
+## SOSL (Salesforce Object Search Language)
+
+Use SOSL when searching text across multiple objects or when LIKE-based
+full-text search would be too broad.
+
+```sosl
+FIND {Acme Corp} IN ALL FIELDS
+RETURNING Account(Id, Name), Contact(Id, FirstName, LastName, Email)
+LIMIT 50
+```
+
+SOSL uses the search index. It is faster than SOQL LIKE for full-text search
+but cannot be used for structured field comparisons or aggregates.
+
+---
+
+## Anti-Patterns to Avoid
+
+- `SELECT *` — not valid; enumerate fields
+- No WHERE on a high-volume object — risks 50k row governor hit
+- Formula field in WHERE — not indexed; causes full table scan
+- Leading wildcard in LIKE: `WHERE Name LIKE '%Corp'` — defeats the text index
+- Querying inside a loop in Apex context — SOQL-in-loop governor trap
+- Hardcoded record IDs in WHERE — use a bind variable or dynamic query instead
+- Mixing date literals with hardcoded ISO strings — timezone ambiguity