Internet Research Notebook — turn scattered research into a public, inspectable research pack

Build an open-source "Internet Research Notebook" for creators, analysts, and builders. The app should help someone turn scattered online research into a public, inspectable research pack. Core idea: A user starts with a question, claim, trend, market, or business idea. The app helps them collect sources, structure evidence, track confidence, record contradictions, and publish a clean public page that others can inspect, reuse, fork, or turn into a build prompt. This is not a trend-discovery tool — it starts after someone has found an interesting signal and wants to make the research credible. Build a working demo with: 1. Research packs — created around questions (e.g. "Are more older adults starting businesses?", "Is perimenopause an underserved market?", "Is remote work actually declining?"). Each pack includes: title, research question, short thesis, target audience/market, status, last-updated date, public/private toggle. 2. Source cards — each with: title, URL, source type, date published, key quote/stat/observation, claim supported, confidence level, notes, tags. 3. Evidence table — all claims in a structured table; each claim links back to supporting sources. Claims have: claim text, supporting sources, confidence level, evidence strength, notes, and whether confirmed/uncertain/disputed/outdated. 4. Contradiction tracker — add sources or notes that disagree with the thesis. The public page shows counter-evidence clearly so the output isn't a cherry-picked trend report. 5. Confidence scoring — mark evidence as strong / medium / weak / anecdotal / outdated / conflicting. 6. Public research page — clean shareable page with: summary, key findings, claims and evidence, contradictions, simple charts/visualizations, open questions, source list, last-updated date. 7. Forking — another user can fork a pack, add sources, challenge claims, update the thesis, or adapt it for a different niche. 8. Build prompt generator — for packs pointing toward a product opportunity, generate a FablePool-ready build prompt with: MVP scope, target user, user stories, milestones, validation plan, risks, success criteria, estimated build complexity. 9. Export — each pack exportable as Markdown, JSON, CSV, newsletter/blog outline, investment memo outline, and FablePool build prompt. 10. Demo data — seed with example research packs around overlooked markets, demographics, creator businesses, niche communities, local services, AI workflows, internet-native businesses. Important constraints: Do not scrape websites in v1. Use manually added URLs and demo data. Do not try to discover trends automatically. Make it white-label, not tied to any specific creator brand. Make public pages clean, credible, and highly shareable. Make every claim inspectable. MIT license. Ship with: working web app, demo data, public research pages, editor/admin interface, evidence table, contradiction tracker, confidence scoring, fork functionality, build prompt generator, export tools, README, setup instructions, database schema, API routes, tests where practical.

Produce a detailed implementation blueprint for the open-source Internet Research Notebook: core user journeys, non-goals such as no scraping and no automatic trend discovery, white-label positioning, page inventory, route map, database/entity model, permission model, export format definitions, public-page requirements, acceptance criteria, and phased build plan. Include wireframe-level descriptions for the dashboard, pack editor, source cards, evidence table, contradiction tracker, public research page, fork flow, build prompt generator, and export screens.

Create the initial working repository for the web app with a practical full-stack TypeScript setup, routing, app shell, reusable white-label UI components, styling/theme tokens, database configuration, migration setup, seed script foundation, environment configuration, MIT license, starter README, linting/formatting, and basic smoke tests. Establish the core schema for users, research packs, sources, claims, contradictions, forks, exports, and generated prompts.

Implement the private editor/admin interface where demo users can create, view, edit, delete, and manage research packs. Include fields for title, research question, short thesis, target audience/market, status, last-updated date, public/private toggle, ownership, and basic permissions. Add dashboard views, filters, empty states, validation, seeded demo accounts, and tests for pack CRUD and access control.

Build full source card functionality for manually added URLs only. Each source card should support title, URL, source type, publication date, key quote/stat/observation, claim supported, confidence level, notes, tags, and pack association. Include source creation/editing forms, tag handling, validation, source lists, source detail views, URL display without scraping, and tests for source creation, editing, deletion, and display.

Implement the structured evidence table. Claims should support claim text, supporting sources, confidence level, evidence strength, notes, and status values such as confirmed, uncertain, disputed, and outdated. Add many-to-many source-to-claim linking, sortable/filterable evidence tables, confidence/evidence-strength badges, inline editing where practical, summary calculations, and tests covering relationships, validation, and evidence table behavior.

Add contradiction tracking so users can record sources or notes that disagree with the thesis or weaken specific claims. Include counter-evidence forms, linking contradictions to packs and optional claims/sources, conflict/outdated handling, visible uncertainty indicators, open questions, and editor views that make contradictory evidence hard to hide. Add tests proving public and private views preserve counter-evidence rather than producing cherry-picked reports.

Build clean public research pack pages for packs marked public. Pages should include summary, thesis, key findings, claims and evidence, contradictions, open questions, simple charts/visualizations, source list, confidence/status indicators, last-updated date, and share-friendly metadata. Include responsive layout, credible white-label styling, private-pack protections, public route tests, and chart components based only on manually entered/seeded data.

Implement pack forking so another user can copy a public research pack, add sources, challenge claims, update the thesis, or adapt it for a new niche. Preserve provenance, original pack attribution, fork timestamps, copied sources/claims/contradictions, ownership, public/private settings for the fork, and a clear UI showing when a pack is a fork. Add tests for fork creation, copied relationships, attribution, and permission boundaries.

Create a build prompt generator for research packs that point toward product opportunities. Generate structured prompts containing MVP scope, target user, user stories, suggested milestones, validation plan, risks, success criteria, and estimated build complexity. Include editable generated output, deterministic template logic based on pack fields and evidence, prompt preview UI, save/regenerate behavior, and tests for complete prompt generation from seeded packs.

Implement export tools for each pack: Markdown research pack, JSON data export, CSV exports for sources and claims, newsletter/blog outline, investment memo outline, and FablePool build prompt export. Add download routes, copy-to-clipboard where useful, consistent schemas, filenames, privacy checks, export previews, and tests confirming exported data includes claims, sources, contradictions, confidence, open questions, and attribution.

Seed the app with polished demo research packs around overlooked markets, demographics, creator businesses, niche communities, local services, AI workflows, and internet-native businesses. Each seeded pack should include realistic manually entered source cards, claims, evidence strengths, contradictions, open questions, confidence levels, tags, public pages, and at least one forked example. Ensure the demo data clearly illustrates inspectability without scraping or automatic trend discovery.

Finalize API routes, validation, error handling, test coverage, and packaging. Add practical unit/integration tests for core flows, database schema documentation, setup instructions, seed/demo instructions, deployment notes, environment variable reference, architecture notes, contribution guidance, MIT license confirmation, and a final QA checklist. Polish accessibility, empty/error states, responsive behavior, and ensure a new developer can run the full demo locally from the README.