Added configuration files for Lefthook and Oxlint, updated Docker Compose and package.json for Node version, and made various adjustments to the API and web components, including new routes and UI elements. Removed unused files and improved code structure across multiple components.

Author: Rykuno

.github/copilot-instructions.md

@@ -0,0 +1 @@
+../AGENT.md

.github/instructions/README.md

@@ -0,0 +1,85 @@
+# Instructions Directory Overview
+
+This directory contains all instruction files that guide AI assistants and developers in maintaining consistent code quality and following established patterns.
+
+## Documentation Flow
+
+```mermaid
+graph TD
+    CLAUDE[CLAUDE.md<br/>symlink]
+    CURSOR[.cursorrules<br/>symlink]
+    COPILOT[.github/copilot-instructions.md<br/>symlink]
+    HUMAN[Developer<br/>Real Human]
+
+    AGENT[AGENT.md<br/>Central Source]
+
+    CLAUDE --> AGENT
+    CURSOR --> AGENT
+    COPILOT --> AGENT
+    HUMAN --> AGENT
+
+    INST[Instruction Files<br/>typescript.md, react.md, etc.]
+    README[README Files<br/>Project & Package docs]
+    CODE[Code Examples<br/>Tests, Stories, Patterns]
+
+    AGENT --> INST
+    AGENT --> README
+    AGENT --> CODE
+
+    style CLAUDE fill:#fafafa,stroke:#222,stroke-width:1px,stroke-dasharray: 5 5,color:#222
+    style CURSOR fill:#fafafa,stroke:#222,stroke-width:1px,stroke-dasharray: 5 5,color:#222
+    style COPILOT fill:#fafafa,stroke:#222,stroke-width:1px,stroke-dasharray: 5 5,color:#222
+    style HUMAN fill:#fafafa,stroke:#222,stroke-width:2px,color:#222
+    style AGENT fill:#fafafa,stroke:#222,stroke-width:3px,color:#222
+    style INST fill:#fafafa,stroke:#222,stroke-width:1px,color:#222
+    style README fill:#fafafa,stroke:#222,stroke-width:1px,color:#222
+    style CODE fill:#fafafa,stroke:#222,stroke-width:1px,color:#222
+```
+
+Each AI assistant tool enters through its own symlink, but they all point to the central `AGENT.md` file. This central file acts as the single source of truth that references the appropriate documentation without duplicating content.
+
+## Documentation Philosophy
+
+### Structure
+
+- **AGENT.md**: Central source of truth, index pointing to resources, not duplicating content
+- **Instruction files** (.github/instructions/\*.instructions.md): Language/framework-specific rules and patterns
+  - All instruction files must follow the naming pattern `*.instructions.md`
+  - Examples: `git.instructions.md`, `typescript.instructions.md`, `react.instructions.md`
+- **README files**: Setup, usage, and overview information
+  - Root README: Project overview and quick start
+  - App/package READMEs: Specific setup and usage for that module
+- **Code examples**: Actual implementation patterns (stories, tests, example components)
+
+### Principles
+
+- Each document has ONE clear purpose
+- Avoid duplicating information across files
+- Reference other docs instead of repeating content
+- More specific docs deeper in directory tree
+- Keep instructions actionable and concise
+
+## Keep Documentation Updated
+
+**When making architectural changes or adding new tools/patterns:**
+
+1. Update the relevant documentation files to reflect changes
+2. This ensures all AI assistants have accurate, current information
+3. Include: new commands, changed workflows, updated dependencies, new patterns
+4. Remove: deprecated commands, old patterns, removed dependencies
+
+Examples of changes that require updates:
+
+- Adding/removing packages or dependencies
+- Changing build/test commands
+- Modifying project structure
+- Updating development workflows
+- Changing environment variables or ports
+- Adopting new conventions or patterns
+
+## How to Add New Instruction Files
+
+1. Create a new file following the naming pattern: `<topic>.instructions.md`
+2. Focus on ONE specific technology or pattern
+3. Include practical examples and clear guidelines
+4. Update AGENT.md to reference the new instruction file

.github/instructions/clean-code.instructions.md

