docs(quick-002): fix duplicate mentor notifications on job republish

Quick task completed.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

.planning/STATE.md

@@ -12,7 +12,7 @@ See: .planning/PROJECT.md (updated 2026-01-14)
 Phase: 7 of 7 (Testing & Polish)
 Plan: 3 of 3 in current phase
 Status: Phase complete - PROJECT COMPLETE!
-Last activity: 2026-01-29 — Completed Plan 07-03 (Admin Flow & Deployment Prep)
+Last activity: 2026-01-29 — Completed Quick Task 002: Fix duplicate mentor notifications on job republish
 
 Progress: ████████████████████ 100%
 
@@ -113,10 +113,17 @@ All 7 phases finished. All identified UX/notification issues resolved. System is
 
 **Production deployment:** Ready to proceed following `.planning/phases/07-testing-polish/DEPLOYMENT-CHECKLIST.md`
 
+### Quick Tasks Completed
+
+| # | Description | Date | Commit | Directory |
+|---|-------------|------|--------|-----------|
+| 001 | UX & Notification Polish | 2026-01-29 | N/A | [001-ux-notification-polish](./quick/001-ux-notification-polish/) |
+| 002 | Fix duplicate mentor notifications on job republish | 2026-01-29 | 4145a92 | [002-fix-duplicate-mentor-notifications-on-jo](./quick/002-fix-duplicate-mentor-notifications-on-jo/) |
+
 ## Session Continuity
 
 Last session: 2026-01-29
-Stopped at: Completed Quick Task 002 (Fix Duplicate Mentor Notifications) - bug fix for republish notifications
+Stopped at: Completed Quick Task 002: Fix duplicate mentor notifications on job republish
 Resume file: None
 
 **Project Status:** ✅ COMPLETE - All 7 phases finished, all polish items complete, system ready for production deployment

.planning/quick/002-fix-duplicate-mentor-notifications-on-jo/002-PLAN.md

@@ -0,0 +1,124 @@
+---
+phase: quick-002
+plan: 01
+type: execute
+wave: 1
+depends_on: []
+files_modified:
+  - includes/class-notifications.php
+autonomous: true
+
+must_haves:
+  truths:
+    - "Mentors receive notification when a job is first published"
+    - "Mentors do NOT receive notification when a previously-published job is edited and republished"
+    - "Each job can only trigger mentor notifications once in its lifetime"
+  artifacts:
+    - path: "includes/class-notifications.php"
+      provides: "Duplicate notification guard using post meta"
+      contains: "_ddhh_mentors_notified"
+  key_links:
+    - from: "notify_mentors_on_job_publish"
+      to: "post_meta _ddhh_mentors_notified"
+      via: "get_post_meta check before scheduling, update_post_meta after scheduling"
+      pattern: "get_post_meta.*_ddhh_mentors_notified"
+---
+
+<objective>
+Fix duplicate mentor notifications when a job is edited and republished.
+
+Purpose: Mentors currently receive "new job" notifications every time a job transitions to
+publish status -- including after edits (pending -> publish). The notification should only
+fire once per job, on the very first publication. Subsequent republications after edits
+should be silent for mentors (the admin already gets a separate edit notification).
+
+Output: Updated `notify_mentors_on_job_publish` method with a post meta guard that prevents
+duplicate notifications.
+</objective>
+
+<execution_context>
+@~/.claude/get-shit-done/workflows/execute-plan.md
+@~/.claude/get-shit-done/templates/summary.md
+</execution_context>
+
+<context>
+@includes/class-notifications.php
+@includes/class-scheduler.php
+
+The bug is in `notify_mentors_on_job_publish()` (line ~430). The current guard:
+
+```php
+if ( 'publish' !== $new_status || 'publish' === $old_status ) {
+    return;
+}
+```
+
+This correctly prevents re-notification when a published post is updated (publish -> publish),
+but it does NOT prevent re-notification when a previously-published job is edited and reset
+to pending (per decision 03-02: "Post status reset to pending after edit"), then republished
+by admin (pending -> publish). This second publish triggers notifications again.
+
+The job lifecycle that causes the bug:
+1. Provider submits -> status: pending
+2. Admin publishes -> pending to publish -> mentors notified (CORRECT)
+3. Provider edits -> status reset to pending (per 03-02)
+4. Admin republishes -> pending to publish -> mentors notified AGAIN (BUG)
+</context>
+
+<tasks>
+
+<task type="auto">
+  <name>Task 1: Add post meta guard to prevent duplicate mentor notifications</name>
+  <files>includes/class-notifications.php</files>
+  <action>
+In the `notify_mentors_on_job_publish` method, add a post meta check AFTER the existing
+status transition guard (line ~437) and BEFORE the mentor query (line ~442):
+
+1. Check if post meta `_ddhh_mentors_notified` exists and equals `'1'` for this post.
+   If it does, log a message like "DDHH Job Manager: Skipping mentor notification for
+   job #%d - mentors already notified on initial publish" and return early.
+
+2. After the `DDHH_JM_Scheduler::schedule_mentor_notification_batch()` call succeeds
+   (line ~457), set post meta: `update_post_meta( $post->ID, '_ddhh_mentors_notified', '1' )`.
+
+Use underscore-prefixed meta key `_ddhh_mentors_notified` so it is hidden from the
+WordPress custom fields UI.
+
+Do NOT change any other logic in this method or file. The existing status transition
+guard should remain as-is (it still serves a purpose for publish->publish transitions).
+  </action>
+  <verify>
+1. Read the modified file and confirm:
+   - `get_post_meta( $post->ID, '_ddhh_mentors_notified', true )` check exists before mentor query
+   - `update_post_meta( $post->ID, '_ddhh_mentors_notified', '1' )` exists after scheduling
+   - No other methods were modified
+2. Run `php -l includes/class-notifications.php` to confirm no syntax errors
+  </verify>
+  <done>
+The `notify_mentors_on_job_publish` method checks for `_ddhh_mentors_notified` post meta
+before scheduling notifications, and sets that meta after scheduling. This ensures mentors
+are only notified once per job, regardless of how many times the job transitions through
+pending -> publish.
+  </done>
+</task>
+
+</tasks>
+
+<verification>
+1. `php -l includes/class-notifications.php` passes with no syntax errors
+2. The `_ddhh_mentors_notified` meta key is checked before notification scheduling
+3. The `_ddhh_mentors_notified` meta key is set after successful scheduling
+4. No other notification methods were modified
+5. The existing `transition_post_status` guard logic is preserved
+</verification>
+
+<success_criteria>
+- First publish of a job (pending -> publish) triggers mentor notifications and sets meta flag
+- Subsequent publishes of the same job (pending -> publish after edit) skip mentor notifications
+- Admin notifications for edits/republications are unaffected
+- No PHP syntax errors introduced
+</success_criteria>
+
+<output>
+After completion, create `.planning/quick/002-fix-duplicate-mentor-notifications-on-jo/002-SUMMARY.md`
+</output>