The daily meter charged 100 credits for every day a campaign was shown,
with no end date. It produced 74-day queues, and worse, each new campaign
added 100/day of charges while adding no inventory: on 18 September, 15
campaigns were charged 1,500 credits against a platform that had produced
367 login impressions in its entire life. That had stopped being a pricing
inefficiency and become members paying for delivery that did not exist.
Now: 3,000 credits buys 30 days of unlimited impressions, charged once at
purchase, with no delivery promise — the model Marty wanted, matching how
ClickBaitPays sells theirs. The price is deliberately identical to 30 days
at the old daily rate, so nobody pays more than before; they just get a
known end instead of an open-ended drain.
It reuses the `featured` shape, which was already a flat up-front buy that
runs to `expires`. Both daily meters — MySQL and JSON — now skip any
campaign with an expiry, so a slot can never be metered. The existing
sweep closes it on day 30 and returns anything unspent.
qa/login-slot.mjs, 9 checks, including that the slot price still equals
30 days at the old rate and that neither meter can touch a slot campaign.
Member walk clean.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Splitting system messages out of the modal was right for payout receipts,
but it would have silenced two that a member genuinely loses money by
ignoring:
- "@someone is trying to buy. Link your wallet so it pays you" — a sale
is blocked right now, and the referral is lost permanently once it
routes to someone else.
- "You missed 43 POL on InstantAdPay" — a payout passed them by, and the
message explains exactly how to stop the next one doing the same.
So the dividing line is not system-versus-human, it is "does this need you
to do something". Those two become kind 'alert' and still interrupt; the
receipts stay kind 'notice' and stay in the inbox.
The modal no longer credits an alert to a person either. It was saying "A
message from @martbost" over machine-generated text, because system mail
is sent by member 1 at ADMIN_EMAIL. Alerts now read "Action needed on your
account".
Also reclassified "X is now in your line for good" as a notice — it is
good news about a referral the member gained, with nothing at stake.
qa/messages-notice.mjs now covers both lanes: 14 checks, including that an
alert interrupts and a flood of 25 receipts does not.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Marty hit this viewing daily ads: a popup after every single return to
the dashboard, each one a different payout notice.
Two causes, both fixed.
The channel was shared. "You just got paid 40.8923 POL" and "Welcome to
my line, here are your first three moves" were stored identically, as
kind 'broadcast' — the kind the sign-in modal is meant to interrupt for.
Dismissing one just promoted the next unread notice, so a backlog became
a carousel. System messages are now kind 'notice': they land in the
inbox, count toward its badge, and never pop. Only a message a person
actually wrote can interrupt.
The modal also had no memory. loadDashboard() runs on far more than
sign-in — after every ad view, campaign edit and chat close — and it
re-popped each time. It now shows at most once per page load and never
twice for the same message.
The 79 existing machine-generated rows are retagged by a migration in
ensureSchema, 15 of them unread and currently popping. Matched on
subject rather than sender on purpose: these come from member 1 at
ADMIN_EMAIL, which is also Marty's own member address, so his genuine
broadcasts sit under the same sender and must be left alone. Verified
against the live data first — "Credits returned: a counting error on our
side" and the broken-banner note are his, and stay as broadcasts.
qa/messages-notice.mjs covers it: a flood of 25 notices produces no
interruption, the human message still does, and chat stays in its own
lane. Member walk clean.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
I read campaigns.received_today as a per-day counter and told Marty the
platform delivers about 2,700 clicks a day. It doesn't. That column is
only a daily figure while the nightly cron resets it, and that reset has
stopped running, so the value is an accumulation since it last ran.
The permanent click ledger is unambiguous: roughly 40 to 50 clicks a day
across the whole platform. It also agrees exactly with ordered-minus-
remaining on every campaign, which is a good independent check that the
read-never-derive design is reading the right thing.
So MAX_CLICKS drops from 10,000 to 2,500. At the real volume a 10,000-click
booking would hold the top of the offerwall for most of a year.
The pack-2 placement is working as intended and is already measurable: the
three backfilled campaigns took 14 of the platform's 17 clicks today.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A campaign's name is the member's own internal label, and some of them are
two characters ("MG"). DripOffers rejects anything under five, and more to
the point a click-earner scanning the offerwall learns nothing from "MG".
So the ad's own headline comes first, then the label, and a very short
label is qualified with the destination host — "MG (mailer.gold)" — rather
than dropped or dressed up in marketing copy we invented on the member's
behalf. Nothing usable at all returns null instead of a made-up title.
Found by the backfill: campaign 88 failed on it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Third syndication rail. The first two send impressions; this one sends
clicks — a real person picks the offer off the offerwall, goes to the
member's link, and has to stay the dwell time before anyone is paid.
Two things it does that the other rails can't:
- It carries geo-targeted campaigns. DripOffers filters on an explicit
country list, so a campaign aimed at Tier 1 finally reaches an outside
audience instead of staying on our own site. Tier-3-only campaigns are
skipped rather than quietly sent worldwide, because an inclusion list
can't express "everywhere except the other tiers" and widening it would
deliver exactly the traffic the owner chose to exclude.
- Delivery is counted, not derived. It reads rows from the platform's
permanent click ledger. It never computes delivery as ordered minus
remaining, and pausing never zeroes remaining — that pair is what
charged members for impressions that never ran on Network Ad Space.
Also fixes two live bugs found while wiring it: the AdRevLinks pause was
nested inside the Network Ad Space check in both the end sweep and
setStatus, so with NAS switched off an ended or paused campaign kept
running on AdRevLinks. Each rail is now checked on its own.
Caps: 1,000 credits minimum, 10,000 clicks maximum per campaign. Not for
cost — Marty owns the platform and these placements are free — but because
the whole site delivers around 2,700 clicks a day, and one campaign
booking 50,000 would sit in the list for weeks.
Inert unless DRIPOFFERS_BRIDGE_URL and _KEY are set. 26 checks green
against the live endpoint; member walk clean.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Second delivery surface for member campaigns, and deliberately the opposite shape to the
Network Ad Space rail: that one is Tier 3 heavy, this one only has prices configured for
US, CA, GB, AU, NZ and UM, so its traffic is Tier 1 by construction.
The AdRevLinks database is not reachable from this server, so rather than opening a
database port to the internet there is a narrow authenticated endpoint on that box which
does the insert locally. Five actions, no general query surface: a leaked key can only
create or remove popup campaigns. The secret lives outside that server's webroot and is
compared in constant time; Apache there strips Authorization, so it travels as
X-Bridge-Key.
adrevlnks.js mirrors nas.js, with two rules carried over from this morning's billing bug:
- DELIVERY IS READ, NEVER DERIVED. status returns the rotator's own per-country counters.
Nothing is computed from a figure a stop could overwrite, which is exactly what charged
16 members for undelivered impressions on the NAS side.
- EVERY WRITE IS IDEMPOTENT. Each campaign carries ref "iap:<id>", so a retry after a
timeout returns the existing campaign instead of booking a second one.
Capped on purpose. That server serves roughly 5,500 popup impressions a DAY in total,
shared by every active campaign, and its rotator favours whichever has delivered least. So
syndicating everything unchecked would starve what is already running, Marty's own ads
included. Hence a credit floor and a per-campaign view cap. Cost is not the reason: he owns
the platform and treats the placements as free. Finite shared inventory is the reason.
Hooked into create, pause/resume and the scheduled end sweep so both networks stay in step.
Inert unless ADREVLNKS_BRIDGE_URL and _KEY are set, and a bridge hiccup can never block a
campaign going live.
qa/adrevlnks-bridge.mjs (15 assertions) drives the REAL endpoint: under-floor campaigns
skipped, full credit value booked, Tier 1 targeting, retry returns the same campaign,
delivery read back, pause/resume mirrored, then deleted and confirmed gone. Creates only
paused campaigns so no live traffic is spent, and leaves nothing behind.
nas-served 8, fraud-allow 12, sponsor-note 5, chatbot-parse 35, qa/run.sh member 0 bugs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Network Ad Space has no stop flag. Its serving query only picks rows with remaining>0,
so zeroing that counter is the only way to halt an ad. But delivery is derived as
assigned - remaining, so the moment an ad was stopped it read back as 100% DELIVERED.
That was not only a reporting error. reconcileNas() runs every five minutes, had no
status filter, and CHARGES member credits off that figure. So pausing a campaign, or
ending one, made the next reconcile pass bill the member for the entire unspent budget
as though it had all been served.
Measured on production before the fix: 23 member campaigns across 16 members, every
single one charged to exactly 100% of budget, 11,437 credits in total, against on-site
delivery evidence of roughly 4,700 impressions. A naturally exhausted ad also ends at
remaining=0, so the two cases cannot be told apart after the fact, which is why the
true figure has to be captured before the stop.
Three changes:
- nas.deactivate() now reads the real served count BEFORE zeroing and returns it.
- a new ads.stopNas() helper is the only path to a stop, and it persists that figure as
the campaign's final delivery. No caller touches nas.deactivate() directly any more.
- reconcileNas() only processes campaigns with status='active'. A stopped ad delivers
nothing further, so there is never anything legitimate left to charge for.
qa/nas-served.mjs (8 assertions) stubs the NAS layer and drives the real code: pausing
records the true 3,000 rather than the 10,000 allocation, a paused campaign is never
charged afterwards and its figure never jumps to the allocation, and an active campaign
still reconciles and is charged normally so the guard did not break delivery.
fraud-allow 12, sponsor-note 5, chatbot-parse 35, qa/run.sh member 0 bugs.
Historical delivery is not recoverable: the stop overwrote the only record of it.
Refunding the 11,437 credits to the 16 affected members is Marty's call, pending.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Marty approves specific people for multiple accounts (partners, staff, a spouse on a
shared machine) and needed a way to say so without the guard fighting him.
Admin > Members > Duplicate signals now carries an "Approved exceptions" list: add an
email with a note, see who is on it and when, remove one. It sits directly under the
signals so the two are read together.
An exception can be added against the address they ALREADY have, not just the new one.
That matters because the usual case is approving a person before their second address
exists, and at sign-up time the new address is unknown to us. checkSignup now tracks
every account the sign-up collided with, and clears the block if either side is approved.
Clearing the HARD flags matters as much as clearing the block. Those flags are what
silently drop an account off the leaderboard and bar it from adopting out of the holding
tank, so an approved person would have been "allowed" in name only. They now keep both.
The account is tagged 'allowlisted' instead, so the admin sees why it went through, and
the server logs the exception by name.
Suspension still wins. An exception is permission to hold several accounts, not immunity
from being suspended for something else.
qa/fraud-allow.mjs (12 assertions) boots its own server and walks the real flow: first
account created, second blocked with the Qualified Start redirect, exception added,
second account now created, no hard flag left on it, exception visible in the admin
report, removing it blocks again, malformed address refused, endpoint admin-only.
qa/sponsor-note.mjs 5, qa/run.sh member 0 bugs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Marty signed in and was told "You're joining the line of @bliss". He is member #1.
Cause: the last-touch sponsor cookie lives 30 days, and /api/sponsor set invited
purely from that cookie. So any member who had ever clicked a teammate's invite link
was greeted on the sign-in screen as though logging in would place them under that
person. Untrue, and alarming in exactly the wrong place: their sponsor locked at their
first purchase and nothing on that screen can move it. Anyone seeing that would
reasonably worry their line was about to change.
The greeting now shows when someone actually arrived through a link (?ref= in the URL),
or when the cookie is present AND this browser has never had an account, which is the
genuine "came back later to finish joining" case. A browser that already has an account,
or a signed-in session, never sees it.
Attribution is deliberately untouched: the cookie still resolves, the sponsor id is
still returned, and placement still works exactly as before. Only the greeting changed.
fraud.hasAccountOnDevice(req) is the new signal, reusing the device cookie the
one-account-per-person checks already set.
qa/sponsor-note.mjs (5 assertions) boots its own throwaway server and creates a REAL
account so the case is proven rather than assumed: still greeted with ?ref=, still
greeted from the cookie on a browser with no account, NOT greeted on the browser that
has one, and attribution still resolving. qa/run.sh member: 0 bugs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Follow-on to the risk rewrite. Two gaps it exposed.
Members ask this without the word PIF: "should I fund their first package", "can I
buy it for them", "can I front someone the $20". Those were falling through to the
AI, which answered reasonably but told the member to "read the full warning on your
training page" - a page section that does not exist and that they would go looking
for. The pattern now also matches a paying verb plus an explicit for-someone-else
phrase, so these get the full canned answer with the risk in it. It deliberately
needs BOTH halves: "which package should I buy" must not be stolen.
The prompt now forbids sending anyone to a warning, guide or page section that is
not in the PAGES list, and requires plain ASCII (the model was emitting non-breaking
hyphens in "Wi-Fi").
Fixed two first-match-wins routing bugs, one of them mine from the previous commit:
"what do I get for buying a package" was returning the commission split, because I
had widened the earnings pattern to "what do I get" when it should only ever have
been "what do I get paid". And "should I buy the $20 package" previously matched
nothing at all and burned an AI call on a question we have a written answer for.
CANNED is an ordered list, so any pattern edit can silently steal a neighbour. The
suite now pins a 19-case routing table across PIF, price, earnings and the tank, so
the next person to widen a regex finds out immediately. qa/chatbot-parse.mjs is 35
assertions. qa/run.sh member: 0 bugs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Marty: the answer has to cover what a member is risking when they send POL to
somebody they have not spoken to and have no commitment from.
The canned answer now leads the advice with "do not send anything until you have
actually talked to that person and they have told you they will use it", then says
plainly: the transfer is wallet to wallet and irreversible, there is no refund and
no chargeback, support cannot pull it back, the gift is theirs whatever they do with
it, and they are free to go quiet or spend it on something else without breaking any
rule. It names the worst case for what it is, which is that a tank member joined
with nobody working with them and may never have engaged, so an unanswered PIF is
the easiest money on this site to lose.
It gives the arithmetic both ways rather than only the upside: a gift that works
costs about half, because the contract pays the sponsor 50 percent when they buy;
a gift to someone who never answers costs all of it. It ends on never gift money
you need and never borrow to do it.
The same guidance goes into the AI prompt as a standing rule, so PIF is never sold
as a tactic on any phrasing that misses the canned pattern, and a "should I PIF
someone from the tank" question starts with talk to them first, not the mechanics.
qa/chatbot-parse.mjs is now 16 assertions: the 9 response-shape cases plus 7 that
pin each risk line, so a future rewrite cannot quietly drop them.
qa/run.sh member: 0 bugs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Marty hit "I hit a snag answering that one" on "Should I pif someone from the
holding tank". Two separate problems behind it.
The real bug: OpenRouter pads a slow upstream with keepalive lines before the JSON,
and when the provider gives up it can close having sent ONLY that padding. HTTP 200,
no body. JSON.parse threw and EVERY non-canned question died the same way, not just
this one. Now we find the actual JSON object in the stream, treat an empty answer as
a failure rather than sending a blank reply, retry once (the usual cause is one
provider dropping the request), and if both attempts fail we say plainly that it was
our side, not their question, and point at a person.
The content gap: PIF and the holding tank were in the system prompt but had no canned
answers, so they depended on the AI being up. Both are now canned and instant. The PIF
answer leads with the thing the question gets wrong, which is that you cannot PIF
somebody still in the tank: adopt first, they link a wallet, then the button appears.
It is honest that nothing obliges them to buy, that crypto transfers are irreversible,
and that the 50 percent coming back only happens if they actually purchase.
Also fixes a pre-existing routing bug found while testing: "how much do I earn"
returned the PACKAGE PRICE ladder, because the price pattern matches "how much do"
and the commission pattern only caught "how much earn".
qa/chatbot-parse.mjs (9 assertions) drives the real parse branch against a stub
server for every response shape: keepalive-only, keepalive-then-JSON, plain JSON,
SSE comments, empty content, non-JSON. qa/run.sh member: 0 bugs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Audit against the live site: removed stale text (featured links and visit packs marked "coming",
Pipeline "coming soon", the superseded sponsor-hold rule, a non-existent home-page calculator,
"earned credits spend on banner and text only", "Coaching pane"); added live featured and visit-pack
rules with prices and limits, the video cap and rewards, the sign-in bonus and claim ladders,
report-an-ad, the public missed-payout posts, the walk-up gain notice, the four-minute overview
video, the promo Videos and Toolkit tabs; new canned answers for featured links, visit packs and
"what is this". KNOWLEDGE_DATE constant + qa/chatbot-sync.mjs (run in public/all QA) fails when a
release note is newer than the chatbot's knowledge.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Headless Playwright checks that boot a throwaway local copy for anything that
signs in or writes; npm run qa / qa:public / qa:member / qa:earn.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
martbost