Analyze workspace: {workspace_root}

File structure: {files_structure_summary}

## Tool Budget

You have a MAXIMUM of 3 tool rounds. Use them strategically:

Round 1: Identify and list ALL files needed for analysis
Round 2: Read ALL files in a single batch
Round 3: Investigate findings from file contents (if needed)

Optional 4th round only in rare cases when absolutely necessary.

## Efficiency Strategy

1. Look at the file structure and identify ALL files needed at once
2. Read ALL of them in a SINGLE batch (Read tool supports multiple calls)
3. Use the third round to investigate any findings that need clarification
4. Never use Grep or search - just read the files directly

## Penalties

- 🚫 Do NOT read the same file multiple times
- 🚫 Do NOT search for files - the file structure provided is complete
- 🚫 Do NOT make separate tool calls for files in the same directory

## CRITICAL Rules

- has_package_manager = true ONLY if project has dependencies listed in its config file. Empty dependencies = false.
- Check ALL relevant dependency sections (dependencies, devDependencies, peerDependencies, etc.)
- Determine ecosystem based on the package manager type

TASKS:

1. Find and read all configuration files (any package managers) for ACTUAL projects only
2. Determine ecosystems and dependencies from actual config content
3. Detect project type based on dependencies and file structure
4. Return ONLY valid JSON - no explanations, no markdown blocks, no additional text

## CRITICAL: Project vs Test Data Distinction

Only analyze ACTUAL projects, not test data, examples, or fixtures:

- **EXCLUDE**: test-fixtures/, examples/, sample/, templates/, demos/, **tests**/, spec/, test/
- **EXCLUDE**: Any directory that appears to contain example/test code rather than production code
- **INCLUDE**: Only directories that represent actual working projects or applications
- **ROOT PROJECT**: Only include root as a project if:
  - It has actual application dependencies (not just build tools/dev dependencies), OR  
  - It's a single project workspace (workspace has only one project)

Look for indicators that distinguish real projects from test data:

- Real projects: Have meaningful dependencies, proper structure, production-ready code
- Test data: Minimal configs, example code, fixture data, sample applications

IMPORTANT: Do NOT use `json` markdown blocks. Return raw JSON only.

## Language Detection Rules:

Detect the PRIMARY language for each project based on file extensions and patterns. Examples: `typescript` for .ts files or tsconfig.json, `python` for .py files, `java` for .java files, `csharp` for .cs files, `go` for .go files, etc. When multiple languages are present, choose the PRIMARY language that represents the main codebase.

## Project Type Detection Rules:

- **cli_tool**: Command-line applications that users interact with via terminal. Examples: commander (JS), click (Python), clap (Rust), cobra (Go)
- **web_app**: Frontend applications served to browsers. Examples: react/next (JS), django (Python), rails (Ruby), laravel (PHP)
- **api_server**: HTTP services providing REST/GraphQL APIs. Examples: express (JS), fastapi (Python), gin (Go), spring-boot (Java)
- **backend_service**: Background processors for queues, cron jobs, data processing. Examples: bull (JS), celery (Python), sidekiq (Ruby)
- **library**: Reusable code packages published to registries. Examples: npm packages, pip packages, cargo crates, maven artifacts
- **script**: Simple automation or utility scripts. Examples: build scripts, deployment scripts, data migration scripts
- **infrastructure**: Infrastructure-as-code and deployment configurations. Examples: terraform, kubernetes manifests, docker-compose
- **desktop_app**: Native desktop applications. Examples: electron (JS), tkinter (Python), javafx (Java), wpf (C#)
- **mobile_app**: Mobile applications for phones/tablets. Examples: react-native, flutter, native iOS/Android projects
- **unknown**: Cannot determine project type from available information

## Framework Detection:

For each project, identify the PRIMARY framework that defines the project's architecture and runtime environment. **IMPORTANT**: Verify the framework is actually used, not just listed as a dependency.

**Validation Required:**
- Don't assume framework presence in dependencies means it's used
- Verify detected framework is actively used by checking:
  - Project patterns correlate with framework patterns
  - Framework is actively used in codebase, not just listed as dependency
- Look for framework-specific files, configurations, or code patterns
- If framework is listed but not actively used, set to null

**General Principle:**
Look for the main architectural framework that provides the application structure, routing, and runtime environment. Examples across ecosystems:

- **Web Apps**: nextjs (JS), django (Python), rails (Ruby), laravel (PHP), spring-boot (Java)
- **API Servers**: express (JS), fastapi (Python), gin (Go), rails (Ruby), aspnet-core (C#)
- **CLI Tools**: commander (JS), click (Python), clap (Rust), cobra (Go)

**Context-Aware Detection:**
When multiple frameworks could apply, prioritize the one that defines the project's primary architecture:

- UI libraries (react, vue, angular) are NEVER the main framework - they are rendering libraries
- Build tools, bundlers, and utilities are NOT frameworks
- Look for frameworks that provide application structure, not just UI components
- For vanilla apps without architectural frameworks, set to null

**Common Mistakes to Avoid:**

- Don't list UI/component libraries as frameworks (react, vue, angular, etc.)
- Don't list utility libraries, build tools, or testing frameworks
- Don't list databases, ORMs, or data access layers
- Focus on what provides the application's core architecture and runtime
- Never assume dependency presence equals active usage

Set framework to null if no clear architectural framework is identified OR if the framework is not actively used.

## Docker Detection:

For each project, check if a Dockerfile exists. Set dockerized to true if present, false otherwise.

## CI/CD Detection:

For the workspace, detect which CI/CD system is being used. Look for CI/CD configuration files in the workspace root (such as .github/workflows/, .gitlab-ci.yml, etc.). Set to "none" if no CI/CD configuration found.

CRITICAL: After your analysis, write the results to `.chorenzo/analysis.json` using the Write tool. The file content must be ONLY this JSON structure with no other text.

After writing the analysis file, you MUST run `npx chorenzo analysis validate` to validate the analysis.json file structure. If validation fails, fix the issues and rewrite the file until validation passes.

Expected JSON structure:
{
"isMonorepo": boolean,
"hasWorkspacePackageManager": boolean,
"workspaceEcosystem": {{{ecosystems}}} | null,
"workspaceDependencies": string[],
"ciCd": {{{cicd_systems}}},
"projects": [
{
"path": string,
"language": string,
"type": {{{project_types}}},
"framework": string | null,
"dockerized": boolean,
"dependencies": string[],
"hasPackageManager": boolean,
"ecosystem": {{{ecosystems}}} | null
}
]
}