@@ -0,0 +1,113 @@
+---
+applyTo: "**"
+---
+
+# Clean Code Guidelines
+
+## Important for AI Assistants
+
+Apply these principles to all code regardless of language or framework. These guidelines complement language-specific rules and should be followed universally.
+
+## Constants Over Magic Numbers
+
+- Replace hard-coded values with named constants
+- Use descriptive constant names that explain the value's purpose
+- Keep constants at the top of the file or in a dedicated constants file
+
+## Meaningful Names
+
+- Variables, functions, and classes should reveal their purpose
+- Names should explain why something exists and how it's used
+- Avoid abbreviations unless they're universally understood
+
+## Smart Comments
+
+- Don't comment on what the code does - make the code self-documenting
+- Use comments to explain why something is done a certain way
+- Document APIs, complex algorithms, and non-obvious side effects
+
+## Single Responsibility
+
+- Each function should do exactly one thing
+- Functions should be small and focused
+- If a function needs a comment to explain what it does, it should be split
+
+## DRY (Don't Repeat Yourself)
+
+- Extract repeated code into reusable functions
+- Share common logic through proper abstraction
+- Maintain single sources of truth
+
+## Clean Structure
+
+- Keep related code together
+- Organize code in a logical hierarchy
+- Use consistent file and folder naming conventions
+- Prefer simplicity over complexity
+- Prefer composition over inheritance
+
+## Encapsulation
+
+- Hide implementation details
+- Expose clear interfaces
+- Move nested conditionals into well-named functions
+- Prefer immutable data structures
+- Make state changes explicit and predictable
+
+## Explicit Over Implicit
+
+- Be explicit about intentions and behavior
+- Avoid hidden side effects
+- Make dependencies clear
+- Prefer explicit returns over implicit ones
+- Name things for what they are, not what you hope they'll be
+
+## Error Handling
+
+- Fail fast - catch errors early
+- Handle errors at the appropriate level
+- Provide meaningful error messages
+- Never ignore or suppress errors silently
+- Use proper error types and avoid generic catches
+
+## Code Quality Maintenance
+
+- Refactor continuously
+- Fix technical debt early
+- Leave code cleaner than you found it
+
+## Performance
+
+- Measure before optimizing
+- Avoid premature optimization
+- Focus on algorithmic improvements over micro-optimizations
+- Cache expensive operations
+- Be mindful of memory usage
+
+## Security
+
+- Never hardcode secrets or credentials
+- Validate all inputs
+- Sanitize outputs
+- Don't log sensitive information
+- Follow the principle of least privilege
+
+## Testing
+
+- Write tests before fixing bugs
+- Keep tests readable and maintainable
+- Test edge cases and error conditions
+
+## Version Control
+
+- Write clear commit messages
+- Make small, focused commits
+- Use meaningful branch names
+
+## Code Reviews
+
+- Focus on the code, not the person
+- Suggest improvements, don't demand changes
+- Explain the "why" behind feedback
+- Be open to different approaches
+- Prioritize critical issues over style preferences

.github/instructions/git.instructions.md

