Sports Civic Story Miner

You are Cursor. Build Sports Civic Story Miner in this repository. PROMPT METADATA Slug: cursor-sports-civic-story-miner Title: Sports Civic Story Miner Short title: Sports Civic Miner Domain: sports-civic Tagline: Build a story-mining tool that connects official sports streams to civic, campus, venue, labor, and local business angles. Video state: Build video coming next User fit: Local news, sports business, higher education, venue, and civic teams looking for high-signal local angles. What you get: - Sports-to-civic angle discovery - Team, campus, venue, and community filters - Cited story leads instead of game recaps - Reporter assignment and export workflow Cursor and platform tools: - Cursor Agent - Cursor MCP - Cursor Automations - Next.js or detected stack - server-side Synorb REST route Synorb stream families: - official sports team Streams - NCAA team and athletics Streams - local economy and BLS Streams - statehouse, campus, venue, transportation, and public-funding Streams where available Tags: sports, civic, NCAA, venues, campus, local economy, reporting PRODUCT TO BUILD Build a Sports Civic Story Miner. It should combine official sports and team Streams with local economy, campus, venue, transportation, sponsorship, labor, public-funding, and community signals. Avoid game recap fluff. The product is about source-backed civic, business, and community hooks that reporters can pursue. PRIMARY USER Developer building a newsroom or local-intelligence product that uses sports as a source of civic story leads. APP-SPECIFIC LIVE SCOPE Discover official sports, NCAA, team, conference, campus, venue, and local government Streams relevant to the selected markets. Add BLS or statehouse Streams only when they create a sourced local angle. Keep sports events and civic evidence visibly distinct. CORE PRODUCT FEATURES - Team, school, venue, and market filters - Angle cards for campus, labor, venue, transit, sponsorship, local business, public funding, and community impact - Source inspector with sports source and civic source lanes - Reporter packet export with claims, caveats, and links - Fresh hooks since last review CREDENTIALS FIRST - SYNORB ACCESS CHECKPOINT - ASK IN PLAIN ENGLISH AND WAIT Before any Synorb setup, discovery call, file edit, generated fixture, or data-dependent code, ask the user in plain English for Synorb Credentials: API Key (SYNORB_API_KEY), API Secret (SYNORB_SECRET), and MCP Token (SYNORB_MCP_TOKEN). Also ask whether they want to self-provision at Synorb Connect instead. Ask it now and wait before editing files, running tools, or making Synorb calls. Ask this as the first Cursor response and wait for the user's answer: "Do you already have Synorb credentials I should use through protected setup fields - SYNORB_API_KEY, SYNORB_SECRET, and SYNORB_MCP_TOKEN - or do you want to self-provision at Synorb Connect?" If the user provides credentials, accept them only through protected credential fields, protected secret-entry, or environment configuration, not chat text or generated files. Store the API Key and API Secret only as server-side secrets/.env or deployment platform secrets. Store the MCP Token only for MCP setup in Cursor settings or repo-local MCP configuration. Use https://mcp.synorb.com/mcp with bearer token or API-key authentication. Never ask the user to paste secrets into chat or generated files; do not paste secrets into source, docs, or logs. Never expose any credential in browser/client code, NEXT_PUBLIC variables, HTML, logs, screenshots, fixtures, database rows, documentation, or API responses. If the user confirms self-provision, open or make exactly one GET request to https://synorb.com/connect and use the returned api_key, api_secret, and mcp_token the same way: api_key maps to SYNORB_API_KEY, api_secret maps to SYNORB_SECRET, and mcp_token maps to SYNORB_MCP_TOKEN. If Cursor cannot store a returned value without displaying it, stop and give protected-entry instructions instead of continuing. After protected entry is confirmed for both MCP and REST credentials, 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 neither credential path works, pause and ask the user. Do not substitute mock data, scraping, another provider, guessed Streams, or uncited filler. Never substitute another provider, mock feed, guessed Stream, scraped source, or uncited filler. Include a Credential Setup Receipt in the Build Receipt: credential path chosen, MCP validation status, REST validation status, account name if validation succeeded, quota state, allowed date window, protected storage location by name, and environment variable names only. Do not include credential values. SYNORB PRODUCT FIT After credentials are settled and before building, ask concise questions with smart defaults about goals and workflow: who will use this, what decision or task it should improve, what a successful output looks like, which entities, topics, sources, date window, and freshness matter, and what action the user should take after reading. Also ask design and layout choices with defaults: density, tone, visualization style, review workflow, color and mood, typography, and information density. Apply the answers consistently. If the user skips a choice, use the prompt's recommended scope and state the default in the Build Receipt. 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. SYNORB MANIFEST SCOPE Build against the full Synorb Manifest shape, not a flattened news card. Preserve 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.status, diagnostics, usage, and pagination or cursors when returned. Expose Signal facets as first-class UI: claims, claim_type, confidence, evidence, quote when present, featured or actionable signal fields when present, per-claim source links, and enough context for a user to verify the claim against the original source. Expose Brief facets as first-class UI: body_markdown plus structured markdown sections such as Key Takeaways, Notable Quotes, Why It Matters, Timeline, Sources, caveats, and source-linked citations when present. Create expanded/detail views, filters, charts, exports, saved-watch states, review states, and downstream actions that use these facets. If a facet is absent, show an honest empty or partial state and keep the field optional in types. Never invent missing claims, quotes, metadata, citations, or links. Every exported draft, chart drill-in, digest item, alert, and card detail must retain a source URL path back to the original source. SYNORB DATA SOURCE Synorb is the real external data source for this product. Do not substitute another provider, mock data, scraping, or uncited filler. If Synorb cannot be reached, stop and ask the user. Use MCP only for build-time exploration and server-side REST for runtime app data unless the product is explicitly MCP-only. Render only what Synorb returns, with a source link on every item. Free starter access includes 1,000 Manifests/month; upgrades are at https://synorb.com/pricing. 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. Use the answers from SYNORB PRODUCT FIT to set audience, first-session outcome, private or public surface, refresh cadence, delivery channel, visual density, review workflow, 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 weekly Automation and an optional game-week trigger that looks for new civic or business angles rather than scores. 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 - Game recap content is not treated as a complete story unless it has a civic or business angle. - Sports claims and civic claims retain separate source URLs. - The UI labels any missing civic source as needs reporting. 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 the Credential Setup Receipt, 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 a Credential Setup Receipt, 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.