SWE-in-a-team: a coding benchmark for software factories

On-call here. Sentry started catching this in production yesterday:

TypeError: Reduce of empty array with no initial value

It fires every time someone opens the invoice detail page for the refunded "Pottery intensive" invoice, the one for Femke. The page dies to the error screen instead of rendering. Every other invoice I tried opens fine.

The thing that's different about that invoice is that every line item on it has been refunded, so there's nothing left to bill. Anything that leaves an invoice with zero billable line items seems to trip the same error, and finance wants to lean on line-level refunds more, so this is only going to happen more often.

Acceptance criteria

• Opening the detail page of an invoice whose line items are all refunded renders normally: subtotal €0.00, tax €0.00, total €0.00, with the refunded lines still listed (and badged as refunded).
• Invoice totals are computed safely for an invoice with zero billable line items (none at all, or all refunded), yielding zero subtotal/tax/total and the correct refunded sum, instead of throwing.
• Invoices with a mix of billable and refunded lines keep today's behaviour (refunded lines tracked but excluded from subtotal and tax).

Front desk flagged this after yesterday's Reformer class filled up.

A member tried to book the full class from the bookings page, the button felt unresponsive, so she clicked it again. Now she shows up twice on that class's waitlist. When a spot opened up this morning, one of her entries got promoted to a confirmed seat, and the second entry is still sitting on the waitlist. It's holding a spot the next person should have, and it's throwing off our occupancy numbers.

I reproduced it in a minute: pick a full class, book the same member, submit again, and the second submit goes through and adds another waitlist row. If the member already holds a confirmed seat, the second submit is correctly rejected ("This member already has a booking for this class"), so it's really only the waitlisted case that slips through.

Acceptance criteria

• Booking a member onto a full class puts them on the waitlist once; any repeat booking attempt for the same member + same class while they are waitlisted is rejected with the same "already has a booking" conflict as a repeat attempt on a confirmed seat.
• After a double submit, the member has exactly one active booking row (waitlisted) for that class.
• Cancelled bookings keep today's behaviour: a member whose booking was cancelled can book the same class again.

Forwarded from our dependency scanner.

High · Regular Expression Denial of Service (ReDoS) in semver

• Advisory: GHSA-c2qf-rxjj-qqgw (CVE-2022-25883)
• Package: semver (npm)
• Affected versions: >=7.0.0 <7.5.2
• Patched in: 7.5.2
• Dependency path: apps/web > semver

The semver range parser can be driven into super-linear backtracking by a crafted version/range string, allowing a denial of service. apps/web depends on a version in the affected range.

We pull semver in to gate the minimum supported client version. Please update the dependency to a patched release so the scanner stops flagging it.

Acceptance criteria

• apps/web no longer depends on a semver in the vulnerable range; the version the package manager resolves is >= 7.5.2.
• A high-severity dependency audit reports no findings.
• Lint, type-check, tests, and the production build all still pass.

Hi. I run security for one of your pilot studios, and while poking at the app with my own signed-in session I noticed the detail endpoints don't seem to check who owns a record.

Here's what I mean. My session is scoped to my studio, but if I take the id of an invoice, member, or booking that belongs to a different studio and request it directly (say GET /api/invoices/<their-id>, GET /api/members/<their-id>, or DELETE /api/bookings/<their-id>), the app hands it over. In the booking case it will even cancel their record for me. The id is the only thing guarding it, and ids are easy to guess. That's an IDOR: one tenant can read and change another tenant's data.

If a record isn't mine, I'd expect it to look like it simply doesn't exist for me.

Acceptance criteria

• Fetching an invoice or member by id, or cancelling a booking by id, is scoped to the caller's own studio: an id that belongs to a different studio is rejected as not found (the record is neither returned nor modified).
• The same operations continue to work for records that belong to the caller's own studio.
• Lint, type-check, tests, and the production build all still pass.

Hi, reporting a stored cross-site-scripting issue in the invoices area.

Invoice line-item descriptions are free text entered by staff, but the invoice detail page renders that text as raw HTML instead of escaping it. If a description contains markup, it gets injected into the page and runs in the browser of anyone who opens that invoice.

