Skip to main content
← Back to list
01Issue
FeatureIn ProgressSwamp ClubPublic
Assigneeskeeb

Relationships

Blocked↑ child of #2008⊘ blocked by #2012⊘ blocked by #2013⊘ blocked by #2014⊘ blocked by #2015⊘ blocks #2017⊘ blocks #2018⊘ blocks #2019⊘ blocks #2020

#2016 feat(nurture): arm the first flow — extension published, email only, verified in prod

Opened by keeb · 9/4/2026

Parent: the product-nurture epic. The first real send.

Problem

Everything up to here has been verified without contacting a single operative. This issue turns the machine on, once, on the safest possible flow, and proves the whole spine end to end in production.

Why this flow first

extension_published (whiteboard #4, GROW CHAMPION) is the right first arm for four independent reasons:

  1. Event-triggered, not time-triggered. It fires off extension_published, which the app already emits. There is no dormancy window to get wrong.
  2. The cold-start backlog is bounded and inspectable — the set of already-published extensions, which you can count before arming.
  3. It cannot be wrong in a way that hurts. The worst failure is congratulating someone who did publish an extension.
  4. Its occurrenceKey is the extension name, so it exercises the repeatable case rather than the trivial once-ever one — which is the part of the dedupe design most worth proving early.

What ships

  • Arm extension_published, email channel only. The inbox comes in D1; keeping this to one channel means a failure here has one possible cause.
  • The cold-start seal runs first and claims every historical publish. Record the sealed count on this issue before flipping the arm.
  • A per-tick send cap (propose 10) for the first week.

Verification — in production, not just in tests

  1. Confirm the sealed count matches the count of pre-armedAt published extensions, from a hand-run query. If they differ, stop.
  2. Publish a real extension from a test account. Confirm exactly one row moves candidatesent, the email arrives, and the panel shows the provider message id.
  3. Publish a second extension from the same account. Confirm a second row is created (the occurrence key is the extension) and a second mail arrives.
  4. Re-publish a new version of the first extension. Confirm no new row — the key is the extension, not the version.
  5. Run the projector twice in the same window. Confirm zero duplicate sends.
  6. Unsubscribe from the footer link, publish again, confirm the row is suppressed with the reason rendered and no mail is sent.

Steps 3–6 are the ones that actually prove the epic's central claim. Do not skip them because step 2 passed.

Out of scope

Every other flow. Do not arm a second flow in this issue — the whole point is that a failure here has exactly one candidate cause.

02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED+ 1 MOREASSIGNED+ 5 MOREREVIEW+ 2 MORECODE_CONFORMANCE_REVIEW

In Progress

9/5/2026, 12:36:38 AM

Click a lifecycle step above to view its details.

03Sludge Pulse
keeb assigned keeb9/4/2026, 11:19:26 PM
keeb linked parent of #20089/4/2026, 7:41:11 PM
keeb linked blocked by #20129/4/2026, 7:41:44 PM
keeb marked as blocked9/4/2026, 7:41:44 PM
keeb linked blocked by #20139/4/2026, 7:41:45 PM
keeb linked blocked by #20149/4/2026, 7:41:46 PM
keeb linked blocked by #20159/4/2026, 7:41:48 PM
keeb linked blocked by #20179/4/2026, 7:41:49 PM
keeb linked blocked by #20189/4/2026, 7:41:50 PM
keeb linked blocked by #20199/4/2026, 7:41:51 PM
keeb linked blocked by #20209/4/2026, 7:41:52 PM

Sign in to post a ripple.