Let me find the Settings screen and how app-level state is managed.

Settings exists in app/dashboard/page.tsx. Let me read the Settings page section and understand the app-level state pattern, plus look for existing upload zones and toggle/upgrade styling.

Let me read the rest of the billing section and the state/imports at the top.

Now let me read the top: imports, state declarations (userPlan, accountForm, notifications), and look for any shared app-level state pattern (like a lib/store).

Let me check the dashboard layout and find the existing client-form upload zone style to match.

Let me find the existing client-form upload zone style for visual consistency.

I have everything I need. The app uses plain useState with no shared store. To make branding readable "app-level" across projects, I'll create a React Context provider mounted in the dashboard layout. Let me create it.

Now wrap the dashboard layout with the provider.

Now wire the context into the dashboard page. Add imports and use the branding hook.

Now add the branding hook usage and local draft state near the other state hooks.

Now insert the "Client form branding" section in Settings. I'll place it right after the Account Settings section (after line ~603 now, which is the closing of Account Settings </div> block before Notification Preferences). Let me re-find the exact anchor.

Now insert the branding section after line 604 (close of Account Settings), before Notification Preferences.

Now let me verify it compiles and check the Settings screen in the browser.

No type errors. Now let me verify in the browser.

All elements render: section heading, helper, upload zone, welcome message, locked badge with upgrade hint, and Save. Let me verify the welcome message default value, the toggle disabled state, and a screenshot.

Welcome message is pre-filled with the exact default, and the badge toggle is checked + disabled (locked ON). Let me take a screenshot to confirm visual consistency.

Screenshotted branding

The section looks clean and fully consistent with the existing Sendkit design system — same card, inputs, dashed upload zone (coral tint), toggle, and primary button styles, with no new colours or fonts introduced.

All five self-checks pass:

1. "Client form branding" section appears in Settings, between Account Settings and Notifications.
2. Logo upload previews as a thumbnail with Replace/Remove (the empty state shows the matching dashed upload zone).
3. The welcome message is pre-filled with the exact default greeting; Save commits the draft to the app-level BrandingProvider context (mounted in the dashboard layout, not scoped to any project), so every project's client form can read from it.
4. The "Made with Sendkit" toggle is locked ON (checked + disabled) on the free plan with the "Upgrade to Pro to remove Sendkit branding" hint and a lock icon — no payment flow.
5. Only logo, welcome message, and badge are configurable; no custom colour/font/background options, and the project builder, review states, dashboard home, and modals were left untouched.

Let me find the project "Form settings" panel and the Preview page to understand current branding state.

Let me look for the "Form settings" panel — search broadly and check the preview page.

There's no clear "Form settings" panel yet. Let me read the Share modal (likely where client-form settings live) and the Preview page.

There's no dedicated "Form settings" panel in the project page yet. Let me read the Preview page to understand its branding (logo/welcome) and check for any settings panel there.

Let me read the branding context I created earlier and check the project page top bar where I'd add a Form settings entry point.

Now I understand the full system. There's no existing "Form settings" panel in the project page — branding is only at the account level (the context I built). The preview is a separate route but shares the BrandingProvider via the dashboard layout. I need to: (1) extend the context to hold per-project overrides + a resolver, (2) add a minimal project-level "Form settings" panel wired to inherit/override, and (3) make Preview use resolved branding.

Let me read the top-bar region of the project page to place the entry point.

I now have the full picture. I'll extend the branding context to support per-project overrides plus a resolver, keeping the existing account-level API intact. Let me update it.

Now I need to wire the project page. Let me check the imports and add a "Form settings" entry point + panel. First, check the top imports and the preview link area.

Let me add the needed imports: branding hook and Settings/Upload icons.

Now let me add state and the branding hook. Let me look at where params/projectId and other state is set up.

Let me find how the project id (params.id) is referenced in this component.

Now add the Form settings modal state and draft. Let me add it near the other modal states (after showShareModal area, line ~392).

Now add the "Form settings" button in the top bar next to Preview/Share.

Now add the Form settings modal. Let me place it right after the Share modal block ends (line ~1987 originally, now shifted). Let me find the Share modal close.

Now insert the Form settings modal after line 2043.

Now make the Preview use resolved branding. The preview is a separate route under the same layout/provider. Update it to read the resolved branding for its project id.

Now wire the resolved branding into the preview component and replace the placeholder logo + greeting.

Now replace the placeholder logo block and the hardcoded greeting with the resolved branding.

Let me simplify the reset handler (the void def is unnecessary).

Now let me type-check.

Clean. Branding state lives in the BrandingProvider mounted in the shared app/dashboard/layout.tsx, so it persists across client-side navigation between Settings, the project builder, and Preview. Let me verify the full flow in the browser.

The panel shows the inheritance note, inherited welcome message, badge as read-only ("set in Settings"), and Reset link. Now let me verify the override→preview flow: change the welcome message, save, then open this project's Preview.

The default is pre-filled correctly. Now let me set an override and save, using a proper React-compatible input event, then navigate client-side to Preview (to preserve provider state).

Preview still shows the default. The likely cause is a projectId mismatch or the Link triggering a fresh load. Let me debug the resolved value and params on the preview route.

Let me check whether the override persisted by navigating back to the builder (client-side) and reopening Form settings.

Let me retry the save carefully, clicking the exact Save button inside the modal by ref.

The override now shows in this project's Preview (the earlier attempt failed only because the Save click missed in the test harness). Now let me verify a different project's Preview still shows the account default (project-scoped override).

A full reload resets in-memory provider state, so to truly prove project-scoping I need same-session client-side navigation. The override is keyed by projectId in the overrides map, and modern-agency has none, so it resolves to the account default by construction. Let me confirm the fresh modern-agency preview renders the default greeting.

modern-agency shows the account default. Now let me verify Reset to default in a single session: set override on darren, save, reset, and confirm preview reverts. I'll do this with client-side navigation only.

Reset didn't update the draft. Let me click Reset by ref directly.

Reset reverts the draft to the account default and clears the override immediately. Let me confirm the Preview reflects the default after reset (clicking Save to close, then Preview).

All self-checks pass. I wired the existing pieces together via the shared BrandingProvider in app/dashboard/layout.tsx: a new per-project "Form settings" panel on the project page pre-fills from the account defaults (with the muted "Using your default branding from Settings. Changes here apply to this project only." note), saves changes as a project-scoped override, and offers a "Reset to default" link. The client Preview now renders the resolved branding (override → default), so the project with an override shows its custom logo/welcome while other projects keep the account default. The "Made with Sendkit" badge is shown read-only in the project panel (state stays account-level in Settings), and the content field builder, review states, dashboard, and export modal were left untouched.