DeepWiki

06.c - Manual-Repository-Access-Workflow

Relevant source files

This document describes the manual workflow the repository owner follows to access customer repositories and generate documentation after a customer has paid and connected their GitHub account. This is the operational procedure that occurs after payment processing and GitHub App installation are complete.

For technical details on the token generation API, see Installation Token Generation API. For authentication mechanisms, see Admin Authentication. For information on how customers reach this point in the flow, see User Journey and GitHub App Installation Flow.

Key Insight: This system does NOT automate documentation generation. The automation ends at repository cloning. Documentation generation is a manual process using external tools (Devin + Chrome extension), followed by manual email delivery to the customer.

The owner's workflow consists of five manual steps to fulfill a customer order:

Sources: CLAUDE.md L33-L42

app/admin/page.tsx L1-L364

scripts/README.md L36-L51

The first manual step is identifying which GitHub installation corresponds to a specific payment. This requires correlating the session_id from Stripe with the installation_id logged by the OAuth callback.

Data SourceContainsAccess Method
Stripe Dashboardsession_id, customer email, payment amount, timestamphttps://dashboard.stripe.com/payments
Vercel Logssession_id, installation_id, GitHub username, email, timestampVercel dashboard function logs for /api/auth/github/callback
ntfy Notificationsinstallation_id, truncated session_id (last 12 chars)ntfy.sh topic logs

Sources: CLAUDE.md L44-L50

app/admin/page.tsx L159-L189

Example Log Entry FormatLink copied!

The OAuth callback logs entries in this format:

GitHub App installed:
- Installation ID: 12345678
- Session ID: cs_test_a1b2c3d4e5f6g7h8
- Username: customer-username
- Email: customer@example.com
- Name: Customer Name

The owner searches Vercel logs for the session_id from Stripe to find the corresponding installation_id.

Sources: CLAUDE.md L63-L65

Once the installation_id is identified, the owner uses the admin panel to generate a short-lived installation access token.

The admin panel at admin

provides a form-based interface for token generation:

Sources: app/admin/page.tsx L152-L215

The admin form requires two pieces of information:

FieldRequiredPurposeSource
installationIdYesGitHub App installation identifierVercel logs correlation from Step 1
customerEmailNoUsed to name the cloned repository (email-reponame)Stripe customer email or Vercel logs

Implementation: app/admin/page.tsx L166-L204

The API returns a response containing:

