|
| 1 | +# CLAUDE.md |
| 2 | + |
| 3 | +This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository. |
| 4 | + |
| 5 | +## Common Development Commands |
| 6 | + |
| 7 | +### Linting and Code Quality |
| 8 | +- **Run all linting checks**: `composer lint` (runs both PHPCS and PHPStan) |
| 9 | +- **Run PHP CodeSniffer**: `composer phpcs` |
| 10 | +- **Fix code style issues**: `composer phpcbf` |
| 11 | +- **Run PHPStan static analysis**: `composer phpstan` |
| 12 | + |
| 13 | +### Testing |
| 14 | +- **Run PHPUnit tests**: `composer phpunit` |
| 15 | + |
| 16 | +### Dependencies |
| 17 | +- **Install dependencies**: `composer install` |
| 18 | +- **Update dependencies**: `composer update` |
| 19 | + |
| 20 | +## High-level Architecture |
| 21 | + |
| 22 | +This project is a PHP AI Client SDK designed to provide a provider-agnostic API for interacting with various generative AI models. The architecture has several key design principles: |
| 23 | + |
| 24 | +### API Layers |
| 25 | + |
| 26 | +1. **Implementer API**: For developers using the SDK to add AI features to their applications |
| 27 | + - Fluent API: Chain methods for readable, declarative code (e.g., `AiClient::prompt('...')->generateText()`) |
| 28 | + - Traditional API: Method-based approach with arrays of arguments |
| 29 | + |
| 30 | +2. **Extender API**: For developers adding new providers, models, or extending functionality |
| 31 | + - Provider Registry system for managing available AI providers |
| 32 | + - Model discovery based on capabilities and requirements |
| 33 | + |
| 34 | +### Core Concepts |
| 35 | + |
| 36 | +- **Provider Agnostic**: Abstracts away provider-specific details, allowing code to work with any AI provider (Google, OpenAI, Anthropic, etc.) |
| 37 | +- **Capability-Based Model Selection**: Models can be discovered and selected based on their supported capabilities (text generation, image generation, etc.) and options (input modalities, output formats, etc.) |
| 38 | +- **Uniform Data Structures**: Consistent message formats, file representations, and results across all providers |
| 39 | +- **Modality Support**: Designed to support arbitrary combinations of input/output modalities (text, image, audio, video) |
| 40 | + |
| 41 | +### Namespace Structure |
| 42 | + |
| 43 | +The codebase follows a structured namespace hierarchy under `WordPress\AiClient`: |
| 44 | +- `Builders`: Fluent API builders (PromptBuilder, MessageBuilder) |
| 45 | +- `Embeddings`: Embedding-related data structures |
| 46 | +- `Files`: File handling contracts and implementations |
| 47 | +- `Messages`: Message DTOs and enums |
| 48 | +- `Operations`: Long-running operation support |
| 49 | +- `Providers`: Provider system with contracts, models, and registry |
| 50 | +- `Results`: Result data structures and transformations |
| 51 | +- `Tools`: Function calling and tool support |
| 52 | +- `Util`: Utility classes for common operations |
| 53 | + |
| 54 | +### Key Design Patterns |
| 55 | + |
| 56 | +- **Interface Segregation**: Separate interfaces for different model capabilities (TextGenerationModelInterface, ImageGenerationModelInterface, etc.) |
| 57 | +- **Composition over Inheritance**: Models compose capabilities through interfaces rather than inheritance |
| 58 | +- **DTO Pattern**: Data Transfer Objects for messages, results, and configurations with JSON schema support |
| 59 | +- **Builder Pattern**: Fluent builders for constructing prompts and messages |
| 60 | + |
| 61 | +### PHP Compatibility |
| 62 | + |
| 63 | +- Minimum PHP version: 7.4 |
| 64 | +- Follows PER Coding Style |
| 65 | +- Uses type hints wherever possible within PHP 7.4 constraints |
0 commit comments