PDD-CLI Bug: Assumes OOP Patterns When Codebase Uses Functional Patterns

[jiaminc-cmu]

PDD-CLI Bug: Assumes OOP Patterns When Codebase Uses Functional Patterns

PDD-CLI generates class-based imports and method calls when the target module uses functional/procedural patterns. This causes import errors because assumed classes don't exist.

Why this matters: Code fails with "cannot import name" errors because PDD tries to import classes that were never defined.

Concrete Example

Imagine a module that uses functional patterns:

# integrations/github.py
def get_github_client(token: str):
    """Returns configured GitHub client."""
    return github.Github(token)

def list_repositories(client):
    """Lists all repositories."""
    return client.get_user().get_repos()

When PDD-CLI generates code to use this module:

# PDD generated this (WRONG):
from integrations.github import GitHubClient  # ← Class doesn't exist

client = GitHubClient()
repos = client.list_repositories()

# Should have generated (CORRECT):
from integrations.github import get_github_client, list_repositories

client = get_github_client(token)
repos = list_repositories(client)

What went wrong: PDD saw "GitHub integration" and assumed there must be a GitHubClient class with methods. But the module uses functions, not classes.

Impact: ImportError: cannot import name 'GitHubClient'

Why PDD Makes This Mistake

PDD-CLI currently:

• Assumes OOP is the default pattern
• Generates class-based imports for "managers," "clients," "handlers"
• Expects state encapsulation in objects

But it doesn't:

1. Detect whether modules use OOP or functional style
2. Parse module structure before generating imports
3. Adapt to existing patterns

How to Prevent This in PDD-CLI

What PDD should do differently:

1. Detect module architecture: Parse target module to identify classes vs functions.

2. Match existing style: If module exports only functions, generate functional code. If it exports classes, generate OOP code.

3. Parse before generating: Always check what's actually exported.

Example improvement:

Current: "GitHub integration" → assume GitHubClient class

Improved: "GitHub integration" → parse integrations/github.py:
  - get_github_client() (function)
  - list_repositories() (function)
  - No class definitions found
→ Generate functional imports

Severity

P1 - High Priority

• Frequency: Medium - depends on codebase architecture
• Impact: Immediate import failures
• Detectability: High - clear error messages
• Prevention cost: Low - module parsing is straightforward

Category

schema-validation

Related Issues

• Generated tests use fragile try/except ImportError pattern for mocking #413 - Function calls without checking exports (same root cause)
• Add failing tests for issue #392: pdd change KeyError at Step 5 #433 - Handlers not wired up (similar architectural misunderstanding)

---

For Contributors: Discovered in backend/functions/crm_github.py, fixed in commit 34a651d5.

[jiaminc-cmu]

Closing: These issues were created from a private test case and contain too much context-specific information for open source contributors. They will be refined and reopened with clearer, more actionable descriptions.