M2: the full job lifecycle — chat, hiring, geocoding, quotes, bookings, reviews
Closes the funnel. Before this the product could match two people and then stopped: `quotes`, `bookings` and `reviews` had tables and state machines and nothing that wrote a row, the entry deck's right swipe was wired to an empty handler, and every address resolved to the city centre. Jobs tab and chat - message router: thread, send, markRead, unreadTotal. A thread is a MATCH, not a job — one job with three interested pros is three private conversations. - Current/Past segments derived from ACTIVE_JOB_STATUSES, job detail listing the pros who accepted, and the conversation itself with attachments. Hiring from the deck - A right swipe on the entry deck opened nothing. It now resolves "which job?" through a sheet — sign in, pick an open job, or post one — and calls the same deck.swipe the per-job deck does, so the open-request cap and row lock apply exactly once. Swipes are vetoable so closing the sheet returns the card. Geocoding - ST_Distance and ST_DWithin rank and filter every deck, and both operands were placeholders. Addresses now resolve through Mapbox (permanent=true, which is what licenses storing the coordinates), the server resolves points rather than trusting client-supplied lat/lng, and every stored point records how it was obtained. A `city`-precision base cannot reach the verification queue. Quote -> booking -> review - The commercial chain, minus payments. Accepting a quote is the only place a booking is created; confirming completion is what unlocks reviews and moves the pro's completed_jobs. - Reviews publish double-blind with no sweeper: each is written with published_at already set to its embargo deadline and every read filters published_at <= now(), so it publishes itself. The second review pulls both forward. A silent counterparty cannot bury a bad review by never replying. State machine changes, both deliberate - booked -> matched: a cancelled booking is not a cancelled job. - scheduled -> awaiting_confirmation: in_progress is optional, so a pro who never tapped Start can still say the work is done. Test suite - api tests ran files in parallel against one database and failed roughly one run in three on whichever file lost the race. Serialised, and three fixtures that grabbed "the first client" pinned to the seeded accounts. Also includes work from a parallel session: admin verification queue, pro public profile and reviews read path, notification sending, denormalised stats recompute, search, and observability. 318 tests passing; typecheck and lint clean across 7 packages. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
serfa
@@ -16,6 +16,24 @@ export const AUTO_CONFIRM_HOURS = 72;
|
||||
/** A quote is only good for this long. */
|
||||
export const QUOTE_VALIDITY_HOURS = 72;
|
||||
|
||||
/**
|
||||
* How long a review sits unpublished while the other side has their say.
|
||||
*
|
||||
* Double-blind: neither review is visible until both are in, so nobody can read
|
||||
* what was said about them and answer in kind. The embargo is the escape hatch —
|
||||
* a pro who never reviews the client cannot bury a bad review by staying silent
|
||||
* forever.
|
||||
*
|
||||
* Implemented WITHOUT a sweeper: a review is written with `published_at` already
|
||||
* set to this deadline, and every read filters on `published_at <= now()`. It
|
||||
* publishes itself. When the second side reviews, both rows are pulled forward
|
||||
* to now.
|
||||
*/
|
||||
export const REVIEW_EMBARGO_HOURS = 14 * 24;
|
||||
|
||||
/** How long after a booking completes either side may still review it. */
|
||||
export const REVIEW_WINDOW_DAYS = 60;
|
||||
|
||||
/** Cards prefetched per deck page. */
|
||||
export const DECK_PAGE_SIZE = 20;
|
||||
|
||||
@@ -33,7 +51,21 @@ export const MAX_QUOTE_CENTS = 2_000_000; // €20,000 sanity ceiling
|
||||
export const MAX_SKILLS = 12;
|
||||
export const MAX_SKILL_LENGTH = 40;
|
||||
|
||||
/** One page of search results. There is no second page; see queries/search.ts. */
|
||||
export const MAX_SEARCH_RESULTS = 50;
|
||||
export const MAX_SEARCH_QUERY_LENGTH = 80;
|
||||
|
||||
/** Pro service radius bounds, metres. */
|
||||
export const MIN_SERVICE_RADIUS_M = 1_000;
|
||||
export const MAX_SERVICE_RADIUS_M = 50_000;
|
||||
export const DEFAULT_SERVICE_RADIUS_M = 15_000;
|
||||
|
||||
/**
|
||||
* One page of written reviews on a public profile.
|
||||
*
|
||||
* A page, not the whole history: a pro with 60 ratings has a `ratingCount` in
|
||||
* the header and a readable slice underneath, and the screen says so rather
|
||||
* than implying the slice is everything.
|
||||
*/
|
||||
export const REVIEWS_PAGE_SIZE = 10;
|
||||
export const MAX_REVIEWS_PAGE = 20;
|
||||
|
||||
+106
-13
@@ -1,6 +1,9 @@
|
||||
import { z } from 'zod';
|
||||
import {
|
||||
MAX_QUOTE_CENTS,
|
||||
MAX_REVIEWS_PAGE,
|
||||
MAX_SEARCH_QUERY_LENGTH,
|
||||
MAX_SEARCH_RESULTS,
|
||||
MAX_SERVICE_RADIUS_M,
|
||||
MAX_SKILL_LENGTH,
|
||||
MAX_SKILLS,
|
||||
@@ -25,6 +28,44 @@ export type LatLng = z.infer<typeof latLngSchema>;
|
||||
|
||||
export const centsSchema = z.number().int().nonnegative();
|
||||
|
||||
/**
|
||||
* How a caller tells us where something is.
|
||||
*
|
||||
* Deliberately NOT a bare lat/lng. Every write path used to take coordinates
|
||||
* straight from the client, which meant two things: a caller could post a job at
|
||||
* any point on earth, and — far more common — a form that had never geocoded
|
||||
* anything sent the city centre and the database recorded it as a location.
|
||||
*
|
||||
* The three cases are the three things a person can actually have done:
|
||||
*
|
||||
* `place` they picked a suggestion. We send the id and the label back, and the
|
||||
* SERVER re-resolves it — the coordinates are never the caller's to
|
||||
* assert.
|
||||
* `device` they tapped "use my current location". Their own GPS is theirs to
|
||||
* report and there is nothing to verify it against, but it lands as
|
||||
* `approximate` because a phone fix is not a rooftop.
|
||||
* `none` they typed something we could not resolve, or the geocoder was down.
|
||||
* Honest: the point is the city centre and is labelled `city`.
|
||||
*/
|
||||
export const locationInputSchema = z.discriminatedUnion('source', [
|
||||
z.object({
|
||||
source: z.literal('place'),
|
||||
placeId: z.string().min(1).max(200),
|
||||
label: z.string().trim().min(1).max(255),
|
||||
}),
|
||||
z.object({
|
||||
source: z.literal('device'),
|
||||
lat: z.number().min(-90).max(90),
|
||||
lng: z.number().min(-180).max(180),
|
||||
label: z.string().trim().max(255).optional(),
|
||||
}),
|
||||
z.object({
|
||||
source: z.literal('none'),
|
||||
label: z.string().trim().max(255).optional(),
|
||||
}),
|
||||
]);
|
||||
export type LocationInput = z.infer<typeof locationInputSchema>;
|
||||
|
||||
export const createJobSchema = z
|
||||
.object({
|
||||
categoryId: z.string().uuid(),
|
||||
@@ -34,8 +75,9 @@ export const createJobSchema = z
|
||||
urgency: urgencySchema,
|
||||
budgetMinCents: centsSchema.optional(),
|
||||
budgetMaxCents: centsSchema.optional(),
|
||||
location: latLngSchema,
|
||||
addressText: z.string().min(3).max(255),
|
||||
// Replaces the old `location` + `addressText` pair: both are now derived
|
||||
// server-side from this, so the two can never disagree.
|
||||
place: locationInputSchema,
|
||||
})
|
||||
.refine(
|
||||
(v) =>
|
||||
@@ -52,7 +94,7 @@ export const proProfileSchema = z.object({
|
||||
hourlyRateCents: centsSchema.max(MAX_QUOTE_CENTS),
|
||||
yearsExperience: z.number().int().min(0).max(70),
|
||||
categoryIds: z.array(z.string().uuid()).min(1, 'Pick at least one trade').max(5),
|
||||
location: latLngSchema,
|
||||
place: locationInputSchema,
|
||||
serviceRadiusM: z.number().int().min(MIN_SERVICE_RADIUS_M).max(MAX_SERVICE_RADIUS_M),
|
||||
});
|
||||
export type ProProfileInput = z.infer<typeof proProfileSchema>;
|
||||
@@ -60,17 +102,17 @@ export type ProProfileInput = z.infer<typeof proProfileSchema>;
|
||||
/**
|
||||
* "Where I am, and how far I will go."
|
||||
*
|
||||
* Every field is optional so the settings screen can save a moved pin without
|
||||
* Both fields optional so the settings screen can save a moved pin without
|
||||
* touching the radius, but an empty object is rejected — a mutation that
|
||||
* silently does nothing is indistinguishable from one that failed.
|
||||
*
|
||||
* `addressText` is a label a human typed, never geocoded: matching happens on
|
||||
* the coordinates alone, so an empty or wrong label costs nothing but clarity.
|
||||
* The label used to be a free-text field stored beside coordinates that had
|
||||
* nothing to do with it. It is now whatever the geocoder called the point the
|
||||
* server resolved, so the text and the pin cannot drift apart.
|
||||
*/
|
||||
export const updateLocationSchema = z
|
||||
.object({
|
||||
location: latLngSchema.optional(),
|
||||
addressText: z.string().trim().max(255).optional(),
|
||||
place: locationInputSchema.optional(),
|
||||
radiusM: z.number().int().min(MIN_SERVICE_RADIUS_M).max(MAX_SERVICE_RADIUS_M).optional(),
|
||||
})
|
||||
.refine((v) => Object.values(v).some((field) => field !== undefined), {
|
||||
@@ -102,6 +144,44 @@ export const updateSkillsSchema = z.object({
|
||||
});
|
||||
export type UpdateSkillsInput = z.input<typeof updateSkillsSchema>;
|
||||
|
||||
export const searchSortSchema = z.enum(['best', 'nearest', 'rating', 'price']);
|
||||
export type SearchSort = z.infer<typeof searchSortSchema>;
|
||||
|
||||
/**
|
||||
* The one unbounded public input in this API.
|
||||
*
|
||||
* Every field is capped, because `pro.search` is reachable without a session and
|
||||
* nothing else rate-limits it yet: the query string has a length, the page has a
|
||||
* ceiling, and the radius cannot exceed what a pro could ever serve. These caps
|
||||
* are a cost bound, not a rate limiter — see the note on the procedure.
|
||||
*/
|
||||
export const searchProsSchema = z.object({
|
||||
q: z.string().trim().max(MAX_SEARCH_QUERY_LENGTH).optional(),
|
||||
categoryId: z.string().uuid().optional(),
|
||||
maxDistanceM: z.number().int().min(MIN_SERVICE_RADIUS_M).max(MAX_SERVICE_RADIUS_M).optional(),
|
||||
/** A floor, not a bucket: 4 means "4.0 and up". Unrated pros are excluded by any floor. */
|
||||
minRating: z.number().min(0).max(5).optional(),
|
||||
maxHourlyRateCents: centsSchema.max(MAX_QUOTE_CENTS).optional(),
|
||||
sort: searchSortSchema.default('best'),
|
||||
limit: z.number().int().min(1).max(MAX_SEARCH_RESULTS).optional(),
|
||||
});
|
||||
export type SearchProsInput = z.input<typeof searchProsSchema>;
|
||||
|
||||
/**
|
||||
* One page of a pro's written reviews.
|
||||
*
|
||||
* Public and session-less like `searchProsSchema`, so the page size is capped
|
||||
* for the same reason. The cursor is the `publishedAt` of the last row the
|
||||
* caller already has — keyset rather than offset, because reviews are ordered
|
||||
* newest-first and a new one landing mid-scroll would shift every offset.
|
||||
*/
|
||||
export const proReviewsSchema = z.object({
|
||||
proId: z.string().uuid(),
|
||||
limit: z.number().int().min(1).max(MAX_REVIEWS_PAGE).optional(),
|
||||
cursor: z.coerce.date().optional(),
|
||||
});
|
||||
export type ProReviewsInput = z.input<typeof proReviewsSchema>;
|
||||
|
||||
export const swipeSchema = z.object({
|
||||
jobId: z.string().uuid(),
|
||||
proId: z.string().uuid(),
|
||||
@@ -147,11 +227,24 @@ export const createReviewSchema = z.object({
|
||||
});
|
||||
export type CreateReviewInput = z.infer<typeof createReviewSchema>;
|
||||
|
||||
export const sendMessageSchema = z.object({
|
||||
matchId: z.string().uuid(),
|
||||
body: z.string().min(1).max(4000),
|
||||
attachments: z.array(z.string().url()).max(5).default([]),
|
||||
});
|
||||
/**
|
||||
* A message needs SOMETHING in it, but not necessarily words.
|
||||
*
|
||||
* `trim()` runs before the check, so a message of nothing but spaces is rejected
|
||||
* rather than stored as an empty bubble. A photo of the leak with no caption is
|
||||
* a perfectly good message, though — which is why the length floor is on the
|
||||
* pair rather than on `body`.
|
||||
*/
|
||||
export const sendMessageSchema = z
|
||||
.object({
|
||||
matchId: z.string().uuid(),
|
||||
body: z.string().trim().max(4000).default(''),
|
||||
attachments: z.array(z.string().url()).max(5).default([]),
|
||||
})
|
||||
.refine((v) => v.body.length > 0 || v.attachments.length > 0, {
|
||||
message: 'Write something or attach a file',
|
||||
path: ['body'],
|
||||
});
|
||||
export type SendMessageInput = z.infer<typeof sendMessageSchema>;
|
||||
|
||||
export const credentialSchema = z.object({
|
||||
|
||||
@@ -20,6 +20,35 @@ type Graph<T extends string> = Readonly<Record<T, readonly T[]>>;
|
||||
export const JOB_STATUSES = ['open', 'matched', 'booked', 'completed', 'cancelled'] as const;
|
||||
export type JobStatus = (typeof JOB_STATUSES)[number];
|
||||
|
||||
/**
|
||||
* The live half of the job lifecycle.
|
||||
*
|
||||
* "Is this job happening or is it history?" is asked by the jobs list, the
|
||||
* counts on it and the chat composer, so the answer is defined once here rather
|
||||
* than as three copies of the same status array.
|
||||
*/
|
||||
export const ACTIVE_JOB_STATUSES: readonly JobStatus[] = ['open', 'matched', 'booked'];
|
||||
export const PAST_JOB_STATUSES: readonly JobStatus[] = ['completed', 'cancelled'];
|
||||
|
||||
/**
|
||||
* How a stored coordinate was obtained.
|
||||
*
|
||||
* Not a status — nothing transitions between these — but it lives here with the
|
||||
* other unions because the DB enum is generated from it (schema/enums.ts) and a
|
||||
* value that exists in one place and not the other is the bug this file exists
|
||||
* to prevent.
|
||||
*
|
||||
* `exact` a geocoded street address. Safe to rank on.
|
||||
* `approximate` a street, postcode or device GPS fix. Real, but not a rooftop.
|
||||
* `city` nothing resolved; the point is the city centre. A placeholder,
|
||||
* and labelled as one so no surface can mistake it for a location.
|
||||
*/
|
||||
export const LOCATION_PRECISIONS = ['exact', 'approximate', 'city'] as const;
|
||||
export type LocationPrecision = (typeof LOCATION_PRECISIONS)[number];
|
||||
|
||||
/** Points good enough to measure distance from. */
|
||||
export const LOCATABLE_PRECISIONS: readonly LocationPrecision[] = ['exact', 'approximate'];
|
||||
|
||||
export const REQUEST_STATUSES = ['pending', 'accepted', 'declined', 'expired'] as const;
|
||||
export type RequestStatus = (typeof REQUEST_STATUSES)[number];
|
||||
|
||||
@@ -58,7 +87,11 @@ export type VerificationStatus = (typeof VERIFICATION_STATUSES)[number];
|
||||
const JOB_GRAPH: Graph<JobStatus> = {
|
||||
open: ['matched', 'cancelled'],
|
||||
matched: ['booked', 'open', 'cancelled'], // back to `open` when every match falls through
|
||||
booked: ['completed', 'cancelled'],
|
||||
// 'matched' because a cancelled booking is not a cancelled job: the customer
|
||||
// still wants the work and their other conversations are untouched, so the job
|
||||
// goes back to the market rather than dying with the slot. Same spirit as
|
||||
// 'matched -> open' above.
|
||||
booked: ['completed', 'cancelled', 'matched'],
|
||||
completed: [],
|
||||
cancelled: [],
|
||||
};
|
||||
@@ -79,7 +112,11 @@ const QUOTE_GRAPH: Graph<QuoteStatus> = {
|
||||
};
|
||||
|
||||
const BOOKING_GRAPH: Graph<BookingStatus> = {
|
||||
scheduled: ['in_progress', 'cancelled'],
|
||||
// 'awaiting_confirmation' directly, because `in_progress` is optional.
|
||||
// Marking a job started is useful to a customer waiting for someone to turn
|
||||
// up, but a twenty-minute job finished by a pro who never tapped Start is the
|
||||
// common case, and being unable to say it is done would be absurd.
|
||||
scheduled: ['in_progress', 'awaiting_confirmation', 'cancelled'],
|
||||
in_progress: ['awaiting_confirmation', 'cancelled', 'disputed'],
|
||||
awaiting_confirmation: ['completed', 'disputed'],
|
||||
completed: ['disputed'], // a dispute can still be raised inside the window
|
||||
|
||||
Reference in New Issue
Block a user