@@ -0,0 +1,192 @@
+# Git Workflow Instructions
+
+Git workflow and commit conventions for the monorepo.
+
+## Branching Strategy
+
+We follow Git Flow branching model.
+
+### Branch Types
+
+**`main`** - Production code (protected)
+
+- Never commit directly
+- Only receives merges from release and hotfix branches
+
+**`develop`** - Integration branch (protected)
+
+- Never commit directly
+- All features merge here first
+
+**`feature/*`** - New features and enhancements
+
+- Branch from: `develop`
+- Merge to: `develop`
+- Naming: `feature/[issue-id]-description` or `feature/description`
+- Deleted after merging
+- Note: Also used for chores, refactors, and other non-feature work
+
+**`release/*`** - Prepare for production
+
+- Branch from: `develop`
+- Merge to: `main` and `develop`
+- Naming: `release/vX.Y.Z`
+- Only bug fixes allowed, no new features
+
+**`hotfix/*`** - Emergency production fixes
+
+- Branch from: `main`
+- Merge to: `main` and `develop`
+- Naming: `hotfix/vX.Y.Z` or `hotfix/[issue-id]-description`
+
+## Commit Messages
+
+Follow [Conventional Commits](https://www.conventionalcommits.org/) specification.
+
+The entire first line must be ≤50 characters (type + scope + subject).
+
+### Format
+
+```
+<type>(<scope>): <subject>    ← ENTIRE LINE ≤50 CHARACTERS
+
+[optional body]
+
+[optional footer(s)]
+```
+
+### Types
+
+| Type       | Description                                         |
+| ---------- | --------------------------------------------------- |
+| `feat`     | New feature                                         |
+| `fix`      | Bug fix                                             |
+| `docs`     | Documentation only                                  |
+| `style`    | Formatting, no code change                          |
+| `refactor` | Code change that neither fixes bug nor adds feature |
+| `perf`     | Performance improvement                             |
+| `test`     | Adding or correcting tests                          |
+| `build`    | Build system or dependency changes                  |
+| `ci`       | CI configuration changes                            |
+| `chore`    | Other changes that don't modify src or test         |
+| `revert`   | Reverts a previous commit                           |
+
+### Scope (Optional)
+
+Common scopes: `api`, `web`, `ui`, `auth`, `db`, `deps`, `config`
+
+- Omit scope for changes affecting multiple areas
+- Use kebab-case for multi-word scopes (e.g., `user-auth`)
+
+### Subject Rules
+
+1. **50 character limit** for entire first line: `<type>(<scope>): <subject>`
+2. **Lowercase start**: `feat: add user auth` not `feat: Add user auth`
+3. **Imperative mood**: "add" not "adds" or "added"
+4. **No period** at the end
+5. **Blank line** required between subject and body
+
+**Quick check:** Write the full line and count characters. If >50, shorten it.
+
+### Examples
+
+```bash
+# Good (under 50 chars)
+feat(api): add user auth                     # 24
+fix(web): resolve login bug                  # 27
+refactor(config): update ts settings         # 36
+
+# Bad (over 50) → Fixed
+refactor(config): reorganize typescript configuration # 54 ❌
+refactor(config): reorganize ts config       # 38 ✅
+```
+
+### Body (Optional)
+
+- Explain **why**, not how (implementation is in the code)
+- **72 characters max per line** (hard limit, count ALL characters including spaces)
+- MUST have a blank line between subject and body (no exceptions)
+- Each line in the body must be ≤72 characters
+
+### Footer (Optional)
+
+- Issue references: `Closes #123`
+- Breaking changes: `BREAKING CHANGE: description` or `!` after type
+- Co-authors: `Co-authored-by: name <email>`
+
+### Shortening Strategies
+
+When your commit message is too long, try these:
+
+1. **Shorten the scope**: `user-management` → `users`, `authentication` → `auth`
+2. **Use abbreviations**: `configuration` → `config`, `typescript` → `ts`
+3. **Be more concise**: `implement profile picture uploads` → `add profile pics`
+4. **Remove filler words**: `establish strict` → `lockdown`, `resolve issues` → `fix`
+5. **Consider dropping scope**: If it makes the message clearer and shorter
+
+## Pre-commit Hooks
+
+Automated code quality checks run on every commit via Lefthook.
+
+### What Runs Automatically
+
+1. **oxlint** - Auto-fixes linting issues on staged JS/TS files
+2. **prettier** - Formats staged files (JS, TS, JSON, MD, YAML, CSS)
+
+These run sequentially (oxlint first, then prettier) to avoid conflicts.
+
+### Manual Checks Before Pushing
+
+While pre-commit hooks handle formatting and linting, run these manually before pushing:
+
+```bash
+pnpm tc  # or pnpm typecheck - ensure no type errors
+```
+
+The CI pipeline will catch any issues, but checking locally saves time.
+
+## Workflow Commands
+
+```bash
+# Feature work
+git checkout -b feature/description develop
+git push -u origin feature/description
+
+# Release (maintainers only)
+git checkout -b release/v1.2.0 develop
+git merge --no-ff release/v1.2.0  # to main & develop
+
+# Hotfix (maintainers only)
+git checkout -b hotfix/v1.2.1 main
+git merge --no-ff hotfix/v1.2.1   # to main & develop
+```
+
+## Version Control
+
+Follow [Semantic Versioning](https://semver.org/): `MAJOR.MINOR.PATCH`
+
+- Breaking changes increment MAJOR
+- New features increment MINOR
+- Bug fixes increment PATCH
+
+Tag format: `v1.2.3`
+
+## Critical Git Rules
+
+**NEVER use `git add -A` or `git add .`** - Always stage specific files deliberately
+
+```bash
+git add <specific-files>      # Stage deliberately
+git add -p                    # Interactive staging
+git diff --cached            # Review before committing
+```
+
+**Commit frequently**: After each logical change, not at task end
+**Keep atomic**: One change per commit
+**Check secrets**: Never commit API keys, tokens, passwords
+
+## Additional Resources
+
+- [Conventional Commits](https://www.conventionalcommits.org/)
+- [Semantic Versioning](https://semver.org/)
+- [Git Flow](https://danielkummer.github.io/git-flow-cheatsheet/)