Architecture Documentation Status:

[EXISTS]  coding-standards.md
[MISSING] tech-stack.md
[MISSING] source-tree.md
[EXISTS]  deployment.md
[MISSING] data-model.md
[MISSING] api-contracts.md

Found: 2/6 documents
Missing: 4/6 documents

What would you like to do?

1. **Create missing documents** - Generate only missing documents
2. **Recreate all documents** - Regenerate all documents (overwrites existing)
3. **Cancel** - Exit without making changes

Your choice [1/2/3]:

# {{Document Title}}

> **Purpose:** {{doc.purpose}}

**Last Updated:** {{current_date}}
**Status:** 🔴 Draft | 🟡 In Progress | 🟢 Complete

---

## Overview

_Brief overview of this document's scope and purpose_

## [Document-Specific Sections]

_Content specific to each document type_

## Related Documents

- [Architecture Overview](./architecture.md)
- [Other related docs...]

## Maintenance

**Review Frequency:** Quarterly
**Owner:** Architecture Team
**Next Review:** {{next_review_date}}

---

_Generated by PRISM architect_

## Code Style Guidelines

### General Principles
- Clarity over cleverness
- Consistency across the codebase
- Comments for why, not what

### Language-Specific Standards

#### TypeScript/JavaScript
- Use TypeScript for all new code
- Follow ESLint configuration
- Prefer functional programming patterns

#### Python
- Follow PEP 8
- Use type hints
- Docstrings for all public functions

## Naming Conventions

### Files and Directories
- Use kebab-case for file names
- Use PascalCase for component files

### Variables and Functions
- Use camelCase for variables and functions
- Use PascalCase for classes
- Use SCREAMING_SNAKE_CASE for constants

## Code Organization

### File Structure
- One component per file
- Group related functionality
- Limit file length to 300 lines

### Import Order
1. External dependencies
2. Internal modules
3. Relative imports
4. Type imports

## Error Handling

### Exception Patterns
- Use try-catch for expected errors
- Log errors with context
- Never swallow exceptions silently

## Testing Standards

### Test Coverage
- Minimum 80% code coverage
- Unit tests for all business logic
- Integration tests for critical paths

### Test Organization
- One test file per source file
- Use descriptive test names
- Follow AAA pattern (Arrange, Act, Assert)

## Code Review Guidelines

### Review Checklist
- [ ] Code follows style guidelines
- [ ] Tests pass and coverage maintained
- [ ] No security vulnerabilities
- [ ] Performance impact considered
- [ ] Documentation updated

## Technology Stack Overview

### Frontend
- **Framework:** [e.g., React 18.x]
- **Language:** TypeScript 5.x
- **State Management:** [e.g., Redux Toolkit]
- **Styling:** [e.g., Tailwind CSS]
- **Build Tool:** [e.g., Vite]

### Backend
- **Runtime:** [e.g., Node.js 20.x]
- **Framework:** [e.g., Express.js]
- **Language:** TypeScript 5.x
- **API Style:** RESTful / GraphQL

### Database
- **Primary:** [e.g., PostgreSQL 15.x]
- **Cache:** [e.g., Redis 7.x]
- **ORM:** [e.g., Prisma]

### Infrastructure
- **Cloud Provider:** [e.g., AWS]
- **Container:** Docker
- **Orchestration:** [e.g., Kubernetes]
- **CI/CD:** [e.g., GitHub Actions]

### Development Tools
- **Version Control:** Git
- **Package Manager:** [e.g., pnpm]
- **Linting:** ESLint
- **Formatting:** Prettier
- **Testing:** Jest, Playwright

## Dependencies

### Critical Dependencies
_List key dependencies that are core to the application_

| Package | Version | Purpose | Alternatives Considered |
|---------|---------|---------|------------------------|
| react | ^18.0.0 | UI Framework | Vue, Angular |

### Dependency Management
- Review dependencies quarterly
- Keep security patches current
- Document why each dependency is needed

## Technology Decisions

### Why This Stack?
_Document the reasoning behind major technology choices_

### Migration Path
_Document how to migrate between versions or technologies_

## Directory Structure

