Fix communicate-score cycle-boundary sentinel resets

[cdunda-perchwell]

Summary

workflow::communicate-score can re-inject incorrectly around cycle transitions because the resolved-this-cycle guard is not fully wired through the framework's cycle-boundary reset points.

Repro

1. Let workflow::communicate-score inject and resolve it.
2. Trigger a follow-up scan / reconcile pass.
3. The workflow gate can re-evaluate after previous_plan_start_scores is cleared.
4. In objective-only or PRR-style flows, sync_communicate_score_needed() may re-inject unexpectedly unless a separate resolved-this-cycle sentinel survives the same cycle.

Root cause

The guard logic needs two pieces:

• a communicate_score_resolved_this_cycle sentinel checked by sync_communicate_score_needed()
• a boundary reset helper that clears that sentinel only at true cycle boundaries

Without both halves wired consistently, one of two bad outcomes happens:

• the item re-injects after resolve + rescan in the same cycle, or
• the sentinel survives too long and suppresses the next real cycle

Proposed fix

• gate sync_communicate_score_needed() on communicate_score_resolved_this_cycle
• set the sentinel when the workflow item is injected
• clear it at the same true cycle boundaries as the other workflow sentinels:
  • force-rescan reset
  • plan-start score seeding
  • queue-drain / plan-start clear
  • trusted review import

Regression coverage

Add focused tests for:

• helper-level clearing of clear_communicate_score_sentinel()
• score seeding clearing all workflow sentinels
• force-rescan clearing all workflow sentinels
• queue-drain clearing all workflow sentinels
• trusted import clearing all workflow sentinels

[cdunda-perchwell]

Investigation update

What we found

The re-injection has two distinct code paths, not one. The original issue description correctly identified the scan-path case. We found a second path during live testing.

---

Path 1: post-queue-drain rescan (scan path)

Sequence:

1. Scan injects communicate-score → sets communicate_score_resolved_this_cycle: True and previous_plan_start_scores
2. Agent resolves it
3. Scan 1 (post-resolve rescan): reconcile_plan runs, blocked by previous_plan_start_scores ✓ — then _clear_plan_start_scores_if_queue_empty runs, clears plan_start_scores, previous_plan_start_scores, AND communicate_score_resolved_this_cycle
4. Scan 2: both guards are gone → sync_communicate_score_needed re-injects

Fix (implemented, uncommitted): Remove clear_communicate_score_sentinel(plan) from _clear_plan_start_scores_if_queue_empty. The sentinel should survive until the next cycle starts, when _seed_plan_start_scores clears it naturally.

-    clear_communicate_score_sentinel(plan)
+    # NOTE: do NOT clear communicate_score_resolved_this_cycle here.
+    # This sentinel must survive until the next cycle starts (when
+    # _seed_plan_start_scores runs), otherwise the post-queue-drain rescan
+    # re-injects workflow::communicate-score because both guards
+    # (previous_plan_start_scores and communicate_score_resolved_this_cycle)
+    # have been cleared before reconcile_plan runs on the next scan.

File: desloppify/app/commands/scan/plan_reconcile.py, _clear_plan_start_scores_if_queue_empty

---

Path 2: immediate re-injection during resolve (resolve path)

Sequence:

1. Scan seeds plan_start_scores → calls clear_communicate_score_sentinel (clears both sentinels as part of seeding)
2. reconcile_plan runs → sync_communicate_score_needed injects → sets communicate_score_resolved_this_cycle: True and previous_plan_start_scores
3. Agent calls plan resolve workflow::communicate-score
4. update_living_plan_after_resolve → purge_ids removes it from queue_order → _reconcile_if_queue_drained → reconcile_plan → sync_communicate_score_needed

At step 4, both sentinels ARE present in the plan object. Simulation confirms sync_communicate_score_needed correctly returns empty when both are set. Yet the execution log shows re-injection at the same timestamp as the resolve.

Status: root cause not yet confirmed. The re-injection is logged as sync_communicate_score with injected: True at the exact same timestamp as the done entry. The simulation (loading the live plan + state and calling sync_communicate_score_needed directly) does NOT reproduce it — the function correctly returns no injection. This suggests either:

• Something in the resolve path clears the sentinels before _reconcile_if_queue_drained runs (not purge_ids, not clear_postflight_scan_completion — both confirmed clean)
• The installed binary is not picking up source changes correctly (ruled out — verified grep on installed files)
• There is a second call site that injects communicate-score outside of sync_communicate_score_needed (ruled out — only one injection point exists)

We stopped investigating Path 2 because the practical impact in PRR flows is low (agent resolves it twice, ~2 extra tool calls, no effect on final score).

---

Current state of PR #448

The PR as pushed to public-fork/fix/communicate-score-cycle-boundaries-447 contains:

• communicate_score_resolved_this_cycle sentinel added to sync_communicate_score_needed
• clear_communicate_score_sentinel() helper added
• Sentinel cleared at force-rescan, score seeding, queue drain, trusted import

This covers Path 1 partially but does not fully fix it — the _clear_plan_start_scores_if_queue_empty change (removing the sentinel clear from queue-drain) is implemented locally but not yet committed or pushed to the PR branch.

Path 2 (resolve-path re-injection) is not fixed in the PR.

---

What needs to happen to close this

1. Commit and push the _clear_plan_start_scores_if_queue_empty fix to PR fix: wire communicate-score cycle-boundary sentinels #448 (fixes Path 1 fully)
2. Investigate Path 2 further — specifically trace what clears the sentinels between purge_ids and _reconcile_if_queue_drained during a live resolve
3. Once Path 2 root cause is confirmed, add a fix and regression test

The regression test for Path 1 is written and passing locally (test_communicate_score_not_reinjected_after_resolve in tests/commands/scan/test_plan_reconcile_postflight_and_reconcile.py).

[peteromallet]

Fix is in PR #448 — the sentinel wiring looks correct, just waiting on the author to split out unrelated changes before merging.

[peteromallet]

Fix is in PR #448 — the sentinel wiring looks correct. Asked the author to split out the unrelated prr plugin and other bundled changes so we can merge the sentinel fix cleanly.

[peteromallet]

Fixed in v0.9.10 via PR #448 by @cdunda-perchwell — communicate-score sentinel resets are now properly cleared at cycle boundaries.