Local-first deployment and operational boundaries

The complete MVP must work locally before public deployment. The same Markdown, IDs, graph relations, citations, metadata, feeds, sitemap, and structured data produce materially equivalent localhost, preview, and production output. Local fixtures and safe stubs exercise contact and community failure states without real credentials or public writes.

Stages and ownership

Stage	Purpose	Promotion gate
Localhost	Content authoring, static build, validation, fixtures, and safe failure testing	Full local check suite
GitHub pull request	Immutable review diff, audit chain, required checks, and non-indexable preview	Positive designated-editor review
Protected main	Approved source of production truth	Reviewed merge only
Vercel production	Static-first delivery plus narrow private functions	Successful main build and health checks

GitHub owns source control, Issues, intake forms, Actions, CODEOWNERS, required checks, review, schedules, and publication authorization. Hourly ingestion runs in Actions, never Vercel Cron. Vercel owns preview and production build/runtime, CDN delivery, environment isolation, observability, rollback, and bounded private functions. It does not decide editorial approval.

Every eligible PR receives a preview tied to an exact commit and marked non-indexable. Preview robots, canonicals, feeds, sitemaps, and structured data cannot masquerade as production. Production deploys only the protected default branch. A failed build leaves the last known-good deployment serving.

Free-MVP controls and upgrade signals

Static generation and caching keep public reading inexpensive. Server functions are reserved for private contact and authenticated mutations, with payload limits, timeouts, per-user/network rate limits, idempotency, and server-only credentials. Monitor builds, bandwidth, image processing, function calls and duration, logs, deployment count, domain usage, Clerk activity, database connections/storage, backups, moderation volume, and webhook failures separately.

Reconfirm Free/Hobby eligibility, quotas, terms, and commercial-use constraints before launch. Upgrade ownership belongs to the named operator. Signals include sustained quota pressure, unacceptable build or function latency, required team/security controls, log retention needs, higher availability/support requirements, or operating risk exceeding the cost difference. Vercel, Clerk, database, and moderation upgrades are independent decisions.

Resilience and exit

Public research remains static and readable if Clerk, the database, moderation, or contact processing is unavailable. Protected controls switch visibly to read-only and do not claim an unconfirmed write succeeded. Only safely idempotent work may queue.

Portable Markdown and documented schemas remain authoritative. Community migrations, exports, moderation reasons, stable ID mappings, and backups are tested. Vercel-specific functions sit behind narrow interfaces. A production-equivalent build runs outside Vercel, canonical IDs survive migration, and a host change does not lose citations, URLs, discussions, graph relations, or editorial history.

Acceptance requires local parity, hourly GitHub ingestion, commit-bound non-indexable previews, merge-only production, private contact handling, production canonicals, last-good rollback, separate service monitoring, auth and webhook integration tests, backup restore, and a tested export/migration path.