Find accountability partner: when “found” means a recurring calendar event, not a conversation

The moment src/app/api/confirm-match/route.ts finishes executing the branch that begins at line 59, where the variable bothConfirmed is true. Not when the cron writes a match row. Not when the first person clicks yes. Not when both people exchange a message. The specific moment is: both token clicks have landed, the match row has flipped both person_a_confirmed and person_b_confirmed to true, a POST to https://www.googleapis.com/calendar/v3/calendars/primary/events?conferenceDataVersion=1&sendUpdates=all has come back with a non-empty hangoutLink, two rows have been inserted into the meet_links table, two intro emails have been sent through Resend, and updateMatchStatus(match.id, 'pending') plus two updateEntryStatus calls have marked both participants as 'matched'. If any single one of those operations throws, 'found' has not happened yet.

A daily recurring event. The recurrence field in src/lib/google-meet.ts line 75 is hard-coded to the array ['RRULE:FREQ=DAILY'] with no end date, no count, and no byday filter. The event is owned by the operator's primary calendar, the start is tomorrow at the best-overlap UTC time returned by computeSuggestedMeetUtcMinutes, and the duration is the longer of the two partners' chosen session durations (parsed at lines 171 to 184 of confirm-match/route.ts, defaulting to 60 minutes if parsing fails). Both partners are invited as attendees. Google's conferenceData.createRequest auto-generates a Google Meet room, and the video entry point URL is copied into the matches.calendar_event_id column and surfaced to each partner via a per-person tracking URL at /meet/<token>.

No. Lines 87 to 101 of confirm-match/route.ts handle that case explicitly. The match row stays at status 'confirming'. No intro email is sent. No Meet link is stored. The server fires a Resend email with the subject 'ALERT: Meet creation failed for <nameA> & <nameB>' to the operator inbox so a human can either retry or create a link manually on /admin/matching. From the user's browser the redirect still goes to /match-confirmed?response=yes, because their click was successful and the OAuth problem is not something they can fix, but in the database they are not matched and no calendar event exists. This is the one case where the page that says 'you are confirmed' is ahead of the database.

Three days. The expire-matches cron at vercel.json line 12 runs at 12:00 UTC daily and calls expireStaleMatches(3) at line 11 of src/app/api/expire-matches/route.ts. That function selects every match where status = 'confirming' and created_at < now - 3 days, flips its status to 'expired', and returns both participants to the 'pending' pool with contact_count incremented by one. So the window between the cron writing your match row and needing both of you to have clicked yes is strictly three calendar days, regardless of timezone. Miss that window and your partner goes back into the pool, your contact_count is one higher than it was, and you re-enter the eligible pool after a 7-day cool-off (the cap is ten attempts before you're permanently dropped from auto-matching).

Because the operator (Matt) is not on the call. Once the recurring event is written, the product exits the loop; there is no coach watching attendance. If only one side had to confirm, the other could easily be a stale email address, a decayed intention, or an inbox that nobody checks. Requiring both tokens to click yes before any calendar event materializes is how the system extracts a weak promise from both sides simultaneously. The cost of that promise is one click each. The benefit is that the daily calendar invite does not get sent to someone who never opened the email.

The check-rsvp cron at vercel.json line 15 runs once a day at 14:00 UTC, loads every match with a calendar_event_id and status in ('pending','scheduling','active'), calls the Google Calendar API to read the attendees' responseStatus fields, and writes them into calendar_rsvp_a and calendar_rsvp_b. If either field changes to 'declined' or the event returns a 404 (eventDeleted), the match status is flipped to 'ended', the event row is updated, and a summary email goes to the operator. Put plainly: if you remove the daily event from your calendar, the partnership closes out on the next daily tick. There is no manual 'end' button needed. The calendar IS the source of truth for whether the partnership is still alive.

Five, in order. (1) confirming, written by createMatchWithTokens immediately after the auto-match cron picks a pair. (2) pending, written by updateMatchStatus on line 152 of confirm-match/route.ts once bothConfirmed is true and the Meet link has been created. (3) The individual entries move from 'matched' to 'engaged' on the first yes click (line 55) and stay at 'matched' for both after line 153-154. (4) active or scheduling can happen if the pair exchanges messages before the first sit. (5) ended, expired, or declined are terminal. The find action is only 'done' at (2), and only 'alive' until (5). Everything between pending and ended is the partnership running; everything before pending is the system still trying to finish finding.

Yes, for the operator. The /admin/matching page can force-create a match row with status 'confirming' directly, which sends the same tokenized confirmation emails through the same confirm-match handler. This is how the first few partnerships on the site were made, before the pool was dense enough for the cron to find useful pairs. From a regular user's perspective there is no direct path: the waitlist form at /practice-buddy is the only public entry point, and it writes into waitlist_entries where the cron takes over. 'Finding', to a regular user, is always scheduled. Only an authorized operator can short-circuit the cron, and even then the two-click confirmation plus the Google Calendar step run the same way.

Because the product's thesis is a daily sit, not a weekly one. The form at /practice-buddy asks 'once a day' or 'twice a day' and the matcher itself builds separate morning and evening slots per person. A weekly calendar event would underbook the partnership against the stated practice cadence; a monthly event would be an attendance experiment rather than a sit. The one-line recurrence field in src/lib/google-meet.ts line 75 encodes the whole cadence claim of the product. Changing that line would change what the site is.

Everything about what actually happens on the cushion once the two of you open the Meet link. How to sit, how to work with a sensation, how long to practice, what to do when the mind wanders, how to handle doubt or resistance. Those questions are the province of the S.N. Goenka tradition, taught during 10-day residential courses at dhamma.org, with authorized assistant teachers. This page describes only the plumbing between 'I signed up' and 'a recurring calendar event exists.' What the calendar event contains, from the practice side, is not this site's to teach.