Treat warmup content as a shared library in settings and admin tables, and realign the conversation pick index with segment-based selection.
Add generation job details and fix warmup placement displays so backend percentages and provider counts render correctly.
Replace the monolithic warmup content admin page with routed overview, library, generate, jobs, and settings pages.
Add shared warmup content layout, tab navigation, and reusable presentation helpers for the section.
Add OpenAI Batch API support for warmup content generation, including job metadata, polling, cancellation, and completed-batch ingestion.
Share the generation prompt between sync and batch modes and humanize/lint generated threads before storing them in the warmup content library.
Add star-rate settings to warmup content controls and include star actions in generated engagement plans.
Execute Gmail stars via STARRED labels while keeping IMAP behavior a no-op to avoid duplicate flagging.
Record warmup spam placements by recipient provider and surface provider breakdowns in the admin health summary.
Track warmup replies and use stable static conversation ids so warmup analytics can correlate content reliably.
Add warmup content generation and admin review surfaces, plus mailbox warmup appeal/status APIs.
Track warmup engagement and tampering signals so unsafe mailboxes can be handled by the warmup flow.
Add PUBLIC_HOST wiring for local web, admin, site, realtime, and backend CORS so the native dev stack can be reached over Tailscale or LAN without changing localhost defaults.
Adds GET /admin/mailboxes — paginated platform-wide mailbox list that
joins email_accounts → users → organizations so the table answers
"whose mailbox is this and where does it live" without N+1 fetches.
Search covers mailbox email / owner email / org name; status filter
defaults to active so the active surface shows first ("inactive" /
"all" both available). Provider filter speeds up "show me every Gmail
mailbox" investigations. Cursor pagination matches the rest of the
admin lists.
Frontend page surfaces warmup-on/off, send budget, and last-sync time
with red-when-never / amber-when-stale-over-24h tone so an
investigator can spot dead mailboxes fast. Mailbox email links into
the owning user's detail page; org name links into the workspace
admin so the pivot path stays one click in either direction.
Gated on AdminPermViewUsers since mailbox triage is tightly coupled to
user/org context today; a dedicated bit can be carved later if
mailbox-specific actions land.
Replace the AnalyticsPage stub with the full chart pack over the
existing /admin/analytics/* endpoints. Four-up trend cards on top
(users / emails / campaigns / revenue growth vs. previous period),
then a 30-day stacked bar chart for daily email volume (delivered /
replied / bounced), and a two-up row with hourly-by-today plus a
sorted worker-load list that links into each worker's detail page.
No chart library — bars are CSS divs so the admin bundle doesn't pay
for recharts/d3 for this one screen. Hover tooltips on the bars carry
the per-day breakdown.
User-growth strip lives below the email charts for symmetry with the
Overview's "platform pulse" framing.
Adds a dedicated admin path for sending platform email — distinct from
the campaign emailsend service (which sends through customer mailboxes)
so the two abuse surfaces never share code paths.
Schema (000047) adds admin_outreach_messages: every send is recorded
with sent_by, the resolved to_email, the optional reply_to, subject,
body, and a queued → sent/failed status. Failed sends keep their error
column populated for the audit log.
Extends notify.EmailNotificationService with SendOutreach so both
backends (SES + SMTP) support custom Reply-To: SES via the native
ReplyToAddresses field, SMTP via a forged Reply-To header. The
existing transactional Send() remains unchanged so no other caller is
affected.
Service (internal/app/adminoutreach) resolves recipients three ways:
to_email (raw address), to_user_id (sends to the user's account email),
or to_org_id (sends to the workspace owner). Persist-then-send-then-
mark ensures the audit row exists even if the mailer hangs, and
mark-failed captures the error string verbatim.
Routes:
POST /admin/outreach manage_organizations
GET /admin/outreach view_organizations
Admin UI: composer with recipient mode picker (email / user_id / org_id),
configurable Reply-To (defaults to support@warmbly.com so customers can
actually reply), subject + HTML body editor, and an outreach log below
showing the last 50 sends with status badges and error details. Sidebar
entry under Accounts (Send icon).
Three surfaces close the loop on the limit-increase workflow:
- admin/dashboard/LimitRequestsPage.tsx queues every pending request
with full context (org → users → field → current vs requested →
+delta) and one-click approve/reject. Both actions open a review
dialog; approve notes are optional, reject notes are required and
surface to the customer.
- web/settings/limits/page.tsx is the customer-facing form. Resource
selector, requested value, reason textarea, plus a list of every
past request with its status (pending/approved/rejected/cancelled)
and the reviewer's notes when present. Pending rows expose a
cancel link. Footer links to the ToS limits clause.
- site/terms.astro grows a new section 07 ("Usage limits and
increase requests"). Explicit: "unlimited" means no plan-tier cap
but a product-wide hard ceiling still applies, increases are at
Warmbly's sole discretion, and previously granted increases can be
revoked when reputation signals deteriorate. Bumps every existing
section heading and id from 07 onward.
Admin sidebar grows a "Limit requests" entry under Accounts (Gauge
icon). Web settings layout grows a "Limits" section under owner-only
sections.
Add users.ban_scope INT NOT NULL DEFAULT 0 in migration 000045 so admins
can describe what a ban concretely stops (login / workspace creation /
outbound send) instead of relying on a single boolean banned_at flag
that meant "everything".
Wire flags in the BanScope enum (kept in sync with the migration) plus
a CHECK constraint guaranteeing non-negative values. Existing bans
backfill to BanScopeLogin so the historical "you can't log in"
semantics is preserved exactly — no behaviour changes silently at
deployment.
BanUserRequest gains an optional scope field, BanUser threads it through
the service to the repo write, and the UserBanDialog grows a checkbox
group with one option per flag. Reason still required; at least one
scope must be picked. Audit details now include the scope bitmask.
Runtime enforcement (refusing login when BanScopeLogin is set, etc.) is
intentionally separate from this commit — the existing codebase doesn't
yet have an active ban check anywhere, so wiring that lives across the
auth middleware, org-create handler, and emailsend service. This slice
ships the schema, the audit story, and the UI vocabulary so the
enforcement PR can land without database churn.
Replace the PlansPage stub with the real plan catalog over /admin/plans.
The list view surfaces visibility (public/private with a colored badge),
price + discounted price, and the four limit columns most often
touched: mailboxes, campaigns, members, contacts, plus daily-email
budget.
Edit dialog covers every safely-editable field — name, price, the four
org limits, daily caps, account limit, dedicated worker count, and the
public flag. Stripe price/product IDs are intentionally read-only;
those must be managed in Stripe and flow back via webhook.
Add /enterprise page wired to /admin/enterprise/inquiries. Sales-style
pipeline: pending → contacted → converted | declined, with an inline
<select> on each row so triage is one click per inquiry rather than a
detail-page round-trip.
Each row shows company, contact, estimated volume, team size, and the
free-form notes from the marketing-site form. Pending is the default
filter so the queue surfaces first; "All" reveals historical decisions.
Added a sidebar entry under Accounts (Briefcase icon) so the inquiry
queue is one click away from the rest of the customer-facing admin.
Replace the CampaignsPage stub with a real list backed by
/admin/campaigns. Search by name, filter by status (active/paused/done/all),
inline engagement counters (contacts, sent, opens, reply %, bounce %).
Bounce rates >5% are tinted red so abuse review is one glance.
Force-stop opens a dialog requiring a reason; the reason is written to
the admin audit log. Stop is disabled on completed/draft campaigns to
prevent accidental clicks.
Org name in each row links into the workspace admin page so an
investigator can pivot from "this campaign looks bad" to "who is
sending it, on what plan, with what override history" without leaving
the admin surface.
No backend changes — every endpoint already existed.
Replace the WarmupPage stub with the real safety surface CLAUDE.md
treats as the platform's most critical. Three layers, all wired to
existing /admin/warmup/* endpoints:
- Health summary: four cards (total participants by state, at-risk
count, avg spam-folder placement rate with green/amber/red tone,
blocked count). Refetches every 30s so an investigator sees pool
drift in near-real time.
- Per-pool table: free + premium with total/active/blocked counts.
Premium gets the purple badge to make the policy-isolation point
obvious at a glance.
- Blocked mailboxes: list with one-click unblock action. Appeals
state surfaces inline as an amber badge when present.
- Appeals queue: pending only by default with an approve/reject pair
that opens a review dialog requiring notes (notes land in the
audit log and may be shown to the appealing user).
No backend changes — every endpoint already existed.
Adds /users/:id with the full preview payload (profile, orgs the user
belongs to, connected mailboxes with provider/status/warmup state, and
ban history) plus two action surfaces:
- UserBanDialog: ban or unban from the same component, reason field
required so the audit trail always carries it. Banning is disabled
for admin accounts at the button level mirroring the backend's
"cannot ban admin users" guard.
- UserRateLimitsDialog: per-user override editor for daily emails,
max concurrent connections, and the three websocket per-minute
caps. Same "blank = no change, 0 = clear override, positive =
explicit cap" convention as the org limit overrides for consistency.
Organization rows on the detail page link straight into the
organizations admin so an ops investigator can pivot user → workspace
→ workspace owner without ever leaving the admin surface.
Replace the UsersPage stub with a real list view. Search covers name and
email, status toggle splits active / banned / all, and an "admins only"
checkbox filters down to accounts with admin_permissions > 0. Each row
shows orgs, mailboxes, and campaign counts inline so abuse review is
one glance; admin accounts get the amber ADMIN badge from the same
visual vocabulary as the app shell.
Backend endpoints already exist — this commit only adds the typed API
client (admin/users.ts) and the page itself. Drill-in to the detail
page lands in the next commit alongside ban/unban and rate-limit
override editors.
Replace the two-column "Plan limit + Headroom" usage table with a
five-column view showing Used / Plan / Override / Effective / Headroom.
The override column highlights non-zero entries in the amber accent so
admin-set caps stand out from plan defaults. Headroom bars compute
against effective, not plan, so they reflect what the runtime actually
enforces.
Add OrganizationOverridesDialog — a modal launched from the detail page
that does a partial PUT against /admin/organizations/:id/overrides.
Each numeric field is blank by default (no change on submit), 0
explicitly removes that column's override, and a positive value sets a
new ceiling. The plan default and current effective value are shown
alongside each input so the admin can see what they're about to change
before saving. Notes field is required when the override is granted so
other admins can read why.
When a save succeeds the org detail query is invalidated so the
plan/override/effective columns refresh in place, and the timestamp +
notes footer below the usage table updates accordingly.
Replace the OrganizationsPage stub with a real list view over
/admin/organizations: search by name/slug/owner email, status filter
(active / pending deletion / all), and inline counts (members, mailboxes,
campaigns + active) per row. Owner banned status surfaces as a red badge
on the row so abuse review is one glance.
Add OrganizationDetailPage at /organizations/:id that composes
/admin/organizations/:id with /admin/organizations/:id/members. Header
summarises owner / plan / lifecycle in three cards; body renders
usage-vs-plan-limits with green/amber/red bars (over-limit shown in red,
"no cap" for unlimited plans) and a members table tagged with role icons.
When the per-org override layer lands the usage table will gain a
"source" column (plan default vs admin override) so a 0 in an override
column reads as "no admin change" by design.
The admin and marketing site sit outside the compose stack, so `make app`
never started them. Add `make admin` and `make site` to launch each
workspace's dev server (Vite on 5174, Astro on 4321), and update the root
README and admin/README to point at them instead of the old "open
localhost:5174" line that implied `make app` was enough.
Also add `make grant-admin EMAIL=... [ROLE=super|support|ops|analyst]`
plus `make revoke-admin` so the first super-admin can be seeded without
hand-writing SQL. Role bitmasks mirror AdminRolePermissions in
internal/models/admin_permission.go.
admin/pnpm-workspace.yaml carries an 'overrides: picomatch: ^4.0.4'
block (added to mirror the dashboard) that was never reflected in
pnpm-lock.yaml — the lockfile was generated before the overrides were
introduced. Admin CI's pnpm install --frozen-lockfile rejected the
mismatch:
ERR_PNPM_LOCKFILE_CONFIG_MISMATCH Cannot proceed with the frozen
installation. The current 'overrides' configuration doesn't match
the value found in the lockfile.
Ran pnpm install --no-frozen-lockfile to regenerate the lockfile with
the override applied; --frozen-lockfile now passes locally.
Shorter, cleaner path. The 'web-' prefix was redundant given the dir
sits at the repo root next to web/ and is unambiguously the admin web
app. Git tracked the rename so blame + history follow through to the
new location.
Updated README.md and docs/VENDOR_LOCKIN.md references plus the package
README header. No code changes.
Matthew Meszaros
Matt