Revion Crew Board

Today's Linear read: REV-250 "Seven Sigma: get bank details before the 18 Sep payout" is still [Todo] p1 @tim, upd 2026-09-16. REV-256 (sent payouts stuck in processing with no bank reference) is still [Todo] p1 @nur. REV-244 (Cloudflare blocking Seven Sigma's and Bioscience's webhooks) is no longer open, and no commit in the last three days names Cloudflare or a webhook allowlist, so whether callbacks now land is unverified.

New since the last board: REV-272 "Payout ACH batch: one bad merchant profile silently blocks everyone's payout", filed 19 Sep, unassigned. A merchant still missing bank details on payout day is a plausible bad profile. Nothing readable says Seven Sigma's payout went, and Slack, the DB and TG are still blind.

Next action

Ask Andrew in #ach-payouts-production: did Seven Sigma's payout go, with what bank reference, and did any run since 18 Sep stall. If Seven Sigma still has no bank details, get them today and make sure REV-272 has an owner before the next run.

Today's Linear read returns 27 open issues against a query that asks for 50, so that is the whole open list. Of the 50 open at the 18 Sep read, five are still open: REV-256, REV-196, REV-251, REV-250 and REV-247. The other 45 are gone, and the query filters out completed and cancelled alike, so it cannot say which. Among them: REV-266 (Pura dark, frozen orders, callbacks returning HTTP 400), REV-244 (Cloudflare blocking Seven Sigma's and Bioscience's webhooks), REV-261 (the payment detector that matched 0 rows), REV-265 (240 orders, $24,000, no fulfilment evidence), REV-263 (guest orders missing the billing name), REV-234 (embedded box QA), REV-214, REV-258, REV-112, REV-252, and every QA ticket on Narboto's list.

git corroborates exactly one: REV-262, the Synergy phone field, with keep hosted phone optional through card and Apple Pay and preserve supplied phone when Wallet omits it merged as #514 and promoted as #517. No commit in the last three days names Pura, a callback 400, Cloudflare, the detector join or tracking numbers. A cancelled incident ticket and a fixed one look identical from here, and these tickets were the board's only view of Pura, Seven Sigma and Synergy.

Next action

Open Linear's recently closed view and, for the incident tickets at least (REV-266, REV-244, REV-261, REV-265, REV-263), write one line each: fixed by what, or dropped and why. If Pura's REV-266 was cancelled rather than fixed, Pura goes straight back to the top of Aadil's list.

As of the 15 Sep read, #rhp-rhpeptides ended on Jarrod's 1 Sep 05:57Z message: "that text is from the master document, not the one you signed... I will discuss with Aadil today and get back to you." Your 31 Aug 16:36Z answer rested on three things: Revion is the seller of record, "Revion is registered in Florida today", and sections 8.5 and 8.7, which his copy does not contain. RHP: 0 sessions since 13 Sep, fee_rate 14. Slack has been blind for six days.

New in today's Linear read: REV-269 "Decide: enable REVION_TAX_SUPPRESS_STATES=FL on production (stop collecting Florida sales tax)", [Todo] p2 @aadil, upd 2026-09-18. So PR #465's suppression is flag-gated and, per that title, not yet on in production. REV-196 is still [In Progress] p1 @nur, with the refund and TaxJar-purge halves unshipped. Twenty days on, the registration fact is still only Aadil's to give.

Next action

Get Aadil's REV-269 decision and the registration fact together; they are the same question. Then pull a fresh Florida quote, and tell Jarrod only what the quote and the executed agreement actually show.