Repro:

1. Create an invoice with a line item whose description is <img src=x onerror="alert(document.cookie)">.
2. Open the invoice detail page.
3. The image tag is parsed and the onerror handler fires, so arbitrary script runs in the viewer's session. One malicious value stored on a single account then executes against every user who later views that invoice.

The description should show as literal text, never interpreted as markup.

Acceptance criteria

• On the invoice detail page, a line-item description containing HTML (e.g. <img src=x onerror=...>) is rendered as inert, escaped text: the markup appears verbatim and no element or handler is created from it.
• Ordinary descriptions still render as readable text.
• Lint, type-check, tests, and the production build all still pass.

Automated dependency PR from the dependency bot.

Bumps zod in apps/web from ^3.24 to the latest** v4** release.

Zod 4 is a major version. Most of our schema code is source-compatible, but a couple of v3-era idioms changed, and the request-error handling that builds the API validation-error envelope depends on one of them. Move apps/web onto Zod 4, confirm the request validators still behave exactly as they do today, and keep the app compiling.

Release notes (upstream)

• Top-level string-format helpers (z.email(), z.url(), …) are now preferred over the chained z.string().email() forms.
• The ZodError surface changed: the flat error.errors array accessor was removed in favour of error.issues; error.flatten() / error.format() are retained (now deprecated).
• Default and transform semantics for object schemas are unchanged for the shapes we use.

Acceptance criteria

• apps/web depends on Zod v4: the version the package manager resolves is 4.x, not 3.x.
• The API request validators keep their behaviour: a malformed email is rejected; a valid email is trimmed and lower-cased; a new member's status defaults to active; and a colour that is not a #rrggbb hex value is rejected.
• Lint, type-check, tests, and the production build all pass.

From engineering:

We are a major version behind on Next.js. apps/web is still on Next 15, and Next 16 is out. Let's upgrade to Next.js 16. Behavior should be unchanged; this is a framework upgrade, not a feature change.

The main thing Next 16 changes for us is that the dynamic request APIs are now asynchronous: params and searchParams in pages and route handlers, and cookies() / headers(), must be awaited rather than read synchronously.

Docs: the Next.js 16 upgrade guide at https://nextjs.org/docs/app/guides/upgrading/version-16.

Acceptance criteria

• The web app runs on Next.js 16: next resolves to a 16.x version in the lockfile (not just the declared range).
• The dynamic request APIs are accessed the Next 16 way: params / searchParams (in pages and [id] route handlers) and cookies() / headers() are awaited, not read synchronously.
• The app's behavior is unchanged: the full test suite and the production build stay green.

From engineering:

We are behind on Tailwind. The web app is still on Tailwind v3 with the old JavaScript config, and v4 has been out for a while with a faster engine and a CSS-first setup. Let's upgrade apps/web to Tailwind CSS v4. The app should look and behave exactly the same afterwards. This is a toolchain modernization, not a redesign.

Docs: the Tailwind v4 upgrade guide at https://tailwindcss.com/docs/upgrade-guide.

Acceptance criteria

• The web app builds and runs on Tailwind CSS v4:
  • tailwindcss resolves to v4 in the lockfile;
  • the PostCSS plugin is @tailwindcss/postcss (not the old tailwindcss PostCSS plugin);
  • the global stylesheet pulls Tailwind in with @import "tailwindcss", replacing the old @tailwind base; @tailwind components; @tailwind utilities; directives;
  • the old tailwind.config.js is removed (configuration moves into CSS).
• The app's appearance and behavior are unchanged: the full test suite and the production build stay green.

Architecture note from the platform team.

