F3: Foundation-First Framework

your-project/
├── F3_FRAMEWORK.md      # F3 hub — start here (routes to modules)
├── F3_CORE.md           # Methodology, standards, guardrails
├── F3_PROMPTS.md        # All Claude Code prompts
├── F3_TEMPLATES.md      # Document templates (CLAUDE.md, SPEC, etc.)
├── F3_SETUP.md          # Setup guides (new & existing projects)
├── F3_CHANGELOG.md      # Version history & roadmap
├── SPEC.md              # Project requirements
├── PLAN.md              # Architecture & implementation plan
├── CLAUDE.md            # Session bootstrap (Claude reads first)
├── docs/
│   ├── architecture.md  # System design
│   ├── api.md           # API contracts
│   ├── stack.md         # Tech stack details
│   ├── decisions.md     # Architecture Decision Records
│   ├── devlog.md        # Session logs
│   ├── todo.md          # Task tracking
│   └── changelog.md     # Release history
└── [your code here]     # Organize however you want

Analyze this codebase and give me an overview:
1. What is this application and what does it do?
2. What tech stack is being used?
3. What's the file/folder structure?
4. Are there any existing docs I should know about?
5. What state is the project in (MVP, production, etc.)?

Based on your analysis of this codebase, create a SPEC.md that 
documents:

1. What this application does (reverse-engineer the vision)
2. The problems it solves and who it's for
3. Core features that exist today
4. Any features that appear partially implemented
5. Technical constraints you can observe

This is retroactive documentation - we're capturing what IS, 
not what we planned to build.

Create a PLAN.md that documents the current implementation:

1. The architecture as it exists today
2. Database schema (from migrations or schema files)
3. API endpoints that exist
4. Component hierarchy
5. Dependencies in use

Mark any areas that seem incomplete or inconsistent.

Read @F3_FRAMEWORK.md and @F3_TEMPLATES.md, then set up the F3 
documentation system.

Using the templates in @F3_TEMPLATES.md, create:

1. CLAUDE.md in the project root
   - Use the CLAUDE.md template
   - Fill in project name, tech stack, current phase
   - Keep all F3 standard sections (Session Protocol, etc.)

2. /docs directory with:
   - architecture.md (system design)
   - api.md (API contracts, if applicable)
   - stack.md (tech stack details)
   - decisions.md (Architecture Decision Records)
   - devlog.md (session logs)
   - todo.md (task tracking)
   - changelog.md (release history)

Pull information from SPEC.md and PLAN.md to populate these files.
Mark anything needing my input with [TODO: ...]

Read @F3_FRAMEWORK.md and convert this existing project to the F3 
methodology.

**Phase 1: Assess Current State**
Analyze this codebase and give me an overview:
1. What is this application and what does it do?
2. What tech stack is being used?
3. What's the file/folder structure?
4. Are there any existing docs I should know about?
5. What state is the project in (MVP, production, etc.)?

**Phase 2: Create Retroactive Foundation**
Based on your analysis:
1. Create SPEC.md by reverse-engineering what was built — document 
   the vision, problems solved, core features, and any partially 
   implemented features
2. Create PLAN.md by documenting the architecture as it exists — 
   schema, API endpoints, component hierarchy, dependencies

Mark any areas that seem incomplete or inconsistent.

