How to build an AI newsletter with Lovable.

LOVABLE PLAN-TO-BUILD CONTRACT — ASK, SHOW, WAIT Start in Plan mode. Do not silently implement the whole application from this prompt. 1. Ask one compact product checkpoint covering the primary user, decision or job to improve, successful first-session outcome, initial content scope, and preferred starting experience: Executive Morning Brief (recommended), Editorial Edition, or Analyst Digest. Recommend Executive Morning Brief. Also ask whether the user has a Lovable template, connected design system, brand kit, screenshot, or existing project to reference. 2. Run the Synorb Access Checkpoint below and wait until both MCP and REST validate. 3. Run Synorb discovery, show the Live Scope Receipt, and ask the user to approve or adjust Streams, source channels, filters, and date range. 4. Present three Lovable design directions or the guided typography/palette/layout choices, then show a formal implementation plan covering routes, components, data model, auth/RLS, Edge Functions, design tokens, image plan, acceptance tests, and deployment. Wait for approval so Lovable records the approved plan in .lovable/plan.md before Agent mode begins. 5. Build one end-to-end vertical slice with real Synorb data. Show the preview and ask the user to choose information density, default Brief or Signal view, up to three priority functions, and one of the three image candidates. Apply the choices together. Invite the user to use Visual Edits for final crop, type, color, spacing, and responsive adjustments, then wait for confirmation. 6. Before publish, ask whether this is a private prototype, authenticated team product, embeddable/public experience, or paid product; confirm refresh cadence, roles, delivery channels, analytics, retention, and custom domain. Run the acceptance tests and provide one Build Receipt listing product choices, design tokens, visual choices, exact Streams and filters, date window, routes, secrets present by name only, image provenance status, test results, and deployment URL. SYNORB ACCESS CHECKPOINT — ASK AND WAIT Before any Synorb discovery call or code generation, ask the user to choose: A. "Use my existing Synorb credentials" (recommended when they already have access). B. "Get free Synorb credentials." For A, guide the user to Settings -> Connectors -> Personal connectors and add a custom MCP server named Synorb at https://mcp.synorb.com/mcp with Bearer token or API-key authentication. The user enters SYNORB_MCP_TOKEN only in that protected connector field. Guide them to Cloud -> Secrets for SYNORB_API_KEY and SYNORB_SECRET. Never ask them to paste any secret into chat, generated code, a VITE_ variable, logs, a database row, or a public preview. For B, only after the user explicitly selects it, make exactly one GET request to https://synorb.com/connect from a one-time server-side Lovable Cloud setup action, never from browser code. Parse credentials.mcp_token, credentials.api_key, and credentials.api_secret without printing or logging the response body. Use Lovable's protected connector and secret-entry flow: SYNORB_MCP_TOKEN belongs only in the Synorb Personal connector; SYNORB_API_KEY and SYNORB_SECRET belong only in Cloud Secrets. If Lovable cannot move a returned value into a protected field without displaying it, stop and guide the user to open https://synorb.com/connect directly and enter the values in those protected fields. Do not echo the bundle, persist it in app data, or retry automatically; do not retry automatically after any credential failure. The API secret may be shown only once. After either path, call synorb-profile through MCP and GET https://api.synorb.com/account through a temporary server-side validation function. Report only pass/fail, account name, quota state, and date window. Never report credential values. If either surface fails, stop and ask the user to correct that surface; do not silently continue with only one credential type. PRODUCT TO BUILD Build an AI-assisted newsletter workflow where Synorb supplies the cited source material and the user approves the edition. Include saved sections, edition preview, source receipts, approve/dismiss state, previous-edition comparison, Markdown/HTML email rendering, scheduling, archive, and a test-send flow. Do not auto-send without explicit approval. APP-SPECIFIC LIVE SCOPE Ask the user to choose one primary beat and up to three sections. Discover and confirm exact Streams for every section; do not combine unrelated Streams merely to fill an edition. Use a 7-day current window and a prior 7-day comparison, with mode "count" before the bounded content pull. SYNORB DISCOVERY AND RUNTIME CONTRACT 1. Call synorb-profile once before discovery. Confirm the account, quota state, and allowed date window. This is a zero-quota call. 2. Call synorb-stream-search for the user's requested entities, sources, media, or topic. Use include_details true and an app-appropriate home_domain or media_format. Treat coverage.status "partial" as a paginated inventory result, not proof that no other Streams exist. 3. Select only real customer-visible Streams with positive 17-digit IDs, and keep every Synorb ID as a JSON string end to end. Call synorb-details on the selected IDs and inspect source channels, media formats, source_class, evidence_type, available filters, and recent volume. 4. Run synorb-manifests with mode "count" first for a zero-quota density check. Then pull one bounded build sample with compact true, page_size 5-12, target_count 5-12, the selected stream_ids, and an explicit days or published_date_from / published_date_to window inside synorb-profile limits. Use tag_names, source_channel_names or source_channel_ids, source_class, evidence_type, media_format, ticker, or isin only when the selected product scope requires them. 5. A count or orient response is preflight only. Do not summarize it as an exhaustive result set. Preserve quota_header, coverage.status, required_user_notice, citations, and recommended_next_call from MCP in the build notes. 6. Show the user a Live Scope Receipt containing exact Stream names and IDs, source-channel names and IDs when used, filters, evidence and media types, date window, sample count, and any coverage caveat. Wait for confirmation before storing the launch configuration or building data-dependent UI. 7. Never substitute scraping, another data provider, guessed IDs, invented fields, or mock Synorb records when Synorb is unavailable. Pause with precise setup guidance. For the shipped app, use Lovable Cloud and a server-side Edge Function. Store SYNORB_API_KEY and SYNORB_SECRET only under Cloud -> Secrets; never use a VITE_ variable or expose either value to browser code. The Edge Function calls POST https://api.synorb.com/streams/query with api-key and secret headers. The first request must omit cursor and send one of stream_ids or home_domains, plus story_type, page_size, and an explicit date window. Multi-stream REST results are flat rows under data.briefs[] or data.signals[]; pagination is under data.pagination and the next request uses data.pagination.next. Do not expect MCP-only quota_header, coverage, or citations fields from REST. Surface REST usage and cite each row's real source_url. Lock CORS to the app origin, require the app's authenticated user where appropriate, validate all input, rate-limit public surfaces, and use row-level security for user-owned records. LOVABLE-NATIVE DESIGN AND ORIGINAL IMAGERY WORKFLOW Treat the product shell, data visualization, and imagery as one design system, not a decorative add-on. 1. In Plan mode, ask whether the user wants to start from an existing Lovable template or connected design system, upload a logo or screenshot, use the recommended direction, or customize. When there is no locked design system, explicitly ask Lovable to show three rendered design directions before the full build. The directions must differ meaningfully in composition, typography, palette, information hierarchy, and image treatment—not just accent color. 2. Also ask the user to choose or delegate: heading/body font feel, color mood, layout family, density, motion level, light/dark behavior, accessibility needs, and image approach—editorial photography, cinematic generated imagery, data-led illustration, abstract visual system, or minimal imagery. Ask for restrained, balanced, or immersive image prominence; brand colors/assets; and subjects, symbols, colors, clichés, or styles to avoid. Recommend editorial briefing design with restrained generated cover art and evidence-forward typography with balanced imagery: one edition cover, section dividers, and email-safe accents. Summarize all answers as a Design Direction Receipt and save the approved rules in Project Knowledge so later generations stay consistent. 3. Create a compact asset plan limited to imagery that improves comprehension or delight: edition cover art, section dividers, email-header crop, empty states, archive thumbnails, and social previews. Never let decoration compete with live Synorb evidence or citations, and never present generated art as primary-source evidence or as a factual visualization of Synorb data. 4. Web search may inform subject matter, factual details, visual vocabulary, composition categories, and color relationships. Do not download, trace, reproduce, or send an ordinary copyrighted search result or thumbnail to an image model merely to restyle it. Appearance in web search is not permission. A style filter does not make a source image proprietary or erase license obligations. 5. Use a reference image only when it is user-owned, verified CC0/public domain, or licensed for commercial use and modification. Record its URL, creator, and license. Reject editorial-only, non-commercial, no-derivatives, unidentified, or ambiguous rights. Trademarks, privacy, and publicity rights may still apply. 6. Prefer text-to-image generation from an original creative brief based on the approved Design Direction Receipt and verified Synorb scope. Do not request a replica of a specific copyrighted image, branded character or logo, unapproved real-person likeness, or the signature style of a named living artist. Use a commercial-use image provider selected by the user and connect its key through Lovable Cloud Secrets and an Edge Function. If no provider is available, stop at an approved asset plan; never fall back to scraped imagery. 7. Before generating the full asset family, create three low-cost image candidates for the highest-impact surface, place each into the same real-data preview, and ask the user to select one, combine specified qualities, request another direction, or continue without imagery. Wait for approval. Then use Lovable Visual Edits to let the user adjust crops, image placement, text, color, type, spacing, and responsive behavior without rebuilding unrelated components. 8. Keep human creative control visible. Save the chosen direction, selections, revisions, crop decisions, and layout treatment. Describe the output as custom, brand-consistent generated imagery; do not promise exclusive copyright or guaranteed proprietary rights. 9. Write docs/image-provenance.json with filename, product location, creation method/provider, generation date, original creative brief, human selections/edits, and every permitted reference URL/creator/license. Never put credentials in that file. 10. Ship responsive AVIF/WebP assets with an appropriate fallback, stable aspect ratios, useful alt text, mobile and desktop crops, lazy loading below the fold, and no important text baked into images. Test light/dark themes, keyboard navigation, reduced motion, mobile, tablet, and desktop. Include the final asset list and provenance status in the build receipt. LOVABLE-NATIVE IMPLEMENTATION Use React and TypeScript with accessible semantic components and an explicit token system. Use Lovable Cloud for authentication, database, scheduled/server functions, logs, and Secrets. Keep project-specific product, data, security, and design rules in Project Knowledge. If a connected template or design system exists, obey it and explain any necessary exception before changing shared primitives. Build by vertical slice, preview with real content, and use Visual Edits for precise design refinements instead of regenerating unrelated code. Never claim a scheduled refresh, email, embed, auth rule, image asset, or source link works until it has been exercised. PRIORITY FUNCTIONS FOR THE USER TO CHOOSE edition review, saved sections, previous-edition comparison, email preview, approvals, scheduling, or exports. ACCEPTANCE TESTS 1. No MCP token, API key, API secret, image-provider secret, or raw credential bundle appears in browser code, VITE_ variables, HTML, logs, database rows, image provenance, or API responses. 2. Both synorb-profile and the server-side REST account validation pass before the app builds against live data. 3. Every persisted Synorb ID is a validated 17-digit string; every exact source filter resolves to the approved source channel. 4. The first real-data screen, every chart drill-in, exported claim, and every Brief/Signal detail preserves a real source_url. Generated visuals are clearly decorative and never styled as factual evidence. 5. Date filters affect MCP discovery and REST runtime requests consistently. Pagination, usage, loading, error, partial, and empty states are exercised with real responses. 6. Authentication, RLS, input validation, CORS, and rate limits are tested for the selected public/private deployment shape. 7. The three design directions, Design Direction Receipt, user-approved image candidate, Visual Edits pass, responsive crops, alt text, and docs/image-provenance.json are complete. 8. The final Build Receipt names exact Streams, source channels, filters, date window, routes, secret names only, design choices, image provenance status, verification evidence, and the live published URL.