Project Planner Client Onboarding

Project Planner Client Onboarding

Last Updated: 2026-07-31
Version: 1.0
System: Shared Tekton Project Planner engine

What

This SOP covers client onboarding into Tekton’s shared Project Planner, estimator, configurator, or pricing-planner engine. It starts when a teammate expresses the intent to create or prepare a planner for a client and ends when an isolated testing-mode preview is verified and handed to the operator.

The trigger is intent, not an exact phrase. Teammates do not need to remember a command or copy a template. Requests such as these all activate the same workflow:

• Set up a Project Planner for Smith Outdoor Living.
• Get ABC's planner ready. The pricing is in this Sheet.
• Build the estimator for the new client.
• Do the same project builder setup for Jones Landscaping.
• Can you get their pricing tool ready for my test?
• A similar request inside a client-specific Discord thread where the client is already clear.

If project planner could mean ordinary project management instead of Tekton’s homeowner estimator, review the active thread and client records first. Ask one narrow clarification only if the intent remains genuinely ambiguous.

The engine is never copied or forked for one client. Clients are added through data-only configuration, services and pricing catalogs, themes, assets, routing, isolated infrastructure, and deployment settings.

Testing readiness does not authorize live installation, production recipients, DNS changes, client-facing email, indexing changes, or production delivery.

Who owns it

Primary owner: AI Operations

AI Operations, currently Clawton, owns the complete workflow from discovery through testing handoff.

The requesting operator supplies only:

1. Client name.
2. Approved services and prices, or the approved source containing them.
3. The Resend API key installed as RESEND_API_KEY in the exact Cloudflare Worker secret location AI Operations identifies after creating the testing Worker.
4. Any WhatConverts access AI Operations cannot retrieve from approved Tekton systems.

AI Operations owns everything else:

• resolving the correct client website and identity;
• researching TaskTracker, Drive, Gmail, GHL, WhatConverts, Cloudflare, GitHub, and public client sources;
• extracting branding, fonts, colors, logos, favicon, photography, voice, and layout patterns;
• acquiring and optimizing approved public assets;
• configuring the client, catalog, theme, emails, routes, tests, and assets;
• provisioning isolated preview infrastructure;
• configuring all secrets except the Resend API key the operator installs;
• configuring Resend and WhatConverts;
• running automated and live QA;
• reconciling provider delivery;
• preparing the test handoff;
• updating the client work log and relevant TaskTracker records after verified completion.

Do not ask the operator for website URLs, colors, fonts, logos, screenshots, design direction, infrastructure choices, recipient setup, webhook setup, or records that can be retrieved safely.

Escalate only when:

• multiple client identities or websites remain plausible after research;
• services or prices conflict or are materially ambiguous;
• an unretrievable business/legal fact changes customer-facing meaning;
• the Resend API key has not been installed in the identified Worker;
• required WhatConverts access is unavailable.

Never infer prices from a public website. Use only the supplied approved information or source. If approved pricing does not exist, use consultation mode only when appropriate and disclose that assumption.

Steps

1. Recognize the request and resolve context

1. Treat semantically similar planner, estimator, configurator, project-builder, or pricing-tool requests as the trigger.
2. Resolve the teammate and active client from the Discord thread, TaskTracker, and Tekton records.
3. Search approved systems before asking for anything beyond the four allowed operator inputs.
4. Create a source-lock record containing the verified client identity, website/origins, stable client ID, source dates, known contacts, asset sources, and WhatConverts profile status.
5. Confirm that the approved service and pricing data is internally consistent. Flag conflicting prices, duplicate services, unsupported ranges, and unclear estimate rules.

2. Extract the client brand

1. Crawl the verified public website and inspect loaded CSS, stylesheets, font files, images, and metadata.
2. Record repeated colors, heading/body/button fonts, logo and favicon variants, hero and service photography, spacing, radii, shadows, cards, buttons, responsive behavior, service labels, estimate language, and voice.
3. Confirm fonts from actual stylesheets or files instead of visual guessing.
4. Download only approved public client assets, optimize local copies, and preserve source URLs.
5. Create semantic design tokens and email-safe PNG/JPEG imagery.
6. Verify contrast, mobile readability, asset ownership/source, and client isolation.

3. Configure the shared engine

1. Start a scoped branch from a clean origin/main in Tektongrowth/tekton-project-planner.
2. Add src/clients/<client-id>/config.ts as data only.
3. Add one client manifest entry and keep assets inside the client’s namespace.
4. Configure identity, services, pricing modes, planner copy, disclaimer, required fields, UI theme, email theme, alt text, storage key, and build identity.
5. Add client-specific automated and browser acceptance coverage.
6. Add the new acceptance command to verify:all and CI.
7. Reject any other client’s names, recipients, assets, routes, or metadata.

4. Provision isolated testing infrastructure

Each client receives its own nonproduction:

• preview Worker;
• D1 database and migrations;
• Turnstile configuration with exact hostnames;
• origin, CSP, CORS, and route maps;
• preview URL;
• Resend endpoint and signed webhook;
• alerting and monitoring;
• encrypted secrets.

