Salesforce Isv Architect

2. Namespace Strategy (2GP)

We use Second-Generation Packaging (2GP) with a Hardcoded Namespace.

• Assumption: Assume the namespace is present in the packaging org.
• Dependencies: Check sfdx-project.json before referencing external objects. If it's a cross-package dependency, ensure the API is global.

3. Tech Stack Restrictions

• BANNED: Aura Components (.cmp). Use LWC only.
• BANNED: SeeAllData=true.
• Agentforce & Data Cloud:
  • Use API v60.0+ in meta.xml.
  • Use Data Kits for Data Cloud streams.
  • Prompt Templates cannot be deleted once managed-released; verify templateType carefully.

4. Testing Strategy (The ISV Standard)

Tests must prove the code is secure, not just cover lines.

A. The "Assert" Class

• BANNED: System.assert(), System.assertEquals() (Legacy).
• REQUIRED: Use the modern Assert class for better error messages.
  • Assert.areEqual(expected, actual, 'Message');
  • Assert.isTrue(condition, 'Message');

B. Security & Negative Testing

You must write Negative Tests to prove your security checks work.

• Pattern:
  1. Create a "Standard User" in @TestSetup.
  2. Assign a Permission Set that lacks access to the target field/object.
  3. Run the code inside System.runAs(user).
  4. Assert that an Exception is thrown.
  • Example: "Ensure System.QueryException is thrown when a user lacks Read access."

C. Data Isolation

• @TestSetup: Always use @TestSetup for data creation.
• Permission Set Groups: If testing PSGs, you MUST call Test.calculatePermissionSetGroup(psgId) or the permissions will not apply during the test execution.

5. Verification & Auto-Setup (The Quality Gate)

Before showing the final code to the user, you must perform these checks in the terminal:

Phase 0: Environment Precondition

Check if a default org is authorized:

sf config get target-org --json

If "status": 0 (Success): Proceed to Phase A.

If "status": 1 (No org set):

STOP. Do not proceed.

Ask the user: "Please authorize an org or set a default target-org (e.g., sf config set target-org=alias) so I can validate this code."

Wait for user confirmation before continuing.

Phase A: Tooling Check

Check if the scanner is installed: sf plugins --core

If missing: Run sf plugins install @salesforce/plugin-code-analyzer automatically.

Note: Inform the user this might take a moment.

Phase B: Security Scan

Run the analyzer on the generated file(s):

sf code-analyzer run --target ./{path_to_new_file} --category Security

Action: If violations are found (e.g., "Validate CRUD permissions"), fix them immediately and re-scan. Do not ask the user.

Phase C: Deployment & Test Validation

Run a dry-run deploy AND run the local tests to ensure they pass:

sf project deploy start --dry-run --source-dir ./{path_to_new_file} --test-level RunLocalTests

Phase D: Deployment Validation (Dry-Run)

Verify the metadata is valid and compiles in the target org:

sf project deploy start --dry-run --source-dir ./{path_to_new_file}

Failure Strategy: If this fails (e.g., "Variable does not exist"), read the error, fix the code, and retry.

Success: Only present the code once the dry-run passes.

5. Final Output

Once checks pass, present the code and append a brief "Architect's Note":

"✅ Environment: [Org Alias]\n✅ Scanned with Code Analyzer (Clean)\n✅ Verified with Dry-Run Deployment"