--- category: reference tags: [process, launch] last_updated: 2026-03-13 confidence: medium --- # Launch Checklist — Human Actions Required Things that require human action before wikibot.io can go live. These cannot be done by agents. ## Branding - [ ] Logo designed (needed for OAuth consent screens, favicon, landing page) - [ ] Favicon / app icon variants (16x16, 32x32, 180x180, 512x512) ## OAuth Providers (WorkOS) ### Google - [ ] OAuth consent screen configured with logo - [ ] App submitted for Google verification review (required for production — unverified apps show scary warnings) - [ ] Privacy policy URL configured (Google requires this) - [ ] Terms of service URL configured ### Apple - [ ] Sign in with Apple configured with logo / branding - [ ] Privacy policy URL configured (Apple requires this) ### GitHub - [ ] OAuth app logo uploaded - [ ] Callback URLs updated for production domain ## WorkOS - [ ] Credit card added (required for production tier) - [ ] Production environment created (separate from staging) - [ ] Production API key generated and stored in Pulumi prod config - [ ] Redirect URIs updated for production domain (`wikibot.io`) ## DNS / Domain - [ ] `wikibot.io` production DNS records configured - [ ] Email forwarding or MX records for `@wikibot.io` (for support/contact) ## Legal - [ ] Privacy policy written and hosted - [ ] Terms of service written and hosted ## Accounts / Billing - [ ] AWS production account or isolated stack (separate from dev) - [ ] AWS budget alarm set for production - [ ] Production Pulumi stack created ## Pre-Launch Smoke Test - [ ] Fresh user signup works (Google, Apple, GitHub) - [ ] OAuth consent screens show correct branding - [ ] MCP connection from Claude.ai works - [ ] MCP connection from Claude Code works - [ ] Create wiki → write page → semantic search cycle works - [ ] Git clone with bearer token works ## Security Review Pre-launch security review before opening to users. This is not a penetration test — it's a structured walkthrough of the attack surface. ### Auth and access control - [ ] Verify tenant isolation: User A cannot access User B's wiki via API, MCP, web UI, or git - [ ] Verify MCP bearer tokens are hashed at rest (not stored in plaintext) - [ ] Verify OAuth tokens are not logged or exposed in error responses - [ ] Verify expired/revoked tokens are rejected promptly - [ ] Verify ACL enforcement on all routes (API, MCP, web, git) - [ ] Test collaborator invite flow: invited user gets correct permissions, uninvited user gets nothing ### Input validation - [ ] Wiki names, page names, usernames: test for path traversal (`../`, `%2e%2e/`) - [ ] Markdown content: test for stored XSS (script tags, event handlers, javascript: URIs in rendered HTML) - [ ] API inputs: test for injection via page titles, search queries, tag values - [ ] MCP tool inputs: fuzz all tool parameters for unexpected types and boundary values ### Infrastructure - [ ] Lambda environment variables: no secrets in plaintext (use Secrets Manager or Pulumi config) - [ ] EFS: confirm no cross-tenant file access is possible via path manipulation - [ ] DynamoDB: confirm IAM policies scope Lambda access appropriately - [ ] API Gateway: confirm rate limiting is active - [ ] HTTPS enforced on all endpoints (no HTTP fallback) - [ ] CORS headers: confirm only expected origins are allowed ### Data exposure - [ ] Error responses do not leak stack traces, file paths, or internal identifiers - [ ] Git clone does not expose other tenants' repos - [ ] Search (keyword and semantic) is scoped to the requesting user's wikis only - [ ] CloudFront cache does not serve User A's cached content to User B