Skip to content

T-9Q4A-deliveryrecord-signature-keyed-idempotent-delivery-log

State: closed/done · Impact: medium · Complexity: medium

pr classify’s cursor advances on every call regardless of outcome, so the Router cannot reuse it to track what feedback has already been delivered — a failed delivery would silently lose the comment. simple-dispatch-interfaces.html’s “Why the router keeps its own delivery record” section designs a separate, signature-keyed record for exactly this.

  1. Define DeliveryRecord (version, subject, a delivered map keyed by item signature, an attempts log, heldSince) per simple-dispatch-interfaces.html.
  2. Derive a stable signature per feedback item: comments/reviews from Activity.kind + id + editedAt ?? at (T-DVLT’s Activity type carries these); pr-update conflicts from the PR + base head SHA + paths, sourced from T-4AQN’s conflict JSON output (AC-3 there reports the base head SHA specifically so this signature has something to key on).
  3. Store one record per subject under this project’s .sdlc/ runtime-state convention (the design doc’s .sdlc/dispatch/deliveries/ layout, adapted).
  4. Wire the Router (T-BT9H) to consult the record before sending and to append an attempt after every delivery outcome.
  5. Reuse classify.ts’s entrySurvives filter so bot/self comments never mint a signature.
AreaNote
solutions/ontological/lib/services/dispatch/New: DeliveryRecord
solutions/ontological/lib/services/pr/ops/classify.tsentrySurvives reused, read-only
  • AC-1: The same unedited comment is never delivered twice across ticks.
  • AC-2: An edited comment gets a new signature and is delivered again.
  • AC-3: A pr-update conflict’s signature changes when the base head moves, so a stale conflict is not re-sent forever.
  • the delivery chain itself (T-BT9H)
  • T-BT9H
  • T-DVLT — Activity.id/editedAt are the comment/review half of the signature
  • T-4AQN — AC-3’s base-head-SHA field is the conflict half of the signature

T-BT9H, T-DVLT, T-4AQN


← Back to Tasks