**Phase 3: Set Up F3 Documentation System**
Using the templates in @F3_TEMPLATES.md, create the full F3 
documentation structure:
1. CLAUDE.md in project root (customize with this project's specifics)
2. /docs/ directory with all 7 template files
3. Populate docs from your codebase analysis — don't leave them 
   as empty templates

When creating documentation:
- Architecture.md should reflect the ACTUAL current architecture
- API.md should document EXISTING endpoints
- Stack.md should list CURRENT dependencies and versions
- Decisions.md can start with a single entry: "Adopted F3 Framework"

**Phase 4: Present Summary**
Show me:
1. What files were created
2. Key findings from codebase analysis
3. Any concerns, gaps, or inconsistencies discovered
4. Recommended priorities for first F3 session

Wait for my approval before proceeding with any changes.

Read @F3_FRAMEWORK.md and its linked modules — I've updated to a 
newer version of the F3 Framework. Compare it against this project's 
current F3 setup and bring everything up to date.

**Check for changes in:**
1. F3 Framework Reference - update version number
2. F3 Methodology Reminder - replace with latest version
3. Pre-Implementation Checkpoint - add if missing, update if exists
4. Build ↔ Guide Cycle Protocol - update if changed
5. Any new sections added since this project was created
6. Any new documentation templates or files introduced
7. Any changes to folder structure or file conventions

**Process:**
1. Show me the current F3 version in this project's CLAUDE.md
2. Show me what sections need updating
3. Identify any NEW files or folders the updated F3 version requires 
   that don't exist in this project yet
4. Show me the proposed changes (diff-style)
5. Wait for my approval before making changes

Do NOT change project-specific content (Quick Context, Tech Stack, 
Current Development Phase, Critical Conventions, etc.) - only update 
F3 framework sections. Create new F3 files/folders only if the 
updated version introduces them.

Let's start a new session. Please:

1. Read CLAUDE.md for project context
2. Check /docs/devlog.md for the last session summary
3. Review /docs/todo.md for current priorities
4. Check for any unresolved BLOCKERs in devlog.md
5. Give me a brief status: what we were working on, what's next, 
   and any blockers

Then let's continue with [describe what you want to work on].

Let's wrap up this session. Please:

1. Summarize what we accomplished today with timestamps
2. Note any decisions we made
3. List any blockers or issues encountered (Hard Stops vs Soft Issues)
4. Identify priorities for next session

Then:
- Append a new entry to /docs/devlog.md with this summary
- Update the "Current Development Phase" section in CLAUDE.md
- Update /docs/todo.md to reflect completed and new tasks
- If we made any architectural decisions, add them to /docs/decisions.md

STOP - we hit a blocker that's halting progress.

Document this NOW in /docs/devlog.md:

## BLOCKER - [TIMESTAMP]

**Issue:** [Exactly what broke or what's missing]
**Impact:** [Why this stops progress completely]
**Context:** [What we were doing when this happened]
**Resolution Plan:** [Steps needed to fix this]
**Estimated Downtime:** [Your time estimate]

Then pause work until the blocker is resolved.

We just completed [FEATURE/COMPONENT NAME]. Before moving on, 
document this work NOW:

1. **devlog.md** — Add a timestamped entry:
   - What was built and why
   - Key decisions made during implementation
   - Any deviations from the original plan and rationale
   - Any gotchas or lessons learned

2. **Run the Documentation Update Triggers:**
   Check every trigger in the F3 Documentation Update Triggers table 
   and update all applicable docs:
   - API endpoints added/changed → api.md
   - Modules/services/data flow changed → architecture.md  
   - Non-trivial tech choices made → decisions.md (add ADR)
   - Dependencies changed → stack.md
   - Schema changes → architecture.md + api.md
   - Auth changes → architecture.md + api.md + decisions.md

3. **todo.md** — Mark completed items done, add any new items 
   that surfaced during implementation

4. **CLAUDE.md** — Update "Current Development Phase" if the 
   completed feature changes project status

5. **Confirm** — List which docs were updated and summarize 
   changes in 2-3 sentences.

Do NOT skip this step. Do NOT defer to session end.

DOCUMENTATION CHECKPOINT — This session has been running for a while. 
Before we continue, do a full documentation sweep NOW.

**1. Audit devlog.md**
   - Review everything we've done since the last checkpoint or 
     session start
   - Add timestamped entries for ANY work not yet documented
   - Include decisions made, problems solved, and workarounds applied
   - Flag anything that feels incomplete or uncertain

**2. Verify all docs against current code**
   Run through every Documentation Update Trigger:
   - architecture.md — Does it reflect all current components and 
     data flow?
   - api.md — Are all endpoints documented with current signatures?
   - decisions.md — Are all non-trivial tech choices captured as ADRs?
   - stack.md — Do dependencies match what's actually installed?
   - todo.md — Is the completed/pending status accurate right now?

**3. Check for doc drift**
   Compare docs against actual code. For each file:
   - If docs match code: Confirm ✓
   - If docs are behind: Update now
   - If unclear whether docs or code are correct: Log a DOC-DRIFT 
     item in todo.md and flag for my review

**4. Update CLAUDE.md**
   - "Current Development Phase" should reflect where we actually are
   - Active work items should match reality
   - Any new conventions or warnings discovered during this session

**5. Checkpoint marker**
   Add this to devlog.md:
   
   ## CHECKPOINT - [TIMESTAMP]
   Docs verified against code. All entries current through this point.
   Next priorities: [list what's next]

**6. Report**
   Give me a summary:
   - What was documented or updated
   - Any DOC-DRIFT items found
   - Any gaps or concerns
   - Confirmation that all F3 docs are current

Do NOT skip any file. We are continuing after this — this is not 
session end.

Resuming after [BLOCKER_TYPE] was resolved:

1. Read the last BLOCKER entry in /docs/devlog.md
2. Confirm what was fixed and how
3. Tell me exactly where we left off before the blocker
4. Verify the fix is working (run any relevant tests)
5. Continue from the precise point before interruption

We were working on [FEATURE] when [BLOCKER] stopped us.

I need you to rebuild your understanding of this project. Please:

1. Read CLAUDE.md for the project overview
2. Read /docs/architecture.md for system design
3. Read the last 3 entries in /docs/devlog.md for recent context
4. Check /docs/devlog.md for any unresolved BLOCKERs
5. Check /docs/todo.md for current priorities
6. Review /docs/decisions.md for key architectural choices

Then give me a summary of:
- What this project is and does
- The current development state
- Any unresolved blockers
- What we should work on next

I want to explore a new feature idea: [FEATURE_IDEA]

Before we build anything, let's run this through F3 Foundation:

**1. Explore the idea:**
- What problem does this feature solve?
- Who benefits from it?
- What's the user story? ("As a [user], I want [feature] so that [benefit]")

**2. Check fit with existing vision:**
- Read SPEC.md - how does this align with project goals?
- Does it enhance or distract from core functionality?
- Are there any conflicts with existing features?

**3. Assess implementation impact:**
- What existing components does this touch?
- What new components would be needed?
- Any database schema changes?
- Any API changes?
- Rough complexity estimate (small/medium/large)

**4. Recommend:**
- Should we add this to the spec? (Yes/No/Defer/Modify)
- If yes, draft the SPEC.md addition
- Flag any concerns or alternatives

Don't implement anything yet—just explore and recommend.

Let's add [FEATURE_NAME] to our Foundation documents.

**1. Update SPEC.md:**
- Add feature to appropriate section (Core Features, Phase 2, etc.)
- Include user story and acceptance criteria
- Note any new constraints or requirements

**2. Create implementation plan in PLAN.md:**
- Break down into components (what needs to be built)
- Define the implementation order
- Identify dependencies on existing code
- Note any architectural decisions needed

**3. Update related docs:**
- If API changes: update api.md
- If architecture changes: update architecture.md  
- If new decisions: add ADR to decisions.md
- Add to todo.md with priority

**4. Summary:**
- Show me the additions to each file
- Confirm the implementation order
- Ask if I want to proceed to implementation

Wait for my approval before making any changes to the docs.

Let's implement [FEATURE_NAME] from PLAN.md.

Following the Build ↔ Guide cycle with explicit checkpoints:

1. Build the [FIRST_COMPONENT] (backend/frontend/database)
2. When complete, STOP and announce:
   - "I've completed [COMPONENT_NAME]"
   - Show what you built (summary, files, key functionality)
   - Ask: "Would you like to review before I continue to [NEXT]?"
3. WAIT for my review and approval
4. After I approve, proceed to next component
5. Repeat: Build → Stop → Announce → Show → Ask → Wait → Approve

**Rules:**
- Complete ONE component at a time
- ALWAYS stop and announce when done
- NEVER proceed without my explicit approval
- Show me what you created before moving on
- If I give feedback, make corrections before continuing

Begin with [FIRST_COMPONENT]. Think through the implementation 
carefully, build it, then STOP and show me what you created.

**Production Standards (required for EVERY component):**
- ☐ Logging: Key actions and errors logged with context
- ☐ Error Handling: User-friendly messages, no raw errors exposed
- ☐ Security: Input validation, parameterized queries, output escaping
- ☐ Accessibility: Semantic HTML, ARIA attributes, keyboard navigation

ultrathink: Design the [COMPLEX_FEATURE] architecture.

Consider:
- How this scales to 100k+ users
- Security implications and attack vectors
- Performance bottlenecks and optimization strategies
- Error handling and recovery
- Data consistency requirements
- Integration points with existing components

Propose a complete architecture before we start coding.

Before we implement [FEATURE], let's do a quick threat check (5 minutes):

1. **Assets:** What are we protecting? (user data, credentials, money, etc.)

2. **Actors:** Who might want to abuse this? (attackers, malicious users, bots)

3. **Attack Surface:** What inputs/endpoints are exposed? What could be manipulated?

4. **Abuse Cases:** How could this feature be misused? (spam, data scraping, 
   credential stuffing, privilege escalation, injection, etc.)

5. **Mitigations:** What protections do we need? (rate limiting, validation, 
   authorization checks, logging, monitoring, etc.)

Give me a brief assessment before we proceed to implementation.

Read @F3_FRAMEWORK.md and @F3_CORE.md, then begin the Existing 
Framework Translation for this project.

Your goal is to capture my framework's DNA across all 11 translation 
categories so you can generate accurate Foundation context files.

For EACH of the 11 categories:
1. Ask me specific questions about my conventions and patterns
2. Probe for details I might not think to mention
3. Confirm your understanding before moving to the next category
4. Note the guardrail that will be enforced for that category

The 11 categories are:
01. Tech Stack Declaration
02. Folder Structure Map
03. Naming Conventions
04. Architectural Patterns
05. Component & Module Patterns
06. Styling Rules
07. State Management Approach
08. Dependency Boundaries
09. Testing Strategy
10. Environment & Deployment Context
11. "Never Do" List

After completing all categories, generate:
1. A project-context.md file with the full framework translation
2. Recommendations for what should go into CLAUDE.md
3. A summary of all guardrails that will be enforced

Let's start with Category 01: Tech Stack Declaration.

I want to build a [TYPE] application for [TARGET USERS].

The core problem: [DESCRIBE PROBLEM]

Let's create a comprehensive SPEC.md. Ask me one question at a 
time to develop a thorough specification. Each question should 
build on my previous answers.

Start by asking about the problem and users.

Read @SPEC.md thoroughly.

Before any coding, please:

1. RESEARCH:
   - Ask clarifying questions about any unclear requirements
   - Research current best practices for [TECH_STACK]
   - Identify potential technical challenges
   - Suggest optimal tech stack choices

2. CREATE PLAN.MD:
   - Development phases (MVP → Phase 2 → Phase 3)
   - Complete file structure to create
   - Component hierarchy and relationships
   - Database schema design
   - API endpoint list with methods
   - Dependencies needed
   - Estimated complexity per feature

3. WAIT FOR APPROVAL:
   Show me the plan and wait for my approval before coding.

Start with research and clarifying questions.

Stop. That's not following our pattern in CLAUDE.md.

We use [CORRECT PATTERN] not [WHAT CLAUDE DID].

Please:
1. Read @CLAUDE.md section on [PATTERN]
2. Rewrite using the correct approach
3. Explain why this pattern is better

Before you code this, explain:
1. Your approach to solving this
2. Why this is the right approach  
3. What tradeoffs you're making
4. What could go wrong

I want to validate the approach first.

That feature isn't in SPEC.md.

Let's:
1. Add it to SPEC.md as Phase 2 if important
2. Document why in decisions.md
3. Stay focused on MVP for now

Get back to [CURRENT_FEATURE].

## Scope
- [ ] Matches SPEC/PLAN requirements
- [ ] No scope creep (extra features)

## Quality
- [ ] Tests added/updated and passing
- [ ] Code follows project conventions

## Production Standards
- [ ] Logging: Key actions + errors logged
- [ ] Errors: User-safe messages only
- [ ] Security: Inputs validated, authz checked
- [ ] Accessibility: Semantic HTML, ARIA, keyboard nav

## Documentation
- [ ] Required docs updated (see triggers)

## Verification
- [ ] Commands run + outcomes captured

1. Inputs identified: [List sources + types]
2. Validation: [Schema/approach]
3. Authorization: [Who can call? How enforced?]
4. Output handling: [Escaped if rendering]
5. Logging redaction: [No secrets/PII]
6. Abuse prevention: [Rate/size limits]

1. Semantic HTML: [Correct elements — no div-buttons]
2. ARIA attributes: [Landmarks, roles, labels applied]
3. Keyboard navigation: [Tab, Enter, Escape reachable]
4. Focus management: [Visible indicators, logical order]
5. Color contrast: [4.5:1 minimum on all text]
6. Alt text: [Meaningful alt or alt="" for decorative]

# [PROJECT NAME]

> Brief one-line description

## Quick Context
[2-3 sentences: purpose, users, value proposition]

## F3 Framework Reference

This project uses F3 (Foundation-First Framework). The framework is split 
into modular files in the project root:

| Module | Contents |
|--------|----------|
| `F3_FRAMEWORK.md` | Hub — read this first, routes to all modules |
| `F3_CORE.md` | Methodology, production standards, guardrails |
| `F3_PROMPTS.md` | All Claude Code implementation prompts |
| `F3_TEMPLATES.md` | Document templates (CLAUDE.md, SPEC, docs/*) |
| `F3_SETUP.md` | Setup guides for new & existing projects |
| `F3_CHANGELOG.md` | Version history & roadmap |

**Claude: Read @F3_FRAMEWORK.md first — it routes you to the right module.**
- Need templates? → @F3_TEMPLATES.md
- Need methodology or guardrails? → @F3_CORE.md
- Need prompts? → @F3_PROMPTS.md

**Current F3 Version:** 3.0.0

## Tech Stack
- Frontend: [React, Next.js, etc.]
- Backend: [Node.js, Python, etc.]
- Database: [PostgreSQL, MongoDB, etc.]
- Infrastructure: [AWS, Vercel, etc.]

## Architecture Overview
See /docs/architecture.md for full system design.

Key Components:
- [Component 1]: [one-line description]
- [Component 2]: [one-line description]

## Current Development Phase
Phase: [MVP, Beta, Feature Development]

Active Work:
- [ ] [Current task]
- [ ] [Next priority]

Blocked By: [None or description]

Last Session: [Date] - [Brief summary]

## Critical Conventions
Code Patterns:
- [Pattern 1]: [explanation]
- [Pattern 2]: [explanation]

Git Workflow:
- Branch naming: [convention]
- Commit format: [convention]

## Operational Guardrails

### Instruction Precedence (when sources conflict)
1. System/platform constraints → 2. CLAUDE.md → 3. SPEC.md → 4. PLAN.md → 5. /docs/*

**If code conflicts with SPEC:** Treat as bug; fix code or update SPEC with approval + ADR.

### Component Sizing
- Max: ~5 files, ~300 lines per component (only tests/** and docs/** excluded)
- Risky changes (auth, billing, migrations): Single-layer only + rollback notes required

### Definition of Done (required)
- [ ] Scope matches SPEC/PLAN
- [ ] Tests passing
- [ ] Lint passes (if configured) or TODOs logged
- [ ] Logging, errors, security implemented
- [ ] Accessibility: semantic HTML, ARIA, keyboard nav
- [ ] Docs updated

### Doc Update Triggers
API change → api.md | Architecture → architecture.md | Decision → decisions.md | Schema affecting API → api.md

### Security Gate (new endpoints)
Inputs → Validate → Authorize → Escape output → Redact logs → Rate limit

### Accessibility Gate (new UI components/pages)
Semantic HTML → ARIA attributes → Keyboard nav → Focus management → Color contrast → Alt text

## Session Protocol

### F3 Methodology Reminder

This project follows F3 (Foundation-First Framework) v3.0.0:

**Area 1: Foundation** - Spec + Plan defined upfront  
**Area 2: Implementation** - Build ↔ Guide continuous cycle  
**Area 3: Documentation** - Continuous logging for persistent context
**Production Standards** - Security, logging, error handling, accessibility in every implementation

**Critical F3 Behaviors:**
- Show me each component before moving on (Build ↔ Guide cycle)
- **After completing each component: STOP, announce completion, wait for approval**
- Never proceed to next component without explicit permission
- Checkpoint progress to devlog.md after every component completion
- Document blockers immediately when they occur
- Never assume - always ask for approval before major changes
- **Include logging, error handling, security, and accessibility in EVERY component**

**⚠️ CRITICAL:** If a requested change is NOT in PLAN.md, do NOT implement it.
Stop and ask: "This isn't in our plan yet. Should we run Feature Discovery first?"

### Pre-Implementation Checkpoint

**Before starting ANY significant work, verify:**

1. ☐ Is this feature/change in SPEC.md?
2. ☐ Is there an implementation plan in PLAN.md?
3. ☐ If NO to either: **STOP** and use Feature Discovery Prompt first

**Before completing ANY component, verify Production Standards:**

4. ☐ Logging implemented for key actions and errors?
5. ☐ Error handling with user-friendly messages?
6. ☐ Security considerations addressed (input validation, auth, etc.)?
7. ☐ Accessibility: semantic HTML, ARIA attributes, keyboard navigation?

**Triggers for this checkpoint:**
- "Significant restructure" or "major refactor"
- Multi-file changes
- New components or features
- Architecture changes
- Anything described as "comprehensive" or "major"

**If you catch yourself about to implement without spec/plan:**
STOP → Acknowledge the gap → Ask: "Should we run this through F3 Foundation first?"

### Build ↔ Guide Cycle Protocol

**After completing EVERY component, you MUST:**

1. **STOP** - Do not continue to the next component
2. **ANNOUNCE:** "I've completed [COMPONENT_NAME]"
3. **SHOW:** Summary of what was built (files created/modified, key functionality)
4. **ASK:** "Would you like to review this before I continue to [NEXT_COMPONENT]?"
5. **WAIT:** Do not proceed until I give explicit approval

## Important Warnings
⚠️ Never edit files in /legacy or /vendor
⚠️ Always run tests before committing
⚠️ Checkpoint progress after completing each component

## Documentation Map
| Document | Purpose |
|----------|---------|
| /docs/architecture.md | System design |
| /docs/decisions.md | ADRs, rationale |
| /docs/stack.md | Tech choices |
| /docs/api.md | Endpoints |
| /docs/devlog.md | Session history |
| /docs/todo.md | Tasks |
| /docs/changelog.md | Releases |

## Session Start Checklist
1. Read this file (automatic)
2. Check /docs/todo.md for priorities
3. Review last /docs/devlog.md entry (including BLOCKERs)

## Session End Protocol
Before closing:
1. Summarize accomplishments and append to /docs/devlog.md
2. Update "Current Development Phase" above
3. Update /docs/todo.md with completed/new items
4. Document any decisions in /docs/decisions.md

# Project Specification

## Vision Statement
[One paragraph: What is this application and why does it exist?]

## Problem & Solution
- **Problem:** What pain point does this solve?
- **Target Users:** Who are they?
- **Solution:** How does this solve their problem?

## Core Features (MVP)
1. **[Feature Name]**
   - User Story: As a [user], I want to [action] so that [benefit]
   - Acceptance Criteria:
     * [Criterion 1]
     * [Criterion 2]
   - Priority: [High/Medium/Low]

2. **[Feature Name]**
   - User Story: ...
   - Acceptance Criteria: ...
   - Priority: ...

## User Flows
### Primary Flow: [Name]
1. User [action]
2. System [response]
3. User [action]
4. Result: [outcome]

## Success Metrics
- User engagement: [How measured]
- Performance: [LCP < 2.5s, etc.]
- Business: [Revenue, conversions, etc.]

## Technical Constraints
- Budget: [Limitations]
- Performance requirements: [Specific targets]
- Security requirements: [Authentication, compliance]
- Accessibility: [WCAG level]

## Out of Scope (v1)
- [Features explicitly NOT in MVP]
- [Features for later phases]

## Design Requirements
- Mobile-first responsive design
- Color scheme: [Colors]
- Accessibility: WCAG 2.1 AA compliance (see Accessibility Requirements below)

## Accessibility Requirements
- [ ] Semantic HTML for all UI components (no div-buttons)
- [ ] ARIA landmark roles on all page regions
- [ ] ARIA attributes on interactive widgets (menus, modals, tabs, accordions)
- [ ] Keyboard navigation: all features accessible without a mouse
- [ ] Visible focus indicators on all interactive elements
- [ ] Color contrast: 4.5:1 minimum (normal text), 3:1 (large text)
- [ ] Alt text on all informational images
- [ ] Form labels, error messages, and required field indicators
- [ ] Skip navigation link on pages with repeated nav
- [ ] Dynamic content announced via aria-live regions
- [ ] Target compliance level: [WCAG 2.1 AA / WCAG 2.2 AA / Section 508]
- [ ] Testing approach: [Manual screen reader testing / axe-core / Lighthouse / pa11y]

# Implementation Plan

## Phase 1: Foundation (Week 1-2)
- [ ] Project initialization and configuration
- [ ] Database schema setup
- [ ] Authentication system
- [ ] Basic UI framework

## Phase 2: Core Features (Week 3-4)
- [ ] Feature 1: [Name]
  - [ ] Backend API endpoints
  - [ ] Frontend components
  - [ ] Integration tests

## Phase 3: Polish (Week 5-6)
- [ ] Performance optimization
- [ ] Accessibility audit
- [ ] Security review

## Database Schema
[Schema definitions]

## API Endpoints
| Method | Endpoint | Purpose | Priority |
|--------|----------|---------|----------|
| POST | /api/auth/login | User login | High |

## Component Hierarchy
[Component tree structure]

## Dependencies
- Production: [list]
- Development: [list]