Home A - Z
Page Index
Properties 
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)
  • 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