Skip to content

stewards: keep unadopted Dependabot adoption decisions and clock the SLA from the alert (BB-227) - #259

Merged
trotterdylan merged 2 commits into
mainfrom
bb/bb-227-bb-plugins-stewards-adoption-decision-thr_xvs264eshy
Nov 4, 2026
Merged

trotterdylan merged 2 commits into
mainfrom
bb/bb-227-bb-plugins-stewards-adoption-decision-thr_xvs264eshy

Conversation

@trotterdylan

@trotterdylan trotterdylan commented Nov 4, 2026 •

Copy link
Copy Markdown
Collaborator

Implements BB-227.

SC-111 sat six days in Backlog because the one "Recommend adopting" escalation lived in the filing thread that was later deleted, and recreating the watch binding reset the SLA clock. This makes the adoption decision durable plugin state keyed by ticket, shows it as a plugin-filed decide need, clocks the deadline from the alert's own created_at, and keeps provenance on the fingerprint row. Reuses the prototype on bb/thr_du2uvaqujc (closed #258), dropping the source-contract.ts due-date change, the ops_log table and the half/eve reminder stages.

Merging moves the bb-plugins pin, builds a new bb-server image and stages a restart on every developer's server (Restart now, or the 03:00–05:00 ET quiet window).

Classification

owner-reviewed: the user entry "The stewards plugin's roles parsing, ready gate and approval and escalation plumbing outside the hard-coded self-widening list" — the diff changes plugins/stewards/server.ts, wake.ts and templates.ts, which that entry names. The store migration is also in the diff (the project entry "A store migration"), but the escalation/decision plumbing is the user's. @dylan, this one needs your approval; the project steward does not approve it.

What changes

  • Durable adoption decisions. New deps_decisions table keyed by (project_id, ticket_key): fingerprints, severity, raised-at/by, need id, status, resolution, snoozed_until and reminded. Raised idempotently in steward_report the moment opsTickets lists a ticket as filed/reopened for a severity deps.autoAdopt does not name, and on every dependency look as the backfill for an open, unlabelled ticket with no decision. Shown as a decide need (filedBy: "plugin", data.adoption = true) on whichever binding watches the repo now; a recreated binding re-files it and closes the earlier item as moved.
  • Choices. With a fixed version: Adopt, Keep tracking, Dismiss as not used. With none: Dismiss, Keep tracking, Adopt. Dismiss is offered only when the playbook's may list declares dismiss-alert; otherwise the item and the wake omit it.
  • Dismiss is the owner's. The wake says a steward may dismiss only from the owner's own answer on that ticket's decision item, names the exact alert numbers from the decision's fingerprints in that repo, and tells the steward to re-read each alert first and skip any already fixed or dismissed.
  • Settle rules. The owner's answer (bb stewards done --choice or the page), the project label on the ticket, or the ticket completing/cancelling. Unreadable tickets change nothing.
  • Keep tracking is a snooze. The plugin records the date the answer's note gives (or one SLA window from today) as snoozed_until, closes the item, and re-files the same decision when the date arrives.
  • SLA clock. deadlineAt uses the alert's own created_at (fallback: first seen), in the look and the batch plan, so a recreated binding computes the date the ticket was filed with. The plugin owns the deadline; source-contract.ts is untouched.
  • One overdue reminder. Past the deadline (or the snooze) the plugin rewrites the item "overdue by N days", adds a note to the project steward's pending notes so the digest names it under needs-you, and records the reminder once.
  • Provenance. ops_fingerprints.filed_by_thread records the acting thread on a filing/reopening; bb stewards show prints it per fingerprint and every decision with its status, dates and resolution.
  • Store migration appended as a new group (DEPS_DECISION_MIGRATIONS) with its three hashes in migrations.snapshot.json; the new statements (including the filed_by_thread ALTER) are prepared lazily so legacy-schema tests still open the store.
  • templates.ts deps-alerts template gains dismiss-alert in may and drops the "raise a decision escalation" instruction; DESIGN.md §19, README and the stewards skill's ops section follow. The live .bb/stewards/playbooks/deps-alerts.md is a later bb-gate slice after this deploys.

