Home A - Z
Page Index
Properties 
## How to read this document

- Dependencies list task IDs that must be complete before this task starts
- Parallel group identifies tasks that can run simultaneously within a phase
- Target identifies which repo and branch the work goes into
- Tasks are numbered P{phase}-{sequence} (e.g., P0-3)
- Acceptance criteria are binary — pass or fail, no judgment calls

Phase 4: Git Remote + Launch Prep

Goal: Git clone/pull access, rate limiting, monitoring, backups, landing page. Free tier shippable after this phase.

P4-1: Git Smart HTTP

Parallel group: Phase 4 (parallel with P4-3, P4-4, P4-5, P4-6) Dependencies: P1-7 (routing) Target: wikibot-io repo, feat/P4-1-git-http

Description: Implement Git smart HTTP protocol for read-only clone/pull access (free tier). Lambda handles git-upload-pack for clone/fetch. Use dulwich for pure-Python Git protocol handling (no git binary dependency).

Route: {username}.wikibot.io/{wiki}.git/*

Deliverables:

  • app/git/smart_http.py — Git smart HTTP handlers (info/refs, git-upload-pack)
  • API Gateway routes for /{wiki}.git/*
  • Integration test: git clone https://user.wikibot.io/wiki.git

Acceptance criteria:

  • git clone succeeds for authorized user
  • git pull fetches latest changes
  • git push rejected for free tier (read-only)
  • Unauthorized clone rejected (unless public wiki)
  • Public wiki clonable without auth

P4-2: Git Auth

Parallel group: Phase 4 Dependencies: P4-1, P2-2 Target: wikibot-io repo, feat/P4-2-git-auth

Description: Git credential authentication. Users authenticate git clone/pull with their MCP bearer token as password (username ignored or set to token). The Lambda validates the bearer token against the wiki's stored hash.

Deliverables:

  • Git credential validation in smart HTTP handler
  • Documentation: how to configure git credential helper for wikibot.io
  • Integration test: authenticated clone, rejected unauthorized clone

Acceptance criteria:

  • git clone https://token:<bearer>@user.wikibot.io/wiki.git succeeds
  • Invalid token rejected with 401
  • Git credential helper instructions work

P4-3: WAF Setup

Parallel group: Phase 4 (independent) Dependencies: None (can apply to existing API Gateway) Target: wikibot-io repo, feat/P4-3-waf

Description: AWS WAF on API Gateway and CloudFront. IP-based rate limiting, OWASP Top 10 managed rule set, bot control.

Deliverables:

  • infra/components/waf.py — WAF web ACL, managed rules, rate limiting
  • Rate limit: 100 requests/minute per IP (adjustable)
  • OWASP managed rule set attached

Acceptance criteria:

  • WAF attached to API Gateway and CloudFront
  • Rate limiting triggers on excessive requests
  • OWASP rules active
  • Legitimate traffic not affected

P4-4: Monitoring and Alerting

Parallel group: Phase 4 (independent) Dependencies: None Target: wikibot-io repo, feat/P4-4-monitoring

Description: CloudWatch dashboards, alarms, and alerting for production readiness.

Deliverables:

  • infra/components/monitoring.py — dashboards, alarms, SNS topics
  • Dashboard: Lambda invocations, errors, duration, cold starts; API Gateway 4xx/5xx rates; DynamoDB throttles; EFS IOPS
  • Alarms: Lambda error rate > 5%, API 5xx rate > 1%, DynamoDB throttle, EFS burst credit depletion
  • SNS email notifications for alarms

Acceptance criteria:

  • Dashboard viewable in CloudWatch console
  • Alarms trigger on test conditions
  • Email notifications received

P4-5: Backup Strategy

Parallel group: Phase 4 (independent) Dependencies: None Target: wikibot-io repo, feat/P4-5-backups

Description: AWS Backup for EFS (daily snapshots, 30-day retention). DynamoDB PITR (already enabled in P2-1, verify here).

Deliverables:

  • infra/components/backups.py — AWS Backup vault, plan, selection for EFS
  • Verification that DynamoDB PITR is enabled
  • Runbook: how to restore from EFS backup, how to restore DynamoDB to point-in-time

Acceptance criteria:

  • AWS Backup plan created with daily schedule
  • EFS filesystem selected for backup
  • 30-day retention configured
  • DynamoDB PITR verified active
  • Restore runbook written and tested (at least one test restore)

P4-6: Landing Page and Docs

Parallel group: Phase 4 (independent) Dependencies: P3-7 (static hosting infrastructure) Target: wikibot-io repo, feat/P4-6-landing

Description: Public landing page at wikibot.io for new visitors. Explains what wikibot.io is, shows pricing (free tier), and has a signup CTA. Basic docs covering: getting started, MCP setup, wiki conventions.

Design spec: Design/Landing_Page — content, structure, tone, logo requirements, deliverables.

Deliverables:

  • Landing page (within SPA or separate static page)
  • Getting Started guide
  • MCP setup documentation
  • Pricing section (free tier only for now, "premium coming soon")

Acceptance criteria:

  • Landing page loads at https://wikibot.io/
  • Getting Started guide covers: signup → create wiki → connect MCP → first note
  • MCP setup docs cover Claude.ai and Claude Code
  • CTA links to signup/login

P4-7: Phase 4 E2E Test

Parallel group: Phase 4 (final) Dependencies: All P4 tasks Target: wikibot-io repo, feat/P4-7-e2e

Description: Full free-tier user journey: discover → signup → create wiki → connect MCP → write notes → clone repo → manage collaborators. This is the launch readiness test.

Deliverables:

  • tests/e2e/test_phase4.py
  • Results written to Dev/Phase 4 Summary per Agent Conventions documentation loop

Acceptance criteria:

  • Landing page → signup → dashboard flow works
  • Wiki creation, MCP connection, note writing all work
  • Git clone of wiki repo succeeds
  • Collaborator invitation and access works
  • Rate limiting doesn't block normal usage
  • Monitoring dashboard shows the test traffic
  • Backup has run at least once
  • No security warnings in WAF logs from legitimate traffic

P4-8: Pre-Launch Security Review

Parallel group: Phase 4 (after P4-7, before launch) Dependencies: P4-7 (E2E test — system must be functionally complete first) Target: wikibot-io repo, feat/P4-8-security

Description: Structured security review of the full attack surface before opening to users. Not a third-party pentest — a systematic walkthrough of auth, access control, input validation, infrastructure config, and data exposure. The full checklist is in Tasks/Launch_Checklist under "Security Review."

This is a gate: launch does not proceed until all security checklist items pass.

Deliverables:

  • Security review results documented (Dev/P4-8_Security_Review)
  • Any vulnerabilities found are filed as issues and fixed
  • All items in Launch_Checklist "Security Review" section checked off

Acceptance criteria:

  • All auth/access control checks pass (tenant isolation, token handling, ACL enforcement)
  • All input validation checks pass (path traversal, XSS, injection, MCP fuzzing)
  • All infrastructure checks pass (secrets management, EFS isolation, HTTPS, CORS, rate limiting)
  • All data exposure checks pass (error responses, git isolation, search scoping, cache isolation)
  • No unresolved high-severity findings