We're consolidating Studiobook onto a single Cloudflare stack. The app already builds and deploys as a Worker (OpenNext), but persistence still runs through @supabase/supabase-js against a hosted Postgres. That's the last thing keeping us tied to a second vendor and its connection model. We want the production data layer on Cloudflare D1 (the app's own SQLite database binding) using** Drizzle ORM**, so everything lives in one account and one deploy.

This is a swap of the adapter, not a change in behaviour. Studiobook already funnels every read and write through the Repositories interfaces (lib/db/repos/types.ts). The Supabase client is confined to a single implementation file behind that seam, and services, routes, and domain code only ever touch the interfaces. So keep the migration contained to the persistence adapter: implement the same repository surface with Drizzle over the D1 binding, then delete the Supabase pieces. Nothing above the repository seam should need to change, and the in-memory fake repositories (used by local dev and the test suite) stay exactly as they are.

Keep the change tight and behaviour-preserving. The demo dataset, the booking, invoice, and notification flows, and every existing check should behave identically afterwards.

Acceptance criteria

• The web app no longer depends on @supabase/supabase-js or @supabase/ssr; both are removed from the app's dependencies (and the workspace lockfile).
• The production repository implementation is written with Drizzle ORM over the Cloudflare D1 binding, behind the existing Repositories seam. A Drizzle dependency is present in the app. The createD1Repositories(db) factory in lib/db/repos/d1.ts takes the D1 database binding as its argument (so the adapter can be constructed against any D1 instance), and resolveRepositories passes the Worker's DB binding to it.
• Ship the D1 schema as migration SQL under apps/web/migrations/ (the standard wrangler D1 migrations directory) and declare the DB d1_databases binding in wrangler.jsonc, so the database can be created from scratch.
• No @supabase/* import remains anywhere under the app's lib.
• Behaviour is preserved: the app builds, and the existing unit + integration suite (services and repositories exercised against the in-memory fakes) stays green. Route handlers, services, and domain modules keep depending only on the repository interfaces, untouched by the swap.

Eng-lead here, writing this up after finance flagged a discrepancy.

We now compute an invoice's total in three different places and they've drifted:

1. computeInvoiceTotals in lib/domain/invoices.ts. This is the original, and the one the invoice page and the stored invoice both rely on. It correctly drops refunded line items out of the taxable subtotal.
2. The invoice create path (lib/services/invoices.ts) has grown its own inlined copy of the subtotal/tax math instead of calling the domain function.
3. The new account statement feature (lib/services/account-statements.ts) rolled its own copy too, and this one is wrong: it taxes every line, including refunded ones. So a member whose invoice had a line refunded sees a bigger total on their statement than on the invoice itself, and bigger than what we actually charged.

Concretely: an invoice with a €100 billable line and a €50 refunded line, at 9% tax, is €109.00 everywhere it's computed correctly, because tax applies to the €100 only. The statement, though, reports €163.50 because it taxes the full €150.

We need ONE invoice-total implementation. Route every surface through the single domain function so a refunded line is handled identically everywhere, and the statement, the invoice record, and the domain calculation all agree.

Acceptance criteria

• There is a single source of truth for invoice totals; the account-statement and invoice-create paths compute totals through it rather than re-deriving the subtotal/tax math inline.
• For an invoice with a refunded line item, the account statement's total excludes the refunded line from the taxable subtotal. It equals the canonical computeInvoiceTotals result and the stored invoice total (for the example above, €109.00, i.e. 10900 cents), never the over-taxed figure.
• No behaviour changes for invoices without refunded lines, and invoice creation still stores the same subtotal/tax/total it does today.

From engineering, flagged by one of our larger studios.

Since we refactored the bookings list last week, the dashboard has gotten noticeably slow for studios with a full schedule. A few hundred bookings and the page crawls. Our query logs show the list now looking up each booking's member and class session one row at a time, so the number of database reads climbs with the number of bookings. It used to fetch them in a batch.

Please get the list back to a bounded number of reads no matter how many bookings it returns, without changing anything the endpoint returns.

Acceptance criteria

• GET /api/bookings returns exactly what it returns today: the same rows, the same fields, in the same order.
• Listing the bookings issues a number of member and class-session repository reads that does NOT grow with the number of bookings. Fetching a list of N bookings must not read the members repository or the class-sessions repository once per booking; a small, fixed number of reads total is expected, regardless of N.
• The existing test suite stays green.

From the founder.

Every quarter I sit down with our bookkeeper and she asks for "the list of what actually happened": which classes ran, who was in them, over a date range she picks. Right now the only exports we have are the members list and the invoices list (/api/export?type=members / ?type=invoices). There's nothing for bookings, so I end up screenshotting the bookings page, which is a bit embarrassing.

Can we add a bookings export to the same download endpoint? I want to ask for "everything between 1 June and 30 June" and get a clean CSV I can open in Excel or hand straight over. A couple of our members have commas in how their name is stored ("Rossi, Chiara"), and the current members export handles that fine, so please keep the same quoting.

Acceptance criteria

• GET /api/export?type=bookings is supported, alongside the existing members and invoices exports, and (like them) requires a signed-in session.
• It accepts optional from and to query parameters (ISO-8601 timestamps). When given, the export includes only bookings whose class session start time falls within [from, to], inclusive of both ends; an omitted bound is unbounded on that side.
• The CSV has these columns, in this order: Starts, Class, Member, Email, Status. Starts is the session start as its ISO-8601 UTC timestamp, Class is the class name, Member is the member's name, Email is their email, and Status is the booking status.
• Fields containing a comma, double quote, or newline are quoted with embedded quotes doubled (RFC 4180, the same escaping the invoices export already uses), so a member named Rossi, Chiara stays a single column.

From the founder, working on next season's pricing:

Every booking today is a one-off. Our most loyal members would happily pay up front for a bundle instead of paying class by class, the way every studio sells a "10-class pass." I want to sell class packs: a member buys a pack of credits, and each class they book spends one credit until the pack runs out. Then they buy another.

Let's start with two sizes, a 5-credit pack and a 10-credit pack. Once a member has a pack, their bookings should draw from it automatically, so the front desk never has to think about it. When the pack is empty, the booking should stop and tell them to buy another. And if we ever have to refund a pack, its remaining credits should be voided so they can't still be spent.

Acceptance criteria

• Buy a pack. POST /api/packages with body { memberId, credits }, where credits is either 5 or 10. It creates an active pack for that member with creditsRemaining equal to credits, and a total priceCents of credits × 1000 — i.e. 1000 cents per credit, so a 5-credit pack is 5000 and a 10-credit pack is 10000 (the priceCents field is the pack's TOTAL price, not the per-credit rate). Responds 201 with { id, memberId, creditsTotal, creditsRemaining, priceCents, status, purchasedAt }.
• List a member's packs. GET /api/packages?memberId=<id> responds 200 with that member's packs (each { id, creditsTotal, creditsRemaining, priceCents, status, purchasedAt }), newest first.
• Bookings draw from the pack automatically. When a member who has an active pack with creditsRemaining > 0 books a class via POST /api/bookings, the booking is confirmed exactly as today AND one credit is spent (the pack's creditsRemaining drops by one, oldest pack first). A member with no pack books exactly as they do today, unchanged.
• A used-up pack stops the booking. Once a member has bought a pack, their bookings must come from a pack. If they have no credits left to draw (every pack they own is exhausted or refunded), POST /api/bookings is rejected with 402 and the error code pack_exhausted; they must buy another. A member who never bought a pack is unaffected and books exactly as today.
• No double-spend. The existing rule that a member cannot book the same session twice still holds: a repeated booking is rejected 409 and spends no extra credit.
• Refund voids the remaining credits. POST /api/packages/{id}/refund sets the pack's creditsRemaining to 0 and its status to refunded; a refunded pack is never drawn from again.

Let members subscribe to their own class calendar

From the PM:

We already publish a studio-wide calendar feed (/api/ical), but members keep asking for "just my classes on my phone calendar." A single shared feed doesn't work for that — it lists everyone's sessions, and it's public.

I'd like each member to have their own private subscription link: a secret per-member token in the URL that returns only the sessions that member is booked into, so they can paste it into Apple/Google Calendar and see their upcoming classes auto-update. Because a calendar app can't log in with our cookie, the secret link itself has to be what authorizes it — so an unknown or made-up token must just 404, never leak someone else's schedule.

Acceptance criteria

• Every member has a private calendar token.
• GET /api/ical/[token] returns an iCalendar feed (content-type: text/calendar) containing calendar events for ONLY that token-holder's upcoming booked sessions (future sessions they hold a confirmed seat in). It must not include other members' sessions or the member's past sessions.
• An unknown or empty token returns 404.
• No session cookie is required — the secret token is the authorization.

Automatic 24-hour class reminders

From the PM:

Our no-show rate spikes for early classes, and members keep telling us "I just forgot." Every other studio app sends a reminder the day before — we should too. I'd like a reminder to go out to everyone who's booked into a class that starts in the next 24 hours.

I want to drive this from our scheduler (a cron that hits an endpoint), so the important thing is that it's safe to call repeatedly: if the cron runs hourly, a member must still only get one reminder for a given class, not one every hour. And obviously anyone who's turned notifications off shouldn't get one, and people only on the waitlist (no confirmed seat) shouldn't either.

Acceptance criteria

• POST /api/reminders/run (requires a signed-in session, like our other write endpoints) finds every class session starting within the next 24 hours and queues a booking_reminder notification — a pending row in the notification outbox — for each member holding a confirmed (booked) seat in one of those sessions.
• Members who have opted out of notifications get no reminder. Waitlisted members, and members whose session is outside the 24-hour window, get no reminder.
• The endpoint is idempotent: running it a second time does not queue a duplicate reminder for a booking that already has one queued.
• Returns HTTP 200 on success.

From the founder:

I have no real picture of our funnel. How many bookings get made, how often members join a waitlist, how often they cancel. Right now I'm guessing. Let's wire up PostHog so I can see these moments in one place.

Instrument the events that matter, and keep it clean. Route analytics through a single helper the way we already route email through the notification adapter, so it's easy to test and swap. Don't scatter posthog calls through the domain code.

Docs: PostHog for Next.js (https://posthog.com/docs/libraries/next-js), also mirrored offline at docs/vendor/posthog-nextjs.md.

Acceptance criteria

• Analytics goes through a single injectable tracker, an interface with a capture method, wired into the booking, waitlist, and cancellation flows, with the real PostHog client constructed only at the composition root (mirroring the notification adapter). Service and domain code depend on the interface, never on a posthog package directly.
• Expose a __setTestTracker(tracker) test seam from the tracker composition root — mirroring __setTestRepositories on the repository seam — so a recording tracker can be injected and the route handlers driven in tests. (How the flows receive the tracker is up to you; the seam is what's graded.)
• These events are captured, exactly once, on their flow, each attributed to the member (the member's id as the analytics distinct id) and carrying the session's id as a session_id property:
  • booking_created when a booking is confirmed.
  • waitlist_joined when a booking is placed on the waitlist.
  • booking_cancelled when a booking is cancelled.
• A waitlisted booking fires waitlist_joined and NOT booking_created; a confirmed booking fires booking_created and NOT waitlist_joined.
• No personally-identifying data in the captured events. No email, name, or phone number anywhere in an event's properties.
• The existing test suite stays green.

From the founder:

We're starting to collect payments through Stripe. Right now when a member pays an invoice, someone has to mark it paid by hand, and we forget. Stripe can tell us the moment a payment succeeds via a webhook, so let's receive that and mark the matching invoice paid automatically.

Two things I care about: it must reject anything that isn't genuinely from Stripe (verify the signature), and if Stripe sends the same event twice (it does), we must not double-process.

Docs: Stripe webhooks (https://docs.stripe.com/webhooks) and signature verification (https://docs.stripe.com/webhooks#verify-events).

Acceptance criteria

• POST /api/webhooks/stripe receives a Stripe webhook. It verifies the request's Stripe-Signature header against our webhook signing secret (STRIPE_WEBHOOK_SECRET); a request with a missing or invalid signature is rejected with 400 and nothing is changed.
• On a verified invoice.paid event, the invoice named in the event (its id at event.data.object.metadata.invoice_id) is marked paid: its status becomes paid and paidAt is set. Respond 200.
• Idempotent: receiving the same event again (same event id) leaves the invoice paid exactly once and still responds 200, with no double-processing and no error.
• A verified event that names an unknown invoice responds 200 (acknowledged) and changes nothing. A verified event of any other type is acknowledged (200) and changes nothing.
• The existing test suite stays green.

From the founder, after a bad month:

Twice last month a member hit a 500 and we only found out because they emailed us. We need real error monitoring. Wire up Sentry so that whenever one of our API routes hits an unexpected server error, it gets reported to Sentry with the error instead of vanishing into the logs.

The important nuance: our normal, handled responses aren't errors. A 404 for a missing member, a 400 for bad input, a 409 for a full class, a 402 for an empty pack: those are expected and must NOT be reported, or Sentry becomes noise. Only genuine unexpected failures should be captured.

Docs: Sentry for Next.js (https://docs.sentry.io/platforms/javascript/guides/nextjs/).

Acceptance criteria

• When an API route handler throws an UNEXPECTED error (anything that is not one of our normal handled outcomes: not a validation error, not a deliberate HttpError), the error is reported to Sentry via the Sentry SDK's captureException, and the response is the existing 500.
• Expected, handled outcomes are NOT reported to Sentry: a 400 validation error and any HttpError (404 / 409 / 402 / etc.) are normal and must not be captured.
• A successful request reports nothing.
• The existing test suite stays green.

From our growth lead:

Every studio already has a public page at /s/<slug> that lists its upcoming classes, and you can open one without logging in. The problem is that it's invisible in search. I checked one with Google's Rich Results Test and Lighthouse and it's a mess. The page is marked noindex so Google won't even index it, the title is just "Studio", there's no meta description, no social preview when you paste the link in Slack or WhatsApp, and none of the structured data Google needs to show class events. We're leaving sign-ups on the table.

Please make the existing public studio page properly SEO-ready so it can rank and show rich results. Don't build a new page. Improve the one that's already there (apps/web/app/s/[slug]/page.tsx). Same content, just search-ready.

Docs: Next.js Metadata: https://nextjs.org/docs/app/getting-started/metadata-and-og-images ; sitemap: https://nextjs.org/docs/app/api-reference/file-conventions/metadata/sitemap ; robots: https://nextjs.org/docs/app/api-reference/file-conventions/metadata/robots ; schema.org Event: https://schema.org/Event.

Acceptance criteria

• The public page at /s/[slug] must be indexable: remove the noindex directive so search engines can crawl and index it. It must still be public (no login) and still render the studio and its upcoming classes (each class's name, start time, and instructor). A slug that matches no studio still returns 404.
• Give it real, studio-specific SEO metadata via Next's Metadata API (generateMetadata): a <title> and <meta name="description"> that name the studio (not a hardcoded "Studio"), Open Graph tags (og:title, og:description, og:type), Twitter card tags, and a canonical URL.
• Embed JSON-LD structured data in a <script type="application/ld+json"> using schema.org Event, one event per upcoming class, each with at least name, startDate, and location.
• Fix the on-page SEO basics: the studio image needs descriptive alt text, and the call-to-action link needs descriptive text (not "Click here").
• Add GET /sitemap.xml listing the public studio page(s) and GET /robots.txt that allows crawling and references the sitemap (use Next's sitemap.ts / robots.ts file conventions).
• The page must NOT require authentication, and the existing test suite stays green (the admin app and its auth are unaffected).

The measurable bar: the page's Lighthouse SEO score should go from its current low baseline (~45) up to ~100.

From engineering.

CI has gone red and it's blocking everyone. The app itself is fine. The problem is the tests. One test leaves shared state behind (it sets something up and never cleans it up), and that leaks into another test, which then fails when the whole suite runs together. Run that other test on its own and it passes; run the full suite and it fails.

Please fix the test isolation so pnpm test is green and stays deterministic. Don't just delete or skip the failing tests. Fix the leak so the offending test cleans up after itself.

Acceptance criteria

• pnpm test (the full suite) passes deterministically.
• The fix is proper test isolation: the leaking test cleans up the shared state it sets (so it no longer affects any other test), rather than the other test being changed to tolerate the leak.
• No test is deleted, skipped (.skip / .only / commented out), or gutted to make the suite pass; every test that existed still exists and still asserts what it did.