How to build an AI newsletter with Lovable.

CREDENTIALS FIRST: Before any Synorb setup, ask the user in plain English for one Synorb Key (SYNORB_KEY). Parse only credentials.synorb_key from GET https://synorb.com/connect; store the one key as a server-side secret and use Authorization: Bearer <synorb_key> for both REST and MCP. A self-provisioned key is DEMO access for 1,000 Manifests and expires 24 hours after mint; read and surface the top-level expires_at field. Bind an email with POST https://api.synorb.com/api/connect/bind-email using the same Bearer key to get Starter, free forever with 1,000 Manifests/month and no expiry; Paid is $10/month for 10,000 Manifests/month. After expiry, bind an email, mint a new demo at https://synorb.com/connect, or sign up free at https://synorb.com/signup. Store one server-side key, show `Synorb key expired - bind an email or mint a new demo key` instead of a generic auth failure, do not retry automatically, and document expires_at plus these recovery paths in the generated README and environment template. 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 Authorization: Bearer <synorb_key>. The user enters SYNORB_KEY only in that protected connector field and Cloud -> Secrets. 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 only credentials.synorb_key without printing or logging the response body, read and surface the top-level expires_at, and store one SYNORB_KEY in the protected connector and Cloud Secrets. DEMO access is 1,000 Manifests for 24 hours; binding an email with POST https://api.synorb.com/api/connect/bind-email using the same Bearer key gives Starter, free forever at 1,000 Manifests/month; Paid is $10/month for 10,000 Manifests/month. If DEMO expires, show "Synorb key expired - bind an email or mint a new demo key" and document binding an email, minting a new demo key, or signing up free at https://synorb.com/signup. If Lovable cannot move the key into a protected field without displaying it, stop and guide the user to open https://synorb.com/connect directly and enter it in those protected fields. Do not echo the key, persist it in app data, or retry automatically. After either path, call synorb-profile through MCP and GET https://api.synorb.com/account through a temporary server-side validation function using Authorization: Bearer <synorb_key>. Report only pass/fail, account name, account ladder state, 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 partial access. 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 false, page_size 5, target_count 5, 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 one SYNORB_KEY only under Cloud -> Secrets; never use a VITE_ variable or expose it to browser code. The Edge Function calls POST https://api.synorb.com/streams/query with Authorization: Bearer <synorb_key>. 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. AGENT-FIRST BRIEF V2 AND SIGNAL CONTRACT The current Synorb Brief is an additive structured object, not a fixed markdown article. Build the Lovable runtime adapter and interface around the returned JSON shape. 1. For POST /streams/query, send compact false. compact true intentionally removes body and body_markdown, so it is suitable only for a lightweight ranking list, never the detailed product experience. 2. Treat each row's body as the canonical Brief or Signal body. Preserve unknown additive keys in storage and server responses. Never reject a row merely because Synorb added a field, and never invent a missing optional field. 3. For Briefs, render the agent-first scan layer before the longer narrative when present: - tldr: one standalone sentence. - facts: up to ten typed objects with label, value, and optional unit, period, delta, or entity. - why_it_matters: bounded professional consequence framing. - timeline: dated objects with date and event. - unresolved: explicit source limitations or open questions. - signal_digest: deterministic claim_count, by_type, optional by_confidence, and featured claim pointers. - brief_meta: schema_version, family, prompt_version, token_estimate, and optional stale_after or revalidate_after_days. 4. Keep the existing narrative layer available below or beside the scan layer: summary; key_insights with key_points as a backward-compatible alias; notable_quotes as objects with text, optional speaker, and context; actionable_takeaways; guest_details with name, title, and affiliation; cross_promotion; cultural_relevance; sentiment; and significance. Treat empty arrays and nulls as honest source outcomes. 5. Render source-backed family facets when returned: filing_facets for regulatory or SEC content, series_facets for data, paper_facets for research, episode_facets for audio, and domain-specific objects such as legal_facets, legislative_facets, or state_legislature_facets. Feature-detect these objects. Do not show empty shells or infer values from prose. 6. body_markdown is a backward-compatible rendered convenience, not the structured-data source. When a full Manifest route is used and markdown_version=2 is supported, body_markdown_v2 is additive and must not replace body_markdown or body. 7. For Signals, render body.claims[] as the deeper machine-readable layer. A claim may contain claim_text, claim_type, confidence, evidence, quote, signal, featured, key_point_index, and entities. Also preserve claims_summary, claims_rollup, topics, entity_details, domain_classification, sentiment, and significance when returned. Do not synthesize a Signal summary that Synorb did not return. 8. Every Brief fact, quote, timeline item, takeaway, facet, and Signal claim inherits the row's real source_url. Keep that citation reachable from every detail view, export, alert, and generated edition. 9. Add tolerant schemas and types for optional additive fields, fixtures for a legacy Brief, a full Brief v2, a sparse Brief v2, and a Signal with claims, plus tests proving unknown keys survive normalization. The first live preview must visibly use at least tldr, facts, why_it_matters, unresolved, signal_digest, and one available family facet instead of flattening every result into headline plus summary. 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 Synorb Key, 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. A full Brief v2, sparse Brief v2, legacy Brief, and Signal all render without fabricated fallback content; unknown additive body keys survive normalization. 7. The live preview visibly uses the agent-first scan layer and an available family facet, while the legacy narrative, complete claims layer, and citations remain inspectable. 8. Authentication, RLS, input validation, CORS, and rate limits are tested for the selected public/private deployment shape. 9. 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. 10. The final Build Receipt names exact Streams, source channels, filters, date window, routes, secret names only, Brief schema versions observed, design choices, image provenance status, verification evidence, and the live published URL.