Never reuse Authentic Homescapes production resources or another client’s preview wrapper. Inspect the current code for pilot-specific recipients, routes, credentials, Wrangler environments, deploy scripts, and attribution assumptions. Generalize and test those paths rather than bypassing them.

Testing behavior must be server-owned and fail closed to:

ENVIRONMENT=preview
DELIVERY_MODE=internal_test
BUSINESS_TEST_RECIPIENT=info@tektongrowth.com
CUSTOMER_NOTIFICATIONS_ENABLED=disabled
PRODUCTION_DELIVERY_AUTHORIZATION=not_authorized

Equivalent implementation names are acceptable, but browser configuration may never control recipients or delivery mode.

5. Configure Resend

1. Verify the intended sender domain live in Resend. Documentation is not proof of current verification.
2. Create and identify the exact testing Worker.
3. Give the operator only the Worker name and exact Cloudflare secret location where RESEND_API_KEY must be installed.
4. Verify the secret exists without printing its value.
5. Configure RESEND_WEBHOOK_SECRET, sender identity, endpoint, signed webhook, routes, and test recipient.
6. Route all test delivery only to info@tektongrowth.com and keep homeowner/client email disabled.
7. Prove the D1 job existed before provider delivery, Resend accepted the message once, the signed webhook recorded final delivery, retries kept the same idempotency key, and logs exposed no secrets or contact data.

The operator does not configure Resend senders, webhooks, routes, recipients, or other Worker settings.

6. Configure WhatConverts

1. Resolve the exact client account/profile and credential profile from approved systems.
2. Request access only when it cannot be retrieved.
3. Route the planner client ID to the credential profile server-side.
4. Store accepted submissions before creating provider work.
5. Preserve the WhatConverts cookie, original landing URL, current lead URL, trusted parent origin, and planner submission ID for each approved install mode.
6. Audit profile-level emails, workflows, webhooks, CRM routes, and downstream automation before creating a test lead. send_notification=false is not proof that all downstream effects are silent.
7. Prove a rejected submission creates zero provider jobs.
8. Prove an accepted submission creates one durable provider job.
9. Prove request replay creates no second durable job.
10. Treat timeouts, network failures, 5xx responses, and malformed success responses as ambiguous. Reconcile in WhatConverts before any resend.
11. Record the provider lead ID and cleanup/reconciliation status when acceptance is proven.

7. Run automated and live QA

Run at minimum:

npm ci
npx playwright install --with-deps chromium
npm run validate:configs
npm run validate:migrations
npm test
npm run typecheck
npm run lint
npm run build:clients
npm run verify:all

Require a clean diff, scoped pull request, green CI, and exact clean commit. A local suite that CI never invokes is not accepted.

Verify the real preview on desktop and at 390-pixel mobile width:

• real service selection and estimate behavior;
• required-field validation and recovery;
• back navigation and non-PII selection persistence;
• print summary;
• keyboard and accessibility behavior;
• hosted, iframe, and native install modes;
• exact-origin handshake, resize, CSP, CORS, and horizontal overflow;
• D1-first persistence, idempotency, retry, and estimate-tamper rejection;
• Resend routing and signed final delivery;
• WhatConverts routing, attribution, durable-job behavior, and reconciliation;
• no cross-client content, assets, recipients, routes, or network leakage.

8. Hand off for operator testing

Return one concise handoff containing:

• preview URL;
• brand summary;
• services/pricing source and disclosed assumptions;
• confirmation that test delivery is info@tektongrowth.com only;
• Resend proof;
• WhatConverts proof and lead ID if created;
• exact homeowner-style testing instructions;
• known limitations;
• production actions that have not happened.

9. Close operational records

1. Add the completed work to the client work log.
2. Update only relevant TaskTracker tasks or subtasks.
3. Attach the exact commit, preview, QA evidence, Resend result, and WhatConverts result.
4. Keep completed work unarchived unless it is stale, duplicate, or wrong.

10. Keep production separately gated

Production requires separate explicit approval for:

• live-site installation;
• production Worker and D1;
• client business recipients;
• homeowner confirmations;
• production WhatConverts routing;
• DNS or sender-domain changes;
• Turnstile live hostnames;
• production delivery authorization;
• rollback and monitoring ownership.

Ready for my test, looks good, or test approval does not authorize production.

Definition of done

The onboarding is done only when all of the following are true:

• The request was recognized from intent without requiring a memorized phrase.
• Only the four allowed operator inputs were requested.
• Client identity and website were resolved from approved systems.
• Services and prices match the approved source and were not guessed.
• The shared engine remains intact with a data-only client configuration.
• Brand tokens and approved client assets are documented.
• Client-isolated preview infrastructure is active.
• The operator’s only routine Resend action was installing RESEND_API_KEY in the identified Worker secret.
• Test delivery fails closed to info@tektongrowth.com.
• Homeowner and client notifications remain disabled.
• D1 persistence precedes Resend and WhatConverts work.
• Resend acceptance and signed final delivery are proven.
• WhatConverts routing, attribution, idempotency, provider result, and reconciliation are proven.
• Automated tests, browser QA, pull request, and CI pass.
• The exact clean commit and preview URL are recorded.
• The handoff names all production actions that did not happen.
• The client work log and relevant TaskTracker records are current.