Phase 2: Coding Conventions

Establish coding standards before writing application code.

Purpose

Phase 2 sets the rules everyone (human and AI) follows. Consistent conventions prevent confusion and reduce code review friction.

Actions

Deliverables

1. Convention Document - docs/01-plan/convention.md
2. ESLint/Prettier Config - Automated enforcement
3. File Naming Rules - Directory and file naming patterns
4. Component Naming Rules - UI component conventions
5. Git Commit Conventions - Commit message format

Process

Step 1: Language & Framework Conventions

## TypeScript Conventions
- Strict mode enabled
- No `any` type (use `unknown` if needed)
- Interfaces over Types for object shapes
- Enum for fixed value sets
- Async/await over .then() chains

Step 2: Naming Rules

Step 3: Directory Structure Rules

• Group by feature, not by type
• Max 3 levels deep
• index.ts for barrel exports
• tests/ next to source files

Step 4: Git Conventions

<type>(<scope>): <description>

Types: feat, fix, docs, style, refactor, test, chore
Scope: component or module name
Description: imperative mood, lowercase, no period

Examples:
- feat(auth): add social login support
- fix(api): handle null response from user endpoint

Step 5: Code Style Enforcement

{
  "extends": ["next/core-web-vitals", "prettier"],
  "rules": {
    "no-console": "warn",
    "no-unused-vars": "error",
    "@typescript-eslint/no-explicit-any": "error"
  }
}

Convention Patterns

See references/naming-conventions.md for detailed patterns.

Output Location

docs/01-plan/
├── convention.md      # Full convention document
project/
├── .eslintrc.json     # ESLint config
├── .prettierrc        # Prettier config
└── .editorconfig      # Editor config

Next Phase

When conventions are established, proceed to $phase-3-mockup for UI/UX design.

Common Mistakes