WastePlace Boston Pilot — Wiring-Trace Explorer

Business decisions — decide before/at Day 0 (they shape code)

Recommendations are scoped to WIRING_GUIDE v0 (DR/JR instant booking; RS + leads deferred). Full sources + detail in MASTER_INVENTORY.md §(c).

Engineering decisions — decide before the day that builds them

Tab · Boston routing

How only Boston metro reaches the new marketplace experience

The decided v0 routing architecture: one domain, one dedicated landing route, one authoritative gate, and a graceful redirect whenever city/zip is known — the fallback the team agreed on. Grounded in MASTER_INVENTORY.md (S1 · S2 · M13 · E22 · B6 · B13 · E4), WIRING_GUIDE.md §1–2, and read-only verification against platform-develop.

How it works — you're in Boston and you type wasteplace.com

Cloudflare has already placed your connection in the Boston metro (DMA 506) before the page loads — the Worker forwards you in ~50ms to the Boston experience. You never see the national homepage; to you, wasteplace.com IS the Boston instant-booking site. Type your zip, see real prices, book with 10% down.

Wrong guess (VPN, mobile carrier)? A quiet "Not in Boston? → main site" link — one click, remembered for 90 days.
Search engines are exempt — Google always sees the national homepage, so SEO stays intact.
Only front doors forward (/ and /get-quotes) — deep links are never hijacked.
The zip you type is the final word — a non-Boston zip slides you into the classic bid flow with your inputs carried.

The decision

Decided — v0

Single domain. Everything lives on the existing app domain. No boston. subdomain for v0 — a subdomain splits the Meteor login token, the GTM attribution cookies, and SEO authority, for zero gating benefit.
One dedicated Boston landing route: /boston — a new public route in imports/routes/public/index.js. All geo-targeted ad spend points there; ?lob= carries the service card into the right intake tab (E22).
The service ZIP is the only authoritative gate. Enforced server-side by bostonGate.isBostonZip (M13, imports/api/Marketplace/helpers/server/bostonGate.ts) at draft creation in marketplace.createDraftQuote, re-checked at bookMarketplaceJob.
City/IP detection now AUTO-ROUTES entry pages (seamless — decided Kado 2026-06-10) — a Cloudflare Worker 302s Boston-DMA visitors from neutral entry pages (/ and /get-quotes) to the Boston flow — with crawler exemption, a one-click 90-day opt-out, and the ZIP gate as corrector. Full code: GEO_ROUTING_GUIDE.md. No IP geolocation exists in the platform today (verified); it stays out of v0. How the majors implement it (and our path): nobody does GeoIP lookups in app code — geo resolution happens at the CDN edge and the app reads trusted headers: Cloudflare CF-IPCountry + visitor-location Managed Transforms (city/region/postal), Akamai EdgeScape, CloudFront CloudFront-Viewer-City/Postal-Code, Fastly geo. WastePlace already runs Cloudflare (Workers/CSM stack) — proxy app.wasteplace.com through CF, enable the visitor-location Managed Transform, and the CF Worker at the edge 302s the entry pages (deployable code in GEO_ROUTING_GUIDE.md); DMA-grain (506) is the signal precisely because city-level IP accuracy is ~70–85% and mobile carrier CGNAT regularly places a Boston phone elsewhere in New England — which is exactly why Home Depot seeds a default store from IP but prices by the ZIP you type, and why Google penalizes IP-forced redirects. Two stronger "big-boy" rungs that need zero IP code: (1) Google Ads DMA geo-targeting does GPS-grade detection before the visitor ever arrives — paid traffic simply lands on the Boston pages; (2) a "Use my location" button on the zip field (HTML5 Geolocation, permission-prompted, reverse-geocoded via the existing Google key) — the store-locator pattern, precise and consensual.
Flag OFF = kill switch. Settings.isFeatureEnabled('instant_marketplace') (S1; mechanism at imports/core/Settings/index.js:217) false → everything routes legacy, byte-identical; /boston degrades to a polite coming-soon redirect.
Graceful redirects whenever city/zip is known — both directions, entered fields preserved, attribution preserved. Never a dead end; never a forced switch.

Industry patterns — how the majors route by location, and what we copy

Pattern	Who runs it (observable practice)	What we copy
Explicit destination URLs per market — path-based city pages on one domain; geo-targeted ads land directly on them	Uber (`uber.com/cities/boston`), Thumbtack & Angi city/service landing pages, Yelp city directories; Craigslist is the subdomain variant (`boston.craigslist.org`)	`/boston` as the ad + SEO front door — same domain, no subdomain
Geo/IP = default suggestion only — IP may seed a default; a visible switcher + typed ZIP override it; the choice is persisted ("My Store")	Home Depot / Lowe's: ZIP entry selects the local store and pricing & inventory follow the selected store, not the IP; Walmart runs the same model	We deviate here (seamless decision): the Worker auto-routes entry pages by DMA 506; the typed service ZIP remains pricing/booking truth, persisted in `wp_market`
Address/ZIP is the transactional gate — browse freely; the service address decides what you can buy, enforced at order time	DoorDash / Instacart (delivery address gates the catalog), Comcast/Xfinity serviceability check, Domino's fulfilling-store assignment by exact address	Server-side `isBostonZip(serviceZip)` at draft creation, re-asserted in `bookMarketplaceJob()` — the gate is the law; routing is UX
No IP-forced redirects (SEO) — Google's locale-adaptive guidance: avoid IP-based content adaptation and auto-redirects; use explicit URLs + visible links/banners	Google Search Central documentation; Google itself replaced IP country-redirects with explicit choice	We deviate deliberately (seamless decision): entry pages geo-302 — but crawlers are exempt so indexed content never varies for bots, deep pages never redirect, and canonicals stand; the deviation is mitigated, not ignored

The consensus stack every one of them converges on — explicit market URLs at the front → soft geo as a suggestion with a visible switcher → the user's explicit location persisted → hard enforcement only at the transaction. That is exactly the ladder + matrix above; we copy three of the four wholesale and deviate deliberately on entry-page geo (seamless auto-route, decided 2026-06-10) with the guardrails recorded above.

The granular fix — persistence, precedence, and the mess-up fallback

Persistence (D1): wp_market cookie — boston | legacy, 90-day TTL, set only on an explicit signal (typed service ZIP, or a signed-in account whose last service address passes the gate). Never set from IP or ad params — those are hints, not choices. Signed-in accounts mirror the value server-side so devices agree.

Precedence (highest wins, evaluated per page load): typed service ZIP → account's last service address → wp_market cookie → ?zip=/?city= ad params → geo Worker (Layer 1 — auto-routes entry pages; GEO_ROUTING_GUIDE.md). An explicit signal overwrites the cookie; geo (DMA 506) auto-routes the neutral ENTRY pages per the seamless decision (bots, opt-outs, and explicit choices exempt); the typed ZIP remains the only signal that can move money.

