feat: freshness engine Phase 4 — re-verify handoff

[divo12]

What

Phase 4 (final slice) of the freshness engine: the background heal demotes drifted code_verified claims to truth: unknown; this hands those to an agent to re-verify and rewrite. Completes the loop: detect → surface → demote → re-verify.

How (ponytail: no queue table)

The re-verify worklist is a query, not a table. claimsNeedingReverify(repoId, limit) derives it from existing state — current claims that were drift-demoted to truth: unknown (via readGraphView + listInvalidationEvents). A claim drops out for free once an agent supersedes it with a fresh code_verified one. This drops the reverify_queue table + 4 repo methods + txn-enqueue wiring the original design sketched (~80 LOC).

• service.reverifyWorklist(input, limit) — thin wrapper over the repository query.
• reverifyPrompt(claims, proposalPath) — pure prompt builder naming each claim + its anchors.
• runReverifyPass(runner, cwd, claims) — hands the worklist to the existing platform agent runner; empty worklist → no spawn.
• Worker drains per active repo, gated by session.autoHealDrift, capped at 3/cycle.
• Extracted shared runMemoryAgent (memory-update + reverify both use it); removed now-dead safePathSegment.

Test plan

• npm test green across all 9 suites (incl. the feat: freshness engine — keep code_verified claims honest as code changes Autoloops/greplica#96 check-anchor-drift regression); tsc --noEmit clean.
• New assertions in check-freshness-background.js: worklist returns demoted claims / excludes a manually-created unknown claim / respects the limit; prompt names the claim + anchor + "re-verify"; runReverifyPass hands the worklist to a fake runner; empty worklist → no agent spawn.
• Deterministic (no model download) — reuses the stub-context-builder + fake-runner pattern.

Ponytail deferrals (marked in-code)

• No per-claim attempts cap — an unfixable claim is re-prompted each cycle. Add a counter only if it storms.
• reverifyLimit = 3 hardcoded — config only if repos diverge.
• Worklist reuses readGraphView — swap to one SQL join only if the graph grows.

Scope

Phase 4 only. Stacks on feat/anchor-drift-invalidation (Phases 1–3 merged).

---

Summary by cubic

Adds Phase 4 of the freshness engine: the worker re-verifies drift‑demoted claims by handing them to the platform agent. The worklist is derived from existing state (no queue), capped at 3 per repo per cycle, and completes the detect → surface → demote → re-verify loop.

• New Features

  • Compute the re-verify worklist from invalidation events + graph; claims drop out once superseded.
  • Expose the worklist via repository claimsNeedingReverify(repoId, limit) and service reverifyWorklist(...); respects a per-pass limit.
  • Worker drains per active repo when auto-heal is enabled; runs the agent with a prompt listing claim IDs and code anchors; skips when empty.

• Bug Fixes

  • Isolate re-verify per repo; errors (e.g., missing install or reverifyWorklist failures) no longer abort the pass — log freshness_reverify_error and continue.

^{Written for commit e94fae9. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 4 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>