Domain Analyzer

Analyzes arbitrary codebases to discover domain structure, naming conventions, and patterns suitable for policy extraction.

Required Policies

["§WFT"]

Workflow

1. Map directory structure - Analyze top-level directories and identify logical groupings (apps, packages, services, shared)
2. Detect languages and frameworks - Identify primary languages via file extensions and framework markers (package.json, pyproject.toml, Cargo.toml)
3. Identify domain boundaries - Find natural module/package boundaries based on directory structure and import patterns
4. Extract naming conventions - Analyze file and directory names for patterns (kebab-case, PascalCase, snake_case)
5. Find recurring patterns - Search for repeated code structures that suggest extractable policy rules
6. Map integration points - Identify how domains connect (shared types, API contracts, imports)
7. Recommend domain triplets - Propose domain definitions with prefix, boundary, and suggested policy areas

Analysis Techniques

Directory structure analysis:

• Root-level directories indicate primary domains
• Nested structure depth suggests complexity
• Shared directories indicate cross-cutting concerns

Pattern detection:

• File naming: *.service.ts, *_test.py, *.spec.tsx
• Directory naming: routes/, services/, models/
• Import patterns: absolute vs relative, barrel exports

Convention indicators:

• Config files define tooling choices
• Test placement indicates testing philosophy
• Type definition locations suggest typing strategy

Output Format

## Codebase Analysis

**Root:** /path/to/project
**Languages:** TypeScript (primary), Python (secondary)
**Frameworks:** React, FastAPI, Nx

## Discovered Domains

### Domain: backend-api
- **Boundary:** `apps/api-service/`
- **Languages:** Python
- **File patterns:** `*.py`, `!*_test.py`
- **Conventions detected:**
  - snake_case for modules and functions
  - PascalCase for classes
  - Type hints on all public functions
- **Integration points:** Shared types with frontend via OpenAPI
- **Recommended policy prefix:** §BE

### Domain: frontend-web
- **Boundary:** `apps/web-client/src/`
- **Languages:** TypeScript, TSX
- **File patterns:** `*.tsx`, `*.ts`
- **Conventions detected:**
  - PascalCase components
  - camelCase utilities
  - Barrel exports in index.ts
- **Integration points:** API client from generated types
- **Recommended policy prefix:** §FE

### Domain: shared-types
- **Boundary:** `packages/shared/`
- **Languages:** TypeScript
- **File patterns:** `*.ts`
- **Conventions detected:**
  - Interface-first design
  - Re-exported from index.ts
- **Integration points:** Imported by both frontend and backend codegen
- **Recommended policy prefix:** §TYPES

## Cross-Domain Patterns

- OpenAPI spec generates both Python and TypeScript clients
- Shared validation schemas in `packages/validation/`
- Common error codes defined in `packages/errors/`

## Recommendations

**Domain triplets to create (in order):**
1. §TYPES - Shared type definitions (no dependencies)
2. §BE - Backend API patterns (depends on §TYPES)
3. §FE - Frontend patterns (depends on §TYPES)
4. §INFRA - Infrastructure patterns (references §BE)

**Additional observations:**
- Monorepo structure suggests §MONO policy needed
- Test patterns consistent enough for §TEST policy
- No documentation conventions detected

Success Criteria

• All major code directories analyzed and categorized
• Primary languages and frameworks identified
• Domain boundaries clearly defined with file patterns
• Naming conventions documented per domain
• Integration points mapped between domains
• Actionable triplet recommendations with creation order
• No assumptions made about structure - all findings evidence-based