Regional Economy Desk

You are Cursor. Build Regional Economy Desk in this repository. PROMPT METADATA Slug: cursor-regional-economy-desk Title: Regional Economy Desk Short title: Economy Desk Domain: regional-economy Tagline: Build a BLS-backed regional economy dashboard with metro charts, local explainers, and cited claim exports. Video state: Build video coming next User fit: Developers building internal reporting tools, local business intelligence, or newsroom economy desks. What you get: - Metro and regional economic charts - BLS release and source-channel filters - Claim cards tied to source releases - Analyst or reporter brief export Cursor and platform tools: - Cursor Agent - Cursor MCP - Next.js App Router - charting library selected from repo conventions - server-side Synorb REST route Synorb stream families: - BLS metro employment - BLS CPI and inflation Streams - BLS wages, unemployment, JOLTS, labor, and regional source channels - regional Federal Reserve or other official economic Streams when available Tags: BLS, regional economy, metro, jobs, inflation, wages, charts PRODUCT TO BUILD Build a Regional Economy Desk that turns BLS and other official regional economic Streams into local charts, release notes, cited analyst briefs, and exportable claims. The first screen should answer what changed in this market, which source proves it, and what a reporter or analyst can do next. PRIMARY USER Product engineer building a regional economy dashboard for analysts, editors, or business users. APP-SPECIFIC LIVE SCOPE Start with BLS Streams and inspect source channels for metro employment, CPI, wages, unemployment, job openings, industry employment, and regional releases. Add regional Federal Reserve or other official economic Streams only when discovery confirms coverage for the selected markets. Use a current window and a prior comparison window. CORE PRODUCT FEATURES - Market selector and release family selector - Charts for returned values only, with source release links next to each chart - Brief panel with key takeaways, why it matters, and notable quotes when present - Claim table with confidence, evidence, and source URL - Export to Markdown or CSV with citations retained SYNORB ACCESS CHECKPOINT - ASK AND WAIT Before making any Synorb discovery call or writing data-dependent code, ask the user to choose: 1. Use my existing Synorb credentials. 2. Get free Synorb credentials through Synorb Connect. For existing credentials, guide the user to add the Synorb MCP server in Cursor settings or the repo-local Cursor MCP configuration. Use https://mcp.synorb.com/mcp with bearer token or API-key authentication, and keep SYNORB_MCP_TOKEN only in the protected MCP configuration. For runtime calls, put SYNORB_API_KEY and SYNORB_SECRET only in server-side environment variables or the deployment platform secret store. For Synorb Connect, send the user to https://synorb.com/connect and have them copy values only into protected credential fields. Never ask the user to paste secrets into chat, generated source files, NEXT_PUBLIC variables, browser storage, logs, HTML, screenshots, fixtures, database rows, or documentation. In plain words: do not paste secrets into chat or generated files. If Cursor cannot store a returned value without displaying it, stop and give protected-entry instructions instead of continuing. After the user confirms both credential paths, call synorb-profile through MCP and create a temporary server-side account validation route or script for REST. Report only pass or fail, account name, quota state, and allowed date window. Never print credential values. If either MCP or REST fails, stop at a setup-blocked state. Never substitute another provider, mock feed, guessed Stream, or scraped source. SYNORB MCP DISCOVERY CONTRACT 1. Call synorb-profile once first. Record account, quota state, date window, and whether coverage or quota warnings are present. 2. Call synorb-stream-search for the requested beat, entity, source family, market, ticker, media format, or policy topic. Use include_details true when choosing streams or source channels. Treat coverage.status "partial" as inventory pagination, not proof that no other Streams exist. 3. Select only real customer-visible Streams with positive 17-digit IDs. Preserve every Synorb ID as a JSON string end to end. Never guess, shorten, coerce, or invent an ID. 4. Call synorb-details on selected Streams when you need source channels, media formats, source_class, evidence_type, available filters, or recent volume. 5. Run synorb-manifests with mode "count" first for a zero-quota density check. Then run one bounded build sample with compact true, page_size 5-12, target_count 5-12, selected stream_ids or source_channel filters, and an explicit date window inside synorb-profile limits. 6. Use tag_names, source_channel_names, source_channel_ids, source_class, evidence_type, media_format, ticker, isin, or identifier only when the approved product scope requires them. 7. Count and orient responses are preflight only. Do not summarize them as exhaustive result sets. Preserve quota_header, coverage.status, required_user_notice, citations, and recommended_next_call when MCP returns them. 8. Show a Live Scope Receipt before building data-dependent UI: Stream names and IDs, source-channel names and IDs when used, filters, evidence and media types, date window, sample count, quota header, citations when returned, recommended next call, and any coverage caveat. Ask the user to approve or adjust it before persisting a launch configuration. SYNORB REST RUNTIME CONTRACT Use Synorb MCP for build-time discovery and Synorb REST for the running application. Put runtime calls behind a server-only route such as /api/synorb, /api/synorb/newsroom, or the equivalent backend endpoint in the detected framework. The server route calls POST https://api.synorb.com/streams/query with api-key and secret headers from server-side secrets. The first request must omit cursor and send one of stream_ids, source_channel_ids, home_domains, ticker, isin, or identifier, plus story_type when needed, page_size, and an explicit date window. Multi-stream REST results are returned as flat rows under data.briefs, data.signals, or data.manifests depending on the request. 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 unless the API response actually includes them. Surface REST usage honestly. Cite each returned row's real source_url. Validate inputs, enforce auth where appropriate, lock CORS to the app origin, rate-limit public routes, and never expose SYNORB_API_KEY or SYNORB_SECRET to browser code. FULL MANIFEST, SIGNAL, AND BRIEF SURFACE Do not flatten Synorb into generic headline cards. Preserve the richest available facets: Manifest fields: id, record_id, source_url, source_name, source_channel, source_channel_names, stream_ids, stream_names, published_at or published_date, media_format, story_type, significance, tags, entities, topics, citations, coverage, diagnostics, usage, and pagination when returned. Signal fields: claims, claim_type, confidence, evidence, quote when present, featured or actionable fields when present, per-claim source links, and enough context for a user to verify the claim against the original source. Brief fields: body_markdown, key takeaways, notable quotes, why it matters, timeline, sources, caveats, and source-linked citations when present. If a field is absent, render a professional missing-state instead of inventing it. Every exported draft, chart drill-in, digest item, alert, and card detail must retain a source URL path back to the original source. GAP-ONLY WEB POLICY Synorb is the source-grounded context layer. Web search may fill an explicit gap only when Synorb coverage is absent or when the user asks for supplemental context. Put web results in a separate lane labeled web context or unverified supplement. Never blend web text into Synorb-cited prose, never present web context as a Synorb Manifest, and never use scraping or another provider as a silent fallback when Synorb is unavailable. CURSOR-NATIVE IMPLEMENTATION LOOP Work like a Cursor agent inside an existing repository: 1. Inspect the repo first. Detect framework, package manager, test runner, auth pattern, server-route convention, component system, and deployment target. If the app is new, recommend Next.js App Router with TypeScript unless the user chooses another stack. 2. Ask one compact product checkpoint only when needed: audience, first-session outcome, private or public surface, refresh cadence, delivery channel, and whether to use the recommended scope. 3. Add repo guidance in .cursor/rules or project notes when useful: server-only secrets, Synorb ID strings, source URL preservation, no silent fallback data, and Build Receipt requirements. 4. Build a vertical slice first with live Synorb data or an explicit setup-blocked state. Local fixtures may exist only for tests. 5. Add typed adapters for Manifests, Signals, Briefs, claims, citations, coverage, usage, diagnostics, and pagination. Keep adapters tolerant of absent optional fields and strict about invented required fields. 6. Add focused tests for secret safety, adapter mapping, empty and partial states, pagination, source links, and product-specific acceptance criteria. 7. Run the local checks that fit the repo. Summarize failures instead of hiding them. 8. Finish with a Build Receipt naming exact Streams, source channels, filters, date window, routes, env names only, automation schedule or trigger, test commands, and known gaps. AUTOMATION FOR THIS BUILD Create a scheduled Automation aligned to selected release cadence, with a conservative weekday fallback if release calendars are not available in returned data. CURSOR AUTOMATIONS When the product needs to keep running, create or describe a Cursor Automation that uses the approved Live Scope Receipt. Prefer scheduled morning or weekday refreshes for desks and dashboards, and GitHub, Linear, Slack, PagerDuty, or webhook triggers for developer workflows. Automation output must include source-linked changes, coverage caveats, and enough Stream/filter metadata for a reviewer to reproduce the call. Do not claim an automation works until it has been run or clearly marked as planned. APP-SPECIFIC ACCEPTANCE TESTS - No chart value is invented or inferred from prose. - Every chart point and claim traces to a returned source URL or visible no-data state. - The product separates national, regional, and metro evidence instead of blending them. SHARED ACCEPTANCE TESTS 1. MCP and REST credential paths are validated before live data is used. 2. No token, API key, API secret, credential bundle, or secret value appears in client code, NEXT_PUBLIC variables, HTML, logs, fixtures, screenshots, database rows, docs, or API responses. 3. Every persisted Synorb ID is a validated 17-digit string. 4. Every first-screen row, draft, card, alert, chart drill-in, digest item, and export preserves a real source_url path. 5. The UI distinguishes Manifest, Signal, Brief, claim, citation, coverage, usage, diagnostics, and web-gap data instead of blending them together. 6. Loading, error, setup-blocked, empty, partial coverage, pagination, and stale-data states are visible and tested. 7. No mock data or substitute provider appears in user-visible preview after credentials validate. 8. The Build Receipt lists exact Streams, source channels, filters, date window, route names, environment variable names only, automation plan, test commands, and remaining gaps. FINAL OUTPUT Build the product as a working vertical slice with real Synorb data or a setup-blocked state. Then provide a Build Receipt with exact Streams, source channels, filters, date window, routes, environment variable names only, automation status, test commands run, and any known gaps. Do not deploy unless the user separately asks after review.