From fe4b03e5d8f249f50f26181c2f8ac305b2bf576c Mon Sep 17 00:00:00 2001 From: faizm10 Date: Tue, 16 Dec 2025 00:38:58 -0500 Subject: [PATCH] live unit testings --- web/lib/gemini/pr-advice.ts | 126 ++++++- web/lib/gemini/prompts.ts | 709 +++++++++++------------------------- web/test/live-test.ts | 83 +++-- 3 files changed, 393 insertions(+), 525 deletions(-) diff --git a/web/lib/gemini/pr-advice.ts b/web/lib/gemini/pr-advice.ts index 2a34676..e49c486 100644 --- a/web/lib/gemini/pr-advice.ts +++ b/web/lib/gemini/pr-advice.ts @@ -13,17 +13,18 @@ export type PRFileForGemini = { } export type GeminiPRAnalysis = { - zones: RepoZone[] - events: string[] - obligations: string[] - docsTouched: boolean - docFilesTouched: string[] - missingDocs: string[] - shouldWarn: boolean - reasoning: string - summary: string - comment: string - fileSummaries: Array<{ + // Legacy fields (for backward compatibility) + zones?: RepoZone[] + events?: string[] + obligations?: string[] + docsTouched?: boolean + docFilesTouched?: string[] + missingDocs?: string[] + shouldWarn?: boolean + reasoning?: string + summary?: string + comment?: string + fileSummaries?: Array<{ path: string status?: 'added' | 'modified' | 'removed' | 'renamed' changeMagnitude?: 'minor' | 'moderate' | 'significant' @@ -32,6 +33,93 @@ export type GeminiPRAnalysis = { }> tone?: string confidence?: 'high' | 'medium' | 'low' + + // New comprehensive structure + executiveSummary?: string + category?: 'feature' | 'refactor' | 'bugfix' | 'performance' | 'security' | 'infrastructure' | 'chore' + whatChanged?: { + headline: string + details: string[] + } + technicalApproach?: { + overview: string + designPatterns: string[] + libraries: Array<{ + name: string + version?: string + purpose: string + }> + architecture?: string + } + implementationDetails?: { + configuration: string[] + dataFlow: string + entryPoints: string[] + integration: string[] + storage: string[] + } + fileBreakdown?: Array<{ + path: string + purpose: string + keyComponents: string[] + complexity: 'low' | 'medium' | 'high' | 'very-high' + importance: 'low' | 'medium' | 'high' | 'critical' + }> + keyInsights?: string[] + developerImpact?: { + newAPIs: Array<{ + name: string + location: string + usage: string + description: string + }> + breakingChanges?: string[] + migrationSteps?: string[] + } + setupRequirements?: { + environmentVariables: Array<{ + name: string + required: boolean + default?: string + description: string + }> + dependencies?: string[] + infrastructure?: string[] + commands?: string[] + } + qualityAssessment?: { + strengths: string[] + concerns: string[] + testCoverage: { + status: 'excellent' | 'good' | 'partial' | 'minimal' | 'none' + details: string + } + security: { + considerations: string[] + risks: string[] + } + } + documentation?: { + docsUpdated: boolean + quality: 'excellent' | 'good' | 'adequate' | 'poor' | 'missing' + suggestions: string[] + inlineComments?: string + } + recommendations?: { + beforeMerge: string[] + afterMerge: string[] + teamCommunication: string[] + } + prComment?: { + tone: 'positive' | 'neutral' | 'concerned' + message: string + } + metadata?: { + confidence: 'high' | 'medium' | 'low' + complexity: 'low' | 'medium' | 'high' | 'very-high' + impactScope: 'isolated' | 'moderate' | 'widespread' | 'critical' + estimatedReviewTime?: string + } } type PromptOptions = { @@ -246,6 +334,7 @@ export async function analyzePullRequestWithGemini( const parsed = extractJsonResponse(text) as Partial return { + // Legacy fields (for backward compatibility) zones: parsed.zones ?? [], events: parsed.events ?? [], obligations: parsed.obligations ?? [], @@ -259,6 +348,21 @@ export async function analyzePullRequestWithGemini( fileSummaries: parsed.fileSummaries ?? [], tone: parsed.tone, confidence: parsed.confidence, + // New comprehensive structure + executiveSummary: parsed.executiveSummary, + category: parsed.category, + whatChanged: parsed.whatChanged, + technicalApproach: parsed.technicalApproach, + implementationDetails: parsed.implementationDetails, + fileBreakdown: parsed.fileBreakdown, + keyInsights: parsed.keyInsights, + developerImpact: parsed.developerImpact, + setupRequirements: parsed.setupRequirements, + qualityAssessment: parsed.qualityAssessment, + documentation: parsed.documentation, + recommendations: parsed.recommendations, + prComment: parsed.prComment, + metadata: parsed.metadata, } } diff --git a/web/lib/gemini/prompts.ts b/web/lib/gemini/prompts.ts index ba8f8f2..d30b9aa 100644 --- a/web/lib/gemini/prompts.ts +++ b/web/lib/gemini/prompts.ts @@ -98,521 +98,244 @@ export function buildPRAnalysisPrompt(options: { }): string { const { prTitle, prNumber, docFilesTouched, files, filesContext } = options - const docList = docFilesTouched.length - ? docFilesTouched.map((doc) => `- ${doc}`).join('\n') - : '- None' + return `You are an expert software architect and code reviewer analyzing Pull Request #${prNumber}: "${prTitle}" - const zonesList = Object.values(REPOSITORY_ZONES) - .map((zone, index) => `${index + 1}. ${zone.name} (${zone.description})`) - .join('\n') +Your mission: Deeply understand this PR and provide insights that would take a developer 30+ minutes to discover by manually reviewing the code. - const eventsList = DETECTABLE_EVENTS.join(', ') +# Complete Context - return ` -${CODEKEEPER_BASE_PROMPT} +## Files Changed (${files.length} files) +${filesContext} + +${docFilesTouched.length > 0 ? `\n## Documentation Modified\n${docFilesTouched.map(f => `- ${f}`).join('\n')}\n` : ''} -You are reviewing a GitHub pull request to detect documentation-impacting events and to help a **new engineer on the team** quickly understand the change. Think like a senior engineer writing onboarding notes. +# Analysis Instructions -You care about these zones: -${zonesList} +Conduct a comprehensive code review covering these dimensions: -For each pull request you must: -1. **Carefully analyze the file changes**: Read through each file's patch/diff in detail. Understand not just what lines changed, but what those changes mean functionally. Look for: - - New functions, classes, components, hooks, utilities, types, interfaces, enums and their purpose - - Modified logic and how behavior differs from before (compare old vs new behavior) - - Removed code and what functionality is no longer present - - Configuration changes and their runtime effects - - Dependencies and how files relate to each other - - Code patterns: Are there new patterns being introduced? (e.g., error handling patterns, async patterns, state management patterns) - - Architectural changes: Are there structural changes to how the code is organized? - - Performance implications: Are there optimizations or potential performance issues? - - Security considerations: Are there security improvements or concerns? - - Testing changes: Are tests added, modified, or removed? What do they cover? +## 1. High-Level Understanding +- What business problem does this solve? +- What user-facing or developer-facing feature is being added/changed? +- Is this a new feature, refactor, bug fix, performance improvement, or something else? -2. Identify the zones touched. +## 2. Technical Deep Dive +- What is the core technical approach? (architecture, design patterns, algorithms) +- Which libraries, frameworks, or external services are being used? +- What are the key technical decisions and why might they have been made? +- Are there any clever or non-obvious implementations worth noting? -3. Detect notable events (e.g., ${eventsList}). +## 3. Implementation Details (BE VERY SPECIFIC) +- WHERE exactly are things configured/stored? (exact file paths, database tables, env vars) +- HOW does data flow through the system? (request → middleware → handler → response) +- WHAT are the entry points and integration points? +- WHAT new dependencies were added and why? +- WHAT environment variables or configuration is needed? -4. Map each event to the documentation areas that usually need updates (${DOCUMENTATION_AREAS.join(', ')}, etc.). +## 4. Code Organization & Structure +- What new files/folders were created and what's their purpose? +- How is the code organized? (feature-based, layer-based, domain-driven?) +- Are there any new abstractions, utilities, or shared components? -5. Decide if documentation already covers the change by looking at the doc files that changed. +## 5. Side Effects & Implications +- Does this change affect other parts of the system? +- Are there migration requirements? (database, config, data) +- Does this introduce new external dependencies or services? +- Are there performance implications (better or worse)? +- Does this change deployment requirements? -6. Decide if Code Keeper should leave a reminder (meaningful events happened but matching docs were not updated). If docs are already updated, respond positively instead of warning. +## 6. Testing & Quality +- What types of tests were added? (unit, integration, e2e) +- What edge cases are being handled? +- Are there any obvious gaps in testing? -7. Craft a comprehensive, friendly Markdown comment tailored to this PR and repo. The comment should feel like a detailed "tour" for a new developer. Structure it with clear sections: +## 7. Security & Data Handling +- Are there any security considerations? (auth, validation, sanitization) +- How is sensitive data handled? +- Are there any new attack surfaces? - **Comment Structure (use proper Markdown formatting):** - - Start with: ## CodeKeeper (use a friendly greeting emoji if appropriate) - - - **## Overview** (2-3 sentences): High-level overview of what this PR accomplishes and why it matters. Set the context for the reader. - - - **## Key Changes** (bulleted list): A well-organized list of the most important changes, grouped by category: - * **New Features**: List new functionality added - * **Modifications**: List existing functionality that was changed - * **Infrastructure**: List infrastructure, deployment, or configuration changes - * **Database**: List schema or data-related changes - * **Other**: Any other significant changes - - - **## Detailed Explanation**: For significant changes, provide comprehensive explanations: - * For each major change, create a subsection (###) with the feature/component name - * Explain what the main new/changed functions do, with specific details about: - - Their behavior and purpose - - Parameters (names, types, required/optional, default values) - - Return values (type, structure, meaning) - - Error handling (what errors can occur, how they're handled) - - Side effects (what else happens when this runs) - * Mention where they live (file paths) and how they are called in the system (controllers, routes, jobs, event handlers, hooks, etc.) - * Explain the flow: How do these changes fit into the application's workflow? What triggers them? What happens next? What is the complete execution path? - * For UI components: explain what they render, what props they accept, what state they manage, and how users interact with them - * For API endpoints: explain the HTTP method, path, request/response formats, authentication requirements, and use cases - - - **## Database Changes** (if applicable): - * Create subsections for each significant change - * Describe new tables/columns, their data types, constraints, relationships, indexes, and how they are used in the application - * Explain any migration implications: what data transformations occur, what downtime might be needed, rollback procedures - * List any new queries or query modifications that are needed - - - **## Infrastructure/CI Changes** (if applicable): - * Create subsections for each type of change (Docker, CI/CD, environment, etc.) - * Describe what changed in how the app runs, deploys, or is configured - * List all new environment variables, their purposes, and default values - * Explain port changes, service changes, volume mounts, network configurations - * Describe deployment steps, build processes, or runtime requirements - * Explain any new dependencies or system requirements - - - **## Impact Analysis**: - * **New Capabilities**: What does this change enable? What can users/developers do now that they couldn't before? - * **Problems Solved**: What issues were addressed? What bugs were fixed? What limitations were removed? - * **Workflow Changes**: What workflows are affected? How do users/developers interact with these changes differently? - * **Breaking Changes**: Are there any breaking changes? What needs to be updated elsewhere? What migration steps are required? - * **Performance**: Are there any performance implications? Is it faster/slower? More/less memory usage? - * **Security**: Are there any security implications? New attack vectors? Security improvements? - - - **## Integration Points**: - * Explain how these changes connect to other parts of the codebase - * What files depend on these changes? List specific files and how they use the new/changed code - * What do these changes depend on? List dependencies and how they're used - * Are there any cross-cutting concerns? (logging, error handling, authentication, etc.) - * How do these changes affect the overall architecture? - - - **## Testing Notes** (if applicable): - * Are there new tests? What do they cover? - * Are there test modifications? What changed in the test suite? - * What should be tested manually? - - Write a comprehensive, well-structured comment (aim for 300-800 words) that gives a new developer everything they need to understand the PR without having to read the code themselves. Use proper Markdown formatting with headers (##, ###), bullet points, code formatting with backticks for file paths and function names, and emphasis where appropriate. +## 8. Developer Experience +- What do developers need to know to use this? +- Are there new APIs, hooks, utilities, or patterns? +- What's the learning curve? -8. **MANDATORY:** For every file listed below (added/modified/renamed), write a **comprehensive, detailed summary** of what changed in that file **from a new developer's perspective**. Populate \`fileSummaries\` with **exactly the same number of entries as there are files**. +## 9. Documentation Quality +- Were docs updated appropriately? +- What additional documentation would be helpful? +- Are there inline code comments explaining complex logic? - **CRITICAL REQUIREMENTS:** - - You MUST provide FULL, COMPLETE explanations for EVERY file. Do NOT truncate or cut off summaries mid-sentence. - - Do NOT use vague phrases like "introduces new logic", "highlights", "refactor", or "major changes" without explaining what that means. - - Every summary must be specific and descriptive, with complete sentences that fully explain the changes. - - NEVER end a summary with incomplete phrases like "Highlights: /** | import {" - always complete your thoughts. - - Each summary must be a complete, coherent explanation from start to finish. - - **EXPANDED FEEDBACK**: Each file summary must be comprehensive and detailed, providing extensive context and analysis. +# Response Format - **EXPANDED FILE ANALYSIS STRUCTURE:** - - For each file, analyze the patch/diff carefully and provide a complete, expanded explanation following this structure: - - **File purpose**: What this file is (route handler, React component, database migration, CI workflow, config file, utility function, etc.) and its role in the codebase. Be specific about the file's purpose. - - **Change description**: A detailed explanation of what was added, modified, or removed. Be specific about the actual changes made - name the functions, classes, variables, or logic that changed. Do NOT say "introduces new logic" - explain WHAT logic was introduced. - - **Functional impact**: What the changes accomplish - what new functionality is added, what behavior is modified, or what is removed. Explain the "why" behind the change when it's evident from context. Describe the actual behavior, not just that behavior changed. - - **Technical details** (REQUIRED for all files): - * For code files: - - Name ALL key functions, classes, endpoints, components, hooks, utilities, types, interfaces, enums that were added/modified - - For each function/class/component: explain what it does, its parameters (names, types, required/optional, default values), return values (type and meaning), side effects, error handling, async behavior - - For React components: explain props (names, types, required/optional), state management, lifecycle hooks used, rendering logic, event handlers - - For API routes/endpoints: explain HTTP method, path, request body structure, response structure, status codes, authentication/authorization requirements - - For hooks: explain what state/behavior they manage, what they return, when they're used, dependencies - - Analyze imports: what libraries/modules are imported, why they're needed, how they're used in the code - - Analyze exports: what is exported from this file (functions, classes, types, constants), how other files might use these exports - - Explain the data flow: how data moves through the functions, what transformations occur, what state changes happen - - Explain error handling: what errors can occur, how they're caught and handled, what error messages are returned - - Explain validation: what input validation is performed, what validation rules exist - - If it's a refactor: explain what was refactored, what the old structure was, what the new structure is, why the change was made, what benefits it provides - - For test files: explain what is being tested, what test cases exist, what mocking is used, what assertions are made - - For type definition files: explain what types/interfaces are defined, what they represent, how they're used - - For utility files: explain what utilities are provided, what problems they solve, how they're used across the codebase - * For database files: - - Explain ALL schema changes: new tables (with all columns and types), modified columns, indexes, constraints, foreign keys - - Migration effects: what SQL operations are performed, what data is affected - - How data structures are affected: what new relationships exist, what queries might need updating - - Name specific tables, columns, their data types, constraints, and default values - * For infrastructure files: - - Explain ALL changes to deployment, configuration, environment variables, ports, services, or runtime behavior - - Name specific config values, ports, services, volumes, networks - - Explain what each configuration option does and what effect it has - * For CI/workflow files: - - Explain what the workflow does, when it runs (triggers), and what actions it performs - - Name the specific jobs, steps, commands, and their purposes - - Explain the workflow's role in the development/deployment pipeline - * For config files: - - Explain what configuration options are set, what values they have, and what effect they have on the application - - List all config keys, their types, default values, and their purposes - - Explain how these settings affect runtime behavior, performance, or functionality - - If environment-specific: explain which environments use which values - - If new config was added: explain why it was needed and what it controls - * For test files: - - Explain what is being tested (which functions, components, or features) - - Describe the test cases: what scenarios are covered, what edge cases are tested - - Explain what mocking/stubbing is used and why - - Describe the test setup and teardown - - Explain what assertions are made and what they verify - * For style/CSS files: - - Explain what styling was added/modified - - Describe the design changes: colors, spacing, layout, responsive behavior - - Explain what components or elements are affected - - If using CSS-in-JS or styled-components: explain the styling approach - * For type definition files (.d.ts, types.ts): - - Explain what types, interfaces, or enums are defined - - Describe what these types represent and how they're used - - Explain any type relationships (extends, implements, unions, intersections) - - Describe how these types improve type safety - - **Context and relationships**: If the changes relate to other files or systems, mention those connections explicitly. Explain how this file integrates with or affects other parts of the codebase. - - **Write 8-15 COMPLETE sentences per file** that are comprehensive and help a new developer fully understand both what changed and what it means. Each sentence must be complete and the summary must end properly - NEVER truncate or cut off mid-sentence. Be descriptive and specific - avoid vague statements like: - - **EXPANDED FILE SUMMARY STRUCTURE (8-15 sentences minimum):** - - Each file summary MUST include ALL of the following sections in detail: - - a. **File Identification & Context** (2-3 sentences): - - What type of file is this? (route handler, React component, service class, utility function, database migration, CI workflow, config file, test file, type definition, etc.) - - What is its role in the codebase? Where does it fit in the application architecture? - - What is the file's relationship to the overall system? (e.g., "This is a Next.js API route handler that processes authentication requests") - - What layer does it belong to? (presentation, business logic, data access, infrastructure, etc.) - - b. **Change Overview & Scope** (2-3 sentences): - - What was added, modified, or removed at a high level? - - What is the scope of changes? (entire file is new, specific functions changed, entire class refactored, etc.) - - What percentage or portion of the file changed? (if modified, not new) - - What was the previous state? (if modified or removed, describe what existed before) - - c. **Detailed Change Description** (3-5 sentences): - - **Name ALL specific changes**: List every function, class, method, variable, constant, type, interface, enum, import, export, configuration value, route, endpoint, component, hook, utility, etc. that was added/modified/removed - - **For each named item**: Explain what it does, what it accepts (parameters with types), what it returns (return type and structure), what side effects it has, what errors it can throw, what validation it performs - - **For imports**: List what libraries/modules are imported, why they're needed, how they're used in the code, what functionality they provide - - **For exports**: List what is exported from this file (functions, classes, types, constants), how other files might use these exports, what API this file provides - - **For configuration**: List all config keys, their values, types, default values, purposes, and effects on runtime behavior - - **For refactors**: Explain what was refactored (specific functions/classes/patterns), what the old structure was (how it worked before), what the new structure is (how it works now), why the change was made (what problems it solves), what benefits it provides (maintainability, performance, readability, etc.) - - **For UI components**: Explain what the component renders, what props it accepts (names, types, required/optional, default values), what state it manages, what lifecycle hooks it uses, what event handlers it has, how users interact with it, what styling it uses - - **For API endpoints**: Explain the HTTP method, path/route, request body structure (fields, types, validation), response structure (status codes, body format), authentication/authorization requirements, error responses, use cases - - **For hooks**: Explain what state/behavior they manage, what they return (structure and types), when they're used, what dependencies they have, what side effects they cause - - **For services/utilities**: Explain what problems they solve, what operations they perform, what algorithms or patterns they use, how they're used across the codebase - - d. **Technical Implementation Details** (2-3 sentences): - - **How does it work?** Explain the implementation approach, algorithms, patterns, or techniques used - - **Data flow**: How does data move through the functions? What transformations occur? What state changes happen? What is the execution flow? - - **Async behavior**: Are there async operations? How are promises/async-await handled? What is the concurrency model? - - **Error handling**: What errors can occur? How are they caught and handled? What error messages are returned? What logging is performed? - - **Validation**: What input validation is performed? What validation rules exist? What happens when validation fails? - - **Performance**: Are there any performance considerations? (caching, memoization, optimization techniques, potential bottlenecks) - - **Security**: Are there any security considerations? (authentication, authorization, input sanitization, SQL injection prevention, XSS prevention, etc.) - - **Dependencies**: What libraries or frameworks are used? Why were they chosen? How are they integrated? - - e. **Integration Points & Relationships** (2-3 sentences): - - **Where is this file used?** List specific files that import or depend on this file, and how they use it - - **What does this file depend on?** List specific files this file imports, and what functionality it gets from them - - **How is it called/invoked?** (API endpoints, event handlers, scheduled jobs, React components, hooks, etc.) - - **What part of the application flow does it participate in?** Explain the complete execution path: what triggers it, what happens during execution, what happens after - - **Are there any cross-cutting concerns?** (logging, error handling, authentication, authorization, caching, etc.) - - **How does it affect the overall architecture?** Does it introduce new patterns? Does it change existing patterns? - - f. **Impact, Purpose & Benefits** (1-2 sentences): - - **Why does this change matter?** What problem does it solve? What issue or limitation does it address? - - **What new capability does it add?** What can users/developers do now that they couldn't before? - - **What behavior does it change?** How does the new behavior differ from the old? What workflows are affected? - - **What are the benefits?** (improved performance, better maintainability, enhanced security, better user experience, etc.) - - **Are there any trade-offs?** (increased complexity, additional dependencies, breaking changes, etc.) - - Be descriptive and specific - avoid vague statements like: - - ❌ "updated code" - - ❌ "made changes" - - ❌ "introduces new logic" - - ❌ "major refactor" - - ❌ "highlights: ..." - - ❌ "see - this gets off" - - Instead, use specific, detailed statements like: - - ✅ "This file is a new authentication utility module (lib/auth/token-validator.ts) that provides JWT token validation functionality. Added a new validateToken() function that checks JWT expiration by parsing the token payload using the jsonwebtoken library and comparing the exp claim to the current timestamp. The function accepts a token string parameter and returns a boolean value, throwing a TokenExpiredError if the token is invalid or expired. This function is called by the authentication middleware (lib/middleware/auth.ts) before processing requests to prevent expired tokens from being accepted. The implementation includes proper error handling for malformed tokens and network errors. This change improves security by ensuring only valid, non-expired tokens can access protected routes." - - ✅ "This file modifies the user registration service (services/UserService.ts) to include email verification in the registration flow. The UserService.register() method now includes a new step that sends a verification email using the EmailService.sendVerificationEmail() method after creating the user account. The changes set the user's email_verified field to false in the database until the user clicks the verification link sent to their email. The verification link contains a secure token that is validated when clicked, and upon successful verification, the email_verified field is updated to true. This is integrated with the existing user registration endpoint at POST /api/users/register and requires updates to the email service configuration. This improves security by ensuring only verified email addresses can access the account and reduces the risk of fake account creation." - - ✅ "This file is a new navigation configuration module (lib/config/navigation.ts) that centralizes route definitions for the application. The file was created by extracting route definitions from the main layout component (components/layout/MainLayout.tsx) into a separate configuration file. The new file exports a routes array containing route objects with path, name, component, and metadata properties. Each route object includes the route path (e.g., '/dashboard', '/settings'), a display name, the React component to render, and optional metadata like icon names and permission requirements. This centralizes route management and makes it easier to add or modify navigation items without touching the layout component. The layout component now imports this configuration and uses it to dynamically generate navigation menus. This refactoring improves maintainability and makes the navigation structure more declarative and easier to test." - - **For refactored files**: - - Explain what was refactored (specific functions, classes, modules, patterns) - - Describe the old structure: how was it organized before? What were the problems or limitations? - - Describe the new structure: how is it organized now? What improvements were made? - - Explain why the refactor was done: what problems does it solve? What benefits does it provide? - - Name the specific functions, classes, or patterns that changed - - Explain any breaking changes or migration needed - - **For new files**: - - Explain what new functionality this file introduces - - Describe what problems it solves or what gaps it fills - - Explain how it fits into the codebase architecture - - Describe its relationship to existing files (what it depends on, what depends on it) - - Explain the design decisions: why was this approach chosen? - - **For modified files**: - - Explain what changed from the previous version, not just what the file does now - - Compare the before and after states: what was the old behavior? What is the new behavior? - - Explain what functionality was added, removed, or modified - - Describe any breaking changes or backward compatibility concerns - - Explain why these changes were made - - **For removed files**: - - Explain what functionality is being removed - - Describe why it's being removed (deprecated, replaced, no longer needed) - - Explain what replaces it (if anything) - - Describe any migration needed for code that depended on this file - - **For renamed files**: - - Explain what the file was renamed from and to - - Explain why it was renamed (better naming, organizational changes, etc.) - - Describe any import path updates needed - - Explain if the functionality changed or if it's just a rename - - Include these summaries verbatim in the final comment under a "## File Snapshots" heading. Format each file summary as: - - ### [File Path] - **Status**: [added/modified/removed/renamed] - - [Full detailed summary here - 8-15 complete sentences following the expanded structure] - - After the detailed "## File Snapshots" section, you MUST also include a concise "## File snapshots" section (lowercase) that provides a quick reference summary. This section should be formatted as a simple list with one entry per file. Format each entry as: - - [Status]: [File Path] ([change magnitude]) — [One-line concise description of the key change] - - **IMPORTANT**: The concise section should use the exact format shown in the examples below. Do NOT use bullet points (-) or dashes, just plain lines without any list markers. - - Examples of the correct format: - Updated: web/app/dashboard/page.tsx (moderate change) — Imported { hasGitHubConnection } from @/lib/github/auth - Updated: web/app/dashboard/settings/page.tsx (moderate change) — Added method hasGitHub - Updated: web/components/dashboard/repository-onboarding.tsx (significant change) — Added interface RepositoryOnboardingProps - Updated: web/lib/github/auth.ts (significant change) — Added function isNetworkError - Updated: web/package-lock.json — package changes (added 0, updated 1, removed 0) - Updated: web/package.json (minor change) — Modified implementation - - The concise format rules: - - Use "Updated:" prefix for modified files, "Added:" for new files, "Removed:" for deleted files, "Renamed:" for renamed files - - Include change magnitude in parentheses: (minor change), (moderate change), or (significant change) - omit if not applicable (e.g., package-lock.json) - - Provide a one-line description focusing on the most important change (key function added, main import, primary modification, etc.) - - For package files, include package change summary if applicable (e.g., "package changes (added 0, updated 1, removed 0)") - - Use the conciseSummary field from fileSummaries for each file's description - - Keep descriptions brief and focused on the single most important change - - If a patch is truncated, binary, or lacks sufficient context, clearly state that limitation at the beginning of the summary but still provide as much detailed insight as possible from the available information, including: - - File structure and organization - - Imports and dependencies (what the file depends on) - - Exports (what the file provides) - - Visible code patterns and conventions - - File size and complexity indicators - - Any comments or documentation in the code - - File extension and type indicators +Provide your analysis as JSON with this structure: -Return JSON with this shape: +\`\`\`json { - "zones": string[], // zones touched (code, docs, infra, db, ci, config) - "events": string[], // detected event names - "obligations": string[], // doc areas that should be updated - "docsTouched": boolean, // true if relevant docs were edited - "docFilesTouched": string[], // subset of doc files that changed - "missingDocs": string[], // doc areas still missing - "shouldWarn": boolean, // true if Code Keeper should flag missing docs - "summary": string, // 2-3 sentence high-level summary for the PR comment opening - "reasoning": string, // detailed explanation of your decision and analysis - "tone": string, // short description of the tone you used - "comment": string, // comprehensive Markdown comment with clear sections (CodeKeeper header, overview, key changes, detailed explanations, database/infra changes, impact analysis, integration points, testing notes, File Snapshots with detailed summaries, File snapshots with concise summaries). Use proper Markdown formatting with headers (##, ###), bullet points, code formatting with backticks for file paths and function names, and emphasis. No code fences, do NOT include the comment marker. Make it detailed and informative - aim for 300-800 words minimum for the main comment. Structure it so a new developer can understand the entire PR without reading the code. MUST include both "## File Snapshots" (detailed) and "## File snapshots" (concise) sections. - "fileSummaries": [ - { - "path": string, - "status": "added"|"modified"|"removed"|"renamed", - "changeMagnitude": "minor"|"moderate"|"significant", // Assess the scope of changes - "summary": string, // 8-15 COMPLETE sentences with FULL, EXPANDED explanation following the detailed structure: file identification and context (2-3 sentences), change overview and scope (2-3 sentences), detailed change description naming ALL functions/classes/methods/variables/imports/exports/configs (3-5 sentences), technical implementation details including data flow, async behavior, error handling, validation, performance, security (2-3 sentences), integration points and relationships with other files (2-3 sentences), and impact/purpose/benefits (1-2 sentences). NO vague phrases like "introduces new logic" or "major refactor" without explaining what that means. MUST be complete - never truncate or cut off mid-sentence. Provide extensive context and analysis. - "conciseSummary": string // One-line concise description for the "File snapshots" section, e.g., "Imported { hasGitHubConnection } from @/lib/github/auth" or "Added function isNetworkError". Focus on the most important change. + "executiveSummary": "2-3 sentence overview of what this PR accomplishes and why it matters", + + "category": "feature|refactor|bugfix|performance|security|infrastructure|chore", + + "whatChanged": { + "headline": "One-line description (e.g., 'Added real-time collaboration using WebSockets')", + "details": [ + "Specific change 1 with context", + "Specific change 2 with context", + "Specific change 3 with context" + ] + }, + + "technicalApproach": { + "overview": "3-5 sentence explanation of the technical strategy and architecture", + "designPatterns": ["Pattern names used, e.g., 'Singleton', 'Observer', 'Factory'"], + "libraries": [ + { + "name": "socket.io", + "version": "4.5.0", + "purpose": "Real-time bidirectional communication" + } + ], + "architecture": "Brief description of architectural decisions" + }, + + "implementationDetails": { + "configuration": [ + "Exact location and purpose (e.g., 'WebSocket server configured in lib/socket/server.ts')", + "Environment variables with examples (e.g., 'SOCKET_PORT=3001 - Port for WebSocket server')" + ], + "dataFlow": "Step-by-step explanation of how data moves through the system", + "entryPoints": [ + "Main entry points into the new functionality (files and functions)" + ], + "integration": [ + "How this connects with existing code", + "What other components are affected" + ], + "storage": [ + "Where data is stored (database tables, Redis keys, file system, etc.)", + "Data structure and schema details" + ] + }, + + "fileBreakdown": [ + { + "path": "src/lib/socket/server.ts", + "purpose": "Detailed explanation of what this file does and why it exists", + "keyComponents": [ + "Main functions/classes and their responsibilities" + ], + "complexity": "low|medium|high", + "importance": "low|medium|high|critical" } ], - "confidence": "high" | "medium" | "low" + + "keyInsights": [ + "Non-obvious observations that would take time to discover", + "Clever implementations or optimizations", + "Potential gotchas or things to watch out for", + "Design decisions and their tradeoffs" + ], + + "developerImpact": { + "newAPIs": [ + { + "name": "useSocket(roomId)", + "location": "hooks/useSocket.ts", + "usage": "Example of how to use it", + "description": "What it does" + } + ], + "breakingChanges": [ + "Any breaking changes developers need to know about" + ], + "migrationSteps": [ + "Steps required to adopt this change" + ] + }, + + "setupRequirements": { + "environmentVariables": [ + { + "name": "SOCKET_PORT", + "required": true, + "default": "3001", + "description": "Port for WebSocket server" + } + ], + "dependencies": [ + "New packages that need to be installed" + ], + "infrastructure": [ + "New services or infrastructure needed (e.g., Redis, RabbitMQ)" + ], + "commands": [ + "New CLI commands or scripts available" + ] + }, + + "qualityAssessment": { + "strengths": [ + "What's done well in this PR", + "Good patterns or practices used" + ], + "concerns": [ + "Potential issues or areas for improvement", + "Missing error handling or edge cases" + ], + "testCoverage": { + "status": "excellent|good|partial|minimal|none", + "details": "What's tested and what's not" + }, + "security": { + "considerations": [ + "Security aspects that were addressed or need attention" + ], + "risks": [ + "Potential security concerns if any" + ] + } + }, + + "documentation": { + "docsUpdated": true, + "quality": "excellent|good|adequate|poor|missing", + "suggestions": [ + "Specific documentation that should be added/updated" + ], + "inlineComments": "Assessment of code comments" + }, + + "recommendations": { + "beforeMerge": [ + "Critical items that should be addressed before merging" + ], + "afterMerge": [ + "Follow-up work that can be done later" + ], + "teamCommunication": [ + "What should be communicated to the team" + ] + }, + + "prComment": { + "tone": "positive|neutral|concerned", + "message": "A thoughtful, constructive comment for the PR (3-5 sentences). Highlight what's impressive, note any concerns, and provide actionable feedback." + }, + + "metadata": { + "confidence": "high|medium|low", + "complexity": "low|medium|high|very-high", + "impactScope": "isolated|moderate|widespread|critical", + "estimatedReviewTime": "Quick scan, thorough review, or deep analysis needed" + } } +\`\`\` -Always fill every field completely. Use the event names described above when possible. +# Critical Success Factors -**Quality Checklist - Before finalizing your response, verify:** -- [ ] Every file has a complete, expanded summary (8-15 sentences minimum, no truncation) -- [ ] All summaries follow the expanded structure: identification, overview, detailed changes, technical details, integration, impact -- [ ] All summaries name ALL specific functions, classes, methods, variables, imports, exports, configs, or changes (no vague phrases) -- [ ] Each summary includes detailed technical implementation (data flow, async behavior, error handling, validation, performance, security) -- [ ] Each summary includes comprehensive integration points (where it's used, what it depends on, execution flow) -- [ ] Each file summary includes a changeMagnitude assessment (minor/moderate/significant) -- [ ] Each file summary includes a conciseSummary for the quick reference section -- [ ] The main comment is comprehensive (300-800 words) with all required sections -- [ ] All file summaries are included in the comment under "## File Snapshots" (detailed format) -- [ ] A concise "## File snapshots" section (lowercase) is included with quick reference summaries -- [ ] The concise section uses the format: "[Status]: [path] ([magnitude]) — [one-line description]" -- [ ] The comment uses proper Markdown formatting (headers, bullets, code formatting) -- [ ] All technical details are explained thoroughly (parameters with types, return values with structures, data flow, algorithms, etc.) -- [ ] Integration points are clearly described with specific file names and relationships -- [ ] Impact analysis covers capabilities, problems solved, workflows, breaking changes, benefits, and trade-offs -- [ ] No incomplete sentences or truncated explanations -- [ ] The response would help a new developer understand the PR completely without reading code -- [ ] Each file summary provides extensive context and analysis as if explaining to a new team member +1. **Be a Detective**: Look for patterns, connections, and non-obvious insights +2. **Think Like a User**: How does this affect end users and developers? +3. **Be Specific**: Always include exact file paths, function names, and configuration details +4. **Show Understanding**: Explain WHY decisions were made, not just WHAT changed +5. **Be Constructive**: Frame concerns as opportunities for improvement +6. **Add Value**: Surface insights that aren't obvious from reading the diff -PR Title: ${prTitle} -PR Number: ${prNumber} -Doc files touched: -${docList} - -All changed files (must summarize each one): -${files.map((file) => `- ${file.status.toUpperCase()}: ${file.path}`).join('\n')} - ---- - -**IMPORTANT: File Change Analysis** - -Below are the detailed file changes with patches/diffs. For each file: - -1. **Read the patch carefully**: Analyze the actual code changes line by line. Look at: - - Lines starting with + (additions) - what new code was added and why - - Lines starting with - (deletions) - what code was removed and what functionality is lost - - Context lines (unchanged code) - understand the surrounding code to see how changes fit in - - Function signatures, class definitions, imports, exports - understand the structure - - **Imports section**: Analyze what dependencies are imported - this tells you what the file depends on and what functionality it uses - - **Exports section**: Analyze what is exported - this tells you what this file provides to other parts of the codebase - - **Type definitions**: Look for TypeScript interfaces, types, enums - these define the data structures and contracts - - **Constants and configuration**: Identify any constants, config values, or environment variables used - -2. **Understand the intent**: Based on the changes, infer: - - What problem is being solved? What issue or limitation does this address? - - What new capability is being added? What can users/developers do now that they couldn't before? - - What behavior is being modified? How does the new behavior differ from the old? - - What dependencies or relationships are being created or removed? - - What is the overall theme or goal of this PR? How do all the file changes work together? - - Are there patterns across multiple files? (e.g., all files are adding error handling, or all are refactoring to use a new pattern) - - Is there a migration or transition happening? (e.g., moving from one library to another, changing architectural patterns) - - Are there cross-cutting concerns? (e.g., logging, error handling, authentication changes that affect multiple files) - - What is the user/developer impact? How does this change affect the end-user experience or developer workflow? - -3. **Provide comprehensive, structured summaries**: When writing file summaries, follow this EXPANDED structure and be extremely specific about: - - **EXPANDED Structure for each file summary (8-15 sentences minimum):** - - a. **File identification & context** (2-3 sentences): - - What type of file is this? (route handler, React component, service class, utility function, database migration, CI workflow, config file, test file, type definition, style file, etc.) - - What is its role in the codebase? Where does it fit in the application architecture? - - What layer does it belong to? (presentation layer, business logic layer, data access layer, infrastructure layer, etc.) - - What is the file's relationship to the overall system? (e.g., "This is a Next.js API route handler that processes authentication requests and integrates with Supabase") - - b. **Change overview & scope** (2-3 sentences): - - What was added, modified, or removed at a high level? - - What is the scope of changes? (entire file is new, specific functions changed, entire class refactored, specific methods modified, etc.) - - What percentage or portion of the file changed? (if modified, not new - estimate: small change, medium change, large refactor, complete rewrite) - - What was the previous state? (if modified or removed, describe what existed before - what functions/classes were there, how did they work) - - c. **Detailed change description** (3-5 sentences - THIS IS THE MOST IMPORTANT SECTION): - - **Name ALL specific changes**: List EVERY function, class, method, variable, constant, type, interface, enum, import, export, configuration value, route, endpoint, component, hook, utility, prop, state variable, event handler, lifecycle hook, etc. that was added/modified/removed - - **For each named function/class/method**: - * What does it do? (purpose and behavior) - * What parameters does it accept? (names, types, required/optional, default values, validation rules) - * What does it return? (return type, structure, meaning, possible values) - * What side effects does it have? (database writes, API calls, file operations, state changes, etc.) - * What errors can it throw? (error types, error messages, error handling) - * Is it async? (promises, async/await, callbacks) - - **For imports**: - * List what libraries/modules are imported (exact package names and versions if visible) - * Why are they needed? (what functionality do they provide) - * How are they used in the code? (specific usage examples from the diff) - * Are they new dependencies or existing ones? - - **For exports**: - * List what is exported from this file (functions, classes, types, constants, components, etc.) - * How might other files use these exports? (what API does this file provide) - * Are these exports new or modified? - - **For configuration files**: - * List ALL configuration keys, their values, types, default values, purposes - * What effect do they have on runtime behavior? (performance, security, functionality) - * Are they environment-specific? (dev, staging, prod) - * Are they new configs or modified existing ones? - - **For refactors**: - * Explain what was refactored (specific functions/classes/patterns/modules) - * Describe the old structure: how was it organized before? What were the problems or limitations? - * Describe the new structure: how is it organized now? What improvements were made? - * Why was the refactor done? (what problems does it solve - maintainability, performance, readability, testability, etc.) - * What benefits does it provide? (specific improvements) - - **For UI components**: - * What does the component render? (UI elements, layout, structure) - * What props does it accept? (names, types, required/optional, default values, validation) - * What state does it manage? (state variables, their types, initial values, how they change) - * What lifecycle hooks does it use? (useEffect, useState, useCallback, etc. and their purposes) - * What event handlers does it have? (onClick, onSubmit, onChange, etc. and what they do) - * How do users interact with it? (user flows, interactions) - * What styling does it use? (CSS classes, inline styles, CSS-in-JS, etc.) - - **For API endpoints/routes**: - * HTTP method (GET, POST, PUT, DELETE, PATCH, etc.) - * Path/route (exact URL pattern) - * Request body structure (fields, types, validation rules, required/optional fields) - * Response structure (status codes, body format, error responses) - * Authentication/authorization requirements (who can access this, what permissions are needed) - * Error responses (what errors can occur, what status codes, what error messages) - * Use cases (when is this endpoint called, what does it accomplish) - - **For hooks**: - * What state/behavior do they manage? (what do they track, what do they control) - * What do they return? (structure, types, values) - * When are they used? (in what components, under what conditions) - * What dependencies do they have? (what values trigger re-runs, what external dependencies) - * What side effects do they cause? (API calls, subscriptions, DOM updates, etc.) - - **For services/utilities**: - * What problems do they solve? (specific use cases) - * What operations do they perform? (data transformations, calculations, validations, etc.) - * What algorithms or patterns do they use? (sorting, filtering, caching, memoization, etc.) - * How are they used across the codebase? (which files import and use them) - - d. **Technical implementation details** (2-3 sentences): - - **How does it work?** Explain the implementation approach, algorithms, patterns, or techniques used - - **Data flow**: How does data move through the functions? What transformations occur? What state changes happen? What is the complete execution path from input to output? - - **Async behavior**: Are there async operations? How are promises/async-await handled? What is the concurrency model? Are there race conditions to consider? - - **Error handling**: What errors can occur? How are they caught and handled? What error messages are returned? What logging is performed? Are errors propagated or swallowed? - - **Validation**: What input validation is performed? What validation rules exist? What happens when validation fails? Are validation errors user-friendly? - - **Performance**: Are there any performance considerations? (caching strategies, memoization, optimization techniques, potential bottlenecks, memory usage, CPU usage) - - **Security**: Are there any security considerations? (authentication mechanisms, authorization checks, input sanitization, SQL injection prevention, XSS prevention, CSRF protection, rate limiting, etc.) - - **Dependencies**: What libraries or frameworks are used? Why were they chosen? How are they integrated? Are there version constraints? - - **Testing**: Are there tests? What do they cover? What testing approach is used? (unit tests, integration tests, etc.) - - e. **Integration points & relationships** (2-3 sentences): - - **Where is this file used?** List SPECIFIC files that import or depend on this file, and explain HOW they use it (what functions they call, what props they pass, etc.) - - **What does this file depend on?** List SPECIFIC files this file imports, and explain what functionality it gets from them (what functions it calls, what types it uses, etc.) - - **How is it called/invoked?** (API endpoints trigger it, event handlers call it, scheduled jobs run it, React components render it, hooks use it, etc.) - - **What part of the application flow does it participate in?** Explain the COMPLETE execution path: what triggers it (user action, API request, scheduled job, event, etc.), what happens during execution (step-by-step flow), what happens after (what is the result, what is the next step) - - **Are there any cross-cutting concerns?** (logging, error handling, authentication, authorization, caching, monitoring, etc.) - explain how this file participates in these - - **How does it affect the overall architecture?** Does it introduce new patterns? Does it change existing patterns? Does it affect other parts of the system? - - **What are the dependencies and dependents?** Create a clear picture of how this file fits into the dependency graph - - f. **Impact, purpose & benefits** (1-2 sentences): - - **Why does this change matter?** What problem does it solve? What issue or limitation does it address? What was the motivation? - - **What new capability does it add?** What can users/developers do now that they couldn't before? What functionality is enabled? - - **What behavior does it change?** How does the new behavior differ from the old? What workflows are affected? What user experiences change? - - **What are the benefits?** (improved performance, better maintainability, enhanced security, better user experience, reduced complexity, increased testability, etc.) - be specific - - **Are there any trade-offs?** (increased complexity, additional dependencies, breaking changes, migration effort, performance costs, etc.) - be honest about any downsides - - **What is the business value?** (if applicable - does it enable new features, improve reliability, reduce costs, etc.) - - **NEVER use vague phrases** like: - - "introduces new logic" (explain WHAT logic) - - "major refactor" (explain WHAT was refactored and HOW) - - "highlights" (explain the actual content) - - "see - this gets off" (explain what "this" is and what it does) - - "new functionality" (explain WHAT functionality) - - "updated code" (explain WHAT was updated) - - "improvements" (explain WHAT improvements) - - **ALWAYS provide full context**: Name specific functions, classes, variables, imports, exports, file paths, and explain what they do and how they work together. Include enough detail that a new developer can understand the change without reading the code. - -4. **For modified files**: Explain what changed from the previous version, not just what the file does now. - -5. **For added files**: Explain what new functionality this file introduces to the codebase. - -6. **For removed files**: Explain what functionality is being removed and why (if evident). - -Files changed with patches: -${filesContext} -` +Now analyze the PR with depth and precision.` } diff --git a/web/test/live-test.ts b/web/test/live-test.ts index d5d9413..eef158b 100755 --- a/web/test/live-test.ts +++ b/web/test/live-test.ts @@ -19,14 +19,29 @@ import { generateReadmeSuggestions } from '@/lib/gemini/readme-suggestions' import { classifyFile } from '@/lib/pr/file-classification' // Load environment variables from .env files -// Try .env.local first (highest priority), then .env +// Try multiple locations: web/.env.local, web/.env, root/.env.local, root/.env +const currentDir = process.cwd() +const isInWebDir = currentDir.endsWith('/web') || currentDir.endsWith('\\web') +const webDir = isInWebDir ? currentDir : resolve(currentDir, 'web') +const rootDir = isInWebDir ? resolve(currentDir, '..') : currentDir + const envPaths = [ - resolve(process.cwd(), '.env.local'), - resolve(process.cwd(), '.env'), + resolve(webDir, '.env.local'), + resolve(webDir, '.env'), + resolve(rootDir, '.env.local'), + resolve(rootDir, '.env'), ] +// Load each .env file (later ones override earlier ones) +// Note: override: false means don't override existing env vars, but load new ones for (const envPath of envPaths) { - config({ path: envPath }) + try { + const result = config({ path: envPath, override: false }) + // Values are automatically loaded into process.env + // result.parsed contains the loaded variables + } catch (error) { + // File doesn't exist or can't be read, that's okay - continue + } } type GitHubPRFile = { @@ -323,7 +338,7 @@ async function main() { let token: string | null = null // Check for token in .env file or environment variable - // Try common variable names + // Try common variable names (in order of preference) token = process.env.GITHUB_TOKEN || process.env.GH_TOKEN || process.env.GITHUB_ACCESS_TOKEN || @@ -331,12 +346,44 @@ async function main() { null if (token) { - const source = process.env.GITHUB_TOKEN ? '.env file or GITHUB_TOKEN variable' : - process.env.GH_TOKEN ? '.env file or GH_TOKEN variable' : - process.env.GITHUB_ACCESS_TOKEN ? '.env file or GITHUB_ACCESS_TOKEN variable' : - '.env file or GH_ACCESS_TOKEN variable' - console.log(`✅ Using GitHub token from ${source}\n`) + // Determine which variable was used + let varName = 'GITHUB_TOKEN' + if (process.env.GH_TOKEN && !process.env.GITHUB_TOKEN) varName = 'GH_TOKEN' + else if (process.env.GITHUB_ACCESS_TOKEN && !process.env.GITHUB_TOKEN && !process.env.GH_TOKEN) varName = 'GITHUB_ACCESS_TOKEN' + else if (process.env.GH_ACCESS_TOKEN && !process.env.GITHUB_TOKEN && !process.env.GH_TOKEN && !process.env.GITHUB_ACCESS_TOKEN) varName = 'GH_ACCESS_TOKEN' + + console.log(`✅ Using GitHub token from ${varName} (loaded from .env file or environment variable)\n`) } else { + // Debug: Show which .env files were checked and if they contain token + const fs = require('fs') + console.log('🔍 Debug: No token found. Checked .env files:') + let foundTokenInFile = false + for (const envPath of envPaths) { + const exists = fs.existsSync(envPath) + if (exists) { + try { + const content = fs.readFileSync(envPath, 'utf-8') + const hasToken = /^\s*(GITHUB_TOKEN|GH_TOKEN|GITHUB_ACCESS_TOKEN|GH_ACCESS_TOKEN)\s*=/.test(content) + if (hasToken) { + foundTokenInFile = true + console.log(` ⚠ ${envPath} (contains token but not loaded - check format)`) + } else { + console.log(` ✓ ${envPath} (exists but no token variable)`) + } + } catch { + console.log(` ✓ ${envPath} (exists)`) + } + } else { + console.log(` ✗ ${envPath} (not found)`) + } + } + if (foundTokenInFile) { + console.log('\n 💡 Token found in .env file but not loaded. Make sure the format is:') + console.log(' GITHUB_TOKEN=your-token-here') + console.log(' (No spaces around =, no quotes needed)\n') + } else { + console.log() + } console.log('🔑 GitHub authentication required') console.log(' Note: This tool needs a GitHub Personal Access Token') console.log(' You can:') @@ -369,18 +416,12 @@ async function main() { process.exit(1) } - // Get repository info - const repoInput = await question('Enter repository (owner/repo): ') - const [owner, repo] = repoInput.split('/').map(s => s.trim()) - - if (!owner || !repo) { - console.error('❌ Invalid repository format. Use: owner/repo') - console.log(' Example: faizm10/code-keeper') - process.exit(1) - } - - // Remove .git suffix if present + // Hardcoded repository + const owner = 'faizm10' + const repo = 'code-keeper' const cleanRepo = repo.replace(/\.git$/, '') + + console.log(`📦 Using repository: ${owner}/${cleanRepo}\n`) // Get PR number const prNumberInput = await question('Enter PR number: ')