Public repo checklist

AI App Launch Safety Checklist for Public Repos

A practical pre-launch pass for AI-built apps, agent workflows, and MCP projects. No credentials are needed. This is not a certified pentest.

Request a fit check Front desk Run it locally

Who this is for

Use it before a public launch, demo, or funding conversation.

The checklist is meant for public GitHub repos built quickly with coding agents, app builders, MCP servers, Supabase/Firebase backends, API integrations, or webhook-heavy flows.

Secrets and env handling

No real tokens, API keys, cookies, private keys, or credentials in tracked files.
Examples use safe placeholders and explain required env variables.
Frontend code does not reference server-only secret names.
Git history and generated reports are reviewed before launch announcements.

Auth and tenant isolation

Routes that read or write user data check ownership or tenant scope.
Admin paths are not protected only by hidden buttons or client-side checks.
Supabase/Firebase policies are documented well enough for review.
Sample data cannot be confused with production customer data.

Webhooks and API boundaries

Webhook handlers mention signature verification or a clear equivalent control.
Public API routes validate method, content type, and expected fields.
Errors avoid exposing stack traces, tokens, or provider payloads.
Rate-sensitive flows have at least a basic abuse plan.

Browser security basics

CORS is not wildcarded for credentialed or sensitive endpoints.
Static sites have a plan for CSP, frame, referrer, and MIME-related headers.
Client config exposes only public identifiers, not service-role keys.
Preview and production origins are documented separately.

Agent, MCP, and tool permissions

Agent instructions do not ask tools to ignore policies or leak secrets.
MCP configs avoid broad filesystem, shell, or network access by default.
Workflows that pass issue or PR text into agents treat that text as untrusted.
Dangerous tool actions require explicit maintainer intent.

Public readiness files

README explains setup, expected env variables, and safe local usage.
LICENSE, SECURITY, gitignore, and CI are present for public launch trust.
Dependency manifests are committed and lockfiles are intentional.
Known limitations are documented without exposing sensitive details.

Self-check

Run the lightweight audit locally first.

The deterministic checks are intentionally public and local. They do not replace manual review, but they catch enough boring launch gaps to be worth running.

git clone https://github.com/bmtriet/FreeCodex.git
cd FreeCodex
python3 scripts/validate_repo.py
python3 scripts/repo_audit.py audit --path . \
  --output local-audit.md

Open the GitHub repo

Optional next step

Did this checklist save you time?

If the checklist helped you catch a launch issue or make a repo safer, optional support helps fund more public proof-of-work, checklists, triage notes, and mini-audits. If you want a scoped review instead, start with a public fit check.

Tip / support public work Sponsor a public pass Request a fit check View sample report

Donations are optional thanks for public work. They do not create an audit slot, support obligation, or guaranteed deliverable. Paid audits require fit and scope confirmation first. Do not send secrets, private keys, tokens, customer data, or account access.

When to request

Ask for a review when launch risk matters more than speed.

Good fits handle auth, payments, user data, APIs, webhooks, MCP tools, or agent workflows. Send a public repo URL and launch context only. Do not send secrets or account access.

Open fit-check issue Open front desk View sample report

Fit checks and paid audits start with public-safe scope confirmation. Do not include secrets, private repo contents, customer data, or account access.

Boundary

This is a lightweight launch/readiness checklist. It is not a certified penetration test, legal advice, compliance guarantee, or proof that a repository is secure.