\`\`\`
project-root/
├── .prism/                    # PRISM configuration
├── docs/                      # Documentation
│   ├── architecture/         # Architecture documents
│   ├── prd/                  # Product requirements
│   └── stories/              # User stories
├── src/                      # Source code
│   ├── components/          # UI components
│   ├── services/            # Business logic
│   ├── utils/               # Utilities
│   └── types/               # Type definitions
├── tests/                    # Test files
├── scripts/                  # Build/deployment scripts
└── public/                   # Static assets
\`\`\`

## Directory Descriptions

### `/src`
**Purpose:** Main application source code

**Organization:**
- One directory per major concern
- Shared code in `/src/shared`
- Feature-based organization where applicable

### `/docs`
**Purpose:** All project documentation

**Organization:**
- Architecture documents in `/docs/architecture`
- Product specs in `/docs/prd`
- User stories in `/docs/stories`

### `/tests`
**Purpose:** Test files and test utilities

**Organization:**
- Mirror source structure
- Unit tests alongside source (`.test.ts`)
- Integration tests in `/tests/integration`
- E2E tests in `/tests/e2e`

## File Naming Conventions

### Components
- PascalCase: `UserProfile.tsx`
- Test files: `UserProfile.test.tsx`
- Style files: `UserProfile.styles.ts`

### Services
- camelCase: `authService.ts`
- Test files: `authService.test.ts`

### Utilities
- camelCase: `formatDate.ts`
- Single purpose per file

## Module Boundaries

### Import Rules
- No circular dependencies
- Services cannot import from components
- Components can import from services
- Utilities have no dependencies

## Code Location Guidelines

### When to Create New Files
- File exceeds 300 lines
- Multiple concerns in one file
- Reusable logic identified

### When to Create New Directories
- 5+ related files
- Clear domain boundary
- Shared functionality

## Deployment Architecture

### Environments

#### Development
- **URL:** http://localhost:3000
- **Purpose:** Local development
- **Database:** Local SQLite/PostgreSQL

#### Staging
- **URL:** https://staging.example.com
- **Purpose:** Pre-production testing
- **Database:** Staging database (data snapshot)

#### Production
- **URL:** https://example.com
- **Purpose:** Live application
- **Database:** Production database (backed up)

### Infrastructure Components

#### Application Servers
- Count: 3 instances (production)
- Scaling: Horizontal auto-scaling
- Health checks: /health endpoint

#### Database
- Type: Managed PostgreSQL
- Backups: Daily, retained 30 days
- Replication: Multi-AZ

#### Cache Layer
- Type: Redis cluster
- Purpose: Session storage, query cache
- Persistence: Disabled (cache only)

### Deployment Process

#### CI/CD Pipeline
1. Code push to Git
2. Run linters and tests
3. Build Docker image
4. Push to container registry
5. Deploy to environment
6. Run smoke tests
7. Monitor health

#### Rollback Strategy
- Keep last 3 versions
- Automated rollback on health check failure
- Manual rollback available

### Monitoring and Alerts

#### Key Metrics
- Response time
- Error rate
- CPU/Memory usage
- Database connections

#### Alerting
- PagerDuty for critical issues
- Slack for warnings
- Email for info

### Security

#### Access Control
- VPN required for infrastructure access
- MFA required for production
- Principle of least privilege

#### Secrets Management
- Use environment variables
- Store in secret manager
- Rotate quarterly

## Data Model Overview

### Entity Relationship Diagram

\`\`\`
[Describe ERD or link to diagram]
\`\`\`

### Core Entities

#### User
**Purpose:** Represents system users

**Fields:**
| Field | Type | Constraints | Purpose |
|-------|------|-------------|---------|
| id | UUID | PRIMARY KEY | Unique identifier |
| email | String | UNIQUE, NOT NULL | User email |
| createdAt | Timestamp | NOT NULL | Account creation |

**Relationships:**
- One-to-Many: Posts
- Many-to-Many: Roles

#### [Other Entities...]

### Database Schema

#### Tables

**users**
\`\`\`sql
CREATE TABLE users (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  email VARCHAR(255) UNIQUE NOT NULL,
  password_hash VARCHAR(255) NOT NULL,
  created_at TIMESTAMP DEFAULT NOW(),
  updated_at TIMESTAMP DEFAULT NOW()
);
\`\`\`

### Indexes

**Performance Optimization:**
\`\`\`sql
CREATE INDEX idx_users_email ON users(email);
CREATE INDEX idx_posts_user_id ON posts(user_id);
\`\`\`

### Data Relationships

#### Referential Integrity
- Foreign keys enforced
- Cascade deletes configured
- Orphan prevention

### Migration Strategy

#### Schema Changes
1. Create migration script
2. Test on staging
3. Backup production
4. Apply migration
5. Verify data integrity

### Data Retention

#### Policies
- User data: Retained until deletion request
- Logs: 90 days
- Analytics: 2 years

## API Overview

### Base URL
- **Production:** https://api.example.com/v1
- **Staging:** https://staging-api.example.com/v1
- **Development:** http://localhost:3000/api/v1

### Authentication
- **Type:** Bearer Token (JWT)
- **Header:** `Authorization: Bearer <token>`
- **Expiry:** 1 hour
- **Refresh:** Use refresh token endpoint

### API Endpoints

#### User Management

**GET /users/:id**
- **Purpose:** Get user by ID
- **Auth Required:** Yes
- **Request:**
  \`\`\`json
  // Path params
  {
    "id": "string (UUID)"
  }
  \`\`\`
- **Response (200):**
  \`\`\`json
  {
    "id": "123e4567-e89b-12d3-a456-426614174000",
    "email": "[email protected]",
    "createdAt": "2024-01-01T00:00:00Z"
  }
  \`\`\`
- **Errors:**
  - 401: Unauthorized
  - 404: User not found

**POST /users**
- **Purpose:** Create new user
- **Auth Required:** No
- **Request:**
  \`\`\`json
  {
    "email": "[email protected]",
    "password": "securepassword"
  }
  \`\`\`
- **Response (201):**
  \`\`\`json
  {
    "id": "123e4567-e89b-12d3-a456-426614174000",
    "email": "[email protected]",
    "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
  }
  \`\`\`

### Error Responses

**Standard Error Format:**
\`\`\`json
{
  "error": {
    "code": "ERROR_CODE",
    "message": "Human-readable message",
    "details": {}
  }
}
\`\`\`

### Rate Limiting
- **Limit:** 100 requests per minute
- **Headers:**
  - `X-RateLimit-Limit: 100`
  - `X-RateLimit-Remaining: 95`
  - `X-RateLimit-Reset: 1640995200`

### Versioning
- **Strategy:** URL-based versioning
- **Current:** v1
- **Deprecation:** 6-month notice

### Integration Points

#### External APIs

**Payment Gateway**
- Provider: Stripe
- Webhook: /webhooks/stripe
- Events: payment.success, payment.failed

**Email Service**
- Provider: SendGrid
- Purpose: Transactional emails
- Fallback: AWS SES

# Architecture Documentation

> **Purpose:** Complete architectural reference for the project

**Last Updated:** {{current_date}}
**Status:** 🟢 Active

---

## Quick Navigation

### Core Documents
- [Coding Standards](./coding-standards.md) - Code quality and style guidelines
- [Tech Stack](./tech-stack.md) - Technologies and dependencies
- [Source Tree](./source-tree.md) - Code organization and structure

### System Architecture
- [Deployment](./deployment.md) - Infrastructure and deployment
- [Data Model](./data-model.md) - Database schemas and relationships
- [API Contracts](./api-contracts.md) - API endpoints and integrations

## Document Status

| Document | Status | Last Updated |
|----------|--------|--------------|
| [Coding Standards](./coding-standards.md) | 🔴 Draft | {{date}} |
| [Tech Stack](./tech-stack.md) | 🔴 Draft | {{date}} |
| [Source Tree](./source-tree.md) | 🔴 Draft | {{date}} |
| [Deployment](./deployment.md) | 🔴 Draft | {{date}} |
| [Data Model](./data-model.md) | 🔴 Draft | {{date}} |
| [API Contracts](./api-contracts.md) | 🔴 Draft | {{date}} |

**Legend:**
- 🔴 Draft - Initial draft, needs review
- 🟡 In Progress - Being actively updated
- 🟢 Complete - Reviewed and approved

## How to Use This Documentation

### For Developers
1. Start with [Tech Stack](./tech-stack.md) to understand technologies
2. Review [Coding Standards](./coding-standards.md) before coding
3. Reference [Source Tree](./source-tree.md) for file organization
4. Check [API Contracts](./api-contracts.md) for integration details

### For Architects
1. Review [Deployment](./deployment.md) for infrastructure
2. Check [Data Model](./data-model.md) for database design
3. Validate [API Contracts](./api-contracts.md) for system boundaries

### For New Team Members
1. Read documents in order listed above
2. Ask questions in architecture channel
3. Propose updates via pull request

## Maintenance

**Update Frequency:**
- Review quarterly
- Update on major changes
- Keep accurate and current

**Document Owners:**
- **Coding Standards:** Engineering Team Lead
- **Tech Stack:** CTO / Technical Architect
- **Source Tree:** Engineering Team Lead
- **Deployment:** DevOps Lead
- **Data Model:** Backend Lead
- **API Contracts:** API Team Lead

## Contributing

To update architecture documentation:
1. Create feature branch
2. Update relevant document(s)
3. Update "Last Updated" date
4. Create pull request
5. Get review from document owner
6. Merge after approval

---

_Architecture documentation initialized by PRISM architect_

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Architecture Documentation Initialized!
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Location: {{arch_location}}

Documents Created:
✅ coding-standards.md
✅ tech-stack.md
✅ source-tree.md
✅ deployment.md
✅ data-model.md
✅ api-contracts.md
✅ README.md (master index)

Total: {{count}} files

**Next Steps:**

1. 📝 Review each document and fill in project-specific details
2. 🎨 Update status indicators (🔴 → 🟡 → 🟢)
3. 👥 Assign document owners
4. 📅 Schedule quarterly review
5. 🔄 Update with actual project information

**Quick Start:**
cd {{arch_location}}
code README.md

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ Architecture documentation is ready!
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━