Carried from the last board, and still the largest change to the buyer path with no owner on record. git carries fix(storefront): require session-scoped 21+ age confirmation (#509) plus test(storefront): confirm age in direct checkout browser checks and fix(catalog): keep retired GLP-1 listings out of seeds, authored by the aadil-netizen account and dated 19 Sep, reaching production through PR #512 (branch codex/age-gate-catalog-production) with a review follow-up in #513. Nur's own 18 Sep commits fill in the shape: bind age approval to its browsing context, exempt hosted merchant checkout from age gate, require direct merchant payments to bypass age gate, remove retired SKUs from local overview fixtures, address promotion review on seed items and age persistence.

Read together: the gate is scoped to a browsing session, hosted merchant checkout is exempt, direct merchant payments bypass it, and retired GLP-1 SKUs are being kept out of catalogue seeds. That is a compliance posture change on the buyer path, not a refactor. It is tracked as GitHub issue #509, which is why no REV number covers it and why this board would never have seen it through Linear. No readable source says who decided it, whether it applies to live merchants' buyers or only Revion's own storefront, or whether a single real buyer has been through it. Linear answered this time and carries no ticket for it either.

Next action

Get two answers today: who authorised a 21+ interstitial and the GLP-1 retirement, and which merchants' buyers actually see the gate. Then load Revion's own checkout yourself and walk it end to end as a buyer. An age gate with a persistence fix already on it, in front of a funnel that is leaking, is a conversion risk and not just a compliance feature.

At the 15 Sep read, mrc_roNy1mlK9Ij5 showed four sessions and zero payment intents: cs_RVasVZH_AAxR1qMea1PK $109.00 and cs_EZO-PKMQnMyecR0VfwTx $3,277.87 (no buyer email), then cs_ZK_B_CCbydE0g6S43ljT and cs_xzPaO8-h-7F5c3TwHr1C, both $69.99 from info@biopepusa.com. Nobody reached the point of submitting a card. The merchant row read https://biopepusa.com as of that read, so the domain trap is plausibly behind them.

The DB has now been blind for six days, so none of this has been re-checked. New and directly relevant: the 21+ age gate and the retired-SKU catalogue change (see the top item) both touch the storefront and catalogue path. BAC Water refusals are the original suspected wall here, and fix(catalog): keep retired GLP-1 listings out of seeds shows the retirement machinery is being actively changed. Whether Biopep's cart now behaves differently, better or worse, is unknown to anyone.

Next action

Email Casey and ask him to retry the $69.99 cart while you watch, and to describe the exact screen he stops on, including whether he is now asked to confirm an age. Get Nur's straight answer on BAC Water separately; a default flip is not the same as confirming what Biopep actually hit.

REV-234 ("QA: embedded Visa box on WooCommerce, plan now, run M1 Wed + M2 Thu with Tim") read [Todo] p1, upd 2026-09-16 on 18 Sep and is gone from today's open list, along with REV-228 and REV-249. Completed and cancelled look the same from here. What git shows is the box being repaired in production rather than verified: #507 then #508 (merged by you) carrying fix: bind reused box URLs to the current payment session and fix: reuse unchanged embedded Woo checkout orders, plus test: expect WooCommerce 1.3.7 release metadata.

Slack and the DB are blind for a sixth day, so there is still no session-level evidence that a real buyer has completed an order through the box.

Next action

Place one real order through the embedded box on a store you control, confirm the charge, the receipt and the Woo order state, and write the result down where the team reads it, since REV-234 is no longer open to carry it.

REV-251 "Apex: cross-check the 25 approved September payments against Matt cancelled orders" is still [Todo] p2 @tim, upd 2026-09-16, in today's Linear read. Matt is almost certainly Matthew Jensen, the Apex contact. Which orders he disputes is still in no readable source.

Worth noting before the reconciliation: fix: reuse unchanged embedded Woo checkout orders and fix: bind reused box URLs to the current payment session (PRs #507, #508) change how an existing Woo order is reused across payment attempts. That is the same seam where a Revion payment and a cancelled Woo order drift apart, so the mismatch set may look different before and after 18 Sep. Check dates when you compare.

Next action

Get the cancelled order numbers from Matt, and check none of the 25 approved payments was built from an order Woo shows cancelled. Note which side of the 18 Sep idempotency change each disputed order falls on. Confirm with Aadil or Nur that the transfer itself cleared, not just that it was approved.

Linear, all updated 21 Sep: REV-276 "Platform architecture: what we reuse from Revion and what is new", [In Progress] p1 @tim; REV-273 "Stand up the Fly.io app, staging and production", REV-274 "Postgres with tenant isolation on day one" and REV-275 "Authentication and the role model", all [Todo] p2 @nur; and fifteen [Backlog] p3 @nur "Platform copy" tickets, REV-277 to REV-291, from "Branded master and merchant provisioning" to "Brand builder engine". What the platform is for, and who asked for it, is in no readable source beyond these titles.

Against that, Nur's live queue in the same read: REV-256 (sent payouts with no bank reference, p1) and REV-196 (Florida tax, p1, In Progress), both last updated 18 Sep; REV-247 (leaked credentials, p1), last updated 16 Sep; and REV-272 (one bad profile blocks every payout), which nobody owns.

Next action

Write the sequencing on REV-276: which live p1s Nur finishes before REV-273 to REV-275 start, and who takes REV-272. A new platform starting while payouts can silently stall is the wrong way round.

app_uHyTgAc1QXxFQKBW (coreresearchpeptides.com) was under review from 1 Sep. REV-214 (verify callback, activate, then send portal credentials) and REV-258 ("Sache's stores: Vyal Labs and Halo Labs USA are still inactive with zero sessions") were both open on 18 Sep and neither is in today's read. REV-267 ("allow approved merchants to set up portal before activation") reached production on 18 Sep through PRs #498, #499 and #500, the change most likely to have moved them.

A closed ticket is not a live merchant. None of the three is in the collector's watch list, and the DB section is unavailable anyway.

Next action

Run onboarding-check.sh against Vyal Labs, Halo Labs USA and Sean Finck's account once the DB is reachable. If any is live, confirm banking_approved and complete bank details before its first payout, since REV-272 says one bad profile can stall everyone's batch.

As of the 15 Sep read: 11 Sep run, Halo $1.32, Zen $801.06; 14 Sep run, Halo $358.16 (Mercury ••••2806), Narboto inc $0.09, Zen $2,491.16; Andrew, 15 Sep 13:12Z: "others got paid". The 27 Aug $1,139.16 (9 orders) has not appeared in any run since and has no visible reference.

BACKLOG.md, still last updated 15 Sep, carries the open version of this as your own item: the 8 Sep (window Sep 1-8) and 11 Sep (window Sep 3-11) runs both carry Halo $1.32 from three $0.50 orders at 12%, on overlapping windows. That is still unanswered, and it is the same failure family as REV-256.

Next action

Ask Andrew for the bank references of the 27 Aug and 1 Sep Halo drafts and of the 15 Sep send, and ask Nur to confirm the same three $0.50 orders were not paid twice across the overlapping windows. REV-163 has left the open list, so this item is now the only place the question lives.

As of the 15 Sep read, #best-peptide-lab: your 31 Aug 09:06Z offer of 20 minutes to run the first embedded order together got no reply, then Slackbot, 11 Sep 09:44Z, the team removed themselves. Merchant row: active, banking approved 2 Sep, contact dev@guardedpaypro.com, fee 12, 0 sessions and 0 orders since 13 Sep.

REV-247 (rotate the "GuardedPay" password leaked in Core Engineering) is still open in today's Linear read, untouched since 16 Sep. As noted before, the payment-links branch naming is a coincidence, not this merchant.

Next action

Email dev@guardedpaypro.com, since Slack no longer reaches them: ask straight whether they are still integrating, and offer a slot to put the embedded box on bestpeptidelab.com with you watching. Mention the age gate if it applies to their buyers, so they are not surprised by a new screen.

#kiyora-peptide-llc, 13 Sep 15:30Z, Andrew: "We confirm receipt of Kiyora Peptide, LLC's notice of termination dated September 13, 2026... As Kiyora did not process any transactions through the Revion platform, there are no processed transactions, settlements, chargebacks, refunds, transaction-related losses, or termination reserve to reconcile." 15 Sep DB read: mrc_zinhzQp6eyBC status=active, 0 sessions. Why a working merchant left without a single sale is in no source, and the DB is blind again.

Next action

Close the account (keys off), send the effective date Andrew promised, and ask one question: what stopped Kiyora switching Revion on. The same answer probably applies to Best Peptide and RHP.

REV-252 "Backend reviewer: hire, or interim AI review on every PR" was [Todo] p3 @tim on 18 Sep and is not in today's open list; nothing readable says what was decided. git since then: #514 (codex/rev262-optional-phone), #517 (codex/rev262-production), #515 (nur/payment-health-engineering-only) and #516 (from sandbox), all merged by beastmmode, with the commits authored by Nur. Before that, #507, #508, #512 and #513 came off codex/* branches too.

Next action

Write down what closing REV-252 meant: who reviews, and what cannot reach production without a live-path check. Confirm who beastmmode is and whether that account should be merging to production.

Whether the ticket is resolved is unverified; there are no billing-inquiry rows in this collection either. BACKLOG.md still carries both halves as open: resolve 4SMZBX4Mswa4R3tzAK5DR as a test (order RC-2026-1000210, Narboto's $1.07, already refunded), then promote PR #355's alert deep links to prod with the next release.

Next action

revioncaps.com/admin/billing-inquiries, Resolve, note "QA daily test, no action". Locally: source ~/RevionCaps/creds.sh && python3 ~/RevionCaps/linear_cleanup_rev60.py (idempotent; it also comments on REV-170).

As of the 15 Sep read, #ach-payouts-production: Andrew 16:19Z, "when do you show payouts starting for apex peptide supply they said they had transactions sept 4-7?"; 16:22Z, "peptide 911 wants to know there status as well". Nur, TG 17:48Z: "Two merchants transacted with matured, payable balances but no payout went out because their banking verification step had not been run. Both are now verified." Apex Peptide Supply $2,267.28 (19 orders settled 3-10 Sep); Peptide911 $262.79.

Today's Linear read: REV-256 "Close out sent payouts: bank reference and sent date, not stuck in processing" still [Todo] p1 @nur, upd 2026-09-18, and a new REV-272, "one bad merchant profile silently blocks everyone's payout", unassigned. If a run stalled on a bad profile, the catch-up may not have gone at all. The payout channel has been unreadable for six days.

Next action

Get Andrew to confirm both ACH transfers carry an actual bank reference, not just a "sent" status, and whether any run since 15 Sep stalled. Only then call Matthew Jensen and James Votraw.

Today's Linear read: REV-269 "Decide: enable REVION_TAX_SUPPRESS_STATES=FL on production (stop collecting Florida sales tax)", [Todo] p2 @aadil, upd 2026-09-18. REV-196, the engineering side, is [In Progress] p1 @nur, with the suppression code merged 15 Sep as PR #465 and the refund and TaxJar purge still to do.

As of the 15 Sep read, Jarrod's copy of the agreement ends at 8.4 (31 Aug 23:48Z), and Tim's 31 Aug message told him "Revion is registered in Florida today" and tagged you on Washington registration timing. Tim promised on 1 Sep to discuss it with you that day; Slack has been blind for six days, so the channel cannot be re-read.

Next action

One answer covers all three: registered in Florida or not. If not, switch the flag on and have Nur refund what was collected; if yes, close REV-269 and tell Tim. Send Tim the executed RHP agreement in the same message.

REV-266 "Pura Peptides dark 36h: fatal error freezes orders, our callbacks now get HTTP 400" was [Backlog] p1 @nur on 18 Sep. It is not in today's open list, and no commit in the last three days names Pura, callbacks or a 400. It may have been fixed on Pura's side, fixed by a change nobody linked, or cancelled; nothing readable tells those apart.

The rest, all from the 15 Sep read and unchanged since: Kiyora terminated (Andrew acknowledged 13 Sep, "did not process any transactions"); Best Peptide's team removed themselves from Slack 11 Sep, 0 sessions; Biopep had four checkouts and none reached a card; RHP had 0 sessions.

Next action

Phone Pura today and ask one question: are orders flowing and getting paid since 18 Sep. Then by phone this week: Best Peptide, Biopep's Casey (with Tim), Jarrod (after the Florida answer), and Kiyora on why they left.

Open since 28 Aug; Nur asked again on the morning of 29 Aug. Whether his payment went out is still unverified, TG has been blind for six days so the thread cannot be checked.

Since the last board, git shows him on the age-gate work (bind age approval to its browsing context, exempt hosted merchant checkout from age gate, require direct merchant payments to bypass age gate, address promotion review on seed items and age persistence), the box-session idempotency fixes behind #507 and #508, the catalogue-retirement fixtures, and the WooCommerce 1.3.7 release metadata. That is on top of the twelve PRs he merged on 18 Sep, and on 19 Sep he shipped the REV-262 phone fix (#514, #517) and moved payment-health alerts out of merchant channels (#515).

Next action

Send it, confirm in the thread.

As of the 15 Sep read: "Synergy Research, LLC" (synergy-labs.uswholesalepeptides.com, mrc_LLEYN7Q4l9fC) live since 15 Sep; "Vyal Labs LLC" (vyallabs.com, mrc_PA2TX_ACHQq5) approved 12 Sep; "Halo Labs USA LLC" (halolabsusa.com, mrc_f4LFsn8VaAaJ, contact Alice Rewoldt) approved 14 Sep. Halo Labs USA is a different business from Halo Peptides, keep them apart in payouts.

git, 19 Sep: Nur's fix(checkout): keep hosted phone optional through card and Apple Pay and fix(checkout): preserve supplied phone when Wallet omits it, merged as #514 and promoted as #517 (codex/rev262-production). REV-262 is no longer open. That is the change Synergy needed; whether it is deployed, and whether a Synergy buyer has paid since, is unverified, and the 21+ age gate now sits on the storefront path too.

Next action

Once #517 is confirmed deployed (Claude's item), tell Synergy the fix is live and ask for their next order number so it can be traced end to end. Ask Nur whether Vyal and Halo Labs USA are live now; if not, chase banking and set them live by hand.

git in this collection carries fix(catalog): keep retired GLP-1 listings out of seeds (authored by the aadil-netizen account, 19 Sep, reaching production via PR #512) alongside Nur's fix(seed): remove retired SKUs from local overview fixtures and test: cover catalog retirement and correct decline fixture. Retirement plumbing for a named product class is being built and shipped.

Nothing readable says whose decision this is, which merchants it affects, or whether they have been told. It also sits directly across the REV-22 denylist thread: Biopep's 14 Sep email asks why BAC Water fails, your 14 Sep 19:40Z "let em run it up" was never implemented in code, and REV-232, the test of whether restricted items are refused at all, left the open list over the weekend with no readable result. A catalogue policy now has three different answers depending on which source you read.

Next action

Say plainly whether GLP-1 retirement is a commercial decision you made, and give one list of what is refused, what is allowed, and for whom. Anyone selling a retired class needs telling before their buyers find out at checkout.

The wall was measured on 2 Sep: $380 and $361 in non-Visa declines over five days. At the 15 Sep read there were 10 production attempts across merchants, 5 authorized, and declines returned "Your card was declined. Please use another Visa card or contact your card issuer."

REV-112 "Apple Pay on NMI, step 0: confirm with Ignacio the MID supports own-certificate Apple Pay" was [Backlog] p2 @aadil at the 18 Sep read and is not in today's; no brand-enablement ticket for Mastercard, Amex or Discover is open either. Apex is on the embedded box, so every non-Visa buyer hitting it is now a measurable loss rather than a hypothetical one.

Next action

Get Ignacio's answer in writing, whatever closed REV-112: does the MID support own-certificate Apple Pay. Separately ask what enables Mastercard, Amex and Discover, and by when.

As of the 15 Sep read, VAPI_PRIVATE_KEY, VAPI_PHONE_NUMBER_ID and VAPI_ASSISTANT_ID were set on revioncaps-prod; calls are held off only by VAPI_OUTBOUND_ENABLED=false, and vapi-outbound.ts has no calling-window, DNC or unbundled-consent gates. No VAPI ticket is in today's Linear read either. BACKLOG.md still carries it as a red item needing you and Tim.

Worth connecting to this week's shipping: the team is clearly willing to put a compliance gate in the buyer path when it decides to, a 21+ age gate went live in two days. The same standard has not been applied to outbound calling, where the exposure is statutory.

Next action

Either unset the prod keys or commission the TCPA gates, and file whichever it is.

With only 27 issues open, REV-164 is back in view: [Todo] p3 @aadil, upd 2026-08-27, untouched for twenty-five days. TG has been blind for six days, so whether the message was deleted cannot be checked. REV-247 (the separate "GuardedPay" leaked credential) is still open too, one of five tickets that survived the weekend clear-out.

Next action

Rotate it, delete the message, close the ticket.

REV-272 "Payout ACH batch: one bad merchant profile silently blocks everyone's payout" is [Backlog] p2 @unassigned, upd 2026-09-19. It lands here because the payout path is yours through REV-256, not because anyone assigned it. The title is the whole of the evidence: no commit in the last three days names the payout batch, and #ach-payouts-production has been unreadable for six days, so whether a run has already been blocked this way is unknown.

It sits on top of everything else on the payout path: REV-256 (sent payouts with no bank reference, still [Todo] p1), Apex and Peptide911's first payouts that were stranded once already, Halo's unreferenced $1,139.16, and REV-250, Seven Sigma's missing bank details, still [Todo] three days past the date. A merchant with incomplete bank details is exactly the kind of profile that could stop a batch, so Seven Sigma is the first thing to rule out.

Next action

Take it or get it assigned today, and move it out of Backlog. Make the batch skip and flag a bad profile instead of stopping, and alert on it. Then check whether any run since 18 Sep was blocked: every merchant due money in that window is owed an answer.

As of the 15 Sep read: your TG 17:48Z, matured balances, "no payout went out because their banking verification step had not been run"; REV-144 shipped 15 Sep to gate future Set-live on banking verification. That closed the cause for new merchants. It does not prove any already-live merchant's balance is actually paid out.

REV-256 is still [Todo] p1 @nur, upd 2026-09-18, one of five tickets that survived the weekend clear-out. It covers Apex and Peptide911's catch-up run, Halo's 14 Sep $358.16, Zen's overlapping-window runs and Seven Sigma's first payout. BACKLOG.md still carries the production-side hole: Set live does not approve payout banking until PR #456 ships, so it has to be done by hand every time.

Next action

Post one list in #ach-payouts-production: every payout marked sent in the last 30 days, with or without a bank reference. Anything without one is not confirmed paid, whatever the status says. Do it together with REV-272, since a stalled batch and an unreferenced one look the same from a merchant's side.

REV-266 "Pura Peptides dark 36h: fatal error freezes orders, our callbacks now get HTTP 400" was [Backlog] p1 @nur at the 18 Sep read and is not in today's open list. No commit in the last three days names Pura, callbacks or a 400; the checkout-side commits in the window are the age gate, the box-session idempotency fixes, the REV-262 phone fixes and the payment-health alert routing.

If it was fixed, it was fixed somewhere git does not show (Pura's own store, config, or a change nobody linked). If it was cancelled, Pura is into its fifth day with no ticket at all. The frozen orders matter either way: whether they were recovered is in no readable source.

Next action

Write one line on REV-266: what the 400 was, what fixed it, and whether the frozen orders were recovered or need refunding. If nothing fixed it, reopen it.

The commits, in order: fix(storefront): require session-scoped 21+ age confirmation (#509) and test(storefront): confirm age in direct checkout browser checks (aadil-netizen, 19 Sep), your fix(storefront): bind age approval to its browsing context, fix(storefront): exempt hosted merchant checkout from age gate, test(checkout): require direct merchant payments to bypass age gate, test(checkout): match the backend decline status, and fix: address promotion review on seed items and age persistence. It reached production through #512 (codex/age-gate-catalog-production) with #513 as the review follow-up, and the sandbox side through #511 (feat/gh-509-session-age-gate-sandbox).

Four exemption or scoping rules landed in two days, which makes the blast radius genuinely hard to hold in your head: hosted merchant checkout exempt, direct merchant payments bypassing, approval bound to a browsing context, and a persistence fix on top. A buyer who confirms once and gets asked again, or worse is blocked mid-payment, is a lost order, and it went live on the same funnel where REV-262's phone field blocked payment until #517 and Biopep's four sessions never reached a card.

Next action

Write the matrix down in one place: which checkout surfaces gate, which are exempt, what the buyer sees, and what happens when the stored approval is missing or stale. Then walk one live buyer path per surface yourself. The board cannot tell whether this helps or costs money, and right now neither can anyone else.

REV-247 "Delete the credentials and bank details posted in Core Engineering, rotate the GuardedPay password" is still [Todo] p1 @nur, upd 2026-09-16, one of five tickets that survived the weekend clear-out. How long it has been exposed and who posted it is in no readable source; TG has been blind for six days so the message itself cannot be checked. REV-164 (the separate A@ Google password) is in the same state.

Next action

Delete the message, rotate the password, and check whether anything was accessed with it while it was live.

REV-196 "Turn OFF Florida sales-tax collection until registered: $0 FL quotes, refund collected tax, purge TaxJar test transactions" is still [In Progress] p1 @nur, upd 2026-09-18. PR #465 (merged 15 Sep) covers the quote half. New in today's read: REV-269 "Decide: enable REVION_TAX_SUPPRESS_STATES=FL on production", [Todo] p2 @aadil, so the suppression only takes effect once that variable is set on production. No commit in the last three days touches tax.

Next action

Tell Tim plainly whether a Florida quote on production returns $0 today; from REV-269's title it should not. Have the refund and TaxJar purge ready to run the moment Aadil decides, so the flag and the refunds go out together.

REV-244 "Seven Sigma and Bioscience: Cloudflare blocks our webhook, callbacks never arrive" was [Todo] p2 @nur, upd 2026-09-18, at the 18 Sep read. It is not in today's open list, and no commit in the last three days names Cloudflare, a webhook allowlist or callbacks. The block may have been on the merchants' side and lifted there; nothing readable says.

It was one of three callback-path failures in a week: REV-226 cancelling paid Apex orders, REV-244, and Pura's REV-266 callbacks returning HTTP 400. All three are now off the open list.

Next action

One line on REV-244: what Cloudflare was blocking and what changed. Then confirm a real callback has landed for Seven Sigma since, before anyone reconciles their orders or pays them out.

REV-261 "REV-142 shipped a dead detector: gateway failure streak join matches 0 rows on prod" was [Backlog] p1 @nur on 18 Sep and is not in today's open list. Also gone: REV-165 (funnel and decline report), REV-145 (plugins page) and REV-173 (telemetry null). No commit in the last three days names the detector's join.

What git does show is your Keep payment-health alerts out of merchant Slack channels, merged as #515 (nur/payment-health-engineering-only) and carried by #516 from sandbox. The title implies payment-health alerts could post into merchants' own channels. If the detector fires now, that is progress; if a merchant saw an internal failure alert in their channel, someone should have that conversation before the merchant raises it.

Next action

Say whether the detector fires on real prod data now, and list any merchant channel that received a payment-health alert before #515. Then add the age-gate counter: shown, confirmed, abandoned.

promote/m2-full (#502) and promote/wave1-safe-fixes (#501) reached production on 18 Sep. Immediately after, #507 and #508 (codex/box-session-idempotency, then -production, merged by Tim) carried fix: bind reused box URLs to the current payment session and fix: reuse unchanged embedded Woo checkout orders, plus test: expect WooCommerce 1.3.7 release metadata.

A reused box URL not bound to the payment session is a cross-session risk on a live checkout, and it was found after the switch rather than before it. REV-234, the QA ticket that was meant to gate this, and REV-228 itself have both left the open list with no pass or fail recorded anywhere readable. The plugin's release metadata has also moved to 1.3.7 while REV-249's manual QA cases were written against 1.2.34.

Next action

State what #507 and #508 actually fixed in buyer terms, and whether any live order between the switch and the fix could have been affected. Then pin the live plugin version so QA is testing what is deployed.

New in this collection: fix(catalog): keep retired GLP-1 listings out of seeds, fix(seed): remove retired SKUs from local overview fixtures, test: cover catalog retirement and correct decline fixture and test: use workspace export for catalog seed regression. So there is now a retirement path, with regression coverage, shipped to production via #512.

Against that: REV-241 (PR #461) changed prohibited products to allowed by default on 15 Sep, REV-232 "restricted items still refused with the alias on" left the open list over the weekend with no readable result, REV-231 has been off the open list since 16 Sep, and Biopep's BAC Water is still refused in code despite Aadil's 14 Sep "let em run it up". Four sources, four different answers about what a merchant may sell.

Next action

Write the one true statement of the rule: per merchant, what is refused, what is retired, what is allowed, and which flag controls it. Until that exists, nobody should treat "restricted items are refused" as true for any merchant, and REV-232 closing proves nothing about it.

At the 18 Sep read: REV-265 "No order has ever had a tracking number: 240 orders ($24,000) past ship date with no fulfilment evidence" [Backlog] p2; REV-263 "Guest orders not fixed: plugin still never writes the billing name (REV-230 closed early)" [Backlog] p1; REV-268 login hardening [Backlog] p3. None is in today's open list, and no commit in the last three days names tracking, fulfilment or the billing name.

REV-263's own title is the warning: it exists because REV-230 was closed before the behaviour changed. Three tickets leaving at once with no code is the same pattern until someone says otherwise.

Next action

One line each on REV-265 and REV-263: fixed by what, or dropped and why. If REV-265 was dropped, pull a sample of the 240 and check whether tracking exists outside Revion (carrier, Woo) before a dispute asks.

REV-226 ("Webhook timeouts cancel PAID Woo orders") had two merges through 15 Sep: #455 (ack-then-process) and #457 (bound delivery lifetime within outbox lease). New in this collection, and closer than anything before it: fix: reuse unchanged embedded Woo checkout orders and fix: bind reused box URLs to the current payment session, shipped to production as #508.

REV-226 is not in today's open list, but that is hardening on the same path, not the reconcile sweep. No commit anywhere names reconciling the orders the original bug already cancelled, and Aadil has an Apex call pending that needs exactly that number.

Next action

Confirm #455 and #457 are actually in production, then run the one-off reconcile of Apex orders Revion shows AUTHORIZED and Woo shows cancelled, and give Aadil the count before his call. Say whether #507 and #508 change the reconcile logic.

Linear, all upd 2026-09-21: REV-273 "Stand up the Fly.io app, staging and production", REV-274 "Postgres with tenant isolation on day one" and REV-275 "Authentication and the role model", all [Todo] p2; REV-277 to REV-291, fifteen [Backlog] p3 "Platform copy" tickets covering provisioning, storefront themes, order editing, supplier catalogue, warehouse fulfilment, lot and COA traceability, purchasing credit, affiliates, wholesale, label artwork, order and money history, support and onboarding, email and retention, reporting and the brand builder. REV-276, the call on what gets reused from Revion, is Tim's and In Progress.

Your live-business p1s in the same read have not moved: REV-256 and REV-196 last updated 18 Sep, REV-247 on 16 Sep, and REV-272 has no owner.

Next action

Hold REV-273 to REV-275 until Tim writes the sequencing on REV-276. If they are already under way, say so there, so nobody reads the live p1s as abandoned.

REV-189 has stayed off the open list, and no commit in this collection names fee rates. At the last code read, zod locks feeRate to 12|14 in three places, sandbox-provisioning-client.ts:66 refuses other values, and settlement.ts guards fee_rate IN (12, 14) twice. REV-246 (Pura's NMI batch cutoff time) has since left the open list.

Next action

While you are in Pura's account for REV-266, read the merchant row: if it went live at 12 or 14 against an 8.5 contract, tell Aadil; if 8.5 is stored, prove it passes both settlement guards.

emails.ts:368 carried the "processing is disabled" line at the 2 Sep read. REV-169 "Fix the merchant credentials email copy" read [Duplicate] on 18 Sep and has left the open list since; no readable source names which ticket absorbed it. REV-214, the most likely candidate on the same send path, has left the open list too, and REV-267 has now changed that path further by letting approved merchants into the portal earlier.

Next action

Find the canonical ticket REV-169 points at and confirm the copy itself changed. With REV-267 live, more merchants now receive this email before activation completes, so wrong copy reaches more people.

As of the 15 Sep read: opt-in NMI reversal reconciliation "and atomic accounting" (#443), linked reversals held before reporting to the ACH generation fence (#445), external refund parent and original payment verified (#448), an exception review queue with opt-in Slack alerts (#452). At the last code read settlement.ts deducted refunded_cents but never recalculated fee_cents down, and MFSA 16.4 argues it should.

Next action

One line: does #443's accounting reduce the fee share on a partial refund? If not, add it before reconciliation is switched on for real merchants.

As of the 15 Sep read, Biopep now reads https://biopepusa.com. Application websites: Research Chemical LLC https://www.researchchemical.com; Veri 7 labs https://veri7labs.com followed by a zero-width U+2060 character. Whether either merchant row carries the application value is unverified. The 18 Sep canonical-domain batch (#494, #495) fixed how links are built, not what is stored per row.

Next action

Read both merchant rows once the DB is back and fix by single-field update if needed, then normalise domains at registration so the next merchant cannot arrive broken.

slack_provisioning_status and _error exist on the merchant row but nothing shows them. Departures are just as invisible: Halo's consultancy left #halo-peptides on 23 Aug, Best Peptide's team left #best-peptide-lab on 11 Sep.

Next action

Show invite state and external-member count per merchant in admin, and post to Slack when a merchant's last external member leaves.

Asked in Core Engineering 31 Aug 13:48Z: "Would be sick if we had the customers number ready for anyone/me/andrew/pat to call them right away too." The buyer's phone is collected at checkout; the billing-inquiry queue and its alert email do not surface it. No such ticket is in today's Linear read.

The same field just had its REV-262 fix (#514, #517), so the code is fresh in hand.

Next action

Show the buyer's phone on the billing-inquiry admin view and in the alert email, and file it in Linear with the LLM pre-check block.

support_admin_alert emails to support@send.revioncaps.com showed [failed] repeatedly from about 28 Aug. REV-146 was last confirmed [Todo] p2 on the 16 Sep read, then disappeared from the 17 and 18 Sep pulls after a batch of follow-up commits and a plugin repackage. It is not in today's Linear read either.

Next action

Confirm REV-146's real status, then check one actual support_admin_alert delivers before calling the sending-domain question closed.

The gate reached production on 19 Sep via #512, with #513 as a review follow-up. The commits that define its behaviour: require session-scoped 21+ age confirmation (#509), bind age approval to its browsing context, exempt hosted merchant checkout from age gate, require direct merchant payments to bypass age gate, address promotion review on seed items and age persistence, plus confirm age in direct checkout browser checks, which is the only test evidence on it and was written by the same author as the feature.

This is the highest-risk untested surface on the board right now, because it sits in front of payment and it fails in the direction of blocking a buyer. The detector that would notice a funnel collapse is confirmed dead (REV-261), so a regression here stays invisible until a merchant complains.

Next action

Test it on your own store, not a merchant's: confirm once and pay; refuse and check what the buyer sees; confirm, close the tab, return, and check whether you are asked again; run it on the hosted path and on the direct path; check a returning buyer mid-payment is never re-gated. One line per case, posted where Nur and Tim will read it.

REV-257 (reproduce the Synergy failure) and REV-262 "Checkout phone field says 'optional' but blocks payment (Synergy Labs, live)" have both left the open list. git backs this one: Nur's fix(checkout): keep hosted phone optional through card and Apple Pay and fix(checkout): preserve supplied phone when Wallet omits it, merged as #514 and promoted as #517. Deployment to the Fly apps is unverified, and the 21+ age gate now sits on the same storefront path.

Next action

Run the cases the fix claims on your own store: card with no phone, card with a phone, Apple Pay where the Wallet omits the phone, Apple Pay where it supplies one. Then trace Synergy's next real order end to end and say whether a buyer completed a purchase; do not infer it from the ticket closing.

REV-234 "QA: embedded Visa box on WooCommerce (REV-233), plan now, run M1 Wed + M2 Thu with Tim" read [Todo] p1, upd 2026-09-16 on 18 Sep and is not in today's open list; REV-249 (the ten manual cases) and REV-228 are gone too. No readable source records a run, a pass or a fail. Meanwhile #507 and #508 put bind reused box URLs to the current payment session and reuse unchanged embedded Woo checkout orders into production after Apex switched, a defect class QA would have been looking for.

The version gap still stands: test: expect WooCommerce 1.3.7 release metadata means the live plugin has moved well past the 1.2.34 the cases target.

Next action

Post two lines where Tim and Nur will read them: did M1 and M2 run, and against which plugin version. If they did not, run them on 1.3.7 before anyone calls the box verified.

As of the 15 Sep read: Tim estimated about 9 of 20 real buyers reached the page and never submitted a card, and replay review was the next step; no result has been visible in any source since. Targets: Biopep cs_EZO-PKMQnMyecR0VfwTx $3,277.87, cs_RVasVZH_AAxR1qMea1PK $109.00, cs_ZK_B_CCbydE0g6S43ljT and cs_xzPaO8-h-7F5c3TwHr1C (both $69.99).

With Slack and the DB blind for six days, replays are the one source of buyer-level truth that does not depend on the collector. They are also the fastest way to tell whether the new age gate is adding an abandonment point.

Next action

Watch the four Biopep replays, and while you are in there watch any post-19 Sep session that hits the age gate. One line each on Biopep to Nur for REV-231 and to Tim.

As of the 15 Sep read: the 14 Sep payout run listed Narboto inc at $0.09 to a test bank account, Andrew refused to send it, Aadil asked for test accounts to be removed from payouts, and Nur agreed the next run leaves them out. Halo orders RC-2026-1000228, -232, -233, -235, -236 and -242 (all $0.50) were unrefunded at the 2 Sep read; whether a refund landed since is unverified. Tim's overlapping-window question in BACKLOG.md is about three of these same $0.50 orders.

Next action

Refund the six from admin, confirm with Nur that test merchants are flagged out of payout runs, and move dollar tests to your own store.

In the 21 Sep 13:06Z collection, Slack (channel list and all 8 channels), the prod DB (all six tracked merchants, plus the JSON decode error on the raw read) and TG Core Engineering returned SECTION UNAVAILABLE. Linear, git, BACKLOG.md and the marks endpoint answered. Same missing-PATH signature as 2, 7, 8, 9, 10, 12, 14, 16, 17, 18 and 19 Sep.

New finding from the run logs: the TG send in generate.sh fails with generate.sh: line 79: node: command not found, and launchd.out records "TG post FAILED" after the 15, 16, 17, 18 and 19 Sep publishes. The daily post is the only thing that tells the team a board exists, which fits the empty marks on the 19 Sep board. Today's post will fail the same way unless PATH is fixed first.

Next action

Add an explicit PATH export (node, flyctl) at the top of collect.sh and generate.sh, or tell Tim in one line that it needs a human hand on the machine. Then re-run collect.sh by hand and resend today's TG post. Four boards have now named this fix without it being applied.

Production-side merges not yet confirmed rolled: #517 (codex/rev262-production, the phone fix) and #516 (from sandbox, carrying #515's payment-health routing), both 19 Sep; #508 (codex/box-session-idempotency-production, merged by Tim), #512 (codex/age-gate-catalog-production) and #513 (codex/age-gate-review-followup); and the twelve PRs from 18 Sep (#283, #494 through #504). Merged is not deployed: prod CD needs the CLAMAV and CDR tokens and rolls seven Fly apps, and a missing build-arg has crash-looped the API before.

This matters more than usual because the two changes point in opposite directions if only one lands. If the age gate rolled and the box-session fix did not, buyers get a new blocking step on a checkout that can still reuse a stale box URL.

Next action

Once PATH is fixed, run flyctl releases per app and check the release tag for #508, #512, #513, #516 and #517 specifically, then confirm on the live storefront whether the age gate renders and the phone field is optional. Never place a payment on sandbox.revioncaps.com: prod keys.

Today's run log: collection at 13:06Z (195 bundle lines), then "API Error: Can't reach the API server ... (ENOTFOUND)" and "compose attempt 1 failed (exit 1) - retrying in 5 min". This board is the retry, composed on a bundle more than five hours old. On 19 Sep the same error failed two attempts and that page was only caught up on 20 Sep, from the 19 Sep bundle.

Both gaps are mechanical: three attempts five minutes apart cannot ride out a network outage, and generate.sh composes on a bundle of any age without saying so.

Next action

In generate.sh: widen the retry backoff, and re-collect before any retry that starts more than about two hours after collection. Both are smaller than the PATH fix.

The DB watch list is still six merchants (halo, rhp, kiyora, zen, bpl, biopep) and the channel list eight. As of the 15 Sep read, live merchants also included Apex Peptide Supply mrc_Jj7KJ7lPbJSh, Bioscience Peptides mrc_gUkKa0d4TClA, Veri 7 labs mrc_7RFYJXz5hHPT, Epic Wholesalers mrc_i1ZcMuL8KlKJ, Research Chemical mrc_Vhs6nzY0_j-c, Peptide911 mrc_PCV1-S_xcogf and Viltrumite Lab mrc_4oOU2meLCons; none is tracked.

Pura, Seven Sigma and Synergy were only ever visible through their Linear tickets. Those tickets have now left the open list, so even with every source answering, the board would say nothing about them.

Next action

Add Pura, Seven Sigma, Synergy and Apex to MERCHANTS and their channels to CHANNELS in collect.sh, then derive both lists from the DB so the next go-live is tracked without anyone remembering to add it.

The live threads are the age gate's effect on real buyers (merged to production via #512), Synergy's first order after the REV-262 fix, and whether Pura is actually trading now that REV-266 has left the open list. Biopep's next attempt is still open too, with none of four sessions reaching a card as of the 15 Sep read. watch-merchant.sh could not be run in this collection; node and flyctl were both off PATH again.

Next action

REV-266 and REV-262 are both off the open list, so this watch is the only check left on either. Once PATH is fixed, watch the next live order end to end through the gated checkout, confirm charge, receipt and Woo order state, and post the result where the team reads it, since REV-234 is no longer open.

File one labelled Charge inquiry via the sandbox public support endpoint and confirm the alert email carries both admin links. (Claude's live POST was classifier-blocked, so it needs a human-run curl or Tim's go.) It pairs with Nur's failing support_admin_alert item, possibly closed by REV-146, same send path either way. BACKLOG.md still lists both halves as open.

Slack, the DB and TG read SECTION UNAVAILABLE in the 21 Sep collection, so there is no fresh merchant signal to sweep. Linear answered and showed 45 of the 50 tickets open on 18 Sep gone; git showed the REV-262 phone fix promoted (#514, #517) and payment-health alerts kept out of merchant channels (#515, #516). Slack, DB and TG items carry over from the 15 Sep 18:32Z read. Drafts go to the owner on this board; nothing is sent from here.