{  token: string           // Installation access token (1-hour expiry)  expiresAt: string      // ISO 8601 timestamp  repositories: Array<{  // Accessible repositories    id: number    name: string    full_name: string    description: string | null  }>  user: {                // Customer GitHub account info    username: string    email: string | null    name: string | null  }}

Sources: app/admin/page.tsx L18-L27

The optional customerEmail field enables automatic repository naming using the formatRepoName() function:

  • Input: customerEmail = "john.doe@example.com", repoName = "my-project"
  • Output: john_doe_example_com-my-project

This naming convention prevents collisions when cloning multiple customer repositories to the owner's personal GitHub account.

Implementation: app/admin/page.tsx L91-L98

Sources: app/admin/page.tsx L91-L98

scripts/README.md L28-L31

The admin panel displays multiple methods for accessing customer repositories using the generated installation token. All methods are valid for the 1-hour token lifespan.

Sources: app/admin/page.tsx L248-L297

For temporary access to inspect or process the repository immediately:

git clone https://x-access-token:TOKEN@github.com/OWNER/REPO.git

Displayed in UI: app/admin/page.tsx L256-L258

Use Case: Quick repository inspection, temporary processing

Limitation: Token expires in 1 hour, so cloned repository becomes inaccessible for further operations

For programmatic access without cloning:

curl -H "Authorization: token TOKEN" \  https://api.github.com/repos/OWNER/REPO

Displayed in UI: app/admin/page.tsx L262-L264

Use Case: Metadata extraction, automated repository analysis, CI/CD pipelines

The recommended workflow for documentation generation creates a permanent private mirror:

git clone https://x-access-token:TOKEN@github.com/OWNER/REPO.git temp-repo && \cd temp-repo && \rm -rf .git && \git init && \git add . && \git commit -m "Initial commit" && \gh repo create klaudioz/EMAIL-REPONAME --private --source=. --push

Displayed in UI: app/admin/page.tsx L269-L275

Requirements:

  • GitHub CLI (gh) installed and authenticated
  • Authentication to klaudioz GitHub account

Result: Private repository created at github.com/klaudioz/customer_email-reponame with all customer code

Sources: app/admin/page.tsx L266-L294

scripts/README.md L28-L31

The admin panel displays all accessible repositories with quick-copy buttons for each access method:

Implementation: app/admin/page.tsx L302-L356

Each button copies the complete command to the clipboard for immediate execution.

Sources: app/admin/page.tsx L302-L356

After cloning the repository to a personal account, the owner manually generates documentation using external tools. This is the critical manual step that is NOT automated by the system.

The documentation generation process uses:

ToolPurposeAccess Location
DevinAI-powered code analysis and documentation generationExternal service (not part of this codebase)
Chrome ExtensionInterface for Devin interactionBrowser extension (not part of this codebase)

Note: These tools are mentioned in operational documentation but are completely external to the godeep.wiki system.

Sources: CLAUDE.md L7-L9

scripts/README.md L50

Sources: CLAUDE.md L7-L9

The system UI sets customer expectations for a 1-9 hour delivery window. This accounts for:

  • Manual correlation of payment to installation (~5-10 minutes)
  • Token generation and repository cloning (~2-5 minutes)
  • Manual documentation generation (majority of time)
  • Quality review and packaging
  • Email composition and delivery

Sources: CLAUDE.md L42

The final step is manually emailing the generated documentation to the customer.

The customer's email address can be found in multiple locations:

SourceLocationData Format
Stripe DashboardPayment details for session_idcustomer_email field
Vercel LogsOAuth callback log entryLogged alongside installation_id
Token API ResponsetokenData.user.emailReturned by /api/admin/generate-token

Admin Panel Display: app/admin/page.tsx L224-L227

There is no automated email sending in this system. The owner must:

  1. Manually compose the email
  2. Attach the generated ZIP file
  3. Send from their personal email client

This manual step ensures quality control and allows for personalized customer communication.

Sources: CLAUDE.md L7-L9

CLAUDE.md L42

While documentation generation remains manual, repository cloning can be automated using the provided scripts in the scripts/ directory.

The automation scripts handle Steps 2-3 (token generation and repository cloning) but do NOT automate Step 4 (documentation generation) or Step 5 (email delivery).

Sources: scripts/README.md L1-L63

ScriptPurposeAutomation Level
ntfy-godeep-automation.shListen for ntfy notifications, auto-clone reposFully automated cloning
ntfy-godeep-automation-remote.shRemote variant for server deploymentFully automated cloning

Both scripts automatically:

  • Extract installation_id from ntfy notifications
  • Call /api/admin/generate-token with ADMIN_PASSWORD from .env
  • Clone customer repository
  • Create private mirror at github.com/klaudioz/customer_email-reponame
  • Display macOS notifications for progress tracking

Documentation: scripts/README.md L23-L48

Scripts are beneficial when:

  • Processing multiple customer orders
  • Reducing time spent on manual cloning
  • Ensuring consistent repository naming
  • Minimizing token expiration risks (1-hour window)

Scripts do NOT help with:

  • Documentation generation (still manual)
  • Quality review (still manual)
  • Email delivery (still manual)

Sources: scripts/README.md L1-L80

This system is fundamentally a repository access provisioning tool, not an automated documentation generator. The workflow automation stops at repository cloning. The core value proposition—documentation generation—remains a manual process.

StageAutomation StatusTime Required
Payment processingAutomated (Stripe)Instant
GitHub App installationSemi-automated (user-initiated)1-2 minutes
Payment-to-installation correlationManual (log searching)5-10 minutes
Token generationManual (admin panel) OR Automated (scripts)1-2 minutes
Repository cloningManual (git commands) OR Automated (scripts)2-5 minutes
Documentation generationManual (Devin + Chrome)Variable (majority of time)
Quality reviewManualVariable
Email deliveryManual2-5 minutes

The 1-9 hour delivery window is primarily driven by the manual documentation generation step, not system latency or automation delays.

Sources: CLAUDE.md L7-L9

CLAUDE.md L32-L42

Refresh this wiki

Last indexed: 23 November 2025 (922b35)

On this page

Ask Devin about godeep.wiki-jb

Syntax error in text

mermaid version 11.4.1

06.c - Manual-Repository-Access-Workflow | DeepWiki | godeep.wiki