sf-intelligence 0.2.1 → 0.2.2

package/dist/index.js

@@ -55506,6 +55506,444 @@ var init_concept_model = __esm({
           { label: "Apex Developer Guide \u2014 Triggers and Bulk Request Triggers", url: "https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_bulk_requests.htm" },
           { label: "Apex Developer Guide \u2014 Running Apex within Governor Execution Limits", url: "https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm" }
         ]
+      },
+      "concept:validation-rule-inactive": {
+        id: "concept:validation-rule-inactive",
+        kind: "firing-condition",
+        label: "An inactive validation rule never enforces its constraint and must be excluded from save-failure analysis",
+        summary: 'A VALIDATION RULE whose `active` flag is FALSE is DEAD enforcement: Salesforce never evaluates its error-condition formula on insert or update, so it can neither block a save nor surface its error message until an admin re-activates it. It must be EXCLUDED from save-order-of-execution analysis (validation runs in the system-validation phase), from "what could reject this write" reasoning, and from required-field / collision gate counts \u2014 treating a deactivated rule as a live guard would cry wolf about a constraint that cannot fire, while treating it as protection would falsely assure that bad data is blocked. This is grounded from the rule\'s own always-present `active` boolean; it names the non-enforcing STRUCTURAL fact, NOT whether the rule WOULD reject a specific record if activated (the error-condition formula is not evaluated offline) and NOT why it was deactivated. Only active validation rules belong in save-failure and enforcement surfaces.',
+        docs: [
+          { label: "Salesforce Help \u2014 Define Validation Rules", url: "https://help.salesforce.com/s/articleView?id=sf.fields_defining_field_validation_rules.htm" }
+        ]
+      },
+      "concept:workflow-rule-inactive-dead": {
+        id: "concept:workflow-rule-inactive-dead",
+        kind: "firing-condition",
+        label: "An inactive workflow rule never runs its actions and is dead legacy automation",
+        summary: 'A WORKFLOW RULE whose `active` flag is FALSE is DEAD legacy automation: Salesforce never evaluates its criteria and never runs its associated actions \u2014 field updates, email alerts, outbound messages, or time-dependent actions \u2014 until it is re-activated. It must be EXCLUDED from save-order-of-execution analysis (an active workflow field update runs in its own save-order phase and can re-trigger automation), from field-writer-collision reasoning, and from "what fires on save" impact counts; counting a deactivated rule would overstate the automation load, while assuming its field updates still run would misattribute a value change. This is grounded from the rule\'s own always-present `active` boolean; it names the non-running STRUCTURAL fact, NOT whether an equivalent Flow has replaced it (migration lineage is org-specific) and NOT whether the rule WOULD match a given record if activated (criteria remain unevaluated offline). Only active workflow rules belong in save-order and automation-impact surfaces.',
+        docs: [
+          { label: "Salesforce Help \u2014 Activate Workflow Rules", url: "https://help.salesforce.com/s/articleView?id=sf.workflow_rules_activating.htm" }
+        ]
+      },
+      "concept:field-longtext-richtext-not-filterable": {
+        id: "concept:field-longtext-richtext-not-filterable",
+        kind: "field-provenance",
+        label: "Long Text Area and Rich Text (Html) fields cannot be filtered, sorted, grouped, or indexed",
+        summary: "A LONG TEXT AREA or RICH TEXT (Html) field belongs to a data-type class that Salesforce does NOT index \u2014 such a field is not filterable, not sortable, and not groupable, so it cannot appear in a SOQL WHERE / ORDER BY / GROUP BY clause, a list-view filter, or a report filter, and it cannot be marked as an external id or as unique. It can be referenced in a SELECT clause and rendered as body content, but any attempt to filter, sort, group, or index on it is rejected by the platform. This is grounded from the field's own always-present `dataType` (LongTextArea or Html); it names the STRUCTURAL platform restriction that follows from the field's type class, NOT whether any specific SOQL query, list view, or report currently references the field (that is a usage question the offline snapshot does not answer here) and NOT the field's length or stored content. Only the queryability class is asserted, never a proven failure of a particular query.",
+        docs: [
+          { label: "Salesforce Help \u2014 Custom Field Types", url: "https://help.salesforce.com/s/articleView?id=sf.custom_field_types.htm" }
+        ]
+      },
+      "concept:duplicate-rule-bypass-sharing-match": {
+        id: "concept:duplicate-rule-bypass-sharing-match",
+        kind: "access-mechanism",
+        label: "A duplicate rule set to bypass sharing matches against records the running user cannot see",
+        summary: "A DUPLICATE RULE whose `securityOption` is BYPASS SHARING RULES runs its duplicate-matching query in SYSTEM CONTEXT: it compares an incoming record against records the RUNNING USER cannot see under the org's sharing model, so a save can be blocked or alerted by a duplicate the user has no visibility into and cannot open to resolve. The alternative, ENFORCE SHARING RULES, restricts matching to records the running user can already access. This is grounded from the rule's own declared `securityOption` scalar; it names the DECLARED sharing-context posture only. It does NOT assert the rule is active (`isActive`), that any matching records exist, that a particular save would actually surface a hidden duplicate, or which specific records lie outside the user's visibility \u2014 those depend on runtime record data and per-user sharing the offline vault cannot evaluate.",
+        docs: [
+          { label: "Metadata API Developer Guide \u2014 DuplicateRule", url: "https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_duplicaterule.htm" }
+        ]
+      },
+      "concept:duplicate-rule-references-inactive-matching-rule": {
+        id: "concept:duplicate-rule-references-inactive-matching-rule",
+        kind: "automation-collision",
+        label: "An active duplicate rule that points at an inactive matching rule does no duplicate detection",
+        summary: "A DUPLICATE RULE reuses a MATCHING RULE to decide which records count as duplicates. When an ACTIVE duplicate rule references a matching rule whose ruleStatus is NOT Active (Inactive, Draft, Deactivating, ActivationFailed, and the like), that matcher runs NO comparison \u2014 so on that path the duplicate rule detects nothing and duplicate records save SILENTLY, with no alert and no block, even though the duplicate rule itself looks enabled. The honest signal conjoins the duplicate rule's own `isActive` flag with the `ruleStatus` of each matching rule it references. HONEST BOUNDARIES: this is grounded from declared metadata flags only \u2014 it does NOT prove any duplicate records currently exist in the org, does NOT prove a specific save would have been caught had the matcher been active, and does NOT check whether another ACTIVE matching rule on the same duplicate rule still covers the object. It names a silently-disabled detection SHAPE, not a proven missed duplicate.",
+        docs: [
+          { label: "Salesforce Help \u2014 Duplicate Management", url: "https://help.salesforce.com/s/articleView?id=sf.duplicate_management.htm" }
+        ]
+      },
+      "concept:approval-process-final-lock-record-readonly": {
+        id: "concept:approval-process-final-lock-record-readonly",
+        kind: "access-mechanism",
+        label: "An approval process that locks the record on final approval or rejection leaves it read-only until unlocked",
+        summary: 'An APPROVAL PROCESS that declares `finalApprovalRecordLock` (or `finalRejectionRecordLock`) as true LOCKS the record when the process reaches final approval (or final rejection): a locked record becomes READ-ONLY to everyone except administrators and users with the "Modify All Data" / "Modify All" permission (plus the approval process\'s own unlock step), so once the process completes, later user edits AND automation updates \u2014 field writes from a flow, workflow, trigger, or the API \u2014 FAIL with an entity-is-locked error unless the record is unlocked first. This matters for save-order and automation reasoning: a downstream flow or trigger that tries to update a just-approved (or just-rejected) record can silently fail on the lock. This is grounded from the approval process\'s own always-present `finalApprovalRecordLock` / `finalRejectionRecordLock` booleans; it names the DECLARED lock behavior, NOT whether any specific record is currently locked (which records have entered or completed the process is record-level runtime state the offline vault does not hold), NOT which specific users can still edit it (permission-holder membership is not evaluated here), and NOT whether any automation actually attempts a post-lock update. Only an approval process whose final-approval or final-rejection step locks the record contributes this freeze.',
+        docs: [
+          { label: "Salesforce Help \u2014 Considerations for Approvals (record locking)", url: "https://help.salesforce.com/s/articleView?id=sf.approvals_considerations.htm" }
+        ]
+      },
+      "concept:record-type-inactive": {
+        id: "concept:record-type-inactive",
+        kind: "access-mechanism",
+        label: "An inactive record type cannot be assigned to new records and is hidden from record-type selection",
+        summary: "A RECORD TYPE whose `active` flag is FALSE is a DEAD routing mechanism: it cannot be assigned to new records and is hidden from users' record-type selection, so it routes NONE of its page layout, picklist value set, or business process to new work until an admin re-activates it. Only pre-existing records keep it. It must be EXCLUDED from \"which record type will new records get\", default-routing, and layout / picklist-scope reasoning about new work \u2014 treating a deactivated record type as a live routing option would misattribute a layout, restricted picklist, or business process that new records can never receive, while assuming it still governs selection would overstate the choices a user is offered. This is grounded from the record type's own always-present `active` boolean; it names the non-assignable STRUCTURAL fact, NOT whether any existing records still carry this record type (that is record-level data, not modeled offline), NOT which profiles or permission sets once defaulted to or were granted it (assignment is separate metadata), and NOT why it was deactivated. Only active record types belong in new-record routing surfaces.",
+        docs: [
+          { label: "Salesforce Help \u2014 Create Record Types", url: "https://help.salesforce.com/s/articleView?id=sf.customize_recordtype.htm" }
+        ]
+      },
+      "concept:remote-site-setting-protocol-security-disabled": {
+        id: "concept:remote-site-setting-protocol-security-disabled",
+        kind: "external-api-surface",
+        label: "A remote site setting that disables protocol security allows cleartext HTTP callouts to its allowlisted host",
+        summary: "An ACTIVE remote site setting whose disableProtocolSecurity flag is TRUE drops the platform's HTTPS-only guard on outbound callouts to its allowlisted host: it permits cleartext HTTP requests to that endpoint, so request URLs, headers, and bodies \u2014 potentially including session ids, tokens, or credentials carried in the request \u2014 travel unencrypted and are exposed to network interception and tampering. This is grounded from the setting's own always-present disableProtocolSecurity and isActive booleans; it names the declared configuration POSTURE, NOT whether any Apex, Flow, or LWC actually issues an insecure callout to this host at runtime (the offline vault does not correlate outbound-callout code to allowlist entries), NOT a confirmed interception or breach, and NOT whether a plaintext endpoint is a deliberate, accepted design choice. The modern replacement is a Named Credential over HTTPS; re-enabling protocol security restores the encrypted-only guard unless a cleartext endpoint is genuinely required.",
+        severity: "high",
+        docs: [
+          { label: "Salesforce Help \u2014 Configure Remote Site Settings", url: "https://help.salesforce.com/s/articleView?id=sf.configuring_remoteproxy.htm" },
+          { label: "Apex Developer Guide \u2014 Invoking Callouts Using Apex", url: "https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_callouts.htm" }
+        ]
+      },
+      "concept:apex-intentional-system-mode-dml": {
+        id: "concept:apex-intentional-system-mode-dml",
+        kind: "access-mechanism",
+        label: "An Apex class runs DML with an explicit AccessLevel.SYSTEM_MODE argument \u2014 a deliberate object-CRUD / field-level-security bypass for that write",
+        summary: "An Apex class runs a DML operation (a Database.insert / update / upsert / delete and its siblings) with an EXPLICIT AccessLevel.SYSTEM_MODE argument. Apex runs in system context and does NOT automatically enforce the running user's object CRUD or field-level security on its DML; passing AccessLevel.SYSTEM_MODE makes that non-enforcement DELIBERATE and explicit for this write \u2014 the developer consciously chose to run the write in system context, so object- and field-level security are intentionally NOT applied and the write can create or change objects and fields regardless of whether the running user is permitted to. This is the CONSCIOUS counterpart to an accidental missing CRUD/FLS check: the recognizer surfaces it as a REVIEW finding rather than a defect, because a deliberate SYSTEM_MODE bypass is often exactly correct (a trusted service that must write fields the running user cannot edit), and adding an isUpdateable()-style guard the write deliberately bypasses would be the wrong fix. The remediation, IF the running user's permissions SHOULD apply to this write, is to switch the argument to AccessLevel.USER_MODE. HONEST BOUNDARIES: this is a HEURISTIC recognition from TOKENIZED Apex source \u2014 NOT a compiler AST \u2014 bound to the DML call site where the SYSTEM_MODE token appears; it names the DECLARED system-context bypass, NOT a proof that the bypass is unsafe or unintended (a deliberate SYSTEM_MODE write may be entirely right), and record-level SHARING is a SEPARATE access plane this does not read. It marks a write to REVIEW, not a proven authorization defect.",
+        docs: [
+          { label: "Apex Developer Guide \u2014 Enforce User-Mode Database Operations (AccessLevel)", url: "https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_perms_enforcing.htm" }
+        ]
+      },
+      "concept:dataraptor-field-security-unenforced": {
+        id: "concept:dataraptor-field-security-unenforced",
+        kind: "access-mechanism",
+        label: "A DataRaptor with Check Field Level Security off reads or writes SObject fields without enforcing the running user's FLS",
+        summary: "A DataRaptor (an OmniStudio OmniDataTransform) whose 'Check Field Level Security' toggle is OFF reads and writes SObject fields WITHOUT enforcing the running user's field-level security: the transform can load a field the user has no Read access to into an output payload, or overwrite a field the user has no Edit access to, because FLS is not consulted on the fields it touches. This is an OVER-PERMISSIVE data-access surface \u2014 an FLS-bypass shape that widens what data can flow through the transform beyond what the invoking user could reach through a normal UI or FLS-respecting API. HONEST BOUNDARY \u2014 this is a DECLARED configuration shape read from the transform's own toggle, NOT a proven exploit: it does NOT establish that any specific field is actually over-exposed (that depends on which fields the transform maps and each running user's actual FLS), NOT who invokes the transform or in what user context, and NOT whether a compensating guard (a wrapping Apex class enforcing security, a restricted entry point, or a guest-user profile with no access) neutralizes the gap at runtime. It names the field-security-unenforced structural signal, not a confirmed data leak.",
+        severity: "high",
+        docs: [
+          { label: "Salesforce Help \u2014 DataRaptor Loads and Field-Level Security", url: "https://help.salesforce.com/s/articleView?id=sf.os_dataraptor_loads.htm" },
+          { label: "Salesforce Help \u2014 Enforce Field-Level Security in DataRaptors", url: "https://help.salesforce.com/s/articleView?id=sf.os_secure_dataraptors.htm" }
+        ]
+      },
+      "concept:field-classic-encrypted-text": {
+        id: "concept:field-classic-encrypted-text",
+        kind: "field-provenance",
+        label: "A classic Encrypted Text field is masked and cannot be filtered, sorted, or used as an external id",
+        summary: `A CLASSIC ENCRYPTED TEXT field stores its value encrypted at rest and MASKS it in the UI, API, and reports for any user who lacks the "View Encrypted Data" permission \u2014 most users see only asterisks. Its type class is NOT filterable, sortable, or groupable: it cannot appear in a SOQL WHERE / ORDER BY / GROUP BY, a list-view or report filter, and it cannot be an external id, a unique field, a default-value source, or a formula input. This is the DISTINCT LEGACY protection (a per-field type), NOT Shield Platform Encryption (a separate field-level encryption strategy not observable from offline metadata). Grounded from the field's own declared data type; it names the masking and restriction POSTURE that follow from the type, NOT which specific users can currently view the value (a permission-assignment question) and NOT whether the field actually holds sensitive data.`,
+        docs: [
+          { label: "Salesforce Help \u2014 Encrypted Custom Fields (Classic Encryption)", url: "https://help.salesforce.com/s/articleView?id=sf.fields_about_encrypted_fields.htm" }
+        ]
+      },
+      "concept:field-autonumber-system-assigned-readonly": {
+        id: "concept:field-autonumber-system-assigned-readonly",
+        kind: "field-provenance",
+        label: "An Auto Number field is system-assigned and read-only on every write path",
+        summary: "An AUTO NUMBER field is SYSTEM-ASSIGNED: Salesforce generates its value from a display format and a sequence when the record is inserted, so it is READ-ONLY on every write path \u2014 the UI, API, Apex, Flow, and data imports cannot set or change it (attempts are ignored). Because it is assigned DURING insert, it is null / unavailable in a before-save context (a before-insert trigger or before-save flow cannot read the final value). It is stored and displayed as a formatted STRING, not a number, so it cannot be used in arithmetic; and changing the display format renumbers only NEW records \u2014 existing values are not rewritten, so sequence gaps from failed inserts or rollbacks persist. Grounded from the field's own declared data type; it names the system-assigned, read-only provenance, NOT the current sequence value or next number (record data) and NOT whether any specific integration attempts to write it.",
+        docs: [
+          { label: "Salesforce Help \u2014 Auto-Number Fields", url: "https://help.salesforce.com/s/articleView?id=sf.custom_field_types.htm" }
+        ]
+      },
+      "concept:field-multiselect-picklist-storage-semantics": {
+        id: "concept:field-multiselect-picklist-storage-semantics",
+        kind: "field-provenance",
+        label: "A multi-select picklist stores selections as one delimited string with special query semantics",
+        summary: "A MULTI-SELECT PICKLIST stores every selected value in a SINGLE semicolon-delimited string, not as separate rows \u2014 so it behaves unlike a normal picklist. In SOQL and reports it must be filtered with INCLUDES / EXCLUDES rather than = / != / IN (an equality filter matches only the exact full delimited combination), and formulas must test membership with INCLUDES(); sorting or grouping orders by the raw delimited string, not by individual values. It CANNOT serve as the controlling field of a dependent picklist, and it cannot be an external id or unique field. Grounded from the field's own declared data type; it names the storage and query SEMANTICS that follow from the type, NOT which values a given record holds and NOT whether any specific query currently filters it incorrectly.",
+        docs: [
+          { label: "Salesforce Help \u2014 Multi-Select Picklists", url: "https://help.salesforce.com/s/articleView?id=sf.fields_about_multiselect_picklists.htm" }
+        ]
+      },
+      "concept:permission-set-license-scoped": {
+        id: "concept:permission-set-license-scoped",
+        kind: "access-mechanism",
+        label: "A license-scoped permission set can only be assigned to users who hold that user license",
+        summary: "A PERMISSION SET whose `license` element is SET is bound to a specific USER LICENSE, and Salesforce only lets it be assigned to users who ALREADY HOLD that license \u2014 so every grant it carries (object CRUD, field-level security, Apex class access, system permissions) is UNREACHABLE by any user lacking the license, narrowing the ELIGIBLE POPULATION before any individual grant even applies. A license-scoped permission set therefore cannot widen access for a user on the wrong license no matter how strong its grants look, whereas an UNSCOPED permission set (no `license` element) carries no such assignability constraint and can be assigned to any user. This is grounded from the permission set's own declared `license` binding; it names the ASSIGNABILITY CONSTRAINT of the container, NOT whether any specific user holds that license or is actually assigned this permission set (an assignment question the offline vault cannot answer \u2014 the live plane resolves who holds a license or a permission set), and NOT the strength or correctness of the grants inside it. Only users on the bound license can ever receive its grants.",
+        docs: [
+          { label: "Salesforce Help \u2014 Permission Set Licenses", url: "https://help.salesforce.com/s/articleView?id=sf.users_permissionset_licenses.htm" },
+          { label: "Salesforce Help \u2014 Permission Sets", url: "https://help.salesforce.com/s/articleView?id=sf.perm_sets_overview.htm" }
+        ]
+      },
+      "concept:session-based-permission-set-dormant": {
+        id: "concept:session-based-permission-set-dormant",
+        kind: "access-mechanism",
+        label: "A session-based permission set grants nothing passively \u2014 every grant is dormant until session activation",
+        summary: "A SESSION-BASED permission set \u2014 one whose activation-required flag is TRUE \u2014 grants NONE of its permissions passively. Every grant it confers (object CRUD, field-level security, View All / Modify All, Apex-class access, and custom-permission grants) stays DORMANT until the permission set is ACTIVATED for the current session, via Auth.SessionManagement or a launching flow, so all of them are conditional-on-activation rather than standing. When reasoning about what a holder of this set can do at rest, its grants must be treated as INACTIVE by default: assignment alone does not confer the access. This is grounded from the set's own always-present activation-required boolean; it names the activation-gate STRUCTURAL fact, NOT whether any given session actually activates the set (session activation is a runtime event the offline vault cannot observe), NOT which users hold the set, and NOT what the individual grants are when it IS active. Only the activation-gate posture is asserted here.",
+        docs: [
+          { label: "Salesforce Help \u2014 Session-based Permission Sets", url: "https://help.salesforce.com/s/articleView?id=sf.perm_sets_session_map.htm" },
+          { label: "Apex Developer Guide \u2014 Auth.SessionManagement Class", url: "https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_Auth_SessionManagement.htm" }
+        ]
+      },
+      "concept:field-restricted-global-value-set": {
+        id: "concept:field-restricted-global-value-set",
+        kind: "field-provenance",
+        label: "Picklist bound to a restricted global value set",
+        summary: "A picklist field can draw its values from a shared global value set instead of an inline list. When that global value set is marked restricted, the field becomes a closed vocabulary: only the values defined in the shared set are valid, admins cannot add ad-hoc values on the field, and an integration or API write of a value outside the set is rejected. Changing the field's allowed values means editing the shared set, which ripples to every other field bound to it. The offline snapshot grounds this from the field's declared usesValueSet edge to a global value set whose metadata carries restricted=true. It does NOT prove runtime enforcement, does NOT assert that no existing record already holds an out-of-set value (a live, record-level question), and when the restricted flag is absent it does NOT fire \u2014 a global-value-set-backed picklist may still constrain values without the flag being declared in metadata.",
+        docs: [
+          { label: "Salesforce Help \u2014 Create Global Picklist Value Sets", url: "https://help.salesforce.com/s/articleView?id=sf.fields_creating_global_picklist.htm" }
+        ]
+      },
+      "concept:field-picklist-has-retired-values": {
+        id: "concept:field-picklist-has-retired-values",
+        kind: "field-provenance",
+        label: "A picklist retaining an inactive value keeps old data readable but no longer selectable",
+        summary: "A PICKLIST field retains INACTIVE (retired) values in its OWN local value set: when an admin deactivates a value, Salesforce does NOT delete it \u2014 it stays in the field definition, so existing records that already hold it keep displaying and reporting it (the value remains readable), while the value is removed from the picker and can NO LONGER be newly selected in the UI. A retired value is therefore a data-hygiene and migration signal \u2014 it usually means old data still carries a value the org has moved away from. This is grounded from the field's OWN declared value-set entries (each value's active flag); it names the DECLARED presence of a retired value, NOT whether any record currently holds it (a record-level count the offline vault cannot answer), NOT GlobalValueSet-backed picklists (whose values live on the shared value set, not the field, and are not evaluated here), and NOT whether any report, formula, default value, or automation still references the retired value.",
+        docs: [
+          { label: "Salesforce Help \u2014 Manage Picklist Values", url: "https://help.salesforce.com/s/articleView?id=sf.fields_managing_picklists.htm" }
+        ]
+      },
+      "concept:approval-process-inactive-dead": {
+        id: "concept:approval-process-inactive-dead",
+        kind: "firing-condition",
+        label: "An inactive approval process never routes a record for approval and is dead automation",
+        summary: 'An APPROVAL PROCESS whose `active` flag is FALSE is DEAD approval automation: Salesforce lets NO record be submitted into it for approval, never evaluates its entry criteria, and never runs any of its initial-submission actions, per-step approver routing, final-approval / final-rejection actions, or record locks until an admin re-activates it. It must be EXCLUDED from "what happens when this record is submitted for approval" reasoning, from record-lock and read-only-freeze analysis (its finalApprovalRecordLock / finalRejectionRecordLock never take effect while inactive), and from automation-impact counts: counting a deactivated process overstates the automation load, while assuming its field-update actions or locks still run would misattribute a value change or a read-only freeze. This is grounded from the process\'s own always-present `active` boolean; it names the non-running STRUCTURAL fact, NOT whether a Flow-based (record-triggered) approval has replaced it (migration lineage is org-specific) and NOT whether the process WOULD admit a given record if activated (entry criteria remain unevaluated offline). Only active approval processes belong in submit-for-approval and automation-impact surfaces.',
+        docs: [
+          { label: "Salesforce Help \u2014 Considerations for Approvals", url: "https://help.salesforce.com/s/articleView?id=sf.approvals_considerations.htm" }
+        ]
+      },
+      "concept:escalation-rule-time-deferred": {
+        id: "concept:escalation-rule-time-deferred",
+        kind: "async-boundary",
+        label: "An active escalation rule's actions are queued and fire later in a separate context",
+        summary: "An ACTIVE escalation rule does NOT run its escalation actions during the record save. When a record (typically a Case) has aged past the rule entry's declared minute offset (`minutesToEscalation`) without meeting the rule's exit criteria, Salesforce's background escalation process fires the queued actions \u2014 reassigning ownership to a queue or user and/or sending a notification email \u2014 LATER, in a SEPARATE context decoupled from the save that first matched the record. So the effect is DEFERRED: the reassignment/notification lands minutes to hours after the triggering edit, its writes are not part of that save and cannot roll it back, and Salesforce re-checks the record at escalation time and silently drops the queued escalation if the record no longer qualifies (for example it was closed or edited to stop matching). Configured business hours on the entry can shift the fire time further. This names the deferred-action STRUCTURE from the rule's own active state; it does NOT evaluate the `minutesToEscalation` offset (which lives on the rule's per-action reference/notification edges, not on the rule node), assert WHEN the escalation fires, whether the record still qualifies when the timer elapses, or whether the action succeeds.",
+        docs: [
+          { label: "Salesforce Help \u2014 Set Up Escalation Rules", url: "https://help.salesforce.com/s/articleView?id=sf.customize_escrules.htm" }
+        ]
+      },
+      "concept:auto-response-rule-first-match-starvation": {
+        id: "concept:auto-response-rule-first-match-starvation",
+        kind: "automation-collision",
+        label: "Auto-response rule catch-all entry starves later specific entries",
+        summary: 'Auto-response rules evaluate their rule entries top-down in XML order \u2014 the first entry whose criteria match wins and sends its email template, and later entries are never considered. A catch-all entry with NO criteria and NO formula filter (zero criteria items, no formula) matches EVERY record, so if it appears before more specific entries those later entries are structurally unreachable \u2014 a common cause of "why did this record get the wrong auto-response email?" confusion. The offline claim is grounded from the AutoResponseRule `sendsEmail` edges carrying `entryIndex` (evaluation order), `criteriaItemCount`, and `hasFormula`: a broad entry is one with `criteriaItemCount === 0` and `hasFormula === false` that precedes at least one later entry with criteria or a formula. HONEST BOUNDARIES: this names the STRUCTURAL ordering risk from metadata, NOT whether a specific record would match a specific entry at runtime (live criteria evaluation is out of scope). Only ONE auto-response rule per object is active at a time, so this reasons about entry ordering WITHIN a rule, not across rules. A `sendsEmail` edge whose target email template was not retrieved does not resolve in the slice, and the rule fails closed \u2014 yielding nothing rather than guessing \u2014 when `entryIndex` or the criteria metadata a counted edge needs is absent.',
+        severity: "medium"
+      },
+      "concept:record-type-business-process-binding": {
+        id: "concept:record-type-business-process-binding",
+        kind: "access-mechanism",
+        label: "A record type bound to a business process scopes the master status picklist to that process''s stages",
+        summary: "A RECORD TYPE that declares a BUSINESS PROCESS binds records of that type to a specific ordered subset of the object's master status picklist \u2014 the Stage, Status, or Solution-status values that process defines \u2014 so records created with this record type are scoped to the stages the bound process exposes, NOT the object's full set of master-picklist values. This scopes what a user or an automation may set the status / stage field to on such a record: a Flow, an Apex assignment, an API create, or a data import that sets a stage value the bound process does not include can be rejected. This is grounded from the record type's own declared businessProcess reference; it names the DECLARED binding (that this record type IS scoped to a business process), NOT the specific stage values that process exposes (those live on the BusinessProcess metadata and are org-specific), NOT which records currently carry this record type or their current stage (record-level runtime state the offline vault does not hold), and NOT whether the bound business process is itself active. A record type WITHOUT a business process uses the object's full master picklist and has no such scoping. Only a record type that declares a business process contributes this constraint.",
+        docs: [
+          { label: "Salesforce Help \u2014 Create Business Processes", url: "https://help.salesforce.com/s/articleView?id=sf.customize_busprocess.htm" }
+        ]
+      },
+      "concept:apex-dynamic-reflective-surface": {
+        id: "concept:apex-dynamic-reflective-surface",
+        kind: "code-quality-defect",
+        label: "A dynamic or reflective Apex construct that static dependency analysis cannot see",
+        summary: "A component uses DYNAMIC or REFLECTIVE Apex \u2014 object, field, or type references assembled at RUNTIME rather than written as static literals: a dynamic query built as a string (the dynamic-query API, Database.query), a runtime schema describe (Schema.getGlobalDescribe), reflective type instantiation by name (Type.forName), or untyped deserialization (JSON.deserializeUntyped). These constructs are INVISIBLE to static dependency analysis: the scanner resolves reads, writes, calls, and references from tokens it can see in the source, so a query, field, or class named by a runtime-built string is never captured as an edge. The honest consequence is a COMPLETENESS gap, not a proven defect \u2014 impact analysis, usage / where-used results, and dead-code findings for this class MAY BE INCOMPLETE, because a real dependency can be hidden behind the runtime construction. HONEST BOUNDARIES: this is a HEURISTIC token recognition, NOT a compiler AST \u2014 it can FLAG a dynamic construct whose reference is actually a safe constant, and can MISS one assembled in a way the tokenizer does not match. It does NOT prove the class is buggy, does NOT identify WHICH objects or fields the dynamic code touches, and does NOT assert any specific hidden dependency exists; it flags the class as one whose static analysis is blind in spots and warrants reading the source to confirm.",
+        docs: [
+          { label: "Apex Developer Guide \u2014 Dynamic SOQL", url: "https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dynamic_soql.htm" }
+        ]
+      },
+      "concept:named-credential-merge-fields-injectable": {
+        id: "concept:named-credential-merge-fields-injectable",
+        kind: "external-api-surface",
+        label: "A named credential that allows merge fields in its HTTP header or body is an outbound injection surface",
+        summary: "By DEFAULT Salesforce BLOCKS merge-field syntax in the HTTP header and body of a callout that authenticates through a named credential \u2014 a deliberate guard against injecting caller-influenced values into an authenticated outbound request. Setting `allowMergeFieldsInHeader` or `allowMergeFieldsInBody` to true LIFTS that guard for this credential: Apex may then substitute merge fields (including values drawn from record or user data) into the outbound HTTP header or body of any callout that uses it. That makes the credential an outbound INJECTION SURFACE \u2014 if a substituted value is attacker-influenced it can alter the request's headers or payload (header injection, request smuggling, or forging fields the upstream API trusts). This is grounded from the credential's own declared `allowMergeFieldsInHeader` / `allowMergeFieldsInBody` metadata; it names the DECLARED configuration that ENABLES substitution, not a proven exploit. HONEST BOUNDARIES \u2014 it does NOT prove: (a) that any Apex callout actually uses this credential (callers are a separate code-level question the offline vault may not resolve); (b) that any merge field carries UNTRUSTED input \u2014 the substituted values may all be static or trusted, in which case the setting is harmless and often intentional; or (c) that an injection actually occurs at runtime. It names the surface ENABLED by configuration, never a vulnerability. The header flag and the body flag are read independently, so a claim fires per flag that is set.",
+        docs: [
+          { label: "Metadata API Developer Guide \u2014 NamedCredential (allowMergeFieldsInHeader / allowMergeFieldsInBody)", url: "https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_namedcredential.htm" }
+        ]
+      },
+      "concept:connected-app-saml-sso-federation": {
+        id: "concept:connected-app-saml-sso-federation",
+        kind: "access-mechanism",
+        label: "A connected app carrying a SAML config is a SAML SSO federation target with Salesforce as the identity provider",
+        summary: "A connected app that carries a `<samlConfig>` block is a SAML SSO federation target: it declares Salesforce as the SAML Identity Provider (IdP) and the app as an external Service Provider (SP) that Salesforce will mint SIGNED SAML assertions for, asserting an authenticated user's identity so they can single-sign-on into that external relying party. The app's `authProtocol` reads `saml` (SAML only) or `both` (SAML alongside an OAuth client), and the surfaced trust boundary \u2014 the Assertion Consumer Service (ACS) URL the assertion is posted to, the SP entity/audience it is scoped to, the expected issuer, and the subject / NameID format \u2014 defines WHO Salesforce federates identities out to. So it is an identity and trust surface worth reviewing: an outbound authentication relationship that hands a user's asserted identity to a third party. This is grounded from the app's own DECLARED SAML metadata; it names the DECLARED federation configuration, NOT a proven active login flow. HONEST BOUNDARIES: the presence of the config is a STATIC shape, not evidence that anyone authenticates through it, that the signing certificate / trust is currently valid (the key material is deliberately never vaulted), or that the relying party is live; WHO may launch or use the app is a separate access layer (profile / permission-set assignment) the config does not encode; and a SAML federation may be entirely intentional for a trusted downstream app.",
+        docs: [
+          { label: "Salesforce Help \u2014 Enable SAML SSO for Connected Apps (Salesforce as Identity Provider)", url: "https://help.salesforce.com/s/articleView?id=sf.connected_app_create_web_app_sso.htm" }
+        ]
+      },
+      "concept:apex-fake-assertion-test": {
+        id: "concept:apex-fake-assertion-test",
+        kind: "test-quality",
+        label: "A test class asserts a tautology that passes regardless of behavior, so it verifies nothing",
+        summary: "An Apex class annotated @IsTest contains a TAUTOLOGICAL or self-referential assertion \u2014 a System.assert(true, ...), a System.assertEquals(x, x) on the same expression, or a System.assertEquals(literal, sameLiteral) \u2014 an assertion whose two operands are identical (or always true) so it PASSES no matter how the code under test behaves. Such an assertion verifies nothing: it can never fail because a computed value was wrong, only if the code under test throws an uncaught exception, yet it still EXECUTES the code under test and so counts toward the org's Apex code-coverage percentage. It therefore inflates the coverage number while providing no real regression protection, and it can mask a genuine defect behind a green run. HONEST BOUNDARY: this is HEURISTIC recognition from TOKENIZED Apex source \u2014 NOT a compiler AST. It flags the tautological call-site itself; it does NOT prove the whole class is worthless, because the same class may carry other, meaningful assertions alongside the fake one, and it can MISS a value-free assertion assembled through a variable or a shared helper. It names a test-quality review candidate, not proven coverage fraud. Read the test before concluding it verifies nothing.",
+        docs: [
+          { label: "Apex Developer Guide \u2014 Testing Best Practices", url: "https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_best_practices.htm" }
+        ]
+      },
+      "concept:entitlement-process-inactive": {
+        id: "concept:entitlement-process-inactive",
+        kind: "firing-condition",
+        label: "An inactive entitlement process never starts its milestone SLA timers and is dead SLA automation",
+        summary: 'An ENTITLEMENT PROCESS whose `active` flag is FALSE is DEAD SLA automation: Salesforce never applies it to a case and never starts any of its milestone timers \u2014 no SLA countdown begins, no business-hours clock runs, and no milestone-driven escalation can fire from this version until an admin re-activates it. It must be EXCLUDED from SLA / entitlement reasoning and from "what milestones apply on save" impact counts; treating a deactivated process as a live SLA guard would cry wolf about timers that cannot start, while assuming its milestones still run would falsely imply cases are being tracked. This is grounded from the process\'s own `active` flag; it names the non-running STRUCTURAL fact, NOT whether any specific case is currently on-track or breached (that is live per-record timer data this offline vault does not hold), NOT whether this version WOULD apply if activated (entry criteria remain unevaluated offline), and NOT whether another active version of the same process exists (version lineage is org-specific). Only active entitlement processes belong in SLA and entitlement-impact surfaces.',
+        docs: [
+          { label: "Metadata API Developer Guide \u2014 EntitlementProcess", url: "https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_entitlementprocess.htm" }
+        ]
+      },
+      "concept:omnistudio-inactive-component-version": {
+        id: "concept:omnistudio-inactive-component-version",
+        kind: "firing-condition",
+        label: "An inactive OmniStudio component version does not execute at runtime and must be excluded from what-actually-runs analysis",
+        summary: "An OmniStudio component version \u2014 an OmniScript, Integration Procedure, or FlexCard \u2014 whose `isActive` flag is FALSE is a SAVED-BUT-DORMANT version: Salesforce serves and dispatches only the ACTIVE version of an OmniStudio component, so an inactive version does not execute at runtime \u2014 it is not rendered, invoked as an action, or embedded on a page until an admin activates it. It must be EXCLUDED from runtime-reachability, invocation-impact, and 'what actually runs' reasoning about OmniStudio; treating a deactivated version as live would overstate the runtime surface, while assuming it still runs would misattribute behavior to a dormant draft. This is grounded from the component's own always-present `isActive` boolean; it names the non-running STRUCTURAL fact, NOT whether ANOTHER version of the same bundle is active and serving in its place (version lineage is org-specific and not resolved offline), NOT whether anything still references this version by name, NOT what the version WOULD do if activated, and NOT why it was deactivated. Only active OmniStudio component versions belong in runtime-execution surfaces.",
+        docs: [
+          { label: "Salesforce Help \u2014 Activate an OmniScript", url: "https://help.salesforce.com/s/articleView?id=sf.os_activate_an_omniscript.htm" }
+        ]
+      },
+      "concept:required-field-absent-from-all-layouts": {
+        id: "concept:required-field-absent-from-all-layouts",
+        kind: "field-provenance",
+        label: "A universally required field placed on no page layout has no declared UI data-entry surface",
+        summary: "A field that is UNIVERSALLY REQUIRED at the field-definition level (every record must carry a value) but is placed on NO page layout has no declared UI data-entry surface: a user creating or editing a record through a layout that omits the field sees no input for it, so its required value must be supplied some other way \u2014 a default value, a before-save automation, an Apex / API / data-import insert that sets it, or the platform's own runtime rendering of universally-required fields on the create / edit form. This is grounded from the field's own declared required flag together with the ABSENCE of any layout that places the field in a field-bearing region (the detail body, the Highlights Panel, or the mini layout); it is an ABSENCE claim, so under incomplete Layout coverage the on-no-layout conclusion is NOT asserted (downgraded to not-checked). HONEST BOUNDARIES: it does NOT prove any specific save fails \u2014 a default, automation, or API path may supply the value, and the platform itself forces universally-required fields onto edit forms \u2014 and it does NOT see Lightning DYNAMIC FORM (FlexiPage) field placement, which lives OUTSIDE classic page-layout metadata, so a field surfaced only through a Dynamic Form still matches this shape. It names the DECLARED layout-placement gap, not a proven runtime data-entry failure.",
+        docs: [
+          { label: "Metadata API Developer Guide \u2014 Layout", url: "https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_layouts.htm" }
+        ]
+      },
+      "concept:dataraptor-errors-ignored": {
+        id: "concept:dataraptor-errors-ignored",
+        kind: "code-quality-defect",
+        label: "A DataRaptor with 'Ignore Error' on swallows per-record failures and continues instead of surfacing them",
+        summary: "A DataRaptor (an OmniStudio OmniDataTransform) whose 'Ignore Error' toggle is ON does NOT halt or raise when an individual record operation inside the transform fails: the failing item is skipped and the transform CONTINUES, returning a success-shaped result to its caller even though some reads or writes did not complete. This is an ERROR-SWALLOWING reliability shape \u2014 a failure that would normally abort the operation is suppressed, so a partial or silent data-integrity gap (records not written, values not loaded) can pass undetected unless the caller explicitly inspects the returned error collection. It is DISTINCT from the 'Rollback on Error' toggle (a separate setting that controls whether already-completed writes are undone on failure); ignoring errors while not rolling back can leave partially applied data. It is also DISTINCT from an Apex swallowed-exception pattern \u2014 this is a DECLARED OmniStudio configuration flag, not a heuristic read of catch-block source. HONEST BOUNDARY \u2014 this is a declared configuration shape read from the transform's own toggle, NOT a proven failure: it does NOT establish that any record actually fails at runtime, NOT that data was actually lost or left partial, and NOT whether the invoking OmniScript, Integration Procedure, or Apex caller checks the error output and compensates. It names the error-suppression structural signal, not a confirmed data-loss incident.",
+        docs: [
+          { label: "Salesforce Help \u2014 DataRaptor Loads", url: "https://help.salesforce.com/s/articleView?id=sf.os_dataraptor_loads.htm" },
+          { label: "Salesforce Help \u2014 Design DataRaptor Loads", url: "https://help.salesforce.com/s/articleView?id=sf.os_design_dataraptor_loads.htm" }
+        ]
+      },
+      "concept:object-deployment-status-in-development": {
+        id: "concept:object-deployment-status-in-development",
+        kind: "access-mechanism",
+        label: "An In Development object is hidden from every user who lacks Customize Application",
+        summary: `A CUSTOM OBJECT whose deployment status is IN DEVELOPMENT (not Deployed) is hidden from every user who lacks the "Customize Application" administrative permission: its tab, list views, and fields do not appear in the app for ordinary users, and it is effectively unusable in production until an admin flips it to Deployed. It must be EXCLUDED from "which users can work with this object" reasoning about non-admin users, because assuming an In Development object is generally reachable would overstate who can see or edit its records. This is grounded from the object's own declared deployment-status value; it names the DECLARED visibility posture, NOT whether any specific user holds Customize Application (an assignment question the offline vault cannot answer), NOT whether the object was intentionally left in development, and NOT record-level access once it IS deployed. Only Deployed objects belong in ordinary-user reachability surfaces.`,
+        docs: [
+          { label: "Salesforce Help \u2014 Object Deployment Status (In Development vs Deployed)", url: "https://help.salesforce.com/s/articleView?id=sf.dev_object_deployment.htm" }
+        ]
+      },
+      "concept:object-autonumber-name-field": {
+        id: "concept:object-autonumber-name-field",
+        kind: "field-provenance",
+        label: "A custom object with an Auto Number Name field has system-assigned, read-only record names",
+        summary: "A CUSTOM OBJECT whose NAME field is an AUTO NUMBER gives every record a SYSTEM-ASSIGNED name generated from a display format and a sequence at insert \u2014 so the record Name is READ-ONLY on every write path (the UI, API, Apex, Flow, and data imports cannot set or change it) and is unavailable in a before-insert context (it is assigned during insert). The name is stored and displayed as a formatted STRING, not a number, so it cannot be used in arithmetic; changing the display format renumbers only NEW records, so existing names and any sequence gaps from failed inserts persist. This is grounded from the object's own declared name-field type; it names the record-name PROVENANCE (system-assigned, read-only), it is DISTINCT from a custom field of type Auto Number (here it is the record NAME itself that is auto-assigned), and it does NOT name the current or next sequence value (record-level data the offline vault cannot answer) or prove any integration attempts to set the name.",
+        docs: [
+          { label: "Salesforce Help \u2014 Auto-Number Fields", url: "https://help.salesforce.com/s/articleView?id=sf.custom_field_types.htm" }
+        ]
+      },
+      "concept:global-value-set-has-inactive-value": {
+        id: "concept:global-value-set-has-inactive-value",
+        kind: "field-provenance",
+        label: "A shared global value set retaining a deactivated value retires it across every bound field at once",
+        summary: "A GLOBAL (shared) value set retains INACTIVE (deactivated) values in its own definition rather than deleting them. Because the set is SHARED, deactivating a value removes it from the picker on EVERY picklist field bound to the set at once \u2014 it is NO LONGER SELECTABLE for new records anywhere \u2014 while existing records that already hold it keep displaying and reporting it (the value stays readable). Reactivating or removing the value ripples to every field bound to the set, so a retired value here is an org-wide data-hygiene and migration signal, not a per-field one. This is grounded from the shared value set's OWN declared entries (each value's active flag); it names the DECLARED presence of a retired value, NOT whether any record currently holds it (a record-level count the offline vault cannot answer) and NOT which specific fields bind this set (that is the fields' own usesValueSet edges, resolved separately).",
+        docs: [
+          { label: "Salesforce Help \u2014 Manage Global Picklist Value Sets", url: "https://help.salesforce.com/s/articleView?id=sf.fields_creating_global_picklist.htm" }
+        ]
+      },
+      "concept:standard-value-set-has-inactive-value": {
+        id: "concept:standard-value-set-has-inactive-value",
+        kind: "field-provenance",
+        label: "A standard value set retaining a deactivated value retires it org-wide on the standard field that uses it",
+        summary: "A STANDARD value set \u2014 the org-wide value list behind a standard picklist such as Industry, Lead Source, or Opportunity Stage \u2014 retains INACTIVE (deactivated) values rather than deleting them. A deactivated standard value is NO LONGER SELECTABLE for new records on the standard field(s) that draw from the set, yet existing records that already hold it keep displaying and reporting it (the value stays readable). This is grounded from the standard value set's OWN declared entries (each value's active flag); it names the DECLARED presence of a retired value. A standard field's binding to its value set is IMPLICIT \u2014 Salesforce wires it internally by the field's type, with no declared metadata pointer \u2014 so this does NOT name which specific fields are affected (there is no edge to follow), does NOT prove any record currently holds the value (a record-level count the offline vault cannot answer), and is DISTINCT from a custom field's own local retired value and from a custom shared global value set.",
+        docs: [
+          { label: "Salesforce Help \u2014 Update Picklists with a Custom or Standard Value Set", url: "https://help.salesforce.com/s/articleView?id=sf.fields_managing_picklists.htm" }
+        ]
+      },
+      "concept:apex-test-hardcoded-sandbox-data": {
+        id: "concept:apex-test-hardcoded-sandbox-data",
+        kind: "test-quality",
+        label: "A test class hardcodes sandbox-specific literals, so it will not run against production or another org",
+        summary: "An Apex class annotated @IsTest contains a HARDCODED SANDBOX-SPECIFIC literal \u2014 a username or URL carrying a sandbox marker such as a `.sandbox` / `.dev` / `.uat` / `.fullcopy` suffix, a `--sandbox` My Domain segment, or a `sandbox.salesforce.com` host. Apex tests are expected to be SELF-CONTAINED and org-agnostic: they should build their own fixtures (a @TestSetup method or a test-data factory) and read environment-specific values from configuration, so the same test passes in every org it is deployed to. A test that embeds a value tied to one specific sandbox breaks that contract \u2014 it may pass in the sandbox it was written against and then FAIL, or silently exercise the wrong data, when the code is promoted to production or run in a different sandbox, and because it is a test the failure surfaces only at deploy or run time. Externalize the value into a Custom Metadata Type or Custom Setting record, or generate it in @TestSetup, instead. HONEST BOUNDARY: this is HEURISTIC recognition from TOKENIZED Apex source \u2014 NOT a compiler AST. It matches string literals that CARRY a sandbox marker, so it can FLAG a value that is deliberately inert or only descriptive, and can MISS a sandbox value assembled at runtime or held in a helper the recognizer cannot follow. It names a test-portability review candidate, not a proven test failure.",
+        docs: [
+          { label: "Apex Developer Guide \u2014 Testing Best Practices", url: "https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_best_practices.htm" }
+        ]
+      },
+      "concept:restriction-rule-inactive": {
+        id: "concept:restriction-rule-inactive",
+        kind: "firing-condition",
+        label: "An inactive restriction rule enforces no narrowing and leaves records fully visible per normal sharing",
+        summary: "A RESTRICTION RULE whose `active` flag is FALSE is DEAD access control: while inactive it filters NOTHING, so the records it would otherwise HIDE stay fully visible to the users it targets under the org-wide default, sharing rules, the role hierarchy, and manual / Apex shares. A restriction rule is the ONE declarative mechanism that NARROWS record access BELOW what every other sharing feature grants \u2014 every other mechanism only widens \u2014 so a deactivated one subtracts nothing until an admin re-activates it. It must be EXCLUDED from \"what can this user NOT see\" reasoning and from any conclusion that an object's records are narrowed on its account: treating a disabled rule as a live boundary would falsely imply records are hidden that are in fact exposed, while treating it as gone would miss that re-activation instantly narrows them again. This is grounded from the rule's own always-present `active` flag; it names the non-enforcing STRUCTURAL fact, NOT whether the rule WOULD narrow a specific record if activated (its recordFilter / userCriteria remain unevaluated offline) and NOT why it was deactivated. Only active restriction rules narrow record access.",
+        docs: [
+          { label: "Salesforce Help \u2014 Restriction Rules", url: "https://help.salesforce.com/s/articleView?id=sf.security_restriction_rule.htm" }
+        ]
+      },
+      "concept:approval-process-pending-lock-editability": {
+        id: "concept:approval-process-pending-lock-editability",
+        kind: "access-mechanism",
+        label: "An approval process can widen the pending record's lock so the assigned approver may edit it",
+        summary: 'When a record is SUBMITTED into an approval process it is AUTOMATICALLY LOCKED while it is PENDING \u2014 read-only to everyone except administrators and "Modify All"/"Modify All Data" holders. The process\'s `recordEditability` setting decides whether that pending lock is WIDENED: `AdminOrCurrentApprover` additionally lets the CURRENTLY-ASSIGNED APPROVER edit the very record awaiting their decision, whereas the default `AdminOnly` bars even the approver from editing it until the process completes. This is an access and audit surface \u2014 under the widened posture the person evaluating the request can also modify the record they are approving, and any field the approver changes while it is pending is a real edit path a save-order or data-integrity analysis must account for. This is grounded from the approval process\'s own declared `recordEditability` value; it names the DECLARED pending-lock editability, NOT whether any specific record is currently pending or locked (record-level runtime state the offline vault does not hold), NOT WHO the assigned approver is on a given record (approver routing is per-record and per-step), and NOT the separate final-approval / final-rejection lock behavior. An approval process set to `AdminOnly` (or that declares no recordEditability) contributes no approver-edit widening.',
+        docs: [
+          { label: "Salesforce Help \u2014 Considerations for Approvals (record locking)", url: "https://help.salesforce.com/s/articleView?id=sf.approvals_considerations.htm" }
+        ]
+      },
+      "concept:approval-process-recall-unlocks-record": {
+        id: "concept:approval-process-recall-unlocks-record",
+        kind: "firing-condition",
+        label: "An approval process that allows recall lets the submitter withdraw a request, unlocking the record and firing recall actions",
+        summary: "An APPROVAL PROCESS whose `allowRecall` flag is true lets the ORIGINAL SUBMITTER RECALL (withdraw) a still-pending approval request. A recall UNLOCKS the record \u2014 it leaves the locked/pending state without any approver's decision \u2014 and FIRES the process's recall actions: the field updates, email alerts, tasks, or outbound messages configured on the recall hook. So the record can exit approval purely by submitter action, and that exit runs its own automation, which matters for \"why did this record unlock, or why did this field change, while it was in approval?\" reasoning and for automation-impact counts. This is grounded from the process's own always-present `allowRecall` boolean; it names the DECLARED recall CAPABILITY, NOT whether any specific record was ever recalled (record-level runtime state the offline vault does not hold), WHO may submit or recall (submitter membership is per-record / per-config), or whether the recall actions succeed. An approval process with `allowRecall` false permits no submitter recall \u2014 a pending record moves forward only by an approver's action (or an admin), so no submitter-driven unlock or recall-action firing applies.",
+        docs: [
+          { label: "Salesforce Help \u2014 Considerations for Approvals", url: "https://help.salesforce.com/s/articleView?id=sf.approvals_considerations.htm" }
+        ]
+      },
+      "concept:auth-provider-registration-handler-apex-hook": {
+        id: "concept:auth-provider-registration-handler-apex-hook",
+        kind: "access-mechanism",
+        label: "An auth provider's registration handler runs Apex in system context during SSO just-in-time provisioning",
+        summary: "An AUTH PROVIDER whose `registrationHandler` names an Apex class binds a hidden identity entry point: on every social-sign-on / SSO login through this provider, Salesforce invokes that class (an implementation of `Auth.RegistrationHandler`) in SYSTEM context to CREATE or UPDATE the User record for the authenticating identity \u2014 just-in-time (JIT) user provisioning. The handler runs OUTSIDE the normal UI / permission path and under the provider's declared `executionUser` identity, so it can insert or modify Users, assign profiles, and set fields with the platform's trust rather than the logging-in person's. This is grounded from the provider's own declared `registrationHandler` binding; it names the STRUCTURAL entry-point fact, NOT whether any user has actually logged in through this provider, NOT what the handler code does (its logic is a separate ApexClass the offline vault does not execute), and NOT whether the class still exists or compiles. Review the handler as a privileged provisioning surface.",
+        severity: "high",
+        docs: [
+          { label: "Salesforce Help \u2014 Add an Apex Registration Handler to an Auth. Provider", url: "https://help.salesforce.com/s/articleView?id=sf.sso_provider_addl_apex.htm" }
+        ]
+      },
+      "concept:platform-event-channel-member-filtered-stream": {
+        id: "concept:platform-event-channel-member-filtered-stream",
+        kind: "firing-condition",
+        label: "A channel member's filter expression narrows which events publish to the platform event or CDC channel",
+        summary: "A PLATFORM EVENT CHANNEL MEMBER that declares a `filterExpression` binds its entity onto the channel with a FILTER: only the change events (or platform events) whose fields satisfy that declared expression are published to the channel and delivered to its subscribers \u2014 every other change is silently withheld from this stream. So a subscriber reading this channel sees a NARROWED subset, not the object's full change feed; automation or integrations that assume every change arrives can miss records that fail the filter. This is grounded from the member's own declared `filterExpression`; it names the STRUCTURAL filtered-stream fact, NOT runtime EVALUATION of which specific records pass the filter (that needs record-level data the offline vault does not have) and NOT the delivery guarantees of the channel itself (retention, replay, and ordering are separate async limits covered elsewhere).",
+        docs: [
+          { label: "Salesforce Help \u2014 Filter Your Stream of Change Events", url: "https://help.salesforce.com/s/articleView?id=sf.cdc_filter_change_events.htm" }
+        ]
+      },
+      "concept:external-service-registration-incomplete": {
+        id: "concept:external-service-registration-incomplete",
+        kind: "status-code",
+        label: "An external service registration whose status is not Complete has unavailable generated actions",
+        summary: "An EXTERNAL SERVICE REGISTRATION whose `status` is anything other than `Complete` (for example `InProgress` or `NotComplete`) did not finish importing its OpenAPI schema into invocable operations: its generated actions are UNAVAILABLE, so any Flow, Apex, or OmniStudio step that invokes an operation from this registration cannot resolve it and fails at build or run time. A non-Complete registration is a half-built integration binding, not a live one. This is grounded from the registration's own always-present `status` scalar; it names the STRUCTURAL availability fact, NOT why the import stalled (schema fetch, auth, or parse errors are not captured offline) and NOT whether any component actually calls an operation from this service (that is a separate usage question). Only a Complete registration exposes callable operations.",
+        docs: [
+          { label: "Salesforce Help \u2014 Generate an External Service", url: "https://help.salesforce.com/s/articleView?id=sf.external_services.htm" }
+        ]
+      },
+      "concept:named-credential-per-user-principal": {
+        id: "concept:named-credential-per-user-principal",
+        kind: "access-mechanism",
+        label: "A per-user named credential authenticates each callout under the running user's own external credential",
+        summary: "A NAMED CREDENTIAL whose `principalType` is `PerUser` does NOT carry one shared org-wide identity: each callout that authenticates through it uses the RUNNING USER's own per-user external credential, which every user must configure individually before their callouts can succeed. So the same Apex or flow callout behaves differently per user \u2014 it authenticates as that user against the external system, and it FAILS for any user who has not set up their personal credential \u2014 and the external system's audit log attributes each call to a distinct per-user identity rather than a single service account. This is grounded from the credential's own declared `principalType`; it names the STRUCTURAL per-user authentication posture, NOT which users have configured their credential (that is per-user runtime state the offline vault does not hold) and NOT whether any Apex actually issues a callout through this credential.",
+        docs: [
+          { label: "Salesforce Help \u2014 Define a Named Credential", url: "https://help.salesforce.com/s/articleView?id=sf.named_credentials_define.htm" }
+        ]
+      },
+      "concept:omnistudio-test-procedure-scope": {
+        id: "concept:omnistudio-test-procedure-scope",
+        kind: "firing-condition",
+        label: "An OmniStudio component flagged as a test procedure is a development test harness, not production runtime, and must be excluded from what-actually-runs analysis",
+        summary: "An OmniStudio component \u2014 an OmniScript or Integration Procedure \u2014 whose `isTestProcedure` flag is TRUE is a DEVELOPMENT TEST HARNESS: its declared purpose is to exercise and validate ANOTHER OmniScript or Integration Procedure during development, NOT to serve end users as a production flow. It is not part of the normal production runtime surface \u2014 it is invoked to test a target component, not rendered to users, embedded on a page, or dispatched as production automation. It must therefore be EXCLUDED from 'what actually runs in production', runtime-reachability, and invocation-impact reasoning about OmniStudio, and it is a likely cleanup candidate when found in a production org. This is grounded from the component's own always-present `isTestProcedure` boolean; it names the declared test-harness scope, NOT whether the test currently passes, NOT which component it targets, NOT whether it has ever been run, and NOT whether it is also active (liveness is the separate `isActive` axis). Test procedures do not belong in production runtime-execution surfaces.",
+        docs: [
+          { label: "Salesforce Help \u2014 Test OmniScripts and Integration Procedures", url: "https://help.salesforce.com/s/articleView?id=sf.os_test_omniscripts.htm" }
+        ]
+      },
+      "concept:dataraptor-load-fires-assignment-rules": {
+        id: "concept:dataraptor-load-fires-assignment-rules",
+        kind: "firing-condition",
+        label: "A DataRaptor with 'Assignment Rules Used' on fires the object's assignment rules as a side effect of the records it writes",
+        summary: "A DataRaptor (an OmniStudio OmniDataTransform) whose 'Assignment Rules Used' toggle is ON writes its Lead or Case records with the assignment-rule header set, so when it inserts or updates those records the object's ACTIVE assignment rules EVALUATE as a side effect of the transform's save: record ownership can be reassigned and assignment email notifications can be sent, even though nothing in the DataRaptor's own field mappings says so. A reader tracing what this transform does must account for that downstream assignment automation, not just the mapped field writes \u2014 the write path fans out into the object's routing rules. This is grounded from the transform's own declared `assignmentRulesUsed` toggle; it names the declared intent to run assignment rules on write, NOT a proof of any outcome: it does NOT establish that the target object has any ACTIVE assignment rule, that any specific record is actually reassigned or notified, or that the transform writes Lead / Case at all (only Lead and Case support assignment rules \u2014 the toggle is inert on any other object). It names the save-time side-effect surface, not a confirmed reassignment.",
+        docs: [
+          { label: "Salesforce Help \u2014 DataRaptor Load Options", url: "https://help.salesforce.com/s/articleView?id=sf.os_design_dataraptor_loads.htm" }
+        ]
+      },
+      "concept:omnistudio-metadata-cache-disabled": {
+        id: "concept:omnistudio-metadata-cache-disabled",
+        kind: "code-quality-defect",
+        label: "An OmniStudio component with metadata caching disabled recompiles its definition on every invocation, adding per-request latency",
+        summary: "An OmniStudio component \u2014 an OmniScript or Integration Procedure \u2014 whose `isMetadataCacheDisabled` flag is TRUE runs WITHOUT metadata caching: the OmniStudio runtime does not cache the component's compiled definition, so it re-reads and recompiles the definition metadata on EVERY load or invocation instead of serving a cached copy. That adds per-request latency, and for an Integration Procedure invoked at volume it repeats that compile work on each call, adding CPU and metadata-query pressure to every transaction that touches the component. Disabling the metadata cache is a documented DEVELOPMENT / debugging aid (so a designer sees definition edits immediately) that is not meant to ship to a production org, where it becomes a standing performance drag. This is grounded from the component's own always-present `isMetadataCacheDisabled` boolean; it names the declared cache-disabled configuration posture, NOT a measured regression: it does NOT prove any specific slowdown, timeout, page-load delay, or governor-limit breach at runtime \u2014 those depend on invocation volume and org load the offline vault does not hold. It names the disabled-cache structural signal, not a confirmed performance incident.",
+        docs: [
+          { label: "Salesforce Help \u2014 OmniStudio Metadata Caching", url: "https://help.salesforce.com/s/articleView?id=sf.os_omnistudio_metadata_caching.htm" }
+        ]
+      },
+      "concept:static-resource-public-cache-control-exposure": {
+        id: "concept:static-resource-public-cache-control-exposure",
+        kind: "access-mechanism",
+        label: "A static resource with Public cache-control is shared-cached and reachable by unauthenticated guest users",
+        summary: "A STATIC RESOURCE whose cacheControl is set to Public is cached in a SHARED, cross-user cache (the browser and the Salesforce CDN keep one copy served to all users) and is eligible to be delivered to UNAUTHENTICATED guest users through a Salesforce Site or Experience Cloud resource URL \u2014 so its bytes are effectively world-readable to anyone who can reach that URL and must never hold secrets such as API keys, tokens, or credentials. The alternative, Private, scopes caching to the requesting user own session and is not shared across users. This is grounded from the resource own always-present cacheControl scalar; it names the DECLARED cache-control posture and the shared-cache / guest-exposure it enables, NOT proof that the resource actually contains sensitive data, NOT whether any public page currently references it, and NOT whether its URL has in fact been shared. Only the Public posture is asserted, never a proven leak of a specific secret.",
+        docs: [
+          { label: "Metadata API Developer Guide \u2014 StaticResource", url: "https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_staticresource.htm" }
+        ]
+      },
+      "concept:custom-metadata-record-protected-namespace-scoped": {
+        id: "concept:custom-metadata-record-protected-namespace-scoped",
+        kind: "access-mechanism",
+        label: "A protected custom metadata record is accessible only to code in its own namespace",
+        summary: "A PROTECTED custom metadata record is accessible ONLY to Apex, Flow, and formula code that runs in the SAME namespace that owns the record. When the owning type is packaged and installed into a subscriber org, the subscriber own Apex and SOQL CANNOT read the record, and its protected field values are returned masked (the three-asterisk literal) rather than as real content \u2014 which is exactly why protected custom metadata is the standard place to store package secrets. An UNPROTECTED record, by contrast, is readable by any code in the org. This is grounded from the record own required, declared protected flag; it names a PACKAGING-SCOPED access boundary only. It does NOT assert the record actual field values (which may be masked and unreadable from this offline snapshot), NOT whether this org is the owning namespace or a downstream subscriber, and NOT that any specific query is currently blocked \u2014 those depend on install context the offline vault does not hold.",
+        docs: [
+          { label: "Metadata API Developer Guide \u2014 CustomMetadata", url: "https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_custommetadata.htm" }
+        ]
+      },
+      "concept:email-template-unavailable-hidden": {
+        id: "concept:email-template-unavailable-hidden",
+        kind: "status-code",
+        label: "An email template marked not Available For Use is hidden from the template picker",
+        summary: "An EMAIL TEMPLATE whose Available For Use flag is false is NOT offered to users when they compose or send an email through the UI \u2014 it is hidden from the email-template picker and cannot be selected for a manual send, so it is effectively dormant for interactive use and should be EXCLUDED from any which-templates-can-a-user-choose surface. This is grounded from the template own required, declared available flag; it names the DECLARED availability status only. It does NOT prove the template is unused \u2014 automation, workflow / flow email alerts, or Apex that reference the template DIRECTLY by id or developer name can still send it regardless of this flag \u2014 and it says nothing about the template body, subject, or merge fields. Only the not-offered-in-the-picker status is asserted, never a proven absence of every sender.",
+        docs: [
+          { label: "Metadata API Developer Guide \u2014 EmailTemplate", url: "https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_emailtemplate.htm" }
+        ]
+      },
+      "concept:group-role-subordinates-transitive-membership": {
+        id: "concept:group-role-subordinates-transitive-membership",
+        kind: "access-mechanism",
+        label: "A public group whose member is a role-and-subordinates transitively contains the whole role subtree",
+        summary: "A PUBLIC GROUP whose declared membership includes a role AND its SUBORDINATES transitively contains the named role plus EVERY role beneath it in the role hierarchy \u2014 the whole subtree is a member of the group. Because groups are the reusable principal that many access mechanisms grant to, ANY access conferred on this group \u2014 an owner-based or criteria-based sharing rule shared to the group, queue ownership, report / dashboard / document folder access, or list-view sharing \u2014 therefore reaches the entire role subtree, not just a single role. This is grounded from the group own declared member row (the role-and-subordinates membership marker); it names the DECLARED membership cascade \u2014 the ROLES the group pulls in \u2014 NOT the individual users occupying those roles (an assignment question the offline vault does not answer) and NOT any specific record grant, which additionally depends on each object org-wide default and record-level state the offline snapshot does not hold.",
+        docs: [
+          { label: "Metadata API Developer Guide \u2014 Group", url: "https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_group.htm" }
+        ]
       }
     });
     CONCEPT_RULES = Object.freeze([
@@ -56824,6 +57262,456 @@ var init_concept_model = __esm({
         maxConfidence: "declared",
         absenceShaped: false,
         dependsOnCoverage: ["AssignmentRule", "Queue", "Role"]
+      },
+      {
+        id: "rule:validation-rule/inactive-dead",
+        concept: "concept:validation-rule-inactive",
+        bind: { componentTypes: ["ValidationRule"], whereProperty: { key: "active", equals: false } },
+        interpretation: `{ids} is INACTIVE \u2014 Salesforce never evaluates its error-condition formula on insert or update, so it can neither block a save nor surface its error message until an admin re-activates it. It must be EXCLUDED from save-order-of-execution analysis, from "what could reject this write" reasoning, and from required-field / collision gate counts: treating a deactivated rule as a live guard would cry wolf about a constraint that cannot fire, while treating it as protection would falsely assure that bad data is blocked. This names the non-enforcing structural fact from the rule's own active flag, NOT whether it WOULD reject a specific record if activated (the formula is not evaluated offline).`,
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["ValidationRule"]
+      },
+      {
+        id: "rule:workflow/inactive-dead",
+        concept: "concept:workflow-rule-inactive-dead",
+        bind: { componentTypes: ["WorkflowRule"], whereProperty: { key: "active", equals: false } },
+        interpretation: `{ids} is INACTIVE \u2014 DEAD legacy automation that Salesforce never evaluates, whose actions (field updates, email alerts, outbound messages, time-dependent actions) never run until it is re-activated. It must be EXCLUDED from save-order-of-execution analysis, from field-writer-collision reasoning, and from "what fires on save" impact counts: counting a deactivated rule overstates the automation load, while assuming its field updates still run would misattribute a value change. This names the non-running structural fact from the rule's own active flag, NOT whether a Flow has replaced it and NOT whether it WOULD match a given record if activated (criteria remain unevaluated offline).`,
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["WorkflowRule"]
+      },
+      {
+        id: "rule:field/longtext-richtext-not-filterable",
+        concept: "concept:field-longtext-richtext-not-filterable",
+        bind: { componentTypes: ["CustomField"], whereProperty: { key: "dataType", in: ["LongTextArea", "Html"] } },
+        interpretation: "{ids} is a Long Text Area or Rich Text (Html) field \u2014 this data-type class is not filterable, sortable, groupable, or indexed, so it cannot appear in a SOQL WHERE / ORDER BY / GROUP BY, a list-view filter, or a report filter, and it cannot be marked as an external id or unique. Reference it only in SELECT clauses and body content. This is the platform restriction that follows from the field's type class; it does NOT assert that any specific query, list view, or report currently references the field (a usage question), only that such a filter, sort, or group-by would be rejected.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["CustomField"]
+      },
+      {
+        id: "rule:duplicate-rule/bypass-sharing-match",
+        concept: "concept:duplicate-rule-bypass-sharing-match",
+        bind: { componentTypes: ["DuplicateRule"], whereProperty: { key: "securityOption", equals: "BypassSharingRules" } },
+        interpretation: "{ids} sets securityOption to BypassSharingRules \u2014 its duplicate matching runs in SYSTEM CONTEXT, comparing an incoming record against records the running user cannot see under the sharing model. A save can therefore be blocked or alerted by a hidden duplicate the user has no visibility into and cannot open to resolve; the alternative, EnforceSharingRules, would limit matching to records the user can already access. This is the declared sharing-context posture only \u2014 not a proof that the rule is active, that matching records exist, or that a specific save would surface a hidden duplicate.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["DuplicateRule"]
+      },
+      {
+        id: "rule:duplicate-rule/references-inactive-matching-rule",
+        concept: "concept:duplicate-rule-references-inactive-matching-rule",
+        bind: { edgeType: "references", componentTypes: ["MatchingRule"], whereProperty: { key: "isActive", equals: true }, aggregate: { edgeSource: "root-outgoing", endpointWhereProperty: { key: "ruleStatus", notIn: ["Active"] }, countDistinctEndpoint: "to", op: "gte", threshold: 1 } },
+        interpretation: "{object} is an ACTIVE duplicate rule that references {count} matching rule(s) ({ids}) whose ruleStatus is NOT Active \u2014 an inactive matching rule performs NO duplicate detection, so on that matcher duplicate records save SILENTLY with no alert and no block, even though the duplicate rule itself is enabled. Reactivate the matching rule, or repoint the duplicate rule at a live matcher, to restore protection. This asserts the declared active flag and the matcher's declared ruleStatus from metadata only \u2014 it does NOT prove duplicate records exist, that a specific save would have been caught, or that another active matcher on the same rule still covers the object.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["DuplicateRule", "MatchingRule"]
+      },
+      {
+        id: "rule:approval-process/final-approval-lock",
+        concept: "concept:approval-process-final-lock-record-readonly",
+        bind: { componentTypes: ["ApprovalProcess"], whereProperty: { key: "finalApprovalRecordLock", equals: true } },
+        interpretation: '{ids} declares `finalApprovalRecordLock` = true \u2192 when this approval process reaches FINAL APPROVAL it LOCKS the record, making it READ-ONLY to everyone except administrators and "Modify All"/"Modify All Data" holders (plus the process\'s own unlock step). After final approval, later user edits AND automation updates \u2014 flow, workflow, trigger, or API field writes \u2014 FAIL with an entity-is-locked error unless the record is unlocked first, so a downstream automation that updates a just-approved record can silently fail on the lock. This is the DECLARED lock behavior from the process\'s own final-approval-lock flag; it does NOT assert whether any specific record is currently locked (record-level runtime state the offline vault does not hold), which specific users can still edit it, or whether any automation actually attempts a post-lock update.',
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["ApprovalProcess"]
+      },
+      {
+        id: "rule:approval-process/final-rejection-lock",
+        concept: "concept:approval-process-final-lock-record-readonly",
+        bind: { componentTypes: ["ApprovalProcess"], whereProperty: { key: "finalRejectionRecordLock", equals: true } },
+        interpretation: '{ids} declares `finalRejectionRecordLock` = true \u2192 when this approval process reaches FINAL REJECTION it LOCKS the record, making it READ-ONLY to everyone except administrators and "Modify All"/"Modify All Data" holders (plus the process\'s own unlock step). After final rejection, later user edits AND automation updates \u2014 flow, workflow, trigger, or API field writes \u2014 FAIL with an entity-is-locked error unless the record is unlocked first, so a downstream automation that updates a just-rejected record can silently fail on the lock. This is the DECLARED lock behavior from the process\'s own final-rejection-lock flag; it does NOT assert whether any specific record is currently locked (record-level runtime state the offline vault does not hold), which specific users can still edit it, or whether any automation actually attempts a post-lock update.',
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["ApprovalProcess"]
+      },
+      {
+        id: "rule:record-type/inactive",
+        concept: "concept:record-type-inactive",
+        bind: { componentTypes: ["RecordType"], whereProperty: { key: "active", equals: false } },
+        interpretation: `{ids} is INACTIVE \u2014 it cannot be assigned to new records and is hidden from users' record-type selection, so it routes NONE of its page layout, picklist value set, or business process to new work until an admin re-activates it; only pre-existing records keep it. It must be EXCLUDED from "which record type will new records get", default-routing, and layout / picklist-scope reasoning about new work: treating a deactivated record type as a live routing option would misattribute a layout, restricted picklist, or business process that new records can never receive. This names the non-assignable structural fact from the record type's own active flag, NOT whether any existing records still carry it (record-level, not modeled offline), NOT which profiles once defaulted to or were granted it, and NOT why it was deactivated.`,
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["RecordType"]
+      },
+      {
+        id: "rule:integration/remote-site-protocol-security-disabled",
+        concept: "concept:remote-site-setting-protocol-security-disabled",
+        bind: { componentTypes: ["RemoteSiteSetting"], whereProperty: [{ key: "disableProtocolSecurity", equals: true }, { key: "isActive", equals: true }] },
+        interpretation: "{ids} is an ACTIVE remote site setting with protocol security DISABLED, so the platform's HTTPS-only guard is dropped for outbound callouts to its allowlisted host: it permits cleartext http callouts to that endpoint, and request URLs, headers, and bodies \u2014 potentially including session ids, tokens, or credentials in the request \u2014 can travel unencrypted, exposing them to network interception and tampering. This names the declared configuration posture from the setting's own flags, NOT whether any Apex, Flow, or LWC actually issues an insecure callout to this host at runtime (the offline vault does not correlate outbound-callout code to allowlist entries) and NOT a confirmed interception. Prefer a Named Credential over HTTPS; re-enable protocol security unless a cleartext endpoint is deliberately required.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["RemoteSiteSetting"]
+      },
+      {
+        id: "rule:code-quality/intentional-system-mode-dml",
+        concept: "concept:apex-intentional-system-mode-dml",
+        bind: { componentTypes: ["ApexClass"], whereProperty: { key: "qualityIssues", anyElement: { key: "rule", equals: "intentional-system-mode-dml" } } },
+        interpretation: "{ids} runs a DML operation with an EXPLICIT AccessLevel.SYSTEM_MODE argument (an intentional-system-mode-dml pattern) \u2014 so for that write it DELIBERATELY opts OUT of the running user's object CRUD and field-level security. Apex runs in system context and does NOT auto-enforce object CRUD or FLS on its DML; the AccessLevel.SYSTEM_MODE argument makes that non-enforcement a CONSCIOUS choice, so the write can create or change objects and fields regardless of the running user's object and field permissions. This is the DELIBERATE counterpart to an accidental missing-crud-check / missing-fls-check omission \u2014 the recognizer surfaces it for REVIEW, not as a defect, because a system-context write is often correct (a trusted service writing fields the running user cannot edit); if the running user's permissions SHOULD apply to this write, switch the argument to AccessLevel.USER_MODE. Record-level sharing is a SEPARATE access plane this does not read. This is HEURISTIC recognition from TOKENIZED Apex source \u2014 NOT a compiler AST \u2014 bound to the DML call site where the token appears; it names the DECLARED system-context bypass, not a proven authorization defect.",
+        maxConfidence: "heuristic",
+        absenceShaped: false,
+        dependsOnCoverage: ["ApexClass"]
+      },
+      {
+        id: "rule:omnistudio/dataraptor-field-security-unenforced",
+        concept: "concept:dataraptor-field-security-unenforced",
+        bind: { componentTypes: ["OmniDataTransform"], whereProperty: { key: "fieldLevelSecurityEnabled", equals: false } },
+        interpretation: "{ids} has 'Check Field Level Security' turned OFF \u2014 it reads and writes SObject fields WITHOUT enforcing the running user's field-level security, so it can load a field the user cannot Read into its output or overwrite a field the user cannot Edit. This is an over-permissive data-access surface (an FLS-bypass shape) that must be treated as a review candidate for data-exposure, NOT as an FLS-respecting transform. This names the declared configuration shape from the transform's own field-security toggle, NOT a proven leak: it does NOT establish which specific fields are over-exposed (depends on the field mappings and each user's actual FLS), who invokes it, or whether a wrapping Apex guard or restricted entry point neutralizes the gap at runtime.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["OmniDataTransform"]
+      },
+      {
+        id: "rule:field/classic-encrypted-text",
+        concept: "concept:field-classic-encrypted-text",
+        bind: { componentTypes: ["CustomField"], whereProperty: { key: "dataType", equals: "EncryptedText" } },
+        interpretation: `{ids} is a CLASSIC ENCRYPTED TEXT field \u2014 stored encrypted and MASKED in the UI, API, and reports for any user without the "View Encrypted Data" permission (most users see asterisks). Its type class is not filterable, sortable, or groupable, so it cannot appear in a SOQL WHERE / ORDER BY / GROUP BY, a list-view or report filter, and it cannot be an external id, a unique field, a default-value source, or a formula input. This is the LEGACY per-field protection, distinct from Shield Platform Encryption (not observable offline). Grounded from the field's declared data type; it names the masking and restriction posture, NOT which users can currently view the value and NOT whether the field holds sensitive data.`,
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["CustomField"]
+      },
+      {
+        id: "rule:field/autonumber-system-assigned-readonly",
+        concept: "concept:field-autonumber-system-assigned-readonly",
+        bind: { componentTypes: ["CustomField"], whereProperty: { key: "dataType", equals: "AutoNumber" } },
+        interpretation: "{ids} is an AUTO NUMBER field \u2014 system-assigned from a display format and sequence at insert, so it is READ-ONLY on every write path (UI, API, Apex, Flow, and data import cannot set it). It is null / unavailable in a before-save context (assigned during insert), is stored as a formatted STRING rather than a number, and changing its format renumbers only new records \u2014 existing values and any sequence gaps from failed inserts persist. Grounded from the field's declared data type; it names the system-assigned read-only provenance, NOT the current or next sequence value and NOT whether an integration tries to write it.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["CustomField"]
+      },
+      {
+        id: "rule:field/multiselect-picklist-storage",
+        concept: "concept:field-multiselect-picklist-storage-semantics",
+        bind: { componentTypes: ["CustomField"], whereProperty: { key: "dataType", equals: "MultiselectPicklist" } },
+        interpretation: "{ids} is a MULTI-SELECT PICKLIST \u2014 every selected value is stored in a SINGLE semicolon-delimited string, not as separate rows. In SOQL and reports it must be filtered with INCLUDES / EXCLUDES rather than = / != / IN (an equality filter matches only the exact full delimited combination), and formulas must use INCLUDES() to test membership; sorting or grouping orders by the raw delimited string. It cannot be the controlling field of a dependent picklist, nor an external id or unique field. Grounded from the field's declared data type; it names the storage and query semantics that follow from the type, NOT which values a record holds and NOT whether a specific query filters it incorrectly.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["CustomField"]
+      },
+      {
+        id: "rule:access/permission-set-license-scoped",
+        concept: "concept:permission-set-license-scoped",
+        bind: { componentTypes: ["PermissionSet"], whereProperty: { key: "license", isNull: false } },
+        interpretation: "{ids} is a LICENSE-SCOPED permission set \u2014 its `license` element binds it to a specific user license, so Salesforce only lets it be assigned to users who ALREADY hold that license. Every grant it carries (object CRUD, field-level security, Apex access, system permissions) is therefore UNREACHABLE by any user lacking the license, which NARROWS the eligible population before any individual grant even applies: no matter how strong its grants look, it cannot widen access for a user on the wrong license. This names the DECLARED assignability constraint of the container from the permission set's own `license` binding, NOT whether any specific user holds that license or is assigned this permission set (a live-plane assignment question the offline vault cannot answer), and NOT the strength or correctness of the grants inside it.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["PermissionSet"]
+      },
+      {
+        id: "rule:permission-set/session-based-dormant",
+        concept: "concept:session-based-permission-set-dormant",
+        bind: { componentTypes: ["PermissionSet"], whereProperty: { key: "hasActivationRequired", equals: true } },
+        interpretation: "{ids} is a SESSION-BASED permission set \u2014 its activation-required flag is TRUE \u2014 so it grants NONE of its permissions passively. Every grant it confers (object CRUD, field-level security, View All / Modify All, Apex-class access, custom-permission grants) stays DORMANT until the permission set is ACTIVATED for the current session, via Auth.SessionManagement or a launching flow, making all of them conditional-on-activation rather than standing. When reasoning about what a holder can do at rest, treat these grants as INACTIVE by default: assignment alone does not confer the access until a session activation occurs. This names the activation-gate structural fact from the set's own activation-required flag, NOT whether any given session actually activates it (session activation is a runtime event not observable offline) and NOT which users hold the set.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["PermissionSet"]
+      },
+      {
+        id: "rule:field/restricted-global-value-set",
+        concept: "concept:field-restricted-global-value-set",
+        bind: { edgeType: "usesValueSet", componentTypes: ["CustomField", "GlobalValueSet"], toWhereProperty: { key: "restricted", equals: true } },
+        interpretation: "{0} draws its values from restricted global value set {1} \u2014 a closed vocabulary. Only values defined in the shared set are valid, so admins cannot add ad-hoc values on this field and an integration or API write of an out-of-set value is rejected; changing the allowed values means editing the shared set, which ripples to every other field bound to it. This is the metadata-declared restriction, not proof of runtime enforcement or that no existing record already holds an out-of-set value.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["CustomField", "GlobalValueSet"]
+      },
+      {
+        id: "rule:field/picklist-has-retired-values",
+        concept: "concept:field-picklist-has-retired-values",
+        bind: { componentTypes: ["CustomField"], whereProperty: { key: "picklistValues", anyElement: { key: "isActive", equals: false } } },
+        interpretation: "{ids} is a picklist whose OWN local value set retains at least one INACTIVE (retired) value \u2014 a value kept in the field definition after an admin deactivated it. Existing records that already hold a retired value keep displaying and reporting it (the value stays readable), but it is NO LONGER offered in the picker and cannot be newly selected in the UI, so a retired value is a data-hygiene and migration signal, not a live option. This names the DECLARED presence of a retired value in the field's own value-set entries from metadata; it does NOT prove any record currently holds that value (a record-level count the offline vault cannot answer), does NOT cover GlobalValueSet-backed picklists (whose values live on the shared value set, not the field, and fail closed here because picklistValues is null), and does NOT prove any report, formula, default value, or automation still references the retired value.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["CustomField"]
+      },
+      {
+        id: "rule:approval-process/inactive-dead",
+        concept: "concept:approval-process-inactive-dead",
+        bind: { componentTypes: ["ApprovalProcess"], whereProperty: { key: "active", equals: false } },
+        interpretation: `{ids} is INACTIVE \u2014 DEAD approval automation that Salesforce never runs: no record can be submitted into it for approval, its entry criteria are never evaluated, and none of its initial-submission actions, per-step approver routing, final-approval / final-rejection actions, or record locks ever fire until an admin re-activates it. It must be EXCLUDED from "what happens when this record is submitted for approval" reasoning, from record-lock analysis (its finalApprovalRecordLock / finalRejectionRecordLock never take effect while inactive), and from automation-impact counts: counting a deactivated process overstates the automation load, while assuming its field-update actions or locks still run would misattribute a value change or a read-only freeze. This names the non-running structural fact from the process's own active flag, NOT whether a Flow-based approval has replaced it and NOT whether it WOULD admit a given record if activated (entry criteria remain unevaluated offline).`,
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["ApprovalProcess"]
+      },
+      {
+        id: "rule:escalation/time-deferred",
+        concept: "concept:escalation-rule-time-deferred",
+        bind: { componentTypes: ["EscalationRule"], whereProperty: { key: "active", equals: true } },
+        interpretation: "{ids} is an ACTIVE escalation rule \u2192 its escalation actions (reassign the record to a queue or user, and/or send a notification email) are NOT run during the record save. They are QUEUED to Salesforce's background escalation process and fire later, in a separate context, once the record has aged past the entry's declared minute offset without meeting the rule's exit criteria. The effect is DEFERRED and decoupled from the triggering edit: the reassignment/notification is not part of that save and cannot roll it back, and Salesforce silently drops the queued escalation if the record stops qualifying before the timer elapses. This names the deferred-action structure from the rule's active state; it does NOT evaluate the `minutesToEscalation` offset (carried on the rule's per-action edges, not the node), assert WHEN the escalation fires, whether the record still qualifies, or whether it succeeds.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["EscalationRule"]
+      },
+      {
+        id: "rule:automation/auto-response-rule-first-match-starvation",
+        concept: "concept:auto-response-rule-first-match-starvation",
+        bind: { edgeType: "sendsEmail", componentTypes: ["EmailTemplate"], aggregate: { edgeSource: "root-outgoing", countDistinctEndpoint: "to", firstMatchOrdinal: { ordinalEdgeProperty: "entryIndex", broadEntryWhere: [{ key: "criteriaItemCount", equals: 0 }, { key: "hasFormula", equals: false }] } } },
+        interpretation: "{0} is an auto-response rule evaluated top-down by entry order: entry {broadOrdinal} is a catch-all with no criteria or formula filter, so it matches every record and its auto-response email {1} is sent before any later, more specific entry is considered \u2014 {starvedCount} later entries are structurally unreachable because the first matching entry wins. This names the metadata ordering risk only; it does NOT prove which email a specific record would trigger at runtime, and only one auto-response rule per object is active at a time.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["AutoResponseRule", "EmailTemplate"]
+      },
+      {
+        id: "rule:record-type/business-process-binding",
+        concept: "concept:record-type-business-process-binding",
+        bind: { componentTypes: ["RecordType"], whereProperty: { key: "businessProcess", isNull: false } },
+        interpretation: "{ids} declares a BUSINESS PROCESS binding, so records created with this record type are scoped to that process's ordered subset of the master status picklist \u2014 it constrains the available stage picklist values to those the bound business process exposes (the Stage / Status / Solution-status values), NOT the object's full master picklist. On any write path \u2014 a Flow, an Apex assignment, an API create, or a data import \u2014 setting the stage / status field to a value the bound process does not include can be rejected. This names the DECLARED binding from the record type's own businessProcess reference, NOT the specific stage values the process exposes (those live on the BusinessProcess metadata and are org-specific), NOT which records currently carry this record type or their current stage (record-level, not modeled offline), and NOT whether the bound business process is itself active. A record type without a business process uses the object's full master picklist and has no such scoping.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["RecordType"]
+      },
+      {
+        id: "rule:code-quality/dynamic-reflective-surface",
+        concept: "concept:apex-dynamic-reflective-surface",
+        bind: { componentTypes: ["ApexClass"], whereProperty: { key: "qualityIssues", anyElement: { key: "rule", equals: "dynamic-apex" } } },
+        interpretation: "{ids} uses DYNAMIC or REFLECTIVE Apex \u2014 object, field, or type references built at RUNTIME (a dynamic-query string, a runtime schema describe, reflective type instantiation by name, or untyped deserialization) rather than as static literals. Such runtime-built references are INVISIBLE to static dependency analysis, so impact, usage / where-used, and dead-code results for this class MAY BE INCOMPLETE \u2014 a real dependency can be hidden behind the runtime construction. This is HEURISTIC token recognition, NOT a compiler AST: it can FLAG a dynamic construct whose reference is actually a safe constant, and can MISS one the tokenizer does not match. It does NOT prove the class is buggy, does NOT name WHICH objects or fields the dynamic code touches, and does NOT assert any specific hidden dependency \u2014 it flags the class as one whose static analysis is blind in spots; read the source to confirm.",
+        maxConfidence: "heuristic",
+        absenceShaped: false,
+        dependsOnCoverage: ["ApexClass"]
+      },
+      {
+        id: "rule:named-credential-merge-fields-injectable/header",
+        concept: "concept:named-credential-merge-fields-injectable",
+        bind: { componentTypes: ["NamedCredential"], whereProperty: [{ key: "allowMergeFieldsInHeader", equals: true }] },
+        interpretation: "{ids} is a named credential with `allowMergeFieldsInHeader` = true \u2014 the default guard against merge-field substitution in the outbound HTTP HEADER is LIFTED, so Apex callouts authenticating through this credential may substitute merge fields (including record- or user-derived values) into request headers. That makes it an outbound injection surface: if a substituted value is attacker-influenced it can alter or forge headers the upstream API trusts (header injection). This names the DECLARED configuration that ENABLES substitution; it does NOT prove that any Apex actually uses this credential, that any merge field carries UNTRUSTED input (the values may be static/trusted and the setting intentional), or that an injection occurs at runtime.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["NamedCredential"]
+      },
+      {
+        id: "rule:named-credential-merge-fields-injectable/body",
+        concept: "concept:named-credential-merge-fields-injectable",
+        bind: { componentTypes: ["NamedCredential"], whereProperty: [{ key: "allowMergeFieldsInBody", equals: true }] },
+        interpretation: "{ids} is a named credential with `allowMergeFieldsInBody` = true \u2014 the default guard against merge-field substitution in the outbound HTTP BODY is LIFTED, so Apex callouts authenticating through this credential may substitute merge fields (including record- or user-derived values) into the request payload. That makes it an outbound injection surface: if a substituted value is attacker-influenced it can forge or tamper with body fields the upstream API trusts (payload injection). This names the DECLARED configuration that ENABLES substitution; it does NOT prove that any Apex actually uses this credential, that any merge field carries UNTRUSTED input (the values may be static/trusted and the setting intentional), or that an injection occurs at runtime.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["NamedCredential"]
+      },
+      {
+        id: "rule:access-mechanism/connected-app-saml-sso-federation",
+        concept: "concept:connected-app-saml-sso-federation",
+        bind: { componentTypes: ["ConnectedApp"], whereProperty: { key: "authProtocol", in: ["saml", "both"] } },
+        interpretation: "{ids} is a connected app carrying a SAML config \u2014 a SAML SSO federation target that declares Salesforce as the SAML identity provider (IdP) and the app as an external service provider (SP) Salesforce will mint signed SAML assertions for, federating an authenticated user's identity into that third party for single sign-on. Its authProtocol is saml (SAML only) or both (SAML alongside an OAuth client), and the declared trust boundary \u2014 the Assertion Consumer Service (ACS) URL, the SP entity / audience, the expected issuer, and the NameID / subject format \u2014 defines who Salesforce federates identities out to. So it is an identity and trust surface worth reviewing. This names the DECLARED SAML SSO federation configuration, not a proven active login: the config is a static shape, not evidence that anyone authenticates through it or that the signing certificate is valid (the key material is never vaulted), WHO may use the app is a separate profile / permission-set access layer the config does not encode, and the federation may be intentional for a trusted downstream app.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["ConnectedApp"]
+      },
+      {
+        id: "rule:apex-fake-assertion/tautology-assertion",
+        concept: "concept:apex-fake-assertion-test",
+        bind: { componentTypes: ["ApexClass"], whereProperty: { key: "qualityIssues", anyElement: { key: "rule", equals: "fake-assertion" } } },
+        interpretation: "{ids} is an @IsTest class that contains a TAUTOLOGICAL or self-referential assertion \u2014 a System.assert(true, ...), a System.assertEquals(x, x), or a System.assertEquals(literal, sameLiteral) \u2014 whose operands are identical or always true, so it passes no matter how the code under test behaves. That assertion verifies nothing: it cannot fail on a wrong computed value, only on an uncaught exception, yet it still executes the code under test and so inflates the org code-coverage number while providing no real regression protection, and it can mask a genuine defect behind a green run. Assert on real field values, record counts, or thrown exceptions instead. This is HEURISTIC recognition from TOKENIZED Apex source \u2014 NOT a compiler AST: it flags the tautological call-site itself and does NOT prove the whole class is worthless (the class may carry other, meaningful assertions alongside the fake one). It names a test-quality review candidate, not proven coverage fraud.",
+        maxConfidence: "heuristic",
+        absenceShaped: false,
+        dependsOnCoverage: ["ApexClass"]
+      },
+      {
+        id: "rule:entitlement-process/inactive",
+        concept: "concept:entitlement-process-inactive",
+        bind: { componentTypes: ["EntitlementProcess"], whereProperty: { key: "active", equals: "false" } },
+        interpretation: '{ids} is an INACTIVE entitlement process \u2014 its `active` flag is FALSE, so Salesforce never applies it to a case and never starts any of its milestone timers until an admin re-activates it. It is DEAD SLA automation: no milestone clock runs, no business-hours SLA countdown begins, and no entitlement-driven escalation can fire from this version while it is inactive. It must be EXCLUDED from SLA / entitlement reasoning and from "what milestones apply on save" impact counts \u2014 treating a deactivated process as a live SLA guard would cry wolf about timers that cannot start, while assuming its milestones still run would falsely imply cases are being tracked. This is the DECLARED non-running fact read from the process\'s own active flag; it does NOT prove whether any specific case is currently on-track or breached (that is live per-record timer data the offline vault does not hold), NOT whether this version WOULD apply if activated (entry criteria remain unevaluated offline), and NOT whether another active version of the same process exists (version lineage is org-specific).',
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["EntitlementProcess"]
+      },
+      {
+        id: "rule:omnistudio/inactive-component-version",
+        concept: "concept:omnistudio-inactive-component-version",
+        bind: { componentTypes: ["OmniScript", "OmniIntegrationProcedure", "OmniUiCard"], whereProperty: { key: "isActive", equals: false } },
+        interpretation: "{ids} is an INACTIVE OmniStudio component version (an OmniScript, Integration Procedure, or FlexCard whose isActive flag is FALSE). Salesforce serves and dispatches only the ACTIVE version of an OmniStudio component, so this saved version does not execute at runtime: it is not rendered, invoked as an action, or embedded on a page until an admin activates it. It must be EXCLUDED from runtime-reachability, invocation-impact, and 'what actually runs' reasoning about OmniStudio \u2014 treating a deactivated version as live would overstate the runtime surface. This names the non-running structural fact from the component's own isActive flag, NOT whether another version of the same bundle is active and serving in its place (version lineage is org-specific), NOT whether anything still references this version by name, NOT what it would do if activated, and NOT why it was deactivated.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["OmniScript", "OmniIntegrationProcedure", "OmniUiCard"]
+      },
+      {
+        id: "rule:field/required-absent-from-all-layouts",
+        concept: "concept:required-field-absent-from-all-layouts",
+        bind: { componentTypes: ["CustomField"], whereProperty: [{ key: "required", equals: true }], antiJoin: { absentEdgeType: "usedInLayout", correlate: "sameTo", absentFromTypes: ["Layout"] } },
+        interpretation: "{ids} is UNIVERSALLY REQUIRED yet NO extracted page layout places it in any field-bearing region (the detail body, the Highlights Panel, or the mini layout) \u2014 so a user creating or editing a record through those layouts has no declared input for its value, which must instead come from a default value, a before-save automation, an Apex / API / data-import insert, or the platform's own runtime rendering of required fields on the create / edit form. Grounded from the field's declared required flag plus the ABSENCE of any usedInLayout edge from a Layout; under incomplete Layout coverage this absence is NOT asserted. This does NOT prove any save fails, and it does NOT see Lightning Dynamic Form (FlexiPage) placement \u2014 a field surfaced only through a Dynamic Form still matches here.",
+        maxConfidence: "declared",
+        absenceShaped: true,
+        dependsOnCoverage: ["CustomField", "Layout"]
+      },
+      {
+        id: "rule:omnistudio/dataraptor-errors-ignored",
+        concept: "concept:dataraptor-errors-ignored",
+        bind: { componentTypes: ["OmniDataTransform"], whereProperty: { key: "errorIgnored", equals: true } },
+        interpretation: "{ids} has 'Ignore Error' turned ON \u2014 when an individual record operation inside the transform fails, the failing item is skipped and the transform CONTINUES, returning a success-shaped result even though some reads or writes did not complete. This is an error-swallowing reliability shape: a partial or silent data-integrity gap can pass undetected unless the caller explicitly inspects the returned error collection. Treat it as a review candidate for silent data loss, NOT as a transform that surfaces its failures. It is distinct from the 'Rollback on Error' toggle \u2014 ignoring errors while not rolling back can leave partially applied data. This names the declared configuration shape from the transform's own toggle, NOT a proven failure: it does NOT establish that any record actually fails at runtime, that data was actually lost or left partial, or whether the invoking OmniScript, Integration Procedure, or Apex caller checks the error output and compensates.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["OmniDataTransform"]
+      },
+      {
+        id: "rule:object/deployment-status-in-development",
+        concept: "concept:object-deployment-status-in-development",
+        bind: { componentTypes: ["CustomObject"], whereProperty: { key: "deploymentStatus", equals: "InDevelopment" } },
+        interpretation: `{ids} has deployment status IN DEVELOPMENT (not Deployed) \u2014 so the object, its tab, its list views, and its fields are HIDDEN from every user who lacks the "Customize Application" administrative permission (in practice, all non-admin users), and the object is effectively unusable in production until an admin sets it to Deployed. It must be EXCLUDED from reasoning about which ordinary users can see or work with this object and its records. This names the DECLARED deployment-status posture from the object's own metadata; it does NOT prove whether any specific user holds Customize Application (an assignment question the offline vault cannot answer) and does NOT establish whether the object was intentionally left in development. Only Deployed objects belong in ordinary-user reachability surfaces.`,
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["CustomObject"]
+      },
+      {
+        id: "rule:object/autonumber-name-field",
+        concept: "concept:object-autonumber-name-field",
+        bind: { componentTypes: ["CustomObject"], whereProperty: { key: "nameFieldType", equals: "AutoNumber" } },
+        interpretation: "{ids} is a custom object whose NAME field is an AUTO NUMBER \u2014 every record's Name is SYSTEM-ASSIGNED from a display format and a sequence at insert, so the record name is READ-ONLY on every write path (UI, API, Apex, Flow, and data import cannot set it), is unavailable in a before-insert context (assigned during insert), and is stored and displayed as a formatted STRING rather than a number. Changing the display format renumbers only new records; existing names and any sequence gaps from failed inserts persist. This is grounded from the object's own declared name-field type; it names the system-assigned read-only provenance of the record NAME (DISTINCT from a custom field of type Auto Number), NOT the current or next sequence value (record-level data the offline vault cannot answer) and NOT whether any integration tries to set the name.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["CustomObject"]
+      },
+      {
+        id: "rule:global-value-set/has-inactive-value",
+        concept: "concept:global-value-set-has-inactive-value",
+        bind: { componentTypes: ["GlobalValueSet"], whereProperty: { key: "values", anyElement: { key: "isActive", equals: false } } },
+        interpretation: "{ids} is a GLOBAL (shared) value set that retains at least one INACTIVE (deactivated) value. Because this value set is SHARED, the retired value is removed from the picker on EVERY picklist field bound to the set at once \u2014 it is NO LONGER SELECTABLE for new records anywhere \u2014 yet existing records that already hold it keep displaying and reporting it (the value stays readable). Reactivating or removing the value ripples to every field bound to the set. This names the DECLARED presence of a deactivated entry in the shared value set's own metadata; it does NOT prove any record currently holds the value (a record-level count the offline vault cannot answer) and does NOT enumerate which fields bind this set (that is the fields' own usesValueSet edges).",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["GlobalValueSet"]
+      },
+      {
+        id: "rule:standard-value-set/has-inactive-value",
+        concept: "concept:standard-value-set-has-inactive-value",
+        bind: { componentTypes: ["StandardValueSet"], whereProperty: { key: "values", anyElement: { key: "active", equals: false } } },
+        interpretation: "{ids} is a STANDARD value set (the org-wide value list behind a standard picklist such as Industry, Lead Source, or Opportunity Stage) that retains at least one INACTIVE (deactivated) value. The retired value is NO LONGER SELECTABLE for new records on the standard field(s) that draw from this set, yet existing records that already hold it keep displaying and reporting it (the value stays readable). This names the DECLARED presence of a deactivated entry in the standard value set's own metadata; a standard field's binding to its value set is IMPLICIT (Salesforce wires it internally, so there is no edge and this does NOT name which fields are affected), it does NOT prove any record currently holds the value (record-level data the offline vault cannot answer), and it is DISTINCT from a custom field's own local retired value and from a shared global value set.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["StandardValueSet"]
+      },
+      {
+        id: "rule:apex-test-quality/hardcoded-sandbox-data",
+        concept: "concept:apex-test-hardcoded-sandbox-data",
+        bind: { componentTypes: ["ApexClass"], whereProperty: { key: "qualityIssues", anyElement: { key: "rule", equals: "hardcoded-sandbox-test-data" } } },
+        interpretation: "{ids} is an @IsTest class that hardcodes a SANDBOX-SPECIFIC literal \u2014 a username or URL carrying a sandbox marker (a `.sandbox` / `.dev` / `.uat` / `.fullcopy` suffix, a `--sandbox` My Domain segment, or a `sandbox.salesforce.com` host). An Apex test is expected to be org-agnostic and self-contained, building its own fixtures in @TestSetup or a test-data factory; a sandbox-specific literal breaks that, so the test may pass in the sandbox it was written against and then FAIL, or exercise the wrong data, when the code is promoted to production or run in another org \u2014 and because it is a test that failure surfaces only at deploy or run time. Move the value into a Custom Metadata Type or Custom Setting record, or generate it in @TestSetup. This is HEURISTIC recognition from TOKENIZED Apex source \u2014 NOT a compiler AST: it flags the sandbox-marked literal itself and can FLAG a deliberately inert string or MISS a value assembled at runtime. It names a test-portability review candidate, not a proven test failure.",
+        maxConfidence: "heuristic",
+        absenceShaped: false,
+        dependsOnCoverage: ["ApexClass"]
+      },
+      {
+        id: "rule:restriction-rule/inactive",
+        concept: "concept:restriction-rule-inactive",
+        bind: { componentTypes: ["RestrictionRule"], whereProperty: { key: "active", equals: "false" } },
+        interpretation: '{ids} is an INACTIVE restriction rule (its `active` flag is false) \u2014 while inactive it enforces NO narrowing, so the records it would otherwise HIDE stay fully visible to the users it targets under the org-wide default, sharing rules, the role hierarchy, and manual / Apex shares. It must be EXCLUDED from "what can this user NOT see" reasoning and from any conclusion that an object is narrowed on its account: a restriction rule is the sole subtractive sharing mechanism, and a deactivated one subtracts nothing until an admin re-activates it. This is grounded from the rule\'s own `active` flag; it names the non-enforcing STRUCTURAL fact, NOT whether the rule WOULD narrow a specific record if activated (its recordFilter / userCriteria remain unevaluated offline) and NOT why it was deactivated. Only active restriction rules narrow record access.',
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["RestrictionRule"]
+      },
+      {
+        id: "rule:approval-process/pending-lock-editable-by-approver",
+        concept: "concept:approval-process-pending-lock-editability",
+        bind: { componentTypes: ["ApprovalProcess"], whereProperty: { key: "recordEditability", equals: "AdminOrCurrentApprover" } },
+        interpretation: '{ids} declares `recordEditability` = AdminOrCurrentApprover \u2014 while a record is PENDING in this approval process it is AUTOMATICALLY LOCKED, and this setting WIDENS who may edit that locked record to include the CURRENTLY-ASSIGNED APPROVER, not only administrators and "Modify All"/"Modify All Data" holders. So the approver evaluating the request can also modify the very record awaiting their decision (an access and audit surface), whereas the default AdminOnly posture bars even the approver from editing while it is pending. This is the DECLARED pending-lock editability from the process\'s own recordEditability flag; it does NOT assert whether any specific record is currently pending or locked (record-level runtime state the offline vault does not hold), WHO the assigned approver is on a given record, or the separate final-approval / final-rejection lock behavior. An approval process set to AdminOnly, or that declares no recordEditability, contributes no approver-edit widening.',
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["ApprovalProcess"]
+      },
+      {
+        id: "rule:approval-process/recall-enabled",
+        concept: "concept:approval-process-recall-unlocks-record",
+        bind: { componentTypes: ["ApprovalProcess"], whereProperty: { key: "allowRecall", equals: true } },
+        interpretation: "{ids} declares `allowRecall` = true \u2014 this approval process lets the ORIGINAL SUBMITTER RECALL (withdraw) a still-pending approval request. A recall UNLOCKS the record (it leaves the locked/pending state) and fires the process's recall actions \u2014 the field updates, email alerts, tasks, or outbound messages configured on the recall hook \u2014 so a record can exit the pending approval WITHOUT any approver's decision, purely by submitter action, and that exit runs its own automation. This matters for \"why did this record unlock, or why did this field change while it was in approval?\" reasoning. This names the DECLARED recall capability from the process's own allowRecall flag; it does NOT assert that any specific record was recalled, WHO may submit or recall it, or whether the recall actions succeed. An approval process with allowRecall false permits no submitter recall \u2014 only an approver's action moves a pending record forward.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["ApprovalProcess"]
+      },
+      {
+        id: "rule:integration/auth-provider-registration-handler",
+        concept: "concept:auth-provider-registration-handler-apex-hook",
+        bind: { componentTypes: ["AuthProvider"], whereProperty: { key: "registrationHandler", isNull: false } },
+        interpretation: "{ids} is an auth provider with a REGISTRATION HANDLER \u2014 an Apex class Salesforce invokes in SYSTEM context on every SSO / social login through this provider to CREATE or UPDATE the authenticating user's User record (just-in-time provisioning), running under the declared executionUser identity rather than the logging-in person. It is a privileged, hidden entry point that can insert Users, assign profiles, and set fields outside the normal permission path. This names the DECLARED handler binding only \u2014 NOT proof that anyone has logged in through this provider, NOT what the handler code does (a separate ApexClass the offline vault does not execute), and NOT that the class still compiles.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["AuthProvider"]
+      },
+      {
+        id: "rule:integration/platform-event-channel-member-filter",
+        concept: "concept:platform-event-channel-member-filtered-stream",
+        bind: { componentTypes: ["PlatformEventChannelMember"], whereProperty: { key: "filterExpression", isNull: false } },
+        interpretation: "{ids} is a platform event / CDC channel member with a declared FILTER EXPRESSION \u2014 it narrows the channel to only the change events whose fields satisfy that expression, so subscribers see a NARROWED subset of the object's changes and every non-matching change is withheld from this stream. Integrations that assume the full change feed arrives can miss filtered-out records. This is the DECLARED filter text only \u2014 NOT runtime evaluation of which records actually pass (that needs record-level data the offline vault lacks), and NOT the channel's retention / replay / ordering guarantees, which are a separate async concern.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["PlatformEventChannelMember"]
+      },
+      {
+        id: "rule:integration/external-service-registration-incomplete",
+        concept: "concept:external-service-registration-incomplete",
+        bind: { componentTypes: ["ExternalService"], whereProperty: { key: "status", notIn: ["Complete"] } },
+        interpretation: "{ids} is an external service registration whose status is NOT Complete \u2014 its OpenAPI schema did not finish importing into invocable operations, so its generated actions are UNAVAILABLE and any Flow, Apex, or OmniStudio step that invokes an operation from this registration cannot resolve it and fails. This names the DECLARED status only \u2014 NOT why the import stalled (fetch / auth / parse errors are not captured offline) and NOT whether any component actually calls an operation from this service. Only a Complete registration exposes callable operations.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["ExternalService"]
+      },
+      {
+        id: "rule:integration/named-credential-per-user-principal",
+        concept: "concept:named-credential-per-user-principal",
+        bind: { componentTypes: ["NamedCredential"], whereProperty: { key: "principalType", equals: "PerUser" } },
+        interpretation: "{ids} is a named credential with a PER-USER principal type \u2014 it carries no shared org-wide identity; each callout authenticates under the running user's own per-user external credential, which every user must configure individually. The same callout authenticates as a different identity per user and FAILS for any user who has not set up their personal credential, and the external system attributes calls to distinct per-user identities rather than one service account. This names the DECLARED per-user posture only \u2014 NOT which users have configured their credential (per-user runtime state the offline vault does not hold) and NOT whether any Apex actually calls through this credential.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["NamedCredential"]
+      },
+      {
+        id: "rule:omnistudio/test-procedure-scope",
+        concept: "concept:omnistudio-test-procedure-scope",
+        bind: { componentTypes: ["OmniScript", "OmniIntegrationProcedure"], whereProperty: { key: "isTestProcedure", equals: true } },
+        interpretation: "{ids} is flagged as an OmniStudio TEST PROCEDURE (isTestProcedure = true) \u2014 a development test harness whose purpose is to exercise and validate another OmniScript or Integration Procedure, NOT a production user-facing flow. It is not part of the normal production runtime surface: it is invoked to test a target component, not served to end users or dispatched as production automation. EXCLUDE it from 'what actually runs in production', runtime-reachability, and invocation-impact reasoning, and treat it as a likely cleanup candidate in a production org. This names the declared test-procedure flag from the component's own metadata, NOT whether the test currently passes, which component it targets, whether it has ever been run, or whether it is also active (liveness is the separate isActive axis).",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["OmniScript", "OmniIntegrationProcedure"]
+      },
+      {
+        id: "rule:omnistudio/dataraptor-load-fires-assignment-rules",
+        concept: "concept:dataraptor-load-fires-assignment-rules",
+        bind: { componentTypes: ["OmniDataTransform"], whereProperty: { key: "assignmentRulesUsed", equals: true } },
+        interpretation: "{ids} is a DataRaptor with 'Assignment Rules Used' turned ON \u2014 when it writes Lead or Case records (a DataRaptor Load), the insert or update runs with the assignment-rule header set, so the object's ACTIVE assignment rules evaluate on the written records and can reassign record ownership and send assignment email notifications as a SIDE EFFECT of the transform's save. A reader tracing what this transform does must account for that downstream assignment automation, not just the mapped field writes. This names the declared assignment-rules toggle from the transform's own metadata; it does NOT prove the target object has any active assignment rule, that any record is actually reassigned or notified, or that the transform writes Lead / Case at all (only Lead and Case support assignment rules) \u2014 the runtime outcome depends on org data the offline vault does not hold.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["OmniDataTransform"]
+      },
+      {
+        id: "rule:omnistudio/metadata-cache-disabled",
+        concept: "concept:omnistudio-metadata-cache-disabled",
+        bind: { componentTypes: ["OmniScript", "OmniIntegrationProcedure"], whereProperty: { key: "isMetadataCacheDisabled", equals: true } },
+        interpretation: "{ids} has metadata caching DISABLED (isMetadataCacheDisabled = true) \u2014 the OmniStudio runtime does not cache this component's compiled definition, so it re-reads and recompiles the definition metadata on every load or invocation instead of serving a cached copy. That adds per-request latency, and for an Integration Procedure invoked at volume it repeats that compile work on each call, increasing CPU and metadata-query pressure. Disabling the metadata cache is a documented development / debugging aid that is not meant to ship to a production org. This names the declared cache-disabled configuration flag from the component's own metadata, NOT a measured regression: it does NOT prove any specific slowdown, timeout, or limit breach at runtime, only the disabled-cache posture.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["OmniScript", "OmniIntegrationProcedure"]
+      },
+      {
+        id: "rule:static-resource/public-cache-control",
+        concept: "concept:static-resource-public-cache-control-exposure",
+        bind: { componentTypes: ["StaticResource"], whereProperty: { key: "cacheControl", equals: "Public" } },
+        interpretation: "{ids} is a static resource whose cacheControl is Public \u2014 the platform caches it in a SHARED, cross-user cache and it can be served to UNAUTHENTICATED guest users through a Site or Experience Cloud resource URL, so its bytes are effectively world-readable to anyone who can reach that URL and must never hold secrets (API keys, tokens, credentials). A Private cacheControl instead scopes caching to the requesting user own session. This names the DECLARED cache-control posture from the resource own metadata; it does NOT prove the resource actually contains sensitive data, that any public page currently references it, or that its URL has been shared \u2014 only that the Public setting makes shared caching and guest exposure possible.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["StaticResource"]
+      },
+      {
+        id: "rule:custom-metadata-record/protected-namespace-scoped",
+        concept: "concept:custom-metadata-record-protected-namespace-scoped",
+        bind: { componentTypes: ["CustomMetadataRecord"], whereProperty: { key: "protected", equals: true } },
+        interpretation: "{ids} is a PROTECTED custom metadata record \u2014 protected metadata is accessible ONLY to Apex, Flow, and formula code that runs in the SAME namespace that owns it. When this type is packaged and installed in a subscriber org, the subscriber own Apex and SOQL CANNOT read the record, and its protected field values come back masked rather than as real content (which is why protected records are the standard home for package secrets); an unprotected record is readable by any code in the org. This names the DECLARED protection flag from the record own metadata \u2014 a packaging-scoped ACCESS boundary \u2014 NOT the record actual field values (which may be masked and unreadable offline) and NOT whether this org is the owning namespace or a subscriber.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["CustomMetadataRecord"]
+      },
+      {
+        id: "rule:email-template/unavailable-hidden",
+        concept: "concept:email-template-unavailable-hidden",
+        bind: { componentTypes: ["EmailTemplate"], whereProperty: { key: "available", equals: false } },
+        interpretation: "{ids} has its Available For Use flag set to false \u2014 the template is NOT offered in the email-template picker, so users cannot select it when composing or sending an email through the UI. It is effectively hidden and dormant for manual use and should be EXCLUDED from which-templates-can-a-user-choose surfaces. This names the DECLARED availability flag from the template own metadata; it does NOT prove the template is unused \u2014 automation, email alerts, or Apex that reference it directly by id can still send it \u2014 and it says nothing about the template body or merge fields.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["EmailTemplate"]
+      },
+      {
+        id: "rule:group/role-subordinates-transitive-membership",
+        concept: "concept:group-role-subordinates-transitive-membership",
+        bind: { edgeType: "hasMember", componentTypes: ["Group", "Role"], edgeWhereProperty: { key: "inheritance", equals: "subordinates" } },
+        interpretation: "Transitive group membership among {ids}: this public group membership includes a role AND its SUBORDINATES, so the group transitively contains the named role plus EVERY role beneath it in the role hierarchy \u2014 the whole subtree is a member. Any access granted to this group \u2014 an owner- or criteria-based sharing rule shared to it, queue ownership, folder access, or list-view sharing \u2014 therefore reaches the entire role subtree, not just a single role. This is the DECLARED membership cascade on the group own member row; it names the ROLES the group pulls in, NOT the individual users occupying them (an assignment question the offline vault does not answer) and NOT any specific record grant.",
+        maxConfidence: "declared",
+        absenceShaped: false,
+        dependsOnCoverage: ["Group", "Role"]
       }
     ]);
   }
