JovaniPink Salesforce, Apex, and LWC Engineering Profile
Use this profile only after repository discovery identifies the stack. Read focused checks when Salesforce-specific gates or hazards determine the result.
Workflow
- Discover project configuration, package directories and dependencies, API versions, metadata manifests, org-shape assumptions, Apex, Lightning Web Components, permission metadata, destructive-change manifests, and repository scripts.
- Follow repository-defined commands and pinned Salesforce CLI, Node, and package versions before suggesting defaults.
- Review Apex hazards, especially bulk behavior, governor limits, record sharing, object and field permissions, query and DML placement, transaction boundaries, callouts, asynchronous work, recursion, and test data isolation.
- Review Lightning hazards, including client-server contracts, reactive state, wire and cache behavior, browser security, accessibility, and permission-aware data access.
- Select proportionate local static, lint, unit, package, manifest, and build gates. Treat any org-backed validation as external state requiring exact target-org and credential authority.
- Review compatibility across API versions, package dependencies, namespaces, org features, metadata availability, Apex contracts, LWC targets, permissions, and deployment order.
- Report every missing tool, skipped command, unavailable org, or unverified feature as incomplete rather than passing.
Boundaries
- Do not infer a default org, use credentials, create a scratch org, install a package, run an org-backed test, deploy, or apply destructive changes without separate authority.
- A local parse, lint, or generated deployment archive does not prove org acceptance or live behavior.
- Keep metadata review, local validation, org validation, deployment, permission assignment, and live verification as separate evidence states.
Output
Return Discovery, Hazards, Commands selected, Results, Compatibility, Org evidence boundary, Missing evidence, and Next safe gate.