[trotterdylan]

Why

SC-111 in santaclaw: two medium Dependabot alerts (echo, go, no patched version) were filed and sat in Backlog unlabelled for six days, up to their due date. Nobody was asked whether to adopt the ticket: the deps steward's one "Recommend adopting" escalation lived in the filing thread, which was later deleted. Recreating the watch binding reset the SLA clock, so every steward report and digest since then said due 11-07 when Linear said 11-04, and nothing mechanical warned as the real date approached.

What

1. Adoption decisions are durable plugin state. New deps_decisions table keyed by ticket. The decision is raised the moment a steward_report lists a ticket filed for a severity deps.autoAdopt does not name, and at every look as the backfill (a ticket inherited by a recreated binding, found by the dedup search, or filed by a thread that never reported). It shows as a plugin-filed decide need on whichever binding watches the repository, in bb stewards needs, on the Stewards page and in the digest's "Needs you", with choices Adopt, Dismiss as not used, Keep tracking (dismiss first when no alert has a fix). It settles when the owner answers (page or bb stewards done --choice), the ticket is labelled, or the ticket closes. A recreated binding re-files the item on itself and closes the earlier one.
2. The SLA clock is the alert's created_at, not when this server first saw it (alertClockAt). Once a ticket exists, its Linear dueDate is the truth: the wake shows it on the alert and names the drift when the SLA alone would disagree; the batch plan uses it and only ever tightens it.
3. Live due date and labels in the wake, read from Linear per look. dueDate is a new optional nullable field on entitySnapshotSchema (all three source-contract.ts copies updated together; linear serves it, github leaves it absent).
4. Mechanical reminders at half the time to the due date, the day before, and once overdue (reminderDue), each once: the item is reworded, a note is queued for the project steward's next wake so the digest names the deadline, and it is logged.
5. Choices fit the case: no patched version leads with dismiss; the wake tells the steward what each answer means (label and Todo, gh api dismiss and close with a comment, or move the due date).
6. Ops action log (ops_log, keyed by target): filed/commented/reopened with the acting thread id, decisions raised, reminders, settlements. bb stewards show <target> prints decisions and the log, so "did anyone ask?" is answered without the filing thread.

The deps-alerts template, DESIGN.md §19, README and the stewards skill are updated. The sibling bb-gate PR (same head branch) updates the live .bb playbook and should merge after this one: bitcomplete/bb-gate#96.

Store

Two new tables, appended as DEPS_DECISION_MIGRATIONS after the escalation-route group; migrations.snapshot.json has the four new hashes. The new statements are prepared lazily so the legacy-schema migration tests still open the store.

Acceptance (replayed in server.test.ts, "replays SC-111")

• After the report that files the ticket, bb stewards needs shows the decision with the three choices.
• After the binding is recreated, the decision is still pending, and the wake says the ticket's due date, computed from the alert's created_at and matching Linear; a moved Linear date is shown with the drift named.
• Reminders fire at half, eve and overdue; the digest lists the item under "Needs you".
• bb stewards show lists that the ticket was filed, the decision raised, each reminder, and the settlement, with the filing thread's id.

Tests

npm run typecheck && npm test in stewards (1234 passed), linear (157), github-watcher (84).

Shipping

Merging moves the plugin pin, builds a new bb-server image and stages a restart on every developer's server. Owner-reviewed: a store migration and a contract change (source-contract.ts).

🤖 Generated with Claude Code

[trotterdylan]

Closing to discuss the design first; a ticket will follow. The branch stays.