**Pairs with #23344** (`twenty-partners` v1.4.1), which adds the
`referredByPartner` relation and the Discord notification. This PR is
the sender; that one is the receiver.
**Merge #23344 first.** Its schema is a non-strict `z.object`, so an
unknown `partnerSlug` is stripped rather than rejected — shipping this
one first degrades silently (attribution dropped) rather than breaking,
but there is no reason to. Until #23344 is deployed, this field goes
nowhere.
No dependency in the other direction and no shared files: #23344 is
entirely inside `packages/twenty-apps`, this is entirely inside
`packages/twenty-website`.
## What this does
A visitor can reach the client brief form from two places: the
marketplace listing page, or a specific partner's profile. Until now
both produced an identical payload, so the partner whose page drove the
lead was lost.
This sends the partner's slug along with the brief when the form was
opened from a profile page. #23344 resolves it to a Partner record and
links it to the created Opportunity.
## How it flows
`PartnerProfileCtas` links to `/partners/brief?partner=<slug>` →
`page.tsx` reads and normalizes the param → prop threaded through
`ClientBriefPageContent` → `ClientBriefWizard` →
`buildClientBriefRequestBody`.
The slug is inert context, never a form field, so the wizard reducer and
`ClientBriefState` are untouched.
The three CTAs on `/partners/list` (`MarketplaceHeader`,
`MarketplaceMatchCard`, `MarketplaceBriefPrompt`) stay bare — a brief
from the listing page has no referring partner, and the notification
labels it "Marketplace listing".
## Why `normalizePartnerSlug` exists
`clientBriefRequestSchema` is a `z.strictObject`. Forwarding a malformed
`?partner=` value straight into the body would fail validation for the
**entire request** and lose the brief — a bad trade for an attribution
field the visitor never saw.
So the param is normalized at the boundary: array-valued params take the
first entry, and anything not matching `[a-z0-9-]{1,100}` is dropped to
`undefined` rather than passed on. The charset mirrors the app's
`slugify` helper, which is what produced the slugs in the first place.
## Testing
8 new cases — 6 for the normalizer (well-formed, absent, empty, bad
charset, over-long, repeated param) and 2 for the schema. Suite: 456
passing, up exactly 8 from a 448 baseline. `oxlint` and `oxfmt --check`
clean; `next build` compiles with no type errors.
Verified in a browser rather than asserted: opening a partner profile,
clicking "Submit a brief", and completing the wizard produces
```json
{"firstName":"Jane","lastName":"","email":"…","companyName":"NetZero Test Co","need":"…","partnerSlug":"netzero-systems"}
```
on `POST /api/client-brief` → 200. `LocalizedLink` preserves the query
string across locale prefixing (`localize-href.test.ts:20` already
covers this; confirmed live on the FR route).
## Deliberately not included
- **CTA-level attribution.** Which of the three listing-page CTAs was
used is not tracked. That is click analytics, a different concern from
partner attribution.
- **Length bounds on the other brief fields.** `country`, `seatCount`,
`timeline`, `budgetRange` and `companyName` remain unbounded, as they
were before this PR. Worth tightening, but pre-existing and out of scope
here.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/23351?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
Rashad Karanouh
7fe59bf42d