@@ -83723,7 +84611,7 @@ var init_refusal_gates = __esm({
 });
 
 // ../mcp/dist/src/funnel-utterances.js
-var FUNNEL_UTTERANCES;
+var FUNNEL_UTTERANCES, INTERPRET_CONCEPT_CARDS;
 var init_funnel_utterances = __esm({
   "../mcp/dist/src/funnel-utterances.js"() {
     "use strict";
@@ -86031,7 +86919,21 @@ var init_funnel_utterances = __esm({
         "does a broad assignment rule entry with no criteria appear before more specific queue routing entries?",
         "assignment rule first-match ordering \u2014 can an early catch-all entry make later entries unreachable?",
         "when an assignment rule has a catch-all entry first, are later specific entries structurally starved by first-match evaluation?",
-        "does entry order on this assignment rule mean a no-criteria row wins before targeted queue rules below it?"
+        "does entry order on this assignment rule mean a no-criteria row wins before targeted queue rules below it?",
+        // ARC-2 concept-expansion — validation-rule-inactive. A deactivated validation
+        // rule never enforces its constraint and must be excluded from save-failure
+        // reasoning. Anchored on the rule-type noun so it does not misbind to
+        // inactive-USER tools. Generic placeholders / standard objects only.
+        "is this validation rule inactive, so it never blocks a save or shows its error message?",
+        "this validation rule is deactivated \u2014 does it still enforce its constraint or is it dead?",
+        "does an inactive validation rule still run in the save order, or can it never fire?",
+        "which validation rules are turned off and therefore never enforce their error condition?",
+        // ARC-2 concept-expansion — workflow-rule-inactive-dead. An inactive workflow
+        // rule never runs its field updates / alerts — dead legacy automation.
+        "is this workflow rule inactive, so its field updates and email alerts never fire?",
+        "this workflow rule is deactivated \u2014 is it dead legacy automation that no longer runs on save?",
+        "does an inactive workflow rule still perform field updates, or has it stopped firing entirely?",
+        "which workflow rules are inactive and therefore never run their actions?"
       ],
       "sfi.find_field_anywhere": [
         "find all objects that have a field called External_Id__c",
@@ -86367,6 +87269,349 @@ var init_funnel_utterances = __esm({
         "interpret this CODE_UNIT_STARTED / LIMIT_USAGE debug log"
       ]
     };
+    INTERPRET_CONCEPT_CARDS = {
+      "concept:field-longtext-richtext-not-filterable": [
+        "Can I filter a report on the long text area field on Account?",
+        "Why can't I sort a list view by a rich text field?",
+        "Is this long text area field usable in a SOQL WHERE clause?",
+        "Can I make a long text area field an external id or unique?",
+        "Why won't Salesforce let me group by a description field?"
+      ],
+      "concept:duplicate-rule-bypass-sharing-match": [
+        "Do any of our duplicate rules match against records the running user can't see?",
+        "Which duplicate rules bypass sharing when they check for duplicates?",
+        "Is there a duplicate rule that runs its duplicate matching in system context?",
+        "Could a duplicate rule block my save because of a duplicate I don't have access to?",
+        "What does bypass sharing rules mean for duplicate matching on Account?",
+        "Show me duplicate rules that ignore the sharing model during matching"
+      ],
+      "concept:duplicate-rule-references-inactive-matching-rule": [
+        "Why is my duplicate rule not catching duplicates on Account?",
+        "Why do duplicate records still save even though I have a duplicate rule enabled?",
+        "Is my duplicate rule actually doing anything if its matching rule is inactive?",
+        "What happens when a duplicate rule points at a matching rule that isn't active?",
+        "Does deactivating a matching rule silently break duplicate detection?",
+        "My duplicate rule looks active but duplicates keep getting created \u2014 why?"
+      ],
+      "concept:approval-process-final-lock-record-readonly": [
+        "Which approval processes lock the record after final approval?",
+        "Does getting this record approved make it read-only?",
+        "Why does automation fail to update a record after it's been approved?",
+        "What leaves a record locked once an approval process finishes?",
+        "Will a rejected record stay locked from further edits until someone unlocks it?",
+        "Does this approval process leave the record read-only after it completes?"
+      ],
+      "concept:record-type-inactive": [
+        "What does it mean that this record type is inactive?",
+        "If a record type is deactivated, can new records still be assigned to it?",
+        "Does an inactive record type still route a page layout or business process to new records?",
+        "This record type has its active flag set to false \u2014 what are the implications?",
+        "Can users pick a deactivated record type when creating a record?",
+        "What happens to a business process when its record type is inactive?"
+      ],
+      "concept:remote-site-setting-protocol-security-disabled": [
+        "does this remote site setting allow insecure http callouts?",
+        "which remote site settings have protocol security disabled?",
+        "is this remote site setting insecure?",
+        "can this org make cleartext http callouts to an allowlisted host?",
+        "why would a remote site setting drop the https-only guard on outbound callouts?",
+        "are any of our outbound allowlist entries not requiring https?"
+      ],
+      "concept:apex-intentional-system-mode-dml": [
+        "Which Apex classes deliberately run DML in system mode and skip the running user's CRUD and field-level security?",
+        "What does it imply when a class writes records with an explicit AccessLevel.SYSTEM_MODE argument?",
+        "Is there Apex that intentionally opts out of object and field security for a write?",
+        "Which classes do a conscious system-context DML bypass rather than an accidental missing check?",
+        "Does running DML in SYSTEM_MODE mean field-level security is not enforced for that write?"
+      ],
+      "concept:dataraptor-field-security-unenforced": [
+        "Does this DataRaptor bypass field-level security when it reads Account fields?",
+        "Which DataRaptors have Check Field Level Security turned off?",
+        "Is this OmniStudio data transform a data-exposure risk for fields the user cannot see?",
+        "Can this DataRaptor overwrite fields the running user has no edit access to?",
+        "Show me DataRaptors that read or write SObject fields without enforcing FLS",
+        "Does turning off field-level security on this DataRaptor over-expose Contact data?"
+      ],
+      "concept:field-classic-encrypted-text": [
+        "Is this an encrypted text field, and who can actually see its value?",
+        "why is this field showing asterisks to most users?",
+        "can I filter or report on a classic encrypted text field?",
+        "is this encrypted field usable as an external id or in a formula?",
+        "does this masked field hide its value unless you have View Encrypted Data?"
+      ],
+      "concept:field-autonumber-system-assigned-readonly": [
+        "Can I set this auto number field from the API or Apex?",
+        "why can't my integration write to this auto-number field?",
+        "is this auto number field available in a before-save trigger?",
+        "what does it mean that this field is an Auto Number?",
+        "does reformatting an auto number field renumber existing records?"
+      ],
+      "concept:field-multiselect-picklist-storage-semantics": [
+        "how is a multi-select picklist stored, and how do I query it?",
+        "why does my equals filter not match this multi-select picklist?",
+        "can a multi-select picklist be the controlling field of a dependent picklist?",
+        "do I need INCLUDES to filter a multiselect picklist in SOQL?",
+        "what are the reporting limitations of a multi-select picklist field?"
+      ],
+      "concept:permission-set-license-scoped": [
+        "Which permission sets are bound to a specific user license?",
+        "Is this permission set restricted to users who hold a particular license?",
+        "What does it mean that a permission set has a license set on it?",
+        "Can a permission set that is tied to a license be assigned to any user?",
+        "Which permission sets can only be assigned to users on a matching license?",
+        "Does binding a permission set to a user license limit who can receive its grants?"
+      ],
+      "concept:session-based-permission-set-dormant": [
+        "Which permission sets require session activation before their grants apply?",
+        "Is this permission set session-based, so its access stays dormant until activated?",
+        "Does this permission set grant its object and field access passively or only after session activation?",
+        "What permission sets confer no standing access because they are activation-gated?",
+        "Are the CRUD and Apex-class grants on this permission set conditional on session activation?"
+      ],
+      "concept:field-restricted-global-value-set": [
+        "Is this picklist field restricted to a fixed set of values?",
+        "Can an admin add new values to this picklist directly on the field?",
+        "Does the Status picklist on Case use a locked-down global value set?",
+        "Will an API write be rejected if it sends a value not in this picklist?",
+        "Which fields share this global value set and can their values drift?",
+        "Is this picklist a closed vocabulary or can users enter free-form values?"
+      ],
+      "concept:field-picklist-has-retired-values": [
+        "Which picklist fields still have inactive values?",
+        "Does the Account Industry picklist have any retired values?",
+        "Show me picklists with old values that are no longer selectable",
+        "Are there deactivated picklist values left on Opportunity fields?",
+        "Find fields that kept legacy picklist entries after cleanup",
+        "List picklists carrying retired values from a past migration"
+      ],
+      "concept:approval-process-inactive-dead": [
+        "Is this approval process still active?",
+        "Which approval processes on Account are inactive?",
+        "If this approval process is deactivated, does submitting a record for approval do anything?",
+        "Show me the dead approval processes in this org",
+        "Does this inactive approval process still lock records on approval?",
+        "Will its final-approval field update run while the process is off?"
+      ],
+      "concept:escalation-rule-time-deferred": [
+        "Do my escalation rules run during the save or later?",
+        "When does a case escalation actually fire?",
+        "Are escalation actions synchronous with the record update?",
+        "Does this escalation rule reassign the case immediately or on a timer?",
+        "Is case escalation part of the save transaction?",
+        "What happens after a record ages past its escalation threshold?"
+      ],
+      "concept:auto-response-rule-first-match-starvation": [
+        "Show me the auto-response rules for Lead",
+        "Why did this case get the wrong auto-response email?",
+        "Do any auto-response rule entries never fire?",
+        "Is there a catch-all auto-response entry starving later ones?",
+        "Which auto-response rule entries are unreachable on Case?",
+        "Are my auto-response rule entries in the right order?"
+      ],
+      "concept:record-type-business-process-binding": [
+        "Which record types are tied to a specific sales process?",
+        "Does this record type limit which stages are available on an opportunity?",
+        "What business process is bound to the Enterprise record type?",
+        "Why can't I pick this status value on a case with this record type?",
+        "Show me record types that restrict the status picklist to a business process",
+        "Which record types scope the stage picklist to a subset of values?"
+      ],
+      "concept:apex-dynamic-reflective-surface": [
+        "Does this Apex class use dynamic SOQL or reflection that static analysis can't see?",
+        "Which classes build queries or field references at runtime?",
+        "Is the impact analysis for this class complete, or are there reflective blind spots?",
+        "Show me Apex that uses dynamic queries, describes, or type reflection",
+        "What classes could have hidden dependencies my usage results miss?",
+        "Are there dynamic-Apex constructs that make dead-code findings unreliable here?"
+      ],
+      "concept:named-credential-merge-fields-injectable": [
+        "which named credentials allow merge fields in the HTTP header or body",
+        "are any of our named credentials an injection surface for outbound callouts",
+        "show me named credentials that lifted the default merge-field guard",
+        "list named credentials configured with allowMergeFieldsInHeader or allowMergeFieldsInBody",
+        "which outbound credentials let Apex substitute merge fields into the request"
+      ],
+      "concept:connected-app-saml-sso-federation": [
+        "Which connected apps are set up as SAML single sign-on service providers?",
+        "Is this connected app a SAML SSO federation target with Salesforce as the identity provider?",
+        "Which connected apps will Salesforce mint SAML assertions for?",
+        "Does this connected app federate a user's identity out to a third party over SAML?",
+        "What connected apps declare a SAML config instead of, or alongside, OAuth?",
+        "Which connected apps act as SAML service providers we should review as an identity surface?"
+      ],
+      "concept:apex-fake-assertion-test": [
+        "Which test classes have fake or tautological assertions?",
+        "Show me tests that assert true or assert a value against itself",
+        "Find Apex tests that pass no matter what the code does",
+        "Are any of my test classes inflating coverage without verifying anything?",
+        "Which tests use System.assertEquals with identical operands?",
+        "List test classes flagged for fake-assertion smells"
+      ],
+      "concept:entitlement-process-inactive": [
+        "Which entitlement processes are inactive?",
+        "Is this SLA / entitlement process actually live or disabled?",
+        "Does this entitlement process still start its milestone timers?",
+        "Are any of our SLA processes dead or deactivated?",
+        "Should I count this entitlement process when reasoning about milestones on Cases?",
+        "Why aren't milestones tracking on my Cases?"
+      ],
+      "concept:omnistudio-inactive-component-version": [
+        "Which OmniScripts are inactive?",
+        "Do we have any FlexCards that aren't active?",
+        "Is this Integration Procedure live or just a saved draft?",
+        "Which OmniStudio components won't run at runtime?",
+        "Show me the dormant OmniScript versions in this org",
+        "Are any of our OmniStudio components deactivated?"
+      ],
+      "concept:required-field-absent-from-all-layouts": [
+        "Which required fields aren't on any page layout?",
+        "Is this required field missing from every layout?",
+        "Do we have required fields with no UI data-entry surface?",
+        "Which required Account fields can't be entered through the UI?",
+        "Show me required fields absent from all page layouts",
+        "Are there any universally required fields not placed on a layout?"
+      ],
+      "concept:dataraptor-errors-ignored": [
+        "Which DataRaptors ignore errors instead of failing?",
+        "Are any of our DataRaptor loads swallowing record failures silently?",
+        "Show me OmniStudio data transforms configured to continue on error",
+        "Which DataRaptors could be losing data without reporting it?",
+        "Do any DataRaptors have 'Ignore Error' turned on?",
+        "Find data transforms that don't surface their write failures"
+      ],
+      "concept:object-deployment-status-in-development": [
+        "Which custom objects are still In Development instead of Deployed?",
+        "Is this object's deployment status hiding it from users without Customize Application?",
+        "What does an In Development deployment status mean for who can use the object?",
+        "Show me objects whose deployment status is not Deployed yet."
+      ],
+      "concept:object-autonumber-name-field": [
+        "Which custom objects use an Auto Number for their Name field?",
+        "Is this object's record Name auto-generated or entered by users?",
+        "Can I set the Name on insert for this object, or is it auto-numbered?",
+        "Does this object's name field auto-assign a formatted sequence?",
+        "What objects have a system-assigned Auto Number record name?"
+      ],
+      "concept:global-value-set-has-inactive-value": [
+        "Does this global value set have any deactivated values?",
+        "Which shared value sets retain retired values across every field that uses them?",
+        "Is there an inactive value in this global picklist value set?",
+        "What global value sets carry values that are no longer selectable?",
+        "Are any entries in this shared value set deactivated but still on records?"
+      ],
+      "concept:standard-value-set-has-inactive-value": [
+        "Does the Lead Source standard value set have retired values?",
+        "Which standard picklists have deactivated values org-wide?",
+        "Are any Opportunity Stage standard values inactive but still on records?",
+        "Show me standard value sets that retain deactivated entries.",
+        "Is there an inactive value in this standard picklist value set?"
+      ],
+      "concept:apex-test-hardcoded-sandbox-data": [
+        "Which test classes have sandbox-specific data baked into them?",
+        "Do any of my Apex tests hardcode a sandbox URL or org suffix?",
+        "Show me tests that won't run in production because of hardcoded sandbox values",
+        "Are there test classes coupled to a specific sandbox environment?",
+        "Which tests reference .sandbox or --sandbox literals instead of using @TestSetup?"
+      ],
+      "concept:restriction-rule-inactive": [
+        "Is this restriction rule inactive \u2014 does it still hide any records or is its narrowing switched off?",
+        "does a deactivated restriction rule leave records fully visible under normal sharing?",
+        "this restriction rule has active false \u2014 does it enforce any narrowing until it is reactivated?",
+        "should an inactive restriction rule be excluded from what a user cannot see on Case?",
+        "if a restriction rule is turned off, do the records it would hide become visible again?"
+      ],
+      "concept:approval-process-pending-lock-editability": [
+        "Can the approver edit a record while it's pending their approval?",
+        "Which approval processes let the assigned approver modify the locked record during approval?",
+        "Is a submitted record editable by the current approver, or admin-only, while it awaits approval?",
+        "Does this approval process widen pending-record editability to the approver?",
+        "Who can change a record that's locked in an approval process before a decision is made?"
+      ],
+      "concept:approval-process-recall-unlocks-record": [
+        "Can a submitter recall a pending approval request on this process?",
+        "Which approval processes allow recall, and what actions fire when a request is recalled?",
+        "What happens when someone recalls an approval \u2014 does the record unlock?",
+        "Does recalling an approval trigger field updates or email alerts?",
+        "Can a record leave an approval process without an approver's decision?"
+      ],
+      "concept:auth-provider-registration-handler-apex-hook": [
+        "Which auth providers run a registration handler during SSO login?",
+        "Does the Corporate SSO auth provider provision users just-in-time?",
+        "What Apex runs when someone signs in through our SAML provider?",
+        "Which SSO providers can create User records automatically?",
+        "Show me auth providers with a JIT user-provisioning handler."
+      ],
+      "concept:platform-event-channel-member-filtered-stream": [
+        "Which platform event channel members have a filter expression?",
+        "Is the Account CDC channel filtered or does it publish every change?",
+        "What filter narrows the change events on this channel member?",
+        "Do any change data capture subscribers only get a subset of records?",
+        "Which channel members withhold non-matching changes from subscribers?"
+      ],
+      "concept:external-service-registration-incomplete": [
+        "Which external service registrations are not fully imported?",
+        "Is the Weather API external service registration complete?",
+        "Which registered external services have unavailable generated actions?",
+        "Do any external service registrations have a broken OpenAPI schema import?",
+        "Show me external services whose status isn't Complete."
+      ],
+      "concept:named-credential-per-user-principal": [
+        "Which named credentials use per-user authentication?",
+        "Does the ERP named credential require each user to set up their own login?",
+        "Which callouts authenticate as the running user instead of a service account?",
+        "Are any named credentials per-user rather than a shared named principal?",
+        "Which named credentials will fail for users who haven't configured credentials?"
+      ],
+      "concept:omnistudio-test-procedure-scope": [
+        "Which OmniScripts are flagged as test procedures?",
+        "Do we have any Integration Procedure test harnesses left in production?",
+        "Is this OmniScript a test procedure or a real user-facing flow?",
+        "List the OmniStudio components marked isTestProcedure.",
+        "Which OmniStudio test procedures are cleanup candidates in this org?"
+      ],
+      "concept:dataraptor-load-fires-assignment-rules": [
+        "Which DataRaptors run assignment rules when they write?",
+        "Does this DataRaptor Load trigger Case assignment rules?",
+        "What OmniStudio transforms reassign record owners on save?",
+        "Which DataRaptors have 'Assignment Rules Used' turned on?",
+        "Will loading Leads through this DataRaptor fire assignment rules?"
+      ],
+      "concept:omnistudio-metadata-cache-disabled": [
+        "Which OmniScripts have metadata caching disabled?",
+        "Are any Integration Procedures running with the metadata cache turned off?",
+        "Does this OmniScript recompile its definition on every load?",
+        "List the OmniStudio components with isMetadataCacheDisabled set.",
+        "Which Integration Procedures skip metadata caching in production?"
+      ],
+      "concept:static-resource-public-cache-control-exposure": [
+        "Is this static resource safe to store an API key in?",
+        "Which static resources are cached publicly and reachable by guest users?",
+        "Does a Public cache-control static resource leak to unauthenticated Site visitors?",
+        "What is the difference between Private and Public cache-control on my static resources?",
+        "Can a guest user download this static resource without logging in?"
+      ],
+      "concept:custom-metadata-record-protected-namespace-scoped": [
+        "Can subscriber code read this protected custom metadata record?",
+        "Why are the values on this custom metadata record masked?",
+        "Is this protected custom metadata type readable outside its managed package?",
+        "Which custom metadata records are namespace-locked to the owning package?",
+        "Does marking a custom metadata record protected hide it from other Apex?"
+      ],
+      "concept:email-template-unavailable-hidden": [
+        "Why can't agents pick this email template when composing?",
+        "Which email templates are marked not Available For Use?",
+        "Is this email template hidden from the template picker?",
+        "Does an unavailable email template still get sent by automation?",
+        "What does the Available For Use flag on an email template do?"
+      ],
+      "concept:group-role-subordinates-transitive-membership": [
+        "Which public groups pull in an entire role subtree?",
+        "Does this group membership cascade down the role hierarchy?",
+        "If I share to this group, does the whole role-and-subordinates tree get access?",
+        "What roles does this public group transitively include?",
+        "Does a role-and-subordinates group member reach every role beneath it?"
+      ]
+    };
   }
 });
 
@@ -86613,7 +87858,7 @@ var init_static_embed = __esm({
 });
 
 // ../mcp/dist/src/semantic-funnel.js
-var STOPWORDS, SYNONYMS, PHRASE_SYNONYMS3, applyPhraseSynonyms3, tokenize6, TOOL_KEYWORDS, PLANE_OVERRIDES, planeForTool, EXCLUDED_FROM_CANDIDATES, liveRequiredForPlane, buildPlaneByTool, cachedPlanes, getPlaneByTool, resolveCandidatePlane, EXPANSION_WEIGHT, expandWeighted, CORPUS_EXCLUDED, buildToolDocs, cached, buildIndex, getFunnelIndex, CONF_HIGH_TOP1, CONF_HIGH_MARGIN, CONF_HIGH_COVERAGE, CONF_FLOOR_TOP1, CONF_MIN_COVERAGE, CONF_LOW_MARGIN, CONF_RESCUE_TOP1, CONF_RESCUE_COVERAGE, CONF_LOW_COVERAGE, funnelConfidence, staticEmbedEnabled, fuseStaticEmbeddings, semanticCandidates;
+var STOPWORDS, SYNONYMS, PHRASE_SYNONYMS3, applyPhraseSynonyms3, tokenize6, TOOL_KEYWORDS, PLANE_OVERRIDES, planeForTool, EXCLUDED_FROM_CANDIDATES, liveRequiredForPlane, buildPlaneByTool, cachedPlanes, getPlaneByTool, resolveCandidatePlane, EXPANSION_WEIGHT, expandWeighted, CORPUS_EXCLUDED, buildToolDocs, TOOL_CONCEPT_CARDS, buildVector, cached, buildIndex, getFunnelIndex, CONF_HIGH_TOP1, CONF_HIGH_MARGIN, CONF_HIGH_COVERAGE, CONF_FLOOR_TOP1, CONF_MIN_COVERAGE, CONF_LOW_MARGIN, CONF_RESCUE_TOP1, CONF_RESCUE_COVERAGE, CONF_LOW_COVERAGE, funnelConfidence, staticEmbedEnabled, fuseStaticEmbeddings, semanticCandidates;
 var init_semantic_funnel = __esm({
   "../mcp/dist/src/semantic-funnel.js"() {
     "use strict";
@@ -87059,6 +88304,27 @@ var init_semantic_funnel = __esm({
       }
       return docs;
     };
+    TOOL_CONCEPT_CARDS = {
+      "sfi.interpret": INTERPRET_CONCEPT_CARDS
+    };
+    buildVector = (toks, idf, idfFallback) => {
+      const vec = /* @__PURE__ */ new Map();
+      if (toks.length === 0)
+        return vec;
+      const tf = /* @__PURE__ */ new Map();
+      for (const t of toks)
+        tf.set(t, (tf.get(t) ?? 0) + 1);
+      let norm = 0;
+      for (const [term, f] of tf) {
+        const w = f / toks.length * (idf.get(term) ?? idfFallback);
+        vec.set(term, w);
+        norm += w * w;
+      }
+      norm = Math.sqrt(norm) || 1;
+      for (const [term, w] of vec)
+        vec.set(term, w / norm);
+      return vec;
+    };
     cached = null;
     buildIndex = () => {
       const docs = buildToolDocs();
@@ -87081,27 +88347,23 @@ var init_semantic_funnel = __esm({
       for (const [term, d] of df)
         idf.set(term, Math.log((n + 1) / (d + 1)) + 1);
       const vectors = /* @__PURE__ */ new Map();
-      for (const [tool, toks] of docTokens) {
-        if (toks.length === 0) {
-          vectors.set(tool, /* @__PURE__ */ new Map());
+      for (const [tool, toks] of docTokens)
+        vectors.set(tool, buildVector(toks, idf, 0));
+      const idfDefault = Math.log((n + 1) / (1 + 1)) + 1;
+      const conceptCardVectors = /* @__PURE__ */ new Map();
+      for (const [tool, cards] of Object.entries(TOOL_CONCEPT_CARDS)) {
+        if (!vectors.has(tool))
           continue;
+        const vecs = [];
+        for (const utterances of Object.values(cards)) {
+          const vec = buildVector(tokenize6(utterances.join(" ")), idf, idfDefault);
+          if (vec.size > 0)
+            vecs.push(vec);
         }
-        const tf = /* @__PURE__ */ new Map();
-        for (const t of toks)
-          tf.set(t, (tf.get(t) ?? 0) + 1);
-        const vec = /* @__PURE__ */ new Map();
-        let norm = 0;
-        for (const [term, f] of tf) {
-          const w = f / toks.length * (idf.get(term) ?? 0);
-          vec.set(term, w);
-          norm += w * w;
-        }
-        norm = Math.sqrt(norm) || 1;
-        for (const [term, w] of vec)
-          vec.set(term, w / norm);
-        vectors.set(tool, vec);
+        if (vecs.length > 0)
+          conceptCardVectors.set(tool, vecs);
       }
-      return { vectors, idf, toolCategory };
+      return { vectors, idf, toolCategory, conceptCardVectors };
     };
     getFunnelIndex = () => cached ??= buildIndex();
     CONF_HIGH_TOP1 = 0.27;
@@ -87200,8 +88462,7 @@ var init_semantic_funnel = __esm({
       qnorm = Math.sqrt(qnorm) || 1;
       if (qvec.size === 0)
         return [];
-      const scored = [];
-      for (const [tool, vec] of idx.vectors) {
+      const dotWith = (vec) => {
         let dot = 0;
         const [small, large] = qvec.size <= vec.size ? [qvec, vec] : [vec, qvec];
         for (const [term, w] of small) {
@@ -87209,6 +88470,19 @@ var init_semantic_funnel = __esm({
           if (o !== void 0)
             dot += w * o;
         }
+        return dot;
+      };
+      const scored = [];
+      for (const [tool, vec] of idx.vectors) {
+        let dot = dotWith(vec);
+        const cards = idx.conceptCardVectors.get(tool);
+        if (cards !== void 0) {
+          for (const cardVec of cards) {
+            const d = dotWith(cardVec);
+            if (d > dot)
+              dot = d;
+          }
+        }
         if (dot <= 0)
           continue;
         const score = dot / qnorm;
@@ -99681,8 +100955,8 @@ var init_server = __esm({
     init_tools();
     SERVER_NAME = "sf-intelligence";
     resolveServerVersion = () => {
-      if ("0.2.1") {
-        return "0.2.1";
+      if ("0.2.2") {
+        return "0.2.2";
       }
       for (const rel of ["../package.json", "../../package.json"]) {
         try {
@@ -100548,7 +101822,7 @@ var init_package_version = __esm({
     "use strict";
     readCliPackageVersion = () => {
       if (true)
-        return "0.2.1";
+        return "0.2.2";
       for (const rel of ["../package.json", "../../package.json"]) {
         try {
           const raw = readFileSync6(fileURLToPath4(new URL(rel, import.meta.url)), "utf8");
@@ -106205,7 +107479,7 @@ var makeShutdownOnce = (ctx) => {
 
 // dist/src/commands/demo.js
 init_refresh();
-var buildVersion = () => true ? "0.2.1" : "dev";
+var buildVersion = () => true ? "0.2.2" : "dev";
 var SHUTDOWN_SIGNALS2 = ["SIGINT", "SIGTERM"];
 var resolveDemoSource = () => {
   let dir = dirname25(fileURLToPath5(import.meta.url));
@@ -107660,7 +108934,7 @@ init_vault_git();
 init_watch();
 var readVersion = () => {
   if (true)
-    return "0.2.1";
+    return "0.2.2";
   const pkgUrl = new URL("../../package.json", import.meta.url);
   const raw = readFileSync10(fileURLToPath6(pkgUrl), "utf8");
   const parsed = JSON.parse(raw);