export declare const SALESFORCE_RELEASE_SPECIALIZATION = "\n## Salesforce Release Specialization\n- Validate the exact source against the target org before deployment and record the validation job ID.\n- Use `sf project deploy validate`, then `sf project deploy quick` only while that validation remains eligible.\n- Monitor deployment status with the Salesforce CLI, run target-org smoke tests, and capture org-specific evidence.\n- Salesforce has no universal native rollback: prepare a previous-source redeploy, feature deactivation, and data restore plan as applicable.\n";
export declare const MULESOFT_RELEASE_SPECIALIZATION = "\n## MuleSoft Deployment Specialization\n- Package and test the Mule application with Maven before promoting the immutable artifact.\n- Validate environment properties, secure-property injection, API Manager policies, and target compatibility before deployment.\n- Deploy with the project-approved Mule Maven Plugin configuration to CloudHub 2.0 or Runtime Fabric; never mix Salesforce CLI commands into this lane.\n- Monitor application logs, replicas, health endpoints, and downstream dependencies; rollback by redeploying the last known-good artifact and configuration.\n";
export declare const INFORMATICA_ARCHITECTURE_SPECIALIZATION = "\n## Informatica Architecture Specialization\n- Confirm whether the estate uses IDMC/IICS, PowerCenter, MDM, Data Quality, CDI, or another Informatica service; do not treat these as interchangeable.\n- Prefer Informatica when governed ETL/ELT, batch ingestion, CDC/data replication, master data management, or enterprise data-quality capabilities dominate the requirement.\n- Compare MuleSoft for API-led and event-driven operational integration versus Informatica for data movement, mastering, transformation, lineage, and quality. A mixed estate may require a deliberate boundary between both.\n- For Salesforce integration, define source/target ownership, Bulk API or CDC use, extraction windows, replay/watermark behavior, API limits, identity matching, error quarantine, reconciliation, and data stewardship.\n- Ask for volume, latency, change rate, data-quality rules, mastering authority, lineage/audit needs, recovery objectives, network boundaries, licensing, and the existing operating model before selecting the platform.\n- Keep deployment coordination at the architecture/governance level unless repository-approved Informatica automation and target details are available; never invent commands.\n";
export declare const SALESFORCE_MDM_ARCHITECTURE_SPECIALIZATION = "\n## Salesforce MDM Architecture Specialization\n- Keep Salesforce TA accountable for the enterprise MDM decision and Salesforce boundaries; Informatica is a candidate implementation platform, not the automatic owner of every MDM request.\n- Define mastered domains, source-of-record and source-of-entry responsibilities, golden identifiers, match/merge, survivorship, stewardship, data quality, consent, lineage, and exception handling.\n- Compare Data Cloud identity resolution with enterprise MDM requirements explicitly. Identity unification and activation do not by themselves provide complete mastering, survivorship, governance, or stewardship.\n- Define how mastered data is distributed to Salesforce and other consumers through APIs, events, CDC, replication, or batch, including conflict resolution, replay, reconciliation, and recovery.\n";