The mess-up fallback — zip enforcement as the safety net: whenever the server gate contradicts the route that got the user there (Boston ZIP typed on legacy, non-Boston ZIP on /boston, ZIP edited mid-draft, stale cookie after a move), the response is always the same: field-preserving redirect per the matrix — automatic, toast-confirmed, UTM/gclid carried, prices recomputed never reused. Multi-zip quotes short-circuit to call-for-pricing on the Boston DID (decided rule — Bid vs Buy collision #11).

The "we messed up" KPI: gate-correction rate — the share of drafts where server-side zip enforcement reversed the initial routing. One counter in the gate, logged from day one. Sustained >~2% means the front door is mis-targeted (ads geo, landing copy, cookie TTL) — fix upstream; never loosen the gate.

Mapped to the live site — www.wasteplace.com parsed

The production estate is a Webflow marketing site (www) + the Meteor app (app.wasteplace.com). The funnel today: homepage → www/get-quotes (service selector) → app.wasteplace.com/get-quotes/<lob> (legacy intake). Crucially, Boston SEO city pages already exist — /us/dumpster-rental-boston-ma plus cross-linked Boston Junk Removal / Waste Services / Compactor pages — currently carrying bid-era copy ("Let Local Haulers Compete", "Bids: 2") and the national (833) number.

Tier	Boston experience	Non-Boston (the live version, untouched)
Marketing (Webflow — copy edits only, zero engineering)	The 4 existing Boston city pages become the front doors: buy-flow copy ("book instantly at a real price"), CTAs repointed to `app.wasteplace.com/boston`, Boston DID replaces (833), "Recently Booked" proof restricted to metro zips (today it shows Webster 01570 / Gardner 01440 — not metro). Geo-targeted ads land here. SEO equity preserved — same indexed URLs.	Homepage, all other city pages, `/get-quotes` bridge: byte-identical. The Worker already auto-routes `/get-quotes`; an optional static "In Boston?" link there is belt-and-suspenders for proxy-off windows only.
App (Meteor — where the flag + gate live)	New route `app.wasteplace.com/boston` (the /boston decision maps to the app host; www stays Webflow). Zip-first intake per the decision; Boston zip typed in the LEGACY intake → seamless auto-switch carrying fields; server gate enforces at draft + booking.	`/get-quotes/<lob>` legacy intake unchanged for everyone; non-Boston zips typed in /boston hand off here with fields carried. Flag OFF → /boston degrades to this.
Phone	Boston DID on Boston pages + the new flow (market-attributed).	National (833) 757-7765 everywhere else, unchanged.

Geo on the homepage itself (the Webflow constraint): www can't run app code, but orange-clouding the DNS through Cloudflare puts a Worker in front of Webflow — it reads the visitor-location headers and, for Boston-metro visitors on /, injects the "Boston: instant booking is live →" 302 to the Boston flow — the seamless decision. Guardrails that make it safe: crawler UA exemption (bots always see canonical content, SEO preserved), wp_noboston one-click 90-day opt-out, wp_market=legacy respect, entry-pages-only (deep SEO pages never redirect), 302 never 301, and the ZIP gate correcting the ~15–30% city-IP error cases in one click. The team already ships CF Workers, so this is an afternoon. Why this beats a new landing page: the Boston city pages are already indexed and already where geo traffic lands — repointing their CTAs is a Webflow copy task, not an engineering one, and non-Boston literally cannot regress because nothing it touches changes.

Entry-point inventory

Every way a person arrives, and what each one sees. Only the first row is steerable by us; the rest are why the detection ladder (C) and redirect matrix (D) exist.

How they arrive	First touch	What they see	Boston signal at that moment
Geo-targeted paid ads Google/Meta, Boston-metro radius	`/boston?lob=dumpster-rental&utm_…&gclid=…`	Boston landing (wireframe 01) with the service card pre-selected via `?lob=` — the carry E22 flags as currently dropped.	Strong hint (ad targeting + params) — confirmed at the zip field.
Organic / SEO	`/` or `/boston` (the indexed Boston page)	Legacy home, or the Boston landing for Boston-intent queries.	None until a zip is typed.
Direct to existing site typed URL, returning customers	`/`	Legacy experience, unchanged.	None until zip entry or sign-in (ladder rung 2).
Bookmarks / old links	`/get-quotes`, `/get-quotes/:lob`	Legacy bidding intake (`ListingProcess`). A Boston zip typed (first field) triggers the seamless auto-switch (matrix row 1).	Appears the moment the zip is typed.
Email / SMS links from the pilot confirmations, offers, review asks	Tokenized deep links (tracking 15, review 16; magic-link pattern `/auth/verify`)	Their booked job — these are post-booking, so the gate has already passed. Links are flag-checked so a killed flag never strands them on a dead page.	Known (job carries `market:'boston'`).
Word of mouth "wasteplace boston"	Search → `/boston`	Boston landing; zip asked early per the wireframe pattern (D, row 3).	Implied — confirmed at the zip field.

The detection ladder

Ordered signals for "do we know they're Boston metro?" Each rung carries a confidence level and the strongest action it is allowed to take. Rung 1 routes; rung 4 (geo) also routes the neutral ENTRY pages per the seamless decision; rungs 2–3 suggest/prefill.

Explicit service ZIP typed in any intake

The authoritative signal. The zip a customer types into the intake (02 asks it in step 1; 17 leads with the address) is the only thing that decides which experience serves the job — and the server re-derives the answer with bostonGate.isBostonZip at draft creation, so a spoofed client changes nothing.

AuthoritativeRoutes the flowGate = M13 · D1

Logged-in account's last service-address zip

High confidence about the account, not the next job — org accounts have mixed-city sites. Reads the user's most recent job serviceAddress (existing field, imports/api/Job/schemas/job.js). Allowed action: a suggestion banner — the deliberate exception: an authenticated mid-session is never yanked; the entry pages and the zip already deliver the seamlessness.

HighSuggest onlyD1

?zip= / ?city= query params on ad links

Medium confidence — it reflects ad targeting, not a typed address. Allowed action: prefill the zip field and open the Boston intake, with the value re-confirmed the moment the customer touches the field. A query param never creates a draft on its own.

MediumPrefill + confirmD1

IP geolocation

Layer 1 of the seamless decision — the CF Worker auto-routes the entry pages by DMA 506 (GEO_ROUTING_GUIDE.md). Nothing existed before — verified: the only IP handling in the platform is x-forwarded-for parsing for email-validation abuse limits (imports/api/User/server/emailValidation.ts:219), and imports/ui/helpers/getGeoLocation.js geocodes addresses, not IPs. Adding it means a CDN header or a client geolocation API — now Layer 1 of the seamless decision — the CF Worker auto-routes entry pages by DMA 506 at launch (GEO_ROUTING_GUIDE.md); the in-app HTML5 geolocation button remains optional/deferred.

DMA-grainRoutes entry pagesD0–D1

The graceful-redirect matrix

The centerpiece: every situation where city/zip becomes known, and exactly what happens. One shared banner/hand-off component serves both directions (E, row 4). The preservation rule below the table applies to every row.

Situation	What happens (decided)	What carries over
Boston zip typed on the LEGACY intake `/get-quotes` (`ListingProcess`)	Seamless auto-switch — the zip is the FIRST field, so nothing meaningful is lost and everything typed is carried. Brief toast on arrival: "Boston has instant booking — we switched you to live prices." Sets `wp_market=boston`; the opt-out link returns to legacy and is remembered 90 days.	zip, `lob`, entered address → query params + sessionStorage mirror. UTM cookies untouched (same domain).
Non-Boston zip on the `/boston` intake	Seamless hand-off into the legacy bidding intake `/get-quotes/:lob` with honest copy: "Instant booking is Boston-only for now — get competitive bids from local haulers instead." Fields pre-filled on arrival; the customer keeps moving, no dead end, no re-typing. (E22's decided divert.)	zip, `lob`, entered address — same carry rule. Attribution cookies persist.
Zip unknown	Ask the zip early — already the wireframe pattern: 02 asks ZIP inside step 1's service-address block with the inline "In Boston service area" check (`wireframes/02-intake-form.html:125–127`); 17 leads with address-only entry (`wireframes/17-rs-entry.html`). No detection guessing before an explicit answer exists.	n/a — nothing to carry yet; `?lob=` from the landing cards is preserved into the intake tab (E22).
Account-known Boston customer signs in on legacy	Suggestion banner on the dashboard/intake (deliberate exception: an authenticated mid-session is never yanked — entry pages + zip already cover seamlessness): "Your last service address is in Boston — instant booking is available." Never forced — the account is not the job (ladder rung 2; org mixed-city rule in F).	Nothing moves until they click; the click opens `/boston` with their zip prefilled.
Flag OFF (kill switch)	`/boston` renders a one-line coming-soon ("Instant booking is paused — get bids instead") and forwards to `/` via the `FlowRouter.redirect` pattern (`imports/routes/redirect/index.js`). Legacy is byte-identical — the WIRING_GUIDE §2 deploy proof. Ads get paused operationally; the route still degrades politely for stragglers.	UTM cookies persist; any sessionStorage field state is kept for when the flag returns.
Service ZIP edited mid-draft (re-hydration after cards were priced)	Three-way rule: new zip is Boston → stay in BUY, cards invalidate + re-price (state-C skeleton, never stale); new zip non-Boston → graceful hand-off to legacy BID with fields carried; more than one service zip in the same quote → call-for-pricing on the Boston DID (no self-checkout; multi-location coordinator pattern). Full resolution: Bid vs Buy tab, collision #11.	Intake fields + UTM carried; priced cards always recomputed — a price is never reused across zips.
Deep link to a mid-flow page (05 results / 07 checkout) without a draft	Bounce to the `/boston` intake with a "let's rebuild your quote" notice. The draftId travels in the URL/session per E4 — never sessionStorage-only — so an absent or TTL-expired draft means a clean restart, prefilled with whatever field state sessionStorage still holds.	Whatever intake fields survive in sessionStorage; UTM cookies persist; a valid draftId in the URL re-hydrates via `marketplace.selectCard`'s round-trip (M3) instead of bouncing.

Preservation rule — applies to every redirect

UTM / gclid: GTM already writes __gtm_campaign_url / __gtm_referrer cookies; getUTMObject() (imports/shared/helpers/client/cookies.js) reads them and analytics.saveAttribution (imports/api/Analytics/methods/analytics.js:32, idempotent first-touch, isLogged) persists them to the attribution collection — called today at SignUp.jsx:40 and ListingProcess.jsx:63; the marketplace flow calls it right after checkout creates the account (E1). Client-side redirects on one domain never lose these cookies — this is the core argument against a subdomain.

Entered data: zip + lob + address carry as query params; bulkier intake state mirrors to sessionStorage; the draftId itself carries in the URL/session per E4 — it is the one thing never trusted to sessionStorage alone.

Implementation map

The whole routing layer is a small build: one route, one gate, one Settings array, one shared component. Everything lands Day 1; the geo Worker ships Day 0–1 (GEO_ROUTING_GUIDE.md).

Piece	Where / how	Exists today	Day
`/boston` route + flag guard	New entry in `imports/routes/public/index.js`; guard via `triggersEnter` redirect — the exact pattern already used by `/get-quotes/:lob`'s LOB whitelist (`public/index.js:94–106`). Registered automatically by `initializeRouter()` in `imports/startup/client/router.js` (ostrio:flow-router-extra; see `docs/ROUTING.md`).	Pattern exists route is net-new	D1
`bostonGate`	New `imports/api/Marketplace/helpers/server/bostonGate.ts` — `isBostonZip(zip)`, `isMarketplaceJob(job)` (M13). Reads the flag through `Settings.isFeatureEnabled('instant_marketplace')`.	Flag mechanism exists `Settings/index.js:217`; gate is net-new — already planned	D1
Boston zip set	Settings array (S2, per E22) under a public key so the client's inline "In Boston service area" check reads the same list the server enforces. Governance: ops owns additions — one Settings edit per zip, no code deploy. Rejected home: `zipCodeArea` is a radius-lookup cache (`zipCode + radius + relatedZipcodes`, filled from the zipcodes.com radius API — `imports/shared/helpers/server/geocoding.js:53`, schema `imports/api/Marketplace/schemas/zipcodeArea.js`), the wrong shape for an authoritative allow-list.	Net-new value	D1
Auto-switch / hand-off component	One shared client React component (`imports/ui/components/`) used in both directions: legacy→Boston auto-switch toast and Boston→legacy hand-off screen. Props: direction, carried fields, dismissal persistence. One component means the carry logic can never fork.	Net-new	D1
Server-side enforcement	The gate re-checks inside `marketplace.createDraftQuote` (M1) and `bookMarketplaceJob` (M4). Client routing is UX; the server is law — no draft, card, or booking can exist for a non-Boston zip regardless of what the client renders.	Net-new (with M1/M4)	D1
Geo Worker (Layer 1, seamless)	Cloudflare Worker 302s Boston-DMA (506) visitors from the neutral entry pages — deployable code, wrangler config, exemptions, and test matrix in `GEO_ROUTING_GUIDE.md`. Nothing existed before (verified, §C); the in-app HTML5 geolocation button stays optional/deferred.	Net-new (Worker)	D0–D1

Edge cases

The boundaries where the simple rule needs a stated answer.

Borderline metro zips

Governance, not code: ops adds the zip to the Settings array — one edit, no deploy. Until then the intake shows the page-20 demand-signal pattern copy — "not yet in Boston metro" — plus the legacy hand-off and the Boston DID. A real, answerable non-555 number is a Day-1 launch blocker (B13); the demand-signal waitlist record itself (C22 marketDemandSignals) stays DEFER.

Org accounts with mixed-city addresses

The gate keys on the per-JOB service zip, never the account. A Boston-HQ org booking a Worcester site gets legacy bidding for that job. Suggestions (ladder rung 2) may read the account's history; enforcement never does. Parent/child billing resolution (docs/ORGANIZATIONS.md) is untouched by routing.

SEO

/boston is the indexed Boston marketing page with a self-referencing canonical; legacy marketing pages keep their own canonicals; body copy is never duplicated between /boston and /. Non-Boston diversions are client-side hand-offs after explicit zip entry, so there is no crawl-cloaking concern.

RS suite deferral

On /boston, the DR and JR cards route to the intake (02). The RS card routes to the thin lead path per B6 — the marketplaceLeads record + Slack alert (C21/M21) — because pages 17–22 are post-v0. Never wire it to listings.createForNewUser (invertedFlow.js:104): that path emits JOB_POSTED into bidding, which Boston jobs must never do.

Bookmarked `/boston` after kill-switch

Flag OFF: the route renders one honest line — "Instant booking is paused — get bids instead" — then forwards to / (the FlowRouter.redirect pattern, imports/routes/redirect/index.js). No 404, no blank page, no stranded ad traffic. Mid-flow deep links degrade the same way via the matrix's last row.

Decision summary

One domain, one new public route: /boston, defined in imports/routes/public/index.js. No subdomain in v0 — cookie, session, and SEO splits with no gating benefit.
Ads aim, the zip decides: geo-targeted spend points at /boston, but only the typed service ZIP routes a job anywhere.
Server is law: bostonGate.isBostonZip enforces at draft creation and booking; every piece of client routing is courtesy UX on top of it.
Graceful redirects, both directions, always: whenever city/zip is known, the customer is offered (legacy→Boston) or handed off (Boston→legacy) with fields and attribution preserved — never a dead end, never a forced switch for signed-in users.
Flag OFF is a true kill switch: legacy byte-identical, /boston degrades to a polite redirect, bookmarks and ad stragglers survive.
IP geolocation stays out of v0: nothing exists in the platform today; query-param and account hints cover the ad funnel.
Build cost: everything in this tab is Day 1, with the geo Worker shipping Day 0–1 (GEO_ROUTING_GUIDE.md) — one route, one gate, one Settings array, one Worker, one shared auto-switch component.

Refactoring CTO review · Fowler / Feathers pattern vocabulary

Migration strategy — strangle the auction, don't overload it

We are not "adding a status to Jobs." We grow a new bounded context (Marketplace/) around the legacy Jobs monolith and route a thin slice of traffic (Boston + flag) into it, while the legacy auction runs byte-untouched. That is the Strangler Fig. Every other pattern below is a named mechanic that makes the fig safe. Full write-up: migration/MIGRATION_STRATEGY.md; the entity set it realizes is the Entity model tab and migration/ENTITY_MODEL.md.

Why this wins the skeptic: the team already refactors this way (verified read-only)

A Strategy seam with unimplemented stubs — executeBookingStrategy (imports/api/Payment/server/booking.js:56-61) already has case 'instant' / case 'delta' literally throwing "not implemented yet". We fill the 'instant' case — we don't add an if.
A gated parallel-run of two Stripe implementations — processWithNewStripeImplementation vs processWithLegacyStripeImplementation (imports/api/Payment/methods/process.js:399 / :224), switched by a Settings flag at :698.
Three forked job-creation pipelines by source — createJob (Job/methods/listing/helpers.js:128), createJobForNewUser (…/server/invertedFlow.js:42), createJobFromOscar (Oscar/server/quoteHandler.js:265).
An instant-book path that already bypasses bidding — bookInstantRate (imports/api/InstantRate/services/server/booking.js:49) with its own durable-timer scheduler (InstantRate/services/futureTasks.js).

You don't have to believe the marketplace journey can be forked safely. The team has already forked job creation three ways, parallel-run two Stripe implementations behind a flag, and stubbed an 'instant' booking strategy waiting to be filled in. We are completing a refactor the codebase started.

Pattern → seam map — every pattern grounded in a real file

Strangler Fig
(umbrella)

New Marketplace/ bounded context grows beside Jobs; a router sends only Boston+flag traffic into it; the legacy auction is untouched.

SeamRouter/facade = Marketplace/helpers/server/bostonGate.ts (isBostonZip, isMarketplaceJob) gating on flag instant_marketplace (imports/core/Settings/index.js:217) + service zip. New context = imports/api/Marketplace/*.

Branch by
Abstraction

Add the buy booking behind the existing dispatch abstraction instead of scattering if (isMarketplace) through process.js.

SeamexecuteBookingStrategy({bookingType}) (imports/api/Payment/server/booking.js:49). The 'instant'/'delta' cases (:59-61) are stubs. process.js:511 already computes bookingType and calls the strategy at :570 — we implement a case.

Anti-Corruption
Layer

One translation module isolates the new context from the legacy Jobs shape; buy money/assignment never leak onto the Job.

SeamMarketplace/acl/server/legacyJobBridge.ts (new). Materializes a legacy Job in active shape with a synthesized winningBid at provider accept only; mirrors JOB_COMPLETED back. Translation table: ENTITY_MODEL.md §6b.

Parallel Run

Run both models against the same reality during the pilot; reconcile before contracting.

SeamDual-write at accept: Booking (record for money/assignment) + materialized Job (record for completion/invoicing), linked by Booking.legacyJobId. Nightly reconcile on the §4 invariants. Precedent: the gated Stripe parallel-run at process.js:698.

Expand–Contract
(parallel-change)

Add the new context without breaking legacy (expand); contract the coupling only after it proves out.

SeamExpand: new collections are additive; the legacy Jobs.status enum gains nothing (Job/helpers/status.js untouched — the buy machine is the Booking's own). Contract: default C1 = keep the ACL permanent; C2 (absorb completion) only if retiring the bid model.

Event
Interception

Buy events are a disjoint vocabulary; a booking can never emit a bid event into the auction.

SeamEventBus (imports/core/EventBus). Buy emits MARKETPLACE_* only; the ACL never emits JOB_POSTED (the fan-out discriminator from createJob). Reverse: the ACL listens for JOB_COMPLETED (from the unchanged jobs.complete, Job/methods/jobs.js:475) to mirror completion back.

The router (facade) — how traffic is split

The gate is evaluated at intake, re-checked on every draft mutation, and re-asserted inside the booking service — so no booking can exist outside the gate, and the router never silently re-routes.

incoming intake / checkout

▼

bostonGate.isMarketplaceJob(zip)flag instant_marketplace (:217) AND isBostonZip(serviceZip)

▼

BUY contextMarketplace/* · DraftQuote → Booking

◀ true | false ▶

BID flow (legacy)createJob → JOB_POSTED → bids[] → scheduleJob · BYTE-UNTOUCHED

▼

flag OFF ⇒ facade short-circuits to BID everywhere — platform byte-identical · KILL SWITCH

The ACL boundary — drawn explicitly

Only the fields the shared completion/invoicing/payout pipeline reads cross the boundary, and they cross once, in active shape. Everything money/assignment-shaped stays in the context.

DraftQuoteSHOPPING

→pay 10%

BookingCONTRACTING

→ladder

acceptProviderOffer

→

ACL
materializeJoblegacyJobBridge.ts

→

legacy Jobstatus:'active', winningBid:synth(payout), winnerBidID

▼ event interception (reverse)

Booking.status='completed'mirrored from event

◀

intercept JOB_COMPLETEDEventBus

◀

legacy jobs.completeUNCHANGED · jobs.js:475

✕ stays left, never written onto the Job: payment{} (deposit/balance/refund) · assignment{} ladder · market · bookingReference · intake snapshot · payout snapshot

Coexistence invariants — break one, isolation breaks

Each is enforced structurally (by construction or guard), not by convention.

Born active, never open/booked-on-the-legacy-enum. The ACL writes the Job directly in active with a synthesized winningBid; it never calls scheduleJob, which hard-asserts status: STATUS.OPEN.value (Job/bidding/server/index.js:526-528, throws "not in open status"). The bidding matcher, every open publication, and JOB_POSTED fan-out can never see a buy job.
One terminal pipeline. active → completed/cancelled is the same legacy code for both flows, hinged on the synthesized winningBid/winnerBidID (bid precedent: winnerBidID: this.userId, Job/methods/jobs.js:297). No forked completion, invoicing, chat-auth, or archival.
The legacy enum gains nothing. The buy state machine lives on Booking.status, not Jobs.status. Job/helpers/status.js is untouched — the sharpest departure from the rejected "add 'booked'" plan.
Buy money never lands on the Job. payment{} lives on the Booking; the legacy paymentType/invoice/PaymentsHistory bid path is byte-identical. stripe.refunds.create is only ever invoked against Booking.payment PIs.
Disjoint sub-aggregates. A Job carries bids[]; a Booking carries assignment — different collections, never handed between flows. Legacy jobs.hauler.list keys on bids.audit.user (blind to buy pre-accept); the new provider publication keys on Booking.assignment.providerId.
Disjoint event vocabularies, intercepted. Buy emits MARKETPLACE_*; the ACL guards a booking never emits JOB_POSTED. Bid events fire only from createBid/expireJobs, which buy code never reaches.
Crons can't touch buy work. expireJobs queries status: {$in:['open','active']} and winningBid: {$exists:false} (System/server/cronjobs/jobs/expireJobs.js:65-66) — a buy Job is born active with a winningBid, so the second clause excludes it. Verified, no patch needed.
Flag + zip gate, fail-loud. Buy entry requires the flag ON and a Boston service zip, re-asserted at materialization. Flag OFF = byte-identical legacy. Gate failure halts/diverts loudly, never silently re-routes.
Idempotent money on one ledger. Every buy Stripe call carries a deterministic idempotency key off the shared correlationId base (Payment/methods/process.js:75-85); both flows log to PaymentsHistory. A re-fired timer cannot double-charge.

Phased cutover — and the risk each phase retires

Each phase is a flag-scope widening (team → pilot zips → broader), reversible by narrowing the flag. No big-bang switchover, no schema down-migration anywhere on the path.

P0 · Behind flag (dark)

FLAG OFF

Marketplace/ context, bostonGate facade, DraftQuote, Booking, ACL stub. Flag default OFF.

Retires: "does new code destabilize prod?" — flag OFF = byte-identical; staging deploy with flag OFF proves zero behavior change.

P1 · Money + ladder

FLAG ON · team accts

Implement 'instant' case in executeBookingStrategy; deposit/balance/refund PIs; webhooks; ladder on FutureTasks; ACL materialization at accept.

Retires: "does the new journey corrupt the shared pipeline?" — ACL writes only active-shape Jobs through the one seam; dogfood catches money bugs first.

P2 · Parallel run

FLAG ON · pilot zips

Flag ON for Boston pilot zips. Both models written at accept; nightly reconcile on the §4 invariants.

Retires: "do the two models agree on reality?" — reconcile surfaces drift (orphan bookings, Jobs missing winningBid, buy Jobs with bids[]) while the kill switch is one flip away.

P3 · Contract

FLAG ON · widen

After N clean reconcile-weeks: default C1 — keep the ACL permanent; the legacy Job is "the fulfillment record." C2 (absorb completion) only if retiring the bid model.

Retires: "are we carrying duplicate runtime mechanics?" — C1 retires it by design (completion never forked); C2 deferred.

▶▶▶

Rollback / kill-switch story

Primary kill switch (already exists): Settings.isFeatureEnabled('instant_marketplace') (imports/core/Settings/index.js:217). Flip OFF → the facade short-circuits → every request takes the legacy bid path → the platform is byte-identical to today. No deploy, no migration, instant.
Blast-radius containment: only three existing-file edits ship, all flag-gated — (a) implement the 'instant' case in executeBookingStrategy, (b) add a taskType discriminator to the FutureTasks startup dispatch (System/server/futureTasks.js), (c) add buy webhook cases to the Stripe webhook switch. None change bid-path behavior; flag OFF, none run.
Data rollback is trivial because data is additive. Buy lives in new collections (DraftQuotes, Bookings) + additive-optional fields elsewhere. Disabling the pilot strands no legacy data and needs no down-migration. In-flight bookings drain to completion through their materialized Jobs (valid active jobs regardless of the flag).
Reconcile-before-contract: the parallel-run reconcile is the gate on Phase C. If reconciliation drifts, you stop contracting and keep the ACL — you never lose the "legacy Job is the record" fallback.

New buy-journey entity model · SHOPPING → COMPLETION

Entity model — re-home the fields into a bounded context

The buy journey gets its own aggregates in Marketplace/; the legacy Jobs God-object stays untouched behind the ACL. Six of the ~9 fields the rejected plan bolted onto Jobs (market, bookingReference, marketplaceIntake, payment, assignment, payout) move off the Job entirely onto the new Booking; the status enum gains nothing. Full write-up + the complete field-remap: migration/ENTITY_MODEL.md.

Lifecycle — one stage owns one entity

SHOPPING

DraftQuote

Intake → priced cards → contact gate → select. Transient, TTL-deleted. PII boundary.

new collection

CONTRACTING

Booking

Created only after deposit succeeds. Owns money, booking ref, intake + payout snapshots. Aggregate root.

new root

ASSIGNMENT

ProviderOffer

Offer ladder embedded in Booking. The structural counterpart of legacy bids[].

embedded entity

FULFILLMENT

Fulfillment

Service window. A read model over (Booking.payment + legacy Job.status), not a write collection.

read model

COMPLETION

legacy Job

Materialized by the ACL at accept, in active shape. Runs the unchanged shared pipeline.

SHARED legacy

The legacy Jobs record is not a buy entity — it is the shared downstream substrate the ACL hands work to, appearing only at the COMPLETION stage.

The entities — purpose · key fields · states · ACL mapping

DraftQuoteSHOPPINGnew · Marketplace/collections/draftQuotes.ts

Purpose: hold an anonymous-or-named shopper's intake, priced provider cards, and the selected card until a deposit converts it or the TTL deletes it. The pre-contract state and the PII-minimization boundary.

Key field	Notes
`intake` (VO)	validates against `shared/schemas/domains/marketplace/v0/intake.ts`; shapes mirror legacy Jobs fields so ACL translation is a copy.
`pricedCards[]` (VO)	per provider: `{providerId, payoutCents, feeCents, customerPriceCents, rateRowId}` — integer cents.
`contact` (PII VO)	`{firstName,lastName,email,phone,consent{...}}` — written at the contact gate, never at intake.
`priceLockExpiresAt` / `ttlDeleteAt`	price-validity cliff vs the Mongo TTL delete date — deliberately distinct (open Q B9).

Statespricing → priced → contacted → (converted | TTL-deleted). converted is the only exit that produces a Booking.

ACLNone. A DraftQuote never touches Jobs, never emits a Job* event, invisible to every bid-flow cron/publication — a separate collection no legacy code imports.

BookingCONTRACTINGnew aggregate root · Marketplace/collections/bookings.ts

Purpose: the durable contract. Created only after the deposit PI succeeds (no unpaid Booking exists). Owns all buy money, the booking reference, immutable intake + payout snapshots, and the assignment ladder. The system-of-record ops/customer/provider key off.

Key field	Notes
`userInfo`	owner — house rule, never `audit.user`; resolved to parent billing account (`getParentUserId(userId) \|\| userId`).
`bookingReference`	`WP-BOS-NNNN` market-prefixed counter, written once (open Q E5).
`payout` (VO)	`{providerId?, payoutCents, rateRowId, frozenAt}` — frozen from the chosen card; later rate edits can't move it.
`payment` (VO)	`{depositCents, balanceCents, balanceDueAt, balanceCapturedAt, refundPolicyCliffAt, termsAcceptedAt, refunds[], ...}` — all integer cents.
`assignment` (entity)	the ProviderOffer ladder (next card).
`legacyJobId`	the ACL handle — null until accept materializes the legacy Job.
`status`	the bounded-context machine (next row), NOT the legacy `Jobs.status` enum.

States (Booking's own machine)booked → assigned → in_fulfillment → completed | cancelled. Ops unassign reverses assigned → booked (admin-only, hard-blocked once payment.balanceCapturedAt is set).

ACLHolds legacyJobId. Translation fires once, at assigned (provider accept), materializing a legacy Job in active shape. Before that, no Job exists.

ProviderOfferASSIGNMENTembedded in Booking · booking.assignment

Purpose: the offer-ladder state machine. The structural counterpart of legacy bids[] — but it lives in the new context, on the Booking, not on a Job.

Key field	Notes
`providerId`	currently-offered provider; null before first offer / after a reject.
`stage`	`offered → round_robin → ops_escalation → fomo_blast → accepted`.
`roundRobinPool[]`	ordered candidates from the matcher.
`history[]`	append-only `{providerId, action, at, reason?}` — audit trail; `reason` optional (open Q E14).

StatesIdempotent on stage + history[] — a re-fired ladder_timeout FutureTask cannot double-advance. accepted flips the Booking to assigned and triggers the ACL.

ACLOn accepted: freeze payout.providerId + call legacyJobBridge.materializeJob(). The single moment the two worlds connect.

FulfillmentFULFILLMENT → COMPLETIONread model — NOT a collection

Purpose + decision: represent the service window. Not a new collection — once the legacy Job is materialized, the service-window state is the Job's active → completed lifecycle; re-implementing tracking/completion/invoicing would fork the biggest pile of working code on the platform. So Fulfillment is a thin read model over (Booking.payment, legacy Job.status, legacy Job.closureDate).

What writes hereBalance capture (balance_capture FutureTask at serviceDate − 7d) → Booking.payment.balanceCapturedAt (buy context). Completion → unchanged legacy jobs.complete (Job/methods/jobs.js:475) stamps closureDate, emits JOB_COMPLETED (shared pipeline).

ACLThis stage is the boundary: buy context owns money (balance/refund); the legacy Job owns delivery/completion/invoicing. JOB_COMPLETED is intercepted to mirror completion back to Booking.status.

Value objects (embedded, integer-cents money): Money(cents) · ServiceAddress (+geocode) · PayoutSnapshot · FeeBreakdown{marginPct:10, feeCents, customerPriceCents} · Contact(PII). Plus MarketplaceLead (thin, pre-SHOPPING RS/out-of-scope demand capture).

Field-remap — every `FIELD_LEDGER.md` field → new home

Nothing is lost. Every field is re-homed into a new entity, kept on the legacy Job only when the shared pipeline reads it, or kept on existing collections that were never overloaded. Class: OFF-JOB moved onto Booking/DraftQuote · TRANSLATED crosses the ACL to the Job · BID-ONLY legacy field buy never touches · REUSED existing infra/collection · NEW new collection kept.

FIELD_LEDGER field (old: on Jobs)	New home	Class
Crosses the ACL to the materialized Job (shared pipeline reads it)
`userInfo`	`Booking.userInfo` + copied to Job	TRANSLATED (dual)
`type`	`Booking.lob` → `Jobs.type`	TRANSLATED
`serviceAddress{}` / `date` / `geocode`	`Booking.serviceAddress` / `.serviceDate` → Job	TRANSLATED
`winnerBidID` / `winningBid` (synthesized)	synthesized by ACL from `Booking.payout` at accept	TRANSLATED (the hinge)
`projectLength`,`size`,`materials[]`,`truckLoads`	`Booking.intakeSnapshot.*` → Job	TRANSLATED
`closureDate`	legacy `jobs.complete` stamps Job; mirrored to `Booking.status`	REUSED + event-mirror
Moves OFF the Job entirely → onto the Booking aggregate
`status` gains `'booked'`	`Booking.status` (own machine); legacy enum untouched	OFF-JOB — no enum change
`market:'boston'`	`Booking.market` — not on the Job at all	OFF-JOB
`bookingReference`	`Booking.bookingReference`	OFF-JOB
`marketplaceIntake{}`	`Booking.intakeSnapshot`	OFF-JOB
`payment{deposit/balance/refund/...}`	`Booking.payment` VO	OFF-JOB
`assignment{provider,stage,pool,history}`	`Booking.assignment` (ProviderOffer)	OFF-JOB
payout snapshot (chosen card)	`Booking.payout` VO	OFF-JOB
Stays where it was — never overloaded
`bids[]`,`instantRate{}`,`campaignId`,`paymentType`,`archived`,`audit{}`	stay on legacy `Jobs`, never written by buy	BID-ONLY untouched
`DraftQuotes{intake,pricedCards,selectedCard,contact,expiresAt}`	`DraftQuote` (always its own collection)	NEW kept
IR rate extensions (`rentalTerms`,`rush`,`travel`,`perCubicYardCents`…)	`InstantRate*` additive (read by buy pricer)	REUSED collection
`users.profile.marketplace{}`	`users.profile.marketplace` additive (ops-set)	REUSED collection
review-intake / strikes / `marketplaceLeads` / demand / coordinator	new `Marketplace/*` collections	NEW kept
`PaymentsHistory`,`FutureTasks`,`Invoices`,`Chat`,`zipCodeArea`,EventBus	reused infra (FutureTasks gains a `taskType` discriminator)	REUSED

Net: of the ~9 fields the rejected plan bolted onto Jobs, 6 move off the Job entirely into the Booking aggregate, and the status enum gains nothing. Only shared-pipeline fields (winningBid/winnerBidID, address/date/intake copies, type) ever touch a Job — once, at one ACL seam, in active shape.

Reframed (supersedes "extend Jobs / status=booked"). The buy journey is no longer modeled as additive fields on the legacy Jobs God-object. It now lives in its own bounded context — a Marketplace/ aggregate set (DraftQuote → Booking → ProviderOffer) — with the legacy Jobs collection left untouched behind an Anti-Corruption Layer. The buy money, the assignment ladder, the booking reference, and the market tag all live on the new Booking aggregate; they never touch a Job. The legacy Jobs.status enum gains nothing. See the Entity model and Migration (Strangler) tabs, and migration/ENTITY_MODEL.md / migration/MIGRATION_STRATEGY.md. The collision table below stands unchanged — it is the per-field coexistence proof, now read as "Booking-context vs legacy-Jobs" rather than "buy-fields vs bid-fields on one collection."

ATwo journeys, one shared terminal pipeline

Both flows end in the same place — a Job in active → completed with a winningBid — but they get there through different front halves and different data models. The bid flow writes a legacy Jobs record from intake; the buy flow lives in the Marketplace/ bounded context (DraftQuote → Booking) and only materializes a legacy Job — through the ACL, in active shape — at provider accept, so the shared completion/invoicing pipeline runs unchanged. The bid flow is byte-untouched everywhere; the buy context exists only behind the flag + Boston zip gate. Everything below is the decided design, verified against platform-develop read-only.

BID — reverse auction (legacy, everywhere)Customer posts · haulers bid · customer awards · pay in full at award

Post. listings.createJR|createDR|createRS (Job/methods/listing/gateway.js) → createJob() writes the Job at status:'open', populates instantRate.matched[], emits JOB_POSTED — fan-out to every eligible hauler in the service area (Job/events/JobPosted.ts).
Bid. createBid/updateBid (Job/bidding/server/index.js) push into bids[] — one bid per hauler, keyed bids.audit.user (:94) — and emit JOB_BID_PLACED to the customer. Pre-award chat threads open per hauler.
Award. Customer checkout → payments.process (Payment/methods/process.js): STRIPE = full-amount PaymentIntent charged immediately (confirm:true), or INVOICE = no card, invoiced later. Then scheduleJob — which hard-asserts the job is currently open (bidding/server/index.js:526-529) — sets winningBid, winnerBidID, paymentType, status active.
Complete. jobs.complete (Job/methods/jobs.js:475, mixins isWinner, isActive) stamps closureDate, emits JOB_COMPLETED.
Or die. jobs.cancel (customer, reason ≤300 chars) or the expireJobs cron (30 days stale, no winner → cancelled + jobExpired:true).

Status machine — bid

open

↓ award — scheduleJob (asserts OPEN) · pay full / INVOICE

active

↓ jobs.complete

completedTERMINAL

Side branches: open ⇄ pending — instant-rate confirm/decline only (bookInstantRate / confirmInstantRate / instantRateDecline) · open|active → cancelled TERMINAL via jobs.cancel or expireJobs. Authoritative table: docs/JOBS_SYSTEM.md.

BUY — instant marketplace (Boston, flag-gated)Customer shops · picks provider · 10% down · we assign · balance at D-7

Shop. Intake submit → marketplace.createDraftQuote writes a DraftQuote (not a Job), runs the existing matcher (instantRateMatcher.js:23), stores priced cards at the locked 10% calculated margin (MARKETPLACE.MARGIN_PCT). Contact gate PATCHes PII via marketplace.saveDraftContact.
Pay 10%. Checkout: deposit PI#1 (10%, immediate capture, setup_future_usage:'off_session'); ≤7 days out → single full-charge PI instead. No Job exists until the deposit succeeds.
Born booked. bookMarketplaceJob() (Marketplace/services/server/booking.ts) creates the Job directly in booked — never open, never through scheduleJob. Tags market:'boston', stamps bookingReference, copies marketplaceIntake{}, seeds payment{} + assignment{} + payout snapshot. Emits MARKETPLACE_JOB_BOOKED — guarded to never emit JOB_POSTED.
Ladder assigns. Offer → 12h timeout → round-robin → 48-business-hr escalation → ops + FOMO → manual (Marketplace/assignment/server/ladder.ts, timers via FutureTasks). Provider accepts → synthesize winningBid/winnerBidID from the priced card → status active.
Balance + complete. balance_capture FutureTask fires PI#2 off-session at service-date −7d; then the same jobs.complete runs untouched. Cancels refund on the tiered policy (>3d: minus deposit · ≤3d: none).

Status machine — buy

DraftQuote (pre-job)

↓ deposit PI#1 succeeds — bookMarketplaceJob()

booked

↓ provider accept — synthesize winningBid

active

↓ jobs.complete — identical code to bid

completedTERMINAL

Side branches: booked|active → cancelled TERMINAL via Marketplace/methods/cancel.ts + tiered refunds · admin-only active → booked unassign reversal (collision #13, E3) · booked never touches open or pending — no transition exists in either direction.

The hinge: accept synthesizes `winningBid` — so there is exactly one terminal pipeline

At booked → active, the accept method writes a winningBid object built from the priced card (amount = provider payout, audit.user = providerId, shape copied from what scheduleJob writes) and sets winnerBidID = providerId — mirroring the bid flow, where jobs.bidAndSchedule passes winnerBidID: this.userId (Job/methods/jobs.js:297). From that moment a buy job is indistinguishable from an awarded bid job to every downstream consumer:

· jobs.complete — its isWinner mixin checks winnerBidID; passes for both. · Invoicing & payout math — reads winningBid; same shape. · Chat auth — provider is the thread hauler; same check (Chat/methods.js:175-191). · Hauler dashboard "won" clause — 'winningBid.audit.user' (Job/server/publications.js:525) matches, so accepted marketplace jobs surface in the legacy hauler list automatically. · expireJobs — its winningBid: {$exists:false} clause can never match an active buy job. One active → completed/cancelled pipeline, zero forked terminal code.

BThe routing rule between flows

One gate, two inputs, no third path. A request enters the buy flow if and only if Settings.isFeatureEnabled('instant_marketplace') (imports/core/Settings/index.js:217) is ON and bostonGate.isBostonZip(serviceZip) passes against the Settings zip set — gated on the service zip, never billing, matching the existing tax-on-service-state rule. Everything else falls through to the bid flow exactly as it runs today; with the flag OFF the gate short-circuits and the entire platform is byte-identical legacy — that is the kill switch. The gate is evaluated at intake, re-checked on every draft mutation, and re-asserted inside bookMarketplaceJob() — it never silently re-routes (deep mechanics, zip-set home, and URL exposure live in the sibling Boston routing tab; not duplicated here).

instant_marketplace ON + service zip ∈ Boston set

⟶

BUY FLOW

instant_marketplace ON + any non-Boston zip

⟶

BID FLOW — untouched

instant_marketplace OFF (kill switch)

⟶

BID FLOW everywhere — byte-identical

CThe data model — bounded context vs legacy Jobs

Field-level source of truth is now migration/ENTITY_MODEL.md (the Entity model tab renders it); the field-remap table there maps every old FIELD_LEDGER.md field to its new entity home. Read the rows below through the new lens: SHARED = the field the ACL translates across the boundary at materialization (owner, type, address, date, the synthesized winningBid) · BID-ONLY = legacy Jobs fields the buy context never touches · BUY-ONLY = fields that now live on the new Booking/DraftQuote aggregates, off the Job entirely (payment{}, assignment{}, market, bookingReference, intake snapshot, payout). The legacy Jobs.status enum is unchanged — the buy state machine is the Booking's own. Zero migrations, zero backfills, no existing field renamed or repurposed.

C-1 · `Jobs` — the three-way split

Field	Class	Written by	Resolution / verified path
Shared — both flows, identical semantics
`userInfo`	SHARED	createJob · bookMarketplaceJob	Owner, always — never `audit.user` (house rule). Every customer-facing query in both flows keys on it (`Job/schemas/job.js`).
`type`	SHARED	both, at creation	'Dumpster Rental' / 'Junk Removal' / 'Recurring Services' — reused unchanged so FeeCalculator, matcher, and `archiveOldJobs` type criteria work on both.
`status`	SHARED ENUM	partitioned by value	One enum, values partitioned by writer: `open/pending` written only by bid+IR code; `booked` (NEW, D1) written only by buy code; `active/completed/cancelled` shared terminal-pipeline values. `Job/helpers/status.js` gains `BOOKED` + `isBooked()`; no `booked` exists there today (verified).
`serviceAddress{street,city,state,zipCode,apartment,building}`	SHARED	both	Reused as-is. Tax keys on service state in both flows (`Invoicing/utils/taxes.js`); buy gate keys on service zip.
`date` / `deliverDate` / `dateServiceStart`	SHARED	both	Canonical service-date precedence (existing InstantRate pattern). Buy flow's balance/refund timers derive from it.
`geocode`	SHARED	both	Migration-25 shape, 2dsphere. Buy captures via server-side `resolveAddress` (attempted-but-optional in v0).
`images[][]`	SHARED	both	Via existing `jobs.addImage` (`Job/methods/jobs.js:344`) + FileService in both flows.
`winnerBidID` / `winningBid`	SHARED	scheduleJob · accept-synthesis	The hinge. Bid: real bid object embedded at award. Buy: synthesized from the priced card at accept, `winningBid.audit.user` = providerId. Downstream (complete / invoicing / chat / hauler-list won-clause) cannot tell them apart — by design.
`closureDate`	SHARED	complete · cancel (both flows)	Stamped by the unchanged `jobs.complete` (`jobs.js:484`); buy's `cancel.ts` stamps it exactly as `jobs.cancel` does (`jobs.js:425`) so archival works (collision #6).
`archived` / `archivedAt`, `audit{}`, `cancellationReason`	SHARED	crons · hooks · cancel paths	Audit/data-integrity substrate identical in both flows; `archiveOldJobs` flags terminal jobs from either origin.
`projectLength`, `size`, `materials[]`, `truckLoads`	SHARED	both	DR/JR legacy intake fields — buy still writes them for downstream display compatibility (FIELD_LEDGER §1).
Bid-only — buy flow never writes, never reads
`bids[]`	BID-ONLY	createBid/updateBid	Booked jobs never enter the bid pipeline, so `bids[]` is simply absent — which is precisely what keeps them invisible to `jobs.hauler.list` (keyed on `'bids.audit.user'`, `publications.js:650`).
`instantRate{matched[], requests[], haulerBlackList[]}`	BID-ONLY	createJob · IR methods	`matched[]` is populated by `createJob()` at posting; buy jobs never run `createJob`, so the whole sub-doc is absent. The buy flow uses the same matcher but stores results on the DraftQuote, never on the Job.
`paymentType` (STRIPE \| INVOICE) + `invoice`	BID-ONLY	scheduleJob (`bidding/server/index.js:564-574`)	The award-time payment discriminator, incl. the INVOICE no-card path (`jobs.bidAndSchedule`, `jobs.js:299`; IR INVOICE branches `instantRates.js:408`). Buy money never uses it — all buy money lives in `payment{}` with Stripe-only PIs. Decided: `bookMarketplaceJob` does not set `paymentType`; any code branching on it sees `undefined` and takes no bid-path action.
`jobExpired`	BID-ONLY	`expireJobs` cron	Only ever set by the expiry cron, whose query can never match a buy job (collision #5). No buy code reads it.
`campaignId`	BID-ONLY	createJob (campaign attribution)	ADV-campaign attribution at posting; buy jobs carry none. Fee-discount lookups (`getJobFeeDiscountAsync`) are not in the buy pricer anyway (locked 10% margin).
Buy-only — all NEW, additive-optional, invisible to bid code
`market: 'boston'`	BUY-ONLY	bookMarketplaceJob (D1)	The kill-query + reporting tag. `Jobs.find({market:'boston'})` lists every pilot job in one query; absent on every bid job ever created.
`bookingReference`	BUY-ONLY	bookMarketplaceJob (D1)	`WP-BOS-NNNN`, market-prefixed counter, written once at materialization (E5 resolved). No `jobNumber` exists anywhere today (verified).
`marketplaceIntake{}`	BUY-ONLY	bookMarketplaceJob (D1)	Copy of the canonical intake at materialization (incl. surcharge counts, windows) so providers/ops can sanity-check inferred size.
`payment{deposit, balance, fullyPaidAt, refundPolicyCliffAt, termsAcceptedAt/Version, lastError, lineItems[]}`	BUY-ONLY	payment.ts (D2) · webhooks · FutureTasks	All integer cents. The buy flow's entire money state; the bid flow's money state stays in `paymentType`/`invoice`/PaymentsHistory exactly as today. The two never mix on one job because a job belongs to exactly one flow.
`assignment{providerId, stage, offeredAt, roundRobinPool[], history[]}`	BUY-ONLY	booking.ts seed (D1) · ladder.ts (D3)	Ladder state machine; `history[]` gains optional `reason` (E14). The key of the new provider publication — the structural counterpart of `bids[]`.
payout snapshot (chosen card)	BUY-ONLY	bookMarketplaceJob (D1)	Provider payout frozen at booking — never the customer price; later rate edits can't move an existing job's payout.

Partition law: a Job carries bids[] xor assignment{} — never both, enforced by construction (only createBid writes one, only buy code writes the other, and no job is ever handed between flows). Every "which world is this job from?" question is answered by market presence, with isMarketplaceJob() (bostonGate.ts) as the single helper.

C-2 · `DraftQuotes` — buy-only, pre-job, transient

Field	Class	Written by	Notes
`intake{}` (canonical payload)	BUY-ONLY	`marketplace.createDraftQuote`	Validates against `shared/schemas/domains/marketplace/v0/intake.ts`; shapes deliberately mirror Jobs fields so materialization is a copy, not a transform.
`pricedCards[]` · `selectedCard{}`	BUY-ONLY	draft service · `marketplace.selectCard`	Per-provider payout + 10% margin + customer price. Lives here, never on the Job until the chosen card is copied at materialization.
`contact{}` (PII) · `expiresAt` + TTL	BUY-ONLY	`marketplace.saveDraftContact`	7-day TTL on un-booked drafts (B9) — PII minimization; `expiresAt` (price lock) is distinct from the TTL delete date.

Why this can't collide with bidding: it is a separate collection that no bid-flow code imports, and the bidding matcher only ever reads InstantRate* + Jobs{status:'open'} (BACKEND_STRATEGY §2.5). A DraftQuote is not a Job; nothing in dashboards, crons, publications, or events knows it exists.

C-3 · `InstantRate` collections — shared matcher, shared rates, additive new columns

Field group	Class	Read by	Notes
Matcher criteria — `type`, `zipArray`, `active`, `deleted` (+ DR `containerSize`)	SHARED	both flows via `findMatchingInstantRates` (`instantRateMatcher.js:23`)	One matcher serves the IR quote path (bid world) and the draft-quote pricer (buy world). Criteria unchanged — additive fields don't alter matching.
Existing rate fields — DR `containerSize, amountHaul, tonsIncluded, overagePerTon, additionalFees.{deliveryFee,dryRunFee}`; JR `halfTruckLoad, truckLoads`	SHARED	both	Payout-first storage (Migration 27) in both worlds. Bid world converts via plan-based `FeeCalculator('bid')`; buy world via the 10% Settings margin — same inputs, different (deliberate, B1-locked) fee fn.
NEW rate fields — `rentalTerms{}`, `rush{}`, `travel{}`, `additionalFees.swapFee`, JR `perCubicYardCents/minJobCents/stairsCarryCents`	BUY-ONLY	buy pricer only (D5 seed)	Additive — the bid flow ignores them. The IR quote/booking path never reads these keys, so a provider's rate row safely serves both worlds. Buy matcher prefers per-cu-yd JR when present; legacy truck tiers stay for non-Boston.
Rate editing — `instantRates.add/update/delete` (`InstantRate/methods/instantRates.js:49/:117/:205`)	SHARED	provider, one pricing UI	One rate source by design: an edit moves pricing inputs for both worlds (collision #17). New fields need schema+validation extension only.

C-4 · `Meteor.users` — one account serves both flows

Field group	Class	Used by	Notes
`emails[0].address`, `profile.firstName/lastName/phoneNumber/mobileNumber`	SHARED	both	Passwordless auth (`docs/PASSWORDLESS_AUTH.md`) is flow-agnostic. Contact-gate email is the account email (E1) — one user record regardless of which flow created it.
`profile.companyName/aboutUs/image`, `profile.zipArray`, `profile.receiveQuotes/smsOptOut`	SHARED	both	Provider identity, matcher gate, and notification preferences — one set, both worlds. Preference filtering applies to MARKETPLACE_* events through the same Notifier.
`connect{}`, `stripeCustomerId`, `taxExempt`	SHARED	both	One Stripe customer per (parent) account; deposit/balance PIs and bid-award charges hit the same customer object. Parent resolution identical (collision #9).
`profile.marketplace{rating, reviewCount, yearsInBusiness, testimonials[], photos[], active}`	BUY-ONLY	buy cards/profile · ops-set only (D5)	Verified absent from `User/schemas/user.js` today; additive. `marketplace.active` doubles as the in-market/FOMO-audience flag. Bid world never reads it.

C-5 · `PaymentsHistory` — one shared ledger, new event types

Both flows log every money operation to the same PaymentsHistory collection (Payment/collections/paymentsHistory.js, PaymentHistoryService.js) with the same correlationId (uuidv5 of jobId, process.js:75-85) — which is also the base for the buy flow's deterministic Stripe idempotency keys (${jobId}:deposit / :balance / :refund:${n}). The buy flow only adds PAYMENT_EVENTS enum values (deposit, balance, refund, dispute, webhook outcomes); existing bid-flow entries are untouched, and the market tag on the job partitions reporting (collision #12). One ledger, two event vocabularies, zero ambiguity.

DCollision issues — solved

Every place the two journeys could touch, with the decided resolution and where it lands. These are commitments, not options. 17 collisions, 17 resolutions.

#	Collision	Resolution — decided	Where
1	Same customer, jobs in both modelsOne dashboard must show an open bid job and a booked buy job side by side.	SOLVEDDashboard is a union by construction — `jobs.customer.dashboard` already queries on `userInfo` only; its status whitelist (`publications.js:272-310`) gains `booked` in `allStatus` + a `booked` switch case. Ordering and `isExpired` ignore `booked`. Marketplace customers land on the tracking page post-sign-in; the legacy dashboard simply also shows their booked jobs.	E21D1 · P3/C3
2	One email / one account across flowsThe buy checkout creates users; the same person may already exist from the bid world.	SOLVEDThe passwordless user is flow-agnostic — contact-gate email is the account email; booking runs `users.create` (`User/methods/create.js`, server-side, abuse-limited) and an existing-email collision links to the existing account at checkout (not at the gate), then mints a passwordless login token. No second account, no password, ever.	E1D1 · M25 glue
3	Notification stream separationA booked job leaking `JOB_POSTED` would blast every Boston hauler with a job that isn't biddable.	SOLVEDTwo guarantees: (a) an explicit guard in `booking.ts` — booked jobs never emit `JOB_POSTED` (the Oscar suppression discipline, B3-E19); (b) bid events are structurally impossible for booked jobs — `JOB_BID_PLACED` fires only from `createBid`, `JOB_EXPIRED` only from `expireJobs`, and booked jobs reach neither. Buy notifications are a disjoint `MARKETPLACE_*` vocabulary through the same Notifier + preference filtering.	D1 · E19 guardD2/D3 events
4	Hauler sees both worlds`jobs.hauler.list` can't see bid-less booked jobs; a naive fix risks double-offering one job in two UIs.	SOLVEDTwo publications, disjoint keys, no overlap by construction: legacy `jobs.hauler.list` keys on `'bids.audit.user'` (`publications.js:636,650`) — blind to booked jobs; new `jobs.provider.marketplace` keys on `assignment.providerId` (+ in-market audience at `stage:'fomo_blast'`), PII-minimal pre-accept. Since a job has `bids[]` xor `assignment{}`, no job can appear as both an open bid opportunity and a marketplace offer. Post-accept, the synthesized `winningBid.audit.user` makes the job appear in the legacy list's won-clause (`:525`) — correct, it's now their job. Never synthesize placeholder bids.	E2D3 · P2
5	Expiry cron vs booked jobs`expireJobs` cancels stale jobs; a booked job waiting on the ladder must not be "expired."	SOLVEDVerified — no patch needed: the query is `status ∈ {open, active}` + `winningBid: {$exists:false}` (`expireJobs.js:62-73`). `booked` never matches on status; an active buy job always carries the synthesized `winningBid`, so the second clause excludes it too. `noBidsReport` only counts open jobs — also clean. D1 acceptance test proves it.	F7 verifyD1 accept
6	Archival of buy-origin terminals`archiveOldJobs` requires `closureDate: {$exists:true}` — a buy cancel that forgot to stamp it would pin jobs in the active dataset forever.	SOLVED`archiveOldJobs` keys on `type + status + closureDate` only (`archiveOldJobs.js:74-120`) — origin-blind, handles completed/cancelled from either flow. Completion already stamps `closureDate` (unchanged `jobs.complete`, `jobs.js:484`); the buy `cancel.ts` stamps it exactly as `jobs.cancel` does (`jobs.js:425`). No archival change required.	D4 · M6WIRE verify
7	Refunds exist only in buyTiered refunds are net-new; could a refund path leak into bid jobs?	SOLVEDZero refund code exists platform-wide today (verified) — so the bid flow's behavior is unchanged by definition. `refund.ts` + `cancel.ts` are guarded by `isMarketplaceJob()`; `stripe.refunds.create` is only ever invoked against `payment{}` PIs, which only buy jobs have. Bid cancellations remain refund-free exactly as today.	D4 · M6/X4RG #2
8	Chat timing differs per flowBid world chats pre-award (per-hauler threads on open jobs); buy world must not let customers message a provider who hasn't accepted.	SOLVEDServer auth is already correct for both: owner / thread-hauler / `job:assigned` (`Chat/methods.js:175-191`). Bid flow keeps pre-award threads untouched. Buy flow hides the Message button until `assignment.stage='accepted'` (E18); post-accept, the provider is the thread hauler and the existing auth passes unchanged — one chat system, two reveal policies, zero server forks.	E18D3+ WIRE · M30
9	Org / parent billingChild accounts can't pay; both flows must resolve the same billing identity.	SOLVEDIdentical resolution in both flows: `getParentUserId(userId) \|\| userId` before any Stripe customer/charge decision (house rule, BACKEND_STRATEGY §0.6; precedent `Payment/methods/billingPortal.js:40-41`). Buy materialization sets `userInfo` = billing user exactly as `createJob` does, so org dashboards, child assignment, and chat org-checks behave identically for booked jobs.	D1/D2M4/M5
10	Pre-existing open bid jobs when the flag flipsA Boston customer has live `open` jobs in the auction the day buy launches.	SOLVEDLeave them running to their terminal state — no migration, no re-route, no cancellation. Bidding stays byte-untouched, existing bids/awards/notifications complete normally. Only new intake routes to buy. The customer's dashboard shows both (collision #1). A job belongs to the flow that created it, forever.	Policy · D0/D1
11	Zip moves mid-draftCustomer edits the service address on draft re-hydration to a non-Boston zip after cards were priced.	SOLVEDDecided rule (Kado, 2026-06-10): the gate re-runs on every draft mutation, and an address change invalidates `pricedCards[]` (state-C skeleton — never a stale price). Routing by the resulting zip set: (1) single Boston zip → stays in the BUY flow — matcher re-runs, cards re-price at the new zip; (2) single non-Boston zip → graceful hand-off to the legacy BID intake carrying the entered fields (redirect matrix, Boston-routing tab); (3) more than one service zip in the same quote (any mix) → no self-checkout — push to call-for-pricing on the Boston DID; inside sales prices it live (the multi-location / coordinator pattern, page 22). `bookMarketplaceJob()` re-asserts `isBostonZip(serviceZip)` as the last line of defense, so no booked job can exist outside the gate.	D1 · M3/M13
12	Metrics / reporting separationPilot numbers (conversion, refund rate) must not pollute legacy marketplace reporting, and vice versa.	SOLVEDEvery buy job carries `market:'boston'` (D1 acceptance: `Jobs.find({market:'boston'})` returns it); no bid job has the field. Legacy reports change zero. Pilot metrics (booked-conversion, ladder depth, balance success %, refund/dispute rate) read PaymentsHistory + the market tag with BetterStack correlation IDs.	D1 · C4D5 metrics
13	Ops unassign on an accepted jobOps console shows unassign; `active → booked` exists in no machine, and money may have moved.	SOLVEDAdmin-only whitelist entry (E3): `active → booked` via `Marketplace/methods/opsAssignment.ts` (`admin:base`) — tears down `winningBid`/`winnerBidID`, appends `assignment.history` audit, re-arms the ladder, applies the strike in the same call (E16, no drift). Hard-blocked once `payment.balanceCapturedAt` is set — at that point route through the D4 refund tooling instead. Impossible in the bid flow: no un-award transition is added there.	E3D3 · M8
14	Two fee models on one platformBid/IR uses plan-based FeeCalculator (DR flat 15%, $20 min, plan discounts); buy is locked at 10% calculated margin.	SOLVEDDeliberate divergence, locked (B1, 2026-06-10): the buy pricer uses `MARKETPLACE.MARGIN_PCT` from Settings — never `payoutToCustomerPrice`/`FeeCalculator` — scoped entirely inside the draft-quote pricer. FeeCalculator is untouched, so every bid and IR quote outside Boston prices exactly as today. Canonical: $444 payout → $44.40 fee → $488.40.	B1 lockedD1 pricer
15	Provider plan perks (priority placement)Growth+ haulers get `isPriority` placement in IR quotes; Boston cards must rank on price alone.	SOLVEDBoth worlds keep their own sort: bid/IR priority placement persists untouched; Boston results sort pure price ascending with `isPriority` suppressed (S10; `instantRatesCore.js:21,:33,:447,:504,:563`). Providers lose nothing in the bid world; the buy world is plan-blind by spec.	S10D5 sort
16	Boston RS demand has no buy pathv0 buy is DR/JR only; the landing's Recurring card must not dump RS jobs into the auction.	SOLVEDThin lead path (B6): the landing RS card writes a `marketplaceLeads` record + Slack alert. Explicitly rejected: `listings.createRS`/`listings.createForNewUser` (`gateway.js:105`, `invertedFlow.js:104`) — the guest path creates an `open` Job and emits `JOB_POSTED` into bidding, which Boston demand must never do. RS pages 17–22 stay deferred.	B6page-11 build · M21
17	One rate row feeds two pricing enginesA Boston provider's `InstantRate` row is read by both the IR quote path and the buy pricer.	SOLVEDBy design — one rate source, additive columns. Legacy fields price both worlds (through their respective fee fns); NEW fields (`rush{}`, `travel{}`, `rentalTerms{}`, per-cu-yd JR) are read only by the buy pricer and ignored by every bid/IR code path. The buy job's payout snapshot (C-1) freezes the price at booking, so a later rate edit moves future quotes in both worlds but never an existing job.	D5 · C11/C12S11 seed

EInvariants — what keeps coexistence safe

If any one of these breaks, the isolation story breaks. Each is enforced structurally (by construction or by guard), not by convention.

Born booked, never open. A buy Job is created directly in booked by bookMarketplaceJob() and never passes through scheduleJob (which hard-asserts open) — so the bidding matcher, every open-status publication, and JOB_POSTED fan-out can never see it. No transition connects booked to open or pending in either direction.
One terminal pipeline. active → completed/cancelled is the same code for both flows, hinged on the synthesized winningBid/winnerBidID. No forked completion, invoicing, chat-auth, or archival logic — ever.
Additive-only fields. No existing field is renamed, repurposed, or removed; every NEW field is optional. Zero migrations, zero backfills, and bid-flow code cannot break on a field it never reads.
Flag + zip gate, fail-loud. Buy entry requires instant_marketplace ON and a Boston service zip, re-asserted at materialization. Flag OFF = byte-identical legacy platform (the kill switch); gate failure halts and diverts loudly, never silently re-routes.
Platform holds funds. No destination charges in either flow (verified — transfer_data absent from the job-payment path); buy deposits/balances charge the platform account, provider payouts are manual-ops ledger entries for the pilot. Money separation between flows is therefore bookkeeping on one ledger, not Stripe topology.
A job belongs to exactly one flow, forever. bids[] xor assignment{}; market tag present xor absent; no in-flight migration in either direction, including at flag-flip.
Idempotent money, one ledger. Every buy Stripe call carries a deterministic idempotency key derived from the shared correlationId base, and both flows log to PaymentsHistory — replaying any timer cannot double-charge, and reconciliation reads one audit trail.

FDecision summary

Coexistence is solved by construction, not coordination: the two flows share a collection but partition it — disjoint status values pre-terminal, disjoint sub-docs (bids[] xor assignment{}), disjoint event vocabularies, disjoint publications keyed on those sub-docs.
The bid flow is byte-untouched. Three small flag-gated edits to existing files (status enum value, FutureTasks taskType dispatch, webhook switch) — none change bid-path behavior; flag OFF is provably identical.
The hinge is the synthesized winningBid at accept — it buys one terminal pipeline (complete, invoice, chat, hauler-list, archival) for the cost of one well-formed object copied from the priced card.
Routing is a two-input gate with a kill switch: flag ON + Boston service zip ⇒ buy; everything else ⇒ bid; flag OFF ⇒ all bid. Re-asserted at booking; never silent.
The data model is additive-only and migration-free: every buy field is NEW-optional on Jobs/users/InstantRate or lives in genuinely new collections (DraftQuotes, leads, strikes); the rate rows serve both worlds with the bid flow ignoring the new columns.
All 17 identified collisions have decided resolutions — including the four open questions folded in: dashboards union with booked filters (E21), one passwordless account across flows (E1), admin-only unassign reversal with a balance-captured hard-block (E3), and the RS thin-lead path that never touches bidding (B6).
Crons need zero patches — verified: expireJobs can't match booked or synthesized-winner jobs; archiveOldJobs is origin-blind given the closureDate stamp both flows write.
Money stays reviewable: refunds exist only in buy (bid unchanged by definition), both flows write one PaymentsHistory ledger under one correlation scheme, and the 10%-margin fee contract is locked in Settings — the single deliberate divergence from the plan-based FeeCalculator.