Digital-Dabei-Hamburg-Job-Manager/.planning/quick/002-fix-duplicate-mentor-notifications-on-jo/002-PLAN.md

---
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>