Testing

  • npm run typecheck in plugins/stewards: pass.
  • npm test in plugins/stewards: pass (1237 tests, 31 files; CI's stewards matrix entry runs it too, and I ran the full suite locally).
  • server.test.ts: the SC-111 replay (durable decision, recreated binding, computed deadline, one overdue reminder, digest note, bb stewards show provenance), settle by label/close, Keep tracking snooze and re-raise, the missing-may case, and the already-closed-alert dismiss instruction.
  • deps.test.ts: deadlineAt from created_at with first-seen fallback, snoozeUntil, overdue wording, choice gating.
  • store.test.ts: the migration group order and legacy-schema store opens, decision lifecycle, filed_by_thread.

@trotterdylan

Copy link
Copy Markdown
Collaborator Author

Independent review running in bb thread @thread:thr_idr7uwzjkg.

— from bb thread thr_xvs264eshy

@trotterdylan

Copy link
Copy Markdown
Collaborator Author

Review round 1 (GLM 5.3 on Fireworks, at 34549d7)

Owner review required: yes — the stewards plugin's approval and escalation plumbing (decide list entry "The stewards plugin's roles parsing, ready gate and approval and escalation plumbing outside the hard-coded self-widening list", decide: user, matched by server.ts, wake.ts, templates.ts; the store migration's project entry does not lower it). @trotterdylan, this one needs your approval; the escalation is binding, so a project-steward bb-approval will not meet the gate and your unsigned approval will.

Blockers

  1. plugins/stewards/README.md (the deps object paragraph, "…kept by the plugin until answered, with reminders at half the time to the due date, the day before, and once overdue") — those half-way and day-before stages are the closed prototype's (stewards: durable adoption decisions for unadopted Dependabot tickets, SLA clocked from the alert #258) and are explicitly out of scope; the implementation and DESIGN.md §19 have exactly one overdue reminder. As written the shipped README documents behaviour this PR deliberately does not have. Drop "at half the time to the due date, the day before, and" and keep "once overdue".

One wrong fact in the PR body: the Testing section says the stewards suite is "not in the CI matrix" — plugins.yaml's matrix includes stewards.

Tested

  • Ran: npm run typecheck and npm test in plugins/stewards (pass; 1237 tests, 31 files), plus bb stewards gate for the lane.
  • Verified against ticket: scope holds — source-contract.ts untouched, no ops_log, no half/eve stages in code; the replay, settle, snooze, missing-may and already-closed-alert cases are all in server.test.ts, and the migration is append-only with the snapshot updated (checked the snapshot test and the group order).

— from bb thread thr_idr7uwzjkg

@trotterdylan

Copy link
Copy Markdown
Collaborator Author

Round 1 addressed at 3968e24.

  • Blocker 1 (README documents the prototype's half/eve reminder stages): fixed in 3968e24 — the deps object paragraph now reads "with one overdue reminder", matching the implementation and DESIGN.md §19.
  • PR body note: corrected the Testing line; CI's plugins.yaml matrix does include stewards, and the full 1237-test suite was run locally.

— from bb thread thr_xvs264eshy

@trotterdylan

Copy link
Copy Markdown
Collaborator Author

Review round 2 (GLM 5.3 on Fireworks, at 3968e24)

Owner review required: yes — the stewards plugin's approval and escalation plumbing (decide list entry "The stewards plugin's roles parsing, ready gate and approval and escalation plumbing outside the hard-coded self-widening list", decide: user, matched by server.ts, wake.ts, templates.ts; the store migration's project entry does not lower it). @trotterdylan, this one needs your approval; the escalation is binding, so a project-steward bb-approval will not meet the gate and your unsigned approval will.

Resolved since round 1

  • Blocker 1 (README described the prototype's half/day-before reminder stages): resolved by 3968e24 — the paragraph now says "with one overdue reminder", matching the code and DESIGN.md §19. The PR body's CI note is corrected too.

The diff since 34549d7 is that one README wording change, so round 1's typecheck and full-suite run stands; nothing new to run.

— from bb thread thr_idr7uwzjkg

@trotterdylan

Copy link
Copy Markdown
Collaborator Author

Reviewer approved 3968e24 (round 2, owner-reviewed lane) and every check is green on that head. The remaining gate is the owner's approval: the decide list's user entry "The stewards plugin's roles parsing, ready gate and approval and escalation plumbing outside the hard-coded self-widening list" makes this the owner's, and a project-steward bb-approval does not meet it. @trotterdylan, this needs your unsigned approval before I merge.

— from bb thread thr_xvs264eshy

@trotterdylan

Copy link
Copy Markdown
Collaborator Author

Approved 3968e24 from the Stewards page

@trotterdylan
trotterdylan merged commit b46ece7 into main Nov 4, 2026
22 checks passed
@trotterdylan
trotterdylan deleted the bb/bb-227-bb-plugins-stewards-adoption-decision-thr_xvs264eshy branch November 4, 2026 19:43
@trotterdylan

Copy link
Copy Markdown
Collaborator Author

Merged: owner-reviewed, approved by trotterdylan on 3968e24 (comment 2026-11-04T19:42:58Z), reviewer approved round 2 at 3968e24, checks green.

Merging moves the bb-plugins pin, builds a new bb-server image and stages a restart on every developer's server (Restart now, or the 03:00–05:00 ET quiet window).

merge commit b46ece7

— from bb thread thr_xvs264eshy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant