fix: DataExportSection error

- Fixed improper referencing for PlatformServiceMixin
- Fixed case where exported data has no contact methods

authored-by: Matthew Raymer <matthew.raymer@anomalistdesign.com>

.cursor/rules/version_control.mdc

@@ -1,34 +1,122 @@
 ---
 alwaysApply: true
 ---
-# Rules for peaceful co-existence with developers
+# Directive: Peaceful Co-Existence with Developers
 
-do not add or commit for the user; let him control that process
+## 1) Version-Control Ownership
 
-the content of commit messages should be from the files awaiting staging
-and those which have been staged.  use the differences in those files
-to inform the content of the commit message 
+* **MUST NOT** run `git add`, `git commit`, or any write action.
+* **MUST** leave staging/committing to the developer.
 
-always preview changes and commit message to use and allow me to copy and paste
-✅ Preferred Commit Message Format
+## 2) Source of Truth for Commit Text
 
-    Short summary in the first line (concise and high-level).
-    Avoid long commit bodies unless truly necessary.
+* **MUST** derive messages **only** from:
 
-✅ Valued Content in Commit Messages
+  * files **staged** for commit (primary), and
+  * files **awaiting staging** (context).
+* **MUST** use the **diffs** to inform content.
+* **MUST NOT** invent changes or imply work not present in diffs.
 
-    Specific fixes or features.
-    Symptoms or problems that were fixed.
-    Notes about tests passing or TS/linting errors being resolved (briefly).
+## 3) Mandatory Preview Flow
 
-❌ Avoid in Commit Messages
+* **ALWAYS** present, before any real commit:
 
-    Vague terms: “improved”, “enhanced”, “better” — especially from AI.
-    Minor changes: small doc tweaks, one-liners, cleanup, or lint fixes.
-    Redundant blurbs: repeated across files or too generic.
-    Multiple overlapping purposes in a single commit — prefer narrow, focused commits.
-    Long explanations of what can be deduced from good in-line code comments.
+  * file list + brief per-file notes,
+  * a **draft commit message** (copy-paste ready),
+  * nothing auto-applied.
 
- Guiding Principle
+---
+
+# Commit Message Format (Normative)
+
+## A. Subject Line (required)
+
+```
+<type>(<scope>)<!>: <summary>
+```
+
+* **type** (lowercase, Conventional Commits): `feat|fix|refactor|perf|docs|test|build|chore|ci|revert`
+* **scope**: optional module/package/area (e.g., `api`, `ui/login`, `db`)
+* **!**: include when a breaking change is introduced
+* **summary**: imperative mood, ≤ 72 chars, no trailing period
+
+**Examples**
+
+* `fix(api): handle null token in refresh path`
+* `feat(ui/login)!: require OTP after 3 failed attempts`
+
+## B. Body (optional, when it adds non-obvious value)
+
+* One blank line after subject.
+* Wrap at \~72 chars.
+* Explain **what** and **why**, not line-by-line “how”.
+* Include brief notes like tests passing or TS/lint issues resolved **only if material**.
+
+**Body checklist**
+
+* [ ] Problem/symptom being addressed
+* [ ] High-level approach or rationale
+* [ ] Risks, tradeoffs, or follow-ups (if any)
+
+## C. Footer (optional)
+
+* Issue refs: `Closes #123`, `Refs #456`
+* Breaking change (alternative to `!`):
+  `BREAKING CHANGE: <impact + migration note>`
+* Authors: `Co-authored-by: Name <email>`
+* Security: `CVE-XXXX-YYYY: <short note>` (if applicable)
+
+---
+
+## Content Guidance
+
+### Include (when relevant)
+
+* Specific fixes/features delivered
+* Symptoms/problems fixed
+* Brief note that tests passed or TS/lint errors resolved
+
+### Avoid
+
+* Vague: *improved, enhanced, better*
+* Trivialities: tiny docs, one-liners, pure lint cleanups (separate, focused commits if needed)
+* Redundancy: generic blurbs repeated across files
+* Multi-purpose dumps: keep commits **narrow and focused**
+* Long explanations that good inline code comments already cover
+
+**Guiding Principle:** Let code and inline docs speak. Use commits to highlight what isn’t obvious.
+
+---
+
+# Copy-Paste Templates
+
+## Minimal (no body)
+
+```text
+<type>(<scope>): <summary>
+```
+
+## Standard (with body & footer)
+
+```text
+<type>(<scope>)<!>: <summary>
+
+<why-this-change?>
+<what-it-does?>
+<risks-or-follow-ups?>
+
+Closes #<id>
+BREAKING CHANGE: <impact + migration>
+Co-authored-by: <Name> <email>
+```
+
+---
+
+# Assistant Output Checklist (before showing the draft)
 
-    Let code and inline documentation speak for themselves. Use commits to highlight what isn't obvious from reading the code.
+* [ ] List changed files + 1–2 line notes per file
+* [ ] Provide **one** focused draft message (subject/body/footer)
+* [ ] Subject ≤ 72 chars, imperative mood, correct `type(scope)!` syntax
+* [ ] Body only if it adds non-obvious value
+* [ ] No invented changes; aligns strictly with diffs
+* [ ] Render as a single copy-paste block for the developer

src/components/DataExportSection.vue

@@ -178,8 +178,8 @@ export default class DataExportSection extends Vue {
     try {
       this.isExporting = true;
 
-      // Fetch contacts from database using database utility
-      const allContacts = await this.$databaseUtil.getContacts();
+      // Fetch contacts from database using mixin's cached method
+      const allContacts = await this.$contacts();
 
       // Convert contacts to export format
       const processedContacts: Contact[] = allContacts.map((contact) => {
@@ -187,8 +187,10 @@ export default class DataExportSection extends Vue {
         const exContact: Contact = R.omit(["contactMethods"], contact);
         // now add contactMethods as a true array of ContactMethod objects
         exContact.contactMethods = contact.contactMethods
-          ? JSON.parse(contact.contactMethods as string)
-          : undefined;
+          ? (typeof contact.contactMethods === 'string' && contact.contactMethods.trim() !== '' 
+              ? JSON.parse(contact.contactMethods) 
+              : [])
+          : [];
         return exContact;
       });