01 - Overview
Relevant source files
This document introduces godeep.wiki: its purpose, what it is and what it is not, its architectural philosophy, and the key system components. For detailed information about specific subsystems, see System Architecture, User Journey, Authentication & GitHub Integration, and other specialized pages.
Purpose and ScopeLink copied!
godeep.wiki is a repository access provisioning system built with Next.js 14 that enables a manual documentation generation workflow. Users pay $10 via Stripe and grant temporary access to their private GitHub repository through a GitHub App installation. The owner has automation in place to generate documentation using external AI tools and deliver it via email within 1-9 hours.
Critical Distinction: This is NOT an automated documentation generator. The system automates payment processing and repository access provisioning, but documentation generation and delivery are entirely manual processes performed by the repository owner.
Sources: CLAUDE.md L1-L9
What godeep.wiki IsLink copied!
godeep.wiki is a payment-gated repository access system that orchestrates the following automated processes:
- Payment Processing - Stripe checkout session creation via
createCheckoutSession()server action - GitHub App Installation - OAuth flow that grants repository access permissions
- Session Correlation - Cookie-based linkage of
session_id(from Stripe) toinstallation_id(from GitHub) - Event Notification - ntfy.sh message broker integration for triggering automation scripts
- Repository Cloning - Automated scripts that clone customer repositories to owner's GitHub account
The system provides the infrastructure for a service business model where the owner manually generates and delivers documentation to paying customers.
Sources: CLAUDE.md L6-L9
(createCheckoutSession), app/api/auth/github/route.ts
app/api/auth/github/callback/route.ts
What godeep.wiki Is NOTLink copied!
godeep.wiki does not:
- Automatically generate documentation from code
- Use AI/LLM models to analyze repositories (this happens externally via Devin)
- Automatically email documentation to customers
- Provide real-time documentation generation
- Include a database for tracking orders or state
- Automate the complete end-to-end workflow
The automation ends at repository cloning. The owner must:
- Manually access the cloned repository
- Manually run external tools (Devin + Chrome extension) to generate documentation
- Manually email the ZIP file to the customer
This manual workflow is reflected in the UI messaging: "Delivered within 1-9 hours" app/success/page.tsx L29
Sources: CLAUDE.md L9
app/thank-you/page.tsx L17-L19
Architectural PhilosophyLink copied!
The system architecture prioritizes simplicity over scalability with the following design decisions:
No Database ArchitectureLink copied!
The system operates entirely without a database. State correlation happens through:
- Cookies - Temporary session state during OAuth flow (
github_oauth_state,stripe_session_id) - Vercel Logs - Permanent record of
session_idtoinstallation_idmappings - Stripe Dashboard - Payment records with customer email
- ntfy.sh - Event notifications with embedded context
This stateless design works for low-volume operations but requires manual log inspection for order fulfillment.
Sources: CLAUDE.md L44-L50
app/api/auth/github/callback/route.ts L55-L75
Event-Driven AutomationLink copied!
The system uses ntfy.sh as a message broker to decouple payment events from repository processing:
Stripe webhook → ntfy.sh → automation scripts → repository cloning
GitHub callback → ntfy.sh → automation scripts → repository cloning
This asynchronous design allows automation scripts to run on separate infrastructure (local machine or remote server) without coupling to the Next.js deployment.
Sources: app/api/webhooks/stripe/route.ts
Dual Authentication ModelLink copied!
The system implements two separate authentication mechanisms:
| Authentication Type | Token Type | Lifespan | Purpose | Used By |
|---|---|---|---|---|
| User OAuth | User access token | 24 hours | Dashboard access to own repos | Customer |
| GitHub App Installation | Installation access token | 1 hour | Access to customer's shared repos | Owner |
This separation ensures customers never gain owner privileges and the owner never uses customer credentials.
Sources: CLAUDE.md L68-L80
Technology StackLink copied!
Frontend LayerLink copied!
- Next.js 14 - App Router with Server Components
- TypeScript - Full type safety
- Tailwind CSS - Utility-first styling with custom oklch color system
- shadcn/ui + Radix UI - Component library
- Lucide React - Icon system
Sources: app/layout.tsx L1-L45
Backend LayerLink copied!
- Next.js API Routes - RESTful endpoints for OAuth, webhooks, admin functions
- Server Actions - Type-safe mutations (e.g.,
createCheckoutSession) - Vercel Edge Functions - Serverless deployment
Sources: app/api/
External ServicesLink copied!
- Stripe - Payment processing and checkout sessions
- GitHub API - OAuth authentication and repository access
- GitHub App - Installation-scoped permissions
- ntfy.sh - Message broker for event notifications
- Cloudflare Analytics - Optional web analytics
Sources: app/api/webhooks/stripe/route.ts
System Workflow DiagramLink copied!
Complete End-to-End Flow with Code Entities
Sources: app/page.tsx L62-L66
app/api/auth/github/callback/route.ts L55-L75
app/api/webhooks/stripe/route.ts
app/api/admin/generate-token/route.ts
Component Architecture with Code EntitiesLink copied!
System Components and Their Implementation
Sources: app/page.tsx
app/api/auth/github/callback/route.ts
app/api/webhooks/stripe/route.ts
app/api/webhooks/github/route.ts
app/api/admin/generate-token/route.ts
ntfy-godeep-automation-remote.sh
Key Files and Their RolesLink copied!
| File Path | Primary Responsibility | Key Exports/Routes |
|---|---|---|
| app/page.tsx | Landing page UI and payment CTA | React component with createCheckoutSession form |
| app/actions.ts | Server actions for mutations | createCheckoutSession() |
| app/api/auth/github/route.ts | OAuth flow initiation | GET handler, sets cookies, redirects to GitHub |
| app/api/auth/github/callback/route.ts L1-L100 | OAuth callback, session correlation | GET handler, logs session_id + installation_id |
| app/api/webhooks/stripe/route.ts | Stripe event processing | POST handler, verifies signatures, notifies ntfy.sh |
| app/api/admin/generate-token/route.ts | Installation token generation | POST handler, returns token + repo list |
| lib/github-app.ts | GitHub App authentication | githubApp, getInstallationAccessToken(), getInstallationRepositories() |
| lib/stripe.ts | Stripe SDK initialization | stripe (server-only) |
| ntfy-godeep-automation.sh | Repository cloning automation | Bash script, git operations, GitHub CLI |
Sources: File paths as cited in table
Session Correlation MechanismLink copied!
The system's critical challenge is linking payment (session_id from Stripe) to repository access (installation_id from GitHub) without a database. This is solved through a cookie-based handoff:
- Success Page app/success/page.tsx L29 - Receives
session_idfrom Stripe redirect - GitHub OAuth Link - Embeds
session_idas query parameter:/api/auth/github?session_id=xxx - OAuth Initiation app/api/auth/github/route.ts - Stores
session_idinstripe_session_idcookie (1-hour expiry) - OAuth Callback app/api/auth/github/callback/route.ts L55-L75 - Retrieves
session_idfrom cookie, receivesinstallation_idfrom GitHub, logs both together - Vercel Logs - Permanent record:
"Stripe Session: xxx, Installation ID: xxx, Username: xxx, Email: xxx"
The owner manually correlates session_id from Stripe Dashboard with logged installation_id to fulfill orders.
Sources: app/success/page.tsx L29
app/api/auth/github/route.ts L20-L30
app/api/auth/github/callback/route.ts L55-L75
Manual Workflow ComponentsLink copied!
The following steps are not automated and require owner intervention:
- Log Inspection - Check Vercel logs to find
installation_idfor a givensession_id - Token Generation - Use admin panel at
/adminto generate installation access token - Repository Access - Manually access cloned repository via git or GitHub API
- Documentation Generation - Run external tools (Devin with Chrome extension) to create DeepWiki
- Email Delivery - Manually send ZIP file to customer email (from Stripe Dashboard)
The system provides the infrastructure (payment, access, automation) but the value delivery (documentation) is manual. This is a conscious design choice for a low-volume, high-touch service business.
Sources: CLAUDE.md L5-L9
app/api/admin/generate-token/route.ts
Security Model OverviewLink copied!
The system implements multiple security layers:
- OAuth State Parameter - CSRF protection using
crypto.randomUUID()app/api/auth/github/route.ts L15 - HTTP-Only Cookies - XSS mitigation, tokens not accessible to JavaScript app/api/auth/github/route.ts L20-L30
- Webhook Signature Verification - Stripe and GitHub webhook authenticity app/api/webhooks/stripe/route.ts L10-L20
- Read-Only Permissions - GitHub App limited to Contents:Read, Metadata:Read
- 1-Hour Token Expiry - Installation tokens expire quickly to minimize exposure window
- Admin Password - Simple password protection for
/adminpanel (stored inNEXT_PUBLIC_ADMIN_PASSWORD)
Notable Security Consideration: The admin password is exposed to the client-side code (NEXT_PUBLIC_ prefix) app/admin/page.tsx
suggesting a simplified security model suitable for single-owner operation rather than multi-tenant access.
Sources: app/api/auth/github/route.ts L10-L30
app/api/webhooks/stripe/route.ts
Refresh this wiki
Last indexed: 23 November 2025 (922b35)
On this page
- Overview
- Purpose and Scope
- What godeep.wiki Is
- What godeep.wiki Is NOT
- Architectural Philosophy
- No Database Architecture
- Event-Driven Automation
- Dual Authentication Model
- Technology Stack
- Frontend Layer
- Backend Layer
- External Services
- System Workflow Diagram
- Component Architecture with Code Entities
- Key Files and Their Roles
- Session Correlation Mechanism
- Manual Workflow Components
- Security Model Overview
Ask Devin about godeep.wiki-jb