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>
Acts on an adversarial review of the M1 auth and authorization code.
Five findings fixed; the rest recorded in SECURITY-FINDINGS.md as the
M1 exit criteria rather than left in a tool transcript.
- auth: serve /phone-number/request-password-reset, /phone-number/
reset-password and /sign-in/phone-number as 404. better-auth's
phoneNumber() registers all three unconditionally -- they are NOT
gated on emailAndPassword.enabled:false. Left live they form a
silent second credential path: request-password-reset stores an OTP
and sends no SMS (sendPasswordResetOTP was never configured, so the
owner is never told), reset-password mints a bcrypt credential row,
and sign-in/phone-number then accepts it forever with no OTP. The
OTP gate still applies, so this is not remote unauthenticated
takeover -- it converts one momentary OTP compromise into permanent
access the victim cannot see or rotate.
- auth: drop bearer(). It accepts the plaintext sessions.token column
as an Authorization credential, making any single leaked row a
replayable login. The mobile client it was added for is hypothetical.
- auth: pin E.164 via phoneNumberValidator, and add toE164/isE164 to
@linkder/shared. phone is UNIQUE and bans are per-account, so
"+34600111222" and "0034600111222" being separately storable meant
one handset could hold two accounts and a ban was escapable by
retyping. 15 tests.
- auth: NEXT_PUBLIC_APP_URL now throws in production instead of
falling back to localhost, which was silently dropping Secure and
the __Secure- prefix from the production session cookie.
- pro.upsertProfile: actually apply requiresReReview. It was computed,
returned to the client and never acted on, so a verified plumber
could become a verified electrician in another city by ignoring a
response flag. Now demotes to pending in the same transaction and
audits it. Trade changes count as material (they did not before) --
the licence is per-trade. Needed a verified -> pending edge in
VERIFICATION_GRAPH, which did not exist.
Removed two untracked scratch repro files. The impersonation repro
depended on bearer() for transport and no longer applies as written;
the underlying finding (resolveSession drops impersonatedBy, so admin
actions are audited as the victim) is open and documented.
typecheck, lint, build clean; 127 tests pass.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Greenfield scaffold for Linkder, a swipe-to-hire marketplace for local
professional services.
- pnpm/turbo monorepo: apps/web, packages/{shared,db}
- Postgres 16 + PostGIS via docker compose (ports 5442/6389 to avoid
clashing with other local stacks)
- Drizzle schema, 23 tables, geography(Point,4326) with GiST indexes
- Domain core in packages/shared: integer-cent money, status transition
graphs, deck ranking weights, cancellation policy — 46 unit tests
- Deck query: filtering in Postgres on the GiST index, ranking in JS so
the weights stay tunable — 18 integration tests against a seeded DB
- Deterministic seed placing pros at known distances, including three
that must NOT appear on a deck (out of radius, unverified, away)
- Next.js 15 app shell with a working swipe deck
- CI: typecheck, lint, test, build against